RC2019-10 - A102 project - The end of the month of hacking

The short version is that I was super productive on these projects this past month.  I didn't complete it, but I never realistically thought I would be able to.  I lost a week's worth of time, or so, prepping our yearly Halloween Hack (blog post soon)... not to mention losing some time to work on building my Lego Saab 900... (blog post soon too).
One thing I will say, is that by combining the projects together, I tricked my brain into quite effectively "being okay with" working on one project or another, by them all being part of the same project.  So I would say that the month was quite successful.


So Anyway, I'm going to first go through a bunch of goals for the month, for the RC challenge, and in general, and briefly discuss my progress on them at a meta-level.  Then I'll get more into details about the actual work.

Overview and goals

Raspberry Pi / Emulation

I wanted to get the Pi 3 configured and booting right into an emulated  Amiga/Amibian environment.  I got the pi configured with standard raspian instead of Amibian, since I wanted this to be more of a general use machine.  It'd be nice to be able to use it for firmware development of the LL530 as well as the machine that it's targeted for.

So the target changed on this, but it is complete for now.

LL530 Development

I wanted to have the LL530 (USB Interface to Amiga serial keyboards, Amiga/Atari controllers and mice) fully finished.  Although I did not finish the firmware this month, I got more done on the project this month than I had in the past 6 months.  However, I was able to test the DIN pinout to discover that it's backwards, so I need to rev the board for those...

I didn't fully succeed, but I was successful.... if that makes any sense.

RC2014 Integration

I wanted to have an RC2014 Z80 computer built in as well, that I can connect to via serial port, for doing RC dev work without an emulator.  This aspect sadly got the least amount of attention.  I have an RC2014 mini installed, connected to the serial port on the Pi 3.  I've rewired the connection twice now, and I still cannot get it to connect using this wiring.

I spent time focusing on the other aspects.  So... 25% success.

Integration / Battery / Monitor / Enclosure

Most of the effort this past month was in this area.  I wanted to have the entire thing as a finished unit; to be able to be brought to a coffee shop, pull it out, turn it on and use it wirelessly. I can do all of these things right now with it.

So I would say this aspect was completely successful... although It does need improvements, particularly with the screen.

Installing The Linux

I started with a base Raspian image from their site.  I had the Pi hooked up to a HDMI monitor with USB keyboard and mouse.  After using Balena Etcher to get the image onto an SD card, I booted the  machine up.  I went through the basic setup, and updates.

I launched raspi-config from a terminal window, and went through to  enable ssh, i2c, and serial.

Next I installed some useful software packages:

apt-get install screen fs-uae-launcher stella

I made sure that serial was enabled  in /boot/config.txt,

enable_uart=1

I use screen as my quick and dirty way to connect to the RC2014 which is wired up to the uart on the raspi per the diagram above.  The reset line is wired to GPIO 4, so i use this shell script to "hit the reset button":

#!/usr/bin/python

import RPi.GPIO as GPIO
import time

print "Resetting the RC2014."

# setup GPIO4 as an output
GPIO.setmode(GPIO.BCM)
GPIO.setwarnings(False)
GPIO.setup(4,GPIO.OUT)

# send LOW (reset) for 1 second, then restore HIGH (normal run)
GPIO.output(4,GPIO.LOW)
time.sleep(1)
GPIO.output(4,GPIO.HIGH)

print "Done."
# return to high-z state
GPIO.setup(4,GPIO.IN)

The Red and Green LEDs are wired to GPIO18 and GPIO12, and I can run this script to do a nice fadey display on them:

#!/usr/bin/python

import RPi.GPIO as GPIO
import time

red = 18
green = 12

GPIO.setmode(GPIO.BCM)
GPIO.setup(red,GPIO.OUT)
GPIO.setup(green,GPIO.OUT)

r = GPIO.PWM(red, 100)  # channel=12 frequency=50Hz
g = GPIO.PWM(green, 100)  # channel=12 frequency=50Hz
r.start(0)
g.start(1)
try:
while 1:
for dc in range(0, 101, 5):
r.ChangeDutyCycle(dc)
g.ChangeDutyCycle(100-dc)
time.sleep(0.01)

r.ChangeDutyCycle( 100 )
g.ChangeDutyCycle( 0 )
time.sleep( 1 )

for dc in range(100, -1, -5):
r.ChangeDutyCycle(dc)
g.ChangeDutyCycle(100-dc)
time.sleep(0.01)

r.ChangeDutyCycle( 0 )
g.ChangeDutyCycle( 100 )
time.sleep( 1 )

except KeyboardInterrupt:
pass
r.stop()
g.stop()
GPIO.cleanup()

