[Coco] "Reading" non-readable bytes with PEEK vs ZBUG
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.
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