464 and ram extension ....

[gerald]

... how can this work !!!

I wanted to do some test regarding C3 mode with my 464 and my memory 512k RAM extension. This extension works well on my 6128 and 6128+ however, it is not working on the 464.

Working, not working 
Test show that everything written to the extension (in mode C4 to C7) is OK, what is wrong is that the base ram in 0x4000-0x7FFF is written as well.
Using a logic analyser, I can see that the DRAM is written as if no extension were connected, despite the RAMDIS signal being asserted. I also checked that RAMDIS was properly propagated from extension to the main board (pull down resistor and or gate).

From a schematic point of view, RAMDIS only prevent data read from DRAM to drive the Z80 databus. There is no direct connection between RAMDIS and the DRAM or the Gate Array. And only the Gate Array has connection to the DRAM RAS/CAS/WE, so only the Gate Array could inhibit the write.
My CPC having a 40007 GA (with heatsink), I also tested it with a 40010. Result are the same.

I cannot test with  a DKTronic extension as I do not own any.

So my question is : how the write to DRAM is inhibited when an extension RAM is selected ?

[arnoldemu]

I cannot test with  a DKTronic extension as I do not own any.

EDIT: Gerald which country are you in? I am happy to lend you mine if you are in UK or Europe.

[gerald]

EDIT: Gerald which country are you in? I am happy to lend you mine if you are in UK or Europe.

I'm in France.

But before risking any HW accross the channel, can you run the following test on a 464 with a memory extension?
Any red message is a problem 

[IanS]

So my question is : how the write to DRAM is inhibited when an extension RAM is selected ?

I really didn't want to spend time tracing the PCB.

Do you want to know about the other transistor on a dktronics ram board?

It looks like it's pulling MREQ up to +5v.

[gerald]

I really didn't want to spend time tracing the PCB.

Do you want to know about the other transistor on a dktronics ram board?

It looks like it's pulling MREQ up to +5v.

Hey, that's an information !!!! Thanks for your time.
Dirty trick, but that could do it.

So DK may be forcing A15 in C3 mode and MREQ in other access.

I may test that, but hell, I do not like forcing the Z80 bus 

[gerald]

All these hacks on DKtronic ram extension let me think that the 464 (664?) was not really designed to have a RAM extension.

[IanS]

I'll try and do some checks tomorrow. I only have a salae logic, but should tell me enough.

[TFM]

All these hacks on DKtronic ram extension let me think that the 464 (664?) was not really designed to have a RAM extension.

Indeed! Maybe it's time to leave 464/664 behind and move on to the 6128. Probably 99% of all CPC users have a 6128 keyboard today (and maybe some 464/664 in the shed or attic, just there to catch dust).

[Bryce]

I still use my 464 and have 512K (2x 256K) DKTronics RAM expansions connected. But I'm starting to wonder if I should remove them. Pulling a negative output that has no inline resistor is a really bad idea and definitely not something I would recommend. I haven't checked the internal circuitry of the Z80, maybe the outputs have some sort of protection. But even then, that would have been designed for "emergencies" and not for regular use.

Bryce.

[gerald]

I still use my 464 and have 512K (2x 256K) DKTronics RAM expansions connected. But I'm starting to wonder if I should remove them. Pulling a negative output that has no inline resistor is a really bad idea and definitely not something I would recommend. I haven't checked the internal circuitry of the Z80, maybe the outputs have some sort of protection. But even then, that would have been designed for "emergencies" and not for regular use.

Bryce.

The Z80 in CPC is a TTL chip and is likely to have totem-pole output. I do not think there is any protection except the main output transistor current sink capability. 
I did not find any indication on the max current the output can sink except a VOH max of 0.4V with a 1.4mA -> the pad could sink 1.4ma while still having a Vout less than 0.4V.
If you force the output high (at least higher than the minimum for being considered high by other chips), the transistor should sink as much as it gain (Beta) and base current allow it. Output voltage will increase as well a power dissipated in that transistor.

Now, should you not use the expansion anymore ? How many Z80 died from having a DKTronics extension attached? I don't know 
But it seems that even Amstrad did not prevent that trick nor attack DKtronics.

@Bryce, Ians, Kevin : can one of you post  a picture of the extension both side (scanned ?). Wiki picture are really too small for any analysis.

I would like to know if the interface uses any of the following expansion connector signals : CLK (pin 50) and READY/WAITn (pin 39)
READY/WAITn should be enough for the A15/MREQn hack.

[Bryce]

If they really did it that way, then that should be ok for the CPU,  but it's still a dodgy hack, not exactly "Best Practise" When I get a chance I'll put a scope on it and see exactly what it's doing. As I have two of them connected, there are two sets of transistors pulling the signals high in parallel. I need to measure exactly what's happening on those lines.

Bryce.

[gerald]

Dodgy hack, not exactly "Best Practise", agreed !
But allowing to have more RAM on the expansion port while not planned on original design is a clever trick.

I am just wondering the chronology of these expansions.
Did they appear before or after the 6128 ?
The RAMDIS signal seem to indicate that AMSTRAD planned the ram extension, but just forgot to protect the internal DRAM ?
Why no fix has been done on later version of 464 ?

By the way, has anyone a 664 service manual ?

[IanS]

@Bryce, Ians, Kevin : can one of you post  a picture of the extension both side (scanned ?). Wiki picture are really too small for any analysis.

I've put a few quick pics here - http://www.testbox2.co.uk/dktronic64K.zip (~6MB)

