source: t29-www/en/development-projects.php @ 485

Last change on this file since 485 was 485, checked in by heribert, 10 years ago

Anelex-Gamma10 Verbindung gestrichen

  • Property svn:keywords set to Id
File size: 10.1 KB
2        $seiten_id = 'entwicklungsprojekte';
3        $version = '$Id: development-projects.php 485 2013-12-28 23:28:14Z heribert $';
4        $title = 'Development Projects';
6        require "../lib/technikum29.php";
9<h2>Development Projects</h2>
11<p>This page lists some of our development projects where old hardware meets modern
12computer equipment. All projects are selfmade, with partly enormous hardware and
13software efforts, like routed PCBs, kernel drivers and microcontrollers.
17<h3><a name="papertape"></a>Paper tape processing with contemporary computers</h3>
19<p>We were often in a situation when some data stored on a punched paper needed
20to be sent over long distances. Having Internet access and e-mail, that's no matter
21for todays computers, once you can read in paper tapes. The other way around,
22punching new or modified data on punched papers is also a frequent need in our daily
23business. <br/>Therefore we initiated the <b>Paper Tape Project</b>, having the
24pronounced goal to handle paper tapes with contemporary computers, that is, to
25read, change and write (punch) them.</p>
26<p>We use comparatively new punched paper devices that already feature a Centronics
27interface at TTL level. Unfortunately the devices (in detail: reader
28Ghilmetti FER 201, puncher FACIT 4070) didn't yet implement the Centronics
29common standard from the 1970s (officially standardized as IEEE-1284 not until 1994),
30therefore simply connecting those devices with a standard parallel port printer cable
31won't do the job.</p>
33<div class="desc-left">
34   <img src="/shared/photos/rechnertechnik/fer201.jpg" width="239" height="148" alt="Photography of the paper tape reader Ghilmetti FER 201" />
35   <p class="bildtext" style="width:239px;"><b>Ghilmetti FER 201</b> reader with framework for reading zig-zag tapes</p>
38<p>The very first step was to read the manual carefully to assemble a specially wired
39cable to connect the punch card device with the parallel port of a PC (commonly known as
40"LPT port", a standard port on PC motherboards just a few years ago). Since the devices
41don't implement the standarized hand shake, the second step was to implement a suitable
42driver to emulate the right communication behaviour for the punch card devices.</p>
44<p>Development started on the free GNU/Linux Operating System where we used the ppdev
45framework of the Linux 2.6 kernel series to program a user space driver in the programming
46language C with a little effort compared to a real kernel space driver.</p>
47<div class="desc-right">
48   <img src="/shared/photos/rechnertechnik/facit4070.jpg" width="192" height="313" alt="Photography of the paper tape puncher FACIT 4070" />
49   <p class="bildtext" style="width:192px;">The legendary puncher <b>FACIT 4070</b></p>
51<p>The parallel port consists of three 8-bit hardware registers: a bidirectional data
52register, a control register and a signal register. Since paper tapes are made of
538-bit words (octetts), we just connected these eight bits on the data register to save
54them directly to one byte in the computer. Using the control and signal pins, we could
55implement a interrupt (device cycle) driven communication, since the status register
56features one interrupt enabled bit (strobe). Our devices punch at 80 chars/sec and read in
57250 chars/sec, so even older PCs can easily run the driver programs.<br>
59As already told, there's not really the question how to model punched papers on
60computers, since they use the same word length (8 bit) and computer files are
61conceptually the same as paper tapes: byte arrays. A 250 byte binary file therefore
62represents a 250 chars long punched paper. Thus processing punch card files
63with Unix command line tools or hex editors is very easy. To speed up the workflow,
64we wrote some simple perl scripts to label paper tapes. Afterwards we wrote a
65graphical editor, called "Paper Tape Editor", where binary files could be visualized
66and directly edited as paper tapes on the screen. This program was written in C, using
67the Gtk+ toolkit. After writing drivers for the Microsoft Windows Operating System,
68this program was extended to the "Paper Tape Suite" to read, edit, save and punch
69paper tapes graphically. That way every possible procedures with paper tapes can be
70performed with ordinary PCs.</p>
72<p>You can get further details with a lot of documentation material on the homepage of
73<a class="go" href=""
74>The Paper Tape Project</a>. The source code was released as open source can be checked
75out from the <a
77subversion repository</a>.</p>
79<h3><a name="punchcard"></a>Reading punch cards with contemprary computers</h3>
80<p>There is an historical storage media that is even more important than paper tapes:
81Punch cards. They were the one of the pillars of early mass electronic data processing
82and were used for saving data and program executables. Based on the <i>Paper Tape Project</i>,
83we started the <i>Punch Card Project</i> with the similar target of reading, editing and
84punching punch cards.</p>
86<p>When connecting these small paper tape devices (shown above) directly to modern
87personal computers via the parallel port ("LPT"), we noticed they were too slow for
88communication. Having modern GHz powered high end computers, how's that possible?
89<br/>The real cause for this performance is the software and hardware design of
90contemporary personal computers. They are conceptually designed for processing huge
91amounts of data and high speed calculations, but no more for short latencies with I/O
92handling. Actually, all time-ciritcal parts in modern high speed communication
93protocols (like USB, Ethernet, Firewire, etc.) are implemented in hardware. Software,
94on the other side, features more and more abstraction levels, so there's no more
95real-time operation even at kernel space.
96<br/>There are real-time operating systems, indeed, but by using such an operating
97system, the computer would be dedicated to communicating to the device. This is not
98neccessary. There is a (not even young) branch of computers which perfectly match
99all the criteria mentioned: Low latency, fast I/O, fully deterministic. Microcontroller
100are these low cost processors, a single chip featuring a lot of peripheral equipment.</p>
102<div class="desc-left">
103    <img src="/shared/photos/rechnertechnik/documation-m200.jpg" width="300" height="215" alt="Photography of the Documation M200 pneumatically Punch Card Reader" />
104    <p class="bildtext" style="width:300px;"><b>Documation M200</b> card reader (this one implemented by WANG)</p>
106<p>We are using an ATmega microcontroller made by Atmel AVR. Most of the 40 digital I/O
107pins are directly wired to the electrical Input/Output of the punch card device
108<i>Documation M200</i> (featuring a pneumatic card feed). On the other side of the small
109development board there is the RS232 port ("serial port"), communicating to the computer.
110This small board is actually so small that it fits right into the device's cabinet.
111Running with 8&nbsp;MHz, the microcontroller is easily capable of hard real-time
112communication (300 cards/minute) and serving 4kB RAM, there is enough space for buffering
113a lot of punch cards until they can be sent to the virtually lazy computer via RS232.
114This is a quite old industry standard for serial data transportation, but since its very
115easy and robust, RS232 is quite perfect for such an interface. Using contemporary USB
116was no option since it's very complex and bulky (above all, there are cheap RS232-to-USB
119<p>We wrote a program for the microcontroller that implements the device driver to the
120punch card device. Now having an electrically specified interface to the computer (RS232),
121how should we communicate to the computer (automatically)? Furthermore, in which way
122should we represent a punch card with binary digits (zeros and ones)?
123<br/>While modeling 8 bit paper tapes into 8 bit bytes is trivial, a punch card, having
12480 columns with 12 rows each, is much more complex. Therefore we wrote the
125<a href="" class="go">PC Documation M200 µC Serial Communication Protocol</a> that defines the
126way how computer and microcontroller shall communicate autonomously. It defines, that
127two punch card columns shall be packed into three octetts, each. This binary format has
128been proposed by the computer sciencist <a href="">Douglas
129W. Jones</a>.
130<br/>For the computer side, we wrote the <i>Punch Card Editor</i>, a program that recieves
131the punch cards from the microcontroller (via the RS232 interface) and visualizes them in
132the graphical user interface. At this step, the text encodings (IBM H9 code, Bull Code)
133can be used to translate between binary punch card data and ASCII text. Thus card decks
134can be read in, modified and saved as files. Of course the comfortable program already
135has the interface for punching paper tapes, once we have selected a device and programmed
136some microcontroller for that job. At this point, there is also another benefit of this
137approach: The program runs on all modern platforms/operating systems (like Microsoft
138Windows, GNU/Linux, Apple OS X, etc. - there just needs to be some RS232 or USB connection).</p>
140<p>You can get further details with a lot of documentation material on the homepage of
141<a class="go" href=""
142>The Punch Card Project</a>. The source code was released as open source can be checked
143out from the <a
145subversion repository</a>.</p>
147<!--  irgendwie schon sinnlos, auf ein deutsches PDF zu verlinken:
148<br/>We've published a german paper <a href=""
149>Lochkartenverarbeitung per Computer</a> (30 pages)
150with an analysis of the problem, modelling and implementation on both microcontroller
151and Computer (there won't be an english translation).</p>
Note: See TracBrowser for help on using the repository browser.
© 2008 - 2013 technikum29 • Sven Köppel • Some rights reserved
Powered by Trac
Expect where otherwise noted, content on this site is licensed under a Creative Commons 3.0 License