[pdp7-unix] pdp7-unix Digest, Vol 5, Issue 21

Sebastian Rasmussen sebras at gmail.com
Thu Oct 24 22:59:17 AEST 2019

> > I suppose a "score board" (table) of program status would be a good
> > thing to have (on the repo wiki?)!!
> I vote yes! I have been trying to do more, but it moves pretty fast around here
> and every time I get ready to submit my changes, somebody else, you know
> who you are :), beats me to it.

Yes, I do. :) These are the files that I have not retranscribed:
bc.s, bi.s, bl.s, cat.s, check.s, db.s, dmabs.s, dskio.s, dskres.s, dsksav.s,
ds.s, ed1.s, ed2.s, fop.s, ind.b, init.s, lcase.b, maksys.s, s1.s, s2.s, s3.s,
s4.s, s5.s, s6.s, s7.s, s8.s, s9.s, sop.s and sysmap

Many of these are files not from the latest scans, but it is not unlikely that
there are still typos in those. What I have been doing is retranscribing files
from scratch from a zoomed in view of the scan (without looking at the
existing file in scans/). Once I'm done I diff my retranscription with the
file in scans/ to see where I made a typo, and hopefully highlight where
the file in scans/ might have a typo. Then I go back and look at the .pdf,
and try to verify that this is indeed a typo in scans/whatever.s. Once I'm
done I have been submitting a pull request to the upstream project.

Doing this for a number of files made it easier for me to recognize the font
used (is that "il" or "i1"?) and the assembler used (is that "lac ii"
or "lac 11"?
is that "prob: .." or "prob: ,,"?). So I realize that my first
transcriptions are
bound to have issues. I'd in particular like if someone would make a
retranscription of fop.s since it appear it has only been me looking at that
file, and only once -- so there are likely typos there.

I also compiled the .s-files using tools/as7 like so:
./tools/as7 --out un ./scans/un.s
./scans/un.s:12: t1 not defined
./scans/un.s:20: t1 not defined
./scans/un.s:24: t1 not defined
./scans/un.s:26: t1 not defined

to look at the error messages and wonder about what that t1 is. Is that
a transcription error where it is used? Is there a transcription error where
it might be defined? Is that a symbol present in another file (i.e. would I
need to do ./tools/as7 --out un ./scans/un.s ./scans/fop.s?). We want all
the files to assemble without errors, so they are a good source of what
to look at. And yes, this t1 error is still present.

These are files that I've either transcribed or retranscribed at least once,
but that doesn't mean that there are not typos still in there (in fact as seen
with un.s above, it is likely that there is!): adm.s, ald.s, apr.s,
as.s, cas.cas,
cas.s, p1.s, p2.s, p3.s, p4.s, p5.s, psych.s, salv.s, scope.cas, st1.s, st2.s,
st3.s, st4.s, st5.s, st6.s, st7.s, t1.s, t2.s, t3.s, t4.s, t5.s, t6.s,
t7.s, t8.s,
ttt1.s, ttt2.s and un.s.

One thing I've been pondering is to try to correlate the labels in the source
files. Having looked at the source a bit now, I'm sensing that there might
be misnamed labels. E.g. sysmap lists all the kernel symbols, and I bet
that there are labels that do not match in the .s-files. That might be a
worth looking into..? It might be a fruitful way to identify mistyped labels.
Can something similar be done for the .s-files for the commands? Maybe,
I don't know.

Some programs, e.g. src/cmd//ttt?.s appear to write something to the
screen and wait for input. How does this program work? Look at the
assembly, figure out how each part works and add comments to the
source file, push a pull request and post here to tell how it works.

On a slightly unrelated note I saw that my gcc 9.2.1 make several
complaints when I run make from scratch in pdp7-unix:
gcc -Wno-multichar -o b ../tools/b.c
../tools/b.c:37:1: warning: return type defaults to ‘int’ [-Wimplicit-int]

Even if that might be trivial to fix (perhaps a missing include or compiler
option?), it is still something that would be nice to have fixed.

The tools/as7 assembler complains about multiply defined symbols
when assembling some commands. Is that something that we want
to address? Maybe tools/as7 should not complain about those since
src/cmd/as.s (if I understood it correctly) does not.

Also there are files in scans/ that are not in src/, to add them there
I believe they must at least assemble cleanly. Pick one that is missing,
do it takes to make it assemble, make pull requests to fix typos and
then a pull request to add it to src/: ald.s, fop.s, ln.s, psych.s,
st1.s, st2.s,
st3.s, st4.s, st5.s, st6.s, st7.s, t1.s, t2.s, t3.s, t4.s, t5.s, t6.s,
t7.s, t8.s
and un.s

Finally, as Phil has pointed out the font when used in SimH still looks
strange. Why is it that A and < and > look strange? It may be due to
a transcription errors in cas.cas, scope.cas or cas.s. It might be somewhere
in the reformatting of the output from cas

cd src/cmd/
../../tools/as7 --out cas cas.s
../../tools/a7out cas cas.out cas.cas
../../tools/a7out cas scope.out scope.cas
cat cas.cas scope.cas

to the format used in SimH:
It might be due to a bug in the intepretation of that font data:
Or is this how the characters should be rendered? If so we need to understand
the cas assembly and the algorithms it implements so we can convince
ourselves that the characters actually were meant to be rendered this way,
and convince ourselves that there are no bugs in the SimH rendering.

As long as we can't easily run SimH's pdp7 emulator with GRAPHICS-2 support,
run the built image, log in as ken, fire up Space Travel and understand how to
play the game, there is still work to be done... :)

 / Sebastian

More information about the pdp7-unix mailing list