Author Archives: Allen Huffman

About Allen Huffman

Co-founder of Sub-Etha Software.

Extended Color BASIC to Arduino Sketch, part 2

See also: Part 1Part 2, Part 3, Part 4 and full source.

Yesterday, I shared a silly little project I was undertaking where I was going to port a BASIC program to the Arduino, line-by-line. I am glad to say I have successfully done just that, but the practicality of such accomplishment is very questionable.

For programs that were not created to use 21K of RAM for a memory-resident userlog and message base (like my *ALL RAM* BBS program does), it seems fairly easy to port over Microsoft BASIC code and get it running on the Arduino with surprisingly easy changes. I am tempted to find some classic BASIC programs (like ELIZA or Hunt the Wumpus) and try to convert them, as well, just to see if 2K of RAM is enough for hopefully less memory-hungry code.

So let’s talk a bit about memory. The Radio Shack TRS-80 Color Computer came out in 1980 with a 4K model (later generations would support as much as 512K, or megabytes through third party suppliers). In a 4K system, all of the BASIC code took memory, as well as any variables the program used. I expect working in an Arduino is similar to the 1980 experience, except for more program space.

On a 4K computer, if you had a BASIC program that took up 3K, you only had 1K left for variables. On the Arduino UNO, there is 2K of RAM, and 32K of Flash storage to hold the program. So, that same 3K program that only had 1K of RAM for variables on a 4K CoCo would do much better on an Arduino since it could store the 3K program in Flash, then have the full 2K for variables.

32K CoCo BASIC memory.

Unfortunately, my BBS program was designed to work on a 32K CoCo. These early 8-bit computers, even with 64K upgrades, still had a BASIC that only recognized 32K (without loading some extra patch program). And, on power up, some of that memory was reserved to hold four graphics pages. Thus, a 32K CoCo would show 24874 bytes available in BASIC.

You could adjust the amount of memory reserved for graphics screens higher or lower with the “PCLEAR” command. A “PCLEAR 8” reduced memory down to 18727 bytes. 6K (6144 bytes, or 1.5K per graphics page) was consumed. For programs not making use of these graphics, we wanted to get rid of that reserve and use it ourselves. Unfortunately, the PCLEAR command only allowed going down to “PCLEAR 1”, which gave 29479 bytes free for BASIC. That’s a nice bit of extra, but someone clever figured out how to achieve a PCLEAR 0 and get the most memory we could use without patching BASIC: 31015 bytes free.

Note that, once you plugged in a Radio Shack Disk Controller and added Disk Extended Color BASIC, the memory available went down a bit due to overhead of supporting the disk system. For this article, we are looking strictly at a circa 1980 style CoCo with a cassette recorder only.

And what does this have to do with the Arduino? I wanted to make sure you understood the limits I was facing when trying to port a cassette based BBS program to a machine with only 2K of RAM (and not all of that is usable by the user program).

My end result was a fully functional clone of the *ALL RAM* BBS, but with some rather impractical limits. For my demo system, I only allocated enough space to support about four users. Even I have more friends than that. And for messages, the limit was about four messages, each having just two or three lines. I would make a comment about how useless this would be, but Twitter seems to have proven people will use something that even gives less space than my 2K BBS.

So how did I do it? One word: gotos. Lots and lots of gotos. My translation was literal. Even though there are much better, more efficient ways to write this program (which I plan to undertake), I thought it would be fun to see just how easily BASIC could be coded in C.

I started out by taking an ASCII listing of the BASIC program, and adding “//” comment markers to the start of each line. I pasted that in to a fresh Arduino sketch, so it looked like this:

//0 REM *ALL RAM* BBS System 1.0
//1 REM Shareware / (C) 1983
//2 REM By Allen Huffman
//3 REM 110 Champions Dr, #811
//4 REM Lufkin, TX 75901
//5 CLS:FORA=0TO8:READA$:POKE1024+A,VAL("&H"+A$):NEXTA:EXEC1024:DATAC6,1,96,BC,1F,2,7E,96,A3
//10 CLEAR21000:DIMNM$(200),MS$(19,10),A$,F$,S$,T$,BR$,CL$,NM$,PS$,PW$,A,B,C,CL,LN,LV,MS,NM,KY,UC
//15 CL$=CHR$(12)+CHR$(14):BR$="*==============*==============*":GOSUB555
//20 CLS:PRINTTAB(6)"*ALL RAM* BBS SYSTEM":PRINT"USERS:"NM,"CALLS:"CL:PRINTTAB(5)"SYSTEM AWAITING //25 A$="Welcome To *ALL RAM* BBS!":GOSUB1055:KY=0:CL=CL+1
//30 PRINT:PRINT"Password or 'NEW' :";:UC=1:GOSUB1005:PS$=A$:IFA$=""ORA$="NEW"THEN55ELSEPRINT"Checking: ";:A=0

