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 > >

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 >>> >>>

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 &lt;cctalk(a)classiccmp.org <mailto:cctalk@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 <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