[Coco] .BIN to .ROM
William Astle
lost at l-w.ca
Tue Dec 24 16:45:55 EST 2013
On 13-12-24 02:23 PM, Chad H wrote:
> That's my thinking, but I don't know enough assembly to decipher the code
> from the Unravelled series and make the loader. I was thinking just any
> .BIN in general, like games, utilities, etc. If the combined loader + BIN
> was larger than my EPROM, just move to a larger capacity EPROM.
>
Warning: mailer code(tm) - may or may not work.
ldy #startbin
again lda ,y+
bne postamble
ldx ,y++
ldu ,y++
nb lda ,y+
sta ,u+
leax -1,x
bne nb
bra again
postamble
The above should handle any properly formed LOADM style binary. Once it
gets to "postamble", the execution address will be at 2,y. The binary
image will be at "startbin".
Actually transferring control to the binary file may not be quite so
simple as doing "jmp [2,y]". Many binaries expect "rts" to return
control to basic which it may not do depending how your loader gets called.
A LOADM file (and multi-record CLOADM files - don't go there) consist of
a series of data blocks each prefixed by a 5 byte preamble. After the
last data block, a 5 byte postamble follows.
A preamble consists of a 00h byte followed by a 2 byte length and then a
2 byte load address. The length is the number of bytes in the data block
which immediately follows the preamble.
A postamble consists of a ffh byte (or any nonzero byte, really, but ffh
is the best to use) followed by two unused bytes followed by the 2 byte
execution address.
Nothing follows the postamble. LOADM (and CLOADM) stops reading the file
at this point even if there is more data following.
If you do find a file with data following the postamble, assume that the
file is not a normal binary file and that it cannot be loaded using the
above loader scheme. In this case, it is either corrupted or doing
something incredibly clever (for some value of "clever").
More information about the Coco
mailing list