32K memory expansion cartridge

[tormod]

memcart1s.jpg (80.37 KiB) Viewed 9429 times

We all know 32K is enough for everybody, but... This was my Christmas present for myself: A 32K memory expansion for my Dragon 32 that plugs into the cartridge port. I can now run NitrOS-9 like on a Dragon 64!

First, after studying the 74LS783 SAM datasheet, I thought I could make the expansion card almost fully compatible with how the Dragon 64 works, enabling the extra RAM while in SAM "map type 1" (all-RAM). But after some trials and looking more closely at the Dragon 32 schematics I understood this could not work.

So instead this card adds a new "map". When poking $FFBF, it disables the BASIC ROM and the card's RAM is available at $8000-FEFF. Poking $FFBE brings back the ROM again. (This "external map" will only activate in SAM map type 0.)

This is different from a Dragon 64:

• Video RAM access must stay in the lower 32K (because the 6847 VDG can only reach the internal memory). So for instance NitrOS-9 needs a small patch.
• The 32K cannot be swapped into the lower 32K (because the cartridge cannot disable the internal lower 32K on writes). Very few 64K programs use this "page" switch on the Dragon 64.
• To go 64K RAM, poke $FFBF instead of $FFDF. NitrOS-9 needs this modification as well.

The card should be of interest to hard-core Dragon 32 owners who are interested in NitrOS-9 but find 7K of available memory a little tight Of course, DriveWire becomes important since the card occupies the cartridge port.

It can also be used on a Dragon 64 to have a total of 96K RAM. But there is no software (yet) to use it. If someone ports Fuzix to it, they'll have free boards

There are some unpopulated headers and spare signals for use as a development board. It is made more in that spirit than a "consumer" product.

I would like to charge 20 USD for an assembled board, plus shipping (economy is 3 USD to Europe, 5 USD world). I have 7-8 boards that I can part with. Send e-mail to:

My "biz" e-mail address.

dragon-tormod-email.png (2.78 KiB) Viewed 9429 times

[pser1]

Hi Tormod,

once again, a pretty and very interesting add-on for my Dragon32
I am sending a mail to you to get one of these!

thanks for working so hard for the Dragon

cheers
pere

[sorchard]

Looks like another fine Tormod product. Neat idea

I'm guessing you're using the EXTMEM signal to disable the LS138.

As you have no doubt discovered, the 9572 can hold quite a bit of logic so it will be interesting to see how this evolves.

[tormod]

Yes, I use the EXTMEM signal (a.k.a. SLENB or DSD) to disable internal devices when the cartridge memory is active. Unfortunately EXTMEM doesn't disable writes to DRAM, which are clocked in directly by the SAM. So any external memory device must stay in the memory space where the SAM believe there is no DRAM (above $8000 and only in SAM map type 0). A MMU with full 64K spaces like on the CoCo3 and used by NitrOS-9 Level 2 just cannot be done externally. It wouldn't take much internal surgery to gate the DRAM writes but then there wouldn't be much point in an external upgrade... For Level 1 however this cartridge gives you the full experience.

It is really nice to be able to configure the logic on the 9572 after the PCBs are ready and some testing can be done. Actually I didn't prototype it, it just worked Currently I am pondering if I should add some "half" modes where only C000-FEFF is active, or maybe even E000-FEFF. Or a software-enabled write lock for BASIC/cartridge ROM emulation, although marginally useful, it would be a feature you don't have in "all-RAM" on a Dragon 64.

[sorchard]

Hmm... you've got me thinking now... I'm not sure that the problem of unwanted writes to internal DRAM is a show stopper for an MMU:

On a 64K machine, one solution might be to put the display in the upper 32K and run in MAP0. Now it doesn't matter that writes to the lower 32K also write to the DRAM. To access the display memory it will be necessary to switch to MAP1 or set the P bit.

One solution for 32K machines is to have a fixed page in the lower 32K reserved for display use.

Another solution for 32K ISS2 machines that run with a 64K memory map is to use the P bit to move the display memory out of the way.

To read back from the display memory, this could be done in software by mapping in an external page on top of the display memory to act as shadow RAM. Writes would go to both memories and reads would be from the external memory. A hardware approach could be to enable a read from internal DRAM when the MMU detects we want to read from display memory.

Detecting task switches to implement system and user maps could be more tricky. An internal MMU has the luxury of access to the 6809 BS and BA signals to figure out what's happening. An external MMU might be able to do it by snooping the bus and detecting when a vector fetch is occurring but it would have to be smart enough to not be falsely triggered by a user instruction reading the vectors.

[tormod]

You've got some good ideas there. I am a bit Dragon 32 centric and would prefer something that wouldn't discriminate them. Having a fixed video page mapped in maybe reduces some compatibility but could be a limitation one can live with. Some modification of Level 2 video drivers and memory managers will be needed anyway.

Good point about the task switching. You got me thinking there... I took a quick look at Level 2 on the CoCo3, it seems it has a vector RAM page (256 byte) mapped in permanently at FE00, but write-protected in user mode by the MMU. There it reads out user/system mode from a GIME register.

I have an idea that might work to detect an interrupt service: Detect an address bus cycle sequence that goes
1. FFFx where x is odd and not F
2. FExx (or wherever the vector RAM page is)
That pattern would be characteristic of an interrupt service since most non-instruction fetch memory access will be followed by a VMA cycle with FFFF on the address bus. From the 6809 datasheet it seems like also indirect address modes resulting in an effective address on the bus will be followed directly by the next instruction fetch without an intermediate VMA cycle, so an indirect access of FFFx executed at the end of FDxx where the next instruction would be in FEXX would also match this pattern. However a trap at the beginning of FExx (which should be there in any case to prevent something from running across from FDxx) would take care of this.

The above sequence would be simple to detect in a CPLD.

Maybe we should move this brainstorming out of the Sales section