#298 REU support in the monitor

[Pontus Berg]

The monitor doesn't at all support access to REU content. Working with REU based functions, there are two workarounds;
Use a file based REU conetent and access that file.
Load in a native c64 monitor that supports REU access

Neither options is very convenient.

[Pontus Berg]

The command needed would be a new option to the "Bank" command and then operations would be directed towards the REU and not computer RAM.

Example of how it was implemented in the past on the native machine:

http://www.fairlight.to/docs/text/tronmon_docs.html

This addresses the REU in chunks of 64K banks. That way you don't need to implement 24 bit addressing.

[Pontus Berg]

If not bank, then possibly enabled as a part of the Device command.

[gpz]

Just so we dont forget it... we had a short discussion in #vice-dev. The conclusion is that
1) this should indeed be implemented via "bank"
2) we also want to expand the "bank" command with an extra parameter, so we dont have to introduce 256 bank names, but instead can write something like "bank reu:12"

1) is easy to do, 2) is somewhat more involved, but really should be done, because having reu00, reu01...reuFF is kinda silly :)

[Pontus Berg]

Looking forward to however you implement it. :)

On Thu, 17 Sep 2020, 15:47 gpz, gpz@users.sourceforge.net wrote:

Just so we dont forget it... we had a short discussion in #vice-dev. The
conclusion is that
1) this should indeed be implemented via "bank"
2) we also want to expand the "bank" command with an extra parameter, so
we dont have to introduce 256 bank names, but instead can write something
like "bank reu:12"

1) is easy to do, 2) is somewhat more involved, but really should be done,
because having reu00, reu01...reuFF is kinda silly

[Paul Hocker]

Wondering if there is any progress on this at all?

[Olaf Seibert]

I have been fixing some details in the banking code related to xcbm2 and disassembly (the D command used a different way to access memory than the M command, which could have the result that they could see different memory). So I looked a bit at the code. Some observations.

Yes it makes sense to use something with the "bank" command.

The supercpu already has more than 256 banks (ram00-f7 + romf8-ff + the others) and that is not very practical, because all these banks need to be listed in several tables.

There is something called a "bank index" with related function mem_bank_index_from_bank() and it it is stored in mon_interfaces[mem]->current_bank_index, but then it doesn't seem to be used anywhere, except for printing bank names as ram00-f7 instead of listing them in full. Maybe this was meant to help with the idea above (bank reu:12), but in that case it was far from finished.

There are more memory expansions that also might want to have their memory banks like this (GEO-RAM, ramcart and RAMLink, and what about the "memory expansion hacks" C64 256K, +60K and +256K).

Ideally the banks are added dynamically only when the appropriate memory expansion is present. Unfortunately the monitor doesn't access all data via function calls, there are also calls to get full tables at once. That doesn't combine well with dynamically changing lists of banks.

In other words, this needs some reorganizations to make it practical.

[Pontus Berg]

Olaf,

Will your work lead to any activity to implement the REU support or were these just observations while passing by?

I would assume you either support the REU or not, but in case it might save a bit of work, just supporting the "m" and "i" commands in the monitor would make all the difference. Support for "d" is nice, but the REU is not really a place for code. Key is to see if the writes actually "took", and to see the data it will read before reading.

/Pontus "Bacchus" Berg