And thus it began. I would go line-by-line and try to write C code for each statement. All C variables would be made global, just like they were in BASIC, and blocks of code called by GOSUBs would become standard C functions (since they return just like BASIC). But, for GOTOs, I decided to just use the C goto, and added labels in the format of “line125:” so I could later “goto line125;” in C.

It looked like it just might work… (And, since I started this story in reverse, you already know that it did, but I will share some of the ways I did it in a future posting.)

Until then… Enjoy having more than 2K of RAM!

Extended Color BASIC to Arduino Sketch

See also: Part 2, Part 3, Part 4 and full source.

  • 2014/03/16 Update: The source code to this is now on GitHub. Check the Arduino link at the top of each page of this site.

In 1983, I released a BBS (bulletin board system) for Tandy/Radio Shack TRS-80 Color Computer (CoCo). Unlike all of the other ones available at the time, mine was rather unique. Instead of requiring “3-4 disk drives” to operate, mine would work with… zero disk drives.

The *ALL RAM* BBS system was designed to run on a 32K CoCo with a cassette tape deck. On startup, it would read in the userlog and message base in to RAM, and then as users called in, messages they posted would be stored in memory. When the SysOp (system operator) needed to use the computer, or was ready to shut things down for the day, he would save the system back to tape.

It was small and primitive, but considering how primitive the state-of-the-art was back then, it was still pretty usable.

The software was meant to be marketed by a CoCo software company, but things ended up not happening, and the software was eventually released as freeware (even though, back then, we did not yet have the names “shareware” or “freeware”. I still remember an experiment a software company did for something they called “pass the hat software”… I guess their name just wasn’t catchy enough).

But I digress.

Tonight, thanks to the XRoar Color Computer emulator, I was able to get my thirty year old software running again thanks to the software being available at the wonderful BBS Documentary website.

My oh my. What a simpler time.

Tonight, I wondered how hard it would be to translate Microsoft Extended Color BASIC to Arduino C. After all, C has a “goto” statement…

And here is part of the *ALL RAM* BBS system running on an Arduino:

The 1983 Radio Shack Color Computer BBS package is back... This time on Arduino!
The 1983 Radio Shack Color Computer BBS package is back… This time on Arduino

The userlog and message base is not yet functional, and likely never will be since the Arduino only has 2K of memory versus 32K on the CoCo 1 it was designed for. But, when I have some time, I will finish it up and maybe support a few users, and a few messages. Perhaps I can even use some of the memory saving tricks I have been using on some work projects to compress things quite a bit.

We shall see.

Hello, *ALL RAM*. Nice to see you again.

P.S. – The *ALL RAM* BBS ran in Houston, Texas under the name Cyclops Castle. The version running there was disk enhanced. Instead of loading and saving to cassette, it used a single disk drive. The software was modified to support dozens of separate message bases, and the user could switch them from the menu. It was quite a feat on a single floppy disk. One day I will have to track down the SysOp, Graham, and see what he remembers from this great experiment.

Use a TRS-80 Model 100 keyboard on a PC

Over on the Color Computer mailing list, Frank Swygert (editor of American Motors Cars Magazine) mentioned a project where someone else was using a Teensy to hook an old matrix-style keyboard up to a modern PC.

A bit of Googling led me to a similar project where someone built a Radio Shack TRS-80 Model 100 keyboard interface that lets you use it on a PC via USB. This is precisely one of the things I will be doing with a Radio Shack Color Computer keyboard (also planned to use the Teensy 2.0, since it has enough I/O lines and is very inexpensive). Share and enjoy:

http://www.seanet.com/~karllunt/M100_usb_keyboard.html

I have also been informed that Chris Hawks of HawkSoft has already done this, using a Raspberry Pi running a version of the MESS emulator. He created a scaled down version of MESS to emulate the Radio Shack Color Computer, then used Teensy to interface an actual CoCo keyboard to the Pi. Very cool.

Parsing Hayes modem AT commands, part 2

See also: Part 1

I know I am supposed to be posting my updated joystick code, which I will do as soon as I have a moment, but I wanted to share some other new stuff first so it can start getting in to the Google indexes.

I have created the first part of some quick-n-dirty code to handle Hayes modem “AT” commands. For a bit of background on the Hayes modem command set, check this Wikipedia entry:

http://en.wikipedia.org/wiki/Hayes_command_set

For some more specific details, check out this Wikibooks entry:

http://en.wikibooks.org/wiki/Serial_Programming/Modems_and_AT_Commands

The Hayes modem company needed a way for the controlling system (user, terminal program, BBS, whatever) to switch the modem from Data Mode (where bytes come in, and bytes go out) to Command Mode, where the modem could be controlled (dial a number, hang up, configure how many rings to answer on).

To get in to Data Mode, a series of three characters is sent – the default being “+++” – with a one second pause (called the “guard time”) before and after them. That way, if the string “+++” appears in normal data being transmitted (like this article), the modem doesn’t respond to it. It would take a pause, then the “+++”, then another pause, and the modem would stop sending and receiving data and present the host system/user with an “OK” prompt and then accept commands.

My code was designed to be used in the main loop() where data would be processed. Code would check for incoming data from the remote device and handle it (such as seeing bytes come in over a modem or serial port), and then look for local input (like the user typing, or a program sending data out). If it was a dumb terminal program, that loop might look like this pseudo code:

loop()
{
    char ch;

    ch = readIncomingData();    // Get byte from remote system.
    Serial.write(ch);           // Print byte to local screen.
    ch = Serial.read()          // Get byte from local input.
         writeOutgoingData(ch); // Print byte to remote system.
}

This, of course, is not working code. A few more lines would be needed to check for valid data and such, but hopefully you get the idea. The loop would continuously run, reading data if it were there, or moving on to the next instruction.

My code is designed to plug in to that loop, after each byte is read from the local user:

loop()
{
    char ch;

    ch = readIncomingData();                      // Get byte from remote system.
    Serial.write(ch);                             // Print byte to local screen.
    ch = Serial.read()                            // Get byte from local input.
         if (cmdModeCheck(ch) == true) cmdMode(); // ADDED
    writeOutgoingData(ch);                        // Print byte to remote system.
}

The idea is to let me code inspect each character that comes from the host system, and then see if there has been a pause of at least “guard time” since the previous character, and if so, start evaluating the characters to see if they are the “+++” escape sequence. If three plusses are seen in a row, it then sees if “guard time” has elapsed and, if so, return a true value to let the calling function know it is time to switch in to Command Mode.

According to the Hayes modem standard, the character used for the escape sequence (“+”) is configurable, as is the guard time. Because of this, I use two global variables for these, so the user can modify them and affect my cmdModeCheck() function:

// Define the escape sequence.
#define ESC_GUARD_TIME 1000 // Seconds required before/after escape sequence.
#define ESC_CHARACTER  '+'  // Default escape character.

// For Command Mode.
unsigned int escGuardTime = ESC_GUARD_TIME; // Delay before/after esc sequence.
static char  escCharacter = ESC_CHARACTER;  // Escape character

I am just using the #defines for default values. A function will be written later that will let the user set them, like setCmdModeCharacter(‘?’) to make it “???” or setCmdModeGuardTime(2) to change the guard time to two seconds.

Not much here so far, so let’s look at the actual function. I will insert some comments

// Magic numbers.
#define ESC_TIMES 3 // Number of escape characters ("+++").

boolean cmdModeCheck(char ch)
{
    static unsigned long escCheckTime = 0; // Next time to check.
    static byte escCounter = 0;            // Number of esc chars seen.

    // If no character is being passed in, we are just doing a check to see if
    // we are in a "wait for end guard time" mode.
    if (ch == 0)
    {
        // See if we are waiting to enter command mode.
        if (escCounter == ESC_TIMES)
        {
            // Yep, we have already found all the escape sequence characters.
            if ((long)(millis() - escCheckTime) >= 0)
            {
                // And the pause has been long enough! We found an escape sequence.
                escCounter = 0;
                escCheckTime = millis() + escGuardTime;

                return true; // Yes, it is time for Command Mode.
            }
        }
    }
    else // if (ch==0)
    {
        // If there has been a pause since the last input character...
        if ((long)(millis() - escCheckTime) >= 0)
        {
            // Check to see if it's an escape byte.
            if (ch == escCharacter)
            {
                // Move to next character to look for.
                escCounter++;

                // Are we out of escape characters to check for?
                if (escCounter >= ESC_TIMES)
                {
                    // Set after delay to signify end of escape sequence.
                    escCheckTime = millis() + escGuardTime;
                }
            }
            else
            {
                // Reset. Not an escape character.
                escCounter = 0;
                escCheckTime = millis() + escGuardTime;
            }
        }
        else
        {
            // Reset. Not an escape character.
            escCounter = 0;
            escCheckTime = millis() + escGuardTime;
        }
    } // end of if (ch==0) else

    return false; // No, it is not time for Command Mode.
}

