Sorry about the double negative.
I was in a hurry as I was supposed to drive over the hill to Santa Cruz for a
couple hours.
"It is unlikely that no current day OCR will produce an error free listing."
Should have read:
"It is unlikely that any current day OCR will produce an error free listing."
I agree with Chuck. A computer code listing cannot tolerate a single mistake in
a number. I recall recovering data from cassette tapes were the tape stuck to
the capstan and got folds. Most of the code was in BASIC so had quite a bit of
redundancy for the program flow. Luckily, there were few damaged segments with
numeric values. The tapes had check sums that helped quite a bit. It is not so
in typed listings.
As I stated, the code I recovered for the 4004 code would have been lost if I'd
not understood the purpose and run the simulation of the code, stopping to see
what alternate values did to the execution of the code. It was over 3K of code.
Quite a bit for a 4004. It was intended to be loaded into 13 1702A Eproms.
There were over 30 points in the code that needed to be resolved.
Dwight
________________________________
From: cctalk <cctalk-boun...@classiccmp.org> on behalf of dwight via cctalk
<cctalk@classiccmp.org>
Sent: Sunday, January 23, 2022 10:06 AM
To: cctalk@classiccmp.org <cctalk@classiccmp.org>
Subject: Re: Typing in lost code
It is unlikely that no current day OCR will produce an error free listing.
It is possible to train an AI to do this but it requires specific training. It
must be on the specific machine code and on the same format. Any generic OCR
will have many errors if the text is hard to read.
The final product must include notes as to things it is not sure about or it
would be useless. I recovered a listing for the 4004 processor that was printed
on a ASR33 with ruts on the platen. The right hand 1/4 of letters were missing
at several locations across the page. Letters such as F and P, as well as 0 and
C were often not well enough printed to distinguish.
Luckily F and P were often in context relatively easy to determine but 0 and C
were often use to describe a HEX number. Unlike the text on this page, the
differences were not always obvious. The final result in working code required
noting which things were possibly one or the other. The only way to determine
most of these was by using a simulation of the code. Most all the cases for the
0 vrs C were that it was a 0, as these were for initializing a pointer base
number ( context of usage ). In one case it was only through the simulation was
I able to determine that it was really CC and not 00.
Marking locations of uncertainty was essential to determine where to check the
program code context.
Any OCR that doesn't include possible options and that isn't trained on that
particular code is worthless.
Dwight
________________________________
From: cctalk <cctalk-boun...@classiccmp.org> on behalf of Noel Chiappa via
cctalk <cctalk@classiccmp.org>
Sent: Sunday, January 23, 2022 9:31 AM
To: cctalk@classiccmp.org <cctalk@classiccmp.org>
Cc: j...@mercury.lcs.mit.edu <j...@mercury.lcs.mit.edu>
Subject: Re: Typing in lost code
> From: Gavin Scott
> I think if I had a whole lot of old faded greenbar etc. ... Someone may
> even have done this already
See:
https://walden-family.com/impcode/imp-code.pdf
Someone's already done the specialist OCR to deal with faded program listings.
Noel
