Category Archives: CoCo 3

We have the CoCo 3 GIME font

A few years ago, both the 1986 and 1987 versions of the Tandy Color Computer 3 GIME chip were de-capped and photographed under a microscope. This work was done thanks to the efforts of Sean Riddle, Erik Gavriluk, and Roger Taylor.

When the first CoCo 3 emulator was released by Jeff Vavasour, he would have had to recreate the CoCo 3 font manually by looking at the screen and counting the pixels. Over the years, we have seen updates to various emulators in regards to the fonts as folks figured out some pixels were wrong here and there.

I believe we know the full font of the CoCo 1/2 MC6847 VDG so those should be accurate these days, but we really never had confirmation of the font in the CoCo 3 until these de-caps were done.

Here is a low-resolution image of the 1986 and 1987 GIMEs:

Tandy CoCo 3 GIME scans.

Quite different! I do not know what the contents of the two ROM areas are, but I suspect the font data is part of it. In the GIME archive (available on my Dropbox or as a torrent), there is an image of the bits from those ROM areas:

CoCo 3 GIME rom bits.

And also from the archive is the font data represented in a text file that Roger Taylor (or one of the others) extracted:

----------
* * *
* *
*
*
*
* *
* * *
*
----------
* *

* *
* *
* *
* * *
* * *

----------
*
*
* * *
* *
* * * * *
*
* * *

----------
*
* *
* * *
*
* * * *
* *
* * * *

----------
* *

* * *
*
* * * *
* *
* * * *

----------
*
*
* * *
*
* * * *
* *
* * * *

----------
*

* * *
*
* * * *
* *
* * * *

----------


* * *
* *
*
* *
* * *
*
----------
*
* *
* * *
* *
* * * * *
*
* * *

----------
* *

* * *
* *
* * * * *
*
* * *

----------
*
*
* * *
* *
* * * * *
*
* * *

----------
* *

* *
*
*
*
* * *

----------
*
* *

* *
*
*
* * *

----------

* *
* *
* * *
* *
* *
* * *
*
----------
* *
*
* *
* *
* * * * *
* *
* *

----------
*
*
* *
* *
* * * * *
* *
* *

----------
*
*
* * *
* *
* *
* *
* * *

----------


* * *
* *
* * * *
* *
* * * *

----------
* * * *
* *
* *
* * * *
* *
* *
* * * *

----------
*
* *
* * *
* *
* *
* *
* * *

----------
* *

* * *
* *
* *
* *
* * *

----------


* * *
* * *
* * * *
* * *
* * *

----------
*
* *

* *
* *
* * *
* * *

----------
*
*
* *
* *
* *
* * *
* * *

----------
* * *
* * *
* * *
* * *
* * *
* * *
* * *

----------
* *
* * *
* *
* *
* *
* *
* * *

----------
* *
* *
* *
* *
* *
* *
* * *

----------
* * *
*
* * *
* *
* * *
*
* * *

----------
*
* *
*
* * *
*
* *
* * * *

----------
*
*
* * * * *
*
*

* * * * *

----------
*
* *
*





----------
*
* *
*
* * *
*
*
* *
*
----------








----------
*
*
*
*
*

*

----------
* *
* *
* *





----------
* *
* *
* * * * *
* *
* * * * *
* *
* *

----------
*
* * * *
* *
* * *
* *
* * * *
*

----------
* *
* * *
*
*
*
* * *
* *

----------
*
* *
* *
*
* * *
* *
* * *

----------
*
*
*





----------
*
*
*
*
*
*
*

----------
*
*
*
*
*
*
*

----------

*
* * *
* * *
* * *
* * *
*

----------

*
*
* * * * *
*
*


----------





*
*
*
----------



* * * * *




----------






*

----------

*
*
*
*
*


----------
* * *
* *
* * *
* * *
* * *
* *
* * *

----------
*
* *
*
*
*
*
* * *

----------
* * *
* *
*
* * *
*
*
* * * * *

----------
* * *
* *
*
*
*
* *
* * *

----------
*
* *
* *
* *
* * * * *
*
*

----------
* * * * *
*
* * * *
*
*
* *
* * *

----------
* * *
*
*
* * * *
* *
* *
* * *

----------
* * * * *
*
*
*
*
*
*

----------
* * *
* *
* *
* * *
* *
* *
* * *

----------
* * *
* *
* *
* * *
*
*
* * *

----------


*


*


----------


*


*
*
*
----------
*
*
*
*
*
*
*

----------


* * * * *

* * * * *



----------
*
*
*
*
*
*
*

----------
* * *
* *
*
*
*

*

----------
* * *
* *
*
* * *
* * *
* * *
* * *

----------
*
* *
* *
* *
* * * * *
* *
* *

----------
* * * *
* *
* *
* * *
* *
* *
* * * *

----------
* * *
* *
*
*
*
* *
* * *

----------
* * * *
* *
* *
* *
* *
* *
* * * *

----------
* * * * *
*
*
* * *
*
*
* * * * *

----------
* * * * *
*
*
* * *
*
*
*

----------
* * *
* *
*
*
* * *
* *
* * *

----------
* *
* *
* *
* * * * *
* *
* *
* *

----------
* * *
*
*
*
*
*
* * *

----------
*
*
*
*
*
* *
* * *

----------
* *
* *
* *
* *
* *
* *
* *

----------
*
*
*
*
*
*
* * * * *

----------
* *
* * * *
* * *
* * *
* *
* *
* *

----------
* *
* *
* * *
* * *
* * *
* *
* *

----------
* * *
* *
* *
* *
* *
* *
* * *

----------
* * * *
* *
* *
* * * *
*
*
*

----------
* * *
* *
* *
* *
* * *
* *
* * *

----------
* * * *
* *
* *
* * * *
* *
* *
* *

----------
* * *
* *
*
* * *
*
* *
* * *

----------
* * * * *
*
*
*
*
*
*

----------
* *
* *
* *
* *
* *
* *
* * *

----------
* *
* *
* *
* *
* *
*
*

----------
* *
* *
* *
* *
* * *
* * * *
* *

----------
* *
* *
* *
*
* *
* *
* *

----------
* *
* *
* *
*
*
*
*

----------
* * * * *
*
*
*
*
*
* * * * *

----------
* * *
*
*
*
*
*
* * *

----------

*
*
*
*
*


----------
* * *
*
*
*
*
*
* * *

----------
*
* * *
* * *
*
*
*
*

----------

*
*
* * * * *
*
*


----------
*
* *
* *





----------


* * *
*
* * * *
* *
* * * *

----------
*
*
* * *
* * *
* *
* * *
* * *

----------


* * *
* *
*
* *
* * *

----------
*
*
* * *
* * *
* *
* * *
* * *

----------


* * *
* *
* * * * *
*
* * *

----------
*
* *
*
* * *
*
*
*

----------


* * *
* * *
* * *
* * *
*
* * *
----------
*
*
* * *
* * *
* *
* *
* *

----------

*

* *
*
*
* * *

----------

*

*
*
*
* *
* * *
----------
*
*
* *
* *
* *
* *
* *

----------
* *
*
*
*
*
*
* * *

----------


* * *
* * *
* * *
* * *
* * *

----------


* * *
* * *
* *
* *
* *

----------


* * *
* *
* *
* *
* * *

----------


* * * *
* *
* *
* * * *
*
*
----------


* * * *
* *
* *
* * * *
*
*
----------


* * *
* * *
*
*
*

----------


* * * *
*
* * *
*
* * * *

----------
*
*
* * *
*
*
* *
* *

----------


* *
* *
* *
* * *
* * *

----------


* *
* *
* *
* *
*

----------


* *
* * *
* * *
* *
* *

----------


* *
* *
*
* *
* *

----------


* *
* *
* *
* * * *
*
* * *
----------


* * * * *
*
*
*
* * * * *

----------
*
*
*
*
*
*
*

----------
*
*
*

*
*
*

----------
*
*
*
*
*
*
*

----------
*
* * *
*





----------






* * * * *

----------

I believe the archive also has a binary file that is the raw data for the font.

Neat.

SockMasters 2-way scrolling in BASIC

Hat tip to L. Curtis Boyle for pointing this one out to me. Published in The World of ’68 Micros back in 1995 was an article by John “SockMaster’ Kowalski demonstrating how to do smooth horizontal scrolling on the CoCo 3 in the 320×200 16-color graphics mode.

In BASIC.

With no assembly.

You can find this demo in Volume 2, Number 5 in an article called “The Seven-line demo: an amazing achievement with DECB!” I must have been fully into OS-9 by this point since this article does not seem familiar to me. I was not really keeping up with any BASIC stuff by that point, having moved to OS-9 assembly and C programming.

Here is that program as I typed it in and adjusted some spacing, with a few comments added by me. The only crucial part is line 70 which must have 11 colons and five spaces after that POKE Q,G line.

0 'The World of '68 Micros
1 'Volume 2, Issue 5
2 REM ** 2WAYSCRL.BAS
4 REM **bySockMaster
10 POKE 65497,0:HSCREEN 2:FOR G=0 TO 15:READ A:PALETTE G,A:NEXT
20 DATA 0,19,22,50,54,52,38,37,44,45,41,13,11,25,27,26
30 FOR G=0 TO 319 STEP .5:HSET(G,RND(191),RND(15)):NEXT
40 C=1:S=40:FOR G=15 TO 1 STEP-1:HCOLOR G
50 HCIRCLE(310-G*5,48),S:HPAINT(310-G*5,48):S=S-2.6:HLINE(RND(110)+210,RND(80)+104)-(RND(110)+210,RND(80)+104),PSET,BF:NEXT
60 Q=65439:W=0:E=127
65 '11 COLONS, 5 SPACES
70 FOR G=0 TO 127:PALETTE W,W:POKE Q,G::::::::::: POKE Q,E-G:NEXT:GOTO 70

I am unsure if the other spaces in line 70 are critical. The original listing looked like it had a lot of spaces between keywords and such, but that should not matter. LINE 70, being a loop, would be made a bit slower with extra spaces. Here is how it was presented in the magazine:

Here is what it does when ran in the XRoar emulator:

Spiffy!

Now I am off to read the full article to better understand how this works.

Vaughn Cato’s 3-D vector maze demo source code!

A special thanks to Vaughn Cato for allowing me to share the source code to his “toast” 3-D vector maze test program, as well as his “mapgraph” bitmap scaling test program.

I have placed all of the files on my GitHub site, including the two compiled executables (“toast” and “mapgraph”) as well as the source code he sent me and his last readme. The “toast.ar” file should be the file he sent me back in 1994 that includes all of these files.

You can find them here:

https://github.com/allenhuffman/Toast

Thanks, Vaughn!

And if you are curious to what Vaughn has been up to since 1994, he apparently continues to work with computers to make things appear on screen … Check out his Internet Movie Database entry:

https://www.imdb.com/name/nm1401781

…and be sure to look for his name when watching movies like Avatar and Lord of the Rings and such ;-)

Until next time…

Vaughn Cato’s bitmap scaling demo.

In a follow-up to my recent post about Vaughn Cato’s 3-D vector maze test for the Radio Shack Color Computer 3, there was another bit of code he sent me: a bitmap scaling test. He created a routine that would take a bitmap graphic then render it on the screen at a different width and/or height. I forget why I was interested in this topic back then, but I do know I have blogged about “scaling” on the CoCo in recent years on this site.

Here is a video of his mapgraph test program running:

The routine appears to use 6809 assembly language and C code. The idea would be you could have a bitmap image then place it on the screen at different sizes. This demo just loops “stretching” a test pattern image, but the graphic could have been anything.

One more post to come…

CLS 100 CoCo 3 easter egg explored.

The most famous CoCo easter egg has to be the hidden photo of the CoCo 3 programmers that shows up if you hold down CTRL-ALT while turning the machine on. (Alternatively, you can hold down CTRL-ALT and hit the reset button on the back of the machine to also display it.)

But, there’s another, which I’d bet came first, since it followed in the footsteps of a pre-existing easter egg that was in the original 1980 Color BASIC 1.0 ROM.

CLS 100

The CLS command is used to clear the screen. On the 32-column text screen, specifying a number from 0-8 will fill the screen with color blocks. That functionality was extended on the CoCo 3’s 40 and 80 column text screens, except there it could clear the screen to a true background color.

For the original CoCos, Microware included an easter egg in the CLS command. If you used a number greater than 8, instead of filling the screen with colored blocks it would display the word “MICROSOFT”.

CLS 9 through 255 present a Microsoft easter egg.

When Microware (not Microsoft) did the BASIC enhancements for the CoCo 3, they included a similar easter egg for the 40 and 80 column screens. If you did a CLS number outside of the range of 0-8, it would display “Microware Systems Corp.”

BUT, they added one special easter egg that you can only see once, then it disables itself (until the next power cycle or cold start). By typing CLS 100 you get to see the names of two of the programmers that worked on the project;

From that point on, if you type CLS 100 again you will only see the “Microware Systems Corp.” message.

In addition to making this easter egg a “one shot”, the programmers also took steps to hide their names so they would not be easily found by looking at the ROM code.

From Super Extended BASIC Unravelled, this note can be found in the memory map:

On startup, the ROMs are copied in to RAM, and these zero bytes will be in RAM at that range.

Then, during the CoCo 3 initialization code, there is a routine that copies the author names to that location. BUT, the data it copies is not the authors’ names — it’s an encoded version of the authors’ names:

Each of those bytes has its bits flipped. If the value in binary was 11110000, it would be encoded as 00001111. That effectively hides what those bytes represent from anyone just PEEKing around memory looking for text. There is a routine in the ROM that will start copying those bytes in to the other location, inverting the bits as it does so. It looks like this:

Here is the CLS code, which has special check for the value of 100 that will branch to a different routine:

The routine that is called when 100 is specified will display the easter egg and then wipe out the “Branch If Equal” instruction that calls it by replacing it with the NOP (no operation) instruction. Below is the code that does displays the egg and then disables it:

LF730 gets a pointer to the decoded author name message and displays it, then it starts in memory at F6F4 and stores a NOP byte there, and after it. That changes the two bytes the start out being “BEQ LF730” to “NOP NOP” effectively making the “CMP #100” useless since there is no longer an operation after it to make use of the results of that compare.

After those two bytes are changed to NOP, there is a loop that starts at memory location where AUTHORMS (F71B) is located and starts putting NOP bytes there until it gets to F74D. That destroys the evidence :) by wiping out everything in this table…

and everything after it (the code) up to the LF74D label:

Thus, after CLS 100, the code that would have jumped to the routine is gone, the routine it would have jumped to is gone, and the data that the now gone routine would have displayed is also gone.

Nice.

Here is a short BASIC program that will dump the hex values of the name bytes on up through the code that displays them, then prints the name bytes out as text.

0 ' COCO3NAMES.BAS
10 WIDTH 40
20 FOR L=&HF71B TO &HF74C
30 PRINT HEX$(PEEK(L));" ";
40 NEXT
50 PRINT
60 FOR L=&HF71B TO &HF72F
70 PRINT CHR$(PEEK(L));
80 NEXT

If you boot a CoCo 3 and run this program, you will see it contains the bytes for the name text and the 6809 code:

Then if you type CLS 100 and run the program again you will see that those bytes are now all the NOP byte (&H12). Since this is not a printable character, nothing is printed after the hex values:

And that is more than we probably ever wanted to know about how the CLS 100 CoCo 3 Easter Egg works.

So let’s do a bit more…

Restoring (and customizing) the egg

Just for fun, I wrote this short BASIC program that does three things:

  1. Restore the easter egg text to the memory from &HF71B-&HF72F.
  2. Restore the display routine at &HF730 that prints the easter egg text and then deletes the easter egg text and the routine.
  3. Restore the “branch if equal” that is supposed to happen after comparing the value of CLS to be 100.

And, as an added bonus, there is a line that will insert a “return from subroutine” RTS instruction in the display routine so it will not run the code that wipes out the easter egg text and display routine.

If you have already done a CLS 100, this code would restore the easter egg and let you run it again:

10 ' COCO3EGG.BAS
20 WIDTH 40
30 ' RESTORE EGG TEXT
40 EG$="T.Harris & T.Earles"
50 ' ROOM FOR UP TO 19 CHARS
60 LN=LEN(EG$)
70 IF LN>19 THEN LN=19
80 ' STORE THE EGG TEXT
90 FOR I=0 TO LN-1
100 POKE &HF71B+I,ASC(MID$(EG$,I+1))
110 NEXT
120 ' ADD CR and 0 BYTES
130 POKE &HF71B+I,13
140 POKE &HF71B+I+1,0
150 ' RESTORE DISPLAY ROUTINE
160 FOR L=&HF730 TO &HF756
170 READ V$:POKE L,VAL("&H"+V$)
180 NEXT
190 ' RESTORE CMP #100 "BEQ"
200 POKE &HF6F4,&H27:POKE &HF6F5,&H3A
210 ' DISABLE EGG KILL (RTS)
220 'POKE &HF73D,57
230 END
240 ' DISPLAY ROUTINE DATA
250 DATA 8D,40
260 DATA 17,FF,57
270 DATA 8D,41
280 DATA 8E,F7,1A
290 DATA BD,B9,9C
300 DATA 34,10
310 DATA 30,8D,FF,B1
320 DATA 86,12
330 DATA A7,80
340 DATA A7,84
350 DATA 30,8D,FF,CE
360 DATA A7,80
370 DATA 8C,F7,4D
380 DATA 25,F9
390 DATA 35,10
400 DATA 39

The DATA statements are organized like that to match the bytes shown in the Unravelled book’s listing of this routine. This helped me find and fix typos.

Line 220 is commented out, but that would place an RTS after the “JSR STRINOUT” in the LF730 display routine, causing it to return rather than do all the code that replaces stuff with the NOP bytes.

And, as an added bonus on top of the added bonus, you can change the easter egg string in line 40 to be anything you want, provided it is 19 characters or less. (Anything longer will just be cropped to the first 19 characters.) I changed mine to read “Sub-Etha Software” and had that message as my CLS 100 easter egg.

Until next time…

How to crash a CoCo 3 – more accurately.

Recently, I shared this way to crash a CoCo 3 in three easy steps:

  1. Turn it on.
  2. Type in “CLEAR 16500:WIDTH 40”
  3. There is no step three.

I expected to do a follow-up once I had time to look at the Super Extended Color BASIC Unraveled book and try to figure out what was causing this crash. I also planned to figure out what value triggered the first crash. I discovered this in a program that did a “CLEAR 17000” and I just went up and down trying to find a threshold where it crashed, and gave up at 16500.

But I am lazy.

And sometimes dense. It didn’t dawn on me that I might have been able to have the computer try to figure out when it crashed. But it did to Juan Castro. In the comments, Juan wrote:

First thing I thought was to increase the value of CLEAR in a loop to see exactly when it crashes… oops, you can’t, you nuked your loop counter with the CLEAR.

No problem, let’s use fixed memory for the counter. &H400, the start of the (now unused) text screen. We’ll start with 16000 (=&H3E80) and increment by one.

10 WIDTH 40
20 POKE &H400,&H3E:POKE &H401,&H80
30 GOSUB 80
40 AD=AD+1
50 GOSUB 90
60 PRINT AD:CLEAR AD
70 GOTO 30
80 AD=PEEK(&H400)*256+PEEK(&H401):RETURN
90 HI=INT(AD/256)
100 LO=AD-256
HI
110 POKE &H400,HI:POKE &H401,LO
120 RETURN

It locks up at 16356 — suspiciously close to 16384. Only 28 bytes off. That’s probably close to how much the stack occupies. (Modulo some buffer headers, variable descriptors, and maybe some non-fatal stack corruption.)

– Juan Castro

Brilliant!

And I bet once we dig in (I believe William Astle has done this work in the past) we will find that location is where an 8K MMU block gets mapped in/out for manipulating the high res text screens. Or some other words to that affect that I do not know how to properly articulate.

More to come on this…

How to crash a CoCo 3

From a fresh boot…

CLEAR 16500
WIDTH 40

I have been going through all my OS-9 hard drive images trying to get everything compiled into one place. During this project I ran across a folder called DECB (Disk Extended Color BASIC). It contained the following files:

colours.BAS
contents.txt
DEL.BAK
del.BAS
microwar.txt
new.BAS
reader
copy.asc
reader.asc
reader.BAS
subs.BAS
TEST.DEL
TEST.TXT

I had no recollection of what this was, nor why filenames were in lowercase. That was not normally how files were done from Disk BASIC on a CoCo due to the 32-column screen showing lowercase as inverted video.

The “microwar.txt” was an e-mail response to an inquiry I made to Microware in 1993 about the history of OS-9:

INTERNET# Document Id: UX00f.BUX0039573

Item 6352278 93/08/24 06:03

From: STEVES@MICROWARE.COM@INTERNET# Internet Gateway II

To: COCO-SYSOP Allen C. Huffman

Sub: Re: The History of OS-9

From mcrware!microware.com!steves@uunet.UU.NET Tue Aug 24 17:24:36 1993
Received: from relay1.UU.NET by relay2.geis.com with SMTP
(1.37.109.4
/15.6) id AA23578; Tue, 24 Aug 93 17:24:36 +0100
Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP
(5T.61/UUNET-internet-primary) id AA11760; Tue, 24 Aug 93 12:24:35 -0400
Received: from mcrware.UUCP by uucp2.uu.net with UUCP/RMAIL
(queuweing-rmail) id 122237.10246; Tue, 24 Aug 1993 12:22:37 EDT
Received: from yme by microware.com with SMTP id AA00775
(5.67a8/IDA-1.5 for <coco-sysop@genie.geis.com>); Tue, 24 Aug 1993 10:03:08
-0500
From: Steve Simpson <steves@microware.com>
Received: by yme id <AA00684@yme>; Tue, 24 Aug 93 10:03:04 CDT
Date: Tue, 24 Aug 93 10:03:04 CDT
Message-Id: <9308241503.AA00684@yme>
To: coco-sysop@genie.geis.com
Subject: Re: The History of OS-9

The “Steve” there was Steve “Homer” Simpson, who I would later know when I went to work for Microware two years later. He provide me with a Microware history article, and a Ken Kaplan interview about Microware’s first 15 years. (Note to self: Get this archived somewhere.)

The “TEST.TXT” file was a 300 line text file, obviously created by a program, that was just this:

This is a file of 300 lines or so, and this is line number * 0*...
This is a file of 300 lines or so, and this is line number * 1*...
This is a file of 300 lines or so, and this is line number * 2*...
...snip...
This is a file of 300 lines or so, and this is line number * 298*...
This is a file of 300 lines or so, and this is line number * 299*...
This is a file of 300 lines or so, and this is line number * 300*...

I was a bit confused at the purpose of these two files. Fortunately, “contents.txt” cleared things up a bit.

Jan  '95  #01
Demonstration Issue
1. All About This Program
Allen C. Huffman
INFO

2. REALLY *BIG* FILE
Bob's Big Boy
TEST

3. Microware Information
Microware Staff
MICROWAR

4. Stuff For Sale
Various
FORSALE

5. Useless File
Bob
USELESS

6. Nothing
Dan
NOTHING

7. Something
Bob & Dan
SOMETHIN

8. Movie Reviews
Sis Kehl
MOVIES

9. Spam Recipes
Mr. Cook
SPAMSPAM

F. Another File
Another Writer
ANOTHER

G. Nothin'
Nobody
NOTHING

H. Nothin' Again
Nobody Again
NOTHING

I. More About Flies
Spider-Man
FLYFILE

J. Jump Text
Jumpman Bob
JUMPTEXT

K. KeepThisSecret
Spy
SPYFILE

*. Use Star for This
StarMan
STAR

Seeing my name in there let me know that this was indeed something I was involved in. But what was it? I needed to move those BAS files over to an emulator and take a look.

Fortunately, one of them was already in ASCII – “reader.asc” – and it was indeed a BASIC program that apparently I wrote back in 1995.

0 REM *
1 REM * Text Viewing Program Thingy V1.00 by Allen C. Huffman
2 REM * Copyright (C) 1995 by Sub-Etha Software
3 REM * Written for Terry Simons and the MI&CC Upgrade Diskletter
4 REM *
5 PALETTE0,0:PALETTE8,63:WIDTH80:CLS1

I had zero recollection of writing this, but I remember the Mid-Iowa & Country CoCo Club (MI&CC) and its organizer, Terry Simons. Sub-Etha Software attended their Middle America Fest held in Des Moines in 1993. Somewhere, I am pretty sure I have photos from this even, but they are not in my online CoCoFest photo gallery for some reason.

I could tell this was something I wrote, since that line 5 of doing the background black, foreground white, width 80, CLS1 line was how I started all my CoCo 3 BASIC programs.

A quick scan of this program, which I will include in full, reveals it would read the “contents.txt” file and display a directory of text files (articles) on the disk and let the user select one. It would then load the file and let them read it, with options to go page to page through the file. A text file reader with a menu system – neat!

0 REM *
1 REM * Text Viewing Program Thingy V1.00 by Allen C. Huffman
2 REM * Copyright (C) 1995 by Sub-Etha Software
3 REM * Written for Terry Simons and the MI&CC Upgrade Diskletter
4 REM *
5 PALETTE0,0:PALETTE8,63:WIDTH80:CLS1
10 CLEAR17000:DIMFL$(15,3),A$(200)
50 REM * Read Index File
55 OPEN"I",#1,"contents.txt":LINEINPUT#1,IS$:LINEINPUT#1,SB$:FL=0
60 FORA=0TO3:LINEINPUT#1,FL$(FL,A):NEXT:IFEOF(1)=0THENFL=FL+1:IFFL<30THEN60
65 CLOSE
100 REM * Table of Contents
105 CLS:LOCATE28,0:PRINT"Mid Iowa & Country CoCo":LOCATE40-LEN(IS$)/2,1:PRINTIS$;:LOCATE0,3:ATTR0,7:PRINT:ATTR0,0:LOCATE0,22:ATTR0,7:PRINT:ATTR0,0
110 GOSUB1155:LOCATE35,2:PRINT"Main Menu";:GOSUB1130:LOCATE23,23:PRINT"Select File to View or [Q] to Quit";
115 FORA=0TOFL:LOCATE40*ABS(A>7)+5,(A AND7)*2+5:PRINTFL$(A,0):LOCATE40*ABS(A>7)+23,(A AND7)*2+6:PRINTFL$(A,1):NEXT
120 GOSUB1055:A=0:IFA$="Q"THEN450
125 IFA$=LEFT$(FL$(A,0),1)THENFL$=FL$(A,2):A$=FL$(A,0)+" by "+FL$(A,1):GOTO205ELSEA=A+1:IFA<16THEN125
130 SOUND100,1:GOTO120
200 REM * View a File (FL$)
205 LOCATE40-LEN(A$)/2,2:PRINTA$;:GOSUB1130:LOCATE2,23:PRINT"[UP] Next Page  [DN] Prev Page  [J]ump to Page  [P]rint File  [Q]uit to Menu";:LN=0:
210 GOSUB1105:ONERR GOTO245:OPEN"I",#1,FL$+".TXT":ONERR GOTO
215 LOCATE32,13:ATTR0,0,B:PRINT"Loading File ...":ATTR0,0:MX=0
220 IFEOF(1)=0THENLINEINPUT#1,A$:A$(MX)=LEFT$(A$,65):MX=MX+1:IFMX<200THEN220
225 CLOSE:LOCATE68,2:PRINT"Lines:";MX;:LN=0:LOCATE0,12:PRINT
230 LOCATE0,2:PRINT"Page"INT(LN/18)+1"of"INT(MX/18)+1"  ";:FORA=0TO17:LOCATE8,A+4:IFLN+A<MX THENPRINTA$(LN+A)ELSEPRINT
235 NEXT
240 GOSUB1055:A=INSTR(CHR$(94)+CHR$(10)+"JPQ",A$):IFA<1ORA>5THENSOUND100,1:GOTO240 ELSEONA GOTO255,305,355,405,430
245 FORA=12TO14:LOCATE15,A:PRINT"* File Not Found - Press Any Key for Main Menu *":NEXT:GOSUB1055:GOSUB1105:GOTO110
250 REM * [UP] Next Page
255 IFLN+18<MX THENLN=LN+18
260 GOTO230
300 REM * [DN] Prev Page
305 IFLN-18=>0THENLN=LN-18
310 GOTO230
350 REM * [J]ump to Page
355 LOCATE0,11:PRINT:PRINT:PRINT:LOCATE29,12:PRINT"Jump to Page 1 -"INT(MX/18)+1":";:GOSUB1005:A=VAL(A$)-1:IFA<0ORA>INT(MX/18)THENSOUND100,1:GOTO230ELSELN=A*18:GOTO230
360 IFPG>1THENPG=PG-1
365 GOTO230
400 REM * [P]rint Article
405 LOCATE0,11:PRINT:PRINT:PRINT:LOCATE13,12:PRINT"Ready Printer.  Press [ENTER] to Print or [Q] to Quit";
410 GOSUB1055:IFA$="Q"THEN230ELSEIFA$=CHR$(13)THEN415ELSESOUND100,1:GOTO410
415 REM --- if printer is not online, beep and go back to 201... <- check here
420 A=0
425 PRINT#-2,TAB(8)A$(A):A=A+1:IFA<MX THEN425ELSE230
430 GOTO110
450 REM * Quit
455 CLOSE:CLS:STOP
460 END
1000 REM * Line Input
1005 LINEINPUTA$:RETURN
1050 REM * Inkey$
1055 A$=INKEY$:IFA$=""THEN1055
1060 CH=ASC(A$):IFCH>95THENA$=CHR$(CH-32)
1065 RETURN
1100 REM * Clear Text Area
1105 FORA=4TO21:LOCATE0,A:PRINT:NEXT:RETURN
1125 REM * Clear Bottom Line
1130 LOCATE0,23:PRINTSTRING$(79,32);:RETURN
1150 REM * Clear Top Line (well, third one actually...)
1155 LOCATE0,2:PRINTSTRING$(79,32);:RETURN

I used the Toolshed (new GitHub home) decb command line tool to create a blank 32-track DSK image, and then then copy the “reader.BAS” file over to it. I also copied the “contents.txt” file, since that was needed.

I booted up the Xroar emulator, mounted my new disk image, and loaded the program. When I ran it, it went to a black screen momentarily, then I saw this:

I assumed the file might be corrupted, so I then tried to CLOAD the ASCII file in Xroar. That is a neat feature that lets you “Load” a text file, then when you type CLOAD it simulates loading an ASCII file form tape, using the input text file as that ASCII file.

Same problem.

I visually inspected the program. Maybe there was some EXEC to an assembly routine that needed to loaded before RUNing this BASIC.

Nothing.

Was Xroar defective? I went to the Xroar Online Emulator and tried it there, loading my DSK image through the web page.

Crash.

I then posted to the CoCo e-mail list sharing a Dropbox link to a folder containing these files, as well as the DSK image. I asked if anyone could test it and see if it crashed for them, as well. Michael Kline was the first to respond:

Alan,

I tested all BASIC programmes on a CC3. They all lock up.

Michael

This at least let me know it was not an Xroar-specific issue. But what was this issue?

I experimented with the TRON command to see how far the program would get before locking up. It would print some quick values [0][1][2][3][4][5] before the screen cleared and things crashed, but this time to a blank green screen. The output to the 32-column screen was changing behavior.

I commented out line 5 so it would stay on the 32 column screen, and ran it again. I saw it spew out line numbers, before clearing the screen and printing an “?HP ERROR IN 105”. That is the error you get when you do CoCo 3 40/80 column screen commands on the 32 column screen. From the looks of things, removing the WIDTH80 line allowed it to get to around line 60 or so before one of those commands was used and it errored out.

Why would WIDTH 80 crash a program? I did more experiments. After this error, with the system not locked up, I typed “5 WIDTH 40” just to add a screen width, but no PALLETEs or CLS command.

According to TRON, the program was crashing at WIDTH 40… Huh???

Each time a crash like this happened, the virtual CoCo had to be restarted (power cycle). Just a virtual reset would not work. You might get “OK” back but things were not working.

Very, very odd.

I finally got my program to run by changing the value of the CLEAR command in line 10. (Initially, I deleted the whole line after the WIDTH line just to see what happened, and narrowed it down to something to do with the CLEAR.)

I shared my results on the CoCo list, and William “Lost Wizard” Astle, one of the great minds at understanding how the BASIC ROMs operate, replied with this tidbit:

It won’t be a string space bug – handling that didn’t change in the Coco3.

Have you been running it from the 40 or 80 column screen? If so, that’s probably why. The driver for handling output to the 40/80 column screen doesn’t properly manage the memory map and if the stack ends up too low in memory, it gets swapped out while the 40/80 column screen is mapped in, leading to a system crash. String space and the address parameter to CLEAR are both above the stack.

This crash happens if the stack ends up below $4000 if memory serves.

If you aren’t running from the 40/80 column screen, it may be some other weirdness triggering it.

– William Astle, via the CoCo List

Light has been shedded, and I knew all I would have to do is look up the Super Color BASIC Unraveled book to find a clear and concise explanation of this bug. But, before I got there, William added more details:

The only solution as far as I can tell is do no output on the 40/80 column screen or clear less string space. Given that a lot of the numbers used for CLEAR for string space are effectively random with no real understanding of how big they need to be, it’s entirely possible that 17000 is way more than it needs to be. Something most programmers don’t know is that a string constant in the program that is never modified doesn’t use up any string space so often the CLEAR number is massively larger than it needs to be.

Having the WIDTH before the CLEAR should prevent WIDTH from crashing but any subsequent PRINT, LOCATE, INPUT (from keyboard), or HSTAT probably would crash.

– William Astle, via the CoCo List

My confusion continued, and finally a third response form him added this:

It’s not that straight forward and unravelled doesn’t mention it. I only know because I tripped on it hard back in “the day” and it left me scratching my head for quite a while.

Basically, the stack has to stay above $4000 (the screen gets mapped in the $2000 to $3FFF range) so that would probably put the absolute limit somewhere just under 16K (16384). You’d want 200 bytes or so room for the stack so 16000 would be a nice round number. On the other hand, if you reserve any memory with the second parameter for CLEAR, that number goes down.

Perversely, if you could get the stack to be *below* $2000, it would also not crash, but that means a very small program with no PMODE graphics, probably.

The size of scalar variables, arrays, or program text doesn’t actually matter for this calculation because the screen is not mapped in except when doing I/O on the screen.

– William Astle, via the CoCo List

A bug the Unraveled folks didn’t know about? William stumbled upon it back then, and if this code was a version I tried to run, I must have, as well. But, why would I have left it in this non-working version? I expect I may find a “fixed” version of this program in my Disk BASIC disk archives, eventually. For all I know, maybe I kept this one around as a “what is wrong with this program” example, copying it to my OS-9 hard drive so I could post it on a BBS or online service (or even to the original CoCo List back then).

Hmm, I wonder if the old Princeton CoCo list archives still exist. Maybe I posted about this 30 years ago (1995!) when I was writing this program? (Note to self: Look that up…)

But I digress.

If you CLEAR a big enough number, then do a WIDTH 40 or 80, the CoCo 3 crashes hard. I toyed with that value, and you can get to a spot where it works, then a bit higher and you get some different types of crashes with the screen freaking out in different ways, but all end up the same way: crashed CoCo, must hard-reset/power cycle to recover.

Have you ever run into this bug on your CoCo 3? Please leave a comment with your story…

Until next time…

One more thing…

Oh yeah… Here is what the program looks like when it runs.

CoCo 3 BASIC and ON ERR GOTO and negative line numbers

Juan Castro strikes again, this time providing a short program for me to try on a CoCo 3 (I used the Xroar Online emulator) that shows another quirk in the handling of 16-bit values on the CoCo.

The reason this requires a CoCo 3 is because it makes use of the ONERR GOTO command that was added for Super Extended Color BASIC.

I recall using these back in my CoCo 3 days. On page 227 of the Color Computer Computer 3 manual is this description:

ON ERR GOTO line number

“Goes to the line number if an error occurs during program execution.”

There are two special variables that get set when an error is trapped by “ON ERR”.

ERNO

“Returns an error number that corresponds to the error that occurred.”

ERLIN

“Returns the line number where the error occurred.”

So in this simple program, with a mis-spelled “PRINT” command…

10 ON ERR GOTO 50000
20 PRUNT "I TYPE POORLY"
30 END
50000 PRINT "ERROR";ERNO;"IN LINE";ERLIN

When I run that, I see:

ERROR 1 IN LINE 20

1 must be the value of ?SN ERROR. The manual says to look for “BASIC Error Messages” in the back of this book, but the page is titled ERROR CODES. It is on page 321. It lists errors 1 to 39.

But that is not important for this post.

ERLIN, which you see reported the error was in line 20, has a problem.

If the line number with the error has the high bit set (higher than 32767), it gets reported as a negative number! Changing the program to make the PRUNT typo happen on a later line shows this:

10 ON ERR GOTO 50000
32768 PRUNT "I TYPE POORLY"
32769 END
50000 PRINT "ERROR";ERNO;"IN LINE";ERLIN

If I run this version, I see:

ERROR 1 IN LINE-32768

If the error line is moved to 32767, you will it it report properly.

The book Super Extended BASIC Unraveled II mentions this bug on page 33:

“The ERLIN function will return a negative number if the line number in which the error occurred is greater than 32767. This is caused by the fact that the ERLIN function returns the line number as a two-byte integer instead of a floating point number, as it should.”

– Super Extended BASIC Unraveled II, page 33

I did not know there was a 2-byte integer routine in the ROMs. Always learning something new! (Or, re-learning in case I actually did learn this decades ago.)

Thanks, Juan, for getting my dusty brain thinking.

Until next time…

Steve Bjork’s Zaxxon, but updated for CoCo 3?

Roger Taylor continues to make discoveries…

https://www.patreon.com/posts/100701156?utm_campaign=postshare_fan

SPECULATIVE UPDATE: Zaxxon ran on the PMODE 4 2-color screen, and used artifact colors. Those did not display on the CoCo 3’s RGB CM-8 monitor. Perhaps this was just a way to make a CM-8 compatible version of the game? Though, changing the title screen and adding the logo (as well as updating the font) does make it appear it was more than just that.

Unreleased CoCo 3 update to the 1983 CoCo Zaxxon???

Super Pitfall … 2???

After the passing of Steve Bjork, his personal possessions ended up in an estate sale. Among them were some fantastic Disney collectables (Steve worked at Disneyland in the 1970s), and a bunch of CoCo stuff.

After the estate sale, much of this ended up at an auction. Roger Taylor spent over $6700 to acquire and preserve a huge bundle of Steve Bjork diskettes and source code printouts. To support him in this endeavor, I am now backing Roger’s Patreon with a $50/month “hardcore supporter” level. If you would like to help out, consider chipping in, even at a $5/month level, to help offset these investments.

Yesterday, Roger shared some photos of the source code printouts that had been kept in a storage box:

https://www.patreon.com/posts/here-we-go-100273449

There are listings from pre-CoCo TRS-80 Model I/III software, as well as highly recognizable CoCo programs such as Clowns & Balloons, Mega-Bug, Micro Painter, Rampage, Bash as well as something called Marty Goodman Game which was written in 30 days. This would be released as Marty’s Nightmare for the 1990 Atlanta CoCoFest (the first time I ever met Steve in person).

One of the more curious things in the printout collection is a listing for Super Pitfall 2, which does not exist. It seems Super Pitfall was only released for the original Nintendo Entertainment System (NES), the Color Computer 3, and a Japanese machine called a PC-88. The Wikipedia page has this comment:

Activision initially was going distribute Sunsoft‘s Atlantis no Nazo in the United States in a rebranded form as a sequel to Super Pitfall on the Super Nintendo Entertainment System. This release did not happen.

https://en.wikipedia.org/wiki/Super_Pitfall

YouTube does have a few videos of a game called Super Pitfall 2, described as a prototype and unreleased:

If this Atlantis no Nazo game, which was only released in Japan, was going to be converted to be Super Pitfall 2 for the USA audience, was Activision also going to have a CoCo 3 version done? This seems unlikely, but the source code clearly says “Super Pitfall 2” and also has that text on its title screen! It also shows that Steve worked on this game from 11/11/1987 to 4/6/1988.

Super Pitfall 2 source code listing, from the collection of Roger Taylor.

I do have a theory. Mine Rescue was a game very similar to Super Pitfall that Steve released in 1989. I cannot find the game in the Color Computer Archive (most likely since Steve was still active in the CoCo community and protecting his copyright), but the manual is there:

https://colorcomputerarchive.com/repo/Documents/Manuals/Games/Mine%20Rescue%20(SRB%20Software).pdf

It was very similar to Super Pitfall. (photos from L. Curtis Boyle’s site)

This was much like Steve’s game Bash was very similar to Arkanoid. (photos from L. Curtis Boyle’s site)

Steve had a library of routines he would use in various games. You could see how the scrolling perspective of his port of Zaxxon might have been re-used for one of the levels in his Ghana Bwana game (photos from L. Curtis Boyle’s site):

I am wondering if this “Super Pitfall 2” might have been the code that was later released as Mine Rescue. But, at the moment in time that printout was noted with “4/6/88”, both the source code and the embedded text for the title screen read “Super Pitfall 2”.

I am looking forward to following Roger Taylor’s exploration of this archive of Steve Bjork material. I wonder what other things will be discovered…

Until then, stop by Roger’s Patreon and please consider supporting him at whatever level you can justify.