Author Topic: Open Source, DIY 512KB RAM Expansion  (Read 1933 times)

0 Members and 1 Guest are viewing this topic.

Offline Sykobee (Briggsy)

  • 6128 Plus
  • ******
  • Posts: 648
  • Country: gb
  • Liked: 214
Re: Open Source, DIY 512KB RAM Expansion
« Reply #25 on: 13:43, 18 May 18 »
Very nice. Put me down for one (a kit would be great, but I'm sure I can manage a digikey order).


Would it be better to centralise the M4 connector at the bottom, for balance, or maybe that wouldn't work if someone has made an M4 case (are there M4 cases?).


Also I wonder how hard it would be to get to 1MB or 2MB, given you have board space?

Offline revaldinho

  • CPC464
  • **
  • Posts: 26
  • Country: gb
  • Liked: 30
Re: Open Source, DIY 512KB RAM Expansion
« Reply #26 on: 23:39, 18 May 18 »



Would the board route with the connector in the absolute centre ? Actually I think I started off with the connector in the centre and moved things around to where they are now to improve the routing. Here's a snap of the underside of the board (attached) where you can see that having the connector offset to be underneath the RAM IC has allowed the relatively large number of address and data signals to have short paths with few vias. Moving the connector back to the centre would probably work although there would be more horizontal routing and vias and I think a lower quality result although I'm not really a PCB design expert so I don't really know that it would matter at these speeds. Maybe I could avoid the extra routing anyway by splitting some of the 74 logic on either side of the RAM? That's certainly possible. Well, I don't know. I'm not planning to move the connector for the respin though. I would like to minimise the number of changes given I seem to have a solid working part now.


Just for future reference though, is there any well accepted board size or connector layout for expansion modules to aim for, to fit some easily available case ?


(I do quite fancy having a mini -rack mount type box for a motherboard and expansion cards. Has anyone built one of these ?)


And would a larger memory size be possible in the 'old school' style ?


I think probably not in the 100mm x 80 mm limit here. Although the board looks pretty comfortable for the 512K RAM, there is only the one large RAM IC. I can't find any SRAM parts larger that this 1Mbit (512Kx8)  in a DIL package on Mouser or Digi-Key. Everything bigger is in an SMD pack of some sort. So to stick with the all-through-hole style would mean multiple RAM ICs on the board which would use up space very quickly. There's also the additional decoding requirement which might be 2 or 3 or even more 74 series parts. All in all, I suspect it wouldn't fit. Again, I haven't tried it, but I suspect that's just too many components for this DIY kit approach and board size.


There are plenty of other RAM expansions about though including at least one 4MB one in development here. If you're not quite as intimidated by SMD soldering as I am, you might even be able to get one to build yourself  :D




R




Offline Duke

  • Supporter
  • 6128 Plus
  • *
  • Posts: 849
  • Country: dk
    • spinpoint.org
  • Liked: 789
Re: Open Source, DIY 512KB RAM Expansion
« Reply #27 on: 09:41, 19 May 18 »
Just for future reference though, is there any well accepted board size or connector layout for expansion modules to aim for, to fit some easily available case ?
MotherX4 (which many use) plugin boards are normally ~80x50 mm with right angle male IDC connector front and center mounted. See ie. Playcity, Xmem etc cards.
Not that it's very important, but it looks nice maybe :)

Offline gerald

  • Supporter
  • 6128 Plus
  • *
  • Posts: 1.244
  • Liked: 894
Re: Open Source, DIY 512KB RAM Expansion
« Reply #28 on: 13:32, 19 May 18 »
Here's a snap of the underside of the board (attached) where you can see that having the connector offset to be underneath the RAM IC has allowed the relatively large number of address and data signals to have short paths with few vias.
Having the RAM parallel to the connector would be far better from a routing point of view since data and address are both grouped on the connector and the RAM. Note also that you don't need to match address and data bit on the RAM level, it does not matter. You can shuffle the bits to ease the layout  (ie putting A10 from CPC to A1 on the RAM).

Offline revaldinho

  • CPC464
  • **
  • Posts: 26
  • Country: gb
  • Liked: 30
Re: Open Source, DIY 512KB RAM Expansion
« Reply #29 on: 14:24, 20 May 18 »
Yes, in fact if you look closely you can see that the address lines are out of order going from connector to SRAM, so that's at least one trick I didn't miss  :D


Have done a bit more testing today and yesterday.


I can run the DK'tronics RAM Expansion RSXes and it correctly identifies the 256K portion of the expansion. Typing in the screen swapping demos from the manual (|SAVES, |LOADS) all works fine.


Also this weekend I have assembled a ROM board so now I can try the Silicon Disk software. That works fine too both in AMSDOS and under CPM2.2 (I have a '464).


So that was all looking good.


My ROM board has the option to switch the lower ROM out too, so I used that to switch firmware and BASIC to v1.1 to turn my '464 into a 6128, nearly.  I thought that I would be able to boot into CPM Plus. I just get this message though "This program will not run in this environment. Press any key". Also I thought I should be able to run the original Amstrad CPC6128 bank manager software supplied on the 6128 system disk. I get a "Load failed" if I try that though.


Is it possible to be DK'tronics compatible but not fully supporting something in the way the 6128 handles its internal 64K expansion ? (And of course I have a Zaxon DDI-3 as my disk drive rather than a DDI-1 - is there any known issue with that in a 'fake' 6128?)


R

Online rpalmer

  • 464 Plus
  • *****
  • Posts: 472
  • Country: au
  • Liked: 313
Re: Open Source, DIY 512KB RAM Expansion
« Reply #30 on: 15:28, 20 May 18 »
The reason hardware attached to a 464 fails to replicate the 6128 is that for configuration 3 address range &4000 to &7fff is mapped to &C000 to &FFFF (and referenced the default memory), but the original &C000 to &FFFF is mapped to an external memory bank. This is possible only on a 6128 since the internal PAL wont get confused by the re-mapping since there is no address feedback, whereas an external expansion will need to handle address feedback and can get quite difficult to get right (from a timing perspective).

Address feedback is when the original mapping tried to change the internal address to become &Cxxx which it then sees (on feedback) and thinks it is for mapping a external memory segment. The outcome from this is that the default memory from &C000 to &FFFF is no longer visible and causes programs to go awry. It can be overcome with a CPLD/FPGA with some very tricky programming, but again it can be quite arduous to get right.

My 4Mb memory expansion cannot handle this (address feedback) on a 464, but on a 6128 it is not an issue as the internal PAL works in unison with the external expansion.

rpalmer

Offline revaldinho

  • CPC464
  • **
  • Posts: 26
  • Country: gb
  • Liked: 30
Re: Open Source, DIY 512KB RAM Expansion
« Reply #31 on: 15:53, 20 May 18 »
Aha ! OK, I didn't know that. I've been working only from the DK'T Technical Manual. That's definitely not going to happen with a handful of 74 series ICs.


So, that's all good then. In that case the board seems to be fully DK'T compatible which was the original goal, and that's what the final 'old school' version will be.


I'll get on with the layout fix and get the new boards started.


R.

Offline IanS

  • CPC6128
  • ****
  • Posts: 191
  • Country: gb
    • index.php?action=treasury
  • Liked: 47
Re: Open Source, DIY 512KB RAM Expansion
« Reply #32 on: 20:37, 20 May 18 »
Aha ! OK, I didn't know that. I've been working only from the DK'T Technical Manual. That's definitely not going to happen with a handful of 74 series ICs.


So, that's all good then. In that case the board seems to be fully DK'T compatible which was the original goal, and that's what the final 'old school' version will be.
The dktronics memory boards do nasty things with mreq to support more of the memory maps. See this thread for more details - http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/464-and-ram-extension/

Offline Duke

  • Supporter
  • 6128 Plus
  • *
  • Posts: 849
  • Country: dk
    • spinpoint.org
  • Liked: 789
Re: Open Source, DIY 512KB RAM Expansion
« Reply #33 on: 23:40, 21 May 18 »
The dktronics memory boards do nasty things with mreq to support more of the memory maps. See this thread for more details - http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/464-and-ram-extension/
Actually it is the only method to do an external RAM expansion on a 464(*1), afaik (thanks to Gerald). The write-through to main memory cannot be avoided unless MREQ is forced high during the write cycle (RAMDIS has no effect on write).
Simple test, that should reveal the issue:
poke &4000,&55
out &7f00,&c4
poke &4000,&AA
out &7f00,&c0
print peek(&4000)

Offline revaldinho

  • CPC464
  • **
  • Posts: 26
  • Country: gb
  • Liked: 30
Re: Open Source, DIY 512KB RAM Expansion
« Reply #34 on: 00:22, 22 May 18 »
IanS and rpalmer - thanks very much for those pointers. That thread in particular was very, very helpful.I should correct my statement then to say that the newly corrected board layout I have would be fully DK'Tronics compatible on the 6128 and later Plus machines ... but wouldn't work in all modes on a '464. Well, that's ok for 6128 owners but I would like to do a bit better than that for the old '464, especially since it's the only machine I own now, and the one I had originally all those years ago.


So, a bit of a think and some playing with my original CPLD-based prototype tonight and I have a partial solution: 7/8ths of a solution to be precise.


Duke suggests this test



Actually it is the only method to do an external RAM expansion on a 464(*1), afaik (thanks to Gerald). The write-through to main memory cannot be avoided unless MREQ is forced high during the write cycle (RAMDIS has no effect on write).
Simple test, that should reveal the issue:
poke &4000,&55
out &7f00,&c4
poke &4000,&AA
out &7f00,&c0
print peek(&4000)

That make sense, but with a bit of lateral thinking there is a solution for that which doesn't involve overdriving any signals !



If I map one of the external 64K banks so that it is always addressed in parallel with the internal RAM it means that I can basically just keep RAMDIS asserted forever. So all writes to 'internal' memory go to both the internal RAM (don't care, except for the video portion) and the external 'shadow' memory. All reads come only from the shadow memory. We never read internal memory again.


Now, in C4-7 mode, when one of the other external banks is selected we can correctly write protect the shadow memory, so running Duke's test above returns the right answer. Yes the internal machine memory is corrupted, but we don't care. The external shadow bank always replaces that for reads so it doesn't matter.


So with this change what I have working at the moment is a '464 mode where the board appears to provide 392K additional RAM which can either be all RAM expansion or, using the DK'T software, a 128K RAM expansion + 256K silicon disk in AMSDOS. OK, we've given up some RAM but all things considered this looks like a good trade off for a '464. (And also on my first pass I've actually given up 128K but I think I should be able to get it working so that I can claw 64K of that back .. but not tonight...)


C3 is more tricky but even so I have fudged a C3 mode so that the 16K block at &4000 gets mapped to &C000 in the new shadow memory. I can't write protect the internal (video) memory at the directly accessed &C000 block but this works well enough that I can now boot into CPM Plus on my 464 either with the '464 ROM present or the 6128 ROM - in both cases needing to use the DK'T |EMULATE command. There is some screen corruption at different times, which doesn't crash the machine of course, but CPM runs and I could load and run BBC BASIC for example.  As Duke and others in the referenced thread have pointed out, you can't write protect the internal RAM without some of that scary looking overdriving of MREQ* or some other signal on the bus. The screen corruption may make this mode unusable. I need to check a bit more.




So, some possibilities here then. I've arranged to borrow a 6128 so I can just double check the compatibility there for myself before making more boards of any kind. Maybe I'll end up with a simple 'old school' DIY board only for 6128 and Plus machines. However, if I can improve on and simplify the '464 mode logic I have now and remap the whole thing to something like 10-11 74 series gates I feel that would be a much better thing, even if I might not quite get the C3 mode working perfectly on a '464. Well, I think so but if most people are really 6128/Plus owners then maybe I should just release the simpler (and now corrected) original board anyway. So any prospective DIYers, please let me know if the effort/delay to do the  '464 mode (and extra chips) are worth it to you or whether you'd be quite happy with a 6128/Plus only board.



And as for the MREQ* overdriving, well I guess I have to have a go at that for myself at some point. I'm not sure it'll make it (as a link option?) on the DIY board,  but I might bodge it in on my CPLD version. Perhaps after I've laid in a stock of replacement Z80s...  :D

R
« Last Edit: 00:25, 22 May 18 by revaldinho »

Offline revaldinho

  • CPC464
  • **
  • Posts: 26
  • Country: gb
  • Liked: 30
Re: Open Source, DIY 512KB RAM Expansion
« Reply #35 on: 17:03, 28 May 18 »



Right, another not-so-short update here.


I have borrowed a CPC6128 to do a bit more testing with my CPLD based prototype and patched 74 series cards. This has been
a bit of an adventure as the '6128 was less than fully working to start with so it has been a bit of fun to sort it out first.


All up and running now though, so I'll try and summarise what I think the current situation is on my attempt to make a
universal card in this table:


Code: [Select]
        C0     C1    C2    C3    C4    C5    C6    C7
CPC464  PASS   PASS  PASS  FAIL  PASS  PASS  PASS  PASS
CPC6128 PASS   PASS  PASS  PASS  PASS  PASS  PASS  PASS


Looking at the CPC6128 first, I have made one small change to prefer using the first bank of onboard extension RAM to the external memory and
have tested C3 working properly using CPM+ with TurboPascal/BBC BASIC etc. That change is easily accommodated with the other layout corrections on
the 'old school' 74 series boards. All other modes seemed to be working fine anyway as expected. So, that's looking good. I will get back to
fixing the layout this week and then are just the Seeedstudio fab/delivery time away from a spin which I can start to distribute.


I didn't want to give up on the '464 though. I still like the '464. Mine has a nicer keyboard than the 6128 I've borrowed and
I have noticed it's a lot less fussy about the length of ribbon cable dangling out of the expansion port too! And anyway, getting the
RAM card working without any dodgy electrical overdriving of MREQ and ADR pins on the '464 seemed to be a bit of a challenge which
I couldn't resist.


In the table above you can see that the '464 is working now in almost all of the modes.


The key to this is the 'shadow RAM' scheme where the whole of the CPC internal RAM is effectively replaced with one bank from the
expansion. When the shadow RAM is written, the internal RAM is written in parallel, so they almost always have the same values. When
the internal RAM would normally be read, reads are taken from the external shadow RAM instead.


With this scheme, modes C4-7 worked immediately because there is no more apparent corruption of the internal memory when using banked
memory. Yes, the internal memory is still getting corrupted because the CPC hardware doesn't protect it when using external RAM. It doesn't
matter though because the shadow memory is protected and all reads come from the shadow bank. This passes Duke's simple test above, and
I have a much more comprehensive RAM test in BASIC and BCPL I'm using to test all banks and base memory in this mode. More importantly
the shadow scheme allows use of the DK'T silicon disk software and DK'T bank switching software and runs various of the DK'T demos.


Mode C3 is listed as 'FAIL' in the table above, but in fact it's partially working and is able to boot the '464 into CPM+ using the disk
images taken from here


http://www.cpcwiki.eu/index.php/DkTronics_CPM


In the 464 mode C3 the odd mapping of 'internal' &4000 to 'internal' &C0000 to handled in the shadow bank. However, data still goes to the
internal video memory at address &C000 as usual. So,  as you can see in the screenshots the outcome
is that CPM+ runs (and with lots of memory in BBC BASIC where HIMEM=60K), but there is a fair bit of 'snow' on screen. This is not great
but actually it's not as bad as I thought it would be; the snow does get cleared up periodically so typing and running the sphere demo
in BBC BASIC was easy enough for example.


As an aside, I am wondering whether a small motherboard hack might fix this completely - intercept the gate array we* signal to
internal RAM and replace it with we* OR RAMDIS. I looked in the service manual and the track is very easy to find near the gate
array signal and then all the DRAM WE* pins are nicely connected in one long chain. So the track cut and resoldering points
look to be very accessible. Something to look at later maybe, unless someone already know the fatal flaw with this idea.


Back to the current implementation: the 464 'shadow mode' doesn't work with the 6128, so it has to be an link or switch selectable option.


For the 464 mode to work we need to give up one bank of 64K RAM for use as the shadow memory. The DK'Tronics software is a bit fussy
as to which bank you use for this as it stops checking for RAM as soon as it finds one bank aliassed to another (ie missing). In other
words if you select bank 000 as the shadow then the DK'T software gives up and reports no memory extension present at all. On the other
hand if you select bank 111 as the shadow then the bank manager software can correctly find 448K available, but the Silicon Disk software
fails to notice a bank missing and thinks that it still has access to a 256K disk (banks 100-111). That's not going to end well.


So, for 464 mode the choices are


- bank3 as shadow which provides 192K DKT RAM expansion + 256K silicon disk
- bank7 as shadow which provides 448K DKT RAM expansion, no silicon disk


Possibly the second of those options could be revived to be a 256K RAM expansion + 192K silicon disk with a hack to the DKT silicon disk
software. That would seem to be the best mode given that a standard 3inch disk is only 180K anyway, so the 192K is more than enough to help
out with disk copying etc. Another thing to put on the to-do list, but that would be software only. Later. Or maybe, later still.


Right, so all this has been done with changes in my CPLD based prototype where a few lines of code can generate rather inconveniently large
numbers of logic gates when it comes to the old school style. Fixing the layout (actually layout library) issues of the first 'old school' boards
is something I've already done. I want to add the tweak for the 6128 internal extension in too, but that will be fairly easy and I'm sure I can get
another IC on the board without too much trouble if that's what it takes. I am planning to remove the external power connector by the way, because I have
already measured power on the v2.00 boards, and don't really need to do that again. Once I've done this I'll get one batch of 6128-only boards done.
I'll update the thread when those are back and tested and, assuming no new issues  will make them available for some low flat fee which is mainly to cover
postage and packing.


The 'universal' 464/664/6128 board though needs a bit more time. I want to do one of these too with 464/664 and 6128 modes and the switchable shadow bank selection.
I think it can be done in a dozen 74 series devices. I might struggle to fit that many into the 80x100mm limit, but I want to have a go at it anyway.
So, if you have a '464/664 DIY board and are interested in a 448K memory expansion with the limitations described above, then this would be the one to wait for.


R


Screenshots:


IMGP8204 - CPC464 with RAM card running BBC BASIC demo under CPM+, HIMEM = 60928, light dusting of snow
IMGP8205 - CPC464 with RAM card running ED80 under CPM+, free space =53754, no snow !
IMGP8206 - CPC464 with RAM card booting into CPM+, fair amount of snow

« Last Edit: 17:10, 28 May 18 by revaldinho »

Offline Duke

  • Supporter
  • 6128 Plus
  • *
  • Posts: 849
  • Country: dk
    • spinpoint.org
  • Liked: 789
Re: Open Source, DIY 512KB RAM Expansion
« Reply #36 on: 18:22, 28 May 18 »
128KB games (probably not many) and demos that use &4000 for screen RAM, would suffer from the shadow ram method aswell, even if just using C4-C7 banking and doing writes to those.

Offline revaldinho

  • CPC464
  • **
  • Posts: 26
  • Country: gb
  • Liked: 30
Re: Open Source, DIY 512KB RAM Expansion
« Reply #37 on: 20:59, 28 May 18 »
128KB games (probably not many) and demos that use &4000 for screen RAM, would suffer from the shadow ram method aswell, even if just using C4-C7 banking and doing writes to those.



Good point.


Any use of internal video memory either at &4000 or &C000 overlaid with external RAM is going to be compromised on the 464, although no problem on the 6128 and presumably the Plus machines.



I accept that the 464 modes can't be perfect without some electrical shenanigans but that's beyond the scope of this mini-project.


Modes C4-7 work fine on the 464 with the screen in the usual place, and that seems enough to have a lot of functionality including the silicon disk working and I think that in itself is worth having in AMSDOS or CP/M 2.2 on a single disk 464 system.


BTW have you got any demos or games in mind I could have a quick peek at ? Would be handy to have a test case I can look at just in case I might get around to looking for a motherboard mod later...


R

Offline Duke

  • Supporter
  • 6128 Plus
  • *
  • Posts: 849
  • Country: dk
    • spinpoint.org
  • Liked: 789
Re: Open Source, DIY 512KB RAM Expansion
« Reply #38 on: 21:14, 28 May 18 »
Yes, probably most things will work.

BTW have you got any demos or games in mind I could have a quick peek at ? Would be handy to have a test case I can look at just in case I might get around to looking for a motherboard mod later...
Not in particular
I would check these Demos tough as they use overscan and 128KB ram (with lotsa tricks):
Still Rising, Onescreen colonies, Batman forever, PHX.
For games:
Xyphoes fantasy, Prehistorik 2.

It's only what comes to mind that could cause corruption of display, if they write to the extended banks, they might not.

Offline revaldinho

  • CPC464
  • **
  • Posts: 26
  • Country: gb
  • Liked: 30
Re: Open Source, DIY 512KB RAM Expansion
« Reply #39 on: 21:17, 10 June 18 »
I sent off the corrected 6128/plus PCB design to Seeed a week or so ago. Just waiting now for those to come back. I haven't found any incompatibilities using my borrowed 6128 and the logic for that card implemented in the CPLD-based prototype, so hopefully this will be the final cut.



I'm still tinkering with a 464 version using the shadow memory scheme implemented on one of my CPLD protos and have now done some testing on various 128K only games and demos.


Unfortunately I couldn't run the Batman Forever demo because I seem to have the wrong type of 6845 on my particular CPC464  - "CRTC Type 2 is not supported" - rather than any memory issues.


On the games I tried so far
  • Both ChaseHQ and Robocop run perfectly and digitised speech is present
  • Gryzor runs with music
  • HardDrivin' detects the expanded memory ("Loading 128K Version") and runs with music playing but some small amounts of snow on screen. Still playable though, at least as far as I got.
  • Double Dragon doesn't run at all - garbage on screen and unresponsive/crashed
I will test some more while waiting for the 6128 cards to return, but looking a bit of a mixed bag so far.


The DK'T bank switching software works fine in BASIC and the Silicon disk is good in AMSDOS and (more importantly) CP/M which is all good and perhaps makes the card worthwhile for some users including me !


As it is though the card can only run CP/M Plus or the TPA-expanded version of CP/M 2.2 with varying amounts of snow and clearly it's going to be a lottery as to which other 128K-only games/demos will run acceptably or even at all.


At the moment I think the 464 card with the shadow memory mode is likely to be about 14 or 15 ICs plus the SRAM. I'm not really sure this one is worth pushing on as an old-school DIY project given that it can't be perfect without some electrical overdriving of signals which would surely make the board more complex again. It can be done more easily in a CPLD (as in my prototype) and that's ok for me, but wasn't really the point of this project.


At some point I might explore a simpler card that would look a lot like the 6128 version but would also use the EXP* pin to signal when the Mode 3 internal mapping should occur. I was thinking that a small motherboard mod might make it possible to do the internal remapping and memory protection as required by intercepting ADR15 to the gate array and the WE* pin from the gate array to DRAM. The idea being that with EXP* asserted then ADR15 to the gate array would be set, and EXP* and RAMDIS would be factored into the DRAM WE* signal. Unless there's an obvious flaw there. this will be on the back burner for a bit while I get some other stuff done and I'll get back to it later.


R