ARDS mode does show a few wrong vectors in chain.pic
rricharz opened this issue · comments
This appears to be a tek4010 problem. A few vectors go in the opposite direction as to where they should.
@larsbrinkhoff I cannot figure out exactly what the problem with decoding chain.pic is. But what I found is that chain.pic draws vectors by calling first POINT followed by either a LONG or SHORT vector. Things go wrong when POINT is not called before drawing a vector. Then it draws the vector from the wrong starting point (as it should from the end of the previous vector drawn). Why the decoder thinks that POINT is not called sometimes I do not know. It is possible that you are right insofar as that some POINT control characters could be missing because this file is not properly converted from its.
I will leave this open as a problem which I cannot solve. Is there a tool which converts those ITS files properly to standard text files?
I will make such a tool.
It would be possible to identify one of the failing POINT commands, and compare against the corresponding characters when viewing the file in ITS. But maybe we should just try the tool (when I have made it) and see what happens.
Look at this:
failure.txt
One byte seems to be missing at 1074. Unfortunately this is not the first error. Now that I see what's happening one could identify the problems with a check for a premature exit of POINT.
Maybe this is the correct input, and POINT should still draw using the three input bytes. I don't remember seeing this case explicitly documented. If missing bytes are treated as zeroes, it could still draw something.
Definitely not documented, but possible. It could well be that the high y is 0 there. I will try that. The tek also skips such bytes, but has an improved way to identify what‘s skipped.
I compared your failure.txt against the file as seen in ITS. Indeed there's a byte missing.
Tek4010: 035 115 145 100
ITS: 035 177 115 145 100
The problem is that the 115 seen by Tek4010 is actually 315 stripped off its top bit. 315 decodes to 177 115.
Yes, I found exactly the same thing. The 0177 is missing. The 0115 0145 0100 are ok. If I just insert a 0177 there (0177 0115 0145 0100), the vector is properly drawn.
Now, tek4010 strips off bit 8 (tube.c line 167), which is the parity bit, and treats the char as a 16 bit integer. With that bit, 0177 is 0377 (or hex FF). That tells us something! Somewhere, this is stripped off. As far as I know "cat" is not the culprit. It can be used to make copies of binary files.
"The problem is that the 115 seen by Tek4010 is actually 315 stripped off its top bit. 315 decodes to 177 115"
No, I don't think so, the 0115 is ok. The problem is that 0177 (or 0377 with bit 8) is missing.
The files are encoded in a special way. 315 decodes to 177 115.
So how do we fix the problem?
I'm making a tool to decode the files and write plain ASCII output.
The ARDS files in the proper ASCII format for tek4010 are now available at https://github.com/larsbrinkhoff/ards-files