UNIBONE on a KS10/2020?

[Robert Armstrong]

  I apologize if this has been asked before, but has anyone used a UNIBONE on a real KS10/2020?  Does it work?  I think the only emulations that would be useful on a 2020 are the RH11 for disk and tape, and maybe some DZ11 terminals.  There are a whole slew of potential issues, such as using the two parity bits as extra data bits, plus just a different UBA and a completely different OS and drivers.

 

Thanks,

Bob

 

[Suzuran Majere]

I have. It was non-trivial. The KS10 UBA places the following hard limits on Unibus transactions that I was unable to reconcile with the requirements of the Unibone software architecture:

1: Devices requesting a grant must acknowledge the grant within 10 microseconds of it being granted by the UBA.

2: Devices addressed by the UBA must raise SSYNC within 1.2 microseconds of the UBA being addressed by the KS.

The deal-breaker was generally item 2; The UBA does not hold the KS bus while a UBA transaction is in progress. When a UBA transaction is initiated, the UBA is addressed by the KS bus master and the UBA will (attempt to) initiate the Unibus transaction requested. If the Unibus transaction completes, the UBA becomes the KS bus master and issues a single transaction to put the UBA transaction's result on the KS bus. No Unibus completion in time means no second transaction on the KS bus, and the UBA sets its timeout bit. If you do return a result in time, but don't clear the bus within 1.2 microseconds of the *next* request, you lose. The Unibone software is designed around the assumption that it can hold SSYNC down indefinitely to stall the processor, but the KS doesn't play ball.

I have only been able to get ITS to run by making drastic changes 100% incompatible with the Unibone software design mantra and by patching DSKDMP (the disk bootstrap) to ensure the RH11 GO bit clears when doing back-to-back commands early in initialization. I have had no success running any of DEC's operating systems (but didn't really try, as my entire goal was running ITS), and I am only able to emulate the two RH11s (hardcoded for RP06es on one and a single TU77 on the other) and a Chaosnet interface, due to limitations of the extremely unapproved changes I felt I had to make. (Even with my changes and with a lot of cheating the Unibone is only just barely capable of achieving RP06 transfer speeds)

You are welcome to try to replicate my results in an approved manner; I strongly recommend a good understanding of the Unibus specification (better than mine), a logic analyzer capable of tracing the entire bus, and familiarity with how to operate said logic analyzer. I don't feel comfortable distributing my code without Jörg's explicit approval though, as I violated the one rule he had in order to abuse things into working for my specific use case, and I don't want to disincentivize someone more skilled than I from replicating my results in an approved manner.

[Joerg Hoppe]

Hi Suzuran,

just a short notice: your semi-port to PDP-10 and all the research is
great news.

Its true, the core idea behind "Emulating UNIBUS devices by Linux" is
the ability to hold UNIBUS transaction for > 1ms.
Too bad the KS10 UBA is not 100%  UNIBUS here. Maybe older '10s are more
tolerant.
VAX 11/780 hast the similar trouble here, but 11/750 is running.

One escape route: there's the much faster "BeagleBone AI".
Though its filled up with stuff we don't need, we could make an Unibone
port and experiment on.
But Linux interupts in the 1us time frame remain impossible.
https://beagleboard.org/ai

*** In any case you have approval to publish & distribute your code ***

But perhaps you can help me:  What is the "one rule" I set on Unibone
modifications?

kind regards,

Joerg

[Robert Armstrong]

> Suzuran Majere <> wrote:
>I have. It was non-trivial.

Thanks - I very much appreciate the detailed answer.

I don't actually have a KS this second, but a situation has come up where I could get one. I'm don't want to hoard hardware though, not to mention that I'm already short on space as it is, so I'm only going to take it if there's a reasonable chance of making it run. Configuration options for the 2020 are limited and practically speaking, you need an RP06. A real working RP06 is never going to happen, and something like the UNIBONE is the only realistic option I can see for making the KS10 live again.

My goal would be to run either TOPS20 or (preferably) TOPS-10. I've worked on both, and I'd be quite comfortable hacking up the disk service on TOPS10. I have a garage full of UNIBUS VAXes, BI bus VAXes, UNIBUS -11s, QBUS -11s and VAXes and even a PDP-8 and I'm pretty happy with fixing old hardware, but it sounds like the problems with this plan run a lot deeper than just that.

Actually this makes me wonder if the UNIBONE works with any of the VAX UBAs? Or are there similar incompatibilities there?? I was also thinking about putting one in my 11/730 as it's R80 drive has suffered an HDA failure. Although the 730 had its own integrated disk controller, VMS is happy to work with a UDA50 and any SDI disk.

Thanks again,
Bob

[Robert Armstrong]

>Joerg Hoppe <> wrote:
>Too bad the KS10 UBA is not 100%� UNIBUS here.
>Maybe older '10s are more tolerant.

Umm, "older -10s" would be older than the UNIBUS!

