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

[Robert Gault]

Roger Taylor wrote:
> At 06:13 PM 1/24/2008, you wrote:
> 
>> Roger, regardless of whether a Coco3 has 128K, 512K, or more memory, 
>> when you send $38-$3F to a GIME MMU register you get the same result. 
>> If you have only 128 or 512K memory, it does not matter what values 
>> you give to the two most significant bits because it won't change 
>> anything regardless what you send to these bits on a Store! Those bits 
>> are only important with more than 512K RAM when you write to them. 
>> They are meaningless on a Read regardless of memory present.
>>
>> That means it does not matter in your program what you are doing 
>> during a LOADM as long as you don't store a value less than $38 or 
>> higher than $3F in an MMU register. Depending on the code in your 
>> program, it may not matter whether you only use MMU values of $00-$0F 
>> because the net result will can still be the same as long as you don't 
>> need the full address of the bytes those MMUs control.
>>
>> If you would post the code you are using during the LOADM (or send it 
>> by private e-mail) I could show why the results of the survey don't 
>> matter. In terms of LOADM, the survey of what can or can't be read 
>> from an MMU register has been pointless except for the interesting 
>> results caused by "floating" bits in a Coco3 system. By the way, you 
>> get the same "incorrect" values with a Paul Barton 8Meg RAM board 
>> installed. Just tested that.
> 
> 
> 
> Robert, 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.
> 
> The actual MMU block # in the entire 2-meg range that is mapped in on 
> any given CoCo the user has shouldn't matter one bit, as long as I leave 
> BASIC's area alone, which to the best of my knowledge is sitting smack 
> dab at "$38-$3F" on any CoCo 3.  Anything outside of that is .... Mine 
> to play with, ghosted or not.
> 
> If you see something I don't and want to explain why it's still working, 
> feel free.  I'm quite happy.
> 
>         org     $FFA1
>         fcb     %01000000+$30           switch in block $30 at $2000
>         fcb     %01000000+$31           switch in block $31 at $4000
>         org     $2000                   load next data into $2000+
>         includebin      "scrpart1.dat"  1st 16k of a graphics screen
> 
>         org     $FFA1
>         fcb     %01000000+$32           switch in block $30
>         fcb     %01000000+$33           switch in block $30
>         org     $2000                   load next data into $2000+
>         includebin      "scrpart2.dat"  2nd 16k of a graphics screen 
> (slightly less than 16k)
> 
>         org     $FFA1
>         fcb     %01000000+$39           restore MMU
>         fcb     %01000000+$3A           these blocks were there for any 
> CoCo 3
> 
>         org     $1000                   start of our program code
> 
>         ... everything else
> 
> 

OK, this will get your code LOADMed into memory but on a Coco with more 
than 512K of RAM, there will be a problem even though your program will 
fit in a 128K Coco.

You said that the first two blocks loaded are graphics. If your code 
displays that graphics screen by sending values to the vertical offset 
registers, you will require two sets of values. That will be the case 
because a 128 or 512K Coco will have the data at $60000 but a 2Meg or 8 
Meg Coco would have the data at $E0000. You won't know which set of 
values to use until you test for the amount of installed memory.

You might run into trouble with third party DOS that may have changed 
the LOADM code. In that case, %01000000 may not be the value you need to 
add.

There is another approach which will be independent of memory but not 
relocated DOS code. Write a Basic program as a LOADM routine for your 
binary program.
10 A=PEEK(&HC003)
20 IF A=8 THEN POKE&HD008,&H21 ELSE POKE&HCF2C,&H21
30 LOADM"ROGER.BIN"

The only sure method would be to LOADM a routine to load the rest of 
your binary without byte verification.