[Coco] CPU speed in MIPS

[Arthur Flexser]

William Astle's break key explanation for why the CoCo 3 does worse in the speed
tests than the CoCo 2 sounds correct to me, but a test of this would be to do a
POKE &HADEB,&H39 on the CoCo 3, which bypasses the break key check entirely, and
see if the CoCo 3 then ran faster than the CoCo 2.  (This poke would also work
on the CoCo 2, but only if you put it into all-RAM mode first.)  Assuming the
explanation is correct, I'd point out that this comparison of the CoCo 3 vs.
CoCo 2 speed is quite misleading in suggesting that the CoCo 3 is significantly
slower than the CoCo 2 on account of the less efficient break key check.  The
obtained results are for a tight loop with short statements being repeated over
and over, so that the break key check time inserted between statements increases
execution time by a substantial percentage.  In a real program, the typical
statement's execution time would be more substantial compared to the break key
check time, so the percentage of slowdown from the break key checks would be
much less.

I'd assume that the reason for the slower break key check on the CoCo 3 (and in
Color Basic 1.2 compared to 1.1) is that it was discovered that quite a few
Basic programs developed under Color Basic 1.0 did not run correctly under Color
Basic 1.1 with its more efficient break key check.  These would be programs that
PEEKed at the keyboard rollover table to determine whether a key was being held
down, such as a game program controlled by the arrow keys.  The more efficient
break key check caused such programs to think the key was still down after it
was released, so the game would not function correctly.  That's why, I assume,
the less efficient check was also incorporated into Disk Basic 1.1, as William
mentions.  (A better solution would have been to publicize that a call to INKEY$
before peeking the rollover table fixes the problem.)

Art


On Thu, 19 Apr 2007, William Astle wrote:

> > Diego Barizo wrote:
> >> Surprisingly, the high speed poke turns a sluggish CoCo into a PC
> >> killer (The T.1100 laptop)
> >> The poor rating on the Print test for the CoCo 3 is because I used one
> >> of the hi-res text modes.
> >> But anyway, the CoCo3 seems slower than a 2. Might be because the 3 is
> >> always in "all RAM"?
> 
> That's actually easily explained. Between every statement, there is a
> poll for the BREAK key. On the original color basic, that meant doing a
> full poll of the keyboard between every statement. In newer versions,
> POLCAT was patched to check if any key was down and if none were down at
> all, it didn't bother polling the keyboard. The upshot of this is that
> BASIC runs faster as long as no keys or joystick buttons are pressed.
> 
> Unfortunately, a patch in the CoCo3 removed the check in POLCAT so that
> the keyboard is scanned completely between every statement again. That
> means that the system runs a bit slower than an equivalent CoCo2.
> 
> IIRC, there's also a replacement to the command interpretation loop in
> DECB 1.1 which does the same thing so you would think that DECB 1.1
> would solve the problem on the CoCo3. Unfortunately, the patching
> routine in the CoCo3 recognizes DECB 1.1 and patches that routine out
> too. Useful, eh?
> 
> So, basically, the CoCo3 is running slower than the CoCo2 on plain basic
> statements because of the BREAK check process is scanning the keyboard
> whether a key is down or not.
> 
> -- 
> William Astle
> finger lost at l-w.ca for further information
> 
> Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL++++$ P++ L+++ !E W++ !N w---
> !D !M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y?
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>