User Interface Exploration: Model T Shell

I like retro computers.  A lot.  While working on my BL-328 project, I snagged my old Tandy TRS-80 Model 102 portable computer, to use as a serial console for it.  Long story short, using it as a serial terminal works great, I just had to throttle the baud rate back to about 1200 baud so that it can keep up.

Because of this, I decided to get back into playing with my Tandy 102 a bit, seen above.  I resubscribed to the M100 mailing list, which is associated with the Club 100 "Model T" Users Group.  They nicknamed the Model 100 and 102 as the "Model T", as in the car, which is an appropriate analogy I think.  I had been subscribed to this in the past, and I really liked the people, their attitudes, and their ethics.  It's as though someone freeze-dried a computer enthusiast group from the late 70s/early 80s, and defrosted them now.

One conversation across the M100 email list mentioned doing a modernized version of the Tandy 100 "Model T" shell interface, running on a portable computer that is a modern version of the '100... which I'm sure you realize is exactly in line with where I am right now. ;)  I picked this idea up and ran with it.3

I started by looking at the interface on my Tandy 102 (seen above), and seeing how it works, and the design used.  I also fired up up the Virtual T emulator, which is a bit more convenient than having the real hardware with me.  It looks like this:

It has an 8 line, 40 column LCD display.  It's got the date in the top left, usually "(C)MICROSOFT" in the top right, since the firm/software was written by Microsoft by a guy named Bill Gates or something.  (This screenshot is from the emulator, so it appears a little different than actual hardware.) The memory free in the bottom right, and the Select prompt in the bottom left, so you could just type in your selection.  The middle area lists all of the files and programs in the ROM, mixed together.

I have started up a project on github called "Model T Shell", and have been exploring this.  It is by no means finished, but I thought I'd bring you along while I experiment and hone the interface to something that makes sense and is reasonably usable.

I started out by doing the basics of it.  It uses curses/ncurses/pdcurses, builds with gcc, and works on OS X (command line developer tools required), Linux (Ubuntu tested, requires ncurses), and perhaps in the future, a build on Windows/mingw.

I took the interface, added color, and made it flexible with respect to the screen size.  Top left has the date and time in the same format (No more Y2k bug!).  Top right is version info and username of the person running it.  Middle section is navigated with the arrow keys, selected with "enter".   Select prompt in the bottom left, and "free memory" in the bottom right.  I wasn't sure what to put in the bottom right yet, so that's just a fixed string for now.

I added in a scanner for the current directory, and quickly realized that doing this was a horrible mess. I also had changed the bottom right to indicate what kind of 'thing' the selector was over.  A directory in the above image.

Next, I figured I'd change it so that you had builtin tools in one section, then the current directory in the bottom section:

This wasn't quite right either.  I think the issue was that I needed to separate them by what kind of thing they are, rather than where they're from.  It needs to make sense for the end user with relation to  workflows, or something. (Sidenote: This is exactly why my basement is a mess.  Everything is in boxes based on where they were one or two houses ago, rather than their function.)

Next, I decided to separate it into three sections: Verbs, Places, Nouns.

Verbs are actionable things.  This includes builtin programs and commandables, and current directory's commandables (executables, shell scripts, runnable programs.) Places are basically directory navigation.  Nouns are things that can be loaded, edited, and such (files).

This seems to make sense for using. As you navigate around the directories, everything sorts as you would expect it to.

So... What's up next?

Next I'd like to change it such that the commandables and places have editable lists.  That means that as you navigate around and find verbs that you like, you can add them to your verb list.  Likewise, you can add places that you like to work from and store them there in that list.

I think that I would need to start with just a few commands and places there, and you could add them as you use the interface.  The default commands might be: CONFIG (preferences), EXIT (leave the interface), ADD (adds a selected place or commandable to the lists), REMOVE (removes a place or commandable). As for places, mountpoints, and home directory.)

I also need to figure out how to let you select commandables for different files. I'm thinking maybe keying off of MIME types, or just more simply, file extensions.  That way, for example, you could open .do or .doc files in PICO, but .txt files in VI or EMACS or whatever.

Oh, and it should also probably do something rather than just letting you navigate around the filesystem.

I don't see there being a final product, a single deliverable to achieve on this project... It's more of an exploration of how an interface like this might work for a modernish system.  I'll post an update when I figure things out more.

Building the BL-328 Computer: Part 1: Introduction and CPU

I recently decided to work on a physically small project. I decided to take the sort of ethics of the classic computer systems from the 1970s, which by design were considered what we now woud call "homebrew" and apply them to modern computing. I tried to keep things as stock and off-the-shelf as possible, so that this was easily reproducible by others.

