Talk:Xerox Graphics Printer

XGP-11 code

So I had a look for the code that ran in the XGP-11 (I wanted to see what it could tell me about the PDP-11<->XGP interface), but I could not find it. SYSTEM; has the code for the TV-11, and the code that ran in MC's 11's and the AI Chaos-11, but despite searching for a while, the XGP-11 code never turned up. Any idea where it is? (The XGP spooler is missing too.) Jnc (talk) 02:45, 11 September 2023 (CEST)

Sure, it's readily available, but there are a few copies around with various names. I believe the most up to date version is (now; on GitHub) SYSEN2; XGP 32 (which has a recent update from version 31). For some reason STUFF defaults the binary file to SYSBIN; VXGP BIN, but eh, close enough.

Spooling documents is done with SYSEN2; XQUEUE, binary name SYS; TS XGP. XGPDEV is the XGP: device which lists documents in the queue. Taking things out of the queue is SYSEN2; XGPSPL.

Larsbrinkhoff (talk) 08:32, 11 September 2023 (CEST)

I was insufficiently determined! I looked in SYSENG;, and maybe in SYSEN1;, but gave up before I got to SYSEN2;! I wonder why it wound up there - was it always there, I wonder, or did it get moved there after the XGP was junked? (Odd that the code for all the other -11's was in SYSTEM; - although the MC front-end -11 ran a combination of IOELEV and KLDCP - this describes how they co-operated to share the machine.)

So it's hard to learn a lot about the XGP<->PDP-11 interface from that code. It appears to be a DMA device, but they didn't build it out of a DR11-B, I'm quite sure (the only possibility - the registers are wrong), so it must have been entirely home-rolled. It must have had the raster/scan line length built into it, because there's a MAR, but no 'transfer length' register. Without reading the code in detail, it must have just fed it one raster at a time. But there are all sorts of mysteries, like this:

 ;VECTRS GETS CALLED AT THE BEGINNING OF EACH PAGE TO RESET THE VECTOR

 ;DATA BASE, SINCE VECTORS ARE NOT ALLOWED TO CROSS PAGE BOUNDARIES.

VECTRS: RTS PC

Looks like they were planning some vector support that either never got done, or got ripped out?

It's interesting to see this code that drives the XGP, because when we got the Dover, it already had a spooler on the Alto that drove it, which included the code to take PRESS files and generate bits to send to the Dover, and I have this vague memory that we never had that source. I'm pretty sure we never messed with that (in fact, when Dave Clark added the code to that machine to talk IP/UDP and TFTP on it, and had it running alongside the PARC code that drove the Dover and did EFTP over PUP [which is what the AI Lab crowd used to talk to it - there's a protocol translator in the AI-CHAOS-11 - which is why that machine was retained after the Rubin interface to AI died] I think he had to use the existing Alto multi-tasking mecanism.)

Is there any documentation at all on the XGP<->PDP-11 interface, do you know? Jnc (talk) 14:49, 11 September 2023 (CEST)

I don't think so... hmm, maybe there is SUDS schematics since it's contemporary with the TV-11. There is documentation for the PDP-10-to-XGP-11 protocol, but not the XGP hardware, as far as I know.

I did start on a XGP hardware emulation for SIMH based on the XGP-11 source code, but as you say, it's not straightforward. I think a mix of reading and understanding the code, and dynamic analysis a.k.a run-it-and-see-what-happens is the way forward. Larsbrinkhoff (talk) 07:50, 12 September 2023 (CEST)

Oh, and by the way, the Spruce software for the Dover is available. I think it would be possible to make an emulated PUP network and put an Alto there as a Dover print server. But it's a lot of work for a niche application Larsbrinkhoff (talk) 07:52, 12 September 2023 (CEST)

XGP<->PDP-11 interface

Yes, we may have to resort to resort to the drawings, if we can find them. I can easily believe that nobody bothered to document how the interface worked.

I've been looking at XGP >, trying to get a handle on how the PDP-11<->XGP interface works, and there are only three places in the code that load the interface's MAR - and two of them use a null scan line:

BNULL:	.BYTE 2,0,0,1		;NULL SCAN LINE

Only 4 bytes, and there is other stuff right after it; so now I am wondering if, rather than each scan line (in memory) being the full size (1700. bits) [since there is no 'length' register], there is a field at the start of each scan line (in memory) that tells something (the XGP interface on the -11 - we need a name for that piece of hardware - I don't recall seeing one anywhere that the MIT people used for it; possibly the XGP itself) how long the scan line is. I.e. when the interface starts a new scan line, perhaps it reads in a header at the start of the line, in memory, which has a field (more than a byte, since a scan line is 1700. bits) which it loads into a counter in the PDP-11<->XGP interface, for that line. Unless it's just a bit in the header, which says 'full scan line' or 'null scan line'. I can probably work that out, once I fully grok the code that turns incoming lines of text into a series of scan line buffers.

I recall you saying, in email to the 'its-hackers' list, that you were thinking of getting a simulation of the XGP running. What is your plan - to emulate the old PDP-11<->XGP interface, so you'd run the XGP > code in a simulated -11? Jnc (talk) 18:36, 12 September 2023 (CEST)

Yes, that is the plan. We had such great success running the TV-11 code in emulation and sharing memory with the KA10, so I'd like to do the same for the XGP-11 (and possibly more). Larsbrinkhoff (talk) 18:44, 12 September 2023 (CEST)

Ah, so you will need a programming specification for the MIT PDP-11<->XGP interface. What do you have so far?

I wonder if there is any connection to the CMU one? (It also used a PDP-11.) Jnc (talk) 20:03, 12 September 2023 (CEST)