search

PDP-10 / its

Incompatible Timesharing System
Other
834 stars 80 forks source link

Enabling use of the XGP #2271

Closed larsbrinkhoff closed 4 months ago

larsbrinkhoff commented 5 months ago

Work being done enabling the XGP and using it to print documents through a PDP-11 emulator.

larsbrinkhoff commented 5 months ago

Some of the parties involved:

larsbrinkhoff commented 5 months ago

The spooler source says:

tty1==3                         ;only these ttys can send to xgp
tty2==24

And TTYTYP:

        TTDPRT 3,SPEED=110,TT=%TTLCL    ;T03 XGP TTY (9TH)
        TTDDPT 24,TT=%TTLCL+%TT340,HOR=71. ;T24 Datapoint Near XGP (9th)

But I don't see any reference to these TTY lines in the rest of the code. I have successfully started XGPSPL from T00.

larsbrinkhoff commented 5 months ago

I found the file .XGPR.;XGP LOGIN. It first stuffs the XGP-11, and then starts XGPSPL. Also, the spooler insists on being run as the XGP user. It would seem appropriate that the INQUIR database has an entry for XGP and for it to have .XGPR. as its home directory. @eswenson1, can we do this from the build script?

Also, when ITS has booted, we should ideally arrange for the XGP user to log in from T03. I'm not sure how.

eswenson1 commented 5 months ago

It would seem appropriate that the INQUIR database has an entry for XGP and for it to have .XGPR. as its home directory. @eswenson1, can we do this from the build script?

Probably. But we use a binary data file for which I don’t think we have source as the primordial INQUIR database. I’ll see if I can reverse engineer source for it and then update to have an entry for XGP.

eswenson1 commented 5 months ago

I think I'm going to switch how we initialize INQUIR on a new system. Rather than using the committed LSR1 EMPTY file as the basis for inquir;lsr1 1, I'm going to update to run INQUPD in LSRINI mode, to create a completely empty LSR1 EMPTY file from scratch. Then, I'm going to commit a INQUPD script that will add the entries we want to the inquir database. That can include an entry for XGP. I'll have the script run the INQUPD such that the input file is processed and the LSR1 1 file updated correctly.

larsbrinkhoff commented 5 months ago

Sounds good, thanks!

larsbrinkhoff commented 5 months ago

Looks like ITS only uses empty lines and XGP image mode, so that's pretty easy to decode.

However, there is one thing that doesn't seem to work. When I spool a file with :XGP LARS; TEST XGP I get this from XGPSPL, and the file name doesn't look right at all.

A new file is being created!                                                                            
LARS    KA - 12:26:04 01/31/22 36       ^Q ^Q/^Q_^Q 0: ^Q ^Q ^Q ^Q ^Q V; X@ ^Q
larsbrinkhoff commented 5 months ago

This CMU document describes their XGP interface: http://shelf2.library.cmu.edu/Tech/backups/227003483.pdf

From clues in the ToTS archives, we can see MIT's interface is clearly a copy of the CMU interface, with slight modifications . The files describing the MIT interface doesn't cover everything, but the CMU documents fills in the gaps.

larsbrinkhoff commented 5 months ago

The emulator is working. I tested AI memo 358. xgp-20240202073943

larsbrinkhoff commented 5 months ago

I updated the KA10 emulator to handle multiple 10-11 ports. Checked that TV-11 and XGP-11 work together.

We now get the XGP status on the Name Dragon free display. namdrg-xgp

larsbrinkhoff commented 5 months ago

@aap supplied a filter to convert the plain bitmap output to something closer to the real thing. I have an XGP printout of AS;CHESS 144. I made a new listing with @ as close as possible, but it's a newer version so there are some minor differences. Here's a comparison between bitmap, filtered, and photo. chess-144-bitmap chess-144-meatball chess-144-photo

larsbrinkhoff commented 4 months ago

Printing works fine. There's still the filename bug as per above. And may need to look into this in XGPSPL:


samp3:  push p,a
        move b,(a)              ;device
        camn b,[sixbit /DSK/]   ;only AI has an XGP
         move b,[sixbit /AI/]
larsbrinkhoff commented 4 months ago

The file name is written by XQUEUE into a queue file in .XGPR. XGPLSPL just prints what's there.

eswenson1 commented 4 months ago

I think I'm going to switch how we initialize INQUIR on a new system. Rather than using the committed LSR1 EMPTY file as the basis for inquir;lsr1 1, I'm going to update to run INQUPD in LSRINI mode, to create a completely empty LSR1 EMPTY file from scratch. Then, I'm going to commit a INQUPD script that will add the entries we want to the inquir database. That can include an entry for XGP. I'll have the script run the INQUPD such that the input file is processed and the LSR1 1 file updated correctly.

Also, the LSR1 EMPTY file can be generated by the INQUPD program, so no need for one in our “bin” directory. I’ll make these changes soon.

