Category Archives: CoCo

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

Sub-Etha Software to attend 2018 Chicago CoCoFEST!

FOR IMMEDIATE RELEASE:

Sub-Etha Software to attend 2018 Chicago CoCoFEST!

Des Moines, Iowa – January 11, 2018 – Iowa-based Sub-Etha Software has announced plans to attend the 2018 27th Annual “Last” Chicago CoCoFEST! The event will be held April 21 and 22, 2018 at the Heron Point Convention Center in Lombard, Illinois.

“We’ve missed a number of years over the past decade or so, but we don’t plan to miss this year,” says Sub-Etha co-founder and current operator, Allen Huffman. “Missing these shows sucks. And this year we don’t want it to suck.”

Sub-Etha Software plans to demonstrate Roger Taylor’s “CoCo on a Chip” FPGA project, as well as a few “vaporware” items from the company’s past, including the CoCo-VR project and CoCo Answering Machine project.

A selection of N.O.S. (new old stock) Sub-Etha items may be available on (probably unreadable) 5 1/4″ floppy disks in original (“vintage”) packaging.

There will not be any Jolt! Cola, because that no longer exists. And there might even be Jolt Cola, because thanks to a tip from L. Curtis Boyle in the comments, it went back in to production in late 2017!

About Sub-Etha Software

Sub-Etha Software was founded in Lufkin, Texas in 1990, as a partnership between Allen C. Huffman and Terry S. Todd. It made it’s first CoCoFest appearance at the First Annual Atlanta CoCoFest in 1990, and it’s first Chicago CoCoFest appearance at the First Annual “Last” Chicago CoCoFEST! in 1992. They may be contacted online at www.subethasoftware.com

About the Chicago CoCoFEST!

The 27th Annual “Last” Chicago CoCoFEST! is sponsored by the Glenside Color Computer Club of Illinois. They may be contacted online at www.glensideccc.com.

Contact:
Allen Huffman
alsplace@pobox.com
PO Box 7634,
Des Moines, Iowa
U.S.A.
Ph: 515-999-0227

###

Revisiting Rainbow magazine.

Happy 2018!

Can you believe this year will mark 38 years since Radio Shack released the TRS-80 Color Computer (later nicknamed the “CoCo”)? According to the always reliable wikipedia, the Color Computer was announced on July 31, 1980. According to a calendar printed in the July 1987 issue of Rainbow magazine, the CoCo was introduced (made available for sale?) on August 20th that same year:

August 1987 Rainbow, anniversary souvenir calendar: “August 20 – Radio Shack introduces the 4K TRS-80 CoCo for $399. First computer to offer easy graphics and  sound programming from BASIC. 1980”

That date always stuck with me because it is my birthday. Too bad I didn’t know anything about computers in 1980, else I might have asked for one. Instead, I didn’t get switched on to computers until a few years later, with my first machine being a Commodore VIC-20 (“the first full featured color computer for under $300”) in 1982.

In my early days of owning a computer, I also owned some computer magazines. I remember Family Computing, COMPUTE! (wow, they published in until 1994), and later COMPUTE!’s Gazette, which focused on the Commodore VIC-20 and 64 (wow again, for them publishing until 1995). Somewhere I still have a box with all my old magazines in them.

When I switched from VIC-20 to Color Computer in 1983, I was still able to make use of some of those early magazines that contained CoCo versions of program listings. I remember being annoyed at seeing the CoCo version rely on BASIC’s single-note “PLAY” command for music, while they had to use assembly language routines to do the same on the Apple 2. If they were using assembly code, they could have done the same on the CoCo and gotten 4-voice harmony music out of the machine! But instead, that “easy graphics and sound programming from BASIC” must have made sticking with one-voice music the easier path. I think that always made the CoCo versions look worse than they had to.

Shattered by a Rainbow

At some point, I learned about an all-Color Computer magazine called The Rainbow. I think my first copy of Rainbow was the November 1983 “Data Communications” issue. I’ll have to dig out my storage box and see how well my memory has held up over the past 35 years!

In a way, it destroyed some of my hopes and dreams. When I made the decision to get a CoCo, part of the reason was because of the small selection of software Radio Shack sold for it. I thought, with such a small software base, it would be a great system to program for! I could become rich in such a desolate marketplace!

The 300+ pages of Rainbow, full of program listings and ads for hundreds of software and hardware items, made me give up those dreams. Looking back, I wish I hadn’t. The market was large enough for some programmers to make their living off of it. Even in the late 1980s, I heard about one shareware programmer who helped pay his way through college by writing CoCo software!

In addition to Rainbow, I also learned about two other CoCo-only publications. Color Computer Magazine was published from March 1983 to October 1984. There was also Hot CoCo (Wayne Green Publications), which lasted a bit longer, publishing from June 1983 to February 1986. (Those links lead to full scans of all the issues over at the Color Computer Archive site.)

Although I did buy a few issues of Color Computer and Hot CoCo, the only one I subscribed to was The Rainbow. As a junior high school student, I didn’t have the income for multiple subscriptions, though I wish I had – I expect I would have benefited from the other two publications.

I chose Rainbow because it was the largest. In December 1983, Hot CoCo had 148 pages, Color Computer Magazine had 146 pages, and Rainbow was larger than both of them put together at 340 pages!

I could read through the two smaller ones, and probably find an article of of interest, but Rainbow always seemed to have dozens of things I liked. If I could only afford one, it just made sense to go for the biggest. (At the time, Rainbow was more expensive, with a cover price of $3.95 versus $2.95 for the other two.)

Back to the Beginning

Sometime in early 1985, I must have been contemplating completing my collection of Rainbow because I decided to order a back issue of the first issue from July 1981. I think I spent $2.00 or so for the issue, plus $3.50 postage and handling.

Imagine my disappointment and surprise when it arrived and it was a photo copy of two sheets of paper, printed doubled sided by a dot matrix printer that didn’t even have true descenders for lowercase!

Could this be? Did this nearly-400 page behemoth of a magazine with it’s glossy, full color cover really start out as a two page newsletter?

Indeed it did!

But rather than complain, I ended up writing in to The Rainbow and suggested that reprinting this early issue inside the magazine would be a neat thing to do. In the July 1985 anniversary issue, they printed my letter and included a reproduction of that original two page newsletter:

August 1985 Rainbow, letters to the editor.

Editor:
I have an idea for your upcoming anniversary issue that you may like. I was told that THE RAINBOW started off as ·a two~page newsletter. Since many CoCo owners were not a part of that beginning, me included, I thought it would be nice to
see some reprints of the “early RAINBOW.” You may not think this is a big deal, but I would be more than happy to see how the # 1 CoCo magazine got its start. I think others share this curiosity as well as I do.
Allen Huffman
Broaddus, TX

Editor’s Note: Great idea, Allen. So, for Allen and all of you helping us celebrate our fourth anniversary, we’ve reprinted our very first Issue in its entirety in this issue (see between pages 98 and 99) – a little birthday treat from all of us to all of you!

I think I had at least two other letters printed in the magazine, but this was the one I was most proud of. (Notice my little white lie about “I was told that…”  I knew darn well it was a two page newsletter because I felt ripped off paying over five bucks to get a copy of it!)

Let’s do the time warp, again!

The days of monthly magazines with computer programs you could type in is long gone. But, the history of them has been preserved thanks to the efforts of folks willing to scan in old paper and make it available online for a new generation to discover (or for us old folks to use to relive our younger years).

You can find issues at Archive.org, but I think the best collection is at the previously-mentioned Color Computer Archive site:

Rainbow, The (Searchable Image)

That link will take you to a repository that contains scans of every issue of Rainbow, from the original two page newsletter in 1980, to the largest of the glossy magazine editions, down to the final newsprint issue of May 1993. Some scans are just images of the pages, but the above link had been OCR’d so you can do text searches on it (mostly).

Until these archives, I had only seen the issues that I owned, from November 1983 to sometime around 1991. I recall ending my subscription in protest because Rainbow had decided to not cover any of the “next generation” CoCo-style machines such as the MM/1. Looking back, that was something I regret. Had we all kept subscribing and supporting them, maybe they could have continued a few years longer.

With all of this said, I have decided to start an interesting project. I plan to read all the issues of Rainbow, starting with July 1981. I’ve actually made it through the first six issues, where it grew from two photocopied pages into the first “magazine style” issue with 19 pages in December 1981.

And boy is it a time travel experiment! It’s stunning to see the tiny thing that birthed the magazine I loved so much.

If you are looking for some retro reading for 2018, why don’t you join me? I bet we (re)learn many things over the course of the year.

It’s quite interesting reading news about Radio Shack working on a “disc system” for the Color Computer, and then reading a review of this new $600 add-on a few issues later. That, and all the mentions of COLOR BASIC, and why you might want to upgrade to 16K or 32K and EXTENDED COLOR BASIC, really take you back to an earlier time.

And I have yet to see the name “CoCo” used. That would come later.

I’ll share interesting tidbits as I run across them. I’m sure I will learn quite a bit about the early years before I was involved.  Maybe you will to.

Until next time…

A Time Travel Experiment: The retro newsletter project proposal

The internet is an interesting place. Quite often, things I am trying to find end up not findable (far too often), but I almost always end up somewhere I didn’t intend to be finding something I didn’t mean to find.

Recently, I went in search for a Chromaset game that was referenced by L. Curtis Boyle on CoCoTalk Live (the nation’s leading weekly Color Computer talk show) episode 17. A reference had been made to this “Zero Gravity” (I think that was the title) game being disassembled and ported to OS-9, and I was curious to see what kind of game it was.

During this search, which was unsuccessful, I ended up at some random home page that had an archive of newsletters in PDF format. The one I found was from 1983, and it contained a review of the Chromaset subscription service (which I think was a cassette tape full of programs you received each month).

It was a fascinating read, including an article talking about rumors that Radio Shack was working on a “CoCo III” model. (That article was a gag, though, but no doubt rumors of a CoCo 3 must have started circulating as soon as the CoCo 2 came out.)

Reading through this newsletter was like stepping back in time. 1983 was when I received my first Radio Shack Color Computer. I remembered newsletters like this.

Today, archive sites like archive.org and the Color Computer Archive do a great job at trying to preserve much of this old information. I have scanned and submitted several newsletters and manuals, myself. One could easily spend weeks going through all that is there, which is why I expect none of us have done it. (I wasn’t even aware of this “ETUG” newsletter until I stumbled on it accidentally.)

Wouldn’t it be neat…

With retro computing so popular these days, wouldn’t it be neat if there were some kind of subscription service that would mail you physical paper copies of newsletters from the past, on a schedule just like they were back then? I’m not talking about anything new, but actually representing a point in time as if you were subscribing to them back then.

All it would take is finding as many of these newsletters as possible and getting them organized by date. Then, when someone subscribed, they’d start receiving newsletters each month, starting with the earliest time available.

Or, you could sign up starting at a specific month (say, the year you first got your computer).

Subscribers wouldn’t be in sync with each other, so discussing the “latest” news would be problematic, but since all of this exists digitally, it would be as simple as…

Hey, I just got the August 1983 issue of CoCo Chronicles out of East Texas. There’s this cool BASIC program that makes sound like a synthesizer with no machine code! Here’s a link to the PDF of the issue

Think of all the great tips and programs we’d (re)discover this way, as a new generation wades through the cutting edge information of 35 years ago.

There might even be a way to automate something like this, through a service that will print and mail on demand.

Sure, we can all go download any of these for free… But have we? It’s much easier to pay attention to something when it shows up at your house, versus you having to remember to go out and find it. (Amazon, anyone?)

There are some problems, of course: Copyright. Low quality scans of copies that might be hard to read. Zero interest in this…

But if such a service existed, would you sign up? How much would you be willing to pay? Who would have the time to run something like this?

Discuss.

1985 unlicensed Dr. Who game for the CoCo

In 1985, a new game was advertised by Prickly-Pear Software for the Radio Shack TRS-80 Color Computer:

DR. WHO

Here is the ad found on page 68 of the the December 1985 issue, typos and all:

Dr. Who ad in the December 1985 Rainbow magazine.

As a kid who had watched Doctor Who on the local PBS station in Houston, Texas, I just had to have this game. I had just moved from Houston to the tiny town of Broaddus (population 225) and no longer could receive a PBS station, so this would be as much Doctor Who as I would get while living there.

I do not think I even had a disk drive of my own yet, since I recall ordering this on cassette.

In those days, us kids would go down to the post office and buy a money order and mail it to the company, then wait for them to mail back the software. This really helped build up anticipation.

Finally, the game arrived:

Dr. Who by Larry Lansberry, as sold by Prickly-Pear Software.

It came with a manual, which I have yet to locate. When I find it, I will scan it and upload it to the Color Computer Archive. Fortunately, it at least has some instructions:

Dr. Who instructions, page 1.

Dr. Who instructions, page 2.

And, the promise of many levels of difficulty:

Dr. Who difficulty levels.

I was a bit disappointed to find that the game was written in BASIC. It also included one machine language program called “CTRYROAD.BIN.” This was a multi-voice music file that played John Denver’s Country Roads hit from the 1970s. And it played it while displaying the instructions, so you had to sit there for several minutes until the song was complete.

After this, the game would present some side scrolling text explaining what keys did what. Thank goodness for the manual! The text went by pretty quick.

After several minutes of generating data for the game, you were presented with the main game screen:

Dr. Who main game screen.

And, you also had the map view:

Dr. Who map view.

There were also animated scenes that showed the TARDIS descending to the planet’s surface, but without the manual, I cannot remember how to even get to the planets.

But … the effect was less than impressive. It was a very disappointing purchase from a cosmetic and user-interface standpoint.

HOWEVER, the actual game was quite good. It reminded me of the Star Trek-style games where you moved around a galactic grid in search of starbases and Klingons.

I must have written Prickly-Pear Software because somehow I got in touch with the author, Larry Lansberry, and we exchanged some letters. I recently found some of these letters, so I need to re-read them and see what we discussed. I know he explained the music choice and why the animation style was done like it was.

I always thought this game would be fantastic with a facelift. Perhaps now that it has been unearthed, someone may consider doing an update/remake of it.

You can try it yourself in a CoCo 1/2 emulator. The disk image is available here:

http://www.colorcomputerarchive.com/coco/Disks/Games/Dr.%20Who%20(Prickly-Pear%20Software).zip

And, just for fun, an old Doctor Who music demo I wrote has also been posted:

http://www.colorcomputerarchive.com/coco/Disks/Demos/Dr.%20Who%20Demo%20(Allen%20Huffman).zip

Doctor Who music demo.

Side Note: I don’t think Zigwald X. Malushi was a real person, and if he was, he had nothing to do with this demo. I used to see that name pop up on random pieces of software, often of the “questionable” nature. Since I was posting a copyrighted tune, I did not want to post it under my name so I used that one. I should find some of the other “Zigwald” programs and make a collection of them. I wonder how many used that name.

Enjoy!

Getting started with Roger Taylor’s “CoCo on a Chip” FPGA CoCo 3

NOTE: This is a work-in-progress. Check back for updates. I will note any revisions at the top of this article.

Updates:

  • 2017-03-19 – Fixed a typo (thanks, Roger), and minor clean up.

Cyclone CoCo – Roger Taylor’s FPGA CoCo on a Chip

In July 2015, Roger Taylor began the process of recreating a CoCo 3 system in an FPGA (field programmable gate array). Using a low-cost (less than $80) Terasic DE0-Nano development board and a custom I/O add-on board, he quickly got a virtual CoCo running. He has been continually improving the system and adding more features. His “CoCo on a Chip” Facebook group has documented this every step of the way.

Last year, I had acquired one of these DE0-Nano development boards and the RGB22VGA add-on board from Ed Snider. I was planning on using it to hook my old CoCo 3 up to a borrowed VGA monitor. But, at last year’s 25th annual CoCoFEST! near Chicago, Mark Marlette of Cloud-9 was selling his all-in-one version of this RGB to VGA adapter. I picked on of those up, and never used the DE0-Nano.

Roger recently sent me one of his add-on boards so I can finally put together my own FPGA CoCo. Let’s see how it goes…

Hardware Required

  1. Terasic DE0-Nano Development and Education Board. These list for $79 on the manufacturer’s website ($61 for academic purchasers). It comes with a retractable USB Mini cable, which will be used to program the FPGA.
  2. Roger Taylor’s Terasic DE0-Nano Upgrade Daughter Board. He sometimes has these available completely assembled for around $99 (via his e-Bay store). You can also just buy the bare boards and build one yourself.
  3. SD memory card. Currently, the project does not support SDHC cards, so you have to find an older, smaller capacity SD (SDSC) card like a 2GB. I picked up a Transcend 2GB card on Amazon for about $7.
  4. PS/2 Keyboard (and optional mouse). I have never owned anything that used PS/2, so I didn’t have an old keyboard to use. I found a cheap Logitech Classic Keyboard K100 on Amazon for $11.99.
  5. VGA Monitor. I have one I borrowed to use with my CoCo, but I think VGA ports can still be found on some modern monitors.
  6. USB Power Supply for the DE0-Nano. You can use the included USB Mini cable and use a USB power port, or use a similar USB charging cable with a Mini connector.

A cheap PS/2 keyboard, 2GB SD card, DE0-Nano and Roger’s add-on card.

About Roger’s Terasic DE0-Nano Upgrade Daughter Board

Roger’s add-on board has RAM, two PS/2 style ports, a 1/8″ audio output jack, and VGA port. There are header connectors for plugging in a module that handles the SD card, and ones for WiFi and Bluetooth. My unit has The SD card and WiFi installed. I will be ordering a Bluetooth module for wireless serial ports (they are very cheap).

The card has writing along the bottom indicating which direction it should be plugged up tot he DE0-Nano: “Faces DE0-Nano USB connector –>>”:

Writing on the board points the way to proper installation…

You can also tell orientation by the cutout in the board, which lines up with some small 2-pin connector on the DE0-Nano below:

Cutout in the board allows access to a connector below.

Software Needed

  • Roger recommends installing the Quartus II programming app. (Smaller than having to install the full Quartus II IDE).
  • You will also need to install the USB Blaster device driver, which will be found in the install directory of the programming app.
  • You also want the latest Cyclone CoCo firmware from his Facebook group. He calls it Cyclone CoCo, for reasons that will become obvious once you start using it :)

Installing

It seems the first step will be to install the Terasic software, and then hook the DE0-Nano up and load Roger’s firmware. The software is only available for Windows and Linux. Since I am a Mac user, I will either have to run it via virtualization (I use Parallels Desktop and Windows 10) or find a PC to use. I have several Raspberry Pis running Linux, so maybe that is an option as well.

After that, you will have to install a driver, and lastly you will be able to load Roger’s firmware on to the device and turn it in to an FPGA CoCo. Here are the steps I took:

Step 1: Install the free programming app.

Download it here:

https://www.altera.com/downloads/software/prog-software/121.html

I am using the Windows version, so my screen shots will be from that version.

Installing the Stand-Alone Quantus II Programmer from Altera.

This will make available a program called “Quartus II 12.1 Programmer” in the Altera 12.1 Build 177 folder.

NOTE: Your version number may be different if you are using later or earlier versions than I have. If you are setting up one of these, I’m sure you can figure that out.

Step 2: Install the USB driver.

When you plug in the DE0-Nano to the computer, Windows should prompt you for a driver. My Windows 10 did not, so I had to manually install it. If yours does, you can skip the next step and go straight to how to browse to the driver.

First, I had to open the Device Manager and find the USB-Blaster in the Other devices section:

Device Manager showing the USB section, missing the driver.

Double clicking on USB-Blaster brings up information about the device:

USB-Blaster needs a driver.

Select “Update Driver…” and then choose “Browse my computer for driver software“. You have to manually tell it where the driver will be found (inside the programmer install directory):

Select the second option so you can browse to where the driver is located.

On my system, I used the default install location and the driver was located here:

C:\altera\12.1\qprogrammer\drivers\usb-blaster\

Browse to the drivers directory inside of the programmer software directory.

Your directory names may be different, depending on what version of the software you install. Browser there, and then click Next:

The system should find the driver and install it.

Step 3: Program the DE0-Nano

Plug in the DE0-Nano to a USB port using the included cable, then launch the Quartus II 12.1 Programmer application.

Quartus II 32-bit Programmer showing No Hardware.

If your Hardware Setup box says “No Hardware”, click the Hardware Setup button and select “USB-Blaster“:

Select the USB-Blaster device.

After you close that windows, you can use File->Open to browse to and load the FPGA firmware image you downloaded from Roger’s Facebook page:

Load Roger’s firmware image.

When it is loaded, you will need to check off “Program/Configure” and (probably optional) “Verify” to enable the Start button:

Firmware loaded and ready to program.

Once those two buttons are checked, you can then click Start to begin programming. After a few moments, you should see “100% (Successful)” in the top right green box:

Programming in progress. It only takes a few moments.

Congratulations! You now have an FPGA CoCo!

Hello, FPGA CoCo!

After these steps, I plugged the device up to a VGA monitor and plugged in my PS/2 keyboard to the left port, and powered it up. It should instantly come to life with a familiar green screen, but if you have not prepared the special SD card for it yet, it will hang, trying to boot from that card.

You can hold down ESCape when you power up to bypass that, and find yourself at a nice virtual CoCo:

Hello, FPGA CoCo!

In the next part, I will figure out how to configure the SD card so I can actually load some software on it, and save any programs I create.

Until then … wow. This was easy! I can’t wait to see what all it can do. Thanks, Roger!

Sir Sound prototype, version 2.

Now working without the crystal. This is using a Teensy and one of the pins to generate a 4mhz signal. I will post a video in coming days, hopefully, as soon as I have some CoCo BASIC code talking to it.

The green and black wires running off of it wold go to a headphone jack that the cassette cable could plug in to so you could feed Sound back to the CoCo without needing to use an external speaker. AUDIO ON!

Introducing the Sir Sound CoCo Sound Card

NEW “PRODUCT” ANNOUNCEMENT

The team that brought you* the CoCoPilot DriveWire Server is proud to announce their latest innovation:

“Sir Sound”

Sir Sound is a solid-state multi-voice audio synthesizer that operates over a serial transport mechanism**. It provides arcade-quality*** sound with up to three independent tonal voices plus one white noise channel all in an external module that doesn’t require voiding your warranty to install. In fact, you won’t even need tools!

Pricing is to be announced but hopefully it will be around $50. Or maybe $30. Or cheaper. Or less if you build it yourself. Heck, we’ll probably just make kit versions available since we don’t really like to solder.

Sir Sound Configurations

  • Turnkey – This is a “plug and go” version where you just plug it in and go. No special drivers are needed, as they are already built in to both BASIC and OS-9.****
  • BYOE – The bring-your-own-everything edition is shipped as a set of simple instructions containing a parts list and how to run wires between the parts.
  • Custom – Also planned to be available are various custom configurations, like what color of case it comes in.

Pricing

We estimate the thing is gonna cost us, like, ten or so bucks to make using off-the-shelf parts ordered in small quantities from China. But, to make it a product, we really should have an integrated circuit board and a case made, which will run the costs up dramatically. Rest assured, we’ll pass those unsavings along to you!

Availability

The first prototype is in the process of being tested. Quit rushing us. We’ll let you know when it’s done.

Specs

Basically it’s a Texas Instruments SN76489 sound chip hooked to a tiny Arduino micro-controller with a TTL-to-RS232 adapter. Here’s the prototype John Strong of StrongWare sent me:

SN76849 sound chip hooked to an Arduino Nano on a neat 3-D printed platform from StrongWare.

You kinda have to use some micro-controller since the sound chip turns on and starts making sound. Something has to issue the “shut up” instruction to it. If you just had hardware to translate a serial byte in to the command, and made the CoCo do all the work, the CoCo would have to load and run a program to shut the thing up every time you powered up. Fortunately, a custom-built Arduino that handles this can be done for like $5. There are cheaper PIC chips that could do it for less.

Then, you add a MAX232 type chip that goes from the TTL signal levels of the Arduino to RS232 signal levels, or using one of these $3 (or less) boards that’s already wired:

TTL-to-RS232 adapter.

Lastly, add a CoCo serial cable (4-pin DIN to DB9), and you are set.

Prototype “Sir Sound” sound module for the CoCo (or anything with a serial port, actually).

A small program on the Arduino will monitor the serial port for bytes and then relay them to the sound chip.

By doing some POKEs in BASIC to set the baud rate, you could make music by doing things like this:

REM PLAY MIDDLE C
PRINT #-2,CHR$(&H8E);CHR$(&H1D);CHR$(&H90);

FOR A=1 TO 1000:NEXT A

REM VOLUME OFF
PRINT #-2,CHR$(&H9F);

The notes always play, so you shut them off by setting volume off. There are different channel values for each of the four channels.

I envision having a “raw” mode where the device just translates the bytes from serial to the sound chip, and a “smart” mode where you could use an API and just send note values (like 1-88 of a piano keyboard, or MIDI note values).

“Smart” mode could simplify the control so it might look like this:

REM ALL DATA: PLAY CHANNEL 0, NOTE 10, AT VOLUME 15
PRINT #-2,CHR$(&H00);CHR$(&HA);CHR$(&HF);

REM NOTE ONLY: PLAY CHANNEL 0, NOTE 10
PRINT #-2,CHR$(&H01);CHR$(&HA);

REM NOTE ONLY: PLAY CHANNEL 1, NOTE 10
PRINT #-2,CHR$(&H11);CHR$(&HA);

REM VOLUME ONLY: CHANNEL 0, VOLUME 5
PRINT #-2,CHR$(&H20);CHR$(&H5);

And, I could also add a “super smart” mode where it could parse PLAY command-style strings, then spool them in the background while you do other things:

REM PLAY COMMAND, CHANNEL 0
PRINT #-2,CHR$(&H30);"CDEFGAB";

And, a “super super smart” mode could let it store string sequences, and play them by triggering with a simple byte:

REM STORE NOTE SEQUENCE 0
PRINT #-2,CHR$(&H40);"CCDCECFECCDCECFE";CHR$(0);

REM PLAY NOTE SEQUENCE 0
PRINT #-2,CHR$(&H50);

REM PLAY NOTE SEQUENCE 0 FIVE TIMES
PRINT #-2,CHR$(&H55);

…or whatever. You could sequence them together, like MIDI sequencers do, and have complex patterns that could play in the background while the program does other things.

There are lots of possibilities. We could even see about using the Carrier Detect line as a way to tell if the sound card was still playing something (rather than needing routines to read data back from the device, which would be doable but not from BASIC without assembly language code).

If this “sounds” fun to you, leave a comment…

Until then…


Notes:

* If you call making a blog post “bringing it” to you.

** It plugs in to the Serial I/O port. “Sir” sounds like “Ser”, get it? Marketing thought SerSound wasn’t friendly enough.

*** This part is true. The same sound hardware is used in the arcade mega-hits Congo Bongo and Mr. Do, among others.

**** PRINT#-2, yo.

Building a Better BASIC Input, revisited

Well, here we go again with a few more tidbits from comments to a previous installment

Lowercase to Uppercase

John Klassek once again provides some interesting tips. He looked at my Building a Better BASIC Input article example:

30 LN=INSTR(“YyNn”,A$):IF LN=0 THEN PRINT”YES OR NO ONLY!”:GOTO 20
40 ON LN GOTO 100,100,200,200

…and suggested this:

40 ON (LN+1)/2 GOTO 100,200

…and noted:

…and you don’t have to keep the line numbers twice in ON…GOTO.

Well that makes sense. The extra bytes taken to do the math would be smaller than all the doubled line numbers. But does doing the math take more time than parsing through the extra line numbers? Let’s fine out:

5 DIM TE,TM,B,A,TT
10 FORA=0TO4:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 LN=INSTR("YyNn",A$):IF LN=0 THEN PRINT"YES OR NO ONLY!":GOTO 20
40 ON LN GOTO 100,100,200,200
70 NEXT:TE=TIMER-TM
80 TT=TT+TE:PRINTA,TE
90 NEXT:PRINTTT/A:END
100 GOTO 70
200 GOTO 70

This produces 866.

John’s suggestion:

5 DIM TE,TM,B,A,TT
10 FORA=0TO4:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 LN=INSTR("YyNn",A$):IF LN=0 THEN PRINT"YES OR NO ONLY!":GOTO 20
40 ON (LN+1)/2 GOTO 100,200
70 NEXT:TE=TIMER-TM
80 TT=TT+TE:PRINTA,TE
90 NEXT:PRINTTT/A:END
100 GOTO 70
200 GOTO 70

…jumps up to 1214! So, smaller code, but at a speed penalty. (See: Size versus Speed.) Brute force is often faster.

However, I also discussed converting characters to UPPERCASE so you only had to compare uppercase. That came with quite the speed penalty:

0 DIM A$,C:A$="*"
5 DIM TE,TM,B,A,TT
10 FORA=0TO4:TIMER=0:TM=TIMER
20 FORB=0TO1000
40 C=ASC(A$):IF C>=97 AND C<=122 THEN A$=CHR$(C-32)
70 NEXT:TE=TIMER-TM
80 TT=TT+TE:PRINTA,TE
90 NEXT:PRINTTT/A:END

That benchmark was 960.

John then presented a much faster approach by using strings and the INSTR command:

0 DIM A$,C,Z:A$="*"
1 AL$="aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ"
5 DIM TE,TM,B,A,TT
10 FORA=0TO4:TIMER=0:TM=TIMER
20 FORB=0TO1000
40 Z=INSTR(AL$,A$): IF Z>1 THEN C=64+Z/2 ELSE C=ASC(A$)
70 NEXT:TE=TIMER-TM
80 TT=TT+TE:PRINTA,TE
90 NEXT:PRINTTT/A:END

That drops it a bit lower to 920. For a custom input routine, every bit helps make it keep up with faster typing. Nicely done! (He also notes that this assumes the character string is non-empty, which we’d ensure is the case if using an INKEY$.) And, remember that we could speed that up even more by changing the decimal numbers to HEX.

He also suggests using AND instead of my “C-32” subtraction:

In case of a conversion with A$=CHR$(ASC(A$)-32) this could be a slightly faster: A$=CHR$(ASC(A$)AND M) but only with a predefinition of M=223 (with constant 223 it would be slower!) which masks bit 5 (value 32) in the character code representation.

Challenge accepted:

0 DIM A$,C,M:A$="*"
1 M=&HDF '110111115 DIM TE,TM,B,A,TT
10 FORA=0TO4:TIMER=0:TM=TIMER
20 FORB=0TO1000
40 C=ASC(A$):IF C>=97 AND C<=122 THEN A$=CHR$(C AND M)
70 NEXT:TE=TIMER-TM
80 TT=TT+TE:PRINTA,TE
90 NEXT:PRINTTT/A:END

This returns 963 while my original using subtraction returned 960. It looks like AND is slower. HOWEVER, if you know the input is already ONLY “a-z”, you can just do the AND without the check. So, there is a use-case if you were scanning for “yYnN” and just AND the result and compare only uppercase….

It’s fun to think outside the box.

Any other suggestions?

Until then…

 

Color BASIC String Theory, part 2

See also: Part 1

I had no intention of turning this in to another rambling multi-part article series, so maybe I can wrap this up in just two posts…

But first, in a comment to the first part, William “Lost Wizard” Astle said:

String manipulation is, in fact, entirely predictable, and logical. I think I’ll do an article on the internals of string evaluation and manipulation in Color Basic. It’s actually fairly straight forward, but the whys and hows of it get a bit complex. – William Astle

His article explains how the string handling really works (unlike my random speculation), and includes some interesting tips about how to make things faster by allocating extra string space if memory allows. Check it out here:

http://lost.l-w.ca/0x05/color-basic-and-string-handling/

…and then read the rest of my speculative fiction about how strings work.

Speculative Fiction About How Strings Work

My original purpose was to talk about making sure you CLEAR enough string memory to keep your program from crashing if a user types in a big string or maxes out all the variables. This will become important when I get to designing the new version of the *ALLRAM* BBS I plan to write.

Today, let’s look at why this mattered when I created the original version back in 1983.

When I first created *ALLRAM*, I decided I would make the message board work on 64-character lines. That would fit nicely on two lines of the CoCo’s 32-column screen, or one line on the 64-column TRS-80 Model I and III screens. Isn’t it weird thinking back to the early days before 80 columns became standard?

On a cassette based CoCo, after a PCLEAR 0 (no graphics pages), I could get 31015 bytes of memory to use for storing the userlog and message base.

Somehow, I decided that I would let each message be up to 10 lines long (640 bytes max), and I used an extra line to store the TO, FROM and SUBJECT of the message. From looking at the old source code, I see that usernames were limited to 20 characters, and the subject was 18 for some reason. They were combined using backslash delimiters like this:

TO\FROM\SUBJECT

At max size (20+1+20+1+18) that is 60 bytes. Ah, now I understand why the subject must have been 18. This makes each message take up to 700 bytes total (640+60).

I used a two-dimensional array to hold the 11 lines for each of the 20 messages:

DIM MS$(19,10)

Twenty messages at 700 bytes each is 14000 bytes. I had to make sure I CLEARed that much plus anything else needed for operation.

I also decided I would store the userlog as an array of strings that contained the username, password and access level, separated by a delimiter:

USERNAME\PASSWORD\LEVEL

A username could be up to 20 characters long and a password 8 characters. The level was supposed to be from 0-9, so it could be 1 character. Thus, the maximum userlog string could be 31 bytes (20+1+8+1+1).

I decided I would allow up to 201 users. I suppose I expected user 0 to be the SysOp (system operator) account.

DIMNM$(200)

This meant the userlog could take up to 6231 bytes (201*31).

Now the RAM storage used by the BBS was 20231 bytes, assuming every byte of every user and message entry was full.

I knew I would need some extra storage for temporary strings and such, so I just rounded up:

CLEAR 21000

And that’s how *ALLRAM* came to exist on a 32K Radio Shack Color Computer. (I had 64K, but Color BASIC did not make use of anything past 32K, and I didn’t know assembly language yet which would have been needed to access the upper 64K. See this article for details.)

You may be able to see that this was a “safe” approach, but probably had a TON of memory that just wasn’t being used. Consider a message like this:

----------------------------------------------------------------
TO: ALLEN HUFFMAN
FR: SYSOP
SB: COOL!

THIS SIMULATES WHAT A MESSAGE MIGHT HAVE LOOKED LIKE ON THE 1983
*ALLRAM* BBS, USING UP TO TEN TEXT LINES OF 64 CHARACTERS. IF I
DIDN'T USE IT ALL, THE REMAINING MEMORY WAS JUST WASTED.

-<>- ALLEN HUFFMAN -<>-
----------------------------------------------------------------

The array that contained this message would look like this:

            ----------------------------------------------------------------
MS$(0,0) = "ALLEN HUFFMAN\SYSOP\COOL!"
MS$(0,1) = "THIS SIMULATES WHAT A MESSAGE MIGHT HAVE LOOKED LIKE ON THE 1983"
MS$(0,2) = "*ALLRAM* BBS, USING UP TO TEN TEXT LINES OF 64 CHARACTERS. IF I"
MS$(0,3) = "DIDN'T USE IT ALL, THE REMAINING MEMORY WAS JUST WASTED."
MS$(0,4) = ""
MS$(0,5) = "-<>- ALLEN HUFFMAN -<>-"
MS$(0,6) = ""
MS$(0,7) = ""
MS$(0,8) = ""
MS$(0,9) = ""
MS$(0,10)= ""

The row of dashes (“—“) represents the 64 character line size. As you can see, this small message is wasting much space because of unused lines, and even leftover space on the lines that are used.

If I were going to redesign this today (which I am), I have several ideas that would probably make it far more efficient, allowing for much larger message bases using the same memory (or, worst case, the same size if every message was maxed out).

Any thoughts?

I’ll share mine in a future installment.