Show 143 - An Interview with Bob Armstrong of Spare Time Gizmos

Hi there,

Show 143, an interview with Bob Armstrong of Spare Time Gizmos, has been posted on the Retrobits Podcast feed.

This was a really fun interview - it was neat to hear about the genesis of the SBC 6120 and the Elf 2K kits.

- Earl

Reversi64 Development Underway

For Retrochallenge 2013 Winter Warmup, I've started in with the Reversi64 development. Here's a rundown:

Reversi64 is (will be) a networked two-player game of Reversi for the Commodore 64. It uses the Flyer Internet modem for communications. Once it's complete, I hope to roll it out for a couple of other Commodore platforms, including the Commodore C128 (in native mode), PET, and VIC-20.

My goal is to have a working prototype by the end of the month.

I've set up a website for tracking Reversi64 progress, including a dashboard of issues that I'm wrestling with, and potential solutions. It's at:

http://reversi64.weebly.com

Some more screenshots and blog entries to come.

Onward!

PX-8 virtual disk drive - the New Adventures

Back to the drawing board!  Let's get 'er done this time!

Batteries Plus made me a new, custom battery pack for my Epson PX-8 laptop.  It was fashioned after the old, tired battery pack.  Now my PX-8 is working better than ever.

With that, it's time to get back to the project idea for a portable PX-8 virtual disk drive.  I would like such a device to have the following features:

• Use SD card media for storage of virtual disk images
• Run from batteries (maybe rechargeable, TBD)
• Have a decent case for transport (not just a bare PCB)
• Have an interface which allows the user to change virtual disk images without the use of an external device (like a computer hooked up to it)

Those of you who have tuned into Retrobits know this has been a long-term goal for me - I've wanted to make this happen for several years, and have made a couple of fledgling attempts at it.  This time I'm determined to see it through to either Epic Success or Abject Failure.

A slice of Pi with your PX-8?

Given the time that has lapsed since I first started thinking about this, new opportunities have arisen for a solution.  For instance, it seems like the Raspberry Pi may be a suitable, low-cost platform for hosting a virtual drive.  It just so happens that the coolest software for emulating a PF-10 (the 3.5" portable drives for the PX-8) is vfloppy, and it runs on Linux - as does the Pi.  Two challenges might stand in the way, though - the need for a serial port, and battery life.

I've read some reports on the web that the Raspberry Pi might have issues with USB to serial devices, including ones based on the common chipsets from FTDI.  I've heard it's possible to wire a serial port to the GPIO pins on the Pi, and run this through a line driver/converter like the MAX3232 (newer version of the MAX232) to provide a serial port without using a USB device.  Maybe that's the way to go.  In any case, the FTDI issues may be solved in the latest kernels - I don't know.

Another question is how long the RasPi would run from batteries.  High-end current consumption on the RasPi is around 700 mA from my reading.  Running the USB serial device might push that up.  Apparently, Duracell AA alkalines have about 2200 mAH of capacity, which would give you just over 3 hours on a set of batteries.  That would get pretty expensive.  Rechargables would be better.  Even better, someone was running their RasPi from a Newtrent iPhone charger, which has 12000 mAH.  That would last a LONG time, but would add weight, and it is over $50 on sale.

More RPMs on the Propeller

Another not-quite-new but enhanced option is the original platform I considered, which is something based on the Parallax Propeller chip.  When I started thinking about this years ago, there wasn't a good way to write in C for the Propeller, and extended RAM options were limited.  Now, both those problems have gone away.  There are two good C compilers for the Propeller - my favorite is the Catalina C compiler.  Also, there are many circuits available, some available as off the shelf products, which extend the RAM of the Propeller chip.  The one I purchased was the Flash Point RamPage, which has both flash and RAM memory on board, and is supported by the Catalina compiler (and costs only $15.99!).  This should make it easier to port the code from vfloppy, which is written in C also, and is GPL-licensed.

Virtual Virtuality

For testing, and for the time being, I wanted to have a vfloppy setup to play around with.  My main laptop runs Windows 8, and vfloppy needs Linux.  Running Linux in a virtual machine would be cool, but would the serial port redirection work?  Maybe, but I wanted to try something more exotic anyhow - I wanted to test my FTDI-based USB to serial converter.  So I installed Ubuntu 12.04 in a virtual machine, hooked the FTDI device to the Windows laptop, and got the right Windows drivers for it.  Then, I told VMWare Player to connect the USB device to the Linux virtual machine (which saw it, and loaded the right drivers without issue).  I ran vfloppy on the Linux VM, and the PX-8 saw the virtual drives!  Voila!  That was simple, and all with free software.

By the way, to do any of this, you need the proper cable to connect the PX-8 to a PC (or other device).  Information on how to make that cable can be found here.

I'm back in the saddle.  I've got 3 days off, and I'm not afraid to use them.  Out comes the Propeller - and saving my pennies for a RasPi!

- Earl

Back in the saddle

Wow, finally a breather so I can get back to programming?  Excellent!

Here's a screenshot of the NetReversi game so far.  It doesn't do anything yet (other than move the cursor), but some of the logic is built-in ready to be used:

Here's a little snippet of the code.  I'm currently using the Notepad++ editor:

Today I'm working on what might be the most difficult piece of this game - determining if a move is legal.

In Reversi, you play on a 8x8 board, with game discs that are black on one side, white on the other.  Like checkers, you and your opponent both have a color (white or black).  When you take one of your opponent's pieces, you turn it to your color by flipping it.

The way to take one of your opponent's pieces is by surrounding them on the board, either horizontally, vertically, or diagonally.  If you have one of your pieces on one side of your opponent's piece(s), and you place one of your pieces on an empty square adjacent to and on the other side of those opponent's pieces, you turn all the opponent's pieces in between to your color.  For a better explanation of the rules, you can consult Wikipedia's page on Reversi.

The thing is, since a capture can happen from any angle (horiz, vert, or diag), and since you have to circumscribe your opponent's pieces, it's actually a deceptively difficult algorithm to determine if a move is legal.  The best bet is probably to use a recursive function.

More to come, hopefully later today...

Retrochallenge: Sharpening the Saw

After a week or two off, I'm getting back into the swing of things on my networked Reversi game for the Commodore 64.

The rules of Reversi are deceptively difficult to program.  I've been faced with creating a recursive algorithm to check whether a move is legal, and then flip the corresponding pieces accordingly.

In terms of development, I've decided on these tools at the moment:

• CC65 C compiler for 6502-based systems (notably the C64)
• Notepad++ for my code editor (probably will replace this part)
• CC65 makefile for building/testing
• VICE emulator for local testing (can't test network functions with this)
• Real Commodore 128 and Flyer drive/network device for testing (have to move code to the device for testing)

My Retrochallenge goal is to have a working prototype of this game - a 0.1 version, if you will - by the end of July.  I'd better get coding!

April re-launch of The Retrobits Podcast

Hi everyone!

It's been a long one-year hiatus - much longer than I planned. But in April, The Retrobits Podcast will re-launch with new episodes.

Things have been busy here, including co-hosting the Retro Computing Roundtable with David Greelish and Carrington Vanston. That's a fun show, by the way - if you haven't checked it out, definitely take a look on iTunes.

It will be fun to be behind the mic once again for Retrobits. Hope you're all doing well out there!

- Earl

PX-8 virtual drive mock-up - the gory details

I am quite pleased to report that I managed to create a prototype of a virtual disk drive for the PX-8, using a Propeller "Professional Development Board", and a cable (more on this later) to connect to the PX-8. Here is a brief background of the project, and what I wanted to accomplish for the Retrochallenge:

The Goal

Create a prototype of a PX-8 virtual disk drive using the Propeller microcontroller.

Measurement of Success

The virtual drive should respond to a DIR command from the PX-8, and load a single file.

Main Obstacle

Garbled communications between the Propeller and the PX-8 "serial" (peripheral) port.

What we have here is a failure...

The PX-8 communicates with its peripherals over something called the "serial" port. This is different than the RS-232 port (it's got one of those, too); however, it is actually RS-232 under the hood. Specifically, 38400 baud, no parity, 8 bits, 1 stop bit.

The Propeller development board has built in a MAX3232 level converter and a female DB-9 connector wired as "DCE" (like a modem). Part of the stock software that comes with the Propeller IDE (called the "Propeller Tool") is a module for doing serial communications.

I had a model of software to work from - the "vfloppy" program. This software runs under Linux, and is a virtual disk drive for the PX-8. It is open-source, and works great.

But in order to make any progress at all, I first needed to find a solution to garbled communications between the Propeller and the PX-8. When looking at the bytes going to and fro, it was clear something was haywire.

That something was me.

When I constructed the cable for use with vfloppy, I neglected that a serial cable has two types of ground. One is similar to chassis ground, and the other is signal ground. The reference I was reading at the time for the PX-8 serial port connector did not differentiate, so I hooked the PX-8 signal ground to the PC side chassis ground. This made it kind of work, but not reliably, as there was obviously impedance between the two types of ground. Once I figured this out, just a few days ago, the garbled communications went away. Just in time, I hoped, for a Retrochallenge entry.

Now to make the Prototype

I knew I wouldn't have time to actually duplicate the EPSP protocol in time, so I thought, why not capture a session with a working package (vfloppy), then make a Propeller program to play back that session. It's a very dumb program, with hard-coded bytes in and bytes out. However, although a one-trick pony, it would demonstrate that not only could the PX-8 and Propeller now communicate, but actually have a working conversation.

vfloppy has a great debug mode that can output everything that's going on in a session. I captured that output for a session that included:

• Go to the E: drive
• Do a directory
• Load a program called "BATTERY.COM"

The session was REALLY long, with lots of bytes. I knew I couldn't write a Propeller program that duplicated that session by hand. So, I dusted off my Perl brain cells, and wrote a Perl program that took the session output from vfloppy debug mode, and converted it to Propeller "Spin" code (Spin is the native language of the Propeller). Here's the ugly Perl code:



By the way, I know the pictures are not good. The lighting was bad, and I'm out of time. I'll get some better pictures later...

And here is a portion of the Spin program that it helped me to write (this is the Propeller Tool, the IDE for Propeller programming):



Here's a picture of the Propeller development board, wired up with VGA output and RS232 output, functioning as the PX-8 virtual drive:



And here's a picture of the PX-8 before power-up:



In the next picture, I power up the virtual drive and PX-8, then navigate to the E: drive. When this happens, the in/out byte sequence plays between the PX-8 and the Propeller exactly as recorded when I did the real session with vfloppy.

(For the next pictures, you'll have to click the image to get a bigger version to make it readable. Again, sorry for the bad lighting, and the notoriously bad contrast on the PX-8 display...)

Notice the PX-8 happily shows the E> prompt, perfectly fooled that it's talking to a real drive:



This thing is functioning like a player piano - so I have to type everything just like I typed it in the real session. Any deviation will make the house of cards fall down. So next, I type DIR (return), just like I did for real with vfloppy:



Now, the big moment - I actually run a program! From the PX-8's point of view, it still thinks it's talking to a real floppy drive. From the Propeller's point of view, it's just waiting for the right bytes to come in, then spewing what was recorded earlier:



Smoke and Mirrors


Before you say it, I know - this approach is smoke and mirrors, because there's really near zero intelligence on the Propeller side. However, it met my goal in proving that the PX-8 and Propeller could successfully communicate, and that the Propeller, when properly programmed, can be a virtual drive for the PX-8.

Next Steps!


Now that the facade has proven the viability of the project, my next step is to begin to crank out the code that makes this thing a virtual drive for real.

An SD card will serve as the mass storage for this device. I've used an SD card with the Propeller before, so that assumption should be a safe one.

The vfloppy code is a very useful reference implementation, but I want to make sure I understand everything that it does, and not just copy the logic from it. As I work through the reverse engineering and compare with the published Epson protocols, I'm sure it will be fun and enlightening.

I will keep my progress updated on this blog, and as the project matures, I may actually start a dedicated blog and progress site.

Yay! Time for some sleep! See you all in the Winter Warmup...