I recently impulse bought an ElectroCom Communication Systems MDT-870 radio car terminal for $5 at a surplus sale. Never knew much about these sort of computers but learned a lot since, and yet remain largely in the dark about this particular model given the complete absence of any documentation or schematics online.
This model in particular was common in squad cars in the 1980s-1990s. Some metadata extracted from a ROM that I dumped when troubleshooting indicated “COPYRIGHT 1986-1996 ELECTROCOM AUTOMATION INC.” and the particular ROM in this unit had a generation date of March 25, 1996. Based on this, the department may well have used it for the better part of a decade before phasing it out in favor of more contemporary solutions.
This exact model appears in an early scene of Terminator 2: Judgment Day, where T-1000 uses it within a police car to query the details of John Connor. Having now used the real device the movie depicts, other than the simulated sound effects in the film the actual on-screen display appears to have been produced and filmed on the actual MDT-870. Of course the one on the set was not wired to actual police databases, but the text on it was typed within one of its free-type interfaces.
Initial Power-up and Short Glimmer of Life
When these were actively used, they had a variety of hookups to police radios, databases and similar. The one I received was barebones aside from some of the wiring that itself appeared cut and severed at various points. It runs on 2A 12V DC power, typically wired to the vehicle’s battery/alternator. After a little bit of review I traced the original positive/negative wires and reworked them into a simple AC-DC power converter adapter and spliced a new cord to go along with it, from a typical computer adapter.
I was able to power up the unit and heard some remarkably 80s-sounding beeps as it booted up. It initially read “SIGNOFF ACCEPTED” and then took me to some integrated applications. This included a MEMO WRITER, QUERY DRIVER STATUS, and some others that I can’t recall.
Alas, this was a short-lived effort as after typing some keystrokes and photographing the images above, something fizzled out and I lost all display and signs of activity.
Hardware Analysis
Unfortunately, not a single trace of documentation, schematics or ROM dumps for this system exist online. I found very few references to it at all. There were sporadic mentions of it appearing in movies, a fan-made STL model of the device citing Robocop 1, and other users looking for any documentation in hopes of setting one up in their own personal vehicles for nostalgia or show. I found one post from more than 15 years ago where someone did have the full gauntlet of schematics, programming guides, service manuals and even hardware-based interface adapters for PC communication. Alas I wasn’t sure how to even approach contacting that user at this point in time.
Disassembly was not too difficult. In fact there exists plastic doors on the back of the unit for direct access and swapping of the CDVR and ROAM ROMs. The entire unit promotes itself as “Proudly Made in the U.S.A.” Several of the ICs including all ROMs, CPU (OKI M80C85A-2 x2) and Graphics Controller (Intel P8725) were pre-socketed using machine pin sockets. I know many advocate for such sockets, but when wanting to quickly remove and replace ICs when troubleshooting and testing, I still find the flat leaf-type DIP sockets much easier to work with and less prone to bent and broken pins. That said, I did eventually swap the three machine pin sockets for the ROMs with leaf style to make my own life easier as I was burning and testing all of those ROMs continuously.
To actually get at the core ICs, you have to unscrew the back (and any brackets that may be attached) and carefully separate the two halves. The back half houses the small amber-lit Clinton Electronics 798P1NGLP picture tube and a simple speaker. Underneath this is the video sub-board and on the other side the main logic board. A ribbon cable transmits data from the logic board to the CRT board and ultimately into the display. The front half houses the membrane-based keyboard, LEDs, variable controls for adjusting Sound Volume, Light (Front LEDs) and Display Brightness. A side control also allows you to adjust the keyboard-based light brightness.
The system has two 80C85A CPUs (8085-based, the minor successor to 8080 and comparable to Z80 except with syntax I find to be much more cumbersome to decipher). The CRT is driven by the Intel 8275 (P8275) video controller. It has two banks of Sharp LH5168 CMOS SRAM and oneM81C55-5 CMOS SRAM a variety of other controllers and ICs. It also has a TMP82C55AP CMOS Programmable Peripheral Interface. I noticed pin one of the uppermost CPU was bent underneath itself when inspecting the chips, but that didn’t seem to have any impact.
ROM Summary and Dumps
There are three ROMs installed in the logic board, with only one of them providing a checksum value to compare clean ROM dumps. They are all programmed onto common 27CXX EPROM chips. Through trial and error, I made the following educated conclusions:
- 502.87003.51 MDT870 CKSMC7B3 MDX-ROAM V2.2 (27C256) – This is the core ROM / OS. It is designed to interface with special frequencies/radios and other input/output devices for querying data, recording memos and otherwise communicating in a pre-mobile, pre-WWW era.
- 501.64519.51 641.07910.00 V1.1 U4 CHRGEN (27C64)– This is the character generator. Mine wound up corrupt before I was even able to get a proper dump, so I am unaware of the precise layout of the original. However, after experimenting I was able to reconstruct a usable CGROM derived from the HD44780 controller after reversing and reordering them. If this chip is corrupt or removed from the set, the screen displays solid blocks as typical when no character generator exists.
- 501.64520.51 641.07900.00 U16 V1.1 CDVR (27C64) – Originally I was unclear what CDVR stood for in this context. But it became clear as soon as I removed it from circuit that it is the CRT Driver. With it removed, the CRT cannot render anything but a high-pitch raster or several as if suffering vertical collapse.
I made ROM dumps of all three of these on my vintage EP-1 programmer. I verified the checksum of the ROAM firmware matched, but had no basis to compare the other two in the event they were corrupt. I later concluded the CHRGEN ROM had indeed corrupted for reasons unknown, whereby once I had fixed the display issues itself that chip would show mostly solid blocks and EPROMS I burned from the dump did the same. Trying the original in my more modern TL866-II programmer detected faulty pin(s), and comparing a dump made from it to any on either programmer always yielded errors. However, I’m confident the ROAM and CDVR dumps are functional and precise.
Below is a ZIP file containing the complete collection of ROM dumps I made in various formats (BIN, Intel Hex, Mitsubishi Hex and another format or two). It also includes my usable 2022-created character generator ROM, one variant with underlines and one without.
Character Generator Woes
After a lot of testing, trial and error I eventually wound up with a semi-bootable MDT-870 again. I believe there was one bad CPU, a few dry solder joints, at least one shorted/dislodged socket, and something astray in an SRAM chip (and am still not convinced the two SHARP chips are not damaged, this will take more testing).
The beep codes were back and the display was, well, showing something or other but basically all corruption.
I recognized even when typing that the glitches correlated to the keys typed, which is usually a sign of bad video RAM or a failed character generator. More testing of the original EPROM proved it to be a problem. I tried a fresh 2764 EPROM with the prior dump and experienced the same symptoms. Peaking into the ROM dump itself and I found almost entirely FFs or 00s, which definitely seemed peculiar compared to other ones I’m familiar with.
Typically character generators define the character sets using 8×8 (or 5×8 or 5×7 or some variant) where each single HEX value depicts one byte-row of character data. So FF would mean “fill in the entire row solid” and 00 would be “keep the entire row blank” but usually you’d see intermediary hex values, such as 3C to indicate “fill only the inner four bits) and this is how basic characters can be defined. Row-by-row. With this in mind, I created a dummy character generator filled with FFs but also randomly changed some values, as an experiment. This yielded the following:
That confirmed to me that the display problem was indeed just a wonky character generator. And, after some additional experimenting with patterns and characters I concluded the CGROM for this set is a pure data dump of constructed characters, it contained no additional logic or coding. This was fortunate as if it intermixed coding and byte data as some do it’d be vastly more difficult to guess the structure going forward.
I then went on a roundabout manner of creating some new character generator that’d at least satisfy the need to see what text is showing up on the screen. As a foundation I used the binary data constructs of the HD44780 and pasted them into a new binary file, repeating the entire set multiple times until padded at 01FF to match the original ROM size. When I tested this new ROM in the machine, I could tell we were headed down the right path.
Seen above was the initial run of a new character dump. I was in some input screen that allowed me to free type. The characters in the middle were me starting with ABC…890. You can see firstly how they are all inverted. This is because the CRT itself is mounted upside down then reflected off a tilted mirror to project through the front of the terminal. The other problem is that one letter gets skipped with each one I press. So A=B, B=D, C=F and so on. This was an immediate clue that the layout of the original CGROM repeated each character twice, AABBCC…889900. Eventually I realized that the most-significant bit (leftmost in a row of 8) determined whether the character would have an underline or not. If padded with “FF” there’d be an underline, otherwise there wouldn’t be. This likely explains the need for replicated lines/characters. To my knowledge, lowercase characters were never displayable or included.
To resolve the reflected issue, I passed the binary format into a reverse line script. I then pass that into a binary-to-hex script. This could then be sit out into another binary file to appear the correct orientation when viewed through the terminal’s mirrored screen. It was then a matter of comparing keystrokes with what the screen depicted, and swapping around the ordering to ultimately end up with a version depicting all characters successfully. You can see below how the mirror affects the display, both on the raw CRT and when viewed from the front with the redone character set.
It Lives Again, But How To Initialize?
Through the various iterations of it working, not-working then working again, any and all previously preserved data seems to have been wiped clean. Some of that likely happened while I was making contact with various pin-outs of the numerous memory-related ICs.
Before I had a proper character display again, I actually wound up with a different start screen. It would throw the error “NO HOME CHANNEL IN LIST” and then enter an empty typing screen. Periodically it would then interrupt with the error: “CHECK CONNECTIONS TO RADIO” Still, being able to type was interesting itself, at least it was something!
But after the final cleaning of the keyboard and another loss of power, then some more IC tinkering, the new screen is different once more. I’m not stuck at the “INITIALIZE MDT” screen and no characters have any affect.
It is evident based on the text data extracted from the ROM dump (see below) that the ROM has some internal way to define channels and so on. Somewhere in the code lies the string: PRESS “C” TO ENTER RAD. CHANNELS and related ones as well including ENTER RADIO CHANNELS and PRESS “X” TO EXIT. What I’m not sure of is how to achieve this, or if that by itself also requires interfacing with an external system.
If I make any further progress on this, I’ll update this post. One interesting discovery worth checking into more thoroughly is the Open Hardware Driver for CRTs. This seems like a promising approach to easily hacking this or similar sets to display typical video output on its crisp amber display. “The driver circuit takes a 0-3.3V analog signal for deflecting the beam along the X and Y axis. The amplifier has enough bandwidth to handle NTSC video, so displaying video along with vector letters and shapes is also a possibility with this circuit.”
Extracted Strings from ROM Dump Metadata
As part of the main ROM dump (502.87003.51 MDT870 CKSMC7B3 MDX-ROAM V2.2) I parsed through identified strings. They are included below, as well as their relative memory location at least as laid out in a decompiled Z80-derived version of the 8085 source. The fact that I was unable to find any references to the applications I had initially observed, may indicate that those along with the radio codes and data were still cached in some form of non-volatile memory but ultimately wiped out.
- 0005: Generated 3/25/96
- 003F: COPYRIGHT 1986-1996 ELECTROCOM AUTOMATION INC.
- 0160: INITIALIZE MDT
- 04D5: WARM
- 1237: DISPLAYED FORM UPDATED BY HOST
- 1261: DISPLAYED FORM DELETED BY HOST
- 1521: H FILE BYTES AVAILABLE.
- 156F: MD:4
- 1699: <FORM>
- 248D: QWERTYUIOP
- 24BD: @ZXCVBNM,.
- 24CD: 1234567890
- 24DD: ASDFGHJKL:
- 2EF7: 99RESET
- 2F0A: PRESS “C” TO ENTER RAD. CHANNELS
- 2F2F: SET ?
- 2F99: TX LEVEL ADJUST (R49) TEST 2
- 31C0: ENTER RADIO CHANNELS
- 31DC: HOME CHANNEL:
- 31F5: BACKUP CHANNEL:
- 320D: SECONDARY CHANNEL:
- 3226: AUTOMATIC XMIT TIME:
- 3249: (FOR CHANNELS 1-9)
- 3267: (FOR CHANNELS 10-16)
- 327E: XMIT TIME IS MINUTES (03-25)
- 32A4: PRESS “X” TO EXIT
- 333C: MDT-870
- 334E: FIRMWARE SERIES 20 V1.2
- 336E: REV. DATE 3/25/96
- 3388: AUTO CHANNEL SELECT/CHANGE
- 33AA: PROM CRCC CHK.
- 5405: <ERROR>
- 5415: <PASS>
- 5420: <TEST>
- 64F8: LED TABLE
- 6D57: DISPATCH DELETED BY THE HOST
- 6E84: NEW DISPATCHES:
- 6F0E: UPDATED DISPATCHES:
- 6FD1: ACTIVE DISPATCH:
- 70C3: STANDBY DISPATCHES:
- 71F0: EXITING DISPATCH MODE
- 720A: ACCESSING CLEARANCE FORM
- 72A4: EXITING DISPATCH MODE
- 7A27: NO RADIO COVERAGE AREA
- 7A40: CHECK RADIO
- 7A50: POOR RADIO COVERAGE AREA
- 7A6D: NO HOME CHANNEL IN LIST
- 7A87: “NEED CHANNEL LIST UPDATE”
- 7AA6: CAN NOT CHANGE RADIO CHANNEL
- 7AC5: CHECK CONNECTIONS TO RADIO
- 7AE4: NO RADIO CHANNELS LISTED
- 7AFF: NEED CHANNEL LIST DATA