[Librecores Discussion] GSoC: EDSAC Museum - report on possible I/O model, queries and an idea

Hatim Kanchwala hatim at hatimak.me
Mon Mar 27 21:32:35 CEST 2017


The GSoC application period is open and I am preparing a proposal to
submit. AFAICT, the one iron goal of this project is to "expose these
historic computers to a new generation". So, IMHO, I believe every
idea/decision for the project should be weighted against this ultimate
benchmark. With that in mind, I'd like to present some ideas/reports
particularly regarding the I/O modelling of EDSAC. I also have a few
queries regarding the project.

1. I/O model of EDSAC
As you will already know, EDSAC used 5-track paper tape reader for input
and Creed teleprinter for output. In the spirit of faithfully
replicating the machine, we should ideally be using (more or less) the
same mechanism. To realise it, I found the following useful resources -
(a) http://hackaday.com/2014/05/02/reading-paper-tapes-from-scratch/
(b) http://makezine.com/2013/05/14/building-a-punchtape-reader/
Let's analyse these resources. The mechanism to "read" the punch tape in
each of these implementations is to have an index punch in addition to
the data-holding holes on the tape. Each index hole triggers a "read",
activating the photo-sensors on one side. On the other side there are
(infrared) LEDs. An Arduino or a Teensy is used to accomplish this and
the housing requires some mechanical construction.
Now a common dependency for each of these is the assumption that a valid
punch tape is present, or can be prepared. Arguably, this is not
necessarily an easy task (for a learner from the new generation). In
(c), they use Silhouette Portrait, which is basically a cutter. It costs
USD 150+.
We must realise that the solutions proposed above render the project
inflexible in that the unavailability of a single component makes
running the FPGA replica infeasible. In order to adhere to our ultimate
benchmark, we must make our implementations flexible to accommodate
variations in I/O modules, giving them more of a plug-and-play type
nature so that the (un)availability of components at user-end is not a
barrier. In order to satisfy this, I had proposed standardising of I/O
communications into and out of the FPGA module (please refer
Here I'd like to extend that idea in the following way -
Use slightly modified principle of "reading" a punch tape as described
above using an Arduino/Teensy/RPi. The Arduino/Teensy/RPi communicate
with FPGA using standardised protocol. The modification is that instead
of having a punch tape, a paper strip with darkened circles (in lieu of
holes) need to be fed in. As part of the project, I can write a utility
that generates a PDF that has proper lines of darkened circles (just
like the punch tape would have holes). The PDF can be printed, the sheet
trimmed to the proper size, and then fed into our DIY reader. The
utility takes as input a file containing the program to run on EDSAC.
The utility is sort-of a compiler. Please refer here
(http://grathio.com/2009/08/dice_reader_version_2/) for a project that
reads "darkened circle" using the above described infrared sensor principle.
The beauty of this approach is that we can have very close to original
mechanism of input without sacrificing flexibility. I think "darkened
circles" are a great trade-off in place of "punched holes"! Let's call
this Input Variation 1 (IV1). We can develop a CLI to our "compiler" to
accept switches on the command line governing which form of output to
produce. That way we can have more Input Variations, like - one switch
produces output that is flashed onto an Arduino, which in turn is
connected to the FPGA board via SPI bus. Call it IV2. IV3 can be a
Python script that is run on an RPi.
Output can be dealt with in similar fashion. The Arduino flasher or the
Python script can configure Arduino or RPi to properly accept and route
the output from the FPGA, to, say an array of LEDs representing various
tanks, or to, say an internal buffer, or in the case of RPi to an
attached monitor (or VNC client).

In this rather long point, I hope I have been able to express myself and
demonstrate the flexibility offered by standardisation without
sacrificing faithfulness to original mechanisms. Use of specific
hardware shrinks our prospective user-base, but having flexibility only
lets the user-base grow, which serves our ultimate benchmark.
Let me know if this idea sounds exciting to you (it is pretty exciting
for me), so that I can develop it even more and include it in my final

2. Availability of hardware
Will the student be supplied with an FPGA board? If yes, which one will
it be? What about any other hardware that might be required throughout
the project?

3. New idea - possibility of a browser-based JavaScript emulator for EDSAC
In addition to a hardware replica of the EDSAC, I was thinking we could
also make a browser-based JavaScript emulator for EDSAC. I looked around
for something similar and came across this
(https://github.com/nishio/EDSAC-on-browser). The demo link on that repo
is broken. AFAICS, the author, a Dr Nishio Hirokazu from Japan, has not
fully emulated the original machine. I have written to him already
seeking more information on the state of his work. I am currently
awaiting his reply. Putting up a browser-based emulator lets a learner
quickly try out stuff right in the browser. This will extend our
user-base further to those from the new generation who are not so
I have prior experience with Node.JS and hosting web apps over the cloud
using AWS/Heroku. From the preliminary timeline that I have chalked out,
I think I could squeeze in a JavaScript emulator as a sub-project.
The folks at Cambridge built a simulator that should run in the browser
(http://www.cl.cam.ac.uk/events/EDSAC99/simulators/india/applet/), but
the technology used is outdated and most modern browsers don't have
Java/Applet support any more. So, as of now, I don't think there exists
a usable browser-based emulator for EDSAC.

Please let me know if you guys find this idea interesting enough to
pursue, so that I can develop this idea in further detail, in addition
to the FPGA simulator. I'll let you know if I receive any word from Dr
Nishio Hirokazu.

4. Could someone please ask Andrew to reply with his ideas about how to
model mercury delay lines? In an earlier mail
you mentioned about it, and I have been waiting since to discuss ideas

In the coming days, I will be preparing a detailed proposal worthy of
consideration. I am keenly interested in working on this project and I
hope my proposal convinces you to grant me an opportunity to work on it
this summer.

Looking forward to hearing from you soon. Thank you for your time.

Have a good day!

Hatim Kanchwala
Undergraduate, Electrical Engineering
Indian Institute of Technology Patna
hatim at hatimak.me, hatim.ee14 at iitp.ac.in (University)
(+91) 966 5154 719

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.librecores.org/pipermail/discussion/attachments/20170328/60cfa2db/attachment.sig>

More information about the Discussion mailing list