[MinnowBoard] GSoC-2015 WITCH-on-a-Board

Anders, David david.anders at intel.com
Wed Mar 18 01:01:53 UTC 2015


1)    The overall of creating the emulator is to have a very fundamental understand of the architecture so that in the future a hardware replica can be created. With that in mind, we want to create the emulator as close to the internal functionality of the original WITCH. Because so many things are not know about the WITCH, we completely expect to discover aspects of the design while working on the emulator. So to answer your question: we want to be as close as possible to the original implementation.

2)    The WITCH uses several different I/O devices. First being punched paper tape readers. Once real tape readers are available and can be attached to the minnowboard max, the emulator should be able to support reading from the. In addition, there are two output devices, including a teletype printer and a punch paper tape printer. These too should be coded in such a way that they could either be simulated hardware or real hardware connected to the minnowboard max.

3)    This is something we are going to need to decide on prior to beginning the project.

4)    As stated above, we’d like to understand the architecture as much as possible so simulating the pulses is important to the overall design.

5)    Indeed we attempted visualize the dekatrons as part of the first emulator, however we found that it filled up the display pretty quickly. If we can get something together that is visually small enough and still provide valuable information, it is acceptable.

Dave Anders

From: elinux-MinnowBoard [mailto:elinux-minnowboard-bounces at lists.elinux.org] On Behalf Of Uros Tesic
Sent: Tuesday, March 17, 2015 6:44 PM
To: elinux-minnowboard at lists.elinux.org
Subject: Re: [MinnowBoard] GSoC-2015 WITCH-on-a-Board

Sorry for bothering you again, but I started writing the proposal, and I have a few questions.

1) The paper describes steps on the higher level (eg. implement division by chain subtraction). Are there any rigid rules that have to be followed (eg. surviving flow diagrams from the WITCH design stage), or we can use the paper as the guideline and implement WITCH according to that (improvise based on more modern architectures)?

2) As for the input-output, in the project you say that the abstract classes should be implemented so that later actual hardware can be connected to WITCH. What are the concrete IO systems WITCH should support at the end of GSoC? I was thinking file IO for testing. Other IO types can easily be reduced to file IO. Should IO system run in its own thread/s?

3) Should the control unit be implemented in software, or virtual hardware?

4) Should trains of pulses be shown, or sending a number they represent down the line object is enough?

5) You mentioned that hooking a simulator to the GTKWave should suffice. As the goal of this project is educational, I was thinking (if there is enough time) of making GUI in eg. QT. I am artistically challenged, but drawing lines and circles should suffice for Dekatrons.

Uroš Tešić
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.elinux.org/pipermail/elinux-minnowboard/attachments/20150318/a995c6bc/attachment.html>

More information about the elinux-MinnowBoard mailing list