I believe what he's trying to do is patch the binary included with
PUTBIN with the assembler itself.
With an assembler written by C64 people you can do this, because they
have separate notions of "physical" and "logical" program counters
within the assembler. For example, in 64tass if you do this:
* = $1000
lda $1234
* = $1001
.word $4567
rts
The output is:
00000000: ad67 4560 .gE`
Merlin32 only has a "logical" PC, so it assembles the same code to:
00000000: ad34 1267 4560 .4.gE`
The C64 assemblers place everything into a 64KB bank. If the output is >discontiguous, you'll get empty gaps in the output file. It will even
wrap around at the end of the bank, so the stuff you output at the end
of the source file ends up at the start of the binary. >(https://sourceforge.net/p/tass64/bugs/59/)
Once I understood this, certain aspects of 64tass and ACME made a lot
more sense. I'm not aware of an Apple II assembler that had the notion
of separate PCs, though the old "OBJ" directive could have been used
this way.
EDASM worked differently and I think you could rewrite earlier
instructions by storing instructions directly in memory at the OBJ addresses. EDASM was really slow and hard to use, so it wasn't popular
(at least the DOS 3.3 version was slow).
I believe what he's trying to do is patch the binary included with
PUTBIN with the assembler itself.
I believe what he's trying to do is patch the binary included with
PUTBIN with the assembler itself.
Exactly! Thanks for boiling that down to one succinct sentence for me.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 67:44:48 |
Calls: | 6,654 |
Files: | 12,200 |
Messages: | 5,331,962 |