Support IDE64: Ultimax mode memory mapping

[mrjoso]

Description

In the current C64 Core on MEGA65 (V5.1), Ultimax mode in Expansion port is incomplete and prevents IDE64 cartridge from functioning properly due to memory mapping limitations.

---

Problem details

• It is not possible to map any external RAM/ROM to $1000-$7FFF in Ultimax mode.
• This limitation prevents IDE64 cartridges from working, as they rely on mapping external RAM from $1000 to $7FFF.
• Incorrect behavior: The /ROMH signal is generated for the $A000-$BFFF range, which is incorrect in Ultimax mode. However, this specific behavior does not interfere with IDE64 functionality.
• Correct behavior: The /ROMH signal is generated for the $E000-$FFFF range, which is correct in Ultimax mode.

---

Expected behavior

• The Expansion port should allow external RAM mapping to $1000-$7FFF in Ultimax mode, ensuring IDE64 compatibility.

[sy2002]

Asked a question on discord, see screenshot:

[sy2002]

[sy2002]

@paich64 - this is FYI for you. The potential PLA change we talked about and that will NOT make it into the V5.2 release.

@mrjoso Let's approach this in steps. It has been quite a while, when I did my deep dive into the C64's PLA. Please have a look at this here:

https://github.com/MJoergen/C64MEGA65/blob/master/doc/PLA.md

and then have a look at this line of code, which SEEMS to be the culprit of the behavior you describe:

https://github.com/MJoergen/C64_MiSTerMEGA65/blob/5afb90e02fcefb053ac27792f42e742ad61e8b9b/rtl/fpga64_buslogic.vhd#L365C6-L365C24

You write that the /ROMH signal should never be generated for the $A000-$BFFF. And indeed, when I read the PLA.md (see above) one could interpret that you are right. So I created an experimental test core for you. It just comments-out the "culprit" line of code. It is for R3 machines-only and it is based on the soon-to-be released V5.2.

c64mega65r3v52a2e1.zip

Can you confirm that the attached core V5.2E1 fixes what you called "Incorrect behavior" above, i.e. that it does not generate the /ROMH signal is generated for the $A000-$BFFF range any more?

If so, I will try to investigate the actual root cause for the problem, i.e. the inability to map any external RAM/ROM to $1000-$7FFF in Ultimax mode. Help from you is appreciated. Do you have documentation for me (weblinks) how this mapping is actually performed, or can you show me / explain to me the right PLA mechanisms for example using PLA.md from above and pointing me to it?

[sy2002]

Feedback from @mrjoso on Discord:

I have tested the provided version 5.2.A2E1, and I can confirm that the /ROMH signal is no longer generated for the $A000-$BFFF range in Ultimax mode.

I’m not sure whether I should have paid attention to the following strange behavior in the provided experimental core. In the $A000-$BFFF area, internal RAM is mapped, whereas in Ultimax mode, there should be empty space (no RAM, no ROM if nothing is connected externally there). This behavior was not present in version 5.1.

That’s all for now. I have to stop here as I’m leaving for a week. I will be back to discuss the root cause. Thank you.

[sy2002]

@mrjoso This core attempts to fix the problem and therefore should be able to support the IDE64 cartridge:

c64mega65v52a2e2.zip

[xlar54]

Tested for you. The IDE64 runs fine on my Ultimate64. But when I plug it into the M65 (using your core), it says "RAM" on the c64 screen. I tried it a number of times, including removing and inserting. according to the IDE64 docs, "RAM" at startup means:

Thecartridge RAM buffer does not work reliable. Clean contact
edges, remove other cartidges or the whole port expander. Too
long ShortBus cable might also cause this. Also you might try
to reseat or replace the RAM chip.

mine is a 4.2, and i did clean the contacts.

[Kugelblitz360]

http://baltissen.org/newhtm/x_dma.htm

has more info about the DMA cycles.