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

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.