eswenson1 commented 4 months ago

Printing works fine. There's still the filename bug as per above. And may need to look into this in XGPSPL.

I couldn’t find a reference to the “file name problem” in a post earlier in the list of posts. What problem are you referring to?

larsbrinkhoff commented 4 months ago

It's this: https://github.com/PDP-10/its/pull/2271#issuecomment-1918923215

I think I found the problem. The XQUEUE has been conditionalized for "mit", but the brackets are in the wrong place here:

;Output the filenames into the queue file.
quefil:
        move b,device
ifn mit,[
        move a,machin
        camn b,['DSK,,]
         movem a,device
        movei b,device
]
        move d,[440700,,fnmbuf]
        pushj p,rfn"pfn

pfn expects the address of a file name quartet in B. It's supposed to be device, but the movei was lost.

larsbrinkhoff commented 4 months ago

Regarding the INQUIR entry, it should be made such that GUNNER doesn't gun down XGP. @eswenson1, I believe there's some user group that are protected against that, correct?

eswenson1 commented 4 months ago

I’ll have to look at GUNNER to see what it might be….

larsbrinkhoff commented 4 months ago

Maybe not!

SUBTTL Autologout
;
; There are five classes of users:
; 1) Non-logged-in network users.
; 2) Logged-in network users:  logged in, but not to a directory, from the
;    net.
; 3) Local users:  coming from a hardwired terminal, or logged into a
;    directory from the net.
; 4) XXFILE and .BATCH:  STYs in use by programs other than telnet
;    servers.
; 5) HACTRNs:  trees, either net or hardwired, with only a hactrn.  They
;    will be logged out, rather than detached.
; Class 4 is never touched:  the program running it is assumed to do
; reasonable things.
; Associated with each of the other classes is a time:  after a tree has
; been 'idle' (see below) for that period of time, some action is taken,
; depending on the class.
; 3:  Local users will be detached, but bit 1.4 of the DETACH call will
;     not be set; the tree will not be killed automatically.
; 2:  Network users will be detached, with bit 1.4 of the DETACH call on.
;     The tree will be killed after an hour (this bit is also set when,
;     for example, the network dies and net users are detached).
; 1:  Others will be gunned down.
eswenson1 commented 4 months ago

What I did, in order to prevent GUNNER from gunning me down when I was logged in and idle was to update the UNAME compare a few instructions after the label ALOGL. The original code had GSB as the UNAME to skip the idle check for. I changed it to EJS on my machines.

We may want to change it to XGP, or add a check for XGP (and EJS).

ALOGL:  SKIPGE  @TTYSTS         ; SKIP IF TTY IS IN USE
         JRST   ALOGFL
        HRRZ    U,@TTYSTS       ; USER INDEX-->U
        MOVE    B,@XUNAME
        CAMN    B,[SIXBIT /GSB/]
         JRST   ALOGFL
larsbrinkhoff commented 3 months ago

I suppose the DM gunner isn't really appropriate for running on a system where there are also many AI jobs running. One workaround would be to not run the DM gunner. The MC gunner seems work better with the AI system. Another solution would be to update the DM gunner to leave "system" jobs alone. Whatever that means. Probably it knows to avoid the DM stuff like COMSYS, right? Or maybe it already has hooks to use INQUIR information.

eswenson1 commented 3 months ago

What do you mean by AI jobs? Are you referring to interactive logins that were really more like “daemons” (eg XGP), and where GUNNER treats them like regular users?

My beef with GUNNER is that it treats network users as very much second class citizens, gunning them if they are idle. I always use chaosnet (supdup) to access all 5 of my ITS systems, so if my sessions are idle, they get gunned. For non-networked, terminal users, such as users of your ITS systems, where you login by connecting to emulated terminals, those jobs will get detached.

The GUNNER daemons, as is, might be useful for systems like HX and BC, where there may be lots of users, limited resources, and the need to free job slots when users leave their sessions attached but idle.

GUNNER does a lot of things and we should look at the functionality and see whether any of the OTHER stuff is useful. If it is, we could simply comment out the idle job gunning task from the task table. We’ve commented out other tasks already (such as NCP-related tasks).

If we find it not useful, we can simply not put in place the ATSIGN GUNNER link, which will effectively disable it, but allow its use on those systems where gunning is useful, or we could make the more drastic change to comment out GUNNER in DEMSTR. That would require someone to update DEMSTR and reassemble it.

How is CSTACY’s gunner better? Because it warns first before gunning? Or does it have a better mechanism for discriminating whom to gun?

larsbrinkhoff commented 3 months ago

I mean some vague and unspecified set which may only be XGPSPL.

I'm starting to think the DM GUNNER is a bit of overkill for most situations. Sure, for HX type hosts, yes it's useful.

I like Cstacy's gunner because it only guns down not-logged-in users. That's pretty much perfect for my use case, because I get a lot of those but rarely any others. And it leaves me and XGP alone.