Character ROM Analysis and Formatting Tricks

Here are some details of how to take a look at what is inside of character ROM or verify a character ROM bin file. The commands work well with the Apple II+ (rev. 7 or later) or any MC6845 or MOS 6545 character ROMs. Also, at the end are some commands to get a .bin file into a hex-dump format for the Apple II Monitor.

Dumping a character ROM

One of the simplest ways to dump an actual Apple II+ (rev. 7 or later) character ROM is to remove it and insert it into the ROM socket of a SuperSerial Card (SSC) in another Apple II. Then you can read the data into memory (the example assumes it is saved at $8000), and send it out to your Mac through another SSC. Unfortunately, you need two Apple IIs and two SSCs because neither the SSC nor the Apple II work properly with their ROMs removed. Once you have the monitor dump, you can convert it to a binary file with xxd like this:
xxd -r -seek -0x8000 characterROM.dump > characterROM.bin

Getting ROM files

If you want to use a different ROM file from what you have in your computer, download the Apple II ROMs file from MacGUI, and open the file in your Downloads folder to unzip it.

Checking ROM files

To see the first character of a ROM file, open the Terminal and run xxd to make a short hex binary dump:

cd ~/Downloads/APPLE\ II\ ROMS/APPLE\ II+/
xxd -b -c1 -l8  \
APPLE\ II+\ -\ 7341-0036\ -\ CHARACTER\ GENERATOR\ REV7+\ -\ 2716.bin

If you blur your eyes, you should see an @ symbol in the right block:

0000000: 00000000  .
0000001: 00011100  .
0000002: 00100010  "
0000003: 00101010  *
0000004: 00101110  .
0000005: 00101100  ,
0000006: 00100000   
0000007: 00011110  .

You can make this easier to read by getting rid of all of the zeros:
xxd -b -c1 -l8 \ "APPLE II+ - 7341-0036 - CHARACTER GENERATOR REV7+ - 2716.bin" \ | sed -e 's/0/\ /g'

       :           .
      1:    111    .
      2:   1   1   "
      3:   1 1 1   *
      4:   1 111   .
      5:   1 11    ,
      6:   1        
      7:    1111   .

And even easier to read by:
xxd -b -c1 -l8 \ "APPLE II+ - 7341-0036 - CHARACTER GENERATOR REV7+ - 2716.bin"\ | sed -e 's/0/\ /g' -e 's/1/█/g'

        :           .
       █:    ███    .
       2:   █   █   "
       3:   █ █ █   *
       4:   █ ███   .
       5:   █ ██    ,
       6:   █        
       7:    ████   .

Remove the "-l8" argument to see all of the characters, and you can see the problem with the standard ROM. There are 4 sets of uppercase and symbol/number characters (representing: inverse, flashing, normal, normal), but no lowercase! Apple included a bigger ROM in the II+, with the capability of holding lowercase characters, but did not include them. Fortunately, the ROM files you just downloaded have a lowercase character ROM included. Check it by: xxd -b -c1 -l8 -s 1800 \ "APPLE II+ - LOWERCASE CHARACTER GENERATOR - 2716.bin"\ | sed -e 's/1/█/g' and you should see:

00000707: 00000000  .
00000708: 00000000  .
00000709: 00000000  .
0000070a: 000███00  .
0000070b: 000000█0  .
0000070c: 000████0  .
0000070d: 00█000█0  "
0000070e: 000████0  .
0000070f: 00000000  .

Yes! Looks good!

Converting to Apple II Monitor Format

Probably the easiest way to get these binary values into the Super Serial Card (SSC) ROM memory space is to use the Apple II Monitor. The Monitor can enter values into arbitrary address locations. The format for entering values looks like this:

C200: 1C 22 2A 2A 2C 20 1E 00
C208: 08 14 22 22 3E 22 22 00

Representing the hexadecimal memory address, ":", and then 8 data bytes in hex format. To generate the right format, with data starting at the Apple II+ $8000 memory space, we can use a command:

xxd -g 1 -c 8 -u -o 0x8000 "APPLE II+ - LOWERCASE CHARACTER GENERATOR - 2716.bin"\
| sed -e 's/0000//' -e 's/  .*//' | tr '[:lower:]' '[:upper:]' > ~/LOWERCASE_8000.mon

We could use this LOWERCASE_8000.mon file to load the data to the $8000 address space, then use the Monitor to move parts of the saved data to the SSC. Unfortunately, we can't just use one address if we want to write directly to the SSC, in one step. The SSC firmware address space is broken up so that the entire 2K ROM will fit in the available Apple II I/O address space. Part is in the slot's IOSEL address space, and part is in the shared I/O ROM address space. Assuming the SSC card with the EEPROM is in slot 2, I used a few Terminal commands to get the right format:

xxd -g 1 -c 8 -u -l 256 -o 0xC200 APPLE\ II+\ -\ LOWERCASE\ CHARACTER\ GENERATOR\ -\ 2716.bin | sed -e 's/0000//' -e 's/  .*//' | tr '[:lower:]' '[:upper:]' > ~/LOWERCASE_SSC_S2.mon
xxd -g 1 -c 8 -u -s 256 -o 0xC700 APPLE\ II+\ -\ LOWERCASE\ CHARACTER\ GENERATOR\ -\ 2716.bin | sed -e 's/0000//' -e 's/  .*//' | tr '[:lower:]' '[:upper:]' >> ~/LOWERCASE_SSC_S2.mon

The first xxd command is for the SSC's IOSEL address space. xxd gets the first 256 bytes of the bin file and offsets the addresses to match slot 2. The second xxd command scans past first 256 bytes of the bin file, and then offsets the remaining addresses to match the shared I/O ROM address space. Each of the commands pipes through sed to remove the leading zeros in the addresses and the trailing ascii byte representation. Then they pipe through the tr command to convert the addresses to uppercase hex (not totally sure this is needed), then outputs to a text file.
If you need the SSC card in another slot, edit the -o 0xC200 format string in the first command and change the '2' to whatever slot you need.

Day 31: Debugging and Resignation

Well, I finally worked up the courage to flip the switch on my robot with everything connected. I quickly noticed problems on the logic analyzer. After figuring out some wires in the wrong spots, the robot still would not move. No indication of life except for a few LEDs. Ultimately, I dont think the output latch is getting addressed correclty, but it is 11:52 PM on the last day and I am done for tonight.

Unfortunately, I did not even get to work on the Halloween theme component which was intended to be some spooky sounds and a fan blowing a ghost on top.

The final mess of wires and logic probes balanced on a small robot chassis:

Lessons learned:

• The mechanicals of a small robot like this are very time consuming. I could not count how many times I took this thing apart and screwed it back together to mount and re-mount things.
• The output driver board was an unexpected success. I am glad I learned a bit more about medium power transistors.
• The MC14500 is a really fun and simple platform to set up and design with, but it is fairly expensive to source all of the support ICs.
• I think I had the most fun writing the NOT assembler and code for the robot. Finishing that part led to a lack of initiative to finish the hardware.
• Those little arduino sensor boards seem to be pretty decent for a project like this.

So, that's it. I give up for this month. Hopefully, I can get this finished soon.

Day 23: Firmware

I have been working on the MC14500b firmware for the line robot on and off for a few days. I sort of realized that it is so simple, I probably could have just done it with a few ICs... no processor necessary. Oh Well. I haven't put it on an EEPROM yet, but once I double check my breadbord connections, I will get it programmed.

	; **************************************
	;
	; MC14500b single line sensor, dual motor,
	; line-following robot (with lights and sound)
	; for RC2024/10.
	; epooches@gmail.com
	;
	; **************************************
	;
	; Inputs:
	; RTSENS EQU 0 ; RIGHT LINE SENSOR
	; LTSENS EQU 1 ; LEFT LINE SENSOR - JUST CONNECTED TO MEM0
	; MVCTRL EQU 2 ; INVERTED LIGHT SENSOR
	; RR EQU 3 ; RR STATUS
	; Outputs:
	; RTMOTR EQU 0 ; RIGHT MOTOR
	; LTMOTR EQU 1 ; LEFT MOTOR
	; SLRSET EQU 2 ; SOUND AND LIGHT /RESET
	;
	; **************************************
	;
	IEN 2 ; Light sensor controls all inputs
	LD 0 ; Load line sensor
	STO 0 ; Right motor control
	STOC 4 ; Store the complement of line sensor
	LD 1 ; ien works properly on both motors this way
	STO 1 ; Left motor control
	LD 2 ; Light sensor
	STO 2 ; Control sound and lights
	NOPF F ; Return

view raw linebot.asm hosted with ❤ by GitHub

Day 22: 8-Bit Addressable Latch Testing

Spent a bit of time testing the addressable latch outputs to make sure they could enable the driver board. Very similar to my sensor testing, except I was using the switches to select a motor to start and stop. Success! I think I just need to go for it and write a program and wire up the processor.

Day 21: Driver Board Testing

Today I test the the driver board that I just soldered up. My vintage digital logic trainer is pretty much the perfect 5V signal source as it does not supply enough current to run the motor on its own without a bit of a push to jump start the wheel (it is probably 1 Amp or less). I hooked the 9V battery and hooked up one of the trainer's data switches to the signal for a motor. Nothing. Hmm, the voltage on the data switches does not seem to work the way i thought it would (found out later that I needed pull-up resistors). Well, then I tried the 1Hz signal output from the trainer, and success!:

The motor is definitely pulsing up to the full 9V speed, using only a weak 5V pulsing signal. Exactly what I need! I am so happy that worked, as trouble-shooting the circuit and changing it for each of the 4 channels would have set me WAY back.

Day 19: Soldering up the Output Driver Board

Finishing up this output driver board took a lot longer than I expected. I had to get the aluminum heat sink, cut it to fit, then grind down some of the extrusions, drill some mounting holes through it and the board, then get the transistors and insulators mounted. Then it took a long time to solder everything up as I am using thicker wires than I usually use and the four transistors are packed fairly close together. This thing is heavy! I thought I was being clever by adding 9V and 5V outputs, but it made everything much more complicated. I will test it out tomorrow, but I am glad that this board is close to finished.

Day 18: More Wires

After testing out the inputs last week, I am wiring things up (including my recently arrived quad NAND IC that I am using for glue logic) so I can test the outputs too. Not much progress this week really.

Day 12: Testing the Sensors

I realized that it would be nearly impossible to test every part of the robot at once, so I removed the ROM and processor and just focused on the sensor selection from the MC14512 8-Channel Data Selector. This IC takes an address from the upper 4 bits in the ROM and selects one of the inputs during a read cycle. I was so excited to see everything work the first time that I had to share:

Day 11: NOT an Assembler

So, I am getting to the point where I really need some firmware to test out everything and get the breadboarded control system running. The instruction set on the MC14500b is delightfully simple:

It is so simple that I expected that could just write out the control program in hex machine code and I would not need any sort of assembler. In fact, I specifically wanted to avoid writing an assembler to keep the project moving. Well, looking back and forth at the manual to pick out hex codes got old quick. So then I thought I would just write a quick shell script to convert the mnemonics to hex, then, of course, I would want it to ignore comments and output in a listing format OR a binary... Pretty soon I had a useful tool that was NOT an assembler, because if it was an assembler, that would mean I got distracted from building a robot today. (There is a python script to do this in github, but my personal experience with python is that it takes longer to figure out all the dependency and pip version conflict errors than to just do something manually. There is only so much diversion I can justify.)

	#! /usr/bin/env bash
	# a145.sh
	# Simple mini NOT assembler for MC14500B Industrial Control Unit
	# Example input file contents:
	: '
	; MC14500B ICU code example
	LD 1 ;LOAD SENSOR 1 STATUS
	ANDC 2 ;AND /SENSOR 2 STATUS
	AND 3 ;AND SENSOR 3 STATUS
	STO 1 ;IF 1-3 ARE ACTIVE, TURN ON LIGHT
	NOPF F ;RETURN
	'
	# Listing output
	: '
	0000: 11 ;LOAD SENSOR 1 STATUS
	0001: 42 ;AND /SENSOR 2 STATUS
	0002: 33 ;AND SENSOR 3 STATUS
	0003: 81 ;IF 1,/2,3 ARE ACTIVE, TURN ON LIGHT
	0004: FF ;RETURN
	'
	# Hexdump (| xxd -c1) of binary results:
	: '
	0000: 11 42 33 81 FF
	'
	# Process:
	# 1) remove comments
	# 2) replace mnemonic with hex nibble
	# 3) insert hex line/byte number
	# 4) use tee to view the hexdump, and ..
	# 5) use xxd to turn it into a binary
	# Set BYTES to width of the program memory in bits divided by 8
	BYTES=1
	LIDX=0
	sed -e '/^ /!d' \
	-e "s/ *NOPO */0/; s/ *LD */1/; s/ *LDC */2/; s/ *AND */3/" \
	-e "s/ *ANDC */4/; s/ *OR */5/; s/ *ORC */6/; s/ *XNOR */7/" \
	-e "s/ *STO */8/; s/ *STOC */9/;s/ *IEN */A/; s/ *OEN */B/" \
	-e "s/ *JMP */C/; s/ *RTN */D/; s/ *SK2 */E/; s/ *NOPF */F/" \
	$1 | while read n; do printf "%04X: $n\n" $LIDX; LIDX=$(($LIDX+$BYTES)); done \
	| tee /dev/tty | xxd -r

view raw a145.sh hosted with ❤ by GitHub

An array or hashtable probably would have been better for all those sed command opcodes, but this was quick and dirty. I will keep it updated and possibly add features.

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.

Games Day...

Day 6:

I mostly played MC-10 games from Jim Gerrie's TRS-80 MC-10 Files repository. So much stuff in there! Unfortunately Google Drive reports a lot of errors when trying to play the files online. It often forces me to download the cassette audio file which is annoying, but it pretty much works. I played a game "rocket" which is basically an Apollo lunar lander simulator. I spent so much time trying to land and win the game... I finally did it though!

I have to give it up for Jim Gerrie who keeps all of this archived, and ported or wrote many of the games. So much fun, even with 4K of RAM still!

On that note, I have been thinking of the best route to upgrade this little MC-10. There are a lot of good semi-commercial options out there, but I think I will go for something far more ridiculous and excessive. If you follow my blog, you probably have some idea of what I am thinking. I am working out some schematics to figure out the best way to do the upgrade from only the expansion port. Stay tuned!

MC-10 Cassette Server is Online!

Day 5:

I spent a fair bit of time today downloading and running TRS-80 MC-10 games and utiliites. Unfortunately, the process was rough:

1. download the file
2. extract it from zip archive
3. load the .c10 file into XRoar
4. save it to .wav file using XRoar
5. awkwardly play it in the Mac Music app
6. organize all the new files

To be fair, many of the zip files already have a .wav format file in there, but it is still not a convenient process. XRoar is esptecially time consuming as the cassette menu controls can be a bit awkward and the conversion is done using MC-10 commands in MC-10 time. There is apparently a Windows utility to do the conversion, but I don't have Windows and it is not open source. Fortunately, I am familiar with the useful c2t utility by datajerk for converting Apple II format files to .wav and .aiff formats. I knew that the MC-10 cassette audio format was vaguely simlar to the Apple II (FM encoding), so I made some changes to make a simple command line tool for converting .c10 files to .wav files. I was so shocked when it worked, I had to double check a few times that I was playing my generated file rather than a comparison file I was using. I just posted the project code on github.

Even with the .c10 format files converted to .wav, I was still struggling with my Mac always importing them into the Music app, or not being able to rewind and start again with the Finder preview. Inspired by the Online Apple II Game Server, I uploaded the .wav files onto Google Drive, and wrote a small web app to organize and display them. So, now I can just hook up my audio cable, go to the MC-10 Cassette Server webpage, and play them right from there. I can even use an iPhone or iPad to connect. I will be adding more files and information there as I test everything.

Comms Day!

Day 4:

I found an MC-10 serial terminal program "COMPAC" online and was able to load it onto the MC-10 using my new 'cassette' interface cable (see part 1 and part 2 of making the cable).

Of course, I could only send letters from the MC-10 to my Mac's terminal program, but not from the Mac to the MC-10. I knew immediately that it was due to the serial cable wiring and how the Tx and CD wires were swapped for printing. I tried to make a little adapter, but it did not work, so I had to re-solder the connector using the orinal pinout in the Service Manual.

Well, it works now! I can type messages back and forth between my computers finally! It's only 300 baud, but it feels like a good success. Oh, in the README for the console program was a link to a 90's awsome MC-10 website on triod. What flashback and a great resource!

Tomorrow I will see if I can access the macOS shell.

screen /dev/cu.usbserial 300,cs7,cstopb

Cassette SAVE and LOAD, pt 2

Pinout:
3.5mm TRRS plug
|   |
-----
  |   = (5) MIC + 10K OHM resistor to ground
  _
  |   = (2) Signal Ground
  _
  |   = (N/C) right EAR
  _
  v   = (4) left EAR or AUX

BASIC after the break...

Cassette SAVE and LOAD, pt 1

So basically, MC-10 can load from Mac, but can't save cassette/audio output to Mac yet. XRoar is converting file formats for me.

Half working audio cable still in development.

BASIC program after the break.