[pdp7-unix] Stuff to do

Will Senn will.senn at gmail.com
Sat Oct 26 07:27:56 AEST 2019

On 10/24/19 8:55 AM, pdp7-unix-request at minnie.tuhs.org wrote:
> Message: 6
> Date: Thu, 24 Oct 2019 14:59:17 +0200
> From: Sebastian Rasmussen<sebras at gmail.com>
> To:pdp7-unix at minnie.tuhs.org
> Subject: Re: [pdp7-unix] pdp7-unix Digest, Vol 5, Issue 21
> Message-ID:
> 	<CAAgDR1NpzEiojU2QLu9LJomO1NBLPjr0_c_4dy+mohsq+0=sXg at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>>> 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.

Got it. I've done a bit of that, but I'll be much more systematic. In 
the absence of any dissent or better idea, I'll start retranscribing and 
diffing, beginning with fop.s, then I think ed?.s.

> 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: ,,"?).

Uh oh, I thought it was just printed funky, you mean lac ii is valid 

> 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
> I
> II
> ./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.

Since I'm still learning my way around assembly, I'll go after this a 
bit gingerly, but if I 'fix' anything, I'll probably ask a question 
rather than submit it.

> 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.

I'll leave these alone for the time being.

> 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.

Beyond my current skill level, but I did notice mismatches between names 
and locations in a.out vs sysmap, but chalked it up to differences in 
the process and order of compilation - again, not something I fully 

> 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.
Way down the road for me :).
> 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

Will do.

> 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:
> https://github.com/larsbrinkhoff/simh/blob/lars/graphics2/display/g2chars.c
> It might be due to a bug in the intepretation of that font data:
> https://github.com/larsbrinkhoff/simh/blob/lars/graphics2/display/graphics2.c#L596
> 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.

Way beyond my comfort zone :)

> 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...:)

Thanks for laying it all out there. If y'all come across something that 
isn't rocket science or that needs another set of eyes on it while 
you're doing the heavy lifting, let me know. I'll just keep working on 
the re-transcriptions, hunting for bugs, and learning about the system 
until then.



GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/pdp7-unix/attachments/20191025/fa168c0e/attachment-0001.html>

More information about the pdp7-unix mailing list