6502.org

I'm having an issue that I'm hoping others have run into and might be able to help.

When writing a program, I tell the assembler (Kowalksi Simulator) to start the code at $8000, which is the start of my EEPROM on my machine.

I can save the assembled code as an intel hex file, but when I go to import in into the program to flash my eeprom, it says "Out of address range for the device." Which I get, because technically my EEPROM only has $0000-$7FFF, which just gets mirrored by my address decoding into $8000-FFFF

Anyways, the point is, if I tell the assembler to start at $0000, it will load into my flashing software, but then the addresses of subroutines get messed up.

Is there any way I can compensate for this? Say, my assembly code starts at address $8000, but the hex file will tell the flashing software to input the machine code at $0000 on my EEPROM chip? Does this make sense? Sorry for the long winded questions!

Otherwise I've just had to assemble the code, look at the memory in the simulator and copy it by hand into my EEPROM programming software starting at $0

Writing (assembler) using the final destination address is correct. All subroutine calls are usually absolute, so they would jump into the forest if the assembled addresses are different from the runtime ones.

How do you import the hex file? Perhaps you have an option to redirect the addresses (encoded within the hex file) by adding/subtracting a fixed offset (in your case $8000).

Otherwise - is there any way to transfer a "binary" file? There an option where to "store" may exist.

There are a couple of things you can do. As mentioned, outputting to a to binary is probably one of the easiest.

There are several utilities named HEX2BIN that will do that and most will support an address offset or have provision for the base to be at the address of the first hex record.

I use 64tass and it includes a .offs (offset) directive. This was common back when you were assembling code on the same machine it was targeted for. If you were writing code for ROM, you needed the assembler to put the code in RAM. (And even if you were targeting RAM, you had to avoid your editor / assembler while you were doing development work.) So you could basically have the program counter set to something like $Fxxx but put the assembled (binary) code at another address like $1xxx. Using the offset feature, you can usually set the base address to $0000 when you are putting it out in Intel HEX format.

But what has become my favorite for this like this is a utility called SRECORD by Ken Krother. This will let you convert between formats and handle things like offsets. And it even supports conversion to the format you could load into the Ohio Scientific C1P monitor. Anything that can do that has to be alright.

http://srecord.sourceforge.net/

It could do either Hex to binary conversion or it could recreate the Hex records with the offset subtracted.

Thanks,
Jim W4JBM

Thank you all for the quick reply. I looked for an offset option in the way that I was importing the code and sure enough there was, but it was worded very weirdly (Chinese software translated to English). Anyways, saying "offset" gave me a good place to look and I found it.


Thank you all so much! I'll have to post pictures of my build somewhere so everyone can cringe at my first breadboard experience.

The simplest way is to just write it as a binary. There is no address attached.
As was stated, most programs that write or read Intel hex have some type
of offset option.
The programmer I have, can put the image anywhere. I just tell it where
to put it.
Dwight