CPCplus internal RAM / ROM Expansion

[SainT]

I've been thinking about hardware mods I can make for the CPCplus, just for my own amusement really (although I would make small quantities available for sale if anyone is interested in them).


One thing I like the look of is the MegaFlash. But I thought I could combine a 512K RAM and 512K FLASH board and make an internal upgrade for the plus range. As the Z80 is socketed, the board would plug into the Z80 socket and the Z80 would then plug into the board (this gives me most signals I need). You'd also need to solder a few wires to the expansion connector (ROMEN, ROMDIS, RAMDIS?) and connect to the board via a header.


The board would then contain a small PLD handling memory mapping. The FLASH would map to the normal 512K Dk'tronics DFxx port (and possibly 78XX also), then the RAM would use 79XX.

[Bryce]

Go for it. If you need any further info / files on the MegaFlash then let me know.

Bryce.

[TFM]

Well, if you make a board to replace the CPU, then - especially today - you should use 4 MB of RAM and 2 MB of Flash (makes it rather cheaper than more expensive). 

[SainT]

Well, if you make a board to replace the CPU, then - especially today - you should use 4 MB of RAM and 2 MB of Flash (makes it rather cheaper than more expensive). 

Not sure where you get your RAM from, but for me 512KB is still a lot cheaper than 4MB... 


I don't know if you can use more than 4MB address space on the CPC without creating some new bank switching method, though?

[TFM]

Take my RAM for free from old PC RAM banks...


4 MB is just fine, not more than 4 MB. RAM7 and Jarek use the same technique for it (4 MB equals 8 blocks of 512 KB, each compatible to the regular 512 KB expansions, but addressed using &7Fxx, &7Exx and so on). Also there is some software for 4 MB RAM already.

[SainT]

Ok, just to clarify how this works for myself, after a bit more reading....


ROM


For a Dk'tronics style mapping, I monitor the Z80 A0-A7 / IORQ / WR for a write to port DFxx. I keep the value written to the port to give me 5 bits for the high address lines. When ROMEN is asserted low I set ROMDIS high for any ROM which is enabled and eanble the ROM. ROMs which should be possible to deactivate are at least 0 and 7.


RAM


For a Dk'tronics style mapping, I monitor for a write to 7FXX, and as above latch the bank number. When RAMEN is asserted low I set RAMDIS (override any internal RAM) and enable the RAM.




I dont need to monitor reads from either port.


This covers both 512K of RAM and ROM.

[Bryce]

More or less correct. However, to detect &DFxx you'll have to monitor some address bits above A7.

Bryce.

[ralferoo]

More or less correct. However, to detect &DFxx you'll have to monitor some address bits above A7.

Indeed. The official way of detecting &DFxx is when A13=0. There's no requirement to check any other bits.

Likewise, &7Fxx is when A15=0. Again, no need to check any other bits.

[SainT]

Indeed. The official way of detecting &DFxx is when A13=0. There's no requirement to check any other bits.

Likewise, &7Fxx is when A15=0. Again, no need to check any other bits.

Ah, thanks very much. That makes things a bit easier.


Forgive my ignorance of the Z80, but how does this happen? I know A0-A7 are the port number for a port read / write operation, but I'm not sure how A15-A8 are set...?

[Bryce]

Indeed. The official way of detecting &DFxx is when A13=0. There's no requirement to check any other bits.

Likewise, &7Fxx is when A15=0. Again, no need to check any other bits.

It's prudent to test at least one other of the higher address bits being = 1 to ensure the address bus contains a valid address. If you are integrating both onto one PCB then it's just a matter of testing A15=1 AND A13=0 for ROM selection and A15=0 AND A13=0 for RAM bank selection.

Bryce. 

[ralferoo]

Forgive my ignorance of the Z80, but how does this happen? I know A0-A7 are the port number for a port read / write operation, but I'm not sure how A15-A8 are set...?

Amstrad ignored the "official" advice from Zilog of how IO should work (which was an extension of the 8080 scheme) and instead used a little-known (but documented) scheme instead.

