But one common little difficulty - not really a difficulty, but often seen as one - is that, for example, code which lives in a ROM which will ultimately be accessed at say $8000 will have addresses in the ROM which start at $0000. There's a difference between the offset in ROM, and the address the 6502 sees.
I think this difficulty is resolved by the way in which the assembler can produce a binary, or the way in which that binary is used to produce a ROM image.
Usually, the assembler has nothing to do with where in the ROM the code gets deposited. You assemble to the target address and when it comes time to burn the ROM, you set the starting point in ROM space as an offset to $0000. I do this all the time with the ROMs that go into my POC units. Ever since I redid the memory map in V1.2, ROM starts at $00D000, as seen by the MPU. Hence addressing $00D000 accesses $1000 in the ROM—ROM space from $0000 to $0FFF is unused.
I haven't studied the behaviour of org in this assembler. But one common little difficulty - not really a difficulty, but often seen as one - is that, for example, code which lives in a ROM which will ultimately be accessed at say $8000 will have addresses in the ROM which start at $0000. There's a difference between the offset in ROM, and the address the 6502 sees.
That was handled in the Needham's PB-10 programmer I was using. (Unfortunately the last PC I had with the right kind of bus for it went south a few years ago.) The stuff about the file pointer, buffer pointer, and device pointer were terribly confusing in the manual, but I finally got a useful explanation that worked. It seems like it would have to be handled in the programmer, because you could for example have multiple 8Kx8 EPROMs, and each one's address 0000 would be at a different address in the 6502's map.
My own dodgy runs-on-a-nucleo programmer takes code assembled correctly for its final destination, and with those addresses included in the hex file, but also takes an offset which is subtracted from the hex addresses. So the prom is assumed to start at zero, but you might for example want to program only the top half of a 32k prom because the bottom half is never addressed: the hex file will start at 0xc000; the offset you need is 0x8000; it goes into nominal address 0x4000 upwards, but in the actual hardware it's in the right place at 0xc000.
So the prom is assumed to start at zero, but you might for example want to program only the top half of a 32k prom...It all makes sense when you do it a few times...
My first attempt to run POC V1.2, whose ROM’s base address is $00D000, failed, prompting me to dig out the logic probe and start searching for what was a non-existent hardware fault. POC V1.x mapped the start of ROM to $00E000, which corresponded to $0000 in the ROM itself. $00D000 in V1.2 corresponds to $1000 in ROM, but out of habit from working with V1.1, I burned the test code into $0000. So sorry! No workie!
So sorry! No workie! 