Story
Hardware
Software
People
Media
Support
(Future)
Archive
Documents
Emulation
Links-
The ICT 1301 Resurrection Project.
The Document Archive
Technical Documents
New in 2009
Reference Manuals
System Documents
None yet!
Software Documents
None yet!
Project Documents
See below.
Assesing alternatives to the Mark One Human Eye Ball:-
Whilst examining the possibillity of reading old 80 column 'Hollerith'
cards. An investigation into possibilities has been recorded here.
The alternative to reading the cards by eye are limited, a standard
1960's card reader mechanism did the following:- Cards were moved along
a track which passed the cards between a light source and photoelectics
cells, these sensed the perforations in the cards and passsed the data
to decoders to translate the combinations of holes to computer codes
representiing the data encoded in the card.
Simple Huh ? But if you lack the required 1960's reader and cannot
afford the very limited alternatives to read the cards in the 21st
century an investigation into alternatives has to be persued.
One such alternative persued here is to scan the cards on a flatbed
scanner and apart from archiving the images taken, write software to
decode the images and parse them back into both card binary images
of the punched data and use these to produce ascii strings representing
the original contents. This data can then be used in emulators and used
to emulate the original data packs.
So lets dig a little deeper into what the card reader actuallly did
to read those cards. Before the card arrives at the read head all of
the cells are illuminated this gives a condition of ' ALL LIGHT ' once
the leading edge of the card obscures the cells, all of the outputs
from the cells go dark. Timing from this transistion is used to select
the 80 positions relating to the columns of the card.
We can use the same rules by taking the file representing the scan of
each card and start to proccess the data, however before we do we need
to understand the difference between the original Card Reader and a
modern Scanner. The primary difference being that a scanner illuminates
the object to be scanned and works from reflected light as opossed to a
light source the opposite side of the card. The other consideration is
that flat image files have to be used, as data is position dependant
and file compression does not retain this data. The chosed file format
is *.TIFF and its close to the original flat image map.
As such working in monochrome gives only card colour and data colour,
as most cards were of a light colour then the alternative had to be a
black background. And further as cards usually have dark printing on the
face of the card it was decided to scan cards from the back view. If
this was done against a black background, then only area's where a
perforation showed would be black. Areas before the start and after the
card would also be black. This results in an inversion of the original
'All Light' and 'All black' levels of logic and had to be designed into
the scan decoding algoritm.
Using these rules we start to work along the card image checking for
the point where background levels change to card levels this approximates
the leading edge of the card. Data is processed until the trailing edge
of the card is found and the length of the card image is then found.
Using the leading edge and trailing edge references found we can then
compute the positions of the individual columns.
And that in essence was the system used in the prototype software,
cards packs were scanned to a set of image files, then each file was
parsesd into a binary image of the holes in the card , giving a 960
bit data field which could be encoded into the final systems data.
Problems with this version:-
1. The resolution of the scan needed to be at least 300 dpi to ensure
the software could detect the correct aiming point for the center
of each column. This setting only gives nine or ten pixels per
column.
2. Any black marks detected on the back of the card could be translated
into spurious holes and the final output data needed a lot of
nursing and editing before use.
3. The range of card colours is limited and after only two small card
packs were scannned it was obvious that another, attempt was needed.
Using the above outline of the process the next step was to try to
revise the software to improve the card data detection rate and
reliability. The first thing to do was to move to grayscale scans,
giving 256 levels which allowed approximation of the levels of black
and white. Where black could be assigned a level from total black to
dark grey, and white could be assigned an alternative set of values
at the other end of the data value and Intermediate data levels were
assigned as ignored. Scan file size grew accordingly but the Card
binary data and the final ascii files were the same size.
Reliability was improved and at least three card packs were
processed this way. One pack bieng of over 50 punched cards, or
over 4 thousand column punchings the process was long winded as
each card in a pack was hand located, scanned and then the images
files were batch processed to complete the output data files.
Problems with this version:-
1. Black marks on the back of cards are still detected as punchings.
2. It was no longer possible to keep the original scanned images
as file sizes made large demands on storeage.
3. The software is faster than the mark one eyeball, but only just.
The final version has never been fully coded but the solution was
to take even larger scan files which allowed colour to be utilised,
by allowing the software to detect the levels of the primary colours
in each pixel. Working on average figures for card tone and background
tone, the problem of black marks had been eliminated. All that has to
be done was to ensure a very contrasting type of colour between the
card and the backgroud. A very sucessful background colour was a bright
pink tone which made dull cards stand out very clearly. The software
could even detect the average levels in the backgroud colour without
hard coding the levels into the software.
The only problem with this version is that it has never been utilised
fully as the concept of data recovery has moved on to a small hardware
device wwhich connects to a laptop via its Printer port. This device is
called the 'SLO-MO' card reader and uses a full set of read cells and
Led light sources to read the card and then the laptop uses the
techniques developed above to decode the data streams recieved from
the cells.
But that, as they say ' Is another Story '
Rod Brown
2008/11/25 Copyright Shedland Software Design.
