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

Jeremy Bennett jeremy.bennett at embecosm.com
Thu Mar 30 10:51:53 CEST 2017


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 27/03/2017 21:32, Hatim Kanchwala wrote:
> Hello,
> 
> 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.

Hi Hatim,

I look forward to seeing your finished proposal. I believe the
deadline is Monday. We are happy to review a draft of anyone's
proposal if that would help.

> 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/ 
> (c) 
> http://www.instructables.com/id/DIY-Paper-TapePunch-Card-Maker-and-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 
> https://lists.librecores.org/pipermail/discussion/2017-March/000290.html).
>
> 
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 proposal.

I like the ideas you discuss here. The use of a standardized interface
will be a good one.

> 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?

We'll make hardware available  to students who request it, which will
be a MyStorm board.

> 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 hardware-savvy! 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.

This is interesting, but definitely out of scope. We are explicitly
looking for hardware re-imaginings. We want  to get across the idea
that EDSAC was something physical. Even if we don't have valves
readily available today, we can use modern technology to recreate some
of the hardware experience.

> 4. Could someone please ask Andrew to reply with his ideas about
> how to model mercury delay lines? In an earlier mail 
> (https://lists.librecores.org/pipermail/discussion/2017-March/000291.html)
>
> 
you mentioned about it, and I have been waiting since to discuss ideas
> further

I've sent him a separate 1:1 message asking him to post the idea here.
This should not hold up your application - just note that you are
exploring ways of replicating the functionality using modern electronics.

> 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.

I believe the deadline is Monday, so don't delay. I should be able to
review any draft tomorrow (Friday) UK time.
> 
> Looking forward to hearing from you soon. Thank you for your time.

We look forward to seeing your proposal.

Best wishes,


Jeremy
> 
> 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
> 


- -- 
Tel:     +44 (1590) 610184
Cell:    +44 (7970) 676050
SkypeID: jeremybennett
Twitter: @jeremypbennett
Email:   jeremy.bennett at embecosm.com
Web:     www.embecosm.com
PGP key: 1024D/BEF58172FB4754E1 2009-03-20
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAljcxykACgkQvvWBcvtHVOEtFACfaWL/f8XYlMHxuFPldUEqhEJD
I8cAnjvWYc/RJt+quVFCI4ZMR9NR5rkZ
=RcI+
-----END PGP SIGNATURE-----


More information about the Discussion mailing list