I should explain that, in order for this function to work, it needs to be called often enough to determine if the guard time (1 second) has elapsed between incoming data. If the input is idle, the function still must be called, but with ch=0 (no data) which is why, at the top, it looks for an incoming character of 0 then it will handle timing stuff.

The way it works is by keeping a count of how many escape characters in a row we have seen so far. I use static variables so they maintain their values between calls to the function. Since I do not use them anywhere outside of this function, I saw no reason to make them global.

“escCounter” starts out at 0. If we get a “ch=0” value, we want to see if we are waiting on the ending guard time. i.e., have we gotten as far that we’ve seen 3 escape characters in a row, and are now looking for a 1 second pause? If escCounter is 3 (ESC_TIMES), we use a nice timing rollover routine from the Arduino.cc Playground to see if it’s been at least guard time with no other characters coming in. If it has been that long, we reset out escCounter back to 0, and make a note of some future time (representing now + guard time in the future). More on this in a moment, but by returning “true” at this point, we have reported back that we have seen “(pause)+++(pause)”.

Ideally, I should have explained the previous code after explaining this next bit first, since it is setting some things up we haven’t discussed yet. Hang in there and things should become clearer…

At the else, we handle a situation if “ch!=0” (i.e., if we were passed in a character from the host system/user). When we initialized this function, there was an “escCheckTime” variable set to 0. In this loop, we test to see if the time difference between now “escCheckTime” to see if we have gone past it. The very first time this runs, that will be some number minus 0, which will always be greater than 0, and thus always look like it’s been that long. Since we are just starting up, we always want to consider the first character we see. Subsequent calls will be using an “escCheckTime” that is generated based on “now + guard time”, so we are really checking to see if we have passed that future moment in time.

As you will see in a moment, every time a non escape character comes in, or anything else comes in during our guard time wait period, we just reset everything since it’s clearly not an escape sequence.

BUT, if the character we receive IS our escape character (“+”), we increment our “escCounter” to indicate how many of them we have seen in a row. It would go from 0 to 1 this first time.

If the counter gets up to 3 (ESC_TIMES), we have seen three of the escape characters in a row without being reset, so we set our escCheckTime to be “now plus guard time”. If you go back a few paragraphs, you will see we check this in the “nothing to do here, move along” function, so it can say “oh, it’s been at least guard time, AND we have seen our escape character sequence. Must be Command Mode time!”

But if it was NOT our escape character (else), we reset escCounter back to 0, and reset our check time yet again to “now plus guard time” to start the whole process over.

The next else is from the “has it been longer than guard time” if statement, and if we got a character before our guard time elapsed, we know it’s not an escape character so reset everything (just like the previous paragraph).

I hope to clean that up a bit so it doesn’t have to do it in two places like that.

At the end, we return false, because if we got there, we are in the process of either normal data, or scanning through a potential escape character sequence.

When I return, I will provide a full code example, and hopefully have some enhancements to the above function. Until then… I have to get back to packing. My rent is going up and it looks like I will be moving soon.

Parsing Hayes modem AT commands, part 1

2014-03-03: Latest source code is on GitHub.

Several of my Arduino plans involve the old 1980’s Radio Shack Color Computer (CoCo). I have previously discussed plans to use modern USB mice, joysticks and keyboards with this old home computer, as well as going the other way and allowing old CoCo joysticks to be used on modern PCs.

That seemed like an easy first step, and one I hope to find time for some time before I retire. I haven’t had time to touch any of this for awhile. That, however, does not stop me from planning even more projects.

There is an Arduino Ethernet shield currently available for $17.99 from Sainsmart in China. They ship free to the USA, but it takes awhile. For a bit more, you can buy it from Amazon and have it shipped 2nd day via Amazon Prime.

These shields provide an Ethernet port for the Arduino, and library code is provided to do basic things such as make a TCP socket connection. Samples exist showing how to go retrieve a web page, FTP put/get a file, or even serve up web content so you can create an HTML interface to interact with the device. With the Arduino doing the physical interfacing to the wire, and heavy lifting of the TCP/UDP/IP protocol stack, this might be an easy way to bring internet connectivity to the CoCo.

Over a decade ago at the 2001 Chicago CoCoFEST! convention, Minnesota-based Cloud-9 Tech announced plans for the “Superboard” hardware add-on. It would be a secondary I/O board that would connect inside a CoCo case and bring all kinds of hardware add ons, such as a hard disk interface. The product has yet to be completed, but many spinoff items have been released during development.

One of the proposed features of the Superboard was the addition of an iChip from ConnectOne. This chip implemented TCP/IP as well as common internet protocols like FTP, Telnet and mail. Small devices could talk to the chip via serial (like talking to a modem) and send commands, then the chip would go do the actual work via a dialup ISP or ethernet link. I thought this was the killer feature, and started referring to this project as the “Internet CoCo.”

I even looked in to making an RS232 adapter that would have an iChip in it, so you could plug a cable from an RS232 pak on the CoCo to this adapter, then to a modem and get all the features that way. But, at the time, I didn’t have the money to invest in the ConnectOne reference platform (a modem with iChip built in) to work on it.

Well, today the iChip is still made and only cost $25 in single unit quantities. I still think this adapter would be a great idea, but perhaps there is another way…

It would be relatively trivial to write Arduino code that would do this. A CoCo (or any device with RS232) could send commands to the device to establish network connections and then the data could be passed back as serial data. The only tricky bit would be allowing multiple socket connections (FTP, for instance, uses two at a time). For that, some form of serial multiplexing (using one serial line with a protocol on it to act as multiple lines) could be used.

Side Note: There is an absolutely amazing thing called DriveWire created by a former coworker of mine, Boisy Pitre. He created a serial protocol to allow a PC to host disk files for a CoCo via the bitbanger serial port. Over the years, the protocol has evolved and gained many features well beyond virtual disks. It’s truly amazing.

Well, today, the DriveWire server already implements much of what I am talking about doing, including multiplexing serial ports so a CoCo, connected by a single serial cable at 115Kbaud, can have multiple virtual serial ports, MIDI ports, disks, hard drives, etc. DriveWire even runs on a $25 Raspberry Pi, so one could do this without even needing a full PC nearby…

…but that won’t stop me from learning and experimenting. In fact, after I started my current job almost a year ago, I got access to a Raspberry Pi which I hooked up recently for the first time. I expect whatever I develop for Arduino I will also port to Raspberry Pi. Perhaps I can even make the Arduino code speak some of the DW protocol for virtual serial ports and such.

We shall see.

But I digress.

The real focus of this posting is to share my code for a Hayes modem “AT” command parser. In olden days of dial up modems, there were certain “smart” modems that could dial the phone on their very own. Amazing. On power up, these modems were in “command mode” and you could type commands to them like “ATDT 555-1212”. This mean “(At)tention. (D)ial using (T)ouch tone. 555-1212”. “ATH” was the hang up command. Various other commands existed for things like telling the modem if it should auto-answer the phone after a certain amount of rings, or specify how fast the touch tone dialing should be.

The “AT” command set was created by the Hayes Modem company, and other manufactures had their own system for interacting with their modems, but eventually the Hayes command set won out and became a standard. (There’s a great Wikipedia article on this.)

Since the iChip (and pretty much everything else, including modern cell phone modems) makes use of a Hayes-style command set, I thought I would implement something similar myself.

