News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Open Source, DIY 512KB RAM Expansion

Started by revaldinho, 22:10, 24 April 18

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Sykobee (Briggsy)

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?

revaldinho




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




Duke

Quote from: revaldinho on 21:39, 18 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 :)

gerald

Quote from: revaldinho on 21:39, 18 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).

revaldinho

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

rpalmer

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

revaldinho

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.

IanS

Quote from: revaldinho on 13: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.
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/

Duke

Quote from: IanS on 18:37, 20 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)

revaldinho

#34
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


Quote from: Duke on 21:40, 21 May 18
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

revaldinho

#35



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:



        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


Duke

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.

revaldinho

Quote from: Duke on 16: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.



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

Duke

Yes, probably most things will work.

Quote from: revaldinho on 18:59, 28 May 18
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.

revaldinho

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










revaldinho


A bit belatedly, I have another update on this project.


In fact I got the boards back a couple of weeks ago, but have been a bit distracted with other things in the meantime and have been a bit slow to update the thread.  Also I didn't want to post 'til I'd had a chance to update some of the documentation.


Still I'm here now and the news is that the revised boards are back and working.


I have built up two of the boards, one using all HCT parts and the other using a mix of predominantly (faster) AHCT with a couple of HCT ICs to fill in the gaps. There's no noticeable difference in performance of either even when varying the power to the card all the way down to around 3.5V. I haven't built one up with LS chips, but those should work too.


Now I'm sure that my testing can't be completely comprehensive, but so far I have successfully run at least the following software:

       
  • Amstrad CPC6128 bank manager
  • DK'Tronics Bank manager
  • DK'Tronics Sillicon Disk (in AMSDOS and CP/M)
  • CP/M+, CP/M 2.2
  • Batman Forever Demo
  • 128K games including Gryzor, Hard Drivin', ChaseHQ and Robocop
  • Some RAM test programs written in BASIC and BCPL
(The 128 games all use the first bank of the 512K expansion rather than the internal 64K expansion).


I had to order a 'protopack' of 10 boards from Seeed so I have 8 left over and I think that there were 8 or 9 people who originally expressed an interest in building the cards themselves. So, if anyone from that cohort still wants a bare board, then please PM me with your postal details. You can consider yourselves Beta testers and I'll foot the bill for postage. If there are any left over then I'll charge a flat rate (incl postage to anywhere) of 5UKP per board and can easily arrange for a second batch if needs be.


Now, this is a totally open project so as well as the source being available on GitHub, you can order boards or download the gerbers directly from Seeed using the SeeedFusion Gallery project page.


Of course having the boards is one thing, but you will need to know what to put in them so I have updated the documentation for the project using the GitHub wiki . More details on the project area there, including a full bill of materials (approximate cost 14UKP + postage if buying from Digi-key in the UK). Please do have a look at the Wiki and contact me either here or via the GitHub interface if you have questions or improvements to make to the documentation/instructions.


Just to be clear again, this is a 512KByte DK'Tronics compatible expansion for the CPC6128 and Plus machines only and the board has an MX4 connector, so you will need any one of the multitude of compatible expansion boards to plug it into. Seems that everyone has done one, so pick your favourite but if you really want to build another card yourself then I also have a simple 3 slot offering which you can find via my GitHub or Seeed pages.


R


Bryce

Going from LS to AHCT/HCT parts won't improve performance. The speed of your device depends completely on the Z80's timing, nothing else. Even if the chips answer quicker, the CPU still waits the entire "timing window", it doesn't jump to the next step any quicker.


Bryce.

revaldinho

Well, yes. And I did know that of course. :D  My point was only to say that there doesn't seem to be any timing marginality in the 74 series logic which might show up as one logic family working down to lower supply voltages than others.

R





Bryce

No, not really, they all tend to start dropping out from around 4.75V, anything above that and they will all perform identically.

Bryce.

kawickboy

As far i know double dragon 1&2 floppy releases (Richard Aplin) aren't exactly the same. Double Dragon runs with a 128ko cpc (including 464 or 664+64ko) but Double Dragon seems to really need a true 6128. I evend bought a duchet computer FO.DOS (adding the 6128 rom) and the game ran, but wasn't stable.


