To use this, add (CMDS) to the sname search list. Then make a
translation from DSK: (CMDS); TS * to DSK: SYS3; TS CMD. Add a file
<HSNAME>; <XUNAME> (CMDS) where each subroutine is one line for the
subroutine name, followed by a body of commands terminated by a ^_
control character.
This means that ITS's version of D can read it correctly. The difference
is that version 26+ files are expected to have one more ASCIZ string in
the header of the file (the board type); an equivalent fix would be to
remove the first 0 word.
This reworks VERSA's test mode so that you can specify an arbitrary list
of filenames as JCL, and have them rasterised either as SUPDUP graphics
(with /D) or as Harvard scan files in .TEMP.; (by default).
From ITS OBUGS0, dated 1982-09-23:
> In theory (if I turned on XGP file recognition in the spooler), XGP
> files produced by R come out correctly, but XGP files produced by TJ6
> or BOLIO (and I think @) cause it to crash.
At present, XGP files from TJ6 are rendered with some problems, and XGP
files from @ aren't accepted at all (because they don't specify fonts).
This program reads files in several printable formats including ARDS,
XGP and PLT, and rasterises them for Versatec V80 and Gould 5200
printers, or as "Harvard scan" RLE bitmap files.
Normally it runs as a printer spooler, scanning the .GLPR. directory.
When invoked as VERSA, it runs in a test mode where it opens a fixed
series of files and displays them interactively using SUPDUP graphics.
The latter is more useful at the moment, so don't install the CHANNA
link by default.
This is based on AI: SYS2; TS XXFILE, which was compiled by TAA on
1979-08-23 from XXFILE MTA220, and on @larsbrinkhoff's reconstruction.
After modifying the XXFILE MTA224 source to match (remove the OASC in
CTTYB, and the three .CLOSEs in CQUIT), this compiles into an identical
binary.
The UUO handlers look like they're based on the ones from DIRED, so I've
preserved the DIRED comments where possible, but otherwise adjusted to
match the style used in XXFILE.
The PURIMP routine splits the page map into three parts: writable data
at the bottom, a large gap in the middle (which the GC will manage
later), and read-only code/data at the top. There's one CORBLK call for
each of these.
The final call, which gave pages BOT/2000 to 400 as the range, failed
with %EROPG when it hit the first unmapped page after the end of the
pure data. Experimentation shows that, at least with current ITS, this
is how CORBLK normally behaves.
Fix by calculating the final page from RHITOP rather than assuming 400.
