Existing emulators don’t really fit the bill because they don’t output to the host OS console, open a window, and are also comparatively slow because they emulate many more things at an accuracy level unnecessary for these purposes, and run the full boot sequence. In my programming environment if I compile and run in openMSX unthrottled it still takes a few seconds before my program executes. While in a build script I would want it (e.g. GEN80, MSX-C, PMARC or my unit tests) to take a fraction of a second to execute to completion.
I've thought about this a lot in the past, and I think that openMSX an actually be used for this:
* openMSX can run without an output window
* sound can be disabled (mute) to avoid wasting CPU time on sound generation
* one could install a script that outputs the MSX-DOS output on stdout
* dir-as-disk is probably a good ingredient as well
I think you can get pretty far with this, but it's no completely free lunch Anyone up for the challenge? I'll help where I can.
Maybe some trickery with a savestate?
I guess all is needed to have an interface that freezes a running MSX, injects the freshly assembled BIN directly into RAM (maybe though the debugger?!) and resumes with a JP to the specified start address.... or something... Like "hot plug" code.
SdC, that certainly can be done. But just loading it could also work
@Philip: to solve which problem exactly?
@Philip: to solve which problem exactly?
To skip the booting of the msx. Make a savestate once booted in msxdos.
Then start openmsx, load the savestate and run the compiled program. This would make running the compiled program pretty much instant.
No idea if it's possible though
Well, at maximum speed, booting MSX-DOS takes no significant time. So, although it is certainly possible to work with a save state, I don't think it's necessary.
I've put the scripts on Github, if anyone is interested to take a look: https://github.com/decocq-stuff/msx-pascal-project-template
I'm certainly interested in feedback!
Thanks will try this out. I favor the Visual Code editor over MSXPad a lot so this sounds like a great solution.
It looks like GitHub strips the JSON files and deletes the .vscode sub-folder, so unfortunately I'll have to add those as a ZIP that you need to extract. Grrrrrrr I was really trying to make it as simple as possible to get up-and-running.
Weird. Have you tried creating a git repository locally and then pushing it to Github? That definitely shouldn't strip anything.
Yeah, it seems to be fixed now after pushing the repo again. Thanks for the tip.