JetSetIlly

Interesting. There are a couple there I've not heard of. For the very modern formats, like DPC+ CDFJ, ACE and ELF. I don't use the size of the ROM file at all when fingerprinting. As such EF is the only format handled by the "size == 64k" condition. I'll keep the EF signature in mind but for now I'll just treat EF as a standard (unsigned) cartridge. 🙂

Good point. As far as I can see, treating it as a 64k standard cartridge (and checking for a superchip "empty" segment) is sufficient and produces correct results. Is there another bankswitching format (that I don't know about) that can be confused for EF/EFSC if we don't use the signature? (Sorry for the constant and basic questions but the 2600 is a continual learning process for me)

That's interesting, what's the reason for that. Yes. This is the original code in Gopher2600: I did a poor job of documenting my implementation process for EF and I wouldn't have spent a lot of time on it, but the README file says that I used Stella as a reference. As I now realise, I didn't need to do that because it's literally just a 64k Atari ROM and there's no need for a fingerprint at all. My question now is: why does bB emit a signature at all?

Yes. I "detect" whether an atari superchip is required by checking if every byte in the ROM for those addresses is the same. My simpler implementation now works with this ROM for that reason.

That makes sense. A cartridge putting a random/uncertain value on the data bus is something I've not considered. I always put something on the bus and for most affected bankswitchers I just generate a zero; but for EF I decided to use the corresponding value from the binary file (for some reason). In this case, it had the consequence of making the ROM appear to work correctly. The question now moves to the PlusCart and why the problem ROM works there. I'll take a closer look at that later. The other thing I didn't notice is that EF is effectively just a 64k standard Atari cartridge. Now that I know that I can simplify the implementation.

There's still a mystery here though with regards to Stella which I'd like to know the answer to. And that's why bank 0 address f000 is an RTI instruction because that's not what's in Cartridge RAM at that time.

I haven't left any comments in the code explaining why I did this, so maybe it was just a mistake. As I said, I'm not sure what the correct behaviour is for this bank switcher but if it can be implemented in hardware with an actual superchip then what you're saying is correct.

I should also mention that the placing of code at $f000 means that the RAM will be written to when those instructions are read. In our case, this is the state of cartridge RAM after reading the instructions between $f000 and $f019 (I suppose this is the reason why you should build projects with "multipsprite_superchip.inc" . I'm not really familiar with batariBasic but I'm guessing that that inc file causes ROMs to be built that don't execute code in between $f000 and $f07f)

A good way of seeing where the two emulations diverge is by placing a breakpoint on 0xffdd of bank 0 The RTS instruction at that address sends execution to address 0xf000 (of bank 0) in both emulators. Stella is reporting that the instruction at that address is an RTI instruction. Gopher2600 thinks this is an LDA instruction. This is the block of code between $f000 and $f019 according to Gopher2600 Looking at the binary of the ROM file itself, these instructions correspond to the raw data. So I think this is a difference in the implementation of EF. I'm not sure what the correct behaviour is. I've taken the view that reading from a cartridge RAM write address will access the corresponding byte in the ROM. Stella appears to be doing something different. I'm not sure where the RTI instruction is coming from but it's not coming from the ROM file.

Yes. BREAK NONEXE (typed into the Gopher2600 terminal) will halt the program if a non-cartridge address is executed.

I've just uploaded the binary to my Pluscart and it works fine on hardware (2600 Jr in this case). So if anything, I would say the error is in Stella. It's an interesting bug though and it would be instructive to understand what's causing it. Does Stella have a way of outputting disassembly as it happens in sequence, as a log? It's difficult to understand the error without being able to see the instructions that led up to the invalid instruction (at PC $0f1f).

The author references your disassembly in a link towards the bottom of the article.

Have you considered using the map generation algorithm that the original game uses? It might be easier in the long run. https://evoniuk.github.io/posts/pitfall.html

Also runs on Gopher2600 🙂

I've not thought about Joy2B+ before but it should be easy enough to add. I'll take a closer look at it in the new year. Thanks for the idea!

Discounting the ARM chip for a moment, let's imagine that somebody wanted to build a cartridge that was adaptive to NTSC/PAL during the early '80s. What would have been the cheapest/easiest method of achieving it at that time? It would need a clock in order to measure the console against and it would also need a specific "bankswitching" protocol in order to get information from the clock. The protocol wouldn't need to be complex, just a binary response to the question, "has the clock elapsed since the last time [some address] was accessed?"

Not possible without additional hardware I'm afraid.

I'm getting the access denied error for this file like the ROMs in the original post.

That's all I'm seeing too. Gopher2600's comparison tool highlights the difference (Fixed version on the large screen and the original version in the comparison window) How did you spot this Thomas? Are you just inspecting the code or do you have a tool?

I like this! I think the opening image of the island is particularly effective.

Option 3 sounds good to me too. The other option is a non-linear increase (eg. 2x after 5, 3x after 10, 4x after 20, 5x after 40). I like this idea because it gives something to players who aren't experts in addition to rewarding and differentiating experts. How do you handle the obstacles that don't need to be avoided? Do they count towards the multiplier?

Yes. It would need an indicator of the current multiplier somewhere for it to be worthwhile.

A combo bonus would be nice. ie. the more blocks you clear without error the higher the multiplier. eg. if you clear 10 obstacles without any collision the multiplier goes to 2x

I really like this. I've an interest in text adventures for the 2600 and I'm impressed you've come up with a usable UI in just 4k.

I like this a lot