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

Roger Taylor operator at coco3.com
Thu Jan 24 23:05:17 EST 2008


At 09:02 PM 1/24/2008, you wrote:


> > ... there's a logic to what I'm doing because of 1) ghosting, 2)
> > my program will only use 128k of RAM no matter what CoCo it's on, and
> > 3) LOADM should see a %01000000 float or actual (doesn't matter to
> > me) when it verifies my GIME writes, and 4) I'll reference the same
> > block #'s in my program by adding %01000000 to the GIME writes.
> >
>
>---
>
>Roger,
>
>You are assuming that all hardware and all implementations of LOADM 
>will produce a '1' in bit 6 of an MMU register. If you are 
>comfortable with that assumption, fine. I would certainly not rely 
>on that for anyhing intended for public release.

>If you insert the following 84 bytes into the beginning of your bin 
>file, you wouldn't have to worry about any of this.
>
>00 00 41 01 DA CC 7E 3B B7 01 6A F7 01 06 8D 23
>34 02 8D 2B 1F 02 8D 27 1F 01 A6 E0 27 0B 9F 9D
>BD A4 2D BD AD 33 7E AC 73 8D 08 A7 80 31 3F 26
>F8 20 DB BD A1 76 0D 70 27 0B C6 2E 7E AC 46 8D
>00 8D F0 1E 89 39 00 00 03 01 06 7E 01 DA 00 00
>01 01 6A 3F
>
>Darren


That's why I did the public test request for MMU PEEK to see what's 
happening.  If I could get 1,000+ confirmations instead of 20 or 30, 
I'd be more happy, but so far the odds of these people being spread 
around the U.S. and globe with not-identical CoCo 3's, I'm a lot more 
than 0% convinced that a 128k/512k CoCo 3 reads back a "01".  I agree 
that this is not a full guarantee, though.

Are you 100% sure your code is fully compatible with all CoCo 3's and 
Disk ROM versions?  Tested?  There's some odd DOSes out there that 
may have their own way of implementing LOADM that doesn't call on 
those hooks.  I see direct ROM calls in your source code which is 
about the same worry as expecting a certain value to be in the 
floating-but-assumed-not-random upper 2 bits of the MMU.

Just because all of the recent conflicting test results were found to 
try to figure out why a 01 or 00 appears based on what opcodes you 
use to read the MMU registers, doesn't necessarily mean the bits 
change at any time the CoCo is LOADMing a file.

Some would say all of this is too much trouble, but I insist that 
it's not.   At worst I can make several copies of the .bin file, each 
expecting a certain 2-bit value to be present.  The most compatible 
one, so far being with everyone with a 128k/512k CoCo 3 who replied 
to my test request, would be the 01 version.





More information about the Coco mailing list