Difficult to get good pics with the edge connectors on each side. And much of the interesting bits happens close to the connector.

[Bryce]

I assume Amstrad messed up too. It's highly unlikely that they planned the computer to NOT have RAM expansions.

The 664 service manual is here: Service Manuals - CPCWiki

Would you need to do exactly the same on the 464+? Surely they fixed it there, but I haven't looked (and I don't think any specific 464+ RAM expansions were ever released).

Bryce.

Edit: Oh yeah, regarding pictures: I have a few here of the top at least: Upgrading a Dk'tronics RAM Expansion - CPCWiki
Upgrading a Dk'tronics RAM Expansion - CPCWiki

[gerald]

The 664 service manual is here: Service Manuals - CPCWiki

The 664 file is cursed (464KB  ), and 7zip cannot open it (corrupted ?)

Would you need to do exactly the same on the 464+? Surely they fixed it there, but I haven't looked (and I don't think any specific 464+ RAM expansions were ever released).

I do not think. The DRAM protection is done by the PAL and the PAL is part of the ASIC, and ASIC is the same on all CPC+.
I do not have a 464+ to check, but reading 2nd bank should return garbage (floating bus) while on 464 you get 1st bank data.

 

I've put a few quick pics here - http://www.testbox2.co.uk/dktronic64K.zip (~6MB)

Difficult to get good pics with the edge connectors on each side. And much of the interesting bits happens close to the connector.

Thanks. As you said, the edge connector is a pain !!
Let see what I can get from this.

[Bryce]

Then they did solve it on future CPCs, just not on the Classic. Maybe they were afraid of causing incompatibilities with existing expansions?

I'll upload my pdf of the 664 Service Manual, one minute...

Bryce.

Edit: Ok, it took more than a minute, it's rather large, but it's there now, same wiki page directly under the rar link.

[gerald]

That pdf is better 

[Bryce]

I'm a hoarder of 8-bit schematics If you're looking for any others (also non- Amstrad) then let me know and I can send you them directly.

Bryce.

[arnoldemu]

The 664 file is cursed (464KB  ), and 7zip cannot open it (corrupted ?)
 
I do not think. The DRAM protection is done by the PAL and the PAL is part of the ASIC, and ASIC is the same on all CPC+.
I do not have a 464+ to check, but reading 2nd bank should return garbage (floating bus) while on 464 you get 1st bank data.

 

Thanks. As you said, the edge connector is a pain !!
Let see what I can get from this.

I can check this, but I think on 464+ it doesn't return garbage, it is like the internal PAL is disabled.

[arnoldemu]

Dodgy hack, not exactly "Best Practise", agreed !
But allowing to have more RAM on the expansion port while not planned on original design is a clever trick.

I am just wondering the chronology of these expansions.
Did they appear before or after the 6128 ?
The RAMDIS signal seem to indicate that AMSTRAD planned the ram extension, but just forgot to protect the internal DRAM ?
Why no fix has been done on later version of 464 ?

By the way, has anyone a 664 service manual ?

I'm guessing the costdown 464 is fixed, but the original 464 is not.
I have both of these 464s.
I will try and find time this weekend to re-check and to run your tests on all the cpcs I can.

[gerald]

To check that the cost down is fixed, you would need a  6128 memory extension.
From picture in wiki, 6128 ram extension does not seems to have the 2 transistors that force A15/MREQn.

[gerald]

Quick status

I got the 464 working properly in mode C4-C7 by driving mreqn high during access to memory extension. Base ram is no more corrupted.
Next step is to deal with C3 mode. I hope to have a full 6128 compatible behaviour by preventing the ROM to appear at 0x4000-0x7FFF range when enabled.

464 still alive 

[TFM]

If that kind of expanson would be doable, then a lot of my programs - not only FutureOS - would work for the CPC464 too. Good luck!

[gerald]

Next step is to deal with C3 mode. I hope to have a full 6128 compatible behaviour by preventing the ROM to appear at 0x4000-0x7FFF range when enabled.

Latest news : DKTronics C3 compatible mode is working.

I was expecting to prevent the ROM to be visible in 0x4000-0x7FFF range by asserting the ROMDIS signal. I just forgot that the gate array will not issue a ramrdn to actually read the DRAM (ie enable the DRAM buffer to Z80 bus) because is think it's a ROM access !!!
So there is no way to get the 6128 compatibility mode.

Now on 464 : when C3 mode is selected

Code: [Select]

   with ROM disabled :
r/w in 0x4000-0x7FFF goes to base bank 0xC000-0xFFFF
r/w in 0xC000-0xFFFF goes to extension bank 0xC000-0xFFFF

  with ROM enabled :
w in 0x4000-0x7FFF goes to base bank 0xC000-0xFFFF
w in 0xC000-0xFFFF goes to extension bank 0xC000-0xFFFF
r  in  0x4000-0x7FFF  and 0xC000-0xFFFF return upper rom content

@arnodemu
If you have time,  can you check the 4 lines after the "memory Expansion test" message of my test when run with a dktronic extension on 464 ?
You should get :

Code: [Select]

Memory Expansion test

C0 80 C0
1C E7 80 80
E7 0C E6 E6 E5 E5 E4 E4
14 00 1C 04


[TFM]

Latest news : DKTronics C3 compatible mode is working.

Can you please give FutureOS a run and check if the mouse pointer moves over the screen like expected or if it leaves a track?