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.



















(Designed for 640 x 480, 800 x 600 or 1024 x 768 Resolution) a 'POPUP' and 'FRAMES' free zone
Legal Info = "Copyright Shedland Software design"
All Images, Graphics, Sounds, Applets, Text, JavaScripts, or Anything Else contained within the Shedlandrobotics WebSite, unless otherwise noted or documented, are the Property, Trademark, or Copyright of Shedlandrobotics 2004 and may not be Copied, Reused, Sold, or otherwise Distributed without permission. So please ask! (Web Masters please note) ) This site is updated monthly and its contents are liable to, and will change. Links to and from the site are both welcome and encouraged. However we consider it a common decency to seek permission first. If we know a link exists, we will endeavor to not make any changes, or notify you of any changes to your links.