Add support for I/O devices

[veeara282]

Our class is using Jade to design a simple computer and we'd like some way to use an I/O device such as a keyboard or monitor.

[veeara282]

Hello Derek, I was thinking more along the lines of a circuit component that simulates a keyboard or screen. Is that more doable? *Aidan Fitzgerald* Executive Director, Coding it Forward Cornell Cornell Engineering 2020 LinkedIn <https://www.linkedin.com/in/aidan-fitz> · GitHub <https://github.com/aidan-fitz> · Blog <https://aidan.rocks/>

…

On Mon, Mar 6, 2017 at 12:55 AM, Aidan Fitzgerald ***@***.***> wrote: ---------- Forwarded message ---------- From: drhodes ***@***.***> Date: Sat, Mar 4, 2017 at 11:20 AM Subject: Re: [6004x/jade] Add support for I/O devices (#7) To: 6004x/jade ***@***.***> Cc: Aidan Fitzgerald ***@***.***>, Author < ***@***.***> Hi Aidan, my name is Derek Rhodes, I'm a community TA at Edx helping with 6.004x. I know you'd probably like to hear from Prof. Terman about this feature request. I hope you and he will forgive me for chiming in here if my response is not appropriate and inaccurate, but I think your idea is great and I've given it some thought. This poses some significant technical challenges, let me try to explain as I've recently tried to drive a VGA display with an FPGA. You may already know the following: on one end the display will be listening for a pixel clock running at 25MHz, on the other end, in the browser, where JADE lives, some mechanism will required to drive that 25MHz signal. So what?! Right? Our machines run at GHz. Yes, but js engines stop the world for garbage collection with delays on the order of milliseconds. Maybe a FIFO buffer would help? But it doesn't stop there. The operating system would have to be in real time mode, is this available on consumer licensed windows or mac. I know it's possible with linux, but even then, are web browsers going to play nicely? These days they spawn and run multiple processes as a matter of course. So, if somehow those challenges were met, there's still the issue of communicating from the browser out to a port. Maybe WebUSB fits the bill?, https://wicg.github.io/webusb/? Alright, now there's a FIFO'd VGA signal output on a USB using a serial protocol that would need to be decoded and converted with a digital to analog converter. And then with some luck ... Video! Now the question is, does the JADE software architecture support driving signals at all? I think the answer is no. If support for driving external hardware is seriously considered, then it makes sense to support more than just VGA displays - that means plugins, which I don't think are supported yet either. Scaling back the scope and still achieving the spirit of the feature request, how about an embedded OpenGL/Canvas context that simulates a 320x240 LCD display? This would still call for a plugin architecture, but that would mean the keyboard interface could run through a plugin too. This opens up audio and whatever else people can dream up. But still, even this idea represents a ton of work and depends on code that does not yet exist. Please know that I have no control over this project and that what I may have said may be inaccurate. But, I also think it would be great to have some sort of I/O available aside from the waveform viewer. Regards, Derek. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#7 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACpAUbLRjr5V4AMS8ec_rfkolfT6PXAKks5riY88gaJpZM4MRLV8> .

[drhodes]

More doable, yes! However there are quite a few undocumented usability
issues that I would imagine take priority over the change required to
introduce the display/keyboard features, which may not seem
overarching, but do introduce complexity in the code base. Amazingly,
for what JADE does, it is still comprehensible by a single
person. That's a property I think everyone in the JADE community can
appreciate, and it should be guarded.

Here's the issue, a single custom component, such as a small simulated
LCD display may not seem to introduce much complexity. Would it
require pulling in any libraries? How to guarentee modularity? It's a
slippery slope. All well intentioned features like the LCD display,
which could arguably add immediate appeal to the project might in the
long run be the very thing that undermines future progress on things
like wire-type inference.

For this reason, I think a plugin system is the way to go. Looking at
Blender, Audacity, Ardour.. Plugin authors have autonomy and are free
to hack away without much worry about breaking things. There's no
reliance on a central authority for deciding features. As a result the
JADE code base can remain focused on central ideas: simulation and
intuitive schematics, while plugin writers take responsibility for handling
their dependencies and are free to publish their projects at will.

What do you think?

[veeara282]

Yeah, I think a plugin architecture could work. I think a circuit editor lends itself well to object-oriented design; are the components objects? Adding a new type of circuit component would entail creating a prototype object that implements a certain API—for example, the inputs could be specified by a list of strings indicating property names, and the outputs could be specified by a list of functions.

[drhodes]

Are the components objects?

In the language sense, yes. In the architectural sense it really
depends on the scope the plugin API. It's conceivable that parts of
JADE, such as the waveform viewer could be extracted and turned into a
plugin. Reducing the core to essentials would help define a boundary to
prevent feature creep.

On the other hand, the waveform viewer as a plugin would require
access to simulation data raising the hazard of plugin authors
acquiring shared mutable state, which may mean copying/allocating
simulation data to prevent that.

A smaller plugin API could be confined to components.

But jade.model.Component doesn't have access to the canvas routines needed
to paint custom oscilloscope features. (edit: I could be wrong here) Maybe part
of the plugin interface could define a set of draw routines itself with
built-in event handling. That would prevent plugin authors from reimplementing
a lot of functionality and promote consistent look-and-feel across plugins themselves.

Adding a new type of circuit component would entail creating a
prototype object that implements a certain API—for example, the inputs
could be specified by a list of strings indicating property names, and
the outputs could be specified by a list of functions.

From schematic_view.js,

470:    Wire.prototype = new jade.model.Component();
744:    Ground.prototype = new jade.model.Component();
786:    Vdd.prototype = new jade.model.Component();
827:    Jumper.prototype = new jade.model.Component();
861:    Port.prototype = new jade.model.Component();
976:    Text.prototype = new jade.model.Component();
1061:    Memory.prototype = new jade.model.Component();

I think you're talking about a more generalized component constuctor
that could be used to instantiate any of the above concrete components.

And, I think this is example of a minimal component and allows for all
schematic activities, event handling, etc.

744:    Ground.prototype = new jade.model.Component();
745:    Ground.prototype.constructor = Ground;
746:    Ground.prototype.type = function () { return 'ground'; };
754:    Ground.prototype.load = function(json) {
766:    Ground.prototype.svg = function(diagram) {
775:    Ground.prototype.netlist = function(mlist, globals, prefix, mstack) {

So, additionally, there would need to be the concept of plugin.draw_frame()
for any sort of animation, like LCD_update_screen()... But, I'm still trying to grok
the code base, so, please take what I'm saying with a grain of salt!