Atari VCS Pac-Man

I remember the excitement surrounding Pac-Man being released for the Atari VCS (the machine later renamed to the 2600). I was in junior high school and living in Houston, Texas at the time. I recall full page newspaper ads for this cartridge.

I had played Pac-Man in the arcades a few times, but I was not good at it and therefore it was not one of my favorite games to spend a quarter on. A quarter in 1980 would be about $1 today, according to a U.S. government inflation calculator. (And yowza to that. When the Up-Down bar-arcade opened in Des Moines, Iowa about ten years ago, the inflation rate made that quarter worth about .72 then.)

No wonder my grandmother wasn’t keen on me spending money at arcades ;-)

The Pac-Man conversion was very different from the arcade original. Some of the changes made to the game were due to limitations of the hardware — such as the “dots” being replaced by “video wafers” (so said the manual) that looked like dashes. The power pills were squares. This is understandable, though future Atari ports of Pac-Man games such as Ms. Pac-Man and Jr. Pac-Man looked much better, thanks to using twice as much cartridge ROM as the original Atari Pac-Man.

However, other changes to the game — such as playing a tune that was NOT the Pac-Man tune, and having the tunnels at the top and bottom of the screen rather than the sides, along with a maze that did not at all resemble the arcade original, seemed … just wrong. It was “Pac-Man in name only.”

It dawns on me that many of this “in name only” ports were more “inspired by”– new games using elements inspired by the original. This is much like how movies based on books are made–changing the plot so much it is barely recognizable except for some character names and general concepts.

The more movies I see that are quite different than their source material, the more I understand the 1982 Atari Pac-Man.

After all, we have seen modern programmers use the same 4K ROM size and create a much more faithful Pac-man (see video below) though I do not know if they could have written this in the same time constraints the Atari programmer had to do his version in…

For an interesting history on the original Atari Pac-Man, check out this video:

Until next time…

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.

Let’s write Lights Out in BASIC – part 7

See also: part 1, part 2, part 3, part 4, part 5, part 6 and part 7.

Code cleanup in aisle 4.

Let me begin this installment by presenting the current Lights Out code with some renumbering done and a few minor improvements.

0 REM LITESOUT-P7.BAS

10 REM SETUP
20 DIM L(9,9)

100 REM START NEW GAME
110 GOSUB 5000
120 REM INITIALIZE GRID
130 MV=0
140 GOSUB 4000
150 REM SHOW GRID
160 GOSUB 1000
170 REM CHECK FOR WIN
180 IF LO=0 THEN 300
190 REM INPUT SQUARE
200 GOSUB 2000
210 REM TOGGLE SQUARES
220 GOSUB 3000
230 REM REPEAT
240 MV=MV+1
250 GOTO 150

300 REM GAME WON
310 PRINT "YOU WON IN";MV;"MOVES."
320 INPUT "PLAY AGAIN (Y/N)";Q$
330 IF Q$="Y" THEN 100
340 PRINT "GAME OVER"
350 END

1000 REM SHOW GRID
1010 PRINT "GAME NUMBER:";GN
1020 PRINT " ";
1030 FOR A=1 TO GS
1040 PRINT RIGHT$(STR$(A),2);
1050 NEXT:PRINT
1060 FOR Y=0 TO GS-1
1070 PRINT RIGHT$(STR$(Y+1),2);" ";
1080 FOR X=0 TO GS-1
1090 IF L(X,Y) THEN PRINT "X ";:GOTO 1110
1100 PRINT ". ";
1110 NEXT
1120 PRINT
1130 NEXT
1140 PRINT "MOVES:";MV;"LIGHTS ON:";LO
1150 RETURN

2000 REM INPUT SQUARE
2010 S$=MID$(STR$(GS),2):PRINT "X,Y (1-";S$;",1-";S$;" OR 0,0)";
2020 INPUT X,Y
2030 IF X=0 THEN IF Y=0 THEN 320
2040 IF X<1 OR X>GS OR Y<1 OR Y>GS THEN 2010
2050 X=X-1:Y=Y-1
2060 RETURN

3000 REM TOGGLE SQUARES
3010 L(X,Y)=NOT L(X,Y):LO=LO-(L(X,Y)*2+1)
3020 IF X>0 THEN L(X-1,Y)=NOT L(X-1,Y):LO=LO-(L(X-1,Y)*2+1)
3030 IF X<GS-1 THEN L(X+1,Y)=NOT L(X+1,Y):LO=LO-(L(X+1,Y)*2+1)
3040 IF Y>0 THEN L(X,Y-1)=NOT L(X,Y-1):LO=LO-(L(X,Y-1)*2+1)
3050 IF Y<GS-1 THEN L(X,Y+1)=NOT L(X,Y+1):LO=LO-(L(X,Y+1)*2+1)
3060 RETURN

4000 REM INITIALIZE GRID
4010 INPUT "GRID SIZE (3-10, ENTER=5)";GS
4020 IF GS=0 THEN GS=5
4030 IF GS<3 OR GS>10 THEN 4010
4040 PRINT "INITIALIZING..."
4050 FOR A=1 TO 10*GS
4060 Y=RND(GS)-1
4070 X=RND(GS)-1
4080 GOSUB 3000
4090 NEXT
4100 RETURN

5000 REM SELECT GAME
5010 PRINT "PLAY SPECIFIC GAME # (Y/N)?"
5020 S=S+1:A$=INKEY$:IF A$="" THEN 5020
5030 IF A$="Y" THEN 5070
5040 IF A$="N" THEN A=RND(-S)
5050 GN=RND(65535):A=RND(-GN)
5060 GOTO 5100
5070 INPUT "PLAY GAME (1-65535)";GN
5080 IF GN<1 OR GN>65535 THEN 5060
5090 A=RND(-GN)
5100 RETURN

As I tested this version, I noticed my random grid generator was not very good–at least on a large 10×10 grid. It really needed to do more random light toggling for larger grids. This change would go in this line – maybe just doing a “grid size * X”, like “10*GS” or something. I am still trying things, but for now I made it do more random toggles the larger the grid size is (line 4050).

I also made it so the default grid size was 5 (line 4010).

And I fixed some output where it printed a numeric variable. In Color BASIC, there is an extra space printed before and after printing a number:

PRINT "*";42;"*"
* 42 *

And, technically, it’s not a space before a number — it’s a place for the sign (none if positive, “-” if negative):

PRINT "*";-42;"*"
*-42 *

Since I knew I was only printing a positive number, I just got rid of that leading space, and the one after it. I did this by converting the number to a string using STR$. That will convert it to a string with the first space (a place for the sign) but no space after it:

PRINT "*";STR$(42);"*"
* 42*

Then all I needed to do was trim off that leading space. In the old days, I would have done this by getting the length of the string using LEN$ and then using RIGHT$ to get just the character(s) after that leading space:

N=42
N$=STR$(N)
L=LEN(N$)
PRINT RIGHT$(N$,L-1)

But in recent years, someone commented on this site (I believe) about how you could use MID$ without a size and just specify the starting position in a string, and it would return everything from that position to the end:

N=42
PRINT MID$(STR$(N),2)

Nice! “Wish I knew then what I know now…”

But I digress…

We now have a fairly “feature complete” version of Lights Out that runs in very basic BASIC — it doesn’t even make use of ELSE.

Before I move on to making this look a lot nicer on a CoCo, I thought it might be fun to port it to a VIC-20. I made use of the wonderful CBM prg Studio Windows-based tool that can build BASIC or assembly programs for all kinds of Commodore machines. I just pasted in my source, and then found a few minor things I would need to change to run on the VIC-20’s CBM BASIC.

The first thing I did after pasting the code in to the editor was to convert it all to lowercase. That seems to be how that BASIC works, as SHIFT characters turn in to PETSCII graphics characters.

Now I would be able to build the program.

It would build right away, but not run on the VIC yet until I fix two things that are different between Color BASIC and CBM BASIC:

  • A$=INKEY$ must be changed to GET A$
  • RND(x) must be changed to INT(RND(1)*X)-1 (Doing the random seed using RND(-X) works the same way on the VIC, and could be left alone.)
CoCo:
5020 S=S+1:A$=INKEY$:IF A$="" THEN 5020

VIC:
5020 S=S+1:GET A$:IF A$="" THEN 5020

CoCo:
4060 Y=RND(GS)-1

VIC:
4060 Y=INT(RND(1)*GS)

CoCo:
4070 X=RND(GS)-1

VIC:
4070 X=INT(RND(1)*GS)

After that, I tried to RUN it and ran in to a problem with INPUT:

From testing, it seems that long prompts on INPUT cause issues, possibly related to how the VIC’s full screen editor works. I sent a tweet to 8-Bit Show and Tell to see what he knew, and did a simple workaround by breaking up the prompt and the input on separate screen lines:

4000 rem initialize grid
4010 print "grid size (3-10, enter=5)":input gs

I thought I might have the same issue with the “select square” input, but that prompt does not overlap to the next line so it worked… or so I thought. With the default grid size of 5×5, the prompt looked like:

X,Y (0-5,0-5 OR 0,0)?(space)
*(cursor here)

That seemed to work just fine, but when I did a grid of 10×10, it made the prompt longer, wrapping the “?” of INPUT to the next line:

X,Y (0-10,0-10 OR 0,0)
? *(cursor here)

So I needed to fix that, too. I had already had to break that one up in to a PRINT and an INPUT since I was printing variables in the prompt, so I just took the semicolon off from the end of the PRINT:

2000 rem input square
2010 s$=mid$(str$(gs),2):print "x,y (1-";s$;",1-";s$;" or 0,0)"
2020 input x,y

Now I had what appeared to be a working version of the game for VIC-20. BUT, it would need some work to reformat the prompts to fit on a 22-column screen, versus the 32- column CoCo screen. For anyone who wants to work on that, here is the VIC-20 version with the lines in bold that have changes from the CoCo version:

0 rem litesout-p7.bas

10 rem setup
20 dim l(9,9)

100 rem start new game
110 gosub 5000
120 rem initialize grid
130 mv=0
140 gosub 4000
150 rem show grid
160 gosub 1000
170 rem check for win
180 if lo=0 then 300
190 rem input square
200 gosub 2000
210 rem toggle squares
220 gosub 3000
230 rem repeat
240 mv=mv+1
250 goto 150

300 rem game won
310 print "you won in";mv;"moves."
320 input "play again (y/n)";q$
330 if q$="y" then 100
340 print "game over"
350 end

1000 rem show grid
1010 print "game number:";gn
1020 print " ";
1030 for a=1 to gs
1040 print right$(str$(a),2);
1050 next:print
1060 for y=0 to gs-1
1070 print right$(str$(y+1),2);" ";
1080 for x=0 to gs-1
1090 if l(x,y) then print "x ";:goto 1110
1100 print ". ";
1110 next
1120 print
1130 next
1140 print "moves:";mv;"lights on:";lo
1150 return

2000 rem input square
2010 s$=mid$(str$(gs),2):print "x,y (1-";s$;",1-";s$;" or 0,0)"
2020 input x,y
2030 if x=0 then if y=0 then 320
2040 if x<1 or x>gs or y<1 or y>gs then 2010
2050 x=x-1:y=y-1
2060 return

3000 rem toggle squares
3010 l(x,y)=not l(x,y):lo=lo-(l(x,y)*2+1)
3020 if x>0 then l(x-1,y)=not l(x-1,y):lo=lo-(l(x-1,y)*2+1)
3030 if x<gs-1 then l(x+1,y)=not l(x+1,y):lo=lo-(l(x+1,y)*2+1)
3040 if y>0 then l(x,y-1)=not l(x,y-1):lo=lo-(l(x,y-1)*2+1)
3050 if y<gs-1 then l(x,y+1)=not l(x,y+1):lo=lo-(l(x,y+1)*2+1)
3060 return

4000 rem initialize grid
4010 print "grid size (3-10, enter=5)":input gs
4020 if gs=0 then gs=5
4030 if gs<3 or gs>10 then 4010
4040 print "initializing..."
4050 for a=1 to 10*gs
4060 y=int(rnd(1)*gs)
4070 x=int(rnd(1)*gs)
4080 gosub 3000
4090 next
4100 return

5000 rem select game
5010 print "play specific game # (y/n)?"
5020 rem s=s+1:a$=inkey$:if a$="" then 5020
5021 s=s+1:get a$:if a$="" then 5020
5030 if a$="y" then 5070
5040 if a$="n" then a=rnd(-s)
5050 gn=rnd(65535):a=rnd(-gn)
5051 rem gn=int(rnd(1)*65535)-1:a=rnd(-gn)
5060 goto 5100
5070 input "play game (1-65535)";gn
5080 if gn<1 or gn>65535 then 5060
5090 a=rnd(-gn)
5100 return

The more I look at this code, the more optimizations I want to make to it.

But for now, that is a version for CoCo, and a version for Commodore. It should be easy to port to other flavors of BASIC. Let me know if you port it to something.

Now that I know how to write the game, the next goal will be to make it look a lot better on the CoCo (and maybe VIC-20 as well, if I feel ambitious).

But I think I need a brake from Lights Out for a bit…

Until then…

The Color Computer 3 Prototype

This article was originally printed in the May 2007 Volume 3 Issue 2 of the CoCoNuts! newsletter. See it, with photos, here. See more photos of this prototype here.

Updates:

  • 2024-03-12 – Corrected resolution of CoCo 3 (incorrectly said 640×480). Thanks, Curtis!

By Allen Huffman

Prologue – In the Beginning

On a warm August day in 1985, a Federal Express delivery truck pulled in to a parking lot in Clive, lowa like it did almost every day. The driver retrieved a nondescript cardboard box from the back of the truck and carried it to the lobby. The box was signed for and left, then the driver returned to his route, unaware of the significance of what he had just been part of. The box, you see, had been sent by Tandy in Ft. Worth, Texas. The recipient was a small computer company called Microware Systems Corporation. The contents of the box were a secret prototype for a new computer which would be appearing the following year in Radio Shack stores nationwide: the Tandy Color Computer 3 (aka, the CoCo 3).

That was two decades ago – a lifetime in the computer world. Few specifics about what went on behind closed doors at Microware or in Tandy Towers are known. What is known, however, is that Microware had previously established a business relationship with Tandy to produce a version of their OS-9 operating system for the original Color Computer. This time, their involvement would go far beyond just doing another port of OS-9 to new hardware. It would involve them working on the onboard firmware to bring the new machine to life. Microware would be expanding Extended Color BASIC to take advantage of the new hardware.

But why Microware? In 1979, Microsoft (yes, that Microsoft) had done the original Color BASIC for the Color Computer so surely they would be the ones to continue doing so. But, by 1985, Microsoft had moved beyond being just a provider of BASIC and those types of projects just weren’t compelling. Some speculate Microsoft would have done it, but it was just cheaper to have another company work on the project. In either case, Microware was likely chosen because they had previous experience working with Tandy and the CoCo on the OS-9 project. Since there were plans to bring out the next generation of OS-9 (Level 2) for the new machine, perhaps the economy of scale (a discount for doing multiple projects) did play a role in this decision. We may never know the full details, but regardless, in 1986 a new CoCo 3 began appearing at Radio Shack stores nationwide, and its new Extended Color BASIC featured enhancements done by Microware.

Although the story of how Microware had to patch and extend Microsoft’s code is an interesting one, this is not that story. Instead, this is the story of the contents of that secret box. This is the story of the CoCo 3 that almost was.

Part 1 – The Discovery

It was January 2005 and the large, three-story custom-built Microware building was finally being vacated by its original owner. Microware had ceased to exist as an independent entity in 2001 after it was acquired by Oregon based RadiSys Corporation. Over the years, the once thriving embedded operating system company had become a much smaller struggling company trying to compete in a market now filled with hundreds of competitors, including offerings from Microsoft and embedded versions of the free Linux. Although the building, completed in 1996, was once fully occupied by Microware staff, it had slowly been rented out as the company reduced in size. At some point, the building was sold and the former owner became a renting tenant. It was on this day that the last remaining Microware folks would be relocating to a much more appropriately sized rented office space a few miles away.

The move was somewhat emotional for those who had been with the company since the 1980s. Efforts were made to preserve any OS-9 related artifacts that might still prove useful, such as motherboards for any versions of OS-9 that were still supported. VME cards were salvaged and server racks were saved, but endless other pieces of ancient hardware were to be recycled. Large trash units had been brought in to the parking lot. Old PCs, SUN workstations, endless cables and old parts were being thrown in to them. A mountain of monitors was stacked high in the lobby, waiting to be picked up by the recycler. Decades of history had been rendered useless by the advances of technology.

One of the final areas to be cleared out was a small storage room in the basement known as “the morgue.” Inside the morgue were some of the more interesting artifacts of Microware’s past. Shelving units full of Compact Disc Interactive (CD-i) development systems stood across from piles of old software disks and tapes. Endless VME I/O cards, motherboards and reference hardware sat under layers of dust next to boxes of blank EPROMS and serial cables. It was a place that, in the 1980s, would have been a hardware hacker’s wet dream, but today it was just a room of ancient technology with no modern value or use to anyone.

Just like Noah and the Ark, two of each potentially useful item was to be saved. Anything that was no longer supported (or functioning) was to be sent to the great recycling center in the sky. Some historic items were allowed to be taken home, including an infamous Japanese video game system that ran OS-9 and featured mechanized 5 1/4″ floppy drives and a fancy joystick. There were a few other pieces of unusual OS-9 hardware that escaped a crushing fate.

For instance, the CD-i machines also had some historic significance. Many were development systems used to create the tools Phillips and other companies used for making CD-i content. Others had been part of a shopping kiosk business known as Micromall, co owned by Microware in the 1990s. These CD-i machines were saved then sold off at the 2006 Chicago CoCoFest, hopefully helping them end up somewhere better than the recycle bin.

During all of this purging, a nondescript brown cardboard box was discovered. One of the remaining long time employees knew of its contents and made sure to set it aside. This box was the same box that Federal Express had delivered twenty years earlier. This box contained not one, but two Color Computer 3 prototypes and a few other surprises. The contents of this box have since helped us learn a bit more about what Tandy had intended the CoCo 3 be.

Part 2 – From Prototype to Pre-Production

Before the discovery of the actual Color Computer 3 prototypes, the CoCo community had already seen what was being called “prototype CoCo 3s.” A few years earlier, some pre-production CoCos were displayed at a CoCoFest convention. The CoCo Communityis official monk, Brother Jeremy, had acquired them somehow. They were the ones used by Microware for developing OS-9 and, we assumed, the Extended Color BASIC extensions. Externally they looked like the CoCo 3s we are all familiar with, but the motherboards inside were different. The GIME chips were earlier prototype versions, different from the ones found in later production units. Little else is known about these machines, but news of their existence spread through the community.

After hearing that “prototype” CoCo 3s had been shown publicly, one of the original Microware CoCo 3 developers made a comment that those couldn’t possibly be the real prototypes because the real ones were still in storage at Microware. This was the first clue that there was something else still to be discovered. Something few had seen, and something hidden away somewhere in a box stored down in a basement.

When the box was opened, it was clear no one had seen or touched its contents for many years, and quite possibly not since 1986. The insides were dusty. The labels were faded and cracked. A small supply of bubble wrap was all that protected the contents. Inside were two large green circuit boards and three smaller ones.

The large boards were covered in chips and wires. The only thing that gave any clue that this was connected to the Color Computer was a series of familiar connectors on the back edge. The standard CoCo joystick, serial and cassette ports were there along with a cartridge connector. Elsewhere on the board could be found a keyboard connector, and further inspection of the chips revealed a few recognizable ones, like a 6809 processor. The amount of chips (on a board four or more times the size of a production CoCo motherboard) was staggering. The back side of the board was covered in dozens and dozens of long green jumper wires.

Two smaller CoCo cartridge boards were also found as well as an unidentified third board that didn’t seem to plug in to anything. The cartridges matched one that had shown up a few years earlier at a CoCoFest that was thought to be some kind of Ethernet networking pak. The third mystery board carried a Copyright 1984 Tandy notice on it, indicating it was probably too early to be anything CoCo 3 specific. It was this set of five boards that was shown at the 2006 Chicago CoCoFest, and this was when the next round of discoveries were made.

CoCo networking cards, and mystery board.

Part 3 – Blue Sky CoCo

“Everything, even the CoCo, starts with a dream.”

When Disney’s Imagineers start designing a new ride or attraction for one of the theme parks, they initially start with what they call the “blue sky” phase. That is, “the sky is the limit.” Anything is possible, even if impossible. These initial concepts and ideas may be far grander than what is technically possibly, or perhaps possible but economically unfeasible. As the project continues, the budget (and often the realities of technology) whittles down the blue sky plans to something much more humble which hopefully will get approved and built. Disney fans know far too well how grand plans originally become much smaller realities, such as how Walt Disney World’s Epcot “Space Pavilion” went from a full experience with a space shuttle launch to a space station, to just a simulator ride that didn’t pretend to be anything grander.

This same approach is common in many areas of design, and likely played a role in the evolution of the Color Computer series. For instance, it is documented that a Deluxe Color Computer was planned but never released. Evidence of this includes references to a deluxe model in the Color Computer 2 manuals. Little is known about the features of this version other than a documented ability to enter BASIC commands in lowercase. Such capabilities never made it in to any official version of Radio Shack CoCo BASIC, but later models did include support for a lowercase display. There were also references to extra keyboard keys. Coincidentally, Radio Shack stores sold some keyboards as spare parts during this time. Theses keyboards had a few extra keys and could be plugged directly in to an existing CoCo. It is believed that these keyboards were designed for the never-produced Deluxe CoCo. Perhaps some day a prototype of this machine will surface.

It is possible that the CoCo 3 grew out of blue sky plans for the Deluxe CoCo, actually allowing more ambitious plans to be made than just minor improvements. All that known for sure today is that the Deluxe CoCo plans got far enough for keyboards to be manufactured and for manuals to be revised and printed.

To understand what was happening, it is helpful to look at what had already happened. Tandy has already evolved the original grey case CoCo several times. There were a few revisions to the original motherboard with the final versions supporting 64K without hardware hacks. A small run of white cased CoCo 1s was also produced which included an updated keyboard. Next was the CoCo 2 in a smaller white case with a similar keyboard, though they were soon revised to have an improved keyboard which would continue to be used on all later models. There were numerous revisions to the CoCo 2 models, though the only significant feature was the addition of true lowercase for the “Tandy” branded units. (None of the models labeled as TRS-80s had this enhanced video chip.) There was also another minor revision that caused the need for Color BASIC 1.3, but the end result was a machine that was effectively no different than the original 1980 model other than in appearance.

To truly make a successor, Tandy needed something bolder than just a new keyboard and case. Game developers wanted to see enhanced graphics. Similar peer systems, such as the Commodore 64, had more colors and hardware sprite capabilities which allowed more advanced games to be created easier. Some of these capabilities were already available as expansion pak add-ons for the CoCo, but developers couldn’t target those enhancements since the base CoCo did not have them. In order to be useful, the hardware would have to be integrated.

Looking at the lineup of add-on hardware paks sold by Radio Shack, certainly building in enhanced audio (like the Speech/Sound Pak) would be useful. The RS-232 pak would also have made a nice addition, effectively giving all those “power user” features to the base model. A “really deluxe” CoCo with better graphics would also need to support something other than an old-style television set. Other obvious enhancements would | include more memory and speed.

Ultimately, the CoCo 3 that was released in 1996 only contained a handful of these blue sky items. Compromises had to be made to keep costs down. One of the original Tandy CoCo 3 developers, Steve Bjork, has stated that there was a requirement for the CoCo 3 to be produced ata lower cost than the CoCo 2 it was replacing. This ambitious economic goal certainly limited all the developer’s requests for enhanced hardware.

When released, the production model CoCo 3 did contain better graphics (up to 640×225 with four colors, or 320×225 with 16 out of 64 colors). More memory was added, with the base model of 128K expandable to 512K. RGB-analog monitor output was added, as well as audio/video outputs for hooking to VCRs or composite monitors. The CoCo 3 could also run at double speed even in RAM mode, allowing a boost in performance for more than just BASIC ROM calls. (The CoCo 1 and 2 had a “double speed” poke which sped up ROM access, but the so-called “triple speed” poke that sped up RAM access garbled the video display. The CoCo 3 allowed the “triple speed” poke to work for both RAM and ROM code without losing the display.)

Other additions were compromises. In lieu of real sound hardware, developers such a Steve Bjork lobbied for and received an enhanced IRQ timer. This didn’t compete with the music chip in the Commodore 64s, but it did allow enhanced background sound effects using the existing CoCo sound capabilities. There was another IRQ that would have dramatically helped with RS-232 performance over the printer/ serial “bit banger” port. It is believed this was meant to substitute for a hardware RS-232 interface, but it was miswired so that potential was never realized. The list of other enhancements that would have been nice but didn’t make it is something discussed to this day, usually under the guise of what would have been ina CoCo 4.

Overall, the CoCo 3 was a significant leap forward for the series. It contained better graphics, more memory, faster usable speed and even added the extra keys that would have been part of the Deluxe CoCo (but still no BASIC enhancements to allow entering commands in lowercase). The new monitor outputs and new color CM-8 monitor allowed using an 80 column screen, finally breaking away from the 1980-vintage 32-column display. It was a significant upgrade and one that developers took too quickly. The new generation of programs, from enhanced games with full color and background sound to the power of OS-9 Level 2, made the new model a more revolutionary a leap than from CoCo 1 to CoCo 2.

This brings us back to that box and the prototype within. By the time hardware is created, even if it’s just a massive circuit board stuffed with chips and wiring, most blue sky goals have been eliminated. The goal of the initial prototype is to begin working on what will hopefully be produced later. Projects certainly continue to evolve, often based on feedback from working with the prototypes, but examining early designs can shed light on the intent of the designers at that moment in time.

As mentioned earlier, the CoCo 3 prototype contained the common ports found on all CoCos up to that point – cassette, joystick, printer, TV RF out, and cartridge. New RCA jacks were added for composite audio/ video output, and a DB9 appeared for the new RGB-analog monitor. While the RCA jacks would make it to the production CoCo 3s, the DB9 connector did not. Instead, an odd square 10-pin header connector was added to the bottom of the machine. This was likely a cost reduction move since placing the connector there on the motherboard probably saved some layout money, and using a surfacemount header was cheaper than adding a DB9 port. Still, it does indicate that Tandy may have intended to use some kind of monitor that had a DB9 connector like other monitors of the day.

On a side note, the production CoCo 3 still contains one mystery related to the monitor port. Under the machine where the monitor plugs in is a square indention that could have fit some kind of small box. Perhaps there was an idea of converting the main RGB-A output to some other format via a converter box (maybe simplifying monitors between US and other parts of the world). Perhaps there was some other intended us that we may never learn about. Perhaps the CoCo 3 prototype will eventually give us a clue. (A more pressing mystery is why CoCo 3 software always asks Composite/TV or RGB? on startup, even though there was a way to detect if a CM-8 was plugged in.)

Something else learned by inspecting the prototype is that Tandy may have had much higher goals for their base model machine. The prototype has no place for RAM expansion. Instead, it is populated with 512K. This would have driven up cost and would have caused real problems during the RAM price crisis of the late 1980s when memory upgrades shot up by hundreds of dollars due to a fire at an overseas production facility. Looking back, releasing a cheaper 128K unit that could be upgraded later was probably a smart move though it ultimately led to few official Radio Shack products taking advantage of systems with that much memory.

Another interesting discovery was noticing a 1773 chip on the prototype. This chip was part of the CoCo floppy drive controller pak. The prototype had the floppy drive circuitry built in and contained a ribbon cable connector for the disk drive. Tandy must have wanted to integrate disk support in the base model, and perhaps had goals of shipping a floppy drive with the system or allowing the CoCo 3 to just plug in an external drive without needing the drive controller. Tandy actually did this very thing with their Tandy 1000 EX and HX PC compatibles. While those systems contained a built-in floppy drive (5 1/4″ and 3.5″ respectively), there was also a port that allowed plugging up an external drive. More on this later.

Probably the most curious observation was that the prototype did not even have a GIME chip. The GIME was a custom IC created to handle things like graphics and memory. In the early prototype stages, before such an expensive chip could be made, designers created the functionality of the GIME using programmable PAL chips and other support hardware. It is unknown how much GIME support is on the prototype, but since Microware used it to create the Extended Color BASIC enhancements (which included the new graphics modes), and since the prototype had 512K, is believed to have implemented the graphics and memory controller that the GIME later would handle.

There could be other secrets in this prototype. Early developers, under Non Disclosure Agreements with Tandy, received pre-production CoCo 3s with pre-production GIME chips. There were two known revisions to the production GIME (86 and 87 revision), and the early development units are believed to have been just earlier (and buggier) versions of what was released. But, documents given to Microware during this project indicated that one of the specifications for the CoCo 3 was a 256-color mode. Steve Bjork has stated that this mode never existed in any manufactured CoCo 3s,

and notes that the graphics hardware itself did not have enough bits available to represent a 256-color map. However, this early prototype may have had the basis for such a mode before it was deemed either too costly or, perhaps, too likely to compete with the Tandy 1000 graphics. The mystery of the specified 256-color mode may finally be unlocked in these early designs.

In a side note, the whole suspicion of a 256-color mode started when a former Tandy Color Computer product manager made reference to it years later. “Has anyone found the 256 color mode?” he asked. No one had, but noted Color Computer programmers John Kowalski

(“SockMaster”) and Australia’s Nick Marentes were able to find abnormalities in the CoCo 3 schematics published by Radio Shack in the Color Computer 3 Technical Service Manual. As Steve Bjork has mentioned, there were not enough address lines for doing an 8-bit color, but the schematics showed some evidence of alterations in that area. There where two extra lines being routed away from the normal path. Perhaps there were plans to achieve the 256-color mode by some way that would allow accessing those extra lines? Nick was able to track down the original designer of the GIME, but he had no recollection of any such mode. It seems likely that this mode, if it ever existed, may not have even made it to the GIME stages.

So the prototype, while not quite a “blue sky” machine with enhanced sound and true RS-232 serial hardware, did certainly represent a somewhat nicer machine than what was actually released. Imagine a CoCo 3 with 512K standard, normal DB9 monitor port on the back, anda place to plug the disk drive ribbon cable in and still have the cartridge port available. This would have removed need for the MultiPak for the large number of CoCoists who used floppy and RS-232, or perhaps floppy and the Speech/Sound Pak.

When the prototypes are fully inspected and, hopefully, reverse engineered, there may be more mysteries discovered. Though the prototypes were supposedly working when they were packed away 20 years ago, until someone qualified has time to inspect them, no attempts are going to be made to power them up.

-end-

Let’s write Lights Out in BASIC – part 6

See also: part 1, part 2, part 3, part 4, part 5, part 6 and part 7.

At this point, we have a nicely functional BASIC version of Lights Out. Some of its features include:

  • 5×5 grid of lights.
  • Random games.
  • Allows replaying a specific game.
  • Counts moves for scoring.
  • Ability to quite a game in progress.
  • Slightly less sucky user interface than the original version.

But we still have more to do!

Bigger grid, please

One of the enhancements I mentioned in the previous installment was the ability to specify larger (or smaller, I suppose), grid sizes. We know that the official Lights Out games from Tiger Electronics in the 1990s used a 5×5 and 6×6 grid. Others have since created variations, such as one that operates around a cube (maybe we write that version some day). Let’s start there…

For this simple version, we’ll just arbitrarily pick a maximum grid size of 10×10. This should still fit easily on the CoCo’s 32×16 text screen. For fun, we could also allow a grid size smaller than 5×5 to be chosen. Since the spiritual predecessor of Lights Out was a 1970s game that featured a 3×3 grid, I’ll use that size as the minimum.

The changes needed should be fairly minor. When starting a game, the user will be prompted for the grid size.

It seems we could allow rectangular grids (5×3, 10×5, etc.), but for now we’ll just stick to square grids where both sides are the same size. The array for the grid just needs to be large enough to hold the largest sized grid.

Wrong DIMension

An oversight I made when starting this program was not adding a DIM statement to specify the maximum size of the two-dimensional grid array! The current version really needs a line that contains this at the very top:

DIM L(4,4)

Reminder: DIM is base-0, so it starts counting entries at 0. A DIM X(4) gives entries X(0), X(1), X(2), X(3) and X(4).

The program only works because Color BASIC allows array entries 0-10 before the DIM is needed. You can do A(10)=42 without needing to DIM A(10) first. (I find it weird that Microsoft chose to default to 11 array entries. I bet whoever coded that was thinking “1-10” rather than “0-10”.)

To enhance the program to support up to a 10×10 grid, we’ll allocate an array that large.

4 DIM L(9,9)

Next we need to ask the user what size grid they want. This can be added to the “initialize grid” subroutine:

4000 REM INITIALIZE GRID
4005 INPUT "GRID SIZE (3-10)";GS
4006 IF GS<3 OR GS>10 THEN 4005
...

After that, any place that is currently hard coded to 4 will need to be changed to use the grid size variable. If the user types in 10 (for a 10×10), the array will be using 0-9. We must pay attention to that and know that a 10 grid is actually 0-9.

This is also a good time to clean up the printing of the grid a bit. Here is the full program with the latest changes in bold:

4 DIM L(9,9)
5 REM SELECT GAME
6 GOSUB 6000
10 REM INITIALIZE GRID
15 MV=0
20 GOSUB 4000
30 REM SHOW GRID
40 GOSUB 1000
47 IF LO=0 THEN 200
50 REM INPUT SQUARE
60 GOSUB 2000
70 REM TOGGLE SQUARES
80 GOSUB 3000
90 REM REPEAT
95 MV=MV+1
100 GOTO 30

200 REM GAME WON
220 PRINT "YOU WON IN";MV;"MOVES."
230 INPUT "PLAY AGAIN (Y/N)";Q$
240 IF Q$="Y" THEN 5
250 PRINT "GAME OVER"
260 END

1000 REM SHOW GRID
1005 PRINT "GAME NUMBER:";GN
1006 PRINT " ";
1007 FOR A=1 TO GS
1008 PRINT RIGHT$(STR$(A),2);
1009 NEXT:PRINT
1010 FOR Y=0 TO GS-1
1015 PRINT RIGHT$(STR$(Y+1),2);" ";
1020 FOR X=0 TO GS-1
1030 IF L(X,Y) THEN PRINT "X ";:GOTO 1050
1040 PRINT ". ";
1050 NEXT
1060 PRINT
1070 NEXT
1080 PRINT "MOVES:";MV;"LIGHTS ON:";LO
1090 RETURN

2000 REM INPUT SQUARE
2010 PRINT "X,Y (1-";GS;",1-";GS;" OR 0,0)";
2011 INPUT X,Y
2015 IF X=0 THEN IF Y=0 THEN 230
2020 IF X<1 OR X>GS OR Y<1 OR Y>GS THEN 2010
2025 X=X-1:Y=Y-1
2030 RETURN

3000 REM TOGGLE SQUARES
3010 L(X,Y)=NOT L(X,Y):LO=LO-(L(X,Y)*2+1)
3020 IF X>0 THEN L(X-1,Y)=NOT L(X-1,Y):LO=LO-(L(X-1,Y)*2+1)
3030 IF X<GS-1 THEN L(X+1,Y)=NOT L(X+1,Y):LO=LO-(L(X+1,Y)*2+1)
3040 IF Y>0 THEN L(X,Y-1)=NOT L(X,Y-1):LO=LO-(L(X,Y-1)*2+1)
3050 IF Y<GS-1 THEN L(X,Y+1)=NOT L(X,Y+1):LO=LO-(L(X,Y+1)*2+1)
3060 RETURN

4000 REM INITIALIZE GRID
4005 INPUT "GRID SIZE (3-10)";GS
4006 IF GS<3 OR GS>10 THEN 4005
4010 PRINT "INITIALIZING..."
4020 FOR A=1 TO 10
4030 Y=RND(GS)-1
4040 X=RND(GS)-1
4050 GOSUB 3000
4060 NEXT
4070 RETURN

6000 REM SELECT GAME
6010 PRINT "PLAY SPECIFIC GAME # (Y/N)?"
6020 S=S+1:A$=INKEY$:IF A$="" THEN 6020
6030 IF A$="Y" THEN 6060
6040 IF A$="N" THEN A=RND(-S)
6045 GN=RND(65535):A=RND(-GN)
6046 GOTO 6090
6050 GOTO 6020
6060 INPUT "PLAY GAME (1-65535)";GN
6070 IF GN<1 OR GN>65535 THEN 6060
6080 A=RND(-GN)
6090 RETURN

This version will display the grid with nicely (?) formatted headers for the columns and rows, and less nicely formatted prompts for what values are allowed.

There is still so much work to do to make the user interface nicer to look at and interact with.

To be continued…

MexiCoCo: The Mexico CoCo 3 clone no one told me about…

Updates:

  • 2024-03-03 – Added “MexiCoCo” name. Also note about ROM.

Be sure to follow Roger Taylor. He acquired one of the MicroSEP computers from Mexico (aka,. MexiCoCo), which is a rebadged CoCo 3 with some BASIC ROM changes.

Of interest — the ROM is socketed in this machine! Earlier, Roger had shown photos of a GIME chip “Made in Mexico.” Maybe that was connected to this product?

https://www.patreon.com/posts/microsep-ii-coco-98294739

Video here:

Decaps of 1986 GIME chip via Sean Riddle, Erik Gavriluk and Roger Taylor

Updates:

  • 2024-03-09 – Added Dropbox link for direct download, any more background details. I have let Roger know I am now ready to download the 1987 version files and get those available.

Last year, Roger Taylor went through the effort and expense to have the Tandy/Radio Shack Color Computer 3’s custom “GIME” chip decapped and scanned. Super high resolution images are available. This should give someone with the knowledge and skills the ability to reproduce these custom chips.

Read more about this, and other fascinating projects, on Roger’s Patreon page. Consider supporting him. He has made some interesting acquisitions lately, including a “did we know this existed?” Mexico CoCo 3 called a MicroSEP II. He has also spend thousands of dollars to acquire the source code archives of the late Steve Bjork.

https://www.patreon.com/rogertaylor/posts


These GIME chip scans are the works of:

  • Sean Riddle
  • Erik Gavriluk
  • Roger Taylor

Any distribution should include their credit.

Use this “1986 GIME.torrent” file to download with a BitTorrent client and help seed it for others to get a backup of these files. I also have the files in a Dropbox share for those really patient with downloading 140+ GB of image files.

https://www.dropbox.com/scl/fi/hecp00zdpkwiodfwic6f6/1986-GIME.torrent?rlkey=omv2kk3me0zf9xwbb5mwoyrjt&dl=0

The files are also currently on my Dropbox, if you want to try to download them from there:

https://www.dropbox.com/scl/fo/rnjy5y4bdi8vanwhfalgx/h?rlkey=6npyri1rbyxwp8d0chr5n6vml&dl=0

I do not have the 1987 GIME chip scans yet, but will do the same with them once I have them.

Let’s write Lights Out in BASIC – part 5

See also: part 1, part 2, part 3, part 4, part 5, part 6 and part 7.

As we begin this part, let’s look at the BASIC Lights Out code as it stands currently:

5 REM SELECT GAME
6 GOSUB 6000
10 REM INITIALIZE GRID
20 GOSUB 4000
30 REM SHOW GRID
40 GOSUB 1000
47 IF LO=0 THEN PRINT "YOU WON!":END
48 PRINT "LIGHTS ON:";LO
50 REM INPUT SQUARE
60 GOSUB 2000
70 REM TOGGLE SQUARES
80 GOSUB 3000
90 REM REPEAT
100 GOTO 30

1000 REM SHOW GRID
1005 PRINT "GAME NUMBER:";GN
1010 FOR Y=0 TO 4
1020 FOR X=0 TO 4
1030 IF L(X,Y) THEN PRINT "X";:GOTO 1050
1040 PRINT ".";
1050 NEXT
1060 PRINT
1070 NEXT
1080 PRINT
1090 RETURN

2000 REM INPUT SQUARE
2010 INPUT "X,Y (0-4,0-4)";X,Y
2020 IF X<0 OR X>4 OR Y<0 OR Y>4 THEN 2010
2030 RETURN

3000 REM TOGGLE SQUARES
3010 L(X,Y)=NOT L(X,Y):LO=LO-(L(X,Y)*2+1)
3020 IF X>0 THEN L(X-1,Y)=NOT L(X-1,Y):LO=LO-(L(X-1,Y)*2+1)
3030 IF X<4 THEN L(X+1,Y)=NOT L(X+1,Y):LO=LO-(L(X+1,Y)*2+1)
3040 IF Y>0 THEN L(X,Y-1)=NOT L(X,Y-1):LO=LO-(L(X,Y-1)*2+1)
3050 IF Y<4 THEN L(X,Y+1)=NOT L(X,Y+1):LO=LO-(L(X,Y+1)*2+1)
3060 RETURN

4000 REM INITIALIZE GRID
4010 PRINT "INITIALIZING..."
4020 FOR A=1 TO 10
4030 Y=RND(5)-1
4040 X=RND(5)-1
4050 GOSUB 3000
4060 NEXT
4070 RETURN

6000 REM SELECT GAME
6010 PRINT "PLAY SPECIFIC GAME # (Y/N)?"
6020 S=S+1:A$=INKEY$:IF A$="" THEN 6020
6030 IF A$="Y" THEN 6060
6040 IF A$="N" THEN A=RND(-S)
6045 GN=RND(65535):A=RND(-GN)
6046 GOTO 6090
6050 GOTO 6020
6060 INPUT "PLAY GAME (1-65535)";GN
6070 IF GN<1 OR GN>65535 THEN 6060
6080 A=RND(-GN)
6090 RETURN

There are quite a few more things that could (and probably need to) be done:

  • The number of moves taken should be counted and displayed.
  • If the game is won, it just ENDs in line 47. It could ask the player if they want to play again.
  • There is no way to quit a game in progress other than hitting the break key.
  • The user interface (typing in coordinates such as “0,2”) is user-hostile. At the very least, we could label the rows/columns to show which values to type. Perhaps even labeling them “A B C D E …” across, and “1 2 3 4 5” vertically, similar to how chess boards are done.
  • Options for grids larger than 5×5 could be implemented with very little change in the code.

Once the game is “code complete“, there is also be some cleanup and renumbering that should be done. (Having those odd line numbers like 47 bugs me.)

Score (Counting Moves)

The current code only knows that you won the game (the game ends) or you are still playing. If one person plays game number 16809 and solves it in 80 moves, and another person plays the same game and solves it in 10 moves, they are both treated to the same ending – the game exits.

Let’s add a move counter. We’ll reset it at the start of a game…

10 REM INITIALIZE GRID
15 MV=0
20 GOSUB 4000

…and increment it after every move:

90 REM REPEAT
95 MV=MV+1
100 GOTO 30

We should also display the move count each time the grid is display. This is a good time to also move the “number of lights on” in to the display grid routine, too.

48 PRINT "LIGHTS ON:";LO (removed)

1000 REM SHOW GRID
1005 PRINT "GAME NUMBER:";GN
1010 FOR Y=0 TO 4
1020 FOR X=0 TO 4
1030 IF L(X,Y) THEN PRINT "X";:GOTO 1050
1040 PRINT ".";
1050 NEXT
1060 PRINT
1070 NEXT
1080 PRINT "MOVES:";MV;"LIGHTS ON:";LO
1090 RETURN

This now gives us a display of our game number (which was already there), the number of moves made so far (new), and the current count of how many lights are on (already there).

DONE: The number of moves taken should be counted and displayed.

Game Over

The next thing I want to add is a game over screen. When the game is on, this screen should display how many moves it took. It could then prompt the user to see if they want to play agan.

It could be as simple as this:

47 IF LO=0 THEN 200

200 REM GAME WON
220 PRINT "YOU WON IN";MV;"MOVES."
230 INPUT "PLAY AGAIN (Y/N)";Q$
240 IF Q$="Y" THEN 5
250 PRINT "GAME OVER"
260 END

DONE: If the game is won, it just ENDs in line 47. It could ask the player if they want to play again.

I give up!

The user should also be able to quit. Currently, the awful “type in an X,Y coordinate” thing is yucky, but we could make typing “-1,-1” end the game. (We will fix the user interface later.)

2000 REM INPUT SQUARE
2010 INPUT "X,Y (0-4,0-4 OR -1,-1)";X,Y
2015 IF X=-1 THEN IF Y=-1 THEN 230

2020 IF X<0 OR X>4 OR Y<0 OR Y>4 THEN 2010
2030 RETURN

This is so yucky, but the goal here is to get the code fully functional. We can make it nice later.

DONE: There is no way to quit a game in progress other than hitting the break key.

The user interface sucks!

Okay, this one will take more work, but a quick enhancement might be to just print the columns and rows so the player knows what to type. Also, humans like counting from one instead of zero (base-1 humans) so typing in things to match the base-0 arrays is not very human friendly. We can fix both things here.

1000 REM SHOW GRID
1005 PRINT "GAME NUMBER:";GN
1006 PRINT " 12345"
1010 FOR Y=0 TO 4
1015 PRINT Y+1;
1020 FOR X=0 TO 4
1030 IF L(X,Y) THEN PRINT "X";:GOTO 1050
1040 PRINT ".";
1050 NEXT
1060 PRINT
1070 NEXT
1080 PRINT "MOVES:";MV;"LIGHTS ON:";LO
1090 RETURN

…and…

2000 REM INPUT SQUARE
2010 INPUT "X,Y (1-5,1-5 OR 0,0)";X,Y
2015 IF X=0 THEN IF Y=0 THEN 230
2020 IF X<1 OR X>5 OR Y<1 OR Y>5 THEN 2010
2025 X=X-1:Y=Y-1
2030 RETURN

Now the user will see numbers above the grid, and to the left of the grid, and be able to enter them using 1-5 rather than 0-4. I made 0,0 exit as well to save the use from having to type the minus signs.

But, this interface still sucks. After we get the “text and typing” version done, we can do one that is more modern and uses the arrow keys to cursor around and select squares.

DONE: The user interface (typing in coordinates such as “0,2”) is user-hostile.

Bigger grid, please

Hey, let’s just get the basic game working first, then we can worry about “Deluxe Lights Out.”

DEFERRED: Options for grids larger than 5×5 could be implemented with very little change in the code.

To be continued…