Transforming a memory dump into something loadable

Question

As a follow-up to this question, I now have:

• A memory dump of the unpacked application
• The start address of the application

I can verify that the dump is correct by starting a new instance of Vice, loading back the dump, and then jumping to the start address, and the program works as expected.

Normally, at this point I would be done: Vice already slaps a two-byte starting address at the start of each memory dump, so I could just put the resulting dump as-is into a tape or disk image using a tool like c1541, and attach that to Vice.

However, parts of the dump correspond to address regions that are by default banked to ROM. This is not a problem when saving/loading from Vice directly, since I can just use the bank ram command to read from / write to RAM regardless of the current state of banking. And of course when jumping to the application's start address, the application initialization code will take care of setting up the right memory layout. But how do I load the data into these regions?

I guess the obvious way would be to write a two-stage loader: load a tiny first program to set the value of 0x01 to expose all RAM, then load the rest. However, this sounds like something that should definitely exist. Moreover, the program + initial data is not all in a contiguous blob, so I should be able to speed up loading by skipping the runtime data parts that will be initalized during normal operation anyway. I would like to avoid this solution not only because I'm too lazy to write this program, but also because I'd like the result to be a single .prg file.

So my question is, what is the easiest way of translating a C64 memory dump, or, potentially, a set of non-overlapping memory dumps each with its own start address, into a single loadable file, if parts of the memory dump correspond to addresses that are mapped to ROM in the C64's initial state?

Answer 1

Your intuition is right and you could write your own loader, of course. But the "standard" way we used to deal with this back in the day was to use a tool most often called a Packer.

It typically accepts a list of memory blocks from disk and often lets you override load addresses of these units as well. Then it combines them into one, does a simple run length encoding compression and prepends a depacker - often stored in the screen memory to leave as much target memory as possible open, including under ROMs and I/O space.

(Typically, you would then run a Cruncher - using some LZW-like algorithm - on this combined version, for greater compression. That could take like half a day to run. :)

Threre are loads of different Packers out there but one of the most well known ones is called Sledgehammer - you've probably seen it advertise itself along with it's depacker code on the display of many an old demo production/crack.

There are many versions of it to be found on CSDB, including a pretty recent version (2018).

Answer 2

Maybe I'm confused by your question, but have you tried LOAD'ing the PRG file?

Loading memory is done with write operations. Write operations ignore ROM banking and always go to the underlying RAM location. Yes, your program initialization needs to bank-in the RAM it will be using, but the loading should work regardless of the initial banking setup.