Category Archives: Retro Computing

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

Leave a reply

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…

Leave a reply

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

Leave a reply

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

Leave a reply

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…

Steve Bjork’s haunted house life…

Leave a reply

Though us CoCo folks knew Steve Bjork from Zaxxon and other games he wrote, in his later years he was very active in the haunted house industry.

He was part of Haunt Hackers which made haunted house electroincs. His partner, Steve Koci, passed away in recent years, and with Bjork’s passing, the website went aware.

Here is the last image of the Haunt Hackers website that the Intennet Archive has a copy of:

Haunt Hackers (archive.org)

He also did a home haunt display called Scary Lane. Here is his home haunt website from the archive:

Scary Lane (archive.org)

More to come…

Keywords: Steven Robert Bjork, Whittier California.

Let’s write Lights Out in BASIC – part 4

1 Reply

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

Where where we?

Oh, right. Light Out, in very basic BASIC.

If Lights Out always started with the same lights on, once you figured out how to win, you could repeat those steps and win every time. This reminds me of a wooden golf tee game I was given as a child. (If you have ever eaten at a Cracker Barrel restaurant, you probably have seen this — they have/had one on every table.)

I never learned how to win that game intentionally, but sometimes I would get lucky. This made visits to Cracker Barrel sometimes frustrating. The game had a listing of rankings based on how many pegs you had left at the end of the game. I was often an “EG-NO-RA-MOOSE.” :)

But then the iPhone happened in 2007, and a year later there was an App Store and you could play games on the phone! I found a peg game app and decided to learn and memorize the steps that win the game. I took screen shots of every step so I could consult them later. Here is one of those tiny 320×480 screen shots taken in 2008 on my original 2007 iPhone:

While I no longer remember those steps, I did for awhile, and visits to the Cracker Barrel were never the same. I was the peg game master! But soon it become boring and not worth playing since I knew how to win it every time.

Oh well. At least the collard greens and fried okra were still great.

Side Note: During research for this article, I found that Cracker Barrel has a blog post with the history of the peg game, as well as all the steps to solve it.

How to Solve the Cracker Barrel Peg Game

Blog post on the steps that solve the peg game every time.

But I digress…

“Random” game variations

The current program has an initializing routine which turns random lights on. But does it really?

As I wrote in an earlier article about RND, RND is not really random. On my CoCo, each time I turn it on, I can print some random numbers. Each time I power cycle and try it again, I will get those same “random” numbers. Here is an example of the first eight random numbers between 1 and 50 on the CoCo:

You get these same random numbers every time you power up the CoCo.

Any programmer that writes something that relies on RND to generate levels or patterns should be aware that it will make the same level or pattern each time the program runs from a fresh power up. BUT, in Color BASIC, you can seed the random number generator to change that pattern. It works by passing in a negative value to RND. When you do that, it seeds the number generator to a specific and repeatable sequence for that seed value.

If you run this code on a CoCo, you will see it print the same set of eight random numbers ten times:

10 FOR A=1 TO 10
20 B=RND(-42)
30 FOR B=1 TO 8
40 PRINT RND(50);:
50 NEXT
60 PRINT
70 NEXT

This means that if I powered up my computer and ran this Lights Out program, I would get the same pattern the next time I powered up and ran the program.

This is probably not a problem that really needs to be solved, but since there is a simple solution, it makes for a good excuse to discuss it.

Seeding the random number generator

In Extended Color BASIC, there is a TIMER function that starts at 0 on power up, then increments every 60th of a second until it rolls over and starts again from 0. Since the amount of time between power up, typing in “CLOAD” or whatever, and “RUN” will vary, using that value makes for a simple seed:

A=RND(-TIMER)

Just doing something like that at the start of the program should be enough to reduce chances that the patterns are not the same each time the game is played from a fresh start.

BUT, Color BASIC does not have TIMER. It would need a different approach to creating that number. If the program has a title/splash screen, it might sit in a loop waiting for the user to press a key to start. Something like that could be used to create a seed number:

PRINT "PRESS ANY KEY TO BEGIN:"
xx S=S+1:IF INKEY$="" THEN xx
A=RND(-S)

It is not perfect since if the user types RUN and quickly hits a key, there is a good potential that the program would be using one of only a few seeds based on the low numbers that the counter got to. But, hey, better than nothing… And that’s something.

We could also keep incrementing that S variable inside the main program loop. If the user chose to play again (our program does not offer that feature, yet), the value could be used to create more random patterns. This is probably overkill, but it would be simple to add.

Predictable randomness could be a feature…

I recall some game that came with Microsoft Windows (maybe a Solitaire, or perhaps Minesweeper) that had a spot where you entered a “game number” or something. This let you replay a specific game. I did not realize it at the time, but this was probably just seeding a random number generator so the order of the cards or the mines (whatever game it was) would be the same for those that wanted to try again.

Update: I was close! It was apparently FreeCell for Windows 95. I asked BING’s AI and it told me:

I believe the game you are referring to is FreeCell. FreeCell is a solitaire card game that was first introduced in Windows 95. It is a popular game that allows players to replay specific games by entering a “game number” ¹. If you’re interested in playing FreeCell, you can download it from the Microsoft Store ¹.

I hope this helps!
– BING AI

Thank you, large language model.

But I digress…

The game could try to randomize, but could also allow the user to pick a “game number” that would be repeatable. That could be a fun feature, since players could use it to practice different strategies.

It could be as simple as something like this (for Extended Color BASIC which has the TIMER function):

xx INPUT "PLAY GAME (1-65535, 0=RND)";S
IF S<0 OR S>65535 THEN xx
IF S=0 THEN S=TIMER
A=RND(-S)

Or if TIMER was not available, it could prompt the user then sit in a loop counting and use the count value as the seed. This is not a great approach, but might work…

PRINT "PLAY SPECIFIC GAME # (Y/N)?"
xx S=S+1:A$=INKEY$:IF A$="" THEN xx
IF A$="Y" THEN yy
IF A$="N" THEN A=RND(-S):GOTO zz
GOTO xx
yy INPUT "PLAY GAME (1-65535)";S
IF S<1 OR S>65535 THEN yy
A=RND(-S)
zz RETURN

I decided to add it to the program as a subroutine that can be called before the main game loop:

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):GOTO 6090
6050 GOTO 6020
6060 INPUT "PLAY GAME (1-65535)";S
6070 IF S<1 OR S>65535 THEN 6060
6080 A=RND(-S)
6090 RETURN

I could just call this before the game begins:

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

This would be simple enough to allow the user to replay a specific game. Here is a screen shot showing two instances of the XRoar emulator running the program, and generating the same pattern by using the same random seed:

This still is not 100% what we might want. While it does allow the user to request a specific game over and over, if they choose a random game, there is no way to get back to that game — it was chosen randomly.

To do that, we’d pick a random number for the “game number”, then use that as the seed value and display it as part of the game (so the user knows which number to use next time). We would still need to do some initial random seeding at the start so the game did not choose the same pattern of game numbers.

Here is a modification to the “select game” routine with some variable changes (GN for game number):

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

Then, we could print the game number before it prints the grid each time:

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

Now I can have the program generate a “random” game for me, and use that game number later to get the same puzzle.

At this point, we have a fairly playable (though ugly) version of a 5×5 Lights Out game.

There are a few more “nice to haves” we can add, so we’ll do those in the next installment.

Until then…

Dissecting my VIC-20 Eggs game

Leave a reply

The story so far…

In 1982 (possibly 1981?), I received my first computer, a Commodore VIC-20.

I taught myself BASIC and ended up sending in a simple game to a newsletter called VIC-NIC News.

Recently, someone sent me a scan of my program submission, ending a quest I had been on for almost a decade.

Here is that article from VIC-NIC News #6 (Volume 2, Number 4) from July/August 1983:

I thought it would be fun to walk through the program and see what it does…

0 rem 2024/2/11 fixed joystick

I added this line when I “fixed” the joystick routine so it could properly read the RIGHT direction. That fix, and the two numbers checked for moving the cup left or right, will be different than the original version published back in 1983.

1 print"{clear}{down*3}      eggs"
2 print"{down*3}  by  allen huffman"
3 print"{down*2}vic-nic news july 1983"
4 forj=1to5000:next

I believe these lines were added by the VIC-NIC NEWS. The {words} in curly braces are ASCII notation for the Commodore escape codes you could put in PRINT statements. {clear} is the code for clearing the screen, and {down} is the code for moving the cursor down one line. Therefore, that clears the screen then moves down three lines before spacing over to print the game title. The text would print in UPPERCASE and the code appears in UPPERCASE on an actual VIC-20. These lines just print a simple title screen, then wait for a few seconds before starting the game.

5 poke36879,8:printchr$(147)

Heh. I remember joking that everything on the VIC-20 used the POKE command, and sure enough, the very first thing I do in my program was a POKE. I consulted a useful VIC-20 memory map document to find this:

900F     36879    Screen and border color register
                   bits 4-7 select background color
                   bits 0-2 select border color
                   bit 3 selects inverted or normal mode

The value of 8 is bit 3 , so I was leaving “normal” mode on and setting background and border colors to 0. I don’t recall what this does, so I tried it in the VICE VIC-20 emulator and see it makes the screen black with blue text:

Checking the PEEK value of 36879 on startup shows it defaults to 27, which is the bit pattern 00101011.

36879    Screen and border color register

7 6 5 4 3 2 1 0
---------------
0 0 1 0 1 0 1 1
| | | | | | | |
| | | | | +-+-+- bits 0-2 select border color
| | | | +------- bit 3 selects inverted or normal mode
+-+-+-+--------- bits 4-7 select background color
                   
Border Color = 011 (3)
Inverted/Normal = 1 (normal?)
Background Color = 0010 (2)

As I searched for information on the colors, I found the wikipedia page for the VIC’s video chip. It lists the 16 colors the VIC-20 could produce as follows:

0 — black
1 — white
2 — red
3 — cyan
4 — purple
5 — green
6 — blue
7 — yellow
8 — orange
9 — light orange
10 — light red
11 — light cyan
12 — light purple
13 — light green
14 — light blue
15 — light yellow

With only three bits for the border color, the border can only use colors 0-7 (black through yellow). The background color uses four bits, so it can be any of the sixteen colors (0-15). I may have known this at the time, but if so, I had forgotten that the border could not be set to match all the possible screen colors.

In my case, setting the background and border to 0 makes it black.

If I had taken the original value (00101011, 27) and just cleared bit 3 (invert/normal, 00100011, 19), I see that it changes the text/foreground to inverted video:

Interesting. So I guess we are seeing inverted video on a black screen with black border? I really don’t know why, and I suspect I just saw that POKE in a magazine and liked it.

The print of CHR$(147) is the escape code that clears the screen. (Yep, there was not even a CLS type command in Commodore BASIC.)

10 b=8130:m=3:sc=0
15 e=int(rnd(1)*20)+7703

Two of these variables deal with locations within screen memory:

1E00-1FFF    7680-8191     Screen memory

B is the memory location of the player’s bucket. This is some spot on the bottom line of the screen. 7680 represents the top left character of the VIC’s 22×23 text screen. If you do the math, that is 506 bytes of memory used to represent the screen. But, screen memory of 7680-8191 is 512 bytes. The actual last visible byte on the screen is 8185. The player’s bucket is at 55 spots earlier, which is two full lines (22 bytes each) and 11 (half way in a 22 line screen). I am not sure why I started the game on the third line UP from the bottom, but I did.

M is how many men are left. Video games were very male-centric in the early days, I guess. Actually, in the early years, I don’t recall ever knowing a single girl that played video games, and do not recall seeing any in the arcades I went to, either.

SC is the score, which starts at 0.

E is the memory location of the falling egg. It starts at 7703 (the second byte of the second line) and then adds a random value of 0-19to it. This means I left out the left and right column of the screen for some reason. Looking at how I designed my later Factory TNT game, where the game had a border on the left and right and also a few lines at the bottom of conveyor belt graphics…

…it makes me wonder if I was already planning something like that for Eggs, but left it out to make the program smaller and easier to type in from a newsletter. (Above, you see I start the cup in Factory TNT 5 lines up, instead of 3 like Eggs, but it also limits the falling bombs under the spigots not using the left and right side of the screen. Curious.)

20 printchr$(19);chr$(5);"score:";sc

CHR$(19) homes the cursor to the top left. This would be like doing “PRINT@0,;” on the CoCo. The “SCORE:” is then printed with the current value.

25 pokeb,21:pokee,81

The character of 21 (a letter “U”) is POKEd to the player location, and a character 81 (filled circle) is POKEd to the falling egg location.

30 poke37154,127
35 j=(not((peek(37152)and128)/8+(peek(37137)and60)/4))+32
40 poke37154,255

This code, which I must have gotten from some magazine, is the joystick code. The code in the original article used incorrect memory locations, and was unable to read the “right” direction. I must not have known why, and just changed the published version to use UP and DOWN to move left and right (or, maybe it worked for me, but VIC-NIC NEWS couldn’t get it to work due to a typo and changed the directions?). Either way, memory location 37152 contains the “right” joystick switch, and 37137 contains the “up, down, left and fire” switches. The bits in one of these gets used for different things, to the POKEs to 37154 are used to toggle one of the bytes from joystick mode to keyboard mode. When you do that POKE, part of the keyboard stops working, so it has to be POKEd back at the end.

Because of how this works — if you BREAK the program at the wrong time, during those lines when it is POKEd to joystick, you won’t be able to type all the characters on the keyboard. A frustrating issue ;-)

45 ifj=0then80
50 pokeb,32
55 ifj=4thenb=b-1
60 ifj=16thenb=b+1

The joystick line basically takes the 4-bits (up, down, left and fire) from one memory location and the 1-bit (right) from the other location and combines them in to one byte. Because the bits read “1” when NOT pressed, and “0” when pressed, the code also inverts the results so “1” now means ON.

This IF statements check for directions. J=0 means nothing is pressed, so skip the rest. J=4 means the left button is pressed, so decrement the bucket location by one (moving it one to the left). J=16 means the right button is pressed, so increment the bucket location by one (moving it to the right).

65 ifb=8120thenb=b+1
70 ifb=8141thenb=b-1

These two checks make sure the bucket did not move too far left or right. B=8120 checks to see if the new position is in the first column. If so, too far, so move it back to the right one place. B=8141 is checking for the right column and if it is there, it moves it back left one. With am minor change, I could have made it so you could “wrap around” the screen, where if you moved to the right it would reset the position to the left, and vise versa. That might be an interesting update or option. (Allowing you to quickly “warp” from the left side of the screen to the right to catch an egg you might have otherwise missed.)

Hmm, thinking about this, maybe I shortened the number of rows that the egg drops so ensure you always had less time to move and catch it, increasing the challenge?

75 pokeb,21
80 pokee,32
85 e=e+22
90 pokee,81

At line 75, the player’s basket location has been updated so we POKE the “U” character (21) back on the screen. We then POKE a space (32) to where the egg is, erasing it. The Egg location is incremented by 22, moving it down to the next line, then the Egg character (81) is POKEd back to that new location.

95 ife=>8120ande=bthen110
100 ife=>8120ande<>bthen115
105 goto25

Much like how the basket is checked against the left and right column of the screen, some checks for the falling egg location are done here. If the egg location is at or greater than 8120 (first character of three lines from the bottom of the screen) then it is checked to see if it is the same position of the basket (the player caught the egg).

I’d have to benchmark this and see if that “e>=8120” even needs to be there. If that condition is not true, it would just skip quickly to the end of the line and move on. I’m expecting the overhead of checking “e=b” is less (no long number to parse) so it would probably be faster to just always check “e=b”. If the egg was caught, GOTO 110 happens to increment the score.

There is another check for >=8120 and then “e<>b” skipping to another line. This is poorly coded. If the check for “bottom” line was needed, something like this might be better:

IF E>8120 THEN xxx
IF E=B THEN 110 (player caught it)
...else, player did not, handle here
xxx continue on...

Something like that would simplify the logic, speed it up, and reduce the program size. But hey, I was just learning BASIC.

After this, if the egg did not reach the bottom and get caught or not caught, it goes back up to line 25 to continue the program loop.

110 sc=sc+10:pokee,32:goto15

This is where we go when the player catches an egg. Score is incremented by 10, the egg is erased by POKEing a space there, and then we go to line 15 where a new egg position will be created and the process will start over.

115 m=m-1:pokee,32
120 ifm=0then135
125 goto15

115 is where we end up if the egg reaches the bottom and the player did NOT catch it. The “men left” variable will be decremented, and the egg erased.

If M gets to 0, then game over, which is handled at line 135.

Otherwise, we go back to line 15 to make a new falling egg and continue.

135 fort=1to5:printchr$(17):next
140 fort=1to6:printchr$(32);:next
145 printchr$(158);"game over"
150 print"{down*2}play again? y/n"
155 geta$:ifa$="y"thenrun
160 ifa$="n"thenend
165 goto155

CHR$(17) is the escape code to move the cursor down one line, so the first line moves down five lines.

CHR$(32) is a space, so the second line prints six spaces over.

CHR$(158) sets the text color to yellow, it seems, and prints “GAME OVER”.

Then, for some reason, I don’t use the CHR$(17) to move down, and instead use the embedded screen code. This makes me wonder if I did this, or if it was changed by the VIC-NIC NEWSLETTER folks.

My choice of looking for “Y” or “N” is interesting. This works, and is short, but it is not how I would do it today. If GET A$ catches a “Y” we just RUN to start everything over. If it is an “N” we just END and stop right there. Otherwise we go back and check again.

This is kinda clever, since I would have thought of writing it like:

xxx GET A$:IF A$="" THEN xxx
IF A$="Y" THEN RUN
IF A$="N" THEN END
GOTO xxx

…and that would be larger. Was I smarter then?

And that, my friends, is my first published program. I do not know how close this code is to what became Factory TNT (it would have been trivial to rewrite from scratch) but I can definitely see similarities — it is effectively the same program, just with more graphics, sound and such added in the Factory TNT version.

And now I guess that is all I can possibly write about this program.

Until next time, that is…

My 1983 VIC-20 Eggs game has a typo in the joystick routine

3 Replies

Down the VIC-20 joystick rabbit hole I go…

In my recently-recovered “first program I ever had published,” I noticed that the joystick was not working. I was testing on VICE (the Versatile Commodore Emulator) on a Mac. The code that I had to read the joystick was clearly something I found in a magazine or somewhere because I have no idea what it does:

30 POKE37154,127
35 J=(NOT((PEEK(37151)AND128)/8+(PEEK(37151)AND60)/4))+32
40 POKE37154,255

I suspected maybe a typo was introduced when VIC-NIC NEWS typed in my program to print it out for publication. I did some searching to see how you were supposed to read the VIC-20 joystick. I was surprised that the Commodore VIC-20 manual didn’t offer any code to do this.

I found an Atari Magazine page that simply said you used two PEEKs:

The VIC is designed to handle only one joystick, and it takes two bytes to control that joystick. In the VIC, location 37137 is PEEKed to read the joystick for the up, down, left, and fire button movements. Location 37152 is PEEKed to detect movements to the right.

…

To see just how easy it is to detect movement on the joystick, plug in your joystick, type in one of the following short programs, and then RUN. The programs simply PEEK the joystick control bytes, and then PRINT that reading to the screen.

For the VIC-20:
10 PRINT PEEK(37137), PEEK(37152) : GOTO 10
– Atari Magazine, issue 42

Curious. My code was not using either of those addresses. Either my code or this magazine had a typo.

I tried those two PEEKs in VICE and noticed only the fire button was making the values change. This matched the VICE joystick display also showing only the fire button working.

I then thought the joystick I was using (a USB joystick that came with my TheVIC20) might have an issue. I tested it using a joystick test program, and it appeared to read all directions correctly.

A bit of more searching and I found that the Mac version of VICE has has an issue with joysticks not working since sometime in 2022:

https://sourceforge.net/p/vice-emu/bugs/1785

Even if my code was correct (to be determined), I would not be able to test it on the Mac version of VICE.

I then tried running Eggs from the Windows version of VICE and was able to see the joystick work — but, it was using UP and DOWN to move the cup left and right. Odd. I know I must have intended for it to use left and right, because my typed instructions clearly stated:

“Use joystick to move the cup left and right to catch falling eggs.”
– Eggs instructions.

While technically it didn’t say “move the joystick left or right,” I think it would have been a very odd choice for me to use “up” to mean left, and “down” to mean right, in a game like this.

This led me back to suspecting a typo in my joystick code. I went back to those two PEEKs from Atari magazine and tested them on the Windows version of VICE. This time, it seemed to change for all directions other than right. It gave values for Up, Up-Left, Left, Left-Down and Down, as well as the button. Clearly, this code was wrong (or maybe the Windows version of VICE also had an issue).

I decided to figure out where my joystick code came from. I searched for this code:

J=(NOT((PEEK(37151)AND128)/8+(PEEK(37151)AND60)/4))+32

…and archive.org actually had a single match! It was found in Issue #8 of The TORPET (Toronto Pet) on page 31. This Commodore PET publication had a section about the then-new VIC-20. For fun, here is the entirety of their VIC-20 section:

VIC NOTES
by John O’Hare

As of Mid October, 15,000 VIC’s have been sold in Japan, 15,000 more in the U.S., and, though not yet available in Europe, orders are accumulating fast. -JS

If you really want a color PET, Commodore suggests you consider buying a VIC as a peripheral for your PET! Seriously, it uses Upgrade BASIC V2, is cassette compatible, and has excellent color compared to Apple, and Atari. -JS

Some VIC POKE locations are:

51 decrements when key hit. 204 cursor on flag.
56 pointer to top of memory. 211 cursor column.
67 holds 1 when key hit. 214 cursor row.
197 value of key depressed. 36865 border position (vertical).
145 flag for left shift key. 36864 border position (horizontal).
245 detects special keys. 36869 pointer to character generator.
240= norm. 255 = 7168.

To read a joystick on a VIC (standard ATARI joystick works), use the following subroutine:

9000 POKE 37154,127
9010 JO= (NOT((PEEK(37152)AND128) /8+( PEEK(37151)AND60)/4)) +32
9020 POKE 37154,255
9030 RETURN

JO Values returned are: 1 = up, 17 = up and rt, 16= right, 18 = down and r t,
2 = down, 6 = down and Ift, 4= left, 5= up and Ift.

VIC GAME REVIEWS

VIC GAMES PAC, $25 from Creative Software. 3 VIC arcade games: VIC Trap, Seawolf, and Bounce Out. Seawolf and Bounce Out are machine language, with very fast action. Very good games, but could be better if they used Hi Res graphics. -JOH
– The TORPET, Issue #8, Page 31

Wow, early days – reporting only 15,000 VIC-20s had been sold at that point!

In my code, I check for the value of 18 to move the bucket left (“ifj=18thenb=b-1”) and a value of 17 to move the bucket right (“ifj=17thenb=b+1”). That matches the values for up and down in this TORPET article! I guess I really did mean for up and down to move left and right.

But I have a theory about this, which I will get to in a moment…

The thing I immediately noticed was this code used two different memory locations, while my program (as listed in VIC-NIC NEWS) used the same memory location twice. I consulted a VIC-20 memory map to see what all the various addresses are for:

37137 – Port A output register: (PA0) Bit 0=Serial CLK IN, (PA1) Bit 1=Serial DATA IN, (PA2) Bit 2=Joy 0, (PA3) Bit 3=Joy 1, (PA4) Bit 4=Joy 2, (PA5) Bit 5 = Lightpen/Fire button, (PA6) Bit 6=Cassette switch sense, (PA7) Bit 7=Serial ATN out
37151 – Port A (Sense cassette switch)
37152 – Port B output register: keyboard column scan, (PB3) Bit 3 =cassette write line, (PB7) Bit 7 =Joy 3
37154 – Data direction register B

The TORPET code looked wrong since one of the locations it was using had nothing to do with the joystick.

The Atari Magazine looked better since it used the two locations that mentioned joystick – 37137 and 37152. 37137 contains three joystick directions (Joy 0-2) plus the button. 37152 contains the final joystick direction (Joy 3). However, running this code doesn’t show anything changing for “right”.

I think the extra POKEs the code I used (and the code in The TORPET used) may explain that. It seems you have to POKE to change the purpose of some of this bits. 37154 is a data direction register for Port B (37152), and before my joystick code I POKE it to 127 which is a binary pattern of 01111111. After doing the joystick PEEK, the code POKEs it to 255, which is 11111111. I am suspecting that that 0 (bit 7) indicates read of whatever is hooked to that bit — which is Joy 3 (PB7). It looks like you turn it to 0, then you can PEEK it, then it gets set back to a 1 after.

I added this to the Atari Magazine code:

5 POKE 37154,127
10 PRINT PEEK(37137), PEEK(37152) : GOTO 10

…and now the second value changes when the joystick is pressed right. Huzzah!

It looks like the first byte reads up, down, left and fire, and the second is right. The POKE is only used to toggle the right bit on and off to do a read. It should get restored after (set back to 1) but in my quick demo, I didn’t bother to do that and I found I could not type certain keys. Aha, that explains “keyboard column scan.” That bit must be used to read a keyboard column, normally, and can be switched to read the joystick instead.

I will have to explore that more, later, but for now I can clearly see an issue with my code. By using only one of those locations, it is never reading the I/O bit that represents the “right” direction.

The code listed in The TORPET is incorrect:

9000 POKE 37154,127
9010 JO= (NOT((PEEK(37152)AND128) /8+( PEEK(37151)AND60)/4)) +32
9020 POKE 37154,255
9030 RETURN

37151 does not have anything to do with the joystick. This code takes the PEEK of that location and ANDs it with 60 (bit pattern 00111100) telling me it is expecting to use four bits. That matches the four joystick bits that are at 37137:

Bit 2 – (PA2) Bit 2=Joy 0
Bit 3 – (PA3) Bit 3=Joy 1
Bit 4 – (PA4) Bit 4=Joy 2
Bit 5 – (PA5) Bit 5 = Lightpen/Fire button

I think The TORPET got it wrong, and that second PEEK should be 37137.

The PEEK of 37152 seems okay. It ANDs it with 128 (bit pattern 10000000) which matches looking for that bit for the joystick:

Bit 7 – (PB7) Bit 7 =Joy 3

I suspect Atari Magazine just omitted the POKE needed to have the bits come from the joystick port, and The TORPET just had the wrong address listed. Since I had never heard of The TORPET, I expect I got my code from one of the few magazines I had at the time (Family Computing, Compute or Compute’s Gazette).

I changed my code to use 37137, but it still did not work! Now I could only move to the right by pressing Up+Right.

I think it is time to figure out what this code is trying to do.

Figuring out what this code is trying to do

Let’s start with the “correct” TORPET code and dissect what it is doing:

J=(NOT((PEEK(37152)AND128) /8+( PEEK(37137)AND60)/4)) +32

37137 – Port A output register: (PA0) Bit 0=Serial CLK IN, (PA1) Bit 1=Serial DATA IN, (PA2) Bit 2=Joy 0, (PA3) Bit 3=Joy 1, (PA4) Bit 4=Joy 2, (PA5) Bit 5 = Lightpen/Fire button, (PA6) Bit 6=Cassette switch sense, (PA7) Bit 7=Serial ATN out
37152 – Port B output register: keyboard column scan, (PB3) Bit 3 =cassette write line, (PB7) Bit 7 =Joy 3

PEEK(37152) uses “AND 128” to get just the high bit (bit 7) of Port B, which is the “right” joystick direction. It will either be 0 (no right) or 128 (right). It then divides by 8 which effectively shifts that bit over three places to the right:

10000000 - 128 (original reading)
00010000 - 16 (after the divide by 8)

PEEK(37137) uses “AND 60” to mask out the four bits in the middle. If they were all “on” (you can’t do that with a normal joystick), it would read 00111100. It then divides by 4 which effectively shifts those bits over two places:

00111100 - 60 (original reading if all joystick inputs were "on")
00001111 - 15 (after the divide by 4)

It adds those two values together, so this code is creating a new value of 5 bits, where those five bits represent the joystick switches for up, down, left, right and fire (00011111). From looking at the bit pattern, this new byte represents the following:

Bit 0 – Up
Bit 1 – Down
Bit 2 – Left
Bit 3 – Fire
Bit 4 – Right

Next I wondered why the program uses “NOT.” From checking the PEEKs, I see that when a joystick switch is not on, it shows a 1. When it is activated, it shows a 0. The NOT is used to invert that logic:

If no switches are pressed, the value is 31 (00011111). NOT flips the bits, so that value becomes 11100000. (Actually, I think it is represented as 16-bits, so 11111111111000000.) I believe when you use AND/OR/etc. the value is treated as a 16-bit signed value (-32768 to 32767) with the high bit representing negative. There result is the 31 becomes a -32. This explains the “+32” at the end.

The result is a value that is 0 if no switches are pressed. All of this match (dividing, adding, NOTing) does make the routine slow so maybe we’ll play with speeding it up sometime…

Using this newly created bit pattern, the BASIC program could use specific values to represent a direction (up), or two directions at the same time (up+left). My game did not use the fire button, but I think the way you would check that would be to use AND on the JO value to look for that specific bit, that way the rest of the value could be anything (up+fire, up+left+fire, nothing+fire, etc.).

Here is a test program for the “fixed” TORPET code:

10 rem fixed torpet code
20 gosub 9000
30 if jo and 1 then print "up ";
40 if jo and 2 then print "down ";
50 if jo and 4 then print "left ";
60 if jo and 8 then print "fire ";
70 if jo and 16 then print "right";
80 if jo<>0 then print
90 goto 20
9000 poke 37154,127
9010 jo=(not((peek(37152)and128)/8+(peek(37137)and60)/4))+32
9020 poke 37154,255
9030 return

Though, a mystery I Have yet to understand, is why do so many VIC-20 joystick references say you can also use 37152 and 37151? This code also works:

9010 jo=(not((peek(37152)and128)/8+(peek(37151)and60)/4))+32

Anyone know?

Now … why did I use Up and Down in my original Eggs? I think this is because the joystick code I had was broken and never returned a value for right. This was because it was PEEKing the same byte twice instead of the second byte being the one that had the “right” switch! I probably couldn’t get it to work, so I just used UP and DOWN.

Using this “fixed” code, I could now alter my program to work like I originally intended:

0 rem 2024/2/11 fixed joystick
1 print"{clear}{down*3}      eggs"
2 print"{down*3}  by  allen huffman"
3 print"{down*2}vic-nic news july 1983"
4 forj=1to5000:next
5 poke36879,8:printchr$(147)
10 b=8130:m=3:sc=0
15 e=int(rnd(1)*20)+7703
20 printchr$(19);chr$(5);"score:";sc
25 pokeb,21:pokee,81
30 poke37154,127
35 j=(not((peek(37152)and128)/8+(peek(37137)and60)/4))+32
40 poke37154,255
45 ifj=0then80
50 pokeb,32
55 ifj=4thenb=b-1
60 ifj=16thenb=b+1
65 ifb=8120thenb=b+1
70 ifb=8141thenb=b-1
75 pokeb,21
80 pokee,32
85 e=e+22
90 pokee,81
95 ife=>8120ande=bthen110
100 ife=>8120ande<>bthen115
105 goto25
110 sc=sc+10:pokee,32:goto15
115 m=m-1:pokee,32
120 ifm=0then135
125 goto15
135 fort=1to5:printchr$(17):next
140 fort=1to6:printchr$(32);:next
145 printchr$(158);"game over"
150 print"{down*2}play again?  y/n"
155 geta$:ifa$="y"thenrun
160 ifa$="n"thenend
165 goto155

And now, while I still wonder why so many VIC articles disagree on how to read the joystick, at least I can move left and right in my 1983 classic VIC-20 game Eggs…

Until next time…

Let’s write Lights Out in BASIC – part 3

7 Replies

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

The story so far… In the beginning, we learned a bit about the game Lights Out and its history. We then saw some very basic BASIC that implements the basic functionality of a basic game of this type. We still have a bit more work to do, such as initializing some of the squares to an “on” state and adding code to detect when the game has been won.

Let’s add that.

Game Initialization

Since variables in BASIC initialize as 0, and 0 means FALSE (the light is “off”), the initial grid would be shown with all lights off. Congratulations. You win!

To make it a game, we need to have some or all of those lights on when the game starts. My initial attempts of just randomly setting some number of lights to on seemed to often produce puzzles that could not be solved — even when using lookup tables (i.e., “cheating”) that show the winning patterns. Are there unsolvable patterns in Lights Out???

I consulted the chat section of the BING search engine, and asked it…

Yes, there are some configurations of the Lights Out game that cannot be solved. In fact, Marlow Anderson and Todd Feil proved in 1998 that not all configurations are solvable. However, it is important to note that these unsolvable configurations are not valid Lights Out puzzles.
– BING AI Chat

Well then. Since unsolvable patterns are not valid for Lights Out, tust turning on random lights is not an acceptable way to start a game.

Side Note: Card games like Solitaire certainly can be unwinnable depending on the order of cards in the deck. I am pretty sure games like Minesweeper are like that, too. But Lights Out patterns are always supposed to be winnable.

It seemed if you started with all lights off, you could simply work backwards by toggling lights on randomly until you got to a stopping point. Whatever pattern that is, the player was assured that there was a way to win. Instead of just turning on specific lights, I could just select a square and allow it to do the normal toggle (that light, plus the adjacent lights).

For my version, I will just make a very simple “initialize game” routine that does this. To do this, I will use a FOR/NEXT loop and generate random X/Y coordinates and call the “toggle” subroutine. This should end up with a random pattern that is 100% solvable.

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

This is what it is doing:

Line 4010 – Since the FOR/NEXT loop will cause a pause, I wanted to print out something to tell the player what was happening.
Line 4020 – A FOR/NEXT loop is done so the random grid selections can be done 10 times. (We’ll improve this later.)
Line 4030 – For X, RND is used to choose a number from 1 to 5. Since the DIM arrays are base-0 (0-4), we subtract 1 so Y will be a number form 0-4.
Line 4040 – Same thing, but for Y.
Line 4050 – We GOSUB to the routine that toggles the specific square (X,Y), and any adjacent squares.
Line 4060 – Continue the FOR/NEXT loop…
Line 4070 – We return back to wherever we were GOSUB’d from.

At the start of the game, we’d just “GOSUB 4000” to initialize the grid. Here is the complete code, so far:

10 REM INITIALIZE GRID
20 GOSUB 4000
30 REM SHOW GRID
40 GOSUB 1000
50 REM INPUT SQUARE
60 GOSUB 2000
70 REM TOGGLE SQUARES
80 GOSUB 3000
90 REM REPEAT
100 GOTO 30

1000 REM SHOW GRID
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)
3020 IF X>0 THEN L(X-1,Y)=NOT L(X-1,Y)
3030 IF X<4 THEN L(X+1,Y)=NOT L(X+1,Y)
3040 IF Y>0 THEN L(X,Y-1)=NOT L(X,Y-1)
3050 IF Y<4 THEN L(X,Y+1)=NOT L(X,Y+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

And it works! Even on a 1980 4K TRS-80 Color Computer (shown here, emulated in XRoar):

But the game still cannot be won because there is no code to check for a win ;-)

