The Simon project was hand assembled and hand typed.  That was a lot of fun and was rewarding.  However, you quickly hit the limit of what can reasonably be done that way.  Several days after posting it on Hackaday, we had a brief power outage from a thunderstorm.  Retyping it was a 20-30 minute job.  While not awful, this isn't something I want to do every day.

So, it was time to see how "the other half lived" and check out the SDK-85 serial port.  The manual explains the ROM monitor commands.  However, if you really want to know what's going on, AP-29 explains how the 8085 built in serial port works.  Basically, it's just bit banging the SID and SOD pins and using timing loops to achieve the desired bit rates.  While AP-29 provides tables for different baud rates, the SDK-85 firmware is locked to 110 bits per second (7E1).  Furthermore, it does not use a regular RS-232C interface but instead uses a 60ma current loop interface.  This is what the ASR-33 teletype of the time used and Intel chose to support this popular (at the time) piece of hardware.

Section 5-7 provides instructions for converting the SDK-85 to use RS-232C (+/- 12V) signaling rather than current loop.  It begins with the phrase "If you are fortunate enough to have a CRT terminal...".  However, I chose not to do this since it was a modification and I wanted to leave the board as original as possible.  So, instead I designed and built a current loop to RS-232 adapter.

Fig 1 - RS-232 converter

This is a simple circuit that uses optocouplers to bridge between the receive and transmit loops and TTL-level signals which are immediately converted using a MAX232-type chip.

Fig 2 - RS-232 converter schematic

However, when I connected this to my modern laptop, I got nothing but garbled text.  Since scope traces revealed correctly formed characters I decided to do a loopback test.  It turns out that FT232RL-based USB to serial adapters are not capable of running below 183 baud.

Having no other options, I pulled out an old DOS machine with a physical serial port and was greeted with an "SDK-85" prompt.  Success... sorta.

The next challenge was formatting the data.  The SDK-85 monitor allows code to be loaded using the `I` command which accepts a single address, followed by 0 or more hex characters and an escape character.  This is not the standard Intel hex format that my tools emit.  So I did some hacking and came up with a script that converts each Intel hex record into an I command.

Anyone who has connected a vintage computer to a modern one knows what happened next - data overruns.  Lots of them!  I was honestly surprised by this because 110 baud is extremely slow - surely the processor can save a byte of data every 80ms?  But the problem lies in the bit banged nature of the port.  The processor is busy waiting for every single bit (including the stop and start bits).  It has no time to do anything else.

This problem is further compounded by the monitor's echoing back the typed characters.  A bit banged port is half duplex by necessity.  While the processor is echoing the character back, it's not doing anything else.  It definitely can't be receiving another character while that's going on.

The obvious solution is to ask the terminal program to "slow down" and pause between characters.  My "go to" DOS terminal is MS-Kermit, but it only supports inter-line pauses, not inter-character.

Since I didn't want to undergo a market survey of DOS terminal programs, I booted into Windows 98 and used Hyperterminal.  I don't love this program, but I was able to get the job done after enough digging around in the menus.  The secret is File->Properties->Settings->ASCII setup.  After some experimenting, I settled on 200ms delay.

Fig 3 - Hyperterminal Configuration

Twelve characters per second (110 bps / 9 bits) is slow.  5 CPS is really slow.  It took over five minutes to load Simon.  Still better than typing it in, but leaves much room for improvement.  Also, the requirement to use legacy hardware really puts a damper on my workflow.  So, I decided that a more modern serial port (operating at a faster baud rate) is in order.

There is another option, which I decided not to pursue.  You could modify the SDK-85 monitor code to operate the port at a higher baud rate.  You still have the half-duplex/busy waiting problems, but it would be occurring at a less glacial pace.  This is something I might try once I get EPROM programming working.