Jim:
Oh absolutely, and no shade meant on the problem. The Vax 8600/780/750,
the pdp11/70, and the DecSystem 2050/2060/2065all have dedicated Massbus
channels that don't deal with Unibus. So a device that plugs into the
end of a MBA cable would be neat without a doubt.
My 2020 is one little chunk of the puzzle, and I am planning to get a
pair of Unibones so I can emulate disks (somewhat important) and a TU77
tape drive (really important). Tape is the big issue, as only the TU45
and TU77 (maybe the TU16, I forget) are supported on a 2020 and both
require the extremely rare TM03 with the 18 bit fiddler (AI has one on
the TU77 there, but I don't think I want to ship my 20 out to Washington
to use it again :-)
An emulator that could do an RM80/RP06/RP07 would be quite handy. If you
need someone to test it, I'd be happy to assist.
CZ
On 4/23/26 11:37, Jim Bender via cctalk wrote:
Yes, there are simpler ways to approach the disk/tape storage problem,
and for
the most part it is already solved on 16 bit machines-- i.e., the
unibus SCSI
card plus a ZuluSCSI if you want to get away from spinning media
entirely or
perhaps a unibone.
For 18 bit disks the situation is a bit more complicated, which is
likely one
of the reasons the original LCM Massbus emulator came into existence.
The goal of this project isn't just to "solve" the disk/tape problem,
it is
also to be able to utilize a major hardware component of the systems
that most
people have avoided in recent years because of the unwieldy,
power-hungry and
relatively low capacity drives normally connected to it.
For some systems, Massbus is a better way to attach storage than on the
unibus, and on other systems the only really practical way.
On 4/23/2026 10:08 AM, Chris Zach via cctalk wrote:
> Indeed. I still have a RM80 MASSBUS drive for MC (Decsystem/20) here,
> and the thought of firing it up fills me with dread.
>
> Running a "modern" SMD drive that plugs into the SMD-ish side of the
> MASSBUS controller on an RM02/03/05/80 would be the simplest (it's
> SMD with some signals inverted because DEC is stupid). Running
> something that attaches to the RH11-C would be ok, but to be honest
> the Unibone with 18 bit circuitry would be the win. That way it's
> just a slot on the computer and your disk and tape problems are solved.
>
> Chris
>
> On 4/23/26 06:40, Hans-Ulrich Hölscher via cctalk wrote:
>> What are you emulating - the UNIBUS MASSBUS interface or the MASSBUS
>> devices? If you intend to emulate the interface, have you had a look
>> at the
>> UNIBONE emulator? Using that one reduces the MASSBUS interface
>> emulation to
>> a software problem only. And the community of UNIBONE users would be
>> very
>> happy too if that emulation was added...
>>
>> Jim Bender via cctalk <cctalk(a)classiccmp.org> schrieb am Do., 23. Apr.
>> 2026, 10:46:
>>
>>> Does anybody here still use Massbus?
>>>
>>> Or have a Massbus system you’d like to run, but the idea of dealing
>>> with
>>> washing-machine disk drives is a bit less appealing these days?
>>>
>>> In what may classified as a momentary lapse of reason, I have taken
>>> up the
>>> old
>>> Living Computer Museum Massbus emulator project and am in the
>>> process of
>>> resurrecting / modernizing it.
>>>
>>> Current progress photo here:
>>>
>>>
http://www.dmv.net/mbe/mbe1.jpg
>>>
>>> Why, you ask? "Has he gone insane?" are you thinking?
>>>
>>> I have three PDP-11/70s that I would like to get running again.
>>> Sure, I
>>> could
>>> cheat and hang a UNIBUS SCSI controller with a ZuluSCSI disk
>>> simulator, but
>>> where is the fun in that? Also, the 11/70 was designed and optimized
>>> around
>>> Massbus for primary storage, so it seems only fitting to use it
>>> that way.
>>>
>>> The original LCM emulator used a PC with a Mesa 5I22 FPGA card as the
>>> Massbus
>>> interface. The FPGA implemented the drive-side bus logic, while the PC
>>> software emulated the backing disk or tape image. A driver/receiver
>>> (“D/R”)
>>> board sat in the middle to translate the Massbus differential
>>> signals into
>>> logic levels suitable for the FPGA. It worked...
>>>
>>> Since Mesa 5I22 cards are now pretty much unobtainium, I went
>>> looking for a
>>> cleaner and more modern approach. The result is a redesigned D/R
>>> board
>>> that
>>> accepts a Terasic DE10-Nano directly. The DE10-Nano is a small
>>> Linux SBC
>>> with
>>> a Cyclone V FPGA onboard, so it can host the emulator software
>>> itself while
>>> the FPGA handles the Massbus interface duties that were previously
>>> done by
>>> the
>>> Xilinx FPGA on the Mesa card. Same general architecture, but much
>>> tidier.
>>>
>>> There is still work to do, but it is coming along nicely. The board
>>> in the
>>> photo is not yet fully populated, since I am doing incremental testing
>>> before
>>> committing the rest of the parts.
>>>
>>> As I have gone down this rabbit hole, naturally a few questions in
>>> the “why
>>> did they do THAT??” category have come up...
>>> paging @Rich Alderson ...
>>>
>>> If anyone here is still actively using Massbus, has experience with
>>> the
>>> original LCM project, or just has relevant war stories, comments,
>>> warnings, or
>>> encouragement, I would be glad to hear them.
>>>
>>> Cheers!
>>> Jim
>>>
>>>