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

jdaggett at gate.net jdaggett at gate.net
Thu Jan 24 21:04:34 EST 2008


On 24 Jan 2008 at 14:46, Roger Taylor wrote:

> At 10:11 PM 1/23/2008, you wrote:
> >Darren A. wrote:
> >
> >>>Does it make any difference in these tests if the CPU is in 
> >>>double-speed mode?
> >>
> >>--
> >>No Roger. I have tested it on a 128K CoCo3 68B09 at both speeds.
> >>There is no difference in behavior. I believe Robert G. has
> >>confirmed that the same results are seen on a 6309 in emulation mode
> >>(don't know about native mode). One thing to consider about your
> >>LOADM trick is that the behavior is dependant on the sequence of
> >>instructions executed. Chances are fairly good that all third-party
> >>versions of Disk Basic have simply copied the LOADM code used in
> >>Tandy's version, but that's just a guess. As someone stated in a
> >>previous post, creating a process that relies on some undefined
> >>behavior makes the entire process undefined. Darren
> >
> >The one thing clear from this discussion is not whether the CPU or
> >GIME are misbehaving or if clock speed is important. What is clear is
> >we should not try to read non-readable bits! Any attempt to get info
> >from the MMU registers should mask off non-active bits. It is silly
> >to insist that it is safe to take the entire byte as meaningful.
> 
> 
> I agree it's normally silly, except for a much needed LOADM approach
> to loading stuff into the extended RAM.  Since LOADM always sees
> 01xxxxxx for 128k/512k CoCo 3's until someone reports otherwise, the
> bits are readable and useable and assumed '01'.  I can't think of any
> other reason someone would want to use the bits.  However, there's no
> danger if the programmer knows what they're doing and has fully tested
> what they're doing.  This is how Sock has given so many impossible
> demos, by doing things to the GIME and video registers that some
> people would say is "not legal".
> 
> 
> 


If the two bits are not actually known or not consistantly the same then do 
two LSLs followed by two LSRs.  This will shift the two questionable bits out 
through the carry and the two LSRs will shift "0" back into the upper two bits. 

problem solved. 

james



More information about the Coco mailing list