Defining a “Win”

Since the goal of Lights Out is to turn all the lights out, winning means that the number of lights that are on is zero. One simple (but slow) way to test for this condition would be to scan through the entire grid and add up how many lights are on.

5000 REM COUNT LIGHTS ON
5005 LO=0
5010 FOR Y=0 TO 4
5020 FOR X=0 TO 4
5030 IF L(X,Y) THEN LO=LO+1
5040 NEXT
5050 NEXT
5060 RETURN

To check, that routine is called. If LO=0 then the game has been won. Since the routine counts the number of “on” lights,, the user could also be told how many lights are on. I would probably add this right after it draws the grid, so the final winning grid is shown before the game ends.

10 REM INITIALIZE GRID
20 GOSUB 4000
30 REM SHOW GRID
40 GOSUB 1000
45 REM CHECK FOR WIN
46 GOSUB 5000
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

For a small 5×5 grid, the CoCo seems plenty fast enough to do this check without much of a delay in between moves. If the machine were very slow, or the grid was very large (and thus, took much longer to check), this might not be the best approach.

Another option might be to start with a count of all lights that are on, and decrement that value each time a light is turned off. If a light is turned on, increment it. If the value reaches zero, the game has been won.

But how do we know which lights are on? We’d could just call our “count lights that are on” function after the grid is initialized and get that value.

Or, maybe we don’t use that routine at all. We could put the count routine directly in the routine that toggles the squares on and off:

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

We could increment some variable every time a light is turned on, and decrement it any time a light is turned off.

It looks like our shortcut of using NOT is going to cause us more work. Since we aren’t manually setting the value to something meaning ON, and something else meaning OFF, we have no place add code to increment or decrement our Lights On count. Had we used 1 for on, and -1 for off, we could just add the value of the square (1 or -1) and been done.

But we didn’t.

We know after the NOT toggle, the value will be -1 or 0. Had it been 1 and -1, counting would be very straightforward. But with -1 and 0, we need to somehow make the -1 (meaning TRUE, a light was turned on) be an increment (+1), and the 0 (meaning FALSE, a light was turned off) to be a decrement (-1).

Side Note: There are many ways to write a program. In this one, I chose an easy way to toggle the lights. At the time, I was not considering counting the lights that were on. This NOT approach adds a bit more work to do the count. It could be that adding extra work here might be larger/slower than just doing a count routine that scans the whole grid. Depending on if we are going for speed or memory usage, the design decisions may need to be different.

Mapping this out, I find a simple solution. I can multiply the value (-1 or 0) by 2, and then add 1.

If the value is -1, multiplying by 2 will make it -2. Then adding 1 will make it -1.
If the value is 0, multiplying by 2 will be 0. Then adding 1 will make it 1.

ON: -1 * 2 = -2 + 1 = -1

OFF: 0 * 2 = 0 + 1 = 1

Well, that gets us a +/- 1, but it is backwards from what I would have preferred. To work around that, I can subtract the value. If you subtract -1, it is like adding one. And if you subtract 1, it is like adding a -1. Easy! :)

The updated routine looks like this:

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

Yuck. But hey, it works!

Now, instead of calling the “count all the squares” routine, we can just reset the LO “lights on” variable during the initialization routine, and it should be decremented/incremented as the game plays.

To test, let’s comment out the call that counts the squares:

10 REM INITIALIZE GRID
20 GOSUB 4000
30 REM SHOW GRID
40 GOSUB 1000
45 REM CHECK FOR WIN
46 REM GOSUB 5000
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

I did a quick test, and this appears to work. It is also faster, since it bypasses the small delay that was happening each time it called the “count all 25 squares” routine. Nice.

Again, the overhead of adding the count in five locations (about 21 bytes each, so 100 bytes extra) does appear to be larger than the “count all the squares” routine. If code size were more important than speed, the count routine would make more sense.

But so far, it still fits on my 1980 4K CoCo with 1514 bytes left to spare (and more room once I remove the un-used “count all the squares” routine). We can add more code! :)

We now have a very primitive but functional version of Lights Out that should guarantee each “random” pattern can be won. The “random” patterns should keep someone from just learning the moves and repeating them to win the level if they play it over and over.

Except they may not be as random as we think.

To be continued…

Sub-Etha Software

"In Support of the CoCo and OS-9 since 1990!"

Category Archives: Retro Computing

The Color Computer 3 Prototype

Prologue – In the Beginning

Part 1 – The Discovery

Part 2 – From Prototype to Pre-Production

Part 3 – Blue Sky CoCo

Let’s write Lights Out in BASIC – part 6

Bigger grid, please

Wrong DIMension

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

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

Let’s write Lights Out in BASIC – part 5

Score (Counting Moves)

Game Over

I give up!

The user interface sucks!

Bigger grid, please

Steve Bjork’s haunted house life…

Let’s write Lights Out in BASIC – part 4

“Random” game variations

Seeding the random number generator

Predictable randomness could be a feature…

Dissecting my VIC-20 Eggs game

My 1983 VIC-20 Eggs game has a typo in the joystick routine

Figuring out what this code is trying to do

Let’s write Lights Out in BASIC – part 3

Game Initialization

Defining a “Win”