LINCtape images

[Vincent Slyngstad]

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