So, coming up soon, I will share code that handles the basics of this, and then will start piecing things together to interface it to the Arduino Ethernet port so you could do something like “ATDI 127.0.0.1:80″ (Attention, dial over the internet to IP address 127.0.0.1 port 80”.

Sounds fun. If I can find the time.

USB host (read a USB keyboard/mouse) without hardware

I have not had time to spend on any research lately, but I did want to pass along this link:

https://courses.cit.cornell.edu/ee476/FinalProjects/s2007/blh36_cdl28_dct23/blh36_cdl28_dct23/

These folks have a software-only implementation of USB host for the AVR chip like the Arduino uses. It allows, with software only and some wires to a USB connector, the device to read a basic USB device like a mouse or keyboard.

The only thing I noticed was it requires a 16Mhz crystal, instead of the stock 15mhz. They did it by building their own system, but someone wanting to do it on an Arduino would need to desolder and replace the crystal.

However, there are some pretty simple plans to “build a $5 Arduino” with minimal parts — so perhaps it would be very cheap to breadboard something that supports this.

2N2222 transistor from Radio Shack links Arduino UNO and Teensy 2.0

This screen shot may not seem like much, but it marks the first time I have ever used a transistor:

Reading Transistor Switch

My Tandy joystick project has two goals. The first is to allow an analog Tandy joystick be used as a USB device for a modern computer. This part is easy, since the variable resistors in the joysticks can be easily read from the Arduino/Teensy’s analog inputs, and the joystick buttons can be read on a digital pin.

The second part is a bit trickier. The idea is to use a modern input device on an old Tandy 1000 or Color Computer. To do this, the USB device’s analog position (if it is an analog stick or a mouse) has to be turned in to a resistance value that the old computer can read through it’s joystick ports. I found a tutorial on the Arduino site that shows doing this with an AD5206 digital potentiometer chip:

http://arduino.cc/en/Tutorial/SPIDigitalPot

That seems easy enough, but I wasn’t sure how to make a digital output pin from the Teensy turn in to a dry contact switch. A bit of research led me to a few useful tutorials dealing with transistors and optoisolators:

…and I found various projects where they were using these devices to simulate a button press on a camera, to automate it:

http://www.zipfelmaus.com/blog/hack-a-canon-camera-and-controll-it-with-an-arduino/

The above project is precisely the type of thing I want to do, so I wired up an Arduino like his layout, and then instead of running wires to the switch of a Canon camera, I ran them to a digital input of my Teensy 2.0 and its ground. Using the Fritzing program, here is a diagram of what I did:

Hooking digital outputs to digital inputs.
Hooking digital outputs to digital inputs. (Diagram done with Fritzing)

I hacked a bit of code on the Arduino side that just toggles that digital pin HIGH and LOW (basically, I hacked the LED blink example to also do pin 12):

int led = 13;
int transistor = 12;

// the setup routine runs once when you press reset:
void setup()
{
    // initialize the digital pin as an output.
    pinMode(led, OUTPUT);
    pinMode(transistor, OUTPUT);
}

// the loop routine runs over and over again forever:
void loop()
{
    digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level)
    digitalWrite(transistor, HIGH);
    delay(1000);            // wait for a second
    digitalWrite(led, LOW); // turn the LED off by making the voltage LOW
    digitalWrite(transistor, LOW);
    delay(1000); // wait for a second
}

Then, on the Teensy, I wired up to the transistor similar to the Input Pullup example (which reads a button) and reports if the status of the pin had changed. Here’s some quick and dirty code:

void setup()
{
    // Initialize the serial port.
    Serial.begin(9600);

    pinMode(3, INPUT_PULLUP);

    pinMode(LED_PIN, OUTPUT);

    Serial.println("Ready.");
}

int oldStatus;
int status;

void loop()
{

    status = digitalRead(3);
    if (status != oldStatus)
    {
        Serial.print("Pin 3: ");
        Serial.println(digitalRead(3));
        oldStatus = status;
        digitalWrite(LED_PIN, status);
    }
}

Now, with both devices running, on the Arduino, every time the LED turns on, it is also turning on the pin connected to the transistor. On the Teensy, that pin connects to digital input 3. (I started at 3 since that is just passed the three pins used by SPI, which I will be needing for my real project.)

When the light on the Arduino goes on, the light on the Teensy goes off. I would need to change how I wired them (active high versus active low) to make them sync. But, it works.

I have much learning to do on all this, but this proof-of-concept gets me one step closer to what I am trying to do. I will be next be trying the same thing using optoisolator chips, though I am not sure there really needs to be any isolation between the joystick buttons and the Teensy.

More to come…

Fritzing circuit designer…

I was looking at an Arduino tutorial and noticed they had a rather nice computer diagram of an Arduino, showing how to connect all the wires up for the project

I decided to check out the link for the Fritzing program that was used to make the diagram. This freely downloadable software for PC, Mac and Linux is pretty neat. You can diagram out an Arduino breadboard layout, and then turn that in to a real schematic and even PCB layout. The layout can then be exported and sent off to have boards made. I have never done anything like this before, but I am having fun experimenting…

The following picture shows something I was playing with. It doesn’t work — it was just me experimenting with some objects. But, I think this program might end up being pretty fun to play with. Check it out.

Playing with Fritzing...

(Above was some initial concept work done on “yet another” joystick converter. This one will be designed to hook a modern USB joystick or mouse up to an old Tandy 1000 or Color Computer. I also plan to allow it to do the same thing with a PC keyboard to the CoCo. For emulation fans, the reverse is also planned, allowing an analog TRS-80 joystick to be hooked up to a modern computer via USB, and the same thing with a CoCo keyboard. This is going to take a bit more work than what I have done so far, but it seems pretty straight forward, once I figure out how to use switching transistors…)

X-Arcade Tankstick

