Category Archives: CoCo

Tandy/Radio Shack TRS-80 Color Computer (CoCo)

CoCo VR

2 Replies

Over the years, there were a number of cool ideas at Sub-Etha Software that I really wish we’d followed through on. Last year, I mentioned some unfinished software projects I uncovered when going through all my old floppies, but there were also a few hardware projects that never made it out of the idea or concept stage…

Reveal VM100 "voice mail" device for PCs.
Reveal VM100 “voice mail” device for PCs.

For instance, once I found a low-cost gadget at Walmart that interfaced a telephone line to a computer. It was controlled by a serial port, and plugged in to the audio in/out ports of a sound card on a PC. It came with software to turn the PC in to an answering machine.

I bought one to hook it up to my CoCo, and had plans to create a simple CoCo answering machine. On a 128K CoCo 3, it would be possible to play a short greeting, and record a short message from the caller then save it out to disk. Sure, the audio quality would have been poor and it would probably be cheaper to just buy an answering machine, but wouldn’t it be fun?

VM100 ready to hook to a CoCo via cassette cable and RS232 pak.
VM100 ready to hook to a CoCo via cassette cable and RS232 pak.
Concept software was witten (in assembly) to record audio from the VM100 (using 1-bit cassette input, or 6-bit joystick input) as well as play back digital audio.
Concept software was witten (in assembly) to record audio from the VM100 (using 1-bit cassette input, or 6-bit joystick input) as well as play back digital audio.

I was even wanting to do touch tone decoding in software and create a simple voice mail system with mailboxes. There was even a plan to create a “telephone adventure game” where a description would be read and the user could make a choice by pressing buttons on their phone. (Years later, the Tellme company did something similar with a version of blackjack you could play over their 1-800-555-TELL demo line. It was so cool, Microsoft bought them!)

Woulda, coulda, shoulda…

I will try to share some more of these “lost” projects in the future, but today I wanted to focus on a virtual reality project I was working on.

VR was a big buzzword in the early 1990s, and many thought it was going to be the next big thing. As we know know, it fizzeled out rather quickly, with Atari, Sega and Nintendo abandoning their home VR products.

The Atari Jaguar VR project was being done in conjunction with Virtuality, the company I previously wrote about that created the VR game I first experienced.

The Sega VR project has a CoCo connection, since one of the launch titles was being worked on by legendary CoCo game programmer Steve Bjork**! I believe this is the game that Bjork was working on: Iron Hammer

Nintendo’s effort eventually came out as the failed Virtual Boy where, instead of wearing an immersive helmet over your eyes, you peered in to a 3-D viewer that remained stationary on a table. Hey, at least they tried!

But I digress…

In the pre-world wide web days, we had things called catalogs which were like paper versions of Amazon.com. One of the catalogs I received always had interesting items often at cheap liquidation prices. One such item was the VictorMaxx Stuntmaster VR helmet. The wiki page claims this was the very first commercial VR helmet made available.

TODO: I need to add a photo of my VR helmet, as soon as I figure out which storage box it is in.

The Stuntmaster wasn’t a real VR helmet, though. It did not provide a stereoscopic display, and did not have any head tracking capability for use with true VR games. Instead, there was an analog dial on one side that connected to a shaft which you clipped to your shoulder. As you turned your head left or right, the shaft would turn the dial, allowing a simulation of left/right head tracking.

You could plug this helmet up to a Sega Genesis game console and then play some games where you held the game controller to play, but used your head to turn left and right. It seems unlikely that this would have worked well with any games not specifically designed for this, but hey, it was the first.

Here is a video of it in all it’s glory:

Me playing Dactyl Nightmare again in 1994.
Virtuality’s Dactyl Nightmare (I am shown here playing it in Dallas in 1994) had a helmet and a hand grip controller that featured a trigger and a thumb button.

When I saw this in the catalog, I immediately ordered one to see if it could be used with the CoCo. My plan was to send CoCo video and audio to the helmet, then wire the left/right control shaft up as a joystick. Taking a nod from the controls of the Dactyl Nightmare arcade VR game I played, I was going to use the two joystick buttons for “walk” and “shoot”. My thought was you could turn your head left or right, then walk in that direction using the button. I guess I was thinking we’d build a special pistol grip controller to work with the helmet.

I had become friends with Vaughn Cato*, who did the original bouncing ball demo when the CoCo 3 first came out. He had been writing routines to do bitmap scaling and such, and I was hoping to use some of this in some CoCo game projects.

Toast 3-D maze engine by Vaugn Cato.
3-D maze engine by Vaughn Cato. It ran under OS-9.

On of the coolest things he created was a 3-D maze engine that drew everything using lines (I guess we would call this a vector engine). It looked similar to Dungeons of Daggorath but you could move through it in all directions, like Wolfenstein 3-D or DOOM did.

I cannot remember why, but for some reason the demo executable was called toast. It would read a small text file that represented the maze, then you could walk through the maze in 3-D. Things never went much further than the demo, but I thought it would work well with the VR helmet as the basis of some kind of VR maze game.

I think I was planning to create something like Phantom Slayer VR (a tribute to the old MED Systems 3-D maze game by Ken Kalish). I certainly know I had worked on this concept before without VR in mind, as well as a 3-D Pac-Man game. The Pac-Man one was interesting, as I got as far as recreating the original Pac-Man maze in 3-D and had it populated with dots you could walk over to “eat.”

Woulda, coulda, shoulda…

I still have the helmet. Who knows . . . maybe some day CoCo VR might still get done, even if there is no longer a supply for helmets to make it a sellable product.

*Vaughn Cato may be the only former CoCo guy to accept an Oscar. He was working with a company doing motion capture and he was on stage to receive a 2005 Technical Achievement Award. That’s quite the trip from a bouncing ball demo on a TRS-80, don’t you think?

**Steve Bjork has also had encounters with movies. If I recall correctly, he was an extra in films like Rollercoaster and The Goonies, as well as working on movie related video games like The Rocketeer and The Mask. Oh, and his CoCo program Audio Spectrum Analyzer appeared in Revenge of the Nerds, and his CoCo Zaxxon program appeared in Friday the 13th Part 4.

64K TRS-80 CoCo memory test

15 Replies

Updates:

  • 2016/1/19 – Added reference to earlier article about more memory for BASIC (and an excerpt about why BASIC is that way). Also added reference to Juan’s comment on improving the program. Added link to Facebook CoCo group.
  • 2016/9/2 – Removed a duplicate line in the 2nd listing. Maybe fixed a typo or two.
On startup, a cassette-based CoCo has 24871 bytes available for BASIC.

Recently, Richard Ivey became the latest person in the Facebook TRS-80 / Color Computer group to ask how to tell if an old Radio Shack Color Computer had 64K without opening the case. The problem has to do with backwards compatibility. When the original Radio Shack TRS-80 Color Computer was released in 1980, it was sold as either a 4K or 16K system. Later, a 32K model would be available, and the Microsoft COLOR BASIC would give about 24K of free memory (with the rest of the memory used by the video display, cassette buffers, BASIC input buffer, etc.).

Update: See this earlier article about getting more memory for BASIC. Here is an excerpt:

64K NOTE: The reason BASIC memory is the same for 32K and 64K is due to legacy designs. The 6809 processor can only address 16-bits of memory space (64K). The BASIC ROMs started in memory at $8000 (32768, the 32K halfway mark). This allowed the first 32K to be RAM for programs, and the upper 32K was for BASIC ROM, Extended BASIC ROM, Disk BASIC ROM and Program Pak ROMs. Early CoCo hackers figured out how to piggy-pack 32K RAM chips to get 64K RAM in a CoCo, but by default that RAM was “hidden” under the ROM address space. In assembly language, you could map out the ROMs and access the full 64K of RAM. But, since a BASIC program needed the BASIC ROMs, only the first 32K was available.

When 64K upgraded became available, the original BASIC would still only report about 24K free since it had never been modified to make use of the extra memory. Thus, typing “PRINT MEM” on a 32K CoCo 1 shows the same thing it does on a 512K (or greater) CoCo 3.

So how do you tell? One easy way is to just try to load a program or game that requires 64K and see if it works. But, if all you have is the CoCo, there is a short program you could type in to test. (NOTE: See a better listing later in this article.)

10 READ A$:IF A$="X" THEN END
20 POKE 20000+N,VAL("&H"+A$)
30 N=N+1:GOTO 10
40 DATA 34,01,1A,50,10,8E,80,00
50 DATA B7,FF,DE,EC,A4,AE,22,EE
60 DATA 24,B7,FF,DF,ED,A1,AF,A1
70 DATA EF,A1,10,8C,FE,FC,25,E8
80 DATA 10,8C,FF,00,24,0C,B7,FF
90 DATA DE,EC,A4,B7,FF,DF,ED,A1
100 DATA 20,EE,35,01,39
110 DATA X

Thanks to Juan Castro for passing this along. I reformatted it so no line would be longer than the 32 column screen, hoping it makes it a bit easier to type in (though it does make the program longer, needing more, shorter lines).

On a 64K CoCo, this program will copy the ROMs to RAM and then switch in to all-RAM mode. RUN it, then type EXEC 20000 to execute it.
On a 64K CoCo, this program will copy the ROMs to RAM and then switch in to all-RAM mode. RUN it, then type EXEC 20000 to execute it.

I believe this is the classic “ROM TO RAM” (or ROM2RAM) program that appeared somewhere in Rainbow magazine back probably around 1983. Basically, it places the system in to 64K mode (where memory addresses &H0000 to &HFFFF are all RAM) and copies the COLOR BASIC and, if installed, the EXTENDED and DISK BASIC ROMs in to that upper 64K so the system can still work.

If you type this in on a CoCo 1 or 2, then RUN it, it loads a small machine language program in starting ad memory address 20000. After this, you can type “EXEC 20000” to execute that machine language program. If you typed it in correctly, it should just return to BASIC and nothing should seem any different.

But, at this point (if it worked), the BASIC ROM is now in RAM, which means you can POKE to those memory locations and make changes.

Juan suggests an easy hack of changing where the prompt “OK” appears. He says:

Now try POKE &HABEF,89 — OK should become OY.

It worked for me in the Xroar emulator (configuration to emulated a 64K CoCo 2):

The BASIC "OK" prompt is changed to read "OY" (after placing the 64K CoCo in to all-RAM mode).
The BASIC “OK” prompt is changed to read “OY” (after placing the 64K CoCo in to all-RAM mode).

Thus, if you can run this program without it crashing, and that POKE works to change something formerly in ROM, your CoCo is operating in all-RAM mode and must have more than 32K.

In the future, I will have to track down a simpler way to test for 64K. Until then, happy typing…

Update: In the comments, Juan suggested making the following changes, so the program will execute the machine language program for you:

10 READ A$:IF A$=”X” THEN 35
20 POKE 20000+N,VAL("&H"+A$)
30 N=N+1:GOTO 10
35 EXEC 20000:POKE &HABEF,89:END
40 DATA 34,01,1A,50,10,8E,80,00
50 DATA B7,FF,DE,EC,A4,AE,22,EE
60 DATA 24,B7,FF,DF,ED,A1,AF,A1
70 DATA EF,A1,10,8C,FE,FC,25,E8
80 DATA 10,8C,FF,00,24,0C,B7,FF
90 DATA DE,EC,A4,B7,FF,DF,ED,A1
100 DATA 20,EE,35,01,39
110 DATA X

With those changes, now all you have to do is type RUN and it will load the machine language program, execute it (to copy ROM in to RAM), then poke the “OK” prompt to say “OY”. Thanks, Juan!

Carl England writes books, too?

Leave a reply

I met Carl England at the very first Atlanta CoCoFest, I believe, back in 1990. If it wasn’t the 1990 one, it was certainly 1991. I have been a fan of his work ever since. His SuperBoot utility was on virtually every RS-DOS disk I owned that had stuff I wanted to run by typing “DOS”. He is also the guy that demonstrated a Tandy DMP105 printer with an add on that turned it in to a full page scanner. It’s a pity that never made it to market. It was way ahead of its time.

Today I found out Carl has also written a fiction book. He is looking for enouhg nominations on Amazon to get it published. If you don’t mind, take a look:

https://kindlescout.amazon.com/p/GCH5VQG8NI6U

Thanks.

ESP8266 $5 WiFi for Arduino?

Leave a reply

This evening, I saw a reference to something called an ESP8266. A quick web search revealed it was a $5 WiFi chip that was mentioned last August 2014 on Hackaday:

New Chip Alert: The ESP8266 WiFi Module (It’s $5)

As of this writing it has only been about six months since the discovery. At the time, little was known about it beyond some documents in Chinese and some early attempts to write code to use it. Today, however, you can find this part on Amazon for $7.99 with Prime shipping, or much cheaper on e-Bay with slow shipping from China:

http://www.amazon.com/s/ref=nb_sb_noss_1?url=search-alias%3Daps&field-keywords=ESP8266
http://www.ebay.com/itm/ESP8266-Serial-WIFI-Wireless-TransceiveR-Module-Send-Receive-LWIP-AP-STA-SY-/221619180149?pt=LH_DefaultDomain_0&hash=item3399885275

The chip can been hooked up to a UART (transmit and receive), or via SPI. This means, with a cheap TTL-to-RS232 adapter and a power supply, you could WiFi enable anything with an RS232 port with a bit of communications software.

The next time I have a few spare bucks, I plan to order one and see how easy it is to work with. It could be a fun way to WiFi-enable a CoCo or Arduino :)

And for those curious, here is a tutorial on using it I found:

http://www.instructables.com/id/Using-the-ESP8266-module/

Please leave a comment if you have worked with this chipset. It seems it might not take much to make a C library for Arduino that mirrored the official Arduino WiFi shield API, but used this inexpensive part.

CoCo/Tandy 1000 joystick adapter project

4 Replies

Last year, I designed an adapter that would let me use original CoCo (or Tandy 1000) analog joysticks on a modern computer via USB. I also designed an opposite adapter, which would let a modern USB controller be used on an old CoCo or Tandy 1000.

I ordered all the parts for a prototype, and did some quick tests to prove that it worked… And then promptly moved on to other things.

Eventually I found some time and I dug out all of these parts and began wiring things up again. My hope was to have a few things available to sell at the Chicago CoCoFEST this past April 25 and 26, 2015. (Money is very tight here, so any thing I can do to generate some extra income is a good thing.) I was unable to go, so did no more work on the project.

Rather than collect dust, I thought I’d share my work so far in this article I originally started working on last February.

The hardware components I have will allow several things:

For the CoCo

  • Use modern USB joysticks/gamepads on the CoCo
  • Use modem Bluetooth wireless joysticks/gamepads on the CoCo
  • Use modern USB keyboards on the CoCo
  • Use modern Bluetooth wireless keyboards on the CoCo

For Mac/Linux/Windows

  • Use an original CoCo/Tandy 1000 joystick as a USB input device
  • Use an original CoCo/Tandy 1000 joystick as a wireless Bluetooth input device
  • Use an original CoCo keyboard as a USB keyboard
  • Use an original CoCo keyboard as a Bluetooth wireless keyboard

As you can see, there are two main goals (use modern stuff on a CoCo, or use old CoCo stuff on a modern computer), with a focus on USB or wireless Bluetooth. All of these are possible, with the cost of doing Bluetooth about the same (or maybe a few dollars less) than USB.

My current prototype reads a PC USB joystick and turns that in to a CoCo-readable analog joystick. I also wired up CoCo joysticks to use on my Mac (very direct and easy).

The keyboard stuff also interests me. I plan to order the Bluetooth part I need so I can embed it inside my CoCo, hooked to the keyboard connector, and use an external battery powered Bluetooth keyboard on my CoCo.

The other combinations are not high on my project list since I do not even own a wireless Bluetooth gamepad or controller (unless my OUYA console controller can be used). However, when I get to that point, I may be able to find someone I can borrow one from for testing.

My eyesight took a hit last year, and now I can no longer focus on things more than a few feet away so I probably won’t do much until I can afford a new set of glasses ;-) Mid-40s is trying to make me think I’m no longer in my mid-20s!

To be continued…

Introducing the CoCoPilot DriveWire Server

1 Reply

NEW “PRODUCT” ANNOUNCEMENT

Sub-Etha Software is proud to announce plans for its latest bit of vaporware: The CoCoPilot DriveWire Server, or “CoPi” for short.

The CoPi is a tiny device (which is approximately the size of a Raspberry Pi in a case) that comes with everything you need to have a functioning DriveWire server without having to keep your Mac or Windows machine nearby and powered on just so you can type “dir /x0”.

Pricing is to be announced but hopefully it will be around $50. Kit versions will also be available so you can just buy the bits you need in case you already have some of the other bits.

CoCoPilot Configurations

  • Turnkey – This is a “plug and go” version, where all you have to do is install the DriveWire drivers for NitrOS-9, or load the appropriate RS-DOS software (like the special DriveWire version of HDB-DOS), and plug it in. It comes complete with the server hardware, power supply, server-to-CoCo interface device (often called an RS232 cable), and internal solid-state boot device (sometimes called an “SD card”).
  • BYOE – The bring-your-own-everything edition is shipped as a set of simple instructions that will let you transform a boring Raspberry Pi in to the amazing CoCoPilot DriveWrite Server. All you have to do is provide the Raspberry Pi, SD card, RS232 adapter and CoCo serial cable. And do a bunch of typing*. And downloading. And editing. And configuring. But the end result is you have everything that the Turnkey edition has at a fraction of the price.
  • Custom – Also planned to be available are various custom configurations. Already have a Pi? Don’t need another CoCo serial cable? Our custom configuration engineers are ready to custom tailor your order.

Pricing

We estimate complete pricing will be around $50. Or maybe $60. But probably not more than $75.Unless someone really wants to overpay for this.

Availability

The first working prototype was just turned on last night. Quit rushing us. We’ll announce availability when it is ready.

For more information, be sure to follow this blog.

(In case you didn’t get it, I started working with DriveWire on my Raspberry Pi. I will try to document all my steps to make things easier for you if you want to try it. And if you just want a Pi already setup, I’ll probably be able to do that as well.)

* Actually, it’s not really that much typing. I will have a full “from getting a Pi, to using DriveWire” tutorial next. But if you already know your away around the Pi, you pretty much can boot a freshly installed Pi, login and type:

wget http://sites.google.com/site/drivewire4/download/DriveWire4_4.3.3.zip
unzip DriveWire4_4.3.3.zip
cd DriveWire4_4.3.3

Then, you have to edit the “config.xml” file to tell it what serial port you are using. For instance, if you plug in a USB-RS232 adapter, it might appear as device “/dev/ttyUSB0”. You just edit the file and change two bits:

<DeviceType category="device" list="serial,tcp-server,tcp-client,dummy" type="list">serial</DeviceType>

…and…

<SerialDevice category="device" type="serialdev">/dev/ttyUSB0</SerialDevice>

Then all you have to do to start it up is type:

java -jar DW4UI.jar -noui

Tada! Now your DriveWire-enabled CoCo should be able to start issuing commands to the server.

However, DriveWire has many more features that you can only get to using the DriveWire GUI. If you have a display, mouse and keyboard hooked to your Pi, you can instead run the GUI like this:

startx

That will start up the X-Windows desktop GUI on the Pi. Now all you have to do is run the DriveWire GUI. One way to do this is by opening up a Terminal to get to a shell prompt (Ctrl-Escape -> Accessories -> Terminal).

But wait! The GUI requires a few elements that are not part of the default Pi Linux installation, so you need to add them first by typing:

sudo apt-get install libswt-gtk-3-java
sudo apt-get install  libswt-cairo-gtk-3-jni

Now you are ready to run the DriveWire 4 GUI:

cd DriveWire4_4.3.3
java -jar DW4UI.jar

Now you can do things like update the DriveWire software and many other things you cannot do without a mouse (apparently).

Check back later for a full, step-by-step article on taking a fresh out-of-the-box Pi and turning it in to a DriveWire server. (Or I can sell you one already configured.)

An easier way to save your old floppies

Leave a reply

Over in the Facebook CoCo group, Steve Batson pointed out an interesting Textfiles.com product review for a USB 5 1/4″ drive interface.

The FD5025 USB 5.25″ floppy controller by deviceside.com is a $55 interface that lets you plug up a “modern. 1.2M 5 1/4” floppy drive (provide your own drive, case and power supply) and run software on Mac, Windows or Linux to read older 360K floppy disks in to disk image files. Currently, the software understands the following disk formats:

  • Apple DOS 3.2 (13-sector)
  • Apple DOS 3.3 (16-sector)
  • Apple ProDOS
  • Atari 810
  • Calcomp Vistagraphics 4500
  • Commodore 1541
  • Kaypro 2 CP/M 2.2
  • Kaypro 4 CP/M 2.2
  • MS-DOS
  • Motorola VersaDOS
  • North Star MDS-A-D
  • PMC MicroMate
  • Tandy Color Computer Disk BASIC
  • TI-99/4A

Unless it’s doing something special with the file system, I would hope that it could also handle CoCo OS-9 disks (same track/sectors, just different data on the 256-byte sectors).

It looks like a very interesting interface and one that would have saved me a ton of time. BUT, my custom approach let me locate and flag the bad disks and identify the “lost” sectors in the copies (I would write a set pattern to any sector I could not read from the disk — easier to detect later with a disk editor or utility program).

Check it out, and if you have experience with this interface, please leave a comment with your comments…

Invaders09 updated to 1.04

Leave a reply
Invaders09 1.04 title screen.
Invaders09 1.04 title screen.

Sub-Etha Software has released another update to our Color Computer 3 OS-9 space invaders-style game, Invaders09. Version 1.04 is now available and is a recommended upgrade for all users. It supplants previous February 1995 release of 1.03. As with all Sub-Etha Software products, bug fixes and maintenance releases are free upgrades.

You may download the 1.04 update as a self-booting .DSK image from our update server:

http://subethasoftware.com/files/coco/

The INVADE09.DSK image includes a fully bootable version of NitrOS-9 v3.3.0 and may be ran directly on a real Color Computer 3 or emulator just by mounting the image and typing “DOS”. You may also copy the invaders1.04.txt documentation file and CMDS/invaders1.04 binary to your existing OS-9 Level 2 or NitrOS-9 6309 or 6809 system.

1.04 RELEASE NOTES

  • Updated title screen (website, new message).
  • Added “secret” options to help screen.
  • Fixed bug that made font not always load.
  • Fixed shield and border graphics, palette cleanup.

KNOWN ISSUES

  • After 20 years, the game still doesn’t have an “attract mode” or “high score” listing. Maybe 1.05 will be out by 2025 to fix this. (Sorry about that, Bob Devries!)
  • The documentation refers to the binary as being called “invaders” but it is really “invaders1.04” on this release. Maybe the author won’t be so lazy next time and will name the binary correctly.

DOCUMENTATION

File:  INVADERS.TXT - Revision 1.2 (2/7/2015) - By Allen C. Huffman

|   I    NNNNN  VV  V   AAA   DDDD   EEEEE  RRRR   SSSSS   |
|   I    N   N  VV  V   A A   D   D  E      R  R   S       |
|   II   NN  N  VV VV  AAAAA  DD  D  EEEE   RRRRR  SSSSS   |
|   II   NN  N   V V   AA  A  DD  D  EE     RR  R     SS   |
|   II   NN  N    V    AA  A  DDDD   EEEEE  RR  R  SSSSS   |
| 
The Invasion Begins!

By Allen C. Huffman
Copyright (C) 1994,1995,2015 by Sub-Etha Software
www.subethasoftware.com

INTRODUCTION

     For years, determined scientists have probed the endless boundries of the
universe for extra-terrestrial signals.  Countless satellites have been
launched, radio signals transmitted, and theories formulated...all without
results.  Until now...
     Far out in the eastern spiral arm of the galaxy, something was listening.
And this something didn't like what it heard.  Soon outposts around the planet
were picking up masses moving towards the Earth.  The planet was preparing for
first contact, but no signals came from the void.
     The scientists prepared their welcome speeches.  The government, of
course, prepared defense actions.  The tabloids prepared headlines about the
end of the world.  The invasion began.
     Without warning, waves of disc shaped ships filled the skies.  Blasts of
energy were fired on unsuspecting buildings, knocking out military
installations before any retaliation strikes could be launched.  The Earth was
defenseless except...of course...for one last hope.
     The E.T.H.A. (Extra Terrestrial Hope Association) had planned for the
worst when the big day of contact would arrive.  Along with an endless supply
of peaceful translation equipment they possessed an experimental plasma cannon.
 This would be Earth's only chance for survival.
     You, my friend, are the control operator of this cannon.  Good luck.

INSTALLATION

     Invaders09 is a self contained executable called "Invaders".  Copy it to
your CMDS directory.  Usage is as follows:

     Invaders 1.04 by Allen Huffman (alsplace@pobox.com)
     Copyright (C) 1994,95,2015 by Sub-Etha Software. www.subethasoftware.com

     Syntax: Invaders [-opts]
     Usage : LEFT/RIGHT to Move, SPACE to Fire, P to Pause, Q to Quit.
     Opts  : -? = display this message.
             -m = monochrome colors (for 'montype m' displays).
             -z = secret option if you think it is too slow.
             -* = secret cheat mode (press * to skip level).

PLAYING THE GAME

     At the title screen, joystick users should press "J" or the fire button to
start the game.  [Note:  The joystick must be plugged into the left joystick
port.]  For keyboard control, press "K".  "Q" will quit back to OS-9.
     The game will begin and the playfield will appear.  The object is simply
to move your cannon (at the bottom of the screen) left and right to shoot at
the bad guys.  Direct hits are required as any side shots will be absorbed
harmlessly by the invaders.  Also, equipment limitations prevent your plasma
cannon from moving and firing at the same time.  Readouts at the bottom of the
screen display your current score, round, power rating, and lives remaining.

     Scoring:  Each invader you hit earns you 10 points.  Occassionally, a
mother ship ufo will pass across the top of the playfied.  Destroying it is
worth 100 points.
     Rounds:  After clearing out all fifty invaders, a new round will begin. 
The invaders will start closer to the ground.
     Power:  This determines how many shots your cannon can fire at a time. 
Each round gives you an extra shot up to the maximum of "J" (10 shots).  Each
time you lose a life your power goes down by one to the minimum of "B" (two
shots).
     Lives:  You start with three cannons.  Use them wisely.  Without them the
dreaded "Game Over" message will appear.
     Pause:  During game play, press "P" to pause the game.
     Quit:  Pressing "Q" during a game will quit.

     You have three shields to hide under.  Be warned:  They do not protect you
from bombs dropped by the mothership.  Also, when the invaders get low enough
your shields will disappear.  Be warned again.

WINNING THE GAME

     As with all classic arcade games, the enemies are never ending.  Each
level causes the enemies to start closer and closer to the ground and they get
faster and faster.  Good luck!

THANKS

     Special thanks to YOU for helping support the future of the CoCo and OS-9
by supporting vendors such as ourselves.  Without you, our hobby would have
died years ago.

SPECIAL THANKS

     Thanks to Bob Devries, Robert Gault, Colin McKay, Alan DeKok and the late
Alex Forrest for helping beta test this product and get it to this stage.

RELEASE HISTORY

Programming on Invaders09 began on 8/21/94 and it debuted at the 1994 Atlanta
CoCoFest.

* 1.00 09/24/94 - Release version for 1994 Atlanta CoCoFest!
* 1.01 10/26/94 - Robert Gault patch for >512K systems
*                 Since NitrOS9 call does not work for >512K, call removed
* 1.02 01/29/95 - Converting to 16-color gfx screen (whew!)
* 1.03 02/04/95 - Added test for valid screen BEFORE mapping it into MEM R.G.
*                 Moved hiscore and packet (=enemies) to dp. A.H.
* 1.04 02/07/15 - Updated title screen (website, new message).
*                 Added "secret" options to help screen.
*                 Fixed bug that made font not always load.
*                 Fixed shield and border graphics, palette cleanup.

CONTACTING SUB-ETHA:

    Internet: www.subethasoftware.com
    Facebook: www.facebook.com/subethasoftware

Manually making a bootable NitrOS9 hard drive image – part 3

11 Replies

See also: part 1, part 2 and part 3.

  • 2016/04/26 – I had a HUGE mistake in STEP 5 about what to put in LSN0 for the os9boot file size. (It’s sectors, not bytes – oops!) Thanks to Travis Poppe for helping me figure out what was wrong in my instructions. I have marked the updates in red. I will do some testing soon to make sure it is correct now.
  • 2016/05/01 – A minor correction to the instructions, and I added links to DSK images of the BASIC and OS-9 programs in this article, as well as a link to the full 128MB NitrOS-9 image, ready for you to start customizing.
  • 2017/02/05 – Well, this is confusing. Ignore my first correction. LSN 0 needs file size in bytes, not sectors. Correcting again.

As promised in Part 1, and teased in Part 2, I finally present some simple steps to making a bootable OS-9 disk without using “cobbler” or “os9gen”. If I had understood this more back in the early 90s when I was using CoCo OS-9 Level 2 full-time, I don’t think I would have seen nearly as many BOOT FAILED messages :)

Step 0 – Creating a 128MB disk image.

This doesn’t have anything to do with the rest of the article, but it’s good to know. CoCoSDC creates disk images, by default as 35-track single sided images. As you write data past the end of those 35 tracks, the image expands. This can lead to fragmentation and performance issues as the CoCoSDC firmware has to juggle more bits and bytes. Instead, designer Darren Atkinson sent me a simple BASIC program that will create a .DSK image and expand it automatically to the size (in megabytes) you specify. I called mine SDCMAKE.DSK (download the SDCMAKE.DSK disk image here).

10 INPUT "DSK NAME";DN$
20 DRIVE 1,DN$,NEW
30 INPUT"SIZE MB";MB:IF MB>128 THEN 30
40 A=&HFF48:SC=INT(MB*4096)-1
50 B1=INT(SC/65536):B2=INT((SC-B1*65536)/256):B3=SC-B1*65536-B2*256
60 POKE &HFF40,67:POKE A+1,B1:POKE A+2,B2
70 POKE A+3,B3:POKE A,&HA1:POKE A+2,0
80 IF (PEEK(A) AND 2)=0 THEN 80
90 FOR I=1 TO 128:POKE A+3,0:NEXT
100 IF PEEK(A) AND 1 THEN 100
110 POKE &HFF40,0

You can run that from BASIC and make a fresh “128MB.DSK” file to experiment on under OS-9.

Step 1 – Format the hard drive for the 128MB.

To do this, we must configure the /sd1 device descriptor so it provides 524,280 clusters – the most we can have (65535 bytes in the DAM, multiplied by 8 bits per = 524280). I use 65535 ($FFFF) cylinders, 8 sides, and 1 sector-per-track which works out to 524280 exactly.

dmode /sd1 cyl=ffff sid=8 sct=1 t0s=1
format /sd1

NOTE: There may be more values that need to be set. I tried this tonight (2/5/2017) on an old SyQuest EZ135 SCSI drive (128MB as well) and format showed some real weird stuff. I think there were some other options in my SCSI descriptor (clusters, etc.) that I needed to override.

Format should report “Disk capacity: 524280 sectors (134,215,680 bytes)” and you should see “Sectors/track” and “Track zero sect/trk” both at 1 (sct and t0s in the dmode command), and “Total physical cylinders” at 65,535 (cyl in the dmode command). Do not to a PHYSICAL format, and there is no need to Verify unless you just have some time to kill.

Format Note: During the research for this article, I realized that not only is cobbler and os9gen broken in regards to hard drive images, but it appears format is as well. There is a byte in LSN 0 that indicates the type/format (DD.FMT) of the disk. It has bits that are associated with various floppy disk formats, with one representing single-sided or double-sided. It appears that, by default, format will set that side bit if sides > 1. By formatting a hard drive like I suggested (with sid=8), the double-sided bit will be set, and that throws off cobbler and os9gen. If you format using the “1” option, for singled sided, it will NOT set that bit (thus, single-sided) BUT it will override the sid=8 settings (or whatever is in the descriptor). What we really need are versions of these commands that have a “it’s a HARD DRIVE, darnit!” option that will not set those floppy drive bits. I expect this was done long ago when hard drives started getting affordable, but reinventing the wheel is fun so maybe that will be another article…

Step 2 – Copy the kernel track from a bootable disk on sectors $264-$275 to sectors $264-$275 on /sd1.

I did this using a brute-force BASIC09 program: (Download the KERCOPY.DSK disk image here.)

PROCEDURE kercopy
DIM in,out:BYTE
DIM srcDev,dstDev:STRING
DIM sectorNum:REAL
DIM sectorData(256):BYTE

INPUT "Source drive with kernel:",srcDev
INPUT "Destination drive       :",dstDev

OPEN #in,srcDev+"@":READ
OPEN #out,dstDev+"@":UPDATE
FOR sectorNum=$0264 TO $0275
PRINT "Copying sector "; sectorNum; " from "; srcDev; " to "; dstDev
; "..."
SEEK #in,sectorNum*256
GET #in,sectorData
SEEK #out,sectorNum*256
PUT #out,sectorData
NEXT sectorNum
CLOSE #out
CLOSE #in
END

Please note that this program does no error checking. When you run it, you would type in “/sd0” for the source disk (if that is the one with your kernel boot track) and “/sd1” for the destination. It will then simply read all the boot track sectors from /sd0 and write them to the same place on /sd1.

Given a bit more time, I need to make that program take care of this next step so it does not have to be done manually… At that point, it would be a nice replacement for cobbler, almost.

Step 3 – Mark sectors $264-$275 as used to prevent files from overwriting the “hidden” kernel track.

I use dEd to edit the hard drive in raw mode (/sd1@)  and then just find the 18 appropriate bits in the DAM (disk allocation bitmap) that represent the 18 sectors of the kernel track and set them.

The boot track is located on sectors $264-$275 in the DAM (disk allocation bitmap). The DAM starts at LSN 1. You basically want to set the 18 bits that represent sectors $264-$275. They reside in bytes $14C, $14D and $1FE:

  • offset $14C = $0F (00001111)
  • offset $14D = $FF (11111111)
  • offset $14E = $FC (11111100)
ded /sd1@
CMD: s 1 [ENTER] (skip to LSN=$01 one)
CMD: e (edit mode)
Cursor over to row 04, column C and change that to $0F
Cursor over to row 04, column D and change that to $FF
Cursor over to row 04, column E and change that to $FC
[ENTER] to exit edit mode
CMD: w (to write sector)
Are you sure? y (yes, you are sure)

Step 4 – Copy your OS9Boot file over to /sd1. If this disk is freshly formatted, it should copy as a contiguous (non-fragmented) file.

copy /sd0/OS9Boot /sd1/OS9Boot

Step 5 – Mark the location and size of the bootfile in logical sector 0. This is how the booter knows where to find OS9Boot.

To do this, I do a “dir -e /sd1” and note the “Sector” and “Bytecount” (size) fields. In my example, dir reports OS9Boot is at Sector 109 and has a Bytecount (size) of $5EDD. The sector reported is NOT the one we want to use. That sector is where the File ID sector is for OS9Boot. File ID is what contains the attributes, owner, creation date, etc. as well as the segment list. For a fragmented file, the File ID sector may contain up to 48 entries of different file segments.

Using “ded /sd1@” again, first we want to verify where OS9Boot is. Open dEd, and skip to the sector that was shown in the “dir -e /sd1” output:

ded /sd1@
s 109 [ENTER] (skip to sector shown in the dir -e display)

That sector should have some data on the first row (00), and a few entries on the second row (10). The second row is what we really want. The first three bytes (offsets $10-$12) are the starting sector for the segment (where OS9Boot really begins), and the next two bytes (offsets $13-$14) are the size in sectors.

On a freshly formatted disk, the starting sector should be one higher than what “dir -e” showed. On my system, it is “00 01 0A” ($10A is the sector after the directory entry at $109).

Just to make sure you have the correct starting sector, in dEd you can skip to that sector (“s 10a [ENTER]”) to look at it and see if it is the kernel. On the top line of the ASCII display on the right you should see the module name embedded in there. In this case, “KrnP2”. That confirms sector $10A is indeed the kernel.

From the NitrOS-9 Technical Reference manual “Identification Sector (LSN 0)” on page 57:

Name    Rel.  Size  Use
        Addr  (Bytes)
DD.TOT  $00   3     Number of sectors on disk
DD.TKS  $03   1     Track size (in sectors)
DD.MAP  $04   2     Number of bytes in the allocation bit map
DD.BIT  $06   2     Number of sectors per cluster
DD.DIR  $08   3     Starting sector of the root directory
DD.OWN  $0B   2     Owner’s user number
DD.ATT  $0D   1     Disk attributes
DD.DSK  $0E   2     Disk identification (for internal use)
DD.FMT  $10   1     Disk format, density, number of sides
DD.SPT  $11   2     Number of sectors per track
DD.RES  $13   2     Reserved for future use
DD.BT   $15   3     Starting sector of the bootstrap file
DD.BSZ  $18   2     Size of the bootstrap file (in bytes)
DD.DAT  $1A   5     Time of creation (Y:M:D:H:M)
DD.NAM  $1F   32    Volume name in which the last character has the most significant bit set
DD.OPT  $3F         Path descriptor options

We will want to put the starting sector (that we got from dEd) as three bytes at offset $15 of LSN 0. We will want to put the byte count (that we got from dir) as two bytes at offset $18 of LSN0.

Now just skip back to LSN 0 and type in the starting sector for the OS9Boot module and it’s size. These go at offset $15-$17 (starting sector) and $18-19 (size in bytes). Basically, you want to edit $15-$19 to be the three bytes that were at $10-$12 in the files’ ID sector, and the two byte size (from dir). In my case, I put in “00 01 0A FE DD” to match the start of my boot file ($00010A) and it’s file size ($FEDD).

s 0 [ENTER]  (skip to Logical Sector 0)
e (to enter edit mode)
Cursor over to row 10, column 5. Change three bytes to the start LSN:
00 01 0A (for me)
Cursor over to row 10, column 8. Change two bytes to the os9boot size:
5E DD (for me)
[ENTER] to exit edit mode
CMD: w (to write sector)
Are you sure? y (yes, you are sure)

Now the kernel track is where the “DOS” command will find it, and its sectors are marked as used to other files will not overwrite it.

OS9Boot has been copied over (and must be contiguous) and LSN0 has been updated to point to where the file starts and how big it is.

Step 6 – The only thing left to do is copy over the other needed files, which at a minimum should be “shell”, “grfdrv” and “sysgo”:

makdir /sd1/CMDS
copy /sd0/CMDS/shell /sd1/CMDS/shell
copy /sd0/CMDS/grfdrv /sd1/CMDS/grfdrv
copy /sd0/sysgo /sd1/sysgo

At this point, you now have a minimally bootable OS-9 hard drive (though it has no commands or anything useful on it yet). You might want to also include utilspak1 (common commands) and the base startup file (which will load them):

copy /sd0/CMDS/utilpak1 /sd1/CMDS/utilpak1
copy /sd0/startup /sd1/startup

I hope this walkthrough demystifies the OS-9 booting process. In a future article, maybe I can present code in BASIC09, C or assembly (or maybe all three versions) that does all of this for you.

2016/5/1: You can download a 128MB disk image here that is the results of me performing this steps tonight.

Until then … tips are always welcome :)