{"comment":{"url":"https://api.github.com/repos/simh/simh/comments/9337384","html_url":"https://github.com/simh/simh/commit/b198e13c09b784e37dcdfa334d3213dc4f09b850#commitcomment-9337384","id":9337384,"user":{"login":"jguillaumes","id":1552242,"avatar_url":"https://avatars.githubusercontent.com/u/1552242?v=3","gravatar_id":"","url":"https://api.github.com/users/jguillaumes","html_url":"https://github.com/jguillaumes","followers_url":"https://api.github.com/users/jguillaumes/followers","following_url":"https://api.github.com/users/jguillaumes/following{/other_user}","gists_url":"https://api.github.com/users/jguillaumes/gists{/gist_id}","starred_url":"https://api.github.com/users/jguillaumes/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jguillaumes/subscriptions","organizations_url":"https://api.github.com/users/jguillaumes/orgs","repos_url":"https://api.github.com/users/jguillaumes/repos","events_url":"https://api.github.com/users/jguillaumes/events{/privacy}","received_events_url":"https://api.github.com/users/jguillaumes/received_events","type":"User","site_admin":false},"position":null,"line":null,"path":"","commit_id":"b198e13c09b784e37dcdfa334d3213dc4f09b850","created_at":"2015-01-19T11:01:01Z","updated_at":"2015-01-19T11:01:01Z","body":"Hello Mark, Stefano and everyone involved in this discussion,\r\n\r\nThe idea of providing an API is, of course, a very good thing and will\r\nallow people to contribute to the project without having to know (too much)\r\nabout the simh internals. But I'd suggest to add another layer of\r\nabstraction to make things even easier: provide a standard communications\r\nprotocol for \"detached\" panel implementations.\r\n\r\nThe idea is to build upon the API to make a piece capable of communicating\r\nwith external processes (in the same machine where the simulator is running\r\nor thru the network) implemented in whatever platform is available (ie,\r\njava, or .NET, or python). It should be necessary to establish a generic\r\n\"PANEL block\" format, which would be sent to the \"panel server\" using UDP\r\n(or TCP, but I'd suggest UDP to minimize the impact in the simulator\r\nitself). In the same way, a \"response block\" should also be defined,\r\nallowing the panel implementation to send commands to the simulator.\r\n\r\nThat basic implementation would also be a \"reference implementation\" for\r\nthe API, allowing the SIMH developers to test the PANEL API implementation\r\nin each simulatior without needing to have a real, working PANEL.\r\n\r\nOnce the protocol is defined and the data blocks are standarized, it would\r\nalso facilitate the building of other transports (ie, serial\r\ncommunications, or GPIO) using the same framework.\r\n\r\n\r\n\r\n2015-01-19 9:03 GMT+01:00 Stefano <notifications@github.com>:\r\n\r\n> Sounds good to mee too.\r\n>\r\n>\r\n>\r\n> Stefano Bodrato\r\n>\r\n> Torino - Italy\r\n>\r\n>\r\n>\r\n>\r\n> Date: Mon, 19 Jan 2015 00:00:27 -0800\r\n> From: notifications@github.com\r\n> To: simh@noreply.github.com\r\n> Subject: Re: [simh] FRONTPANEL: Initial API description (b198e13)\r\n>\r\n> The concept is architecturally sound, and it is IMHO the 'right' way to do\r\n> it.\r\n>\r\n> Jordi Guillaumes i Pons\r\n> Barcelona - Catalunya - Europa\r\n>\r\n> El 16/01/2015, a les 21:41, Mark Pizzolato <notifications@github.com> va\r\n> escriure:\r\n> > Hi Leo,\r\n> >\r\n> > I'm sure it is missing pieces and/or various arguments to some of the\r\n> calls I defined.\r\n> >\r\n> > Meanwhile, the vision here is that any number of external programs can\r\n> exist which can provide a front panel interface to a particular simulator.\r\n> This program might provide a GUI display which can be interacted with or it\r\n> might somehow act as a bridge to physical hardware which is the original or\r\n> a model of the original hardware front panel. In the GUI case, folks could\r\n> write per simulator dedicated front panel implementations OR a single\r\n> program could, in theory, exist which had configuration files that\r\n> contained enough descriptive information and bitmap images to provide front\r\n> panel interface for many fundamentally different simulators.\r\n> >\r\n> > At some point there will be at least one additional variant of the PANEL\r\n> constructor API. One which comes to mind now is one which might provide a\r\n> front panel for a device (or set of devices on a simulator). The\r\n> implication here is that multiple PANEL objects can exist concurrently\r\n> (only one controlling the CPU). Each with different probe (REGISTER) and\r\n> timing attributes. Such an additional concurrent PANEL object might provide\r\n> blinking lights on a disk device, or spinning reels on a tape device,\r\n> etc...\r\n> >\r\n> > So as for interaction...\r\n> >\r\n> > Using the current PANEL constructor, the panel program starts and it\r\n> creates the PANEL object which starts the simulator process. Depending on\r\n> the front panel design, the \"start\" state might be with the CPU powered on\r\n> or might need some user input on the panel to turn on the power switch.\r\n> Maybe the power switch actually invokes the PANEL constructor. Once the\r\n> PANEL is constructed, the front panel program describes what information it\r\n> is interested in seeing changes for (i.e. what REGISTERs are to be\r\n> displayed). The front panel program can either poll for state changes\r\n> whenever it is interested in updating its view by calling\r\n> sim_panel_get_registers() OR it can setup a callback with\r\n> sim_panel_set_display_callback. If a callback is defined, a best effort\r\n> will be made to update the local copy of the register data and call the\r\n> callback routine when this update has happened (this will only happen when\r\n> the simulator is actually running).\r\n> >\r\n> > When a front panel program has some input which it wants to affect the\r\n> simulator with, one of the APIs like sim_panel_exec_run or\r\n> sim_panel_exec_halt or sim_panel_exec_step would be called. Additionally\r\n> there also needs to be a sim_panel_set_register API to allow a panel to\r\n> change some register contents.\r\n> >\r\n> > Please poke holes in this idea or suggest missing pieces.\r\n> >\r\n> > Thanks.\r\n> >\r\n> > Mark\r\n> > —\r\n> > Reply to this email directly or view it on GitHub.\r\n> >\r\n> —\r\n> Reply to this email directly or view it on GitHub.\r\n>\r\n> =\r\n>\r\n> —\r\n> Reply to this email directly or view it on GitHub\r\n> <https://github.com/simh/simh/commit/b198e13c09b784e37dcdfa334d3213dc4f09b850#commitcomment-9335041>\r\n> .\r\n>\r\n\r\n\r\n\r\n-- \r\nJordi Guillaumes i Pons\r\nBarcelona - Catalunya - Europa"}}