internal console expansion system

[dphirschler]

So I have this idea and I want help to flesh it out. This all started with the internal speech mod, which I still plan on doing eventually. And after I got the new 32k mem expansion board, I started thinking of ways to mount it internally. So the speech mod required wires soldered to several leads on the mainboard. They have to be far enough back so that you can still plug in the PE box firehose. So what if a small board was made that was simply a sideport connector, a backward-facing ribbon cable that went directly into the console, ending with an edge connector that the speech synth could be plugged into? Does that sound feasible? Perhaps even a 32k board could be chained to it if the connector was on the edge of the board. All this would be inside the console! I am only guessing that it all fits in there above the mainboard.

 

Thoughts?

 

 

Darryl

[Sinphaltimus]

If you could do a short ribbon cable just plug the speech synth in to the 32k side port both mounted internally. Leave edge connector for fire hose.

[RickyDean]

So I have this idea and I want help to flesh it out. This all started with the internal speech mod, which I still plan on doing eventually. And after I got the new 32k mem expansion board, I started thinking of ways to mount it internally. So the speech mod required wires soldered to several leads on the mainboard. They have to be far enough back so that you can still plug in the PE box firehose. So what if a small board was made that was simply a sideport connector, a backward-facing ribbon cable that went directly into the console, ending with an edge connector that the speech synth could be plugged into? Does that sound feasible? Perhaps even a 32k board could be chained to it if the connector was on the edge of the board. All this would be inside the console! I am only guessing that it all fits in there above the mainboard.

 

Thoughts?

 

 

Darryl

Well if your going that route, you could always look up the schematics for a zeno board or do a internal 32k mod and add in the speech synth. I thought the external 32k mod was meant to replace the peb 32k without opening the console, but each to their own.

[+arcadeshopper]

Pretty much, if you are going to go through all the trouble of wiring in the 32k internally the little pcb with just a couple chips is your best route. The external 32k is designed to eliminate the need for cracking open the console for those that are not up to the task of soldering 21 wires to various chips

 

Greg

[Omega-TI]

The internal 32K mod is really inexpensive for sure, and it can be a great option for those who NEVER plan to expand a specific console in the future.

 

There are a couple of drawbacks with the internal modification though:

 

1) Age - sadly for some of us, our eyes are not what they used to be, so if you want to get it done for you, labor and possibly

even the cost of shipping may cost as much, if not more than just buying one of Matt's Plug-N-Play devices.

2) If think you might want to expand in the future, it would be easier to unplug a device like Matt's 32K Plug-N-Play unit and go from there.

3) If you do expand in the future you'll have to either disable or remove the internal modification.

 

Now me, I'm just lazy when it comes to doing anything I may have to undo later, so Matt's little device is great.

[apersson850]

My own internal memory expansion, 64 Kbytes, can be disabled by CRU setting selective CRU bits. By default, the 64 K RAM is enabled at the addresses where you normally find a 32 K memory expansion, and disabled elsewhere.

Then, by setting CRU bits at base address >400, I can enable 8K RAM blocks overlaying internal console ROM, DSR space etc., to eventually get contiguous 64 K RAM in the console. I can also disable the internal 32 K RAM, which then will send memory access instructions to the external memory expansion, if available. Thus my design allow two 32 K RAM expansions to exist at the same time, with access to either one or the other at any specific moment.

I also have hardware, enabled by a CRU bit, which detects and inserts a wait cycle in VDP accesses, so that it's not necessary to add NOP instructions to handle the VDP correctly.

 

Via a switch on the outside, the mapping of the internal 32 K RAM expansion can be inverted, if you want the console to start up with the internal 32 K RAM disabled, and then enable it with the CRU bit instead.

Thus such a design is more flexible, but still completely transparent, than a "fixed" internal 32 K RAM expansion.

[RickyDean]

My own internal memory expansion, 64 Kbytes, can be disabled by CRU setting selective CRU bits. By default, the 64 K RAM is enabled at the addresses where you normally find a 32 K memory expansion, and disabled elsewhere.

Then, by setting CRU bits at base address >400, I can enable 8K RAM blocks overlaying internal console ROM, DSR space etc., to eventually get contiguous 64 K RAM in the console. I can also disable the internal 32 K RAM, which then will send memory access instructions to the external memory expansion, if available. Thus my design allow two 32 K RAM expansions to exist at the same time, with access to either one or the other at any specific moment.

I also have hardware, enabled by a CRU bit, which detects and inserts a wait cycle in VDP accesses, so that it's not necessary to add NOP instructions to handle the VDP correctly.

 

Via a switch on the outside, the mapping of the internal 32 K RAM expansion can be inverted, if you want the console to start up with the internal 32 K RAM disabled, and then enable it with the CRU bit instead.

Thus such a design is more flexible, but still completely transparent, than a "fixed" internal 32 K RAM expansion.

Do you, by chance, have plans, schematics? Sounds intriguing.

[apersson850]

I should have some pencil drawings from "back then". I think they are still in the attic. Some photos of the install too.

 

Internal memory expansion 1

Internal memory expansion 2

Internal memory expansion 3

 

As can be seen it's the piggy-back principle. As far as I can remember, I got the idea from someone who mounted 64 K RAM to get 32 K RAM (the double capacity was just to make it 16 bit wide). But I thought that when I had 64 K RAM in there, I could just as well make it useful. When running software which doesn't rely on ROM in a cartridge, you can use the cartridge memory space, >6000 - >7FFF, as an extra buffer, for example. Since you can switch the RAM in and out as you like, you can even both use a cartridge with ROM (like Extended BASIC) and use the same area as an 8 K buffer at the same time. The only demand is that you access the buffer via assembly, from a program that runs somewhere else.

Or you can copy the console ROM to RAM, then play with modifying the interrupt vectors and get your own interrupt service routine. Or you can switch the ordinary 32 K RAM in and out, to get an extra buffer there.

Or you can let the computer use the ordinary 32 K RAM normally, and the internal one for a buffer, if it's important that the program executes at original speed.

 

Being able to overlay all memory with 16 bit wide non wait state RAM implies that the speedup of assembly programs is about 110 %, if you compare programs that runs entirely within the normally 8-bit wide memory expansion (both workspace, code and operators). Most programs do have at least the workspace in fast console RAM, and then the speedup is less dramatic.

Edited January 13, 2017 by apersson850

[RickyDean]

I should have some pencil drawings from "back then". I think they are still in the attic. Some photos of the install too.

 

Internal memory expansion 1

Internal memory expansion 2

Internal memory expansion 3

 

As can be seen it's the piggy-back principle. As far as I can remember, I got the idea from someone who mounted 64 K RAM to get 32 K RAM (the double capacity was just to make it 16 bit wide). But I thought that when I had 64 K RAM in there, I could just as well make it useful. When running software which doesn't rely on ROM in a cartridge, you can use the cartridge memory space, >6000 - >7FFF, as an extra buffer, for example. Since you can switch the RAM in and out as you like, you can even both use a cartridge with ROM (like Extended BASIC) and use the same area as an 8 K buffer at the same time. The only demand is that you access the buffer via assembly, from a program that runs somewhere else.

Or you can copy the console ROM to RAM, then play with modifying the interrupt vectors and get your own interrupt service routine. Or you can switch the ordinary 32 K RAM in and out, to get an extra buffer there.

Or you can let the computer use the ordinary 32 K RAM normally, and the internal one for a buffer, if it's important that the program executes at original speed.

 

Being able to overlay all memory with 16 bit wide non wait state RAM implies that the speedup of assembly programs is about 110 %, if you compare programs that runs entirely within the normally 8-bit wide memory expansion (both workspace, code and operators). Most programs do have at least the workspace in fast console RAM, and then the speedup is less dramatic.

Yes I actually have this upgrade on two of my motherboards ( discussed sometime last year in a 32k thread here) and had wondered at the time if the complete memory could be used, yes I would be interested in seeing how you did it.

[Asmusr]

Why is it not possible for SAMS to overlay the system ROMs and other memory areas? Does it have to be connected to the 16-bit bus in order to do that?

[+mizapf]

Being able to overlay all memory with 16 bit wide non wait state RAM implies that the speedup of assembly programs is about 110 %, if you compare programs that runs entirely within the normally 8-bit wide memory expansion (both workspace, code and operators). Most programs do have at least the workspace in fast console RAM, and then the speedup is less dramatic.

 

How do you overlay the system ROMs? I guess you have to cut traces on the board to inhibit the selection line.

[apersson850]

The different 8 K memory blocks have their address lines split up, so that they are sent to this or that circuit,depending on the state of their associated CRU bit. Thus console ROM is kept off when RAM is enabled at the same addresses.

Due to the implementation of various memory mapped I/O in the console, I've chosen not to implement any write-through, though.