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?

  • As I understand this question it's about VICE and its workings, not the C64 or anything contemporary to a C64. It seams more qualified for some VICE support forum, not RC.SE, doesn't it?
    – Raffzahn
    Commented Sep 23, 2020 at 15:21
  • 2
    @Raffzahn: My interpretation would be that it's about how to convert a VICE memory dump into a form that could be loaded by a Commodore 64 operating under its own control.
    – supercat
    Commented Sep 25, 2020 at 20:10

2 Answers 2


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).

  • Thank you, I guess "packer" and "cruncher" are the two words I wasn't aware of. I'll need to use a packer and a cruncher that runs on my host machine (Linux). I've found Exomizer for packing, and I managed to get it working. Any good recommendations for a cruncher that runs on Linux?
    – Cactus
    Commented Sep 24, 2020 at 10:12
  • 2
    From what I can read, Exomizer is actually a hybrid packer/cruncher, so possibly there is little to gain by crunching it separately.
    – user6576
    Commented Sep 24, 2020 at 14:54

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.

  • Exactly. AFAIK using default C64 LOAD"*",8,1 command you can load .prg to RAM up to 0xD000 address where VIC registers start. If you'd like to go over that address then you have to deal with your own loader (or alternatively, just use some .prg packer! :))
    – lvd
    Commented Sep 23, 2020 at 16:01
  • It goes all the way up to 0xFFFF.
    – Cactus
    Commented Sep 23, 2020 at 23:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .