Ability to set starting Offset

Wishlists for new functionality and features.
Post Reply
rprouse
Posts: 4
Joined: 04 Jul 2021 05:16

Ability to set starting Offset

Post by rprouse »

I am working with binary files that are loaded to EEPROMs that when run will be at a non-zero location in memory. One example is a Commodore 64 cartridge that loads at 0x8000. It would be convenient if the starting offset address could be set after a file is opened so that the go to in the data inspector went to the correct address and Copy offset copied the correct address.

The simplest option would probably be to add a Starting Offset option to the View menu.
Maël
Site Admin
Posts: 1454
Joined: 12 Mar 2005 14:15

Re: Ability to set starting Offset

Post by Maël »

I think I have an option that integrates better with the rest:
Add an entry to the extras/tools menu, to open a memory image. Then it would insert a folded region of undefined data (depending on the file type, or file contents), just like in the RAM editor/virtual memory editor as well.

Additional to that, have an option to omit leading or interspersed undefined regions when saving to a file.

What kind of memory images would that be? That is, what file extensions and do they contain the loading offset or is it hardcoded?

Edit: I see the C64 has a memory map, so that fits well with how it works in modern machines with virtual memory. So the idea would really be to provide a memory map, or for simplicity, just one section of this map (start explicit, end implicit by file size). That way this concept is general, and could be extended to a full memory map in future.
http://blog.worldofjani.com/?p=879
http://sta.c64.org/cbm64mem.html
rprouse
Posts: 4
Joined: 04 Jul 2021 05:16

Re: Ability to set starting Offset

Post by rprouse »

This is an interesting option especially if the memory maps were pluggable so that they could be updatable or added to depending on the user's needs. For example, the cc65 compiler provides configuration files for various 6502 based machines that among other things define the memory map.

Memory maps can get quite complicated though as most machines allow you to bank/switch out memory. For example, the C64 allows you to bank out the Kernal and Basic roms effectively giving you a different memory map.

I'd also argue to keep it extendable/plugable for people like me that build their own 8-bit computers which all have their own memory maps.

One complication is that memory can get banked out using the high address pin of a ROM chip. A simple example of this would be a 16 Kbyte ROM that is used as two 8 Kbyte memory areas depending on the state of the high memory pin. The low or the high of the ROM is visible on the address bus from 0x8000 to 0x9FFF depending on the high pin. I'm not sure how you would deal with that though.

To answer your questions,

File extensions for ROMs are usually BIN and they don't have any headers. They are programmed onto the ROM chips at address 0x0000 but when connected to the computer, those ROM chips appear at other addresses depending on how they are connected to the bus.

For the C64, there are also program files with the extension PRG. These have a two byte little endian header that specifies the address that the rest of the file is loaded at. The rest of the file is straight binary machine language. I am not sure about other retro systems, but there are other common formats with short headers especially for loading into headers. I think all of this is outside the scope of this request though :D
Maël
Site Admin
Posts: 1454
Joined: 12 Mar 2005 14:15

Re: Ability to set starting Offset

Post by Maël »

I agree, banking will be difficult, e.g., when searching a file/stream, as it would break a fundamental assumption (each byte has exactly one address). You'd only find data for the currently active bank. For display you could have a kind of listbox or arrow buttons to select the bank, but that would be mostly for visualization.

Doesn't seem to be worth the effort, except if you write an emulator, where you will be able to see the whole memory.

But for the rest, I guess a minimal memory map makes sense.
rprouse
Posts: 4
Joined: 04 Jul 2021 05:16

Re: Ability to set starting Offset

Post by rprouse »

Doesn't seem to be worth the effort, except if you write an emulator, where you will be able to see the whole memory.

But for the rest, I guess a minimal memory map makes sense.
I agree with that. I think that just being able to have the correct memory addresses will be a huge help.
Additional to that, have an option to omit leading or interspersed undefined regions when saving to a file.
Could I also add the option to fill the remaining unused space with a set value when saving a file? When programming an 8K ROM, you use an 8K BIN file and usually fill it with something like the binary representation of a NOP instruction.
Maël
Site Admin
Posts: 1454
Joined: 12 Mar 2005 14:15

Re: Ability to set starting Offset

Post by Maël »

rprouse wrote: 05 Jul 2021 17:30Could I also add the option to fill the remaining unused space with a set value when saving a file? When programming an 8K ROM, you use an 8K BIN file and usually fill it with something like the binary representation of a NOP instruction.
If you open a file, the only undefined region would be the leading "bytes" before $8000. If you would want the following section to be larger than the bytes in the bin file, it could be automatically filled with a byte pattern upon opening.

Not sure how you want to do that when saving/closing a file.
rprouse
Posts: 4
Joined: 04 Jul 2021 05:16

Re: Ability to set starting Offset

Post by rprouse »

it could be automatically filled with a byte pattern upon opening.
Sounds good, I misunderstood.
Post Reply