archive.worldofdragon.org

Great stuff guys!

I'm back playing with Fuzix again, which means I've got Tormod's 512K MOOH card plugged into my machine. Having an internal memory upgrade would (I presume) free up my cartridge port again, which would be really useful. Would either of these upgrades use banking in a similar style to the MOOH? Always up for beta-testing if it gets to that stage!

Cheers, Tony

My thing would be quite MOOH-like because I'm also trying to replicate the CoCo 3 MMU functions. Some of them, anyway. But it's not happening any time soon, as parts are a little less available than they used to be...

(With apologies to Stewart for the inadvertent topic hijack)

I invited a hijack by mentioning the memory upgrade at the start so I can't get mad

It sounds like Ciaran's upgrade is going to be more plug and play than mine, as he's looking at an MMU, plus the upgrade board hosts the memory.

I've gone old school with my upgrade: It's based on a design for the CoCo from the 80's that provides the extra address line required to drive 256K DRAMs fitted to the Dragon main board. The memory is banked in 32K pages, limiting your options as far as operating systems go, but still useful e.g. RAM disk, sideways software, banked rom emulation, high-res text display in shadow ram etc.

The main prerequisite is you need your 64K memory socketed, so that it can be replaced with 256K. More details here

The pcb design has been successfully tested in a (formerly) 64K upgraded Dragon 32.

That looks nice and small and elegant! And portable, too - mine will need the Dragon 64 board layout.

And here it is working happily on a D64. A little fiddlier - socketing the RAM was a bit of a nightmare, as the tiniest bit of solder left on the component side would mean torn pads and traces when I tried to the remove the chip (so there's a few bodge wires on the underside!). But it's sitting there running its tests, and working fine! Cheers Stew!

sorchard wrote: ↑Mon May 24, 2021 8:44 pm I've gone old school with my upgrade: It's based on a design for the CoCo from the 80's that provides the extra address line required to drive 256K DRAMs fitted to the Dragon main board. The memory is banked in 32K pages, limiting your options as far as operating systems go, but still useful e.g. RAM disk, sideways software, banked rom emulation, high-res text display in shadow ram etc.

The main prerequisite is you need your 64K memory socketed, so that it can be replaced with 256K. More details here

The pcb design has been successfully tested in a (formerly) 64K upgraded Dragon 32.

Very nice!

That bank access mechanism is a quite infuriating for OS9 ramdisk use, as a truly horrible hack will be required to do the stub thing.

As you've got the GAL, a Z7 invert option set/cleared by a new address pair that only applies in Banks 1-3 would make all the banks accessible from RAM mode without terrible coding horrors...

Hmm. I'm going to go back to thinking about that coding horror now, but will probably try for 90k first!

Mike.

A Z7 invert option is a great idea. I wish it would fit but unfortunately the GAL only has one spare I/O, and that would get used up just by adding the register.

I wonder if any OS support was produced for the original banker board? There was no mention of it in the Hot CoCo article.

Edit:
Drivers were written according to this document: http://www.cocopedia.com/wiki/index.php ... em_Modules
Not sure were to find them though.

Oh, that's unfortunate. Was fooled by the schematic which looks to suggest some spare capacity!

Anyway a zip of the Delphi OS9 archives containing a 'drivepak' of those OS9 6809 system modules is on the Coco archive for download. So looks like I'll be downloading that and trying to figure out how to access the contents then!

Well be interesting to compare drivers between the Compusense DragonPlus one, which I've just been through and commented, and these ones. Might help me understand a couple of odd looking bits of driver code.

The Compusense driver did have some mileage to be adapted for this though as it inexplicably left the bottom 512 bytes of each 32k page unused by the Ramdisk, so space for a restore buffer and a stub area were available and could be set up as part of the initialisation process. Still pretty ich-y though.

Mike

Oh, looks like I made a bit of an assumption there.

Just because a list of modules exists, doesn't mean that list corresponds to the contents of any available archive. Ah well, back to thinking about the stub mechanism!

Aha. Via Dragon Update and The Rainbow Feb '86... there is some OS9 driver info available!

Dale L. Puckett's KISSable OS9 column published an original banker board OS9 ramdisk drive and source code by William Good. The driver uses a helper program which modifies the driver module loading to ensure it and the device descriptor are in low 32k, and an access stub in high mem pages to enable access to low mem ones.