Retrochallenge R̶C̶2̶0̶1̶8̶/̶0̶9̶ RC2019/10

Update – 1 OCT 2019: Retrochallenge RC2019/10 is now underway!!!

This update will summarize what I have done so far. I have already decided on the system I will use to recreate the MOBIDIC. Keep in mind that the MOBIDIC was all transistorized, and did not have any form of integrated circuit. Recreating a MOBIDIC in its true form will be very time consuming and costly. Emulation (or simulation) is really the only sensible way to recreate it.

I decided to use the ESP32 platform for emulation. I like that it not only has a very large non-volatile RAM capacity, but as the complexity of emulation begins to occur, it has a large amount of program space for the compiled application. The ESP32 runs on an Arduino platform. It is this platform which will be used to create the source code for emulating the MOBIDIC. The built-in WiFI and Bluetooth capabilities could be leveraged for remote control in the emulation of original MOBIDIC peripherals.

The MOBIDIC in its base form used switches and lights to allow for input and to display bus and memory status, not unlike the MITS Altair. Since it’s cost prohibitive at the moment to buy, mount, and wire up the large number of lights and switches needed to create a minimal panel, I have opted to emulate the light output using ANSI control codes to a serial terminal which supports ANSI block graphics.

The lights I need to emulate, at a minimum, are the lights that represent the SYSTEM BUS, the ACCUMULATOR register, contents of an OPCODE instruction word, the PROGRAM COUNTER, and the system’s TIMING FUNCTION. Here is a sketch some of the indicators in their natural layout.

Top Panel

With the ESP32 being arduino based, I can use any one of the Arduino serial libraries that are capable of generating ANSI codes. As of now, the emulator just generates random RAM content, then rolls through RAM to display each byte on the system bus, continually outputting the status lights into my Windows 10 based terminal program. Right now, this is what the emulated output looks likes.

Terminal Control Panel

The monitored registers are named in green, bit position is in white, bit segments in cyan, and actual bits are in yellow, represented by a single dot as off (or zero), and a square as on (or one).

Notice anything unusual about the registers…? How about that funky architecture, huh? What is that… 37-bits?

It certainly is! Well, technically, it’s 38-bit. the extra bit was utilized as a RAM parity bit by the MOBIDIC to allow the system to halt on a parity error. Parity bits are not needed by today’s standards because the concept of RAM in emulated program structures is a moot point, so therefore, I have opted not to fully emulate the parity bit.

The MOBIDIC was designed before even the architecture for early integrated microprocessor was designed that started the current industry on the 4, 8, 16, 32, etc. bit wide control architecture was readily accepted. Engineers of the MOBIDIC were sort of working from a clean slate in the concept of a Von Neumann computing system. Unlike today’s CPU architecture which relies on opcodes being retrieved from RAM in one byte, then the operands retrieved from the next byte, MOBIDIC engineers decided to make the RAM bit size big enough to contain a bit representation of an opcode, along with any address and operands needed by the opcode, in a single byte of memory.

For example, an opcode byte in RAM contains the following segmented data:

Bits (from right to left) Purpose
12 to 1 Alpha portion of the opcode, which contains the RAM address the opcode is to reference in its operation
15 to 13 If set, references one of seven specially designated registers, such as the accumulator
27 to 16 Beta portion of the opcode. Could represent a number that gets added to a designated index registers referenced in the next bits, or be used to indicate another RAM address, depending on the opcode
30 to 28 Gamma portion of the opcode, which indicates which index register, if any, that is to be used during opcode processing. In effect, the contents of the indicated index register is added to the address value in the Alpha portion to generate a new RAM address for the opcode to reference.
36 to 31 Bit representation of one of 64 opcodes.
37 Spare bit. Used by some operation, either explicitly by the program, or by specific opcodes.

Right now, my emulated MOBIDIC is dumb. While it can manage the cycling through RAM, it cannot compute. My next step in the Retrochallenge is to integrate opcode processing by the emulator, so it can do some form of work.

Update – 12 SEP 2019: I’m back at it, again, to continue with another Retrochallenge. But, instead of picking something new to not eventually finish, I’ll rehash an old one which means a great deal to me. The only thing is, I will use the incentive of Retrochallenge to focus more of my limited free time to do so. So, instead of creating an entirely new post for this, I’ll just rehash last year’s post as a starting point.

Aaaand…. another Retrochallenge! I still try to participate in these whenever I get wind of them, even though I rarely ever finish one. I do it for the fun and camaraderie. For those who have started to put bets on me even starting on one or completing one of these fully, here’s a hint… I WON’T (technically) FINISH THIS ONE!

What the heck does that mean?!?

It means that I have a Retrochallenge idea I plan to pursue, but it’ll take a lot longer than one month to actually finish the project I plan to work on during the challenge. Some of you might have known, or have seen, that I had an introductory demonstration of an emulator for a VERY vintage (or ancient) computer called the MOBIDIC… a.k.a. MOBIle DIgital Computer at the Vintage Computer Festival East XIII.

MOBIDIC Cutaway

MOBIDIC Cutaway

The MOBIDIC was a portable (by 1960’s standards) Von Neumann style computer system designed by Sylvania for the U.S. Army. The beast of a machine was all transistorized and mounted in a tractor trailer, ready to be hauled on-site wherever computing and data processing resources were needed. My exhibit demonstrated and introduced the MOBIDIC to the public as a vintage computer worth learning about. An attempt is being made to recreate a full sized MOBIDIC computer using emulation as its core. THAT is my Retrochallenge for this session. I have already emulated an idling CPU for the project before the VCF East demonstration. I have also somewhat created a replica output, which was also displayed at VCF East. The MOBIDIC’s standard output is rows of blinkenlights, but it can also interface with punch or magnetic tape, and teletype output. In the available time allotted for the Retrochallenge, I plan on making the CPU portion do more than idle (running only housekeeping tasks) to a CPU that can interpret the MOBIDIC op-code set and actually process a program. Will this be an easy task or not? I don’t know, nor do I care. I want to do it, and the Retrochallenge is incentive enough to keep me motivated to continue the work I have started earlier this year.

I’d wager that the MOBIDIC is the one of the oldest computing platforms ever addressed for any Retrochallenge. It was designed and built between 1959 and 1962. And since it was comprised of so many transistors, it’s more cost effective to emulate one rather than replicate one.

Leave a Reply

Your email address will not be published. Required fields are marked *

The way ELECTRONICS used to be!

css.php