Day 9-10: Losing Momentum

Ok, THIS is why I don't like breadboarding. Total loss of momentum. But to be fair, it has allowed me to replace some components easily. I previously ordered the MC14099 Addressable Latch which arrived today (very quick shipping!), but I am still waiting on the MC14011 NAND gates that will be my "glue logic."

In the meantime, I wired up the switch on the robot chassis and attached the 9V battery terminal more permanently. Along with the addition of some velcro, the battery should stay put now. I am using the unused side terminals on the DPST switch as solder points for my ground and 5V... I hope that isn't a dumb decision but I can't see how they would ever short.

Day 8: Minimaler ICU System

While trying to wire up this breadboard, I realized that I had already made enough changes that it probably warranted another schematic. I mentioned in a recent post (Day 6) that the MC14599 addressable latch in the "Minimal ICU System" schematic in the MC14500b Handbook is only used as an output register. Well, I realized that is not true. One of them is used as register that the processor can read and write to, like RAM. Well, I don't need that part because will be connecting some lines of my data selector to the output register, giving me a couple bits of RAM for free, since I am not using all of the input or output lines. Between this change and my decision to use the more affordable MC 14099 addressable latch, I had made a lot of changes to the control logic. So, an updated schematic was in order. I didn't want to start a schematic from scratch, so I just edited the schematic in the handbook today:

This simpler ICU system is my "Minimaler ICU System". It doesn't show every connection, but it will definitely help me complete my breadboard wire-up while I work out the details.

• MC14500B Industrial Control Unit (ICU)
• MC14512B 8-Channel Data Selector
• MC14099B 8-Bit Addressable Latch
• MC14040B 12-Bit Binary Counter
• MC14011B Quad 2−Input NAND Gate
• AT28C16 EEPROM

Day 7: Breadboard wires.

Breadboard wires, boring, not finished. 'Nuff said.

Day 6: Some Switches

In trying to figure out the best way to attach this most common of switches, I found some tiny rivets that fit the small chassis holes well. But there is no way I could crush them enough to grab the large mounting holes in switch, so I would need some washers with tiny holes in them too, and I then would not be able to remove it without some grinding. Ultimately, I just decided to carefully drill out the holes to 3/32" which nicely fits a #2-56 bolt. I have plenty of hardware that size. BTW, sorry to the metric people, but these 80's mechanicals for electronics are all imperial. I am reluctant to do the conversions because I am not totally sure if hardware in the size I convert to is available or would work. Lets just say that is a bit over 2mm. Anyway, the edge of the hole is very close to the cut-out for the switch, but it works. Between the TO-3 voltage regulator and the old-school switch, the robot is getting quite a retro vibe. I am not sure that I am really feelin' the red now though.

To fix the counter-rotating wheels, I swapped one wheel onto the opposite axle for the motor, then rotated the motor in the case so that the wires come out in the right spot, and moved the motor mount to the opposite side. Once I realized that my longer motor mount screws were touching the voltage regulator case again, I had to take both motor mounts off and switch the screws around. I guess I could have just swapped the positive and negative wires, but I wasn't sure of the consequences and I didn't feel like soldering. It seems to be set-up properly now, even if the motors are not quite perfectly symmetrical.

As I was starting to wire up ICU on the breadboard, that obviously counterfeit MC14599 was really bugging me. There just aren't any reasonably priced ones available and there is not a cheap CD series equivalent. Then I noticed on the data sheet that the MC14599 is the same as the MC14099, but the former is bi-directional. That's weird because it is only used as an output register in the "Minimal ICU System" which the MC14099 is fully capable of. I can only speculate that the inverted write select input corresponds better with he MC14500B, and saves an inverter. Well, if that is the only benefit, I am going with a real MC14099, and adding an inverter. Purchased.

Busy connecting wires and looking for my breadboard power supply. I decided to use hot glue to affix the ends of the jumper wires to the breadboard and keep them in place. I think it could use this extra help, especially on a moving robot.

Day 5: Collecting my (digital) wits

I had a lot of IC's arriving by mail over the last month to prepare to build this robot. I made a few small kits and the rest kind of spread around my work area like chaff in the wind. Having a larger project box earlier on would have been a good idea. So, after getting everything organized, I will start with a breadboard with these components:

• MC14500B Industrial Control Unit (ICU)
• MC14512B 8-Channel Data Selector
• MC14599B 8-Bit Addressable Latch (This one is quite clearly a knock-off)
• MC14040B 12-Bit Binary Counter
• AT28C16 EEPROM

Normally, I would just start soldering stuff as it takes a lot longer to put it in a breadboard and then lay it out again for the proto PCB. This project is complicated enough and has a suspect knock-off component, so I will take the time to put everything in a breadboard first. Ideally I would like to use a DM72LS471 PROM for the memory as it is a small dip package, but I don't have a way to program it yet. Instead, the AT28C16 EEPROM will be very easy to program and test with.

On a related subject, my experiment yesterday that resulted in a spinning robot made me realize I needed an on/off switch. Every time I worked on the robot, I wondered what the rectangular cut-out was on the front. Then yesterday, out of the blue, while doing something completely different, it dawned on me that it was for a switch! And not just any switch, one of the most common switches ever. It is a 250V 3A DPST switch that shows up on tons of old tube amp equipment from the 1950s and 60s. In fact, there are 7 of them on the stereo system I am listening to right now. Since they are so common, I had a few tucked away. It didn't dawn on me earlier because it is a huge switch compared to the robot. The fitment (like the TO-3) is a bit off too. The screw holes are so small that I really don't have any nut/screw combos that can fit. Drilling the screw holes out much more is not really possible since they are so close to the switch cut-out. Also the holes in the switch are much bigger. I'll figure something out. I have gotten really good at stripping this thing down and reassembling it...

Note the switch taped into position. That is probably all I will do today... It is a nice day out!

Day 4: Spinning My Wheels

Spinning My Wheels... and that's a good thing! I had some time this morning before work to grind off the ends of the motor mount screws. They are still fairly close to the ground contact, but there's no way they will touch. Even if they do it's not a huge deal. I found that a 5 position Molex KK 2.54/.100 housing fits nicely across the TO-3 voltage regulator's terminals. So, I wired up a little wire harness to connect a 9V battery to the voltage regulator, then directly to the motors.

It seems one of the motors needs to be connected backwards so it will go straight!

That thing flying around the side is the 9V battery hanging on for dear life!

Day 3: Explanations

So, I started right in on this project and didn't really explain much. You can't blame me. That robot chassis had to be built immediately!

My end goal is a line following robot that uses a MC14500B 1-bit processor from 1977 to control it. Now, "1-bit" sounds absurd, but that just refers to the size of the data that it can do operations on. It still uses 4 bit wide instructions, and the address bus and program counter could really be as wide as you want as that is external to the processor.

I won't go into a huge amount of detail on the processeor as there is a lot of good reading available about it:

• Wikipedia
• Motorola's MC14500B ICU Handbook
• Ken Shirriff's epic reverse engineering effort
• Usagi Electric's YouTube Channel where he makes a tube computer modeled on the MC14500B
• av-retro's MC14500B line-following robot from RC2022/10, my inspiration for this project

For my purposes, I will be using an 8-bit wide ROM of some sort. As the instructions are 4 bits wide, that leaves the other 4 bits to do fun stuff like select the input or output registers. Those 4 address bits would give us (2^4) 16 possible 1 bit inputs or outputs to choose from and process. Since I don't need that many for my simple robot, and the standard ICs I am using use 3 address bits, and I am tight on space, I will end up with 8 possible I/O registers to choose from. Four of those will probably be directly connected to each other, providing a tiny amount of memory. For the most part, I will just be copying the Minimal ICU system in the Handbook:

So nothing really revolutionary here. But, I will be adding some additional spooky sounds, and I think I will try to add a fan to make the ghost pop up like one of those inflatable wacky waving arm flailing tube man things! It sounds pretty ridiculous, but so be it!

Just working on the gopher site tonight. Didn't have time to cut off that motor mount screw before the kids went to bed.

Day 2: Power Diversions

Intending to start discussing and working on the MC14500B processor board, I had to change plans when I saw voltage regulators in the mailbox this afternoon. These beauties are 3Amp LM323 +5V regulators in a gorgeous TO-3 package. They scream vintage electronics! No modern switch-mode power here, just the tender warmth of a linear regulator. In a weird stroke of luck (or an odd feature), two mounting holes in the chassis and the large cutout in the middle fit the TO-3 package almost perfectly.

Even if you are not familiar with the TO-3 package, you might quickly notice that there appear to be only 2 terminal pins for a transistor or regulator that typically has 3 pins. For purposes of our 9V to 5V voltage regulator, we need input voltage (9V), output voltage (5v), and common ground connection. The TO-3 package supplies each of these, but the ground is provided by the metal case of the device. As a result, unless we want the robot chassis to be at ground potential, the regulator and its screws must be isolated from the metal mounting plate by some insulators. Unfortunately, the chassis screw holes are not quite big enough for the insulators and I drilled them out to 11/64". Of course, that meant I had to disassemble everything first. So once everything is insulated from the chassis, you still need to make the connection to the case of the TO-3 component with a little eye lug terminal on one of the machine screws holding everything together. It is all delightfully mechanical.

I was so proud of myself and thinking that I might get to hook up a battery to the voltage regulator, then directly to the motors and give it a (uncontrolled full speed) test run. Not so fast... as I was putting everything backtogther, it was clear that the motor mount screws were just barely touching the voltage regulator screws. It probably would not be too big of a deal to just have everything grounded, but it took the wind out of my sails. Too late at night to use power tools to shorten the motor mount screws.

Note the flat white plastic insulator that extends through the holes in the chassis (middle to left of photo), the grey silicone(?) insulator on the other side (barely visible though some of the extra screw holes), the long and thin round terminal sticking through the insulators (extreme lower left of photo) and the metal fittings holding it all together... and of course, the horizontal motor mount screw barely touching the grounded mounting nut.

Parts list once I fix this issue.

Day 1.5: Temporal Fraud

After a bit of research, I realized that the QRE1113 "Reflective Object Sensor" (Digital) that I had purchased for the line sensor would not work for my 1-bit robot. Although it is advertised as "Digital" it requires a microcontroller to charge up a small capacitor and time how long it takes to discharge - "the faster that capacitor discharges, the more reflective the surface is." What, what? Timing a discharging capacitor is not "Digital". I don't even know what that is... "temporal" maybe? The advantage is that you get a gradient input, and you would test for your cut-off (on vs off the line) in software. But there is no way I can do that with my 1-bit MC14500b processor. I could rewire the sensor to be the same as the analog version, then send the signal to a comparator circuit, but I really don't wnat to get bogged down in that during the short time I have dedicated to work on this.

Fortunately, I found a standard sensor board that includes the comparator circuit and will give me a nice adjustable "1 or 0" binary output (or analog if I want). It's certainly not era-appropriate, but the LM393 comparator circuit is probably not too different from what might have been used back in the day.

After getting new sensors ordered, I went to work on the output driver board. I basically copied a circuit I found online for driving small DC motors and duplicated it four times. I know I will need two drivers- one for each wheel, and maybe one more for the sound/light board, and I added a fourth just because it all looked so tidy that way. I still need to get a piece of metal for the heatsink, finalize the layout and get it soldered down. I used TIP110 transistors because they were cheaper and could handle more than enough current to drive the 1.5Amp max power (stalled) requirements of each motor. For a modern build, a MOSFET like the IRFZ44 would be better choice and would have an even simpler circuit. I bought some MOSFETs to test out and if I get this running I will make an interchangeable 'modern' driver board. Note the shrouded connector that will help orient the ribbon cables carrying 9V, 5V, GND and input signals. I also added some jumpers to select whether to use +5V or +9V output voltage.

Stay Tuned for some more thorough exposition and background once I start working on the MC14500b processor circuit.

Current Part List:

Chassis

• FEETECH Mini Round Robot Chassis Kit - 2WD with DC Motors
• 5x7cm Universal Breadboard Bakelite Test Prototype Boards for Electronics Experiments
• Misc. screws and nylon risers from my favorite store, Murphy's Surplus.

Input

• Line Sensor Breakout - QRE1113 (Digital)
• TCRT5000 IR Photoelectric Reflective Sensor

Output

• 4 x TIP110 Darlington Transistors
• 4 x 2.2K resistors
• 2x5pin shrouded header, Murphy's Surplus
• Single row straight pin header, cut to 4 pieces with 3 pins each

Day 1: A late night

I stayed up late to start the RetroChallenge right at midnight. I have been itching to put that robot chassis together! It assembled pretty well, but I have to admit it was a bit daunting to get it together and realize that there are no more instructions from here on.

After the chassis was assembled, I test fitted the proto PCBs that I intend to use. I hope to fit everything on three modular boards: 1) the MC14500b system; 2) medium power switching outputs; 3) sound and lights.

Unfortunately, I see that I am going to have some issues with this setup. There are a lot of mounting holes on the chassis for common 7x5cm (or 7x7cm, or 3x7cm ) PCBs, but they dont align quite right (I assume it is probably my PCBs at fault). Since most of the hardware I have (besides the robot chassis) is not metric I had to open up the holes in each of the proto PCBs a little bit to fit my standoffs. That helped the alignment with the holes in the chassis, however the holes I need to mount PCBs are directly over and blocked by the motors. My screws simply won't fit there. I will probably have to counter-sink the chassis to accept some flat-head screws in the future. Those standard "Radio Shaek 2" 5x7cm power bus proto PCBs need to be rotated 90 degrees and only fit on 2 of the chassis holes, but I don't think I will be using those.

Next I test fitted the light sensor for the line follower. I looked into the data sheet a bit more and I think I am not going to be able to use this "digital" sensor. I will post details to come once I have some time to figure this thing out.

That's it for now, maybe I will make some progress tonight.

Current Part List:

• FEETECH Mini Round Robot Chassis Kit - 2WD with DC Motors
• SparkFun Line Sensor Breakout - QRE1113 (Digital) < May not work...
• 5x7cm Universal Breadboard Bakelite Test Prototype Boards for Electronics Experiments
• Misc. screws and nylon risers from my favorite store, Murphy's Surplus.

RC Robot Preparations

Lots of robot goodies arriving for Retrochallenge! It is taking all my willpower to not assemble that robot chassis...

RetroChallenge 2024 is Here!

I was really inspired by avretro's MC14500b based RetroChallenge project a few years ago. A line following robot is such a perfect application for the 1-bit processor. I was so inspired that I think I will work on a similar project: a Halloween themed MC14000b based line following robot. Unlike avretro, I will try to stick to era-correct main components to get it working and hopefully keep it quite simple.

If I manage to complete that, I also want to get my recently acquired Motorola MicroModule O1A2 working with at least a debugger and figure out a serial connection to my Elenco 6802D5 (rebranded MEK6802D5).

[Bing co-pilot is obviously unfamiliar with the data bus width of the MC14500b]

EXORbus Card Cage and Backplane (Semy Engineering)

In the past I had a lot of difficulty finding a reasonably priced backplanes and card cages for EXORbus systems and ended up trying to make my own. Since then, I have discovered many more PLC manufacturers that made EXORbus based systems and have been able to find more reasonably priced processor cards, backplanes, and cages. As a result, I did not find it necessary to make a new run of my Multi-Plane ExorBus backplanes. Instead, I am going to finalize and open source the design so that others can have it manufactured if they want.

Almost a year ago, I saw a Semy Engineering cage and backplane on sale for about $150. They typically are listed for over $500, but like much of this EXORbus hardware, it sits for sale for a long time, awaiting the perfect buyer who has a malfunctioning PLC system and a silicon wafer production line waiting on it to get repaired. As more and more of it reaches end-of-life, it accumulates on ebay until there is a glut, and finally the prices are slashed. While the price still isn't cheap, it is probably a better deal than trying to make one myself... or so I thought.

Unfortunately, when it arrived, I realized that it did not have a ±12V power supply for the RS-232 line drivers on my boards, only the +5V main power supply. This probably isn't too big of a deal, as most modern equipment deals well with lower RS-232 voltages and I am not planning on running very long serial communication lines. However, I felt like it was worth the time to get this running the right way. So, the hunt for suitable power supplies began.

±12V Options

Searching for a ±12V PSU is pretty difficult, as there is not a widely used term to describe them, and the minus sign usually gets ignored by the search or acts as a NOT operator. "Dual rail" led me to some decent options, and the electronics parts suppler search filters were helpful to find some (expensive) power supplies too. The MEAN WELL PD-2512 is a well-priced option, but it is quite large, and I dont need nearly that much power.

Parallel 12V PSUs

Apparently, you can connect two 12V switch mode power supplies so that the negative wire of one is connected to the positive terminal of the other (creating a GND reference), and leaving you with +12V, GND, and -12V power. While I understand how you could do this with two transformers to effectively create a single center-tapped transformer, I am struggling to wrap my head around how this would work properly with the various diodes and voltage regulators that might be involved in the full power supply. I believe a single 24V power supply with a "virtual center tap" GND reference using a couple of resistors would work as well to give ±12V, rather than just +24V. I am not excited about either of these options and I am not willing to risk my boards if this does not work properly.

MULTI-PLANE

While attempting to solve the ±12V issue, I noticed that my Multi-Plane backplane fit perfectly into the card slot, as was intended (whew)! The Multi-Plane was designed to be an ATX power supply injector for another backplane just like this. However, when I designed the board there really wansn't enough space to include the ATX power connector in a location that would allow to clear the sides of a card cage and clear the cards inserted into the board at the same time. So, To get it to work in this cage, I would need to swap the right angle ATX PSU connector with a straight one (or cut a hole in the side of the cage), but then I would lose a slot, I would still need an external ATX power supply, and I would not be able to use the MULTI-PLANE for anything else. This really isn't a great solution for me, just to get ±12V power.

DVD Universal PSU

In the end, I stumbled across an "EVD/DVD Universal Switching Power Supply Module" that is very cheap (<$6 shipped), widely available, and provides the ±12V at a reasonable 200mA for each rail.

It also includes ±5V power, useful to run cards with old DRAM chips. I will likely be using the +5V for a power indicator light or maybe connect to a relay to turn on the main power supply. I would not want to use this product to run the entire system though, and will be keeping the orignial power supply for that duty.

Installation

The DVD power supply has a 7 pin XH (2.54mm pitch) header for the output power and a 3 pin CH (3.96mm pitch) header for the AC input and another for the switch. I went ahead and bought a pre-made pigtail for the XH header ("JST XH 2.54 2~12 Pin Connector Plug Single Head With 300MM Wire") and rearranged the wires so that the voltages would correspond with the wire colors, just like an ATX power supply.

A used two of the existing holes in the case to mount a couple of nylon posts for the new power supply board. One required a new hole in power supply PCB but fortunately it landed on the ground plane. I glued two more nylon posts onto the case, aligned with existing holes in the power supply board. I rigged up a splitter/extension harness to give the board 120V AC power from the plug socket. I also needed to add a jumper wire for the switch socket so that it will remain powered on. This case does not have a power switch on it, but I expect to add one to a front panel once I get it built.

Next, I removed the backplane and soldered up the pigtail for the DVD power supply to the appropriate pins and ground plane. I also soldered up some wire to ensure that every slot gets the 12V power.

I routed the pigtail (covered in a piece of wire loom for protection and tidiness) under the backplane and card slots, out the side of the case, and back in one of the air holes to the DVD power supply.

After a bit of testing to make sure the voltages looked correct, I plugged in an expendable board and was happy to see everything working!

Now I can start building up a usable OS-9 system that I won't have to tear-down every time I want to do some experiments with another board.

RetroChallenge Day 4: MBC020 video and troubleshooting

A while back, I tested out the video output on my new-to-me SYNERTEK MBC020 ExorBus SBC, and noticed problems with the upper half of the video. I wanted to make sure it was not my LCD monitor that was at issue so, I went out and bought a 9" black and white CRT security monitor to use for further testing. Unfortunately, when I recently went to connect it to the monitor, I could not get the MBC020 to boot anymore!

This is a good excuse to share some troubleshooting tips for these vintage SBCs.

With a multimeter or voltage tester:

1. Check the power rail voltage- this may seem obvious, but is an important first step, especially since these boards usually do not have any power indicators.
2. Verify that RTS or DTR goes low on the ACIA (or high on the serial connector)- This is a very simple check and you don't need an oscilloscope. If RTS or DTR goes low at the ACIA on boot, it indicates that the microprocessor is able to access ROM (to read the firmware) and the ACIA (to configure the ACIA), and is probably running OK. If it does go low but there is no activity on the serial connection then you may have a cable configuration problem, a terminal settings misconfiguration, or a problem with the RS232 driver ICs.
3. Verify that RESET goes high-

With an oscilloscope or logic analyzer:

1. Test clock signal to processor.
2. Test chip select signals to RAM, I/O chips
3. Test data bus and buffers

With this procedure I was able to pretty quickly determine that I had no clock signal to the CPU. After I swapped a few ICs in the circuit around the oscillator with no improvement it became apparent that the crystal was likely at fault. This problem seemed consistent with my nearly 2-year-old son knocking the board off of the dining room table a few months ago. I ordered the crystal and that brings us to now, the first week of RetroChallenge.

---

Replacing the crystal was pretty straight-forward, despite the large amount of solder on the board in that area. I did have to use a small drill bit to completely clean out one of the vias, but no big deal. I really dreaded turning the board on for the first time though. If the problew was something other than the crystal, I would be very stumped and my RC2023/10 would get stalled right out of the gate.

Fortunately, everything came right back to life! The CRT monitor initially showed the same skewed image as the LCD, but after some heavy adjustment to the vertical hold, I ended up with a nice clear display. Although everything seemed to be working, I did notice some spurious "E" characters popping up after a command is completed. I am not sure if this is normal, or some new fault in the board, but I do not recall it happening before.

With everyting up and running, of course I had to mess with video connector and sudddenly I lost video and the terminal stopped responding. I tracked the problem down to a blown 5V fuse on the backplane. I must have short-circuited something. Fortunately, I still have a few hundred fuses left over from when I first built the backplane, so a new fuse and little soldering got it working again. I think I would definitely make the fuses easier to replace if I make another run of these backplanes.

RetroChallenge 2023/10 Preview

This year for RetroChallenge, I think I will focus on some 6502 projects, mostly my Synertek MBC020 ExorBus board. I never got it working correcly as a terminal: skewed video and no keyboard yet. Let's see if I can get all of this working properly! This was supposed to be my project last year before I picked up a Radio Shack Micro Color Computer MC-10.

CMS 9639A Memory Management Processor

A while back I was fortunate enough to spot a CMS 9639A Memory Management Processor as part of a lot of boards in an eBay auction. This board sat on its box for a long while due to the extra cards I needed to interface with it. It does not have a debug ROM, no on-board system RAM, and the ROM is expecting a disk drive card (probably the CMS 9672 DMA Host Adapter) to actually boot from. At the time, I did not even have a proper backplane.

Since then, I built a backplane and re-purposed a relatively cheap MIKUL 6218 Memory and I/O card. After modifying the MIKUL card to have 1MiB of onboard RAM and reprogramming its address decoding to comply with the CMS 9639, I finally had something close to a usable system. Getting a disk drive working with the system was not something I was looking forward to. Fortunately, I had enough experience with NitrOS-9's 'DriveWire' disk emulation on my CMS 9619 port to know that it would be a good fit here too. Also, Søren Roug had done some great work disassmebling my CMS 9639's boot ROM and included it in his osnine-java project. This project includes lots of old Microware OS-9 source code from many systems. It has a very clever Java 6809 emulator that runs a native 6809 assembler to build all of the code.

First, I added the DriveWire module to the end of the boot ROM, in place of the normal disk drive boot module. After much experimentation, I was able to piece together a semi-working OS-9 system from the source code of other systems including the Dragon 128 and Positron 9000. Then, I struggled for quite a while as the computer did not seem to respond to my key input, even though it would send data to my terminal. Note that I had a similar problem with the CMS 9619 which came down to enabling interrupts. However, the CMS 9639 was designed to use OS-9, so it did not have interrupt enabling jumpers like the CMS 9619. I finally figured out that I had a flakey 6551 ACIA after swapping in a known good one. After using some of the NitrOS-9 tools to build a disk image, my CMS 9639 suddenly came to life! Some fine tuning of the modules and I was able to boot to the OS-9 shell and run some simple commands.

I stored all of my configuration to my fork of Søren's osnine-java repository.

---

Left	Middle	Right
CMS 9600A MPU		CMS 9609 MPU
	CMS 9642 SERIAL I/O PROC.
CMS 9619A ASBM		CMS 9639A MMP

---

PS/2 Keyboard - the Retro Way!

I have seen a lot of overpowered PS/2 keyboard interfaces lately: microcontrollers, bit-banged PIAs, PIAs with shift registers. All sorts of complex solutions. Here is my simple contribution, using retro hardware.

It is important to note that the PS/2 protocol is basically just an isosynchronous serial connection with open-collector i/o. Isosynchronous is basically the same as the normal asynchronous serial connection, but there is also a clock signal. To simply implement this protocol, all we need is an ACIA or UART that supports a 1x clock mode and a buffer to make the signals open-collector. The 1x clock requirement rules out the common MOS 6551 (16X clock required), but includes many common alternatives such as the MC6850, Signetics 2651 and Zilog SIOs.

Next, the signals to the keyboard need to be buffered and converted to open-collector outputs. The 74LS05 open-collector hex inverter is a simple choice for this. Since this inverts the signals and the PS/2 data is already at the correct polarity, we need to invert the TX data signal 2x: invert the signal, pull it up, and invert it again. Here is an example for the MC6850:

Sorry for the weird orientation of the schematic; it is part of another project.

Notice that the clock from the PS/2 device is connected to the ACIA as the RxClk, but is also inverted, pulled up and used as the ACIA TxClk. The RTS signal from the ACIA can be used to pull the PS/2 clock low for commands to the keyboard (untested). The data line from the PS/2 device is pulled up and connected directly to the ACIA, while the command data to the keyboard is inverted twice with open collector output.

If you only want to receive data from the keyboard, you can just connect up the clock (to ACIA RxClk) and the data line (to ACIA RxData) through non-inverting buffers (to protect the ACIA). Too simple!

Once you have the data from the ACIA, you will unfortunately need to use a small lookup table to translate the PS/2 keyboard codes to ASCII. A small PROM on the data lines of the ACIA could also work, but you would also need a tranceiver to do writes to the ACIA and a decoder to make sure the data moves through the PROM or tranceiver at the right times.

The one issue with this technique is that when using the 1x clock mode on the MC6850, I think that the the ACIA needs one more clock cycle than the PS/2 protocol provides per byte to indicate that there is a byte available (this could just be an issue with my clock phasing though). As a result, the input buffer full flag does not get set until the start of the next byte. Unfortunately, this means you are always one byte behind the keyboard. That may seem like a non-starter, but in reality, it does not affect much because the proper key code does get sent when the key is released. So every key press/release cycle sends you:

[previous key code]...[key code][break code]

instead of:

[key code]...[break code][keycode]

So, the key code for the current key is available when it is released, or when repeating. Not perfect, but it is much simpler than many of the solutions out there. It definitely needs more testing, and I would love to hear your results. This makes me want to try interfacing with a PS/2 keyboard and a character LCD with a single ACIA.

MC6800 assembly available for a test program:

MC-10 to EXORbus adapter

I previously hinted at a hardware project I have been working on- an expansion bus adapter for the MC-10 allowing it to use EXORbus peripheral cards. The idea is pretty absurd as it the MC-10 is a little low-end consumer computer while EXORbus was typically used for pretty advanced industrial PLC or scientific computers. For instance, an EXORbus serial card would be quite expensive and have 8 ACIAs on it, giving you 8 serial ports, an insane amount for the lowly MC-10. My EXORbus Static RAM card has 1 MiB of RAM on it, also an insane amount for this little guy.

Since the EXORbus is made for 6800/6809 processors, and the MC-10's expansion bus is mostly just unbuffered signals from the mostly compatible processor, all we need is a bunch of buffers and connectors and a GAL to do address decoding into the MC-10's memory map. Here is the design I have been working on, yet to be prototyped:

I really wish I could have finished this during Retrochallenge, but I lost momentum with family events and vacations. Next time!

+

Off the MC-10 Wagon

Day 14:

So, I was making good progress doing daily tasks on my MC-10, but lost my momentum after a camping trip. I have been doing minor development and added a new level to my BAM Minesweeper game, but I have been using XRoar emulator instead of the MC-10. Unfortunately, the extra level will not load on my bare-bones MC-10, so I am working on trimming the fat.

BASIC Programming

Days 7-9

I started working on a BASIC game for the MC-10. Previously, I had been able to use the MC's serial port to "LPRINT" any BASIC programs to my Mac. Of course, this did not work anymore, since I had to change the serial cable wiring. So, I had to make a little adapter to make the serial port cable work with the BASIC ROM functions. Very frustrating.

After I got that working I had a decent build chain to write a BASIC game, doing as much of the programming as possible on the MC-10 and saving to my Mac. The line editor for the MC-10 is non-existant, but there are some solutions out there. Still it took a long time for me to write a simple mine-sweeper type game that was based on my TS-1000 efforts in a previous Retrochallenge. As much as I despise the keyboard on the TS-1000, the BASIC implementation is quite good with some conditional printing syntax that is lacking in the traditional MS BASICs. But I enjoyed figuring out how to work around the shortcomings in the MC-10 BASIC. I know there are a number of minesweeper games out there for the MC-10, but they don't seem to work on an unexpanded 4K RAM MC-10. Anyway, I have a working first version that is pretty fun to play. I intend to add a second level before the end of RetroChallenge. I used a few of the tricks that I learned on the TS-1000 to keep memory down. I was also proud of how it only has code for 2 loops - one to loop through the locations on the game board and one to loop through the 8 locations surrounding the current selection. The loops call different subroutines to do the work on each square on the grid based on a preset variable. Probably horrible coding practices, but it kept the number of code intensive for-next loops down to a minimum. Screenshot:

You can find it on my MC-10 Cassette Server.