For the 8080, an IO instruction used only A0-A7 and was of the form IN A,(#xx) or OUT (#xx),A (using Z80 mnemonics).

For the Z80, this was expanded, so the forms above additionally put the A register on A8-A15 and the additional IN r,(C) and OUT (C),r instructions actually put the entire BC register on A0-A15, although the mnemonic implies just C (which is A0-A7, like the older instructions).

By choosing to start at the high bits of the address bus, Amstrad forced people to set the BC register to perform any IO. This is actually a real shame as it means you can't use the new useful instructions like OTIR etc as they expect B to be used as a count register.

Like most 80s computers with only a few chips to select, the logic low selection was chosen so that the address lines could be used directly as chip select pins. So, A15=0 is used to select the gate array, A14=0 is used to select the CRTC, A13=0 for ROM banking, A11=0 for PPI, etc. The side effect of this is that the lower 8-bits are generally unimportant and so it doesn't usually matter what C is set to when doing an IO.

If you compare to the Spectrum where the IO ports are used as intended, you'll see IN A,(#FE) where A0 is used to enable the device.

One curious thing is that you can do some things without using BC at all, e.g. reading a bit from tape:

Code Select Expand


LD A,#F5
IN A,(0)
RLA


It's prudent to test at least one other of the higher address bits being = 1 to ensure the address bus contains a valid address.

Well, usually you should check that IORQ=0 and the appropriate bit. It doesn't harm to check more, but it's not officially required and the CPC itself doesn't. It's only actually a problem during an in when more than one device might try to drive the data bus.

A15=0 AND A13=0 for RAM bank selection.

Should be A15=1 AND A13=0 for RAM bank selection.

[SainT]

Thanks ralferoo, very good explanation. Makes sense from hardware simplicity perspective to use the high bits as chipselects.

[Bryce]

Should be A15=1 AND A13=0 for RAM bank selection.

Oops, yeah, I should read what I've typed before I hit the post button

I can't remember exactly where I encountered the issue, but I know I found a situation that caused the CPC to reset if I only tested for A15=0 on the MegaROM and MegaFlash, despite testing IORQ.

Bryce.

[arnoldemu]

Gate Array is A15=0, A14=1.
It's the PAL that is A15=0

[ralferoo]

Gate Array is A15=0, A14=1.

I thought this was pretty unlikely as it was contrary to what I thought I knew about the CPC. However, I just made some tests and sure enough on my 464, writes to #3fxx are only recognised by the CRTC and not the GA. I'd previously just thought the GA used A14 as part of the ROM bank test, but obviously I was wrong!

[TFM]

One must (to do it properly) test at least the four upper bits, else there is a chance that two I/O chips get active. Some demos / games even USE this feature when they need to write the same value to two I/O targets.


I could make a bet now that our self made hardware gods now pour liquid tar on me... Haha, but I know what I know.

[Bryce]

One must (to do it properly) test at least the four upper bits, else there is a chance that two I/O chips get active. Some demos / games even USE this feature when they need to write the same value to two I/O targets.

Then it's the demos are going against the Amstrad standards. Most hardware expansions test only 2 of the upper address bits. You don't make hardware more complicated and expensive just to satisfy the needs of one demo that bends the rules.

How would that work anyway? Enabling two devices in parallel is no guarantee that the data will get written to both of them.

Bryce.

[arnoldemu]

I thought this was pretty unlikely as it was contrary to what I thought I knew about the CPC. However, I just made some tests and sure enough on my 464, writes to #3fxx are only recognised by the CRTC and not the GA. I'd previously just thought the GA used A14 as part of the ROM bank test, but obviously I was wrong!

It is something I tested and found a few years back. I think there is one demo where this makes a difference. May be Hi-Tech by Overflow.


I think it's documented, or at least should be.

[arnoldemu]

Then it's the demos are going against the Amstrad standards. Most hardware expansions test only 2 of the upper address bits. You don't make hardware more complicated and expensive just to satisfy the needs of one demo that bends the rules.

How would that work anyway? Enabling two devices in parallel is no guarantee that the data will get written to both of them.

Bryce.

I thought reading was more of a problem.

In terms of writing, it means that two devices would be enabled, both accepting data from the bus.

In terms of reading, it means two devices trying to assert potentially 2 different bytes with unknown results.

or???

[Bryce]

Yes, reading is a bigger issue, but writing can be a problem too. If the device (IC) sending the information can't drive more than one device at a time, then the "stronger" of the two devices will save the information, but a bit may get flipped on the weaker device.

Bryce.

[arnoldemu]

Yes, reading is a bigger issue, but writing can be a problem too. If the device (IC) sending the information can't drive more than one device at a time, then the "stronger" of the two devices will save the information, but a bit may get flipped on the weaker device.

Bryce.

Ahh ok I understand.

[TFM]

Then it's the demos are going against the Amstrad standards. Most hardware expansions test only 2 of the upper address bits. You don't make hardware more complicated and expensive just to satisfy the needs of one demo that bends the rules.

How would that work anyway? Enabling two devices in parallel is no guarantee that the data will get written to both of them.

Bryce.

It's some commercial games too. For example you can write to the GA and the CRTC at once.


Of course this is no proper practice and to use it makes sense very very seldom.


However, if I would construct hardware, then I would try to omit these problems.

[SainT]

Hmm, does the ROMEN / ROMDIS method of ROM selection interfere with the cartridge ROM (I have seen mention it does)? Or is this an entirely different access method, using the ROM line? So you can have 512KB cart, 512KB ROM and 512KB RAM with standard single register paging methods?


Getting it all straight in my head. 

[IanS]

One must (to do it properly) test at least the four upper bits, else there is a chance that two I/O chips get active. Some demos / games even USE this feature when they need to write the same value to two I/O targets.


I could make a bet now that our self made hardware gods now pour liquid tar on me... Haha, but I know what I know.

Why the hidden "I could make a bet now that our self made hardware gods now pour liquid tar on me... Haha, but I know what I know."?

As for needing to test at least four bits, you need to explain why. The DDI-1 and internal 6128 disc interface only check one bit (A13). The printer port only checks one bit (A12). Hardware expansions need to check as many bits as needed to uniquely identify the address. Saying you need to check at least four bits without explanation or justification is unhelpful.

[ralferoo]

Why the hidden "I could make a bet now that our self made hardware gods now pour liquid tar on me... Haha, but I know what I know."?

As for needing to test at least four bits, you need to explain why. The DDI-1 and internal 6128 disc interface only check one bit (A13). The printer port only checks one bit (A12). Hardware expansions need to check as many bits as needed to uniquely identify the address. Saying you need to check at least four bits without explanation or justification is unhelpful.

Particularly as the GA only has A14 and A15 entering the chip, the CRTC has A14 connected to CS, A9 to RW, A8 to RS, the PPI/PIO has A11 connected to CS, A9 to a1, A8 to a0, IORD to RD and IOWR to WR, printer has (IOWR or A12) connected to CLK.

There is absolutely no question about it. The hardware DOES NOT and moreover CANNOT decode any bits other than those.