JetSetIlly

Let's make that a tryptych of people called Stephen (or Steven)

The binary files should be 8448 bytes. The first 6k is loaded into Supercharger RAM according a page table which is stored at the end of the file. The next 2k is just junk data. And the final 256 bytes is meta-data that would normally be loaded from tape, but is not part of the data that is loaded into RAM.

It's fun! Couple of points: 1) You should be able to start the game from the title screen with the fire button. @ZeroPageHomebrew talks about games being "couch friendly". 2) It would be better if the game didn't immediately return to the title screen at the end of a game, to give the player a better understanding of what has happened. For example, in one of my first games the game returned to the title screen and I didn't understand why. I had to rewind the game in the emulator to find out what had happened. I recorded the event in the video below. We can see that the pink alien appeared on the left without warning and in the space of just a couple of frames the game was over. Bu all in all. I enjoyed playing it 🙂 2022-10-25 21-40-44.mp4

What do the numbers 1 to 10 refer to in the sensitivity setting? Is it just a scale?

That made me smile. I love it!

Indeed. CRT blur sounds possible. Maybe an RGB mod issue?

The SAX instruction ANDs the A and X registers together and stores the result at the address LAX loads a value into both the A and X registers.

I've never seen an example of a ROM where the TIA revision effects the timing of COLUP0 and COLUP1. Quickstep is an example of a ROM where the timing of COLUPF is affected and this sound like something similar for the player colour registers. Is this a 7800 only phenomenon and not seen on any 2600 revision?

Maybe not 🙂

Indeed. To be clear I'm only throwing around ideas here but (unless the Harmony developers ask for it not to be re-implemented in software) it's not an impossible task. Difficult and challenging but not impossible.

The underlying hardware requirements will be significantly higher, for sure.

I'm meaning emulating the ARM chip in its entirety to run the firmware. In that way, you don't need to know the details of the implementation.

There's a lot to think about for sure. But in the case of the Harmony type cartridges, I don't see any reason why you couldn't have the different firmware files on disk for testing purposes. For a developer it would be useful to know if their particular ROM is incompatible with a particular firmware. Indeed. There are awkward cases like startup-bank to consider.

Indeed. I do think it's important to acknowledge the original limitation in emulation in some way. A simple "lint" check in developer mode would be a good start. eg. Will this ROM run on hardware available in 1977? (How much would it cost to build?) FWIW, I've implemented the stricter protocol in Gopher2600. It seems fine but without knowing what other homebrew CBS ROMs are out there, there's a risk it will break those ROMs for no good reason. One idea that could be developed is the separation of the two concepts - "bankswitching" and "cartridge package". Currently, emulators implement cartridges in an ideal way and are only really concerned with which bankswitching method is being used. But as we've discussed, the bankswitching "protocol" is affected by the cartridge "package". I'm thinking that emulators should allow the user to select the "package" that the ROM is "contained" in. The package option might simply be: (1) Idealised and (2) Period Accurate. But it could be extended to (3) Harmony/Melody or (4) Uno/PlusCart etc. with full firmware emulation. A really good emulation would be able to answer the question: Which cartridge packages will this ROM work with? ... Anyway, just thinking out loud. Interesting. Thanks Do you have a link for that document?

Outstanding. Works beautifully on Gopher2600 too.

I think implementing the CBS protocol as per the patent is maybe artificial but in the case of SARA RAM I think there are benefits to implementing the limitations in some way - even if it's just a warning on the screen in "developer" mode. Are there any examples of SARA ROMs (meaning F4 etc.) that have made the assumption that it's okay to execute code from the cartridge RAM?

It's an interesting point. However, for practical purposes, we might argue that the CBS protocol as it exists today under emulation is "correct". There are no consequences with the simplified protocol when applied to Omega Race, Tunnel Runner and Mountain King, that I can see. In other words, it seems that those ROMs were created without the additional detail in mind. (Are there any other CBS/FA ROMs?) On the other hand, if there are practical advantages for the data bus restriction then there is a good case to be made for implementing the "full" protocol in emulation, so that new developers might explore it further. But it's unclear to me whether any advantage exists; or whether the data bus detail described in the patent is simply a novelty introduced for purposes of the patent.

Gosh. That's really interesting. I'd not considered that as an issue at all. I'd like to model what the results of that look like in emulation. @Thomas Jentzsch is the limitations of the SARA chip with regard to speed something the Stella team have thought about at all?

Another small release. Full change log on release page https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.19.3 This implements the CommaVid cartridge mapper, as recently used by @SvOlli in his new 512 byte demo I've not written a cartridge fingerprinter because I have a feeling anything I come up with will have many false positives. So, the mapper needs to be selected either on the command line or by changing the file extension to .cv The Gar Nix Supercharger MP3 file doesn't work. I'm not sure why. The real Supercharger BIOS that the emulator relies on (which you must supply yourself https://github.com/JetSetIlly/Gopher2600-Docs/wiki/Supercharger) handles the decoding of the PCM stream so there must be an issue with converting the MP3 to PCM in this instance. Also fixed in this version is the handling of the PA7 bit and a bug that caused the address bus information in the 6507 Pinout window to be useless.

Thanks for the answer. Does CommaVid offer any advantage over other cartridges with onboard RAM?

Interesting. Thanks.

Nice! I love to see scene demos on the 2600. But newbie question, what is CommaVid?

Excellent. Nicely implemented. Very hard though 🙂 An easier setting would be a good addition I think.

Great! The player control feels spot on. You should continue with this.

Outstanding. I love it.