The OpenC64Cart will allow us to place multiple cartridge roms on a largish eprom and select between them with jumpers. This is the 8k version giving us up to 8 8k images on a 512kbit rom. There is a 16k version of the PCB that would give you 4 16k images on the same rom, but I opted for the 8k version this time around.
- Github - SukkoPera / OpenC64Cart16k
- PCBWay - SukkoPera / OpenC64Cart16K V1
- PCBWay - SukkoPera / OpenC64Cart16K V2
- PCBWay - SukkoPera / OpenC64KernalCart V1
- VICE - The Versatile Commodore Emulator
- hexed.it - Web Hex Editor
ALWAYS TURN OFF THE COMPUTER BEFORE ADJUSTING THE JUMPERS
On and Closed mean the same thing, just as off or open do.
|ROML||LOW||OPEN||CLOSED||Most common setting|
|ROMH||HIGH||CLOSED||CLOSED||Used for 16k cartridges, so does not apply|
|Ultimax||HIGH||CLOSED||OPEN||Japan MAX machine, works if Kernal damaged|
The DEADTEST rom seems to require using the Ultimax mode. I could be wrong here, but I suspect this is essentially ‘kernel replacement’ mode.
The most common form of cartridge image appears to be the .CRT format popular with emulators. These have to be converted to straight BIN files. Vice comes with a useful tool that will let you strip the actual rom dump out of the CRT file and give you the required bin file.
Display information about a rom
C:\XXX>cartconv -f "Pac-man (1993)(Atari).crt" CRT Version: 1.0 Name: Pac-Man Hardware ID: 0 (Generic Cartridge) Hardware Revision: 0 Mode: exrom: 0 game: 1 (8k Game) offset sig type bank start size chunklen $000040 CHIP ROM #000 $8000 $2000 $2010 total banks: 1 size: $002000 C:\XXX>
Things to note here is size. $2000 is 8192 bytes or 8k. Start is where this rom is expected to live in the memory map.
Extract BIN from CRT File
C:\XXX>cartconv -i "Pac-man (1993)(Atari).crt" -o ROM1.BIN Input file : Pac-man (1993)(Atari).crt Output file : ROM1.BIN Conversion from Generic Cartridge .crt to binary format successful. C:\XXX>
Combine BIN files to make one large multi-image BIN
C:\XXX>copy 1.bin+2.bin+3.bin+4.bin+5.bin+6.bin+7.bin+8.bin OUT.BIN 1.bin 2.bin 3.bin 4.bin 5.bin 6.bin 7.bin 8.bin 1 file(s) copied. C:\XXX>
Burning the ROM
I combined my rom images on the PC and then used the Promenade C1 Clone to burn my eprom. One thing I ran in to with this process, is that normally in a Commodore file the first two bytes dictate where in memory to load the data and my raw binary copies of the roms were of course not going to have those bytes prepended to them. While we do specify where in memory to begin loading, the software takes this file format in to account, happily discarding the first two bytes of the file and starting at the 3rd byte for it’s load. This results in our data being shifted two bytes over in memory from where we would prefer to see it. I didn’t come up with a great way to defeat this behavior, but I worked around it by loading at a starting location 2 bytes ahead ($2002 instead of $2000 for example), then manually placing the missing two bytes in at $2000 and $2001 which I obtained using a hex editor on my PC. Another method would be to offset start and end addresses by negative 2 bytes.
You’ll have to refer to the instructions for your programmer if you run into this. Modern stuff is probably fine.
All the best!