SSV 22 crashes when displaying some ARDS files

[larsbrinkhoff]

Most files in -PICS- break SSV: 10, 3D, DRAGON, WUMPUS, ...

FOOBAR PIC will display, but SSV acts strangely afterwards.

How to repeat: :IMPRINT -PICS-; FILE NAME

@jdersch, I don't know if the problem is in SSV or sImlac.

[larsbrinkhoff]

After displaying DRAGON:

Internal error during execution: Unhandled extended Display Processor Mode instruction 170003
PC=001306 AC=177777 MB=011305 - Running
JMP 001305
DPC=017776 DT=000000 DPCE=004633 X=878 Y=110
Mode=Processor HalfWord=First

DPC looks totally off.

[larsbrinkhoff]

However, the contents around DPC looks ok.

>disassemble DisplayProcessor 17770 20
017770\053146 DJMS 003146 
017771\053645 DJMS 003645 
017772\054044 DJMS 004044 
017773\053607 DJMS 003607 
017774\053702 DJMS 003702 
017775\054007 DJMS 004007 
017776\170003 DLXA 001776 
017777\000000 

[larsbrinkhoff]

It's interesting there s a DLXA with bit 0 set. Is that on purpose? Better check what the input file looks like and what SSV is doing here.

[jdersch]

"170003" doesn't decode as a DLXA instruction. There appears to be an issue with sImlac's instruction cache in this case -- it fails to decode the instruction and halts, so the instruction decode cache never gets updated.. but I'm a bit confused as to why the disassembly doesn't similarly fail since they both share the same code path for decoding the instruction.

• Josh

On Sun, May 3, 2020 at 8:01 AM Lars Brinkhoff notifications@github.com wrote:

It's interesting there s a DLXA with bit 0 set. Is that on purpose? Better check what the input file looks like and what SSV is doing here.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PDP-10/its/issues/1881#issuecomment-623123314, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG4E7MNLUFBK7YWNHTI6QF3RPWBNHANCNFSM4MYEB6NQ .

[larsbrinkhoff]

I tested WUMPUS with the ARDS decoder I added to @rricharz's Tektronix emulator. I don't see anything obviously wrong. Here's a screenshot.

[larsbrinkhoff]

Most strokes are short vectors. There are some points and long vectors.

[larsbrinkhoff]

Actually, at the very end of WUMPUS is something a little strange: a point at -525, 665, and then a short vector.

Other coordinates seem to be inside ±300.

[larsbrinkhoff]

Without those last two commands, SSV survives. But the picture doesn't look good.

[larsbrinkhoff]

Macsyma seems OK.

[larsbrinkhoff]

I reduced the WUMPUS data to a smaller set of ARDS commands that look like this:

^]QevD^_\nM{OI^^j@^?A^_FaEk]OaGoCoD]BuJYLIXDbJj^^R@NA

These are five commands (or more if you count short vectors separately):

1. Set point at -168, 155
2. Short vectors: +14,+23; -6,-29; -7,-4
3. Long vector: +21,-63
4. Short vectors: +3,-16; -2,-21; -14,-7; -16,-3; -23,-1; -23,+2; -14,+1; -26,+5; -12,+6; -4,+12; +2,+17; +5,+21
5. Long vector: +9,+39

It should look like this:

But it looks like this:

[larsbrinkhoff]

If I understand correctly, this is the display program. Though I'm not sure exactly where it starts. Maybe it's at 17711. The number of long vector instructions is 17, just like the ARDS data.

017677\000117 DDYM  DHLT DLPN 3
017700\001032 DDSP ,DIXM  DHLT DSTB 2
017701\100011  DHLT DSTB 1
017702\023774 DLXA 001774 (1020)
017703\023775 DLXA 001775 (1021)
017704\037747 DEIM | 0,-3 ON 
017705\037747 DEIM | 0,-3 ON 
017706\100006  DHLT DSTS 2
017707\023776 DLXA 001776 (1022)
017710\037737 DEIM | 3,-3 ON 
017711\077771 SGR1 000001
017712\010530 DLXA 000530 (344)
017713\021233 DLXA 001233 (667)
017714\040011 DLVH (46,55) OFF DOTTED
017717\040027 DLVH (-38,-61) OFF DOTTED
017722\040003 DLVH (-39,-36) OFF DOTTED
017725\047726 DLVH (21,-63) ON 
017730\047763 DLVH (35,-48) OFF DOTTED
017733\040023 DLVH (-34,-53) OFF DOTTED
017736\040007 DLVH (-46,-39) OFF DOTTED
017741\040015 DLVH (-48,-35) OFF DOTTED
017744\040026 DLVH (-55,-33) OFF DOTTED
017747\040025 DLVH (-55,34) OFF DOTTED
017752\047763 DLVH (-46,33) OFF DOTTED
017755\040025 DLVH (-58,37) OFF DOTTED
017760\047772 DLVH (-44,38) OFF DOTTED
017763\040010 DLVH (-36,44) OFF DOTTED
017766\040017 DLVH (34,49) OFF DOTTED
017771\047760 DLVH (37,53) OFF DOTTED
017774\047742 DLVH (9,39) ON 
017777\000000  DHLT 

[larsbrinkhoff]

Of course, if just two vectors are "ON" the display makes sense. It looks like all ARDS short vectors are "OFF DOTTED".

It looks like there might be an underflow in the X coordinate, perhaps explaining the overly long line.

[larsbrinkhoff]

The SHTVCT subroutine in SSV 22 is wrong. It sets 40000 in the second long vector word, intending a solid visible line. But that's dotted invisible. Fixing to to 20000 gives us this, which is an improvement.

[larsbrinkhoff]

The other SSV 22 bug is that it doesn't mask ARDS short vector characters with 77. Fixing that I get the right picture. It's still susceptible to crashing, possibly when a partly inserted Imlac long vector instruction is executed.

[larsbrinkhoff]

Fixed in #1875.