avatar_PulkoMandy

How do RAM expansions prevent writes to internal RAM on the 446/664?

Started by PulkoMandy, 12:48, 14 October 21

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

PulkoMandy

A question for you all electronics electronics hacker out there.


I'm looking at the schematics of the CPC and as far as I can see, the RAMDIS signal only disable reads from the main memory on the 464 and 664. On the 6128 on the Plus this was changed as the signal from the expansion port goes through the memory management PAL.


However, I know there are several memory expansions that work just fine on these machines. Do they do anything special to prevent writes to the internal RAM when external RAM is mapped? How does this work? Is the 464/664 schematics incorrect, or do they use some other trick to disable RAM access?


I have found mentions of this oddity various times in the forum, but never found a conclusive answer. Some people said it would be the Gate Array handling it, but I checked the reverse engineering of the Gate Array from pictures of the die, and I did not see anything related to the MMR there. Also this wouldn't work for the Multiface, for example, since it maps its memory using a different register.

gerald

Quote from: PulkoMandy on 12:48, 14 October 21A question for you all electronics electronics hacker out there.

I'm looking at the schematics of the CPC and as far as I can see, the RAMDIS signal only disable reads from the main memory on the 464 and 664. On the 6128 on the Plus this was changed as the signal from the expansion port goes through the memory management PAL.

However, I know there are several memory expansions that work just fine on these machines. Do they do anything special to prevent writes to the internal RAM when external RAM is mapped? How does this work?
Most 464 ram extension (DK tronic's one, XMEM) works by forcing MREQ on write request. This make the gate array ignore the write at all.
The C3 mode 'support' is done by forcing A15 high during extension ram access.

PulkoMandy

I see the Multiface II also has a transistor driving MREQ, so I guess it does the same. Thanks for clarifying!

rpalmer

The 464/664 does not have the MMU PAL as seen in the 6128 as there is no memory expansion to deal with. The only controls on a 464/664 is with the 74LS153 address selection chips between the 6845 and Z80.

The external memory expansion which implement the DK'Tronics standard use the RAMDIS to disable the internal memory so that accesses is correct on the 464/664.

As for "C3" mode (correctly is defined as mode '3') as mentioned by others, is handled by completely disabling the internal memory so that all accesses go the external unit meaning the external memory looses 64K of its total expansion memory.

zhulien

There is also the RAMROM which is a bit of an oddity, it is RAM in that it allows you to program it, but when in normal mode you lock it with a switch and all writes go to RAM even when ROM is enabled. Reads come from ROM if ROM is enabled otherwise RAM as per a normal ROMboard.

PulkoMandy

Quote
The 464/664 does not have the MMU PAL as seen in the 6128 as there is no memory expansion to deal with. The only controls on a 464/664 is with the 74LS153 address selection chips between the 6845 and Z80.

The external memory expansion which implement the DK'Tronics standard use the RAMDIS to disable the internal memory so that accesses is correct on the 464/664.

On the 464 and 664, the RAMDIS only disables reads from the internal memory. It is not possible to use it to disable writes. That was the point of my question. I got my answer, in addition to RAMDIS, 464 and 664 compatible extensions lock memory writes by forcing the MREQ signal. With just RAMDIS, it would not work. If you use only RAMDIS, the access will NOT be correct on the 464/664. Writes will affect both the internal RAM and the expansion.

Quote
There is also the RAMROM which is a bit of an oddity, it is RAM in that it allows you to program it, but when in normal mode you lock it with a switch and all writes go to RAM even when ROM is enabled.

I know about it very well since before designing and starting to sell the FlashGordon, I have built a few batches of Ramcard (designed by Ram7) and eventually reverse engineered how it works and published an article about it. However, it is not mapped as a standard memory expansion, and it does NOT block writes to the RAM even when its write switch is enabled. It does not use RAMDIS at all, that is not needed because the Gate Array will already disable RAM reads when a ROM is mapped, even if it is an external ROM.

GUNHED

Quote from: rpalmer on 21:45, 14 October 21
As for "C3" mode (correctly is defined as mode '3') ...
Better call it &C3 mode, because &D3 / &E3 / &F3 are _not_ the same.
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)

TotO

Quote from: rpalmer on 21:45, 14 October 21As for "C3" mode (correctly is defined as mode '3') as mentioned by others, is handled by completely disabling the internal memory so that all accesses go the external unit meaning the external memory looses 64K of its total expansion memory.
I'mcurious to know where it is correctly defined as mode "3" ?
The 64K of the RAM expansion are only lost on the Revaldinho's memory expansion (shadow memory). It is a choice to be able to use this mode while the ROM is mapped. The only known usage is the FutureOS pointer at #C000. A work around to properly run on any RAM expansion for 464/664 will be to handle RMR bit3 into the software.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

zhulien

Is mode 3 the reason CPM+ (unpatched) locks up on a 464 and 664 with additional RAM?

TotO

Quote from: zhulien on 18:49, 15 October 21
Is mode 3 the reason CPM+ (unpatched) locks up on a 464 and 664 with additional RAM?
Yes, CP/M Plus check C3 ... (but it doesn't use it)
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

revaldinho

Quote from: TotO on 17:56, 15 October 21
The 64K of the RAM expansion are only lost on the Revaldinho's memory expansion (shadow memory). It is a choice to be able to use this mode while the ROM is mapped.


Yes, this is correct. On the Revaldinho boards a DIP switch selects between Dk'tronics mode and the Shadow mode. In DK'Tronics (normal) mode you get the full 512K RAM like all other expansions. In shadow mode you get accurate &C3 video operation and the ability to run FutureOS or unpatched CP/M+ on a 464/664. The price for this is that you lose 64K of RAM for the shadow bank making it effectively a 448KB expansion.


If having that full 512K expansion in shadow mode is important, then I do have an alternative 1MByte card. The full 1MByte expansion isn't so useful for existing software, although again FutureOS is one system that can make use of it, but in this case you always have at least 960KB available.
[size=78%] [/size]




rpalmer

Toto,
Mode 3 is based on the I/O data issued to the. Gate Array.
The format of the data is:
11aaabbb where aaa is the 64K segment to act upon and bbb is the actual mode which is requested (0 to 7).
This means mode &c3 (11000011) acts in the same as &D3 (11010011).

Mode 3 acts in rather unusual way. It directs memory access from &4000-&7fff to &c000-&ffff into the banked 64K segment, while accesses to &c000-&ffff remain accessing the main memory.
Another reason why the shadow memory is used is that you dont want to electrically overload the A15 line from 0V to 5V to force the memory access to the right location. This is a bad idea if anyone were to do it.
rpalmer

TotO


Sorry, but my question was more related to the remark "correctly is set as mode 3" than how the memory mapping works.
Yes, it is more correct to speak of mode 0, 1, 2, 3 since a RAM extension can be greater than 64K.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

GUNHED

Quote from: rpalmer on 22:00, 17 October 21
This means mode &c3 (11000011) acts in the same as &D3 (11010011).
No, in case of &C3 and &D3 the upper 16 KB RAM bank (&C000-&FFFF) is coming from a different 64 KB block.
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)

Powered by SMFPacks Menu Editor Mod