DRAM data retention time

A place to discuss everything Dragon related that doesn't fall into the other categories.
tjewell
Posts: 309
Joined: Mon Oct 19, 2009 4:58 pm
Location: Cambridge, England

Re: DRAM data retention time

Post by tjewell »

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
sixxie
Posts: 1181
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: DRAM data retention time

Post by sixxie »

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)
sorchard
Posts: 466
Joined: Sat Jun 07, 2014 9:43 pm
Location: Norwich UK

Re: DRAM data retention time

Post by sorchard »

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.

20210524_125449.jpg
20210524_125449.jpg (2.51 MiB) Viewed 1585 times
20210524_155120.jpg
20210524_155120.jpg (2.39 MiB) Viewed 1585 times
20210524_155148.jpg
20210524_155148.jpg (3.28 MiB) Viewed 1585 times
Stew
sixxie
Posts: 1181
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: DRAM data retention time

Post by sixxie »

That looks nice and small and elegant! And portable, too - mine will need the Dragon 64 board layout.
tjewell
Posts: 309
Joined: Mon Oct 19, 2009 4:58 pm
Location: Cambridge, England

Re: DRAM data retention time

Post by tjewell »

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!
PXL_20210607_214630073.jpeg
PXL_20210607_214630073.jpeg (955.75 KiB) Viewed 1345 times
PXL_20210607_210545283.jpeg
PXL_20210607_210545283.jpeg (1.32 MiB) Viewed 1345 times
bluearcus
Posts: 95
Joined: Wed Sep 07, 2016 4:45 pm

Re: Memory upgrade hijack!

Post by bluearcus »

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.
sorchard
Posts: 466
Joined: Sat Jun 07, 2014 9:43 pm
Location: Norwich UK

Re: DRAM data retention time

Post by sorchard »

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.
Stew
bluearcus
Posts: 95
Joined: Wed Sep 07, 2016 4:45 pm

Re: the Delphi archives

Post by bluearcus »

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
bluearcus
Posts: 95
Joined: Wed Sep 07, 2016 4:45 pm

Re: Anything OS9 level 1 data retention time

Post by bluearcus »

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!
Post Reply