Difference between revisions of "Talk:MIT UNIBUS XGP interface"

From Computer History Wiki
Jump to: navigation, search
(Data encoding: Not sure, but maybe interface.)
(Data encoding: Interesting find! Where next...)
Line 9: Line 9:
 
Are those encodings interpreted by the UNIBUS XGP interface, or by the XGP itself? [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 14:10, 31 January 2024 (CET)
 
Are those encodings interpreted by the UNIBUS XGP interface, or by the XGP itself? [[User:Jnc|Jnc]] ([[User talk: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 he 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. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 14:52, 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. [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk: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 [http://shelf2.library.cmu.edu/Tech/backups/227003483.pdf 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'! :-) [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 16:17, 31 January 2024 (CET)

Revision as of 16:17, 31 January 2024

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)