UniBone: Linux-to-DEC-UNIBUS-bridge, year #1
>> Well, I was expecting to have to do all of the work myself. There’s still the problem of the disk Unibus itself to solve > -the disk UBA doesn’t terminate into a normal Unibus. > It goes into the disk RH11 directly, and the bus is terminated on the far end of the RH11. I’d either have to buy another Unibus backplane to plug the Unibone into, or find a way to plug the cables from the UBA directly into the Unibone. >This still leaves the issue of terminating the bus. > The ideal scenario would be if the first slot of a RH11 (where the bus jumper comes in) can accommodate the (quad card) > Unibone without issues, the rest of the RH11 boards can simply be pulled without breaking bus continuity, > and the normal terminator in the far slot can be used. I haven’t looked at any prints or anything yet. I gave UniBone a set of pinheaders for all UNIBUS signals in parallel to the gold fingers. So an adapter board can be designed, which plugs onto the pinheaders, contains some provision for the UBA connection and contains the terminator array. The UBA-UniBone adapter may consist of two parts coupled via flat cable, with flipchip plugs on one end if necessary. All this is only mildly annoying, did similar before, for example http://www.retrocmp.com/tools/uniprobe > Right, there were two unibus ports on a 2020: The first one went to the > RH11-C and was very odd in that "Hog Mode DMA" was enabled to allow the > device to just stream data as much as it wanted to the controller. This > would mean that other devices on the bus would time out and not have > their interrupts serviced, but since the RH11 was the only thing it > didn't matter (and I think this is why you could use RM03's instead of > RM02's: The whole track could be read and buffered to the 2020's UBA > controller in one shot. > That would have to be programmed into the BBB software to ignore the 16 word > DMA limits and go as fast as the drive can go). As the disk drives are also emulated, they are not putting any constraints on the DMA logic: give them the speed and DMA length you prefer. Joerg
Re: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1
> On Nov 20, 2019, at 10:37 AM, Chris Zach via cctalk > wrote: > > Gotta drag this stuff out and take a look. Oh and RD54's are *slow* compared > to ESDI disks and controllers. Ouchies! Can’t be worse than my original plan, which was to use a Viking SCSI controller and hack all the things to support it. Bit fiddling happened in the driver, in exec mode. I actually had a hacked standalone DSKDMP that knew how to format “packs” on it, but it was so dog slow I never bothered writing a timesharing driver for it, instead waiting until someone came up with a better solution.
Re: Got it: RD54 formatting write protect solved
I Use a spare MicroVAX-2000, the system roms ahve good diags and formatter for floppies and HD. Allison On 11/20/19 1:14 AM, Jacob Ritorto via cctalk wrote: > Nice going! > > Related story: > I had probs formatting a maxtor 11xx (not an actual xt-2190 but really close) > as an rd54 due to geometry differences and binary patched that formatter to > deal with it using the xxdp equivalent of od. Have the patched xxdp > formatter binary on an rl02 pack here if anyone needs it. > > Works a treat, close enough that dec software thinks it’s an rd54. > > Jake > > Sent from my iPhone > >> On Nov 19, 2019, at 20:13, Chris Zach via cctalk >> wrote: >> >> Figured it out at last. On a BA23, the RD54 needs to be jumpered at the >> disk as UNIT 3, and I had it as unit 4. Thus the jumper needed to be between >> 3 and C, I had it one stake over between 4 and C. >> >> Fixed that, did the format where you do not select Autoformat, and downline >> load UIT and you get the disk going tick, tick, tick as the sectors are >> formatted. Here is Terry Kennedy's instructions updated to a BA23 instead of >> a BA123: >> >> DR> STA >> >> CHANGE HW (L) ? Y >> >> # UNITS (D) ? 1 >> >> UNIT 0 >> Enter controller IP address (O) 172150 ? >> What unit do you want to format [0-255] (D) 0 ? 0 >> Would you like to revector a single LBN only [Y/N] (L) N ? >> Do you want to use the "AUTOFORMAT" Mode [Y/N] (L) Y ? N >> >> >> Would you like to use the RCT - Revector known bad blocks [Y/N] (L) N ? >> >> WARNING >> >> [text about don't proceed if you're just kidding deleted] >> >> Do you wish to continue [Y/N] (L) Y ? >> >> >> MSCP Controller Model: 19 >>Microcode Version: 4 >> >> Do you want to use manufacturing bad block information [Y/N] (A) N ? >> >> Downline load UIT [Y/N] (A) Y ? >> >> >> UIT Drive Name >> --- >> 0 RD51 >> 1 RD52 part # 30-21721-02 (1 light on front panel) >> 2 RD52 part # 30-23227-02 (2 lights on front panel) >> 3 RD53 >> 4 RD31 >> 5 RD54 >> 6 RD32 >> >> Enter Unit Identifier Table (UIT) [0-7] (D) ? 5 >> >> Continue if bad block information is inaccessible [Y/N] (A) N ? Y >> >> Please type in the serial number [8-10 digits] (A) ? 013284212 (use >> whatever you want) >> >> >> Formatting of Drive 1 Begin. >> >> [a long sequences of messages is displayed here, 1 per minute, showing the >> progress of formatting and what step is in progress on which block number.] >> >> Format Completed. >> >> And Bob's your uncle!
Re: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1
Well, I was expecting to have to do all of the work myself. There’s still the problem of the disk Unibus itself to solve - the disk UBA doesn’t terminate into a normal Unibus. It goes into the disk RH11 directly, and the bus is terminated on the far end of the RH11. I’d either have to buy another Unibus backplane to plug the Unibone into, or find a way to plug the cables from the UBA directly into the Unibone. This still leaves the issue of terminating the bus. The ideal scenario would be if the first slot of a RH11 (where the bus jumper comes in) can accommodate the (quad card) Unibone without issues, the rest of the RH11 boards can simply be pulled without breaking bus continuity, and the normal terminator in the far slot can be used. I haven’t looked at any prints or anything yet. Right, there were two unibus ports on a 2020: The first one went to the RH11-C and was very odd in that "Hog Mode DMA" was enabled to allow the device to just stream data as much as it wanted to the controller. This would mean that other devices on the bus would time out and not have their interrupts serviced, but since the RH11 was the only thing it didn't matter (and I think this is why you could use RM03's instead of RM02's: The whole track could be read and buffered to the 2020's UBA controller in one shot. That would have to be programmed into the BBB software to ignore the 16 word DMA limits and go as fast as the drive can go). So you would need two BA11's, one for the RH11C and one for the DZ11's and other unibus "stuff". *however* I seem to recall that the RH11C included a full length unibus slot after the boards, so maybe you could pull the RH11 boards and plug the BBB board into the end of the RH11C Gotta drag this stuff out and take a look. Oh and RD54's are *slow* compared to ESDI disks and controllers. Ouchies! C
Re: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1
> On Nov 19, 2019, at 9:35 PM, Josh Dersch wrote: > > Joerg is the one building and selling the board, I'm just a satisfied > customer who's also been hacking new device support into it. I'll keep y'all > posted as to when I make progress on this. > > Also if anyone has a KS they could, uh, "lend" me it sure would speed up the > development process and I'm sure you'd eventually get it back someday. > > (Kidding.) Well, I was expecting to have to do all of the work myself. There’s still the problem of the disk Unibus itself to solve - the disk UBA doesn’t terminate into a normal Unibus. It goes into the disk RH11 directly, and the bus is terminated on the far end of the RH11. I’d either have to buy another Unibus backplane to plug the Unibone into, or find a way to plug the cables from the UBA directly into the Unibone. This still leaves the issue of terminating the bus. The ideal scenario would be if the first slot of a RH11 (where the bus jumper comes in) can accommodate the (quad card) Unibone without issues, the rest of the RH11 boards can simply be pulled without breaking bus continuity, and the normal terminator in the far slot can be used. I haven’t looked at any prints or anything yet. The “second” Unibus is otherwise normal.