Seriously though, the KS10/2020 was the only 36 bit machine that ever had a UNIBUS, and that was only because it was intended to be a very low end, low cost, system.

>VAX 11/780 hast the similar trouble here, but 11/750 is running.

Do you know about the 725/730?

Bob

[Suzuran Majere]

The one rule was (keeping your formatting): "This is the UniBone mantra: The whole device emulation logic shall be done in Linux user processes."

Since the 2020 was only ever going to need the RH11s of a single device type on each bus, I moved the RH11 emulation and the massbus-side drive registers into the PRU, leaving just the actual storage parts of the disk and tape drives in Linux. I also dumped all of the C++ code and kept only the bits I needed for communicating with the PRU. The rest I wrote in straight C. I was only ever going to emulate the RH11 and the stuff attached to it, so the vast majority of the Unibone user-space code was just overhead in my case. The Chaosnet interface was only a 5 registers and an interrupt latch, so it was done at the very end of things, using the remaining code space in the second Unibone. I wound up with just a handful of bytes of free PRU code space on both sides, and it's not pretty, but it runs.

My priorities were to keep speed up and latency down over all other concerns. I didn't use SimH compatible disk images at all, the disk images are stored in PRU register layout so words can be dumped directly to or from the PRU registers with no shuffling. Sector headers are stored as formatted instead of generated on the fly so I didn't have to spend time generating them when a "read headers and data" command was given (and because ITS uses the "spare" header words for pack identification data). Disk images are mmap()'d on the Linux side so I don't have to issue seek requests in the image file; writes are committed at the end of a (possibly multi-sector) transaction. I don't bother implementing the disk address prediction register because only twenex uses it. The implementation doesn't pass DEC's diagnostics. And so on. I only wanted to run ITS with as little speed penalty as possible.

I also did away with passing bus grants because it used up too much time - The software assumes the Unibone is the last (or only) device on the bus, which is where the RH11 and Chaosnet would normally go anyway.

[Suzuran Majere]

Here's a video made on the 8th of last month - The interface hasn't changed much since then, but I changed the timing for LED blinking so it looked better to a human observer.

https://www.youtube.com/watch?v=addQkpU4ZF8

The machine has run for more than 24 hours while connected to the global chaosnet, so there's that. I'm working on getting it accessible via modem dial-up (over SIP) and/or a gateway from the public internet.

[John H. Reinhardt]

On 9/7/2022 9:36 AM, Joerg Hoppe wrote:
> One escape route: there's the much faster "BeagleBone AI".
> Though its filled up with stuff we don't need, we could make an Unibone port and experiment on.
> But Linux interupts in the 1us time frame remain impossible.
> https://beagleboard.org/ai

Looking around, make sure you get the AI and not the AI-64 version. The AI-64 is newer but has a different board layout which I don't think will work with the QUniBone board.  The BeagleBone AI is hard to find.  Digi-Key says it's "obsolete" and doesn't list them as available.  Mouser doesn't have any in stock but says you can backorder them.  There is one AI available on Amazon (US).  That's about all Google found for me, maybe you know of other sources.

Withe the 4 PRU units and the faster processors it looks like it would be handy for a QUniBone but it seems the original form factor is on it's way out.  I can't tell.  The Beagleboard site doesn't say discontinued, but Digi-Key apparently thinks so.  Mouser has none and none on order, whereas the AI-64 has 800+ on backorder. Unfortunately the AI-64 is a much different design.  Probably more powerful but I think the old AI would have been better suited.

Mouser BeagleBone AI: https://www.mouser.com/ProductDetail/BeagleBoard/BBONE-AI?qs=%252B6g0mu59x7IfEw1Zb81%252B%252BQ%3D%3D#
Amazon: https://www.amazon.com/Beagleboard-SED-102010027-BeagleBone-AI/dp/B07YR1RV64
Digi-Key: https://www.digikey.com/en/products/filter/evaluation-boards-embedded-mcu-dsp/786?s=N4IgjCBcpg7ALAJiqAxlAZgQwDYGcBTAGhAHsoBtEJWWRAZhAF0SAHAFyhAGV2AnAJYA7AOYgAvuJLJIVAEYEsInATmkhBAARYBzcUA

--
John H. Reinhardt

[Suzuran Majere]

The other idea I was kicking around in my head is a modified Unibone board that would accept a DE10 Nano instead of a Beaglebone Black, which would allow implementation of some (or maybe even all) of the device logic in FPGA.

[Robert Armstrong]

On 9/7/22 09:49, Suzuran Majere wrote:
> The other idea I was kicking around in my head is a modified Unibone
> board that would accept a DE10 Nano instead of a Beaglebone Black,
> which would allow implementation of some (or maybe even all) of the
> device logic in FPGA.

  How about an "adapter" PCB that takes a DE10 and plugs  into the
UNIBONE?   It would be a thick stack of boards, but if the UNIBONE is
the only thing in your BA11-K then you have plenty of room.

Bob

[Suzuran Majere]

