Atom Emulator AtoMMC support

[hoglet67]

Hello Andre,

Thanks for all your great work on the emulator, it's really impressive what you have achieved.

I just wanted to let you know that I've started work on adding full AtoMMC support to your Atom emulator, with the goal of being able to run the AtomSoftwareArchive on the web.

It's definitely work in progress, but you can try it out here: https://hoglet67.github.io/

The first time this is loaded will be slow, as there is a ~20MB file download. This is then cached locally, so subsequent loads are much faster.

*MENU will start the Atom Software Archive MENU system (normally you would do SHIFT BREAK, but that's not currently possible in the emulator).

The current AtoMMC source is here: https://github.com/hoglet67/chips/blob/master/chips/atommc.h

I'm struggling a bit with the build system. There are a few emcc settings than need changing, e.g.

    set(EMSC_LINKER_FLAGS "${EMSC_LINKER_FLAGS} -s FORCE_FILESYSTEM=1")
    set(EMSC_LINKER_FLAGS "${EMSC_LINKER_FLAGS} -s LZ4=1")

I'm not sure how to set these just for the atom and atom-ui targets. I also found the LZ4 support wasn't working with the closure compiler in the release build. And I also ended up packaging the AtomSoftwareArchive files manually.

The main issue I'm seeing with the emulator is with keyboard handing. Lots of atom games use Ctrl, Shift and Rept as these are easy to read. It seems only work when used with another key, not on their own. On a real Atom, the following code should detect Shift and Ctrl being pressed:

DO PRINT ?#B001;UNTIL 0

Is this something that's fixable?

Anyway, this seems like a fun Christmas project, so I'll keep working on it over the next few days.

Dave

[hoglet67]

Andre,

I've done a bit more work on the AtoMMC implementation, it now supports random access files.

I've also reworked the keyboard handling so that shift, control, repeat and break are handled as they would be on a real Atom. I'll let you decide whether you want to use this, or whether you had some different ideas for how to address this.

Finally, I see in the last couple of days you have reworked the m6522 so I've pulled that across, as quite a few Atom games need interrupts. So now demos like Bad Apple work, and the loading screen of Manic Miner also works (it uses interrupts to make a palette change half way down).

The deployment reflects all these changes: http://hoglet67.github.io

Dave

[floooh]

Hi @hoglet67, this is awesome stuff :)

I'll try to have a close look when I have some time, I definitely want to improve the Atom emulation and merge your work, but it'll probably need to wait until January or so.

We should find a way to not require FORCE_FILESYSTEM. Maybe we can pull in any required data through a normal HTTP request after the emulation is loaded, but I can look into this.

Keyboard input bugs are definitely fixable. But with the current keyboard matrix helper code in kbd.h there might be issues if a key is both a modifier and must be detectable as a regular key too (e.g. Shift), so maybe that's where you'd run into problems with the current code.

[hoglet67]

I'm in no hurry to get this merged, and I'm happy to take on board any suggestions you have.

I'll try over the next couple of weeks to create some seperate pull requests for:

• the AtoMMC hardware (I'd like to add a UI for this, as a learning exercise)
• Atom SID at BDC0-BDDF (this is quite a common addition for real Atoms)
• extending RAM to cover A000-AFFF (so you can load a utility ROM)

I've also tried reworking the keyboard handling so it uses the same mapping as Atomulator, which tries to physically map the Atom keyboard onto the PC. This allows shift and control to work as independent keys. But I'm not happy with this, as it's harder for people unfamiliar with the Atom to use, and it's also broken some of your nice features, like the input URL parameter. I have a couple of other approaches to try that might get the best of both worlds. So lets see...

Dave

[floooh]

Hi, FYI: I'm going to merge changes to the Atom emulation soon which changes the emulators tick function. Basically, the remaining chips in the Atom (i8255 and MC6847) had their iorq() functions merged into the tick() function.

The work was happening in the atom-tick branch, and the new tick function looks a bit differently:

https://github.com/floooh/chips/blob/61f50d1fd16bcc6c5fb17501ee134fc6faf28996/systems/atom.h#L355

The biggest change is how the i8255 is ticked:

https://github.com/floooh/chips/blob/61f50d1fd16bcc6c5fb17501ee134fc6faf28996/systems/atom.h#L438-L484

Instead of the I/O code being spread over various callbacks, everything happens now before and after the i8255_tick() function (basically setting the right input pins, and inspecting the output pins). I think this all looks a bit clearer now when having the actual schematics in mind, if a bit crammed :)

One thing that will also happen soon, and which unfortunately will break existing code is the addition of a CLK pin for support chips (see here: https://github.com/floooh/chips/issues/27).

Cheers!

[hoglet67]

Thanks for letting me know. Once you have this merged, I can update/fix the AtoMMC code as required.

What I'll probably do is to seperare out the changes for:

• adding AtoMMC
• adding a SID
• keyboard handling

Then you can decide seperately which of these you want.

I'm still not really happy with the way I have the atom keyboard working in my master branch. This maps Atom keys by their physical position on the keyboard (as far as is possible), which is how Atomulator does it by default. But it's very hard for new users.

I also did an experiment, rolling back to your original keyboard handling code, then doing as little as possible so the reading #B001 would give the expected result (showing shift and control). You can see this work here: https://github.com/hoglet67/chips/commit/fd29aa36726091dc56f50d0e911c8b4562d54155

On balance, this second approach is probably better for a web-based emulator that's likely to have a broader user base of people.