Commodore 64 memory layout management

[grue74]

Hello, I have done now quite a many C64 game modifications which are all started with creating a source code with 6502bench.

Almost always there is a problem with IO labels and code/data under IO space. Same goes with Kernal rom labeling and code under kenral rom.

Like I have data on $d000- $dffff, and I want to add labels for IO area, you can see the problem. It would be great that when assigning address like $d020 (border colour on c64) you could mark it as being ROM/IO which is not always visible to the cpu. So these addressed wouldnt be assigned automatically or the user might want to check that yes, all of these addresses in the code which matches the IO symbol definitions can be marked automatically.

I dont know if my explanation makes any sense, but this is a real pain on many of my projects. Its very common that the code/data uses all of the 64k and also roms and ofc IO registers on another memory layout.

I'm not asking that those sould be automatically resolved,. but something that there could be ROM/RAM layers and when youre listing ram, you shouldnt see ROM references there. But its usefull to see also ROM/IO references when needed.

[fadden]

Is the idea that you have a capture of the complete system address space, and want certain areas to be treated as external to the program you're analyzing rather than included within?

If so, one approach is to excise those areas from the data file. Tools > Slice Files is useful for this.

Another approach is to put those areas in address regions that do not allow references from other regions to resolve automatically. This is done by selecting the area, creating a new address region, and checking the "disallow inbound address resolution" box. For example, if $d020 is in a "no inbound" address region, a reference to $d020 from a different address region would fail to find a matching address, and would resolve to EXTCOL from the symbol file instead. This does not place the EXTCOL label on $d020, and has no effect on resolution within the $dxxx space, it just affects auto-resolution from other areas. The flag just affects automatic address-to-symbol resolution, and does not prevent you from explicitly referencing a symbol in the $dxxx space.

[grue74]

Oh, I havent thought about making address reqion with the same exceptions, but then again that breaks the inbound resolutions on the addresses that really use the area.
But defining this area solved some of the cases.

[grue74]

In Ghidra its handled by adding Layers to the program, then you define name for the addressspace, here IO

and then you define reference for that label point into IO space instead of RAM

[fadden]

I haven't done much with Ghidra. Looking over the docs a bit, the "memory overlay" mechanism is used to handle file sections that are overlaid in memory, e.g. for bank-switching or dynamically-loaded sections. The SourceGen address region approach lets you do more or less the same thing in terms of identifying regions and start addresses, but doesn't expose the regions in the UI as an entity that you can refer to directly.

At first glance, supporting something like this would require:

• Allowing address regions to have names.
• Providing a way (probably in Edit Instruction Operand) to say that a reference should try to resolve addresses by looking in a certain region first. It might be useful to have a general priority mechanism to say which comes first globally.
• Some UI to view and manage named regions. (This might be useful now... Navigate > View Address Map was meant to be a place-holder.)

In any event, this doesn't feel like a totally foreign concept.

It also creates the possibility of establishing multiple addresses for a single region, which comes in handy when a piece of code or data is copied around. This is currently sort-of handled with the address space "pre-label" mechanism, but that's only really useful for one-time relocations.