Talk:MIT UNIBUS XGP interface - Revision history

Jnc: /* XGP PDP-11 model */ new section

2024-02-03T20:43:43Z

XGP PDP-11 model: new section

← Older revision		Revision as of 20:43, 3 February 2024
Line 28:		Line 28:

	:: I like that analogy! [[User:Jnc\|Jnc]] ([[User talk:Jnc\|talk]]) 15:38, 3 February 2024 (CET)		:: I like that analogy! [[User:Jnc\|Jnc]] ([[User talk:Jnc\|talk]]) 15:38, 3 February 2024 (CET)

			== XGP PDP-11 model ==

			The [[:Image:MITXGP.jpg\|recent image]] shows definitively that it was a [[PDP-11/20]]. Also, it's not the very similar [[PDP-11/15]]; that machine had only 16 switches in its switch register, as can be seen [[:File:Pdp1115.jpg\|here]], not the 18 on the -11/20. [[User:Jnc\|Jnc]] ([[User talk:Jnc\|talk]]) 21:43, 3 February 2024 (CET)

Jnc: I like that analogy!

2024-02-03T14:39:25Z

I like that analogy!

← Older revision		Revision as of 14:39, 3 February 2024
Line 26:		Line 26:

	: 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. [[User:Larsbrinkhoff\|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff\|talk]]) 07:35, 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. [[User:Larsbrinkhoff\|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff\|talk]]) 07:35, 3 February 2024 (CET)

			:: I like that analogy! [[User:Jnc\|Jnc]] ([[User talk:Jnc\|talk]]) 15:38, 3 February 2024 (CET)

Larsbrinkhoff: /* Using the XCRIBL document */ Yes, I'm careful.

2024-02-03T06:37:05Z

Using the XCRIBL document: Yes, I'm careful.

← Older revision		Revision as of 06:37, 3 February 2024
Line 24:		Line 24:

	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 [https://www.computerhistory.org/collections/catalog/102803907 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 >. [[User:Jnc\|Jnc]] ([[User talk:Jnc\|talk]]) 06:06, 3 February 2024 (CET)		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 [https://www.computerhistory.org/collections/catalog/102803907 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 >. [[User:Jnc\|Jnc]] ([[User talk: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. [[User:Larsbrinkhoff\|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff\|talk]]) 07:35, 3 February 2024 (CET)

Jnc: /* Using the XCRIBL document */ new section

2024-02-03T05:06:57Z

Using the XCRIBL document: new section

← Older revision		Revision as of 05:06, 3 February 2024
Line 20:		Line 20:

	: Fantastic! [[User:Jnc\|Jnc]] ([[User talk:Jnc\|talk]]) 00:07, 3 February 2024 (CET)		: Fantastic! [[User:Jnc\|Jnc]] ([[User talk:Jnc\|talk]]) 00:07, 3 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 [https://www.computerhistory.org/collections/catalog/102803907 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 >. [[User:Jnc\|Jnc]] ([[User talk:Jnc\|talk]]) 06:06, 3 February 2024 (CET)

Jnc: /* Emulator working */ Fantastic!

2024-02-02T23:07:56Z

Emulator working: Fantastic!

← Older revision		Revision as of 23:07, 2 February 2024
Line 18:		Line 18:

	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. [[User:Larsbrinkhoff\|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff\|talk]]) 07:37, 2 February 2024 (CET)		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. [[User:Larsbrinkhoff\|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff\|talk]]) 07:37, 2 February 2024 (CET)

			: Fantastic! [[User:Jnc\|Jnc]] ([[User talk:Jnc\|talk]]) 00:07, 3 February 2024 (CET)

Larsbrinkhoff: Emulator working.

2024-02-02T06:38:00Z

Emulator working.

← Older revision		Revision as of 06:38, 2 February 2024
Line 14:		Line 14:
	:: We can probably answer the question definitively by looking at the drawings for the MIT UNIBUS XGP interface; are those available?		:: 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)		:: 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)

			== 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. [[User:Larsbrinkhoff\|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff\|talk]]) 07:37, 2 February 2024 (CET)

Jnc: /* Data encoding */ Interesting find! Where next...

2024-01-31T15:17:17Z

Data encoding: Interesting find! Where next...

← Older revision		Revision as of 15:17, 31 January 2024
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)

Larsbrinkhoff: /* Data encoding */ Not sure, but maybe interface.

2024-01-31T13:52:29Z

Data encoding: Not sure, but maybe interface.

← Older revision		Revision as of 13:52, 31 January 2024
Line 8:		Line 8:

	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)

Jnc: /* Data encoding */ new section

2024-01-31T13:10:51Z

Data encoding: new section

← Older revision		Revision as of 13:10, 31 January 2024
Line 4:		Line 4:

	: 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! [[User:Jnc\|Jnc]] ([[User talk:Jnc\|talk]]) 15:06, 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! [[User:Jnc\|Jnc]] ([[User talk:Jnc\|talk]]) 15:06, 30 January 2024 (CET)

			== Data encoding ==

			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)

Jnc: /* SAIL hardware interface? */ Yes. definitely a PDP-10 I/O bus device

2024-01-30T14:06:54Z

SAIL hardware interface?: Yes. definitely a PDP-10 I/O bus device

← Older revision		Revision as of 14:06, 30 January 2024
Line 2:		Line 2:

	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/ [[User:Larsbrinkhoff\|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff\|talk]]) 07:29, 30 January 2024 (CET)		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/ [[User:Larsbrinkhoff\|Larsbrinkhoff]] ([[User talk: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! [[User:Jnc\|Jnc]] ([[User talk:Jnc\|talk]]) 15:06, 30 January 2024 (CET)