Talk:MIT UNIBUS XGP interface
SAIL hardware interface?
I found these SUDS drawings dated 1973, in an archived ITS directory called "XGP". I was hoping they would explain MIT's hardware interface, but they don't seem to match the PDP-11 software. Since I see references to IOBUS, CONO, CONI, I suspect they are for SAIL's XGP interface. I converted the files to SVG format; feel free to take a look. http://lars.nocrew.org/tmp/xgp-drawings/ Larsbrinkhoff (talk) 07:29, 30 January 2024 (CET)
- I am 99.4% sure they are for the PDP-10 I/O bus (not only a reference in drawing 'COMND' to "CONO SET", and also to "CONI" in 'STATUS', but if you look at the way "DEVSEL" is generated, on 'COMND' - and neither there or anywhere else any reference to MSYN or SSYN), so not the UNIBUS interface from MIT (or CMU). I designed several UNIBUS interfaces, and this ain't one! Jnc (talk) 15:06, 30 January 2024 (CET)
Data encoding
Are those encodings interpreted by the UNIBUS XGP interface, or by the XGP itself? Jnc (talk) 14:10, 31 January 2024 (CET)
- I'm not sure. I found a file that seem to describe an interface, maybe the CMU one. It says "The BIT CLocK is active only when data is actually being sent to the XGP. Its most direct purpose is to clock the next video bit into the VIDEO flip-flop from either the right end of the SR (Sheet 8) in CHAR or IMAGE modes, or from the BLACK/WHITE flip-flop (Sheet 8) in VECTor mode. This VIDEO is actually nothing more or less than the z-axis input to the CRT in the printer." (SR is a shift register.) Thus it seems to me most or all logic is in the interface. The description of the SAIL interface seems similar; there's a direct feed to the CRT. Larsbrinkhoff (talk) 14:52, 31 January 2024 (CET)
- Interesting! Good find - where was it?
- We can probably answer the question definitively by looking at the drawings for the MIT UNIBUS XGP interface; are those available?
- Looking at Appendix I of the XCRIBL document for the CMU system, covering the PDP-11—XGP interface, which gives some detail of their interface, it has a lot of similarities to the MIT one, including character/vector/image modes, and lack of a 'count' register (only an 'address'). (It's clearly a different design, though.) One has to wonder if that's because the MIT one was based on the CMU one (ISTR seeing something which said it was) - perhaps only at the level of verbal discussions, of 'how do we attack this problem'? Or is some of that similarity because of what the XGP itself requires as input? Although the descriptions sound like the input to the XGP is just a video signal, line by line, though. So I would guess either design communication, or 'great minds think alike'! :-) Jnc (talk) 16:17, 31 January 2024 (CET)
Emulator working
I have an emulator running. I have tested the complete chain from TJ6 producing an XGP file, :XGP spooling it, the XGP: device showing the queue, XGPSPL sending the file over the 10-11 interface, and a PDP-11 emulator running the XGP-11 code. Larsbrinkhoff (talk) 07:37, 2 February 2024 (CET)
Using the XCRIBL document
We need to be careful in using the XCRIBL document; from the XGPHRD DOC description of the CMU interface, it's quite a different piece of hardware from the MIT one. That talks about using an M796, an M7821 and an M105, which would need to plug into a backplane; in the recent picture, the XGP interface sems to be built out of a wirewrap card at the top of the rack. (Yes, the XGP interface could be split between that card, and some cards mounted in either the main PDP-11 box, or in a possible BA11 expander box behind the blank panel above or below the CPU, but - if they split it that way, they'd have a lot of signals needing to go from there to that wirewrap card, and that seems unlikely.) It may be very similar in programming terms, but there is no guarantee that anything described there is in the MIT interface. It's probably best to just keep that interface description in the back of one's mind when reading the PDP-11 code in XGP >. Jnc (talk) 06:06, 3 February 2024 (CET)
- Almost everything is implemented as per MIT sources. There's one thing no MIT code or text explains: how to interpret "2 0 0 1" as an empty line. The CMU information says "2 0" is two white dots in character mode, and then "0 1" is a stop. It's curious that there are two dots there. Why two, no more, or less? Why just not a "0 1"? Maybe two is the minimum to make some marginal thing in the hardware happy. Anyway, this is the best theory I have so far. Making emulators from incomplete information is like a testing a scientific theory. The emulator is the theory, and running the original software is the experiment. If all experiments are successful, we'll consider the theory validated. If we can design a test to break the emulator, the theory is invalidated and needs updates. Of course, there's a complication in that the original software may have bugs. Larsbrinkhoff (talk) 07:35, 3 February 2024 (CET)
