[Coco] "Reading" non-readable bytes with PEEK vs ZBUG

Roger Taylor operator at coco3.com
Thu Jan 24 22:20:34 EST 2008


At 07:10 PM 1/24/2008, you wrote:
Ah, that makes more sense. There are three approaches for that 
problem. 1) Make the BEQ in the LOADM routine a BRA (DOS1.1 $D008 
DOS1.0 $CF2C). (Requires knowing whether DOS1.0 or DOS1.1 is 
present.) 2) LOADM your own LOADM routine which does not bother with 
verification. 3) Do what Roger is doing, use MMU values that will be 
verified because they match the floating bit misreads.

>A possible problem with 3) is it will use different memory with more 
>than 512K RAM present.


As I mentioned, the actual MMU blocks mapped in will always be 
outside of $38-$3F so it won't matter since the game only requires an 
extra 64k "somewhere".

If I write a 512k game which I most certainly will do soon, I'll 
reference blocks as $00-$3f but in LOADM I'll still add %01000000 to 
stash data during the load, but I won't be able to load more than the 
maximum floppy disk size, so I'm just guessing about ~137k of media 
content depending on how tight the actual game code is.  Actually, 
code segments can be loaded in the same way as I do with Projector-3 
during run-time (OS-9 L2 ring a bell?).

As for my little LOADM trick, the only person who seems to be worried 
is Tim but I can't imagine why since it's totally safe all across the 
board.  From BASIC, the stack is the only worry and I'm *nowhere* 
near it from $2000 to $5FFF.  None of Disk BASIC's tables are 
anywhere near $2000.  It's the same "clear zone" that almost every 
single LOADMable program has used since ~1980.

So...

It's a Go, and great things are going to happen due to how simple 
everything can be loaded from a single .bin file, with no patching, 
no hacking, and all-CoCo 3 compatible.






More information about the Coco mailing list