On 11/3/2021 9:13 AM, Jay Jaeger wrote:
On 11/2/2021 9:53 PM, Vincent Slyngstad via cctalk wrote:
In making the page zero literals line up (so that the code matches the
originals), I found two locations in xmtape which are coded as
TAD (16.
but the code references a new literal at location 0161, instead of the
previously generated one at location 0166. This is at location 0567
and again at 0666.
I probably used LAP-6 or DIAL to do the assembly - I don't recall right
now.
It seems you didn't notice that I included two separate programs in my
previous post: XMTAPE and CMPTAP ;)
In XMTAPE we see:
0215 0315 1161 0020 TAD (16.
0540 0567 1161 0020 TAD (16.
0646 0666 1161 0020 TAD (16.
In CMPTAP - a separate program - we see:
0216 0336 1166 0020 TAD (16.
I had noticed the two programs, and have translated them both.
The grep-like output you include does help clarify the confusion I was
suffering when I wrote. I later figured out that what was actually
confusing my PAL code was that I had messed up translating the instance
at 0215.
The PAL style assembler assembled that line as if it read
TAD [16 .
which says to OR 0016 and the current location counter, then make a
literal, then make a TAD instruction referencing the literal. Which
basically filled the slot at 0161 with rubbish, but generates the
correct "1161" instruction. The two later references generated a
literal elsewhere, and their code was therefore flagged as incorrect
when the binary diff was done.
The binary diff was against the assembled octal from column 3, and
therefore is missing the literals (and thus always flags them all as
different).
Anyway, the short version is there was never anything wrong with your
LAP/DIAL output, but I was confused for a bit.
Thanks again!
Vince