20130225-171025.jpg
(photo from xgaming.com)

There is a popular set of arcade style joysticks made by a company called X-Arcade. A friend of mine owns one, and he was kind enough to send me a few links with information about these joysticks, and I thought I would share them here.

First, there is an online (Java-based) test program that shows the Tankstick buttons working:

http://www.xgaming.com/support/questions/4/Test+Your+X-Arcade%E2%84%A2+First%21+-+Online+Test+Utility+Program

And this page shows what the various buttons map to:

http://www.xgaming.com/service/images/Layouts/PC-MAC.htm

Of particular interest to me is the realization that Tankstick doesn’t appear as a USB joystick at all. Instead, it appears as a keyboard, and sends key presses for the joystick directions, buttons, etc. For models with a trackball (Tankstick+, for instance), I am guessing the trackball appears as a mouse. So, Tankstick is a keyboard/mouse, as opposed to an analog or (as I previously expected) digital joystick.

This means a third layer of support will be needed to create a conversion between Tankstick keyboard presses and the iCade sequences. This would be a very simple Arduino script since it removes any need for reading digital input pins or USB status bits. It does complicate things for me, however, since now I have to learn what it takes to expect data from either a keyboard or joystick (hopefully without requiring the user to switch). My ultimate goal is to have my code “just work” whether the user is wiring up their own controls to the digital inputs, or using a USB host shield and plugging up an analog or digital joystick, or keyboard device like the Tankstick.

Incidentally, the Tankstick still supports the “ancient” (by computer standards) PS/2 style keyboards as well, and those could be read on an Ardunio (or Teensy) using very little add-on hardware and digital pins. It seems a Tankstick-to-iCade converter could be done very easily, so maybe I can spin one of those off as well.

More updates when I have time to get back to this…

iCade button numbering.

A few notes from my research on the iCade. There is a developer document currently linked from this page:

http://www.ionaudio.com/products/details/icade

Here is the direct link to the current version (1.5) in PDF format:

http://www.ionaudio.com/downloads/ION%20Arcade%20Dev%20Resource%20v1.5.pdf

This document covers the button layout of the original iCade/iCade Core (same layout) used by the iPad, and the iCade Jr./iCade Mobile used by the iPhone/iPod Touch models. Only with the addition of photos showing the buttons for the iCade Mobile did I begin to understand I have been wrong about how the iCade organizes its buttons. Without one to test and play with, I have just been guessing based on available documentation.

(photo from http://www.ionaudio.com/products/details/icadecore)
(photo from http://www.ionaudio.com/products/details/icadecore)

All models provide either a joystick or a 4-way touch pad. For the original iCade (and the cost reduced iCade Core, which is the same unit but without the arcade-looking enclosure), there are eight buttons, organized as two rows of four buttons each. The buttons go red, black, black and white on each row, as if to indicate the group of 2×2 black buttons in the center are different than the red and white ones on the ends. I had been assuming that the main control buttons would be the black ones in the center, similar to the USB joystick I have been experimenting with, which labels the four buttons in the center with the Playstation symbols (square, circle, triangle, smiley face, cute kitty, whatever they are).

With the additional descriptions of the iCade Mobile button layout, I see now this is not the case. I had guessed that the buttons were numbered across, as in the first row being button 1-4 and the second row being button 5-8. This is not the case. Instead, the numbering looks more like this:

1 3 5 7
2 4 6 8

I realized this when I noticed the iCade Mobile was using the four buttons on the left (1-4) for it’s buttons, with 5-8 going to the front index finger buttons. The same was true for the iCade Jr., except buttons 5-8 were located on the back of that unit.

So, the four “primary” buttons for the iCade were 1-4, with two being red and two being black, and the other four (two red, two white) were the extra buttons. This was not what I expected, and it has led me to reorganize my button mapping for the iCade converter project.

There is only one diagram in the iCade documentation that numbers the buttons. Here it is, for the iCade Mobile:

(from http://www.ionaudio.com/products/details/icade)
(from http://www.ionaudio.com/products/details/icade)

Here it seems they number the directional buttons as 1-4, then the primary buttons as 5-8 and the final four as 9, 0, E1 (enter 1) and E2 (enter 2). With that in mind, I have changed my button definitions.

My arcade joystick has the primary buttons in the center, with the extras as grey buttons to the left and right:

Playtech Pro arcade fighting stick

So my arcade joystick thinks it is like a Playstation game pad, with the center color buttons being the right hand buttons, and the grey ones on the left and the right being the four buttons under the fingertips on the front of the gamepad.

If I wanted my joystick to use the same layout as the original iCade, I would have to map my buttons differently. With the joystick now being known as buttons 1-4, the iCade numbering layout looks like this:

  1  (5) (7) (9) (E1)
 3+4
  2  (6) (8) (0) (E2)

I build my iCade array in the order of the 12 buttons:

// This is just used for printing out debug info to the console.
char iCadeDesc[][USB_BTN_COUNT] =
{"Up", "Down", "Left", "Right",
"Btn5", "Btn6", "Btn7", "Btn8",
"Btn9", "Btn0", "BtnE1", "BtnE2"};

So in order to map my joystick over, I created alternate defines for my buttons so they would be easier to figure out:

// We will be treating joystick as a 16-bit value.
// Extra Buttons:
#define SELECT_USB  (1< &lt;8)  // Z1:0x0100 - Select
#define L3_USB      (1<&lt;9)  // Z1:0x0200 - L3
#define R3_USB      (1<&lt;10) // Z1:0x0400 - R3
#define START_USB   (1<&lt;11) // Z1:0x0800 - Start
// Joystick:
#define UP_USB      (1<&lt;12) // Z1:0x1000 - Up
#define RIGHT_USB   (1<&lt;13) // Z1:0x2000 - Right
#define DOWN_USB    (1<&lt;14) // Z1:0x4000 - Down
#define LEFT_USB    (1<&lt;15) // Z1:0x8000 - Left
// Grey/Front Buttons:
#define BTN1_USB    (1<&lt;0)  // Z2:0x0001 - L2
#define BTN2_USB    (1<&lt;1)  // Z2:0x0002 - R2
#define BTN3_USB    (1<&lt;2)  // Z2:0x0004 - L1
#define BTN4_USB    (1<&lt;3)  // Z2:0x0008 - R1
// Primary Buttons:
#define BTN5_USB    (1<&lt;4)  // Z2:0x0010 - "Triangle"
#define BTN6_USB    (1<&lt;5)  // Z2:0x0020 - "Circle"
#define BTN7_USB    (1<&lt;6)  // Z2:0x0040 - "X"
#define BTN8_USB    (1<&lt;7)  // Z2:0x0080 - "Square"

// Redefine some buttons for Playstation type layout:
#define TRI_BTN     BTN5_USB
#define CIR_BTN     BTN6_USB
#define X_BTN       BTN7_USB
#define SQR_BTN     BTN8_USB
#define L1_BTN      BTN3_USB
#define R1_BTN      BTN4_USB
#define L2_BTN      BTN1_USB
#define R2_BTN      BTN2_USB

The group at the end just gives me Playstation-style labels for the buttons I will be using. So, for a gamepad style controller, my mappings would be like this:

unsigned int myPins[USB_BTN_COUNT] =
{UP_USB, DOWN_USB, LEFT_USB, RIGHT_USB,
/*5*/SQR_BTN,   /*6*/X_BTN,    /*7*/TRI_BTN,   /*8*/CIR_BTN,
/*9*/BTN5_USB,  /*0*/BTN6_USB, /*E1*/BTN7_USB, /*E2*/BTN8_USB};

…but for my arcade stick, where the Playstation buttons are in the center, I would map it like this:

unsigned int myPins[USB_BTN_COUNT] =
{UP_USB, DOWN_USB, LEFT_USB, RIGHT_USB,
/*5*/L1_BTN,  /*6*/L2_BTN,  /*7*/SQR_BTN, /*8*/X_BTN,
/*9*/TRI_BTN, /*0*/CIR_BTN, /*E1*/R1_BTN, /*E2*/R2_BTN};

Here you can see I assign my L1 button (top left grey) to be button 5 to the iCade, L2 for button 6, and so on. This will map my layout to match the original iCade.

It looks like I am going to need a way to switch the type of joystick being used, since clearly things are different. I will work on this next.

Oh, and I plugged up my Legacy Engineering Atari 2600 USB joystick and found it did not work at all with my converter. (Original company seems to be gone, but here is another recreation.) Instead of stuffing bits in Z1 and Z2, the Atari joystick puts them in the X and Y locations. 0 meaning left, 128 meaning center, and 255 meaning right. They are basically taking a digital joystick and faking out analog positions. The single button is mapped in to Z1 as a bit. (Inside this joystick you can hack on additional buttons, and I bet they fill out other bits in Z1.)

So, I now need to deal with two types of digital layouts (gamepad style, and fighting stick style) and an analog type stick (even one being faked, like the Atari).

To be continued…