I may rewire these, or wire up additional LEDs to the ones specified with the Amibian/UAE led indicators, which are defined as GPIO4 for activity, GPIO16 for "Power", and GPIO16 for a clean shutdown button.

LCD Monitor

For a monitor, I'm using a $10 3.5" composite monitor.  I had to do a few things to get it to work however.

I had to hack the power input so that it would run off of 5v.  These are made to be used in cars, so they expect 12v of power.  At the time I did this, there were examples of doing this modification on
other displays, but not this model.  I powered it up using 12v, then probed the outputs in the power supply section for a 5v rail... and I soldered a 5V input there.

Once I had done this, I connected it to the 5v power in the enclosure, and hooked up the video input from the composite output on the Pi 3.

One snag I hit though, is that it wouldn't work right, It would flash on when the Pi booted, but it wouldn't show the desktop. Testing the Pi with HDMI or a known working composite input worked just fine though.

I was trying all sorts of things, and eventually decided upon trying PAL  video modes instead of NTSC, and that worked.  I spent some time tweaking the overscan settings as well, to stretch the screen to fit.  I also noticed that the contrast viewing range was substantially better on the top side of the display, so I ended up mounting it in the enclosure upside down, and I flip the video in the pi's config too.

So the changes that all this amounts to for /boot/config.txt are:

disable_overscan=1
display_rotate=2

overscan_left=0
overscan_right=0
overscan_top=5
overscan_bottom=5

sdtv_mode=2
sdtv_disable_colourburst=0

framebuffer_width=320
framebuffer_height=288

Although, as you can see from the screenshot above, it's basically unreadable.  So I was able to get it to work, but any future development on this will need to be with a different display.  Something with at least 480 rows, so that Amiga emulation can be reasonable on it.

Combining it all, and the Future...

I spent a few evenings rewiring that keyboard which mostly works really well.  I'm using a 5000mAh battery and get an undetermined-but-better-than-my-old-iBook amount of time with it.

The display is garbage.  I'm currently looking into replacing it with an HDMI-based 4" Waveshare IPS display with an 800x480 resolution for about $40.  Surely that will require moving around hardware inside of this enclosure, and since the display is meant to piggyback on the Pi, I will lose my integration board.

Obviously, I'll need to install the Amiga emulator, Tandy 102 emulator, my Model-T-Shell, and the Arduino IDE so that I can continue development on the LL530

In short, I'm super happy with where things are now, it just needs some tweaks to get it to be usable as a primary system. :D

RC2019-10 Update 1: A102 Amiga/Tandy/RC2014 Frankenstein

The Enclosure

Since I had started working on this last year, the enclosure is partially completed.  I had removed some plastic ribbing prior to the RetroChallenge, and mounted both a Rasperry Pi 3 and a LL530 keyboard interface board inside of it.  That's about as far as I had gotten last year, so that's a good start. (pics in the next update post)

The Keyboard

I started out with trying to get the keyboard working.  This seems to be the most time consuming portion of the hardware at this point, and has the most question marks associated with it.

The big issue is using the Tandy 102 keyboard with a spare "two header" Amiga 500 keyboard "encoder" board.  I had toyed with the idea of perhaps just wiring up the row/columns to the Tandy keyboard's rows and columns, but this brought up some issues.  Obviously, the matrix would be different... ie; row 2 column 2 would be different keys on the two keybaords.  This would be fine as I could just change the code in the LL530 to convert the fakey-102-500 keycode to be the correct keypress.  I kinda wanted to use the LL530 stock though, so this meant rewiring the 102 keyboard.

The 102 keyboard has diodes at most of the junctions, and there were a different ratio of rows/columns. but I plan on ignoring those by cutting the traces on the board and wiring around them, ignoring them.

I measured resistance for each key on both keyboards.  The Tandy 102 keys ("Alps Mount Round Slider") came out at about 100 ohms when pressed.  The Amiga keys ("Mitsumi KPR Hybrid Switches") were 0 ohms (no resistance).  Could this be an issue with the custom Commodore key matrix scanner on the Amiga encoder board?  Only one way to find out... Wire it up!

I wired up a couple of the Alps keys to the scanner, hooked it up to my LL530 and tried it.  Turns out it all works great, so no worries there! I apparently picked "9" and the left spare key usually between 'left shift' and 'z', which apparently maps to a "section character" (§)

Next, I wanted to try to clean up the keys.  They seem to bind a little as you press them down, as the plastic tube is getting snagged in the mechanism. This is probably due to wear, dirt, etc.  I removed one from the board (four through-hole solder pins), and disassembled it carefully to see what I was dealing with.

The keys popped off using an official key cap removal tool... a pair of tweezers wedged under the key.  Then the plunger and dome could be removed from the enclosure by flexing out the two T shaped tabs on the enclosure top. From left to right: the key cap, top cover (snaps on using the two large T shaped tabs), round plunger, rubber dome with carbonized contact, and finally the enclosure with the contacts in the bottom.


As far as I know, all of the keys are contacting/switching okay, but if i need to replace components, they're easy to swap in or replace the entire key.

I also took this opportunity to replace the "caps lock" and "num lock" keys, which are latching, with two spare keys, since I wanted to reuse the Num key for "right Amiga" and the caps lock key needs to be momentary for the Amiga matrix scanner. The pin layouts were different, so i needed to drill new holes in the board for the momentary switches. The switch labelled "56" above is the replaced caps lock, while "57" is the control key next to it.

Four of the "top row" keys of the 102 keyboard, the arrow keys, don't have quite the right snap/click that the others do, due to 30 years of use and wear.  I happened to have a bunch of exact replacements, which I got on ebay for another project a couple years back, "12x12x7.3mm Tact Switches"

Next is the task of remapping the matrix.  I found some commonalities between the two matrices, seen color coded above... the keys in yellow share the same x/y indexing with the Amiga layout, and the other colors only share the same column.  I traced out the schematic on the keyboard, and cut a bunch of traces.  Next up is rewiring it and wiring it up to the Amiga Encoder board.

More to come....

RC2019-10 - The Globbing Of The Projects... Globjects?

Hey.  Long time no post.  How y'all doing?  I'm still here. I've gotten a lot of small things done over the past half year, and a lot of things almost done as well... and some long-standing projects not done too.  So, I've been almost productive...  Anyway, I hope to try something different this month for the RetroChallenge RC2019-10...  Let me explain...

The main projects I've been trying to work on recently are:

LL530 USB interface for Amiga serial keyboards and controllers

I've been poking at it a little over time, and am really damn close to getting the proper firmware done for it, but I just haven't finished it.  Which is stupid because I can actually sell these things once I'm ready!  I have keyboard working for all but my A1000 keyboards, and I have joystick/mouse/paddle working... but not at the same time in a way that I'd be proud of.  I also will eventually need to rev the board to fix three layout issues; a power/ground short, lack of ICSP programming header, and lack of pull-up resistor for VCS paddle sampling.

Llichen-80 Computer (LL80)

Okay, so it's not really a whole other completely new computer... but it is a specific configuration of the RC2014 Z80 computer.  It started out this year as a whole lot of customizations to standard (but old, obsoleted) RC2014 boards to add bank switching, using the 8 bit parallel IO board (the one with all the LEDs and switches!).   Now, I reworked the idea so that I just use the standard "Switching ROM" board and the "64k RAM" board.  That simplifies the design; making it easier to get to the LL80 spec, since just using those two cards replaces two RAM boards, one ROM board, and one IO board... plus no modifications to any of the boards are necessary.

The other part of the LL80 computer is the "LLSuper" board.  This is an arduino-based supervisor of sorts that sits on the serial console port.  It acts as your usb-serial interface for when you use a desktop computer as a console.  This board used a CH376S USB Drive interface to access any flash drive as mass storage (it's a neat part.. like $2 for a board with a USB A port... it talks TTLRS232, SPI or parallel, and handles all of the disk switching, FAT filesystem etc. So there's very little overhead on a tiny ATmega micro.  I also have an I2C based clock chip board for this.  This sits between your console and the RC, and lets you have a kind of shell access to the disk from the console, as well as from the RC.  The RC side of things also got direct access to virtual disk image files with a sector-based interface, as well as direct fileio...

The next steps would have been to write a CPM BIOS and make the thing boot into that.

But I've come to realize that even the LLSuper board is unnecessary.  I can accomplish near-similar things using the standard  "Pi Serial Console" board.  If i use a RasPi Zero, and boot linux on it (or adapt the code in the PiGFX kernel, I can put in my serial-disk IO stuff, for cheaper, without needing to fab up my own board.  I started to mess around with this using my new RC2014 Micro, a Pi Zero, and a slight hack to attach the reset line of the RC to a GPIO of the Pi, so i can now reset the RC from the Pi.

I do have the protocol all worked out for the serial interface using unused ANSI escape codes, which are made for custom purposes like this.

A102 - Portable Emulated Amiga in a Tandy 102 shell

This is one i've wanted to work on since last year. I was trying to get it done before Rochester MakerFaire last November, but burned out on it.  It essentially is a project that joins together a bunch of parts... all of which I have:

• Raspberry Pi 3, with Amibian... booting right into an emulated Amiga environment
• Tandy 102 shell, rescued from some unrepairable 102's
• Tandy 102 keyboard, also rescued (keys bind as they're pressed though)
• Amiga 500 keyboard interface board, from a long-gone computer
• My LL530 USB serial keyboard interface board
• Amiga mouse
• 3.5" composite LCD panel (new, $10 online!)
• large Power Bank battery pack

This project entailed hacking the keyboard (removing the wiring/traces on the board) to convert the scan matrix to match an Amiga 500 keyboard.  This gets connected to the LL530, which is plugged into the Pi.  All of it gets jammed into the 102 shell, and becomes a portable computer. 

I waffled a bit on this... mainly because the keyboard stuff would be a chore.  I want to remove every key, and clean their travel tubes, to eliminate the keys binding.  Wiping out the traces and rewiring the board seems like it's going to be a tedious process... So i kept thinking that maybe I should make a cherry-mx switch based board to fit the keyboard space instead... and... yeah... i just kept going down that same path of "maybe i should do this other thing" instead... instead of actually moving forward on any of it.

I also pondered putting the entire Llichen 80 computer into this shell... which brings us to...

RC2019-10!

So that's where RC2019-10 comes in.  Why almost fail at three projects when I can almost fail at ONE project! Seems a lot more efficient!

The end result for this month will be to have a working portable laptop computer that runs Amibian (Linux), RC2014 (via serial connection to the Pi) and general Linuxy stuff.

Or, more granularly, here are the tasks as I see them now: (in no particular order)

• Finish the Keyboard + Joystick/Mouse firmware for the LL530
• remove the wires on the 102 keyboard PCB
• clean the travel tubes on the keyboard
• rewire the keyboard to match the Amiga's matrix
• Wire the keyboard to the Amiga 500 interface board
• Connect the RC2014 Micro via the Pi's serial interface pins
• Additional buttons on the device to cleanly shut it all down
• Have it all powered from a 5V/USB powerbank mounted internally
• Serial-console textmode app for Linux that provides the beginnings of a backchannel to 

Stretch goals:

• Full drive interface for the RC2014
• CP/M BIOS for the RC2014 that uses the serial protocol
• Fit the RC2014 Mini + 64k RAM + switching ROM + TMS9918A cards inside the case
• Have the video switchable between the Pi and the TMS9918A video card

Not sure how far i'll get, but it globs together all of the recent projects in a way that I won't feel like I'm neglecting one project by working on the others... since they're all the same project now. :D

Sparkfun Arduino Day / SD-Arduino device

Sparkfun had their "Arduino Day 2014 Sale" this past weekend.  Thanks to their sale, as well as an additional $20 off thanks to Reddit Gold ($4 for one month), I was able to get a whole lot of stuff at a really good price.

So here's what I got:

• Arduino Uno R3 - I wanted a modern board with the 32u4 on it, for doing USB device enumeration type of stuff. My first thought is to put it on my C=64 keyboard, replacing the old Arduino Serial i've got on there, and turning it into a real HID keyboard.  That could be really neat.
• Two Arduino Pro Mini 3.3v - For future projects, including a super small SD interface (below) And for $3, it's a no-brainer.
• Two Arduino Pro Mini 5v - For future projects. Again. $3? No questions there...
• Two soft-power switches - I need one for my Lego RCX/Arduino project, and I figured it'd be nice to have a spare for another project.
• 5v-3.3v level converter - I've modified my old Sparkfun SD shield, which did not have level conversion, using resistor networks, and that was always a variable.  For the next time I need 3v-5v conversion, I have this thing to use, in my toolbox.
• Pack of LEDs - because why not. I needed to pad my order to $50 to be able to use the $20 off reddit coupon.
• Bunch of male and female headers, since I always seem to depleat my supply of these.  Useful thingies.

One of the things I wanted to do with the 3.3v Pro Mini was to try to make a serial-sd device as small and as inexpensive as possible, for a serial-based storage device and SD management shell project.  I did the trick of wiring up an SD-MicroSD adapter to the Arduino.  Since they're both 3.3v, i didn't need to do any conversion, so it's directly hooked up.

It was pretty straightforward wiring here. +3.3v to one pin, ground to two pins, then four data lines. Easy stuff.  The only nonconventional thing I needed to do was to wire up the FTDI connector to the RAW power input, rather than directly to VCC on the board.  My FTDI interface boards are all 5v, so that would kinda fry things.  The short red wire jumper over to the RAW input on the board means that it all gets regulated down to 3.3v, and everybody is happy.

Here's the wiring diagram:

The fun thing is, that it all fits inside of a SD Card storage case pretty neatly. (Well, not including the FTDI interface.) 

I figure that I can eventually work this in with a 2032 Lithium cell holder, RS232 adapter, and shove it into a DB-25 shell, for it to be a tiny "plug into serial port" storage device for my Tandy 102, Amiga 1000 or some other classic machine.

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.