Re: MASSBUS disk emulator (Was: Unibus controller for MFM disks)

2016-10-19 Thread Noel Chiappa
> From: Rich Alderson > Yes, the d/r card is strictly level conversion, and the microcode in > the Xilinx does all the Massbus protocol. So if you don't mind continuing to indulge my curiousity (thanks for all the indulgence so far :-), is the D/R card a daughtercard that mounts on

Re: 2020 Power consumption [Was: Re: MASSBUS disk emulator (Was: Unibus controller for MFM disks)]

2016-10-19 Thread Mike Ross
On Wed, Oct 19, 2016 at 7:44 PM, Pontus Pihlgren wrote: > On Tue, Oct 18, 2016 at 06:26:06PM +, Rich Alderson wrote: >> >> There have been 2 generations of Massbus Disk Emulator (MDE) at LCM. The >> one of which people have seen pictures was the first generation, created

Re: 2020 Power consumption [Was: Re: MASSBUS disk emulator (Was: Unibus controller for MFM disks)]

2016-10-19 Thread Paul Anderson
That should be in the site prep documents, or the installing documentation. On Wed, Oct 19, 2016 at 1:44 AM, Pontus Pihlgren wrote: > On Tue, Oct 18, 2016 at 06:26:06PM +, Rich Alderson wrote: > > > > There have been 2 generations of Massbus Disk Emulator (MDE) at LCM.

2020 Power consumption [Was: Re: MASSBUS disk emulator (Was: Unibus controller for MFM disks)]

2016-10-19 Thread Pontus Pihlgren
On Tue, Oct 18, 2016 at 06:26:06PM +, Rich Alderson wrote: > > There have been 2 generations of Massbus Disk Emulator (MDE) at LCM. The > one of which people have seen pictures was the first generation, created > when there were only 2 people working on the collection which became the >

RE: MASSBUS disk emulator (Was: Unibus controller for MFM disks)

2016-10-18 Thread Rich Alderson
From: Noel Chiappa Sent: Tuesday, October 18, 2016 11:51 AM >> From: Rich Alderson >> Data was transferred via FTP over a 100baseT crossover cable connected >> to a Slackware server; the Rabbit was able to keep up with 4 drives at >> this speed > Were the bits actually stored on the Slackware

Re: MASSBUS disk emulator (Was: Unibus controller for MFM disks)

2016-10-18 Thread Ethan Dicks
On Tue, Oct 18, 2016 at 11:33 AM, Ethan Dicks wrote: > I would consider one for my VAX/11-750 since Unibus disk emulation > solutions aren't plentiful (but I think I'd have to get a DR750 > (L0014) first). Correction: RH750 (L0007). The DR750 is a CMI-bus "interprocessor

Re: MASSBUS disk emulator (Was: Unibus controller for MFM disks)

2016-10-18 Thread Ethan Dicks
On Tue, Oct 18, 2016 at 9:39 AM, Noel Chiappa wrote: > > From: Paul Birkel > > > Maybe there are three ribbon cables back there > > We _definitely_ need to put these things in 'production'. I would consider one for my VAX/11-750 since Unibus disk emulation

Re: MASSBUS disk emulator (Was: Unibus controller for MFM disks)

2016-10-18 Thread Noel Chiappa
> From: Paul Birkel > Maybe there are three ribbon cables back there Sure looks like it, and running to a standard MASSBUS connector, to boot. (Not that I have any use for the latter - absolutely no MASSBUS cables at all. But one could just run flat cables from this, to one's

RE: MASSBUS disk emulator (Was: Unibus controller for MFM disks)

2016-10-18 Thread Paul Birkel
-Original Message- From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Pontus Pihlgren Sent: Tuesday, October 18, 2016 1:58 AM To: General Discussion: On-Topic and Off-Topic Posts Cc: j...@mercury.lcs.mit.edu Subject: Re: MASSBUS disk emulator (Was: Unibus controller for MFM

Re: MASSBUS disk emulator (Was: Unibus controller for MFM disks)

2016-10-17 Thread Ian S. King
I've made some inquries, stay tuned On Mon, Oct 17, 2016 at 1:09 PM, Pontus Pihlgren wrote: > On Mon, Oct 17, 2016 at 12:16:10PM -0400, Noel Chiappa wrote: > > > From: Ian S. King > > > > > When I left in 2014, LCM's Massbus disk emulator was working quite >

Re: MASSBUS disk emulator (Was: Unibus controller for MFM disks)

2016-10-17 Thread Pontus Pihlgren
On Mon, Oct 17, 2016 at 12:16:10PM -0400, Noel Chiappa wrote: > > From: Ian S. King > > > When I left in 2014, LCM's Massbus disk emulator was working quite well > > indeed, and was running in 'production' ... ISTR the plan was always to > > open-source the hardware and firmware,