Support JSON machine definition files

[mihailik]

I want to help with migrating XML to JSON. Would you like that?

My suggestion is that if the machine file is JSON (heuristic check maybe?), then parsing and transformation is implemented by a separate logic.

Specifically, XSL transformation would be converted from a set of instructions written using XSLT language into a set of JavaScript statements.

The premise is to make it work, test — and then convert all XML files into JSON and obsolete the XML support.

For me it would be a good opportunity to get used to the complex parts of the code. The long goal for me is to improve the embedding. Right now I embed pcjs by proxying and polyfilling window, XMLHttpRequest, LocalStorage and a bunch of hackery around it. It sort of works, I can properly embed the whole of PCJS in one file — but it's very kludgy.

So this could be my first step to make embedding work.

Many thanks!

[jeffpar]

It would definitely be nice to support JSON configuration files, so if you're interested in pursuing, that would be great.

You might want to take a look at pcjs -- it's a JavaScript file without a .js extension designed to be run directly from Node (eg, "node pcjs --cmd="load ibm5150.json") and includes some very quick-and-dirty code to parse a JSON file ("ibm5150.json") and mimic the web initialization sequence. It's a headless version of PCjs (no UI), so it's not particularly exciting to use, but I'd like to marry it to a standalone UI framework one of these days.

My main quibble with JSON is that the format imposes annoying restrictions. For example, JSON.parse() barfs on JSON containing comments and hex constants, whereas XSLT couldn't care less.

Something else to be aware of is that PCjs XML files aren't strictly just a definition of a machine's innards. They also determine layout. In other words, the order of the components within the XML is important, as well as XML tags like <control> which do nothing more than define UI elements (buttons, lists of floppy disk images, etc) on the page that machine components can then bind to.

That was the other attraction of using XML: leveraging its similarity to HTML to define both the configuration of the UI and of the machine itself.

Finally, another XML feature to be aware of is that one XML file can reference another. For example, if multiple machines all want to use the same Floppy Disk Controller (FDC) definition, they can do that by using a "ref" attribute (eg, <fdc ref="/disks/pc/library.xml"/>). That eliminates a lot of redundancy, because an FDC component definition defines not only the controller behavior (eg, which disk images to autoload) but also which additional disk images should be available to the machine.

[jeffpar]

I would like to create an automated way of doing this, so that I can start building some Node-based machine test scripts.

For example, I would like to be able to start any predefined machine in the project from the command-line, let it run for so many cycles, and then confirm that the machine's video buffer contains the expected results.

Even better, enable a special testing mode which, among other things, would log all text written to the machine's screen. In most cases, intercepting selected INT 0x10 operations would be good enough.

Longer term, I would like to go beyond text modes to graphics modes, so that a machine configured to boot into Windows could have its screen compared to a snapshot, to verify that it booted properly.

[jeffpar]

Another approach I played with was reading XML files with xml2js. See the PDP11 command-line utility for an example of how that worked. I think at this point, I'm sticking with XML files, for all the reasons I gave above, plus inertia. ;-)

[mihailik]

By the way, Google puppeteer is a viable way to run web page in headless browser, take screenshots, talk back-and-forth between JS in that webpage and the node.js JS invoking the headless browser.

Of course, it's quite a bit heavier than just running in node. But if you want to add an automated test, and do it NOW - it works well.