It's not the *only* thing in the BA11 (I have two DZ11s, and one more I can install if I find another distribution panel) but it has plenty of room; I'll have to look at how different the pinouts are. An adapter is absolutely the cheaper option.

[Suzuran Majere]

I should also point out that if you have working Massbus controllers in your KS (I did not, I was missing some pieces) there are Massbus device emulation solutions that make using a Unibone unnecessary. The Living Computer Museum published their designs for Massbus device emulation, but I don't have the links handy.

[pbi...@gmail.com]

See: https://github.com/livingcomputermuseum?tab=repositories 

[Robert Armstrong]

> pbi...@gmail.com wrote:
> The Living Computer Museum published their designs for Massbus device emulation,

>but I don't have the links handy.

  Very true – I know it well.

 

          https://github.com/livingcomputermuseum/MDE2

 

  You will need a PC with Windows, PCI slots, and one or two PLX PCI FPGA cards to make this work, though.  Not sure what happened to the PLX people, but you might still be able to find one of their cards.  The UNIBONE is much more straightforward option if it can be made to work.

 

  AFAIK the LCM never tried this with an RH11 or a  2020, but it certainly worked with the RH20 in a KL, and with the RH70 in Miss Piggy.  It would probably work with the 2020.

 

Bob

 

[Suzuran Majere]

Well, good news and bad news on the BBB-to-DE10-adapter front: Looking at the code again, I forgot that the BBB has tight constraints on what the PRUs can actually access as far as external pins. Only 20 signal lines are used to interface to the Unibone, so it wouldn't be hard to make an interposer routing those to DE10 FPGA pins, but those signal lines aren't connected to any of the Unibus transceiver chips - they drive a register selector and can only see 8 lines of the bus at a time. I imagine this probably isn't well-suited to driving parallel logic like a FPGA, and with the switching delays needed to access other signals I don't know that it buys us much.

[Joerg Hoppe]

Hi all,

I think "BBB on DE10" is a clumsy approach.
Better invest the brainpower into a redesign with an ARM/FPGA  core like
Xilinx Zynq.
That'd be a different project then.
I rejected that idea in 2018 because ZYNQ evaluation boards are quite
expensive
(at least for models with a FPGA suitable for a fast ARM core),
I mistrusted future availability, and the BBB gave me all I needed.

kind regards,
Joerg

[Suzuran Majere]

The reason I was specifically leaning toward the DE10-Nano is because they are popular in the retro-gaming emulation community (via the MISTer project) and so have consistent demand, I thought this would help ensure a steady supply would be available in the future. This was before the supply chain issues.

[Mike Ross]

Oooooooh. 

I nearly missed this!

Would you be willing to share an image of the current state of your work?

I have a KS10, I have two broken TU45s, I have a bunch of TOPS-10 RP06 packs, but no drive. I have a perfect RM02, but no packs with any -10 OS installed! A Unibone is my best option to bring it up.

Thanks

Mike 
http://www.corestore.org 

--
You received this message because you are subscribed to the Google Groups "UniBone" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unibone+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/unibone/15dced80-176e-4a74-967f-441260fe7bd6n%40googlegroups.com.

--

http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'

[Mike Ross]

Bob,

There IS another option, but it needs a bit of work to get it up and running. LCM did open-source their Massbus emulation hardware and software. So building the hardware and installing/configuring the software would let you boot a -10 from a modern PC server emulating Massbus devices, exactly as LCM does/did. 

Mike 

--
You received this message because you are subscribed to the Google Groups "UniBone" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unibone+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/unibone/004a01d8c2c8%2492460620%24b6d21260%24%40com.

[Suzuran Majere]

I made a couple cursory attempts at getting TOPS-10 to run but it failed very early on starting the distribution monitor. I want to say it was unhappy with something tape-related and hadn't touched disks yet. I didn't do much in the way of diagnosing.

If you don't already have an assembled unibone, I can set up my analyzer and diagnose further after this weekend to see what I can shake out, while you go about getting a unibone. If you already have a unibone, and you have a logic analyzer you can connect to the unibus, I can clean things up to cut a distribution and then leave it to you - but without the logic analyzer or some other way of logging the bus it's going to be a lot of extremely frustrating guessing at best.

[Mike Ross]

I have a Unibone, and if you can boot ITS with what you have right now, a copy of that would enable me to test the KS10!

Mike 

To view this discussion on the web visit https://groups.google.com/d/msgid/unibone/b16b418f-dab3-4a51-a2e1-966d3651d597n%40googlegroups.com.

[Suzuran Majere]

Oh, if you just want to test, I can absolutely send you the tape stuff and a diagnostics tape. You don't need even need disks or a disk controller to check the majority of the machine. I'm at work though, and won't get off until 5 PM central time; Let me see what I can get away with.

[Suzuran Majere]

I tried sending you a direct message; Please let me know if you got it (or didn't)

On Friday, September 9, 2022 at 8:19:08 AM UTC-5 tmfd...@gmail.com wrote: