JetSetIlly

If you've coded with the assumption that Flash Origin is at 0x00000000 then you're going to need to change more than the header files. The diff file below shows how I needed to add the "ROM" address to "offset" values in a few places. https://github.com/JetSetIlly/plusromtest_cdfj/commit/33d400d2ceb9ea8be7dc3c0178b812236f224fc9#diff-2978fe1c2c45b4eca89dc476376ddc7193bc4e5e7fff0c7d1c465f057b35a5e6

Github project. The second commit shows the changes I made to target PlusCart. https://github.com/JetSetIlly/plusromtest_cdfj

No.

Not a problem for emulators, all the pieces are there, so it should work using the same ROM compilation method as for DPC+ ROMs. For the PlusCart itself, there needs to be a reimplement of the CDFJ functions that are present in the Harmony driver.

I expect there'll be other complications but the first step was to change the memory map for the new processor. I left it with @Al_Nafuur but I got the impression that he had compiled Harmony programs for the PlusCart's CPU and managed to get them running. This is the memory map definitions for Gopher2600. As you can see, I've not identified the registers for the Timer or the MAM (I'm not even sure if there is a MAM in the STM32F). So as long as you don't need the timer then I suppose this is okay. https://github.com/JetSetIlly/Gopher2600/blob/a096d74b314ec9a54dd7b7a969023b796dad3feb/hardware/memory/cartridge/harmony/arm7tdmi/memorymap.go

To be clear, this only changes the memory map. Cycle counting will be different - it'll be similar but there's bound to be differences.

This version of the bot is working only with visual and audio cues. There is no direct access of the emulation's memory. The plan is to extend this framework to other games but obviously, most other games are more complex so that will be quite a challenge. Combat would be a good second project I think.

A longer video of Video Chess playing Stockfish. The bot is moving a little bit quicker now. I don't think I can't get it going any quicker though because of how Video Chess works. I certainly don't think I can just poke values into memory but I could be wrong on that.

That sounds achievable. You should finish that project off.

I was watching game 4 of the Chess World Championship this afternoon and stared thinking about computer chess. Specifically, whether I could get Video Chess to play against an external chess engine. Here's the first attempt. Video Chess is playing black. It should work against any standard chess engine but in this instance I'm using Stockfish.

I've not dug into it too much but a quick look at what's happening to the memory in the ARM, it looks like there's a value in RAM that's not being updated when cycle counting is off. It looks to be a value that's copied to address 0x82 of the VCS RAM (or maybe the other way around). That might be a clue as to what is happening. demo_video.mp4

Excellent. In the latest binary, you're not using much ARM time at all compared to previous versions, so you have lots of room for more processing. Incidentally, all versions work OK on Gopher2600 but cycle counting is on by default, so for earlier versions of your binary you need to turn it off, or the scanline count is unstable. In the latest version of Stella, it is the other way around - cycle counting is off by default and on in developer mode.

There's the Atari Diagnostic Test Cartridge which came with a Field Service Manual. That would be good for you to get your hands on. Example page below. Just six basic tests so it would be nice to have something more comprehensive I think.

It is. I don't think we tell from this if the routines are the same or not. All we can say is that the starting seed is different - there's no randomisation from any other source and the user input is the same. Why the starting seed is different I'm not sure. My guess is that it's a magic number in the binary. Has anyone ever done a disassembly of Solaris? It would be interesting to know what randomisation method it uses. We might then be able to force the use of the same seed to test whether the routines are the same. That might be because that particular sequence takes longer. Sometimes, the map screen comes up at the same time. One thing I did notice is that shade of blue in the compass is sometimes different on the map screen. This isn't a difference in the binaries I don't think because it doesn't always happen. Yes. Once I've nailed down the synchronisation so that it's perfect, it could be a useful tool. What it would be useful for is testing for differences between machines. So two emulations using the same ROM but the emulation is using a different TIA revision. That would quickly tell us whether a ROM plays or looks different on different versions of the 2600.

There is no randomisation in the emulation for these tests. Any random elements can only come from user input. The effects of which I've mostly ironed out by running the two emulations in parallel. This should mean that any differences we see come only from the differences in the binary itself. The first difference I can see is that the pre-release must be started with the panel's start switch. The release version that I have can be started with the joystick's fire button. Visual differences in the video below. As I say there is no randomisation and the video is shown from startup, so the differences in the planets/craters is caused by the initial state of the binary itself. The only user input is pressing of the start switch and then the fire button to get the ship moving. Trivial differences really. All this tells us I think, is that the starting state of the binaries are slightly different. Synchronisation of the emulations is tricky. The previous video was being synchronised by frame (so the visual differences are matched frame by frame) which is fine, but it's possible for user input to be given on or near a frame boundary. This means that it is possible for one emulation to receive the input on one frame and for the other emulation to receive it on the next frame. The previous Pitfall video I believe that's what happened in the second half of the video when we see the screen having been scrolled by slightly different amounts. It makes more sense that this was caused by a slight difference in user input than any differences in the binary. It should be possible to synchronise input exactly but I haven't done that yet.

It's my own emulator called Gopher2600. I added the comparison window this evening so this tooling is brand new. If you think it would be useful I can polish it up and make it more usable. I had a quick look at the Solaris ROM and it was quite successful at showing the differences with that too. (I just had another watch of the YouTube video and I noticed that the first glitch as you fall in the water might not be visible unless you're running the video at 720 60fps)

I thought this was an interesting puzzle so I thought about how we could perhaps make an automatic tool to illustrate where a game plays differently. I've hacked up my emulator so that it runs two emulations side by side, with the two different ROMs. Both emulations receive the same user input. The video below shows what I found. The large screen is the known good dump of the Pitfall 2 ROM, while the smaller window has the "beta" ROM in the top part and a screen showing the visual differences between the two ROM in the bottom part. The first minute or so there are no differences apart from the visual glitch that has already been found and a small difference in the water snake (probably been run a frame behind). This shows that the tool basically works as intended I think. After I die and go back to the beginning, I manage to trigger some differences, with quite a dramatic difference when I fall into the water for a second time. It looks to me like one or other of the ROMs hasn't quite scrolled by the same amount. What's interesting about this is that the different persists right up to when I pick up the gold bar. At which point the two games come back into alignment.

Version 0.15. Major change this version is the ability to switch between debugger and play mode with the key below the escape key - tilde key on US keyboard (the same default key as in Stella). There is also a ROM requester that will show on startup meaning that the emulator can be now be launched from the desktop. The requester window will show a thumbnail for all supported ROMs. Performance is also improved I would say and there is a new interference effect in the CRT emulation. Full changelog on the release page: https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.15.0 Some features are better shown rather than described so I made a short video illustrating some of the most interesting ones introduced this version. (Best viewed in HD 60fps) I've tried adding an icon to the Windows binary but it's not that successful yet. It definitely needs some work. It's based on a fun logo I made this morning. The logo works but it's too complex for an icon. As ever, feedback is welcome.

The demo looks very effective. (It also runs on Gopher2600 if you turn cycle counting/enforcement off)

Another demo video of the tracker window. This time with piano keys. I'm quite pleased I can do this sort of stuff in regular playmode without any performance drop. It opens up other possibilities too I think.

Tuning in for the Donkey Kong zoetropes. That sounds like fun.

Video showing new audio engine. This is a straight reimplementation of @Crispy research and is the same as 6502.ts and Stella. Sounds pretty good I think. The video also shows a new Audio Tracker window. Early stages of development yet but it's helped me track down a bug so it could be useful for regular development work too. Thanks to @DirtyHairy for pointing me in the right direction for the engine implementation.

Are there any example ROMs where this is particularly noticeable?

Thanks. I've made some progress with that. Question: Why is the tone generation divided into two phases? Phase 0 at the first 114 clock and Phase 1 at the 228 clock. The results are similar (to my ear) if you run both functions every 114 clocks and create an output sample then. Is this a reflection of the hardware somehow? It's okay. I see what it's doing now.

I'm hoping someone can help me with the Audio implementation in Gopher2600. It's mostly okay (correct) but there are a couple of things which don't work correctly. I've implemented the volume mixing as described in the document "TIA Sounding Off in the Digital Domain" by @Crispy and to my ears that correctly implements the MsPacMan music distortion (I've attached a WAV file) mspacman.wav On its own however, this doesn't fix the the ET spaceship effect et.wav or the phaser06.bin demo ROM phaser06.wav (WAV files of current Gopher2600 version) My code is based on Ron Fries original TIASound.c file and the volume mixing taken from the "Digitial Domain document". What am I missing or misunderstanding?