What about testing games like xyphoes fantasy, prehistorik 2, orion prime, targhan or zapt'balls AE ?

revaldinho

Quote from: kawickboy on 08:53, 10 July 18
As far i know double dragon 1&2 floppy releases (Richard Aplin) aren't exactly the same. Double Dragon runs with a 128ko cpc (including 464 or 664+64ko) but Double Dragon seems to really need a true 6128. I evend bought a duchet computer FO.DOS (adding the 6128 rom) and the game ran, but wasn't stable.


What about testing games like xyphoes fantasy, prehistorik 2, orion prime, targhan or zapt'balls AE ?


I've just tried Zapt'balls and Prehistorik 2 and happy to say 128K versions of both run very well on the '464. There is a very small amount of screen corruption during gameplay but hardly anything and the games are both fully playable. I've attached a screenshot of Prehistorik 2 for you to see what I mean.

Just to be clear though, this is using the shadow RAM mode on the CPLD based prototype card. The 6128-only card which is the main event here has no such problems.

I still have a couple of the 6128 bare boards left for anyone else wanting to build their own 'old school' cards by the way.

On a 464 version, I'm not quite sure whether to do anything more with that or not. The shadow mode works perfectly in modes C4-7, and imperfectly but pretty well in the other modes really. That's certainly good enough for what I want to run on it. Even so, I am thinking of respinning the prototype to let me try some experiments backdriving the MREQ* and ADR15 signals but that's probably just for my own amusement. I don't expect this to result in another DIY 74 series based card, and there are already other pre-built '464 compatible cards around such as ToTO's X-MEM and Y-MEM.

R.




GUNHED

You can use the 'OS-Infos' Tool for FutureOS to check if RAM is properly detected too.  :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

revaldinho

Quote from: GUNHED on 15:30, 12 July 18
You can use the 'OS-Infos' Tool for FutureOS to check if RAM is properly detected too.  :)


You mean this one ? (attached)


This is the output from the 74 series card running on a 6128 - all banks and blocks present and correct.


I posted out a few of the bare PCBs last week, so hopefully will hear from other successful builders soon. I still have a few PCBs for this card available so open season on those now - first few to ask for them can have them (PM me with your address) and remember this round is free. And I do mean free as beer not just as in speech. Once the first ones are gone, help yourself to the boards from Seeed or the gerbers from GitHub.


Meanwhile back on the '464 I tried my other CPLD proto card using FutureOS too. It boots fine and shows the desktop, you can enter hot-key commands and run the monitor, for example, and all looks great - no snow on screen like with the games in the last screenshot I showed. There's just one problem. You can't see the cursor. It's a little thing, but I can't help thinking that not being able to see the cursor in a GUI is a fail.  ;D




GUNHED

First of all Congratulations to create your own hardware.  :)  Well, if the mouse-pointer / arrow can not be seen in FutureOS then this is a indicator that RAM banking &C3 doesn't work properly. When you OUT &7FC3,&C3 then the RAM block from &C000 to &FFFF will be banked in at address &4000 (this works on 6128, but not on 464 or 664). Due to the differences some RAM expansions have a 464 mode and a 6128 mode, like the X-MEM from Tot0. Since I'm not an hardware expert I'm sure somebody can explain this better.
However, great to see the advances and it seems to run stable. That's great!  :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

revaldinho

Quote from: GUNHED on 15:28, 14 July 18
Well, if the mouse-pointer / arrow can not be seen in FutureOS then this is a indicator that RAM banking &C3 doesn't work properly.


Thanks. I assumed that would be the problem. The 6128 card is super stable and appears to work well in all modes running down to a very low voltage. The 464 version on the other hand supports only mode C4-7 completely at the moment and operation in other modes is a bit variable as discussed earlier in the thread. At some point I'll hack the 464 card to try backdriving the A15 signal which seems to be the only solution for mode C3 short of taking a craft knife to the motherboard (but that remains an option too - after all, does anyone really use the LPEN input these days ?   ;D )


R.

Powered by SMFPacks Menu Editor Mod