jzIntv in a Browser Window (OT)

[First Spear]

Kind of a continuation from an old thought at http://atariage.com/forums/topic/242580-can-intybasic-be-run-in-a-cloud-environment/page-2?hl=%2Bjzintv+%2Bbrowser&do=findComment&comment=3322184.

 

 

Is DOSBOX still the best way to run jzIntv "in a browser"?

 

I know it is not actually running from the web, it is all being run locally. I am trying to think through a way to deliver+execute a ROM in a virtual environment so a user would not have to do anything other than click the correct (web page) button. Some folks had created an Apple II emulator in JavaScript, so I wasn't sure if there was anything current/equivalent for us in the Inty world.

 

Thanks.

 

 

 

 

 

 

 

 

[mr_me]

DOSBox would mean an emulator within an emulator, assuming you have jzintv and sdl compiled for dos. I thought there was a java version of the Bliss emulator that would run in a browser with java. At archive.org they have Mame running in a browser https://archive.org/details/intv_4_TRIS_2000__PD .

 

edit:

Intellivision Lives for PC comes with a DOS emulator so you don't need to compile jzintv for DOS, and there's also IntvDOS. http://www.intellivisionbrasil.com.br/Menu_Emuladores.htm

Bliss Java is at that link as well.

Edited October 3, 2018 by mr_me

[intvnut]

I would say jzIntv is about 80% of the way (perhaps 90%) to being able to run in a web browser using Emscripten.

 

jzIntv itself supports embedding files into the jzIntv executable. This support is currently unused (no files are embedded), but it would not take very much to enable it. There is an lzo_embed tool that comes with jzIntv that compresses files, and outputs C source. This then needs to be compiled into jzIntv, and a line added to main() to register the directory of files that were just added ("lzoe_register"). Once added, the internal compressed filesystem looks like it's just overlaid on the regular filesystem with respect to the rest of jzIntv, at least for reading files. With this facility, you could embed miniexec, minigrom, and your game.

 

Emscripten supports SDL, which makes the back end darn near trivial. I've already experimented with Emscripten and an SDL-based demo here: http://spatula-city.org/~im14u2c/slackies/

 

There are a few places jzIntv uses platform-specific optimizations rather than relying on SDL abstractions. For an Emscripten target, I need to tell it to use a pure SDL approach. The two main places I do this are: reading the time, and limiting execution rate. I have generic fallbacks for both (with the latter just being SDL_Delay()). I don't remember if SDL_Delay() is verboten in Emscripten, though.

 

To work in the web-browser with a single game, you probably want to lock down all of the flags given to jzIntv. That's trivial, actually, by replacing argv[] with an array of constant strings for the canned flags.

 

The main sticking point will actually be the main "runner" loop. Emscripten does not like infinite loops. So, the main loop that runs the emulator will need to be broken out into a "runner function" and registered with the Emscripten run-time. Perhaps the best approach would be to just write an Emscripten-specific jzintv.c for the top-level that throws out anything not needed for the web, locks the command line down, and moves the 'runner' loop to a threading-friendly function.

[intvnut]

OK, perhaps I should have put it closer to 95%.

 

http://spatula-city.org/~im14u2c/spacepat/

 

This is still very rough and very buggy. I don't think I'll have much time to actually work on it. But, if someone wants to poke at it, I've checked the fairly minor delta into the source tree.

 

 

Most of that are the compressed "embedded filesystem" that contains minigrom, miniexec, fake_ecs, and SDK-1600 Space Patrol.

[intvnut]

If anyone reading this has any experience with Emscripten, I'm interested in help in a couple places:

• Why doesn't audio start straight away?
• Why does the game consistently hang about 90 seconds in?
• When it recovers from the hang, why does audio start working suddenly?

I think these are all related, but so far I haven't found any deep insights out there to assist me.

 

In any case, jzIntv almost works in a web-browser now.

[artrag]

Just a curiosity, why do you emulate an embedded file system to access to roms that you can include at compile time into the data of the emulator?

Wouldn't simpler to preset the addresses space of the Cp1600 with the rom contents stored in constant arrays?

[intvnut]

Just a curiosity, why do you emulate an embedded file system to access to roms that you can include at compile time into the data of the emulator?

Wouldn't simpler to preset the addresses space of the Cp1600 with the rom contents stored in constant arrays?

 

It might be simpler for a one off. If I combined it with a lot of hacking and slashing, I could seriously put jzIntv on a diet.

 

I wanted a more general purpose facility, for multiple reasons:

• Far fewer things to change. I write a wrapper around FILE*, fopen, fread and friends once, point everything at the wrappers, and I'm done. (Here's the actual code itself. It's not much code.)
• No "special cases" in any of the code that consumes files. If it works when loading from a file, it doesn't matter whether that the file came from the internal filesystem or outside world. I don't need to implement and test "preloaded ROM" of various forms. I don't need to create multiple forms of tooling for all the pieces I need to generate preload images for. (.ROM is different from .BIN, which is different from kbdhackfile, which is different from a palette file.)
• I can mix and match embedded assets with external assets. I can even completely ignore the embedded assets until they're wanted/needed. For example, I could embed minigrom/miniexec and set those as the default fallback if the real EXEC/GROM aren't found. Or, I could compile in some ROM images (event_diag, joy_diag, and whatnot) so that they are always present, but are ignored when not used. Or, I could compile in some default alternate keyboard hack files that are easily accessed. All of these make jzIntv more self-contained, but still provide a uniform "filename" interface to these resources.

One idea I've toyed with is to write a jzIntv front end in CP-1600 itself, and embed it in jzIntv. The Emu-Link / ELFI interface would enable it to scan the filesystem and get the information it needs. (I would need to add directory-reading APIs to ELFI.) It would take some work, but I think it would be doable. I could borrow much of the user interface code I already wrote for LTO Flash, for example.

Edited October 3, 2018 by intvnut

[First Spear]

 

For my use case, which would be delivering a bin+cfg in a runtime environment via a browser, it doesnt matter if a file system exists. I do need a programmatic way to build the game and runtime into a unitz, but I dont need a full menu to select multiple games, just one at launch.

 

 

 

 

 

Just a curiosity, why do you emulate an embedded file system to access to roms that you can include at compile time into the data of the emulator?

Wouldn't simpler to preset the addresses space of the Cp1600 with the rom contents stored in constant arrays?

[intvnut]

For my use case, which would be delivering a bin+cfg in a runtime environment via a browser, it doesnt matter if a file system exists. I do need a programmatic way to build the game and runtime into a unitz, but I dont need a full menu to select multiple games, just one at launch.

 

There is a way for me to embed all of the necessary files into jzIntv.

[First Spear]

Could a game be dynamically compiled into jzIntv, so in the course of development something new could be generated repeatedly for testing?

 

 

 

There is a way for me to embed all of the necessary files into jzIntv.