My previous version of my SBC had ROM in the entire upper address space: $8000...$FFFF. However, I rarely use that space so I've reconfigured it to have RAM $0000...$BEFF, I/O $BF00...$BFFF and finally ROM $C000...$FFFF. I am using an AT28C256 for my ROM. However, now that I've done this, my ROM should have length $4000 and so it doesn't fill the entire ROM and I can't use minipro to install it.

Is there a way in a cc65 cfg file to configure cc65 to make a file with length $8000, pad with zeroes until the start of my code section at $C000, and then fill out the rest with the real bytes? Or, alternatively, can i write a file starting at a specific location in minipro?

EDITED: I had "finally RAM" and it should be "finally ROM"

Sorry, this isn't directly answering the question...

While there might be a way to configure cc65 as you want it, another possible way is just to write your assembly code such that it starts with 4k of zeroes. (I'm assuming you are writing in assembly, not in C.)

And another way is to use some other tool like dd to prepend 4k of zeroes to the 4k ROM binary you can write.

But another way is this: your glue logic determines which bits of the ROM land at which addresses. You could arrange for the low half of the ROM to land at C000, perhaps just by tying off an address input.

Some ways to set this up in the ld65 linker config:

16K padding section:

32K section with coded loaded at 16K offset:


Personally, I'd to what Ed suggested and handle the padding as a separate step in a script. If your only concern is the correct file size, you could just double up the file:

(or "type" instead of "cat" on Windows)

Yeah ok, I wrote a python script to pad the beginning it appears to be working. Added it to my makefile when installing so it's not too bad. Thanks!

If you have unused EPROM/EEPROM space, it’s better to pad with 0xFF than 0x00 as then it programs quicker. Unless of course you actually need the values stored to be 0x00.

0xFF is the ‘blank’ value that memory addresses in a EPROM/EEPROM go to when erased.

Mark

There is another advantage of padding with $FF: You can burn new code into the padding later without having to erase and reprogram the whole thing.

Using the AT28C256, you can program it insitu... very simple to do. You don't have to pad it with anything. I have routines in my Monitor code that will allow changing one byte at a time or moving any length block from RAM to ROM.

On another note: not sure why there was a need to pad the file to program with... but I'm guessing the schematic was probably changed.... posting that would be helpful to figure out why any changes were needed.

_________________
Regards, KM
https://github.com/floobydust