I know we have a few users (and fans) of Michal Kowalski's 6502 simulator (which can also be used for code development)

(It's a Windows program but it works (more or less) in linux too.)

It can write Intel hex format, and also binary format (*.65b) - it claims to offer Motorola srec format but that seems to be plain binary too(*). For binary, there's an Options button which allows you to specify the address range to dump.

The point of this post: to write a PROM, one might wish to have Intel hex format starting from $0000, but the code must start from say $C000. I think it is absolutely necessary to code with
.ORG $C000
or the equivalent
*=$C000
but then the Intel hex will describe a load address of $C000.

What to do with that?

Will a programmer happily ignore the offset and program the PROM as expected? Or is a conversion needed?

Is it better to dump a plain binary from $C000 to $DFFF using the Option button and then somehow convert to a format that the programmer needs?

Is the srecord utility going to be useful?

Cheers
Ed

(The Intel format from Kowalski's program doesn't seem to be acceptable to the srecord utility, although it may be acceptable to a programmer or to other utilities. So working with the binary output format might be necessary.)

(*) Edit: in fact, thanks to BDD's report of success, I find that I can write srecord format if I write explicitly to a file with a *.65m extension. See below. Writing to a *.s9 file is still broken for me.

I thought the offset helped set the jump and branch adddressing. Hmmm....

_________________
"My biggest dream in life? Building black plywood Habitrails"

Sorry, I must have expressed myself poorly. I'm actually unfamiliar with the conventions of feeding PROM contents to programmers - I posted my question as a generalisation of a private query I received.

A PROM runs from 0000 to 3FFF, in its own terms, but the program it contains runs from 8000 to BFFF, for example.

Do we expect to see an Intel hex file for that PROM starting like this

or like this

or does it not matter?

Cheers
Ed

it DOES matter, as the program internal jumps will go off where you dont want it.

For example, on my pinball, I use 32K base program, 8000-FFFF.I start at 8050. for example, if the org is set correctly, I can do this:

JMP Next

which would compile as an example to
JMP $8100


HOWEVER, if you do NOT set the org to 8000 it defaults to org 0000 and the command would become

JMP $0100

which wouldnt work so well....

_________________
"My biggest dream in life? Building black plywood Habitrails"

Agree completely - the ORG has to be the address that the program will run at.

My question is whether or not the PROM programmer needs to see zero-based addressing.

Cheers
Ed

The prom programmer wont care about the data, it only sees where the rom image starts in its own memory. (at least for me, using the Needham programmer).

_________________
"My biggest dream in life? Building black plywood Habitrails"

Great: so you set the ORG in Michal's simulator to $8000, you write a HEX file, and all is well?

My Needham's programmer software gives the option to do the offset, so the assembler doesn't have to know anything about it. The manual is extremely hard to understand on how to do that part, but when it was explained by one of their people on the phone, it finally made sense.

At my last place of work I used a Bytek Writer stand-alone programmer from 1986 to 1992 and it could do the same thing but I don't remember how. There's one on eBay that I would buy right away if I could get a manual for it. It has an RS-232 port and I have even hosted it with my Hewlett-Packard hand-held computers.

Ah - do I get the impression that with some programmers there would be a need to prepare the HEX file more carefully?

Another thing that comes to mind is the ability for the programmer to split high & low bytes of 16-bit words to put two 8-bit PROMs on a 16-bit data bus. I think the Needham's can do something else related to that as well. It does seem like that kind of thing is best left to the programmer.

Garth if the price is right, go fer it and you may be able to find the manual floating round. The knowledge may come back to you once you have it in front of your hot little hands

//sorry, nice to breathe easy after evil asthma attack fun, so am squirrelly today. bear with me...

_________________
"My biggest dream in life? Building black plywood Habitrails"

I bought a Genious Chinese programmer from ebay, it can split bytes, and has offset, which i can't get to work... The programmer can program all kind of stuff, even test some simpler chips like 4000 series... It has some weird bugs, but it is worth the money(i think)... Anyway i use the mentioned simulator and i tried to do the offset manually using notepad and the replace function where i replaced C0 to 00, C1 to 01, ect... But EhBasic didn't work after programming the eeprom...

am wondering if there is confusion about the offset. the eprom programmer woulnt care about the data internal to the rom image in the memory. I think that it is offset from its base memory. For example:

Let us say we have a single rom image but split it into 2 roms.

total image load:
0000-7FFF

but the eproms are programmed as
0000-3FFF
4000-7FFF

so you set the offset the first time as 0000 and the second time as 4000.

The eprom programmer would NOt change the locating jump addresses internal tot he rom image since it only knows it as a block of data to program into an eprom.

_________________
"My biggest dream in life? Building black plywood Habitrails"

I think if you replace (exactly) the fourth character in each line of the hex file, you should be fine. But if you changed all the C1 to 01 then you will almost certainly make more changes than you intend. Have a look at my post above - change ":208" to ":200" and the code assembled to 8000 would then be programmed to 0000, without otherwise being changed.

(Oh, and when you get to :209 you change to :201 and so on...)

From this

to this


Ahem, the checksums are not going to match, that could be a problem. Perhaps we do need to use 'srecord' after all. Which means we do need to write a binary file from Kowalski's program and then convert to hex.

This command line will pick out and re-dump 4k from C000 to FFFF:



Cheers
Ed

The Kowalski simulator's Motorola S-record output does work (but see caveat below) and will generate properly formed S1 and S9 records. I use it all the time to assemble code and send it to my POC unit through its auxiliary serial port. I can push 8 KB through that way in a matter of seconds.


Actually, you would be better served by having the simulator produce a binary image and use the Options button to set the starting and ending address range. Your program must be assembled at the address from which it will start executing. You burn it into your EPROM at the ROM address that will map into the true execution address.

For example, my POC unit sees ROM from $00E000 to $00FFFF. I have the ROM's address lines rigged up so that when the MPU puts $00E000 on the address bus, $0000 in the ROM is accessed. If the MPU places $00F436 on the bus, ROM will be accessed at $1436. So even though I assembled the ROM code at $00E000 I would burn it into the ROM starting at $0000. The decision to burn code at $0000 is made in the EPROM burner's software, not the assembler. If I were to start assembly at $000000 and burned the ROM at $0000, as Tony noted, none of the absolute target addresses (e.g., JMPs and JSRs) would be right—only relative addressing would work.


The Intel format and the S-record structure are substantially different (although similar in principle). My recommendation is don't waste your time with the S-record or Intel hex formats for use with an EPROM burner. Those formats are best used when the code must be transmitted to a different machine and the possibility of data corruption due to transmission errors exists. For output to an EPROM burner, use the binary image output (.65b) and be sure set the correct starting and ending addresses of your program (e.g., $E000-$FFFF).

You should consider that the Kowalski simulator doesn't generate an S0 or S5 record, neither of which is required by the official Motorola standard—only S1 and one of S7, S8 or S9 are mandatory. The lack of an S0 or S5 record will cause some EPROM programmers to reject the code. The TopWin software that drives the TOP853 burner is such a case—it's a good example of poorly written software.