To me, building a standard x86 PC from boards is not really in the same neighborhood of what I wanted to do here.  I want to do something with the feel of the Apple I for example.  Buying components, making wiring harnesses, writing firmware to control it, and having the primary user interface for it be a BASIC environment, much like the home computers of the 1970s and 1980s.

The name "BL-328" is taken in the same way that the TRS-80 got its name (Tandy/Radio Shack Z80 based computer.) For this, I went with "BL" signifying "BleuLlama", the nickname I use for IRC, and "328" signifying the ATMega 328 AVR microcontroller in the form of an Arduino.

I should note that Ben Heckendorn recently did a similar project, which you can watch his project on The Ben Heck Show.

To follow along with this first step, all you will need for the first step is an Arduino board, available from Adafruit, Sparkfun, Radio Shack, homemade, etc.   The one I'm using is one I bought a few years ago from Sparkfun, the Arduino Pro.

This one has the pin header on the right side there which connects to an FTDI cable to a host computer.  I will also be using this connector to power the entire system through the use of the FTDI-USB cable, AA Battery holder, or rechargable battery pack.

To start off, I took "TinyBasic" which had been ported for use on the Arduino by Michael Field, and I have since expanded upon(github project link).  I have added SD card support with loading and saving, data pin IO, as well as graphic functions specific to this project, but I'm getting ahead of myself.

Downloading that project's TinyBasicPlus.ino to the Arduino will give you a Basic interface with few hundred bytes of program space free.  You can use the "Serial Monitor" which is bundled with the Arduino IDE to interact with it.

The Arduino has 13 digital IO pins, some of which can be used for pseudo-analog output through the use of PWM,  as well as 6 analog Input pins, which can also be used for Digital IO.  A simple program to print out 10 results from Analog input 3, and turn on digital output 5 is as follows: (Note, that this assumes a new feature of TinyBasicPlus, "autoconfigure" is enabled)

10 REM example program

20 DWRITE 5, HIGH

30 FOR A = 0 TO 10

40 b = AREAD 3

50 PRINT B

60 NEXT A

You can write programs that will read port pins, write to port pins, and then load and save to an SD card, if you have FileIO enabled.  The SD interface I went with from this was the SeeedStudio SD Card Shield which was reasonably priced at Radio Shack.  It is hard-configured for its "select" to be on pin 10, which is shown in the TinyBasicPlus.ino file.  You will need to comment out the #undef for fileio and SD card support, and remove the comment for the related #define.  In its current state, it uses the SD library included with the Arduino package, this uses 9k bytes of program space, which is a lot.  I need to find a smaller SD library.

Now that this is enabled, the above program could be saved out to the SD card like so:

SAVE example1.bas

And then re-loaded later like so:

LOAD example1.bas

Recently, a feature was added to TinyBasicPlus that lets programs be autoloaded when you power on.  This is especially useful if you want to write your program (or programs) in BASIC on the device itself, rather than through the Arduino IDE in C.  This is accomplished by enabling the AUTORUN feature in TinyBasicPlus.ino, and by saving your startup program as "autorun.bas".

You can go a step further and have the end of your program "chain" to another program.  That is to say, you could have it load and run another program. eg:

the file "autorun.bas":

10 PRINT "Hello"

20 CHAIN "two.bas"

the file "two.bas":

10 PRINT "World!"

20 CHAIN "autorun.bas"

This will start up, run the "autorun.bas", which will then load the "two.bas" program, which will chain to the "autorun.bas" program, forever.

Enough with the software though.  I'll now get into a bit of the hardware, namely the power system.

As mentioned before, there are a few ways we can power the system.  Currently, since the only interaction you have with it is through the serial port/FTDI interface, you'll have it powered through that, but once we bring this thing into a standalone configuration, we'll want battery power.

The first power pack is a 4AA battery pack with a switch that I picked up from Adafruit. This has the power lines wired to a 6-pin interface like the FTDI interface has.  This lets me use standard AA batteries (rechargable or not) to power the device.

Next up is a USB-based rechargable battery I picked up at the local supermarket for $20.  It's a rechargable (Lithium Ion, perhaps?) battery with Mini USB input for charging, then standard USB for output.  I could use the FTDI cable off of this, but instead, I decided to make a tiny adapter so that I can plug it directly in through the same 6 pin interface:

I have no idea how long either of these will power the system for.  I'm guessing a substantial number of hours.  I've also since made a cable that connects between the battery pack and that header, rather than that little widget pictured above, which is essentially a USB cord whose power lines are wired directly to the FTDI connector.

Using the above, you can hook up an LED to digital pin 5, and do a version of the "Blink" program included with Arduino:

the file "autorun.bas":

10 REM Basic Blinker

20 DWRITE 5, HIGH

30 DELAY 500

40 DWRITE 5, LOW

50 DELAY 500

60 GOTO 30

Then, disconnect the FTDI cable, hook up the battery, and it should blink the LED forever.

That's it for this time.  Soon, we'll convert an old Commodore 64 keyboard into an input device for the computer, add LCD modules for output, and other goodies so that we'll be able to go standalone and not need a host computer at all!

Amiga 1000 Repaired!

Amiga 1000 computer (1985) with an Amiga 3000 "pregnant" mouse.

One of the fun things about owning retro computers is that you get to repair them yourself. (Perhaps this isn't a fun thing for some of you, but I really enjoy it.)

About 6 years ago, my Amiga 1000 started showing some strange behaviors but only in the green levels of the video.  If you dragged the green slider, instead of it stepping up gradually from dark to bright, it would get brighter, darker, brighter, darker, much brighter, a little darker than that, and so on. The following video shows this...

About 5 years ago, I had opened it up and replaced two '244 latches in the video output section.  I kinda did this blindly by looking at the schematic...

Video output circuit on the A1000
Left to right: Denise coprocessor, '244 latches, resistor ladders, and output transistors.

...and replacing the two latches, assuming that one of them had gone bad.  After doing the repair, the problem persisted and I just gave up on it for a while.

Green section is at the top.  The two '244 latches are now socketed and replaced.

A few days ago, a comment on the above video re-sparked interest in this project and I decided to bring the Amiga over to Interlock and really get to the bottom of the problem. I hooked it up to a scope and followed the paths according to the schematics.

Amiga 1000 apart, hooked up to a scope and a LCD monitor.
The video circuit is on the left edge of the board, just under the power cable.

I traced the lines from input on Q2 (where all of the four resistors in the D-to-A resistor ladder are joined, and back through to the latch, and then continuing back to the Denise video generation coprocessor.

I tried jumpering across various portions of the resistor ladder to try to track down exactly where the issue was.  It gave some pretty interesting results, but really only helped me track down where the issue is.  I eventually came to the realization that something on the R55 data path was drawing it down to ground, or at least close to ground. (Where the left alligator clip is attached in the above picture.)

The "Green" section of the video generation circuit in
the Amiga 1000 with notes

I tried pulling out the pins on the Denise's G1 output (pin 29) and soldering it directly to pin 15 of U6A, and it didn't change anything.  I then pretty much realized that the issue was on the other side of U6A -- the connection between pin 5 of U6A and the left side of R55 (4k resistor).  I decided to leave the above wire "flying" and pulled the resistor leg, soldering it directly to pin 5 of U6A.

This did the trick!  It worked.  I probably could have restored the flying wire back to the original traces on the board, desoldering the wire, re-seating the chips, but I had flexed those pins in and out a lot, and decided to not stress out the pins anymore, and just leave it.  -- "It works... don't touch it!"

After 5 years of it sitting on a shelf, my trusty 'ol Amiga, my favorite computer, is finally is working again!

Puzzle Cube Hacks

There are a lot of hacks of Rubik's style puzzle cubes out there.  Many of them require modifications of the shapes of the pieces themselves, like Tony Fisher's "Fisher's Cube", which rotates one plane of the cube by 45 degrees.  It makes it very confusing to solve.  Similarly is the "Windmill Cube" which also rotates one plane.  Others slice away at portions of the cube to produce a dodecahedron.  (Many of these can be found on TwistyPuzzles.com).

Another modification of twisty puzzles involves restickering a puzzle cube to do things like maze puzzles, color-sudoku, and such.

I decided to do a take on this.  I had a "stickerless" DaYan 2 Guhong "speed cube" that I had bought to see what this design of cube felt like.  I'm by no means a speed cuber, but I figured I'd check it out.  I decided that this cube would be a platform for trying a few different puzzle mods.

Being "stickerless", this meant that each piece's plastic is actually the cube's color (red, orange, blue, green, yellow, white) rather than having stickers applied to a black plastic cube.  I kinda like the look of the stickerless cubes.

The first one I did was to shuffle up the cube, and put stickers (in this case, vinyl electrical tape diamonds) on it to look like pips on a die.  In its solved state, it looked like a multicolored die, 6 opposite 1, 3 opposite 4 and 5 opposite 2.  I didn't leave this cube in this state for very long, as I found that it was impossible for me to solve once it was mixed up.  I cannot find a picture of it.

Next I decided to do something with it that I'm pretty sure hasn't been done before. I made it into an "Inverted" cube.  Rather than it having colored stickers on a black cube, I have black stickers on a colored cube.  Unfortunately, I ran out of black stickers, and had to use purple for the white side, but I've got some stickers on order to replace that and "complete" this cube.

It's a nice fun challenge to only be able to partially see the colors of the sides. I really like solving this one.