> The emulator and game took a long time to start with no feedback as to what is happening (e.g. it would be nice to see 'Booting the emulator' , 'Loading the game', 'Optimising for running' or what have you).

This would be an interesting area of research. Once we fire up the emulator, it starts drawing to its screen buffer (which is an HTML5 canvas). What you see is presumably exactly what you would see on the original machine (sadly, I never had an Amiga myself). You see the workbench, possibly some messages in it from the software, then the software takes over the screen and starts drawing pretty pictures. In between, a lot of these things seem to blank the screen, turning it black or grey, or filling it with noise.

Providing meaningful and accurate feedback on top of that would be a fun application of computer vision, but it could turn out to be a difficult problem in the general case.

Thanks for mentioning the fullscreen button, I hadn't noticed that it was broken; I'll see if I can fix it. Muting is a horror show, because MAME and DosBox don't yet support it. SAE does though, so we'll work on it next.

One option for better feedback is to add indicators for floppy and hard drive activity, like the leds on the original Amigas.

Some emulators even emulate the sound of the physical fdd :)

https://www.youtube.com/watch?v=csjqX3bm2lc

Indeed, a disk activity indicator is actually an option now with SAE. It'll probably take a bit longer to do correctly, as it will touch more of the page than just the canvas.

If you can get the current instruction pointer of the emulated CPU and compare it to a system memory map (or just previous runs of the same ROM and software), you could probably create a progress bar. No computer vision required ;).

Hmm. Such a progress bar would be really cool, but it would jump back and forth a lot.

Also, I have secret plans to use the progress-bar metaphor as an interface for accessing past game states. Imagine if you started playing Pacman, and the progress bar started filling up. Then you click in the middle of the filled-in bar to jump back to that place in time...

I imagine building a table of, say, 100 IP values that are only ever visited in order. That is, IP table 5 will never be seen after IP table 6 has been seen. But even that isn't necessary. You could just say, "the first time I see this IP value, increment to 37%", so that the progress bar never moves backward.

The progress-bar-as-rewind idea is very cool, too.

Nah, you are overthinking it.

You can record how many frames or cycles it takes for the first thing to appear on the screen.

Since the emulator is deterministic and you are always starting from the same state, it will always take the exact same amount of emulated time (for each version of the emulator). So your progress bar is simply a measure of emulated time.

Or take it a step further, and store a savestate from the moment the first thing appears on the screen, and the user's emulation will start from there instead.

Save states would solve a lot of problems :)

Try to play Frontier: Elite II on http://www.jor1k.com. When it finished booting just open the menu by typing "help" and then choose Elite in the graphic games menu. Change to 30 frames per second.

This way it runs smooth on my system. The version in jor1k ran through several transformation steps. It uses the Atari version of Frontier written in Assembler. Then Tom Morton wrote a 68k to C converter for this game (https://tom.noflag.org.uk/glfrontier.html). This was compiled to OpenRISC machine code which is then emulated by jor1k.

The fact that this runs faster then the Amiga emulator shows, that they have still have a lot of work to do.

I just tried it.

The frame rate was still sub-optimal.

It may be time to upgrade my motherboard and CPU - the Phenom II X4 is really starting to show its age these days :)

Hmm, looks like I am wrong. The shift key is recognized by JavaScript.

The games needs about 130 MIPS in the emulation. If it runs at that speed you have to adjust the frame rate in the dropdown menu. But the main problem is the keyboard emulation. Frontier needs the shift key to slowdown the spaceship. And there is no way in JavaScript to get the keydown and keyup events for this key.

I wonder what happens when it asks you to type in a word from the manual.