Jump to content
IGNORED

internal console expansion system


dphirschler
 Share

Recommended Posts

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

Link to comment
Share on other sites

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. :)

  • Like 1
Link to comment
Share on other sites

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 :D

 

Greg

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 weeks later...

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.

  • Like 1
Link to comment
Share on other sites

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. :)

Link to comment
Share on other sites

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 by apersson850
  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...