[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