Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New feature : input device #25

Open
msuzenne opened this issue May 2, 2017 · 0 comments
Open

New feature : input device #25

msuzenne opened this issue May 2, 2017 · 0 comments

Comments

@msuzenne
Copy link

msuzenne commented May 2, 2017

Hi Schweigi,

first of all : great thanks for this very nice work ! I use it for computer science teaching, and it s a top tool for learning computer basics :-)
Then : do you plan to add an input device ? It would be marvellous ! Why not an input device with a little buffer, and two memory mapped registers (this would force the stack memory zone to be shifted just by two cells) : a status register for signaling, and a data register for inputed data gathering, each one being one byte large.

The status register bits could be as this :

  • LSB bit : some data is available in the input buffer
  • thus it would simple to test if data is available and doing anything usefull with the inputed data (JNZ for example) the rest of MSB bit could be reserved for any other signaling feature (*)

It could work as follows :
If there are bytes inputed (via the keyboard captured through the web navigator, or via a GUI keypad in the input panel), the status register would be "0x01" else it would be "0x00".
The current first inputed byte in the input buffer would be accessible in the data register, and the rest of the buffer would be visible in the GUI in the "input" pannel
Any "mov" from the data register would then gather the first inputed byte in the buffer, and this byte would be removed from the buffer, and the following byte of the buffer would be available in the data register.

(*) And what about an extensible input device ? It could be structured like this :

  • a panel in the GUI clearly identified in the HTML code as a div with an "id=input-panel" (wiich would let set its inner HTML easily via JS/DOM)

  • a JS callback named i.e. "input-registers-action", called automagically every time a "mov" is targetting the status or data register (moving values from or to these register), with the avent details as parameters :
    -- first parameter : a string signaling the type of register access ("R" for read, "W" for write)
    -- second parameter : a string signaling the register which is accessed ("S" for status, "D" for data)
    -- and a third and last parameter being the value put or read to/from the register

This could enable users to customize the input device as needed, without requiring more work for you, as all the customization would be possible from the JS callback which could analyze the fired event, doing what is needed about the app logic, and finally modify the appearance of the input panel (via innerHTML of the div with "id=input-panel") for presenting the user with the modified state of the input panel.

So it would be possible to emulate a bout all possible input device, even an hard disk controler with a hard disk connected to it, but yes only in PIO mode, but it would be so great enough ;-)

Sorry for this (too ?) long post, and these are just ideas, nothing more, nothing less :-)

Regards.
Mickaël.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant