Loom Communications – Emulating the DMD 5620 Terminal
Printed Thursday, December 13 2018
Again within the early Eighties, earlier than GUIs had been commonplace, Rob Pike and Bart
Locanthi Jr. at AT&T Bell Labs created a bitmapped windowing system for
use with UNIX. Initially, they known as the system “jerq”, a play on the
title of the Three Rivers PERQ laptop. When the know-how began to get
confirmed round outdoors of the lab, nonetheless, they modified its title to
“Blit”, from the title of the “bit
blit” operation.
Right here’s a small demo of the system in motion, circa 1982.
The windowing system was a mix of {hardware} and software program. The
{hardware} was a terminal constructed round a Motorola 68000, with an 800 by 1024
pixel 1-bit bitmapped show in portrait mode, a keyboard, and a
mouse. The software program was hosted on a UNIX laptop and could be uploaded to
the terminal’s reminiscence on demand, the place it executed on the terminal’s CPU
itself.
Later nonetheless, AT&T and the Teletype Company teamed as much as commercialize
the system. They reimplemented the {hardware} and based mostly it on a Western
Electrical WE32100 CPU. They named it the DMD 5620 (DMD for “Dot-Mapped
Show”).
Software program emulators for the sooner 68000 Blit exist already, each in
C and
in JavaScript. However the DMD 5620, the
model that noticed some business success outdoors of bell labs, has by no means
been emulated.
As a result of I’m such a fan of emulation, and since I labored so lengthy and laborious
on the AT&T 3B2/400 Emulator, and since 3B2s usually ran
DMD 5620 terminals in business environments, I knew I needed to treatment the
state of affairs.
Not like the 3B2/400, the DMD 5620 is awfully properly documented. Not
solely that, however the supply code for the ROM is accessible, as is the supply
code for the driving force and software software program on the UNIX facet. Many
thanks go to Eric Smith for his DMD 5620 FAQ and Software
archive,
with out which this undertaking wouldn’t have been attainable. It made writing
the emulator a weeks-long undertaking as a substitute of a years-long undertaking.
I made a decision to not use a framework like
SIMH to construct the DMD 5620 emulator,
so I might begin recent. I additionally wished to take the chance to make use of my
favourite new language, Rust. I knew I wished the
emulator to be absolutely cross platform, so I cut up the work into two components: A
Rust again finish that may very well be compiled as a library on Home windows, Linux, and
macOS; and a entrance finish written in JavaScript that may very well be constructed as an
ElectronJS desktop software (or within the
future, doubtlessly deployed to a webpage backed by a WASM library. However
that’s an train for a future me…)
The Again Finish
Naturally, I labored on the Rust again finish first, beginning with the very
tedious work of porting my WE32100 CPU core from the 3B2/400 emulator to
the brand new DMD 5620 emulator. It gave me an opportunity to rethink some issues, and
additionally add unit exams the place I didn’t have them earlier than (SIMH doesn’t assist
any unit testing framework, which I thik is a disgrace). After the CPU core
was applied, I added the opposite peripherals one after the other, emulating them
as I went, till I might boot the ROM efficiently.
Fortunate for me, the DMD 5620 as a system is fairly easy. There’s a ROM, a
RAM, a DUART, some non-volatile reminiscence, a few standing registers, and
an non-compulsory parallel I/O interface that I’ve chosen to not
implement. Pretty easy-peasy. The largest ache is the 2681 DUART, which is
very advanced. I used to be in a position to crib many of the structure for this from
the 3B2/400 emulator, although, because the 3B2/400 makes use of the identical mannequin of
DUART for its console I/O.
When you’re fascinated about trying on the again finish, I’ve revealed it here
on my Github, and it’s accessible
here as a Rust crate.
The Entrance Finish
Lastly, it was time to stay a entrance finish on it so I might see whether or not it
was making an attempt to speak to me after it booted.
The primary entrance finish I constructed was simply an experiment, written in Rust, and
not meant to be cross platform. It makes use of the
Piston rust library to attract
to an OpenGL window, however in any other case has no fascinating options.
The second entrance finish, the one I’ve truly revealed on GitHub [ed: link
now defunct, since the JavaScript front end was scrapped], makes use of
JavaScript for the drawing, and Neon
Bindings as a Rust-to-JavaScript bridge. It’s
packaged as an ElectronJS app as a result of ElectronJS apps may be constructed and
deployed to all the foremost platforms, which was a necessary aim.
Really drawing the bit-mapped show is fairly simple. The DMD 5620
exposes a 100KB window of its RAM as video reminiscence, so actually all I needed to
do was iterate over this block of reminiscence, studying it little by little, and draw
a inexperienced pixel if the bit was set, or a black pixel if the bit was not
set. Nonetheless, it took me a couple of tries to get it proper, as a result of I’m a
doofus. Ultimately, although, I might see the DMD 5620 booting, echoing some
standing messages to the display, presenting a cursor, after which ready for
enter.
Enter dealing with within the JavaScript entrance finish is accomplihed with keydown
,
keyup
, mousemove
, mousedown
, and mouseup
occasions. These are fed
into the again finish as both keyboard UART obtain occasions, mouse button
UART occasions, or reminiscence updates (the DMD 5620 writes the present mouse X
and Y place to a pair of registers in reminiscence).
Lastly, there must be a option to talk with a bunch. My first
implementation is Telnet, which can be utilized to attach the terminal
emulator to a 3B2/400 emulator on the identical host, or on a distinct
host. It might be a little bit counter-intuitive, however the entrance finish is definitely
chargeable for dealing with the Telnet protocol. The again finish is completely
agnostic about the place characters come from, it doesn’t care. This implies I
can plug in several character sources, say direct serial interface.
With all the weather put collectively, it’s a reasonably usable system!
The principle ache level to date has been working with the JavaScript ecosystem,
which has hitherto been an enigma to me. I’ve discovered ElectronJS to be
considerably painful to work with as a result of, though it’s certainly cross
platform, there are various caveats. The first subject is in recompiling
native NodeJS modules throughout platforms, which took some trial and error to
get working accurately. The truth is, I nonetheless haven’t produced a Linux app
bundle but, as a result of the construct retains failing in methods I don’t fairly
perceive.
Basically, it looks like JavaScript and NodeJS modules are much more
brittle and error-prone than the code I’m used to working with. This may occasionally
simply be one thing of a blanket assertion based mostly on restricted expertise. I
hope so.
I’m pleased with how this undertaking progressed. The majority of the time spent on
it was porting the CPU core, which was tedious and error susceptible (thank
goodness for unit exams). The remainder of the time appears to have breezed by,
because of good documentation and a easy system.