C64 cart preset

[BacchusFLT]

The wish is fee, even if I know this is a total corner case and realise the consequential priority;

I guess you have a mechanism for parsing/handling the different filetypes, when selecting the file types. So if I select C64 PRG it will have a routine that imports knowing the file type structure of that file type which is slightly different than when selecting c64 BIN.

I would very much like to see support for c64 cartridges (as that seems to be what I have used the program for, given that no other program on that market can handle the size of these 6502 binaries).

This would means setting an ".addrs" to $8000 on every $2000 bytes of the file. Adding a note that also denotes the location would be a clear bonus.

(There is also a CRT format with a header but parsing the binary option is likely easier).

[fadden]

The trick is to avoid hard-coding it into the executable. Adding a feature to SystemDefs.json that drops an address region every N bytes might be sufficient, possibly with an initial offset for the file header, though it looks like CRT headers aren't fixed-length. Then we'd just add a new "C64 cartridge" entry to SystemDefs.

This might be better served by an existing item on the to-do wiki:

• Add "file format recognizers". Simplest form looks at filename and bits of files, and sets default values for things like address and entry-point status flags. Could pull in optional symbol files and extension scripts.
  • Could implement as one or several extension scripts. Possibly platform-specific.

Instead of trying to define everything in SystemDefs.json, SourceGen would run a script that parses the file contents and generates project elements (address regions, notes, comments, project symbols, etc).

On a related note, marking the header as non-addressable actually works out pretty well... go to https://6502disassembly.com/nes-smb/SuperMarioBros.html#SymStart and scroll up to see what it looks like for an iNES header. (I reworked SMB's addresses after releasing v1.8.0-beta1. FWIW, Metroid is closer to what you're doing.)

[fadden]

Moved to "TO DO" wiki.

[BacchusFLT]

Just to make sure I have made this clear, there are two types of headers. One is where the header is part of the native environment and then one which is only for "bigger systems".

C64 PRG and Cart files (binary with a native cart header) are native to the environment, where the PRG has the two byte load header and the Carts have a structure that would tell the native environment that they are carts and how the warm/clod boot would work.

Then you have stuff like the SID and CRT which is emulator filetypes, with a lot of metadata information that must be extracted before it works in the native environment.

My reference here was a native fileformat with a cart struct header - no emulator headers or such.