I am making a full sized Sol-20 reproduction, the first fully assembled microcomputer with a built-in keyboard and television output.
To make the experience fit your profile, pick a username and tell us what interests you.
My Fubata MD-4PCS key switches finally arrived! Time to get the keyboard put together. The first step was to add the 85 IN4148 diodes. To save some time I printed a diode lead bender from Thingiverse.
I was super careful to double and triple check the orientation of each diode since trying to replace one after all the switches are installed would be very hard.
You can also see that I have installed the screw-in stabilizers for the space bar and Shift keys plus the three limiting resistors for the Local, Upper Case, and Shift Lock key LEDs. On the back a 2x20 pin female connector was added to mate with the encoder.
On the aligner PCB there are four extenders to be used with the Spacebar and Shift Stabilizers.
Snip these off and as the text instructs you have to file down one end so that it is 1.5 mm thick so they will fit into the keycaps.
This is how they will be installed when you first start adding switches attaching the aligner and keyboard PCBS.
Make sure that they pass through the openings in the aligner as pictured above.
I followed Dave's advice adding the switches.
Here is what I have so far. The wires you can see on the left had side of the keyboard are for the Local, Upper Case, and Shift Lock key LEDs since I found that the leads on the LEDs that I had were too short.
Using one of the keycaps I cut the wires so that when the LED was attached it would extend up into the keycap without touching the top when the key was depressed. Looks like this.
Finally I attached the encoder via the 40 pin connector. There were holes on the encoder and keyboard PCBs but I found they did not line up correctly and would have been hard to reach at any rate. So I printed a brace to secure the front part of the encoder board.
That's pretty much it for the keyboard. I'll attach the keycaps once I have verified that everything is working as expected.
I finished the cover for the back part of the Sol-20. I had to print it in four parts which I glued together and braced.
If I get another 3D printer it will have a 500 mm x 500 mm print bed for sure. Or maybe I can just get Ivan Miranda to print these large parts for me ;-)
At any rate the panel fit perfectly on my Sol-20 frame.
Seeing more of the light blue convinces me that it's my preferred color choice.
One of the things that makes the Sol-20 so memorable is the logo bar of yellow/orange lettering that runs the full width of the body. Stunning. Needless to say I wanted to do a good job of reproducing the logo.
Again I have to thank redjr16 who sent me a great picture of the logo from his machine.
With his picture, and knowing the dimensions of the logo (width 446 mm), I brought the image into Fusion 360 as a Canvas and calibrated it within fusion to it's actual size. Using Fusion drawing tools (mostly splines) I "traced" the letters and icon and ended up with a sketch of the logo.
My plan at this point was to save the sketch as a DXF file, bring it into Inkscape, add the colors, and print the logo onto cardstock which is what was done on the original Sol-20. I even had a piece of acrylic cut to size to go in front of it to protect it, again like the original.
I have had some success in previous projects "drawing" text by extruding the letters and printing them in a different color by pausing the print at the appropriate layer and switching the filament. So I decided to give this a try. To my delight this worked better than expected.
The small amount of relief afforded by the extrude characters makes them really pop. So as not to waste, I am using the acrylic piece as a backing for the printed logo which is only about 1 mm thick.
Here is a sneak peek at the logo bar in place. I have only just started printing the top panel.
You might be asking "Hey Mike what's with the two different blues?". I tried the lighter blue on the top panel and I like it better, so I will eventually be reprinting the keyboard panel to match.
So I'm working on the blue console piece that extends from the logo to the back of the Sol-20. Having the DXF for the inside panel that this rests on is a big help getting the measurements right, but since the total print time for this piece is 11 hours I really wanted to make sure the fit is correct. So to that end I invested 30 minutes to print a 10 mm slice of this piece just to be sure.
On the right you can see that the console panel extends a bit past the acrylic plate that covers the logo with a little overhang. On the left it wraps around...oops
Ironically at this point in writing the log I realized that the curved part at the back was wrong, and should not just follow the inside panel like that. It needed to look more like this:
So a few tweaks to my model and another 30 minutes of printing and I get this:
Much better. I feel a lot more confident now kicking off those long prints.
Maybe I should change the title to Measure Thrice...
I talked about Dave's very flexible encoder in my previous log and in this one I'll cover it's construction.
I'm still waiting for the keyboard switches to arrive (last seen in Chicago IL), but the hardware for the encoder hit my mail box a couple of days ago. I followed Dave's assembly notes on GitHub. Here is what the end result looks like.
The assembly was all pretty straight forward. Nothing to see here. What was a little trickier was flashing the ATmega328P with the encoder firmware. Dave uses Atmel Studio 7 to build the firmware and a high end Atmel-ICE programmer burn the chips. A little out of my price range.
Fortunately you can use practically any Arduino as an AVR programmer. There is a lot of sometimes confusing information online on how do do this. I'll just tell you about what worked for me.
I started by opening the Arduino IDE and loading the sketch ArduinoISP.
I had a Arduino UNO attached on COM12 so I compiled and uploaded ArduinoISP with the following settings.
Then I switched the Programmer: setting in the IDE to Arduino as ISP.
Using jumpers I wired the Arduino UNO to the encoder board's ISP Header with the following connections.
|Pin 10||Pin 5 (RESET)|
|Pin 11||Pin 4 (MOSI)|
|Pin 12||Pin 1 (MISO)|
|Pin 13||Pin 3 (SCK)|
Here is my setup.
The Arduino IDE uses a command line program called avrdude under the covers to flash AVR devices. Getting the command line parameters to this program correct can be tricky. Fortunately there is a GUI called avrdudess which can be found here that I downloaded.
I didn't have an environment setup to build Dave's encoder firmware, but he was kind enough to send me the latest build's HEX file. At this point I was all set to flash the ATmega328P on the board. I fired up avrdudess.
I altered the following inputs:
Then I pressed the Program! button. You can see that the writing and verification all checked out so the keyboard encoder is ready to go.
The keyboard in the Sol-20 was a capacitive keyboard made by Keytronic. These keyboards had a great feel, but unfortunately, the foam pad present in each key deteriorated over time and virtually all keyboards of this type failed. To be fair it has been 45 years since the Sol-20 was introduced.
If you are lucky enough to find a vintage Sol-20 for sale (and can afford to buy it) you will probably be faced with this keyboard issue. Fortunately all is not lost. One option is repair. Geoff Harrison has figured out a way to make his own foam pads, and has a nice write-up on how he did it. Please see Geoff's web page on how to repair a Sol-20 Keyboard. Also Texelec has a 105 key replacement pad set at a reasonable price.
The second option is to replace the keyboard. I have already mentioned Dave from osiweb.org who has designed a complete replacement keyboard for the Sol-20 using modern Cherry key switches. While not an exact replica, Dave has gone to great lengths to reproduce the look of the original keyboard, including having a set of custom Sol-20 specific keycaps manufactured. Dave's keyboard will drop right into an original Sol-20. So cool.
Fortunately Dave's keyboard is also perfect for someone trying to make a Sol-20 reproduction. I received Dave's keyboard kit yesterday. Dave offered to ship me an assembled keyboard, but I didn't want to deprive myself the fun of soldering one up myself.
You can see above the keyboard PCB and aligner for Futaba MD-4PCS switches. The bag to the right is a set of "standard" keycaps. The keycaps below the PCBs are Sol-20 specific keycaps that Dave had manufactured, and the smaller PCB to the right of that is the PCB for a very flexible encoder with the following capabilities (from Dave's GitHub repository):
I'm chomping at the bit to get started on this but the actual Futaba key switches and some of the other components I need to populate the encoder are still in transit. Patience Michael, patience.
I've been in a bit of a holding pattern waiting for external stuff to happen. For instance my local makerspace is in the process of rewiring the woodworking shop which includes the CNC that I want to use to mill the walnut side panels. In the mean time I have been taking the pre-requisite online courses in order to qualify on that particular piece of equipment.
Similarly I have been waiting for Dave's keyboard kit to arrive (from osiweb.org - a complete replacement keyboard for the Sol-20). According to the USPS tracking it is currently in Toronto which is about 100km from where I live, hopefully this will arrive tomorrow.
Even though I can't make the walnut side panels right away I decided to get going on the Sol-20 case. In addition to creating the reproduction keyboard, Dave has also produced DXF files for the side panels.
As you can see there are two distinct parts. There is the outside panel that will be milled from walnut, and an inside panel onto which the blue console pieces will rest. There are a lot of cutouts on the inside panel that were used to attach internal components from the original design like the 5-slot S-100 bus cage and power supply. In my much simpler reproduction these will not be used.
With the side panels pretty much a known quantity, there were still many unanswered questions. For instance how wide are the blue console pieces? I know the size of the keyboard cutout from Dave's KiCad files, but how is it positioned relative to the edges of the case?
Well redjr16 to the rescue. Rick, who actually owns a Sol-20 (I'm totally jealous), was kind enough to take the time to answer these questions, take pictures, and more. Thanks Rick!
With these measurements I was confident that I could produce a Sol-20 body that was pretty close to the original's. I loaded the DXF files into Fusion 360 and produced STL files for each of the side pieces. Then I brought these STL files into TinkerCAD so I could noodle around with the design. Here is what I ended up with.
I used the laser cutter at my makerspace to cut four of the inside panels (blue) and two of the outside panels (red) from 3 mm hardboard. The outside pieces will be used as templates when producing the final walnut panels, but in the mean time I can use them as stand-ins while I work on the case panels. The cross pieces (yellow) are 1" x 3" pine cut to 434 mm lengths and are attached to the inside pieces with #8 x 1 1/4" flat head wood screws (in which the heads should end up being flush with the panel). Outside pieces are for the moment bolted to the inside with M3 x 12mm bolts and nuts using existing holes.
Using the inside panel DXF outlines as a guide, and with additional pictures from Rick, I modelled the keyboard panel seen in the rightmost photo above. I lucked out because the width of the panels (446 mm) will just fit on my printer if split in two. The pieces are then glued together and reinforced with cross beams.
The panel is 3 mm thick which seems to be sufficient to prevent sagging in the middle. It shouldn't be too hard now to finish the rest of the console pieces.
When I was working on the virtual display I skipped a couple of improvements in the interest of finishing some of the other stuff like keyboard and virtual cassette tapes. The first was the aspect ratio which was more like 16:9 than the period 4:3. This has been adjusted by altering the character ROM images, basically by doubling every scan line.
I have also added an optional virtual blinking cursor, the original's display hardware took care of this. The original Sol-20 also had a bank of 8 dip switches that controlled display options like SOLID and BLINK cursor. I'll be adding a similar set of switches to my reproduction, but for now the BLINKING_CURSOR option is a Boolean in my Python code.
My local fine wood place (A & M Wood Specialty) hooked me up with a beautiful 1/2 inch walnut slab.
You can also see a template for the side panels that I have laser cut. My woodworking skills are limited so I'll be leaning heavily on some of my makerspace mates for advice and guidance.
I've been working on this project for a few weeks now. In that time I did a fair amount of research, but mostly I was writing a Sol-20 emulator. I thought about using Jim Battle's Solace emulator, but it is Windows based and ultimately I hope to run my Sol-20 reproduction on a Raspberry Pi 4.
Since the Sol-20 was based on the Intel 8080 microprocessor I thought that would be the logical place to start. Fortunately for me, Space Invaders and some of the other early arcade machines also used the 8080. Because there is a very active gaming community helping to preserve these retro classics, there are a number of great 8080 emulators to be found on GitHub. I ended up cloning py8080 because it's Python based and I'm more comfortable right now with Python than I am with C++.
So with a working virtual 8080 processor it was a pretty easy task to allocate some memory for it (64K because why not), load a monitor program (Solos since it was the default shipped), set the instruction pointer to the start of the program (0xC000), and run the emulator. Success! Technically I had a Sol-20 running in emulation, but it was pretty boring since I had no way to interact with it. Time to create some virtual devices.
The system memory used by the Sol-20 is as follows:
C000-C7FF - System ROM. Sol-20 "Personality Modules" like Solos are mapped here. C800-CBFF - System RAM. Reserved by the system. CC00-CFFF - Display RAM. Shared memory between the CPU and VDM-1 video circuit.
Although most systems shipped with only 8K or 16K of memory (or less) in those days, I have to wonder why they didn't map these addresses up into the F000-FFFF space to allow a contiguous 60K memory space for user programs. At any rate the important thing to note for display purposes is the CC00-CFFF shared video RAM. This 1K space was used to store 16 lines of text each of which is 64 characters long. Any text written to this memory would automatically be displayed on the screen.
Using PyGame I created my virtual screen. I could have written the characters from the shared video memory directly to the screen but the Sol-20 used a lot of unique character glyphs.
So based on the original 6574 character ROM I created a set of character tiles that I could easily "blit" to the screen. I wrote a function to iterate over the 64 x 16 array of characters in the shared video memory and write them out to the screen and added this function to the main loop of my emulator. When I did that I was rewarded with this. I know the aspect ratio is off here. I'll deal with that later.
Wow. Still super boring but I see a > prompt so progress. I realized that the display was being updated every time through the main loop so I added a check in the 8080 emulator to set a dirty flag whenever the shared video memory was written to and now only update the screen when the dirty flag is set. Good enough for now.
The 8080 can communicate with peripherals through shared memory locations like the Sol-20 display does, or through I/O ports. I/O ports are accessed via the 8080 op codes IN and OUT. There are 256 possible ports numbered 0x00-0xFF. When an IN instruction is executed the 16-bit address bus is set with the port number of the request in both the upper and lower bytes of the address, the IORQ (Input/Output Request) line is held high, and a data byte is retrieved from the 8-bit data bus. Similarly, for an OUT instruction, the 16-bit address bus is set with the response port number in both the upper and lower bytes of the address, the IORQ line is held high, and a data byte is written to the 8-bit data bus. You can think of this block of ports as a separate "memory space" for the 8080.
For the exception of the memory mapped display, all communication between the Sol-20 and peripherals is accomplished via I/O ports. I have added code that "handles" the IN and OUT op codes and emulates device interaction....Read more »
Become a member to follow this project and never miss any updates