Jump to content
IGNORED

64kSC multi sprite ROMs error out in Stella (for me)


Gemintronic

Recommended Posts

 

8 hours ago, JetSetIlly said:

The question now moves to the PlusCart and why the problem ROM works there. I'll take a closer look at that later.

 

7 hours ago, alex_79 said:

The "last value on the bus" on the next instruction after a "RTS" would be the byte at the address stored in "Stack Ptr + 1" (lsb) and "Stack Ptr + 2" (msb).


In the case of the "RTS" at $ffdd in bank 0, the address pulled from the stack is $0fff, which is the TIMINT riot register. The timer has not expired when the instruction is executed, so reading that address returns $00.

 

If, with the Pluscart, reading from the write port returns the last value on the bus, then the opcode that the CPU sees at $f000 in bank 0 is $00, that is "BRK". And there's a valid interrupt vector in bank 0 ($1fbc, the same as the reset vector). So that might explain why it doesn't crash there. (I'm just guessing, I'm currently unable to test on real hardware and won't be for a while).

 

I am not sure, but if there is "code" in the SC-RAM area of the ROM file, the PlusCart might detect the ROM as EF and not EFSC..

 

  • Like 1
Link to comment
Share on other sites

9 hours ago, Al_Nafuur said:

I am not sure, but if there is "code" in the SC-RAM area of the ROM file, the PlusCart might detect the ROM as EF and not EFSC..

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.

 

 

Link to comment
Share on other sites

9 minutes ago, JetSetIlly said:

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.

 

 

The PlusCart is doing the same, but if the code in the SC RAM area in all 16 banks is not identical then EF will be detected.

 

Stella is also checking for the "EFEF" and "EFSC" signature at $FFF8:
https://github.com/stella-emu/stella/blob/master/src/emucore/CartDetector.cxx#L611
 

and bB is writing this signature:
https://github.com/batari-Basic/batari-Basic/blob/master/includes/2600basicfooter.asm#L22

 

So this might be the reason why PlusCart and Gopher2600 are detecting this ROM as EF and Stella as EFSC

 

Link to comment
Share on other sites

1 minute ago, Al_Nafuur said:

The PlusCart is doing the same, but if the code in the SC RAM area in all 16 banks is not identical then EF will be detected.

That's interesting, what's the reason for that.

 

1 minute ago, Al_Nafuur said:

Stella is also checking for the "EFEF" and "EFSC" signature at $FFF8:
https://github.com/stella-emu/stella/blob/master/src/emucore/CartDetector.cxx#L611
 

and bB is writing this signature:
https://github.com/batari-Basic/batari-Basic/blob/master/includes/2600basicfooter.asm#L22

 

So this might be the reason why PlusCart and Gopher2600 are detecting this ROM as EF and Stella as EFSC

Yes. This is the original code in Gopher2600:

image.thumb.png.a2b230bd6c9f1e03c867fe0edb3d6b16.png

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?

 

Link to comment
Share on other sites

21 minutes ago, JetSetIlly said:

That's interesting, what's the reason for that.

My explanation was wrong.

 

Basically the PlusCart

https://github.com/Al-Nafuur/United-Carts-of-Atari/blob/main/source/STM32firmware/PlusCart/Src/cartridge_detection.c#L123

 

does for SC the same than Stella:

 

https://github.com/stella-emu/stella/blob/master/src/emucore/CartDetector.cxx#L293

 

(except for the additional "EFEF"/"EFSC" signature check)

 

21 minutes ago, JetSetIlly said:

Yes. This is the original code in Gopher2600:

image.thumb.png.a2b230bd6c9f1e03c867fe0edb3d6b16.png

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.

You don't need to check the whole ROM for this signature ($FFF8 should be enough/correct)

 

21 minutes ago, JetSetIlly said:

My question now is: why does bB emit a signature at all?

 

🤔

To help Stella detecting the ROM

Link to comment
Share on other sites

10 minutes ago, Al_Nafuur said:

You don't need to check the whole ROM for this signature ($FFF8 should be enough/correct)

Good point.

 

10 minutes ago, Al_Nafuur said:

🤔

To help Stella detecting the ROM

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)

Link to comment
Share on other sites

54 minutes ago, JetSetIlly said:

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?

There are quite a few 64K banking schemes:

https://github.com/stella-emu/stella/blob/master/src/emucore/CartDetector.cxx#L170

 

and apparently F0 is the default.

 

54 minutes ago, JetSetIlly said:

(Sorry for the constant and basic questions

Not a problem at all!

54 minutes ago, JetSetIlly said:

but the 2600 is a continual learning process for me)

for me too.

 

 

Link to comment
Share on other sites

3 minutes ago, Al_Nafuur said:

There are quite a few 64K banking schemes:

https://github.com/stella-emu/stella/blob/master/src/emucore/CartDetector.cxx#L170

 

and apparently F0 is the default.

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.

 

3 minutes ago, Al_Nafuur said:

for me too.

🙂

Link to comment
Share on other sites

1 hour ago, JetSetIlly said:

My question now is: why does bB emit a signature at all?

It provides a quick way to identify ROM bank-switching schemes.  This also helps avoid identification issues from doing the banking-code analysis identification process.

 

Being as both bBasic and the Harmony Cart were made by the same person, it's probably in there to help the Harmony Cart identify the ROM.  That's just a guess though.

Link to comment
Share on other sites

Just now, splendidnut said:

It provides a quick way to identify ROM bank-switching schemes.  This also helps avoid identification issues from doing the banking-code analysis identification process.

Indeed. For modern formats it makes sense to add a signature to help emulators and multi-format cartridges. In this instance though, it throws up a false positive (EFSC when the ROM doesn't require a superchip)

 

3 minutes ago, splendidnut said:

Thanks. It's a comprehensive list. I've mainly used Kevin Horton's "Cart Information" document in the past, which is great for "classic" bank switching schemes. For modern schemes I've struggled to find good information. Dr Boo's list would benefit from having links to example ROMs.

Link to comment
Share on other sites

3 minutes ago, JetSetIlly said:

In this instance though, it throws up a false positive (EFSC when the ROM doesn't require a superchip)

I don't fully agree with this... since the thread title says 64kSC... I believe the intention was to create a 64k ROM utilizing the Superchip.

 

The issue with the broken ROM here is that it's a hybrid:  bB partially generated a Superchip ROM (at the very least, the signature tells you that).... which is why the ROM is having issues.

 

We're ultimately talking about a broken ROM here.  I don't think it's the emulators job to identify that issue.

Link to comment
Share on other sites

1 hour ago, Gemintronic said:

What is the proper behavior when something attempts to access non-existent SuperChip RAM? 

If there's no Superchip, you'd be reading ROM data.  Which may surprise you if you were expecting a Superchip to be there.  :)

 

---

 

I did a bit more thinking on @JetSetIlly's approach of reading the ROM data "underneath" the RAM, and I think that is a reasonable approach and likely how an actual Superchip cartridge would work.  Though, it all depends on how the chips (ROM and RAM) handle that bus contention.... along the lines of what @alex_79 brought up.

 

I believe the design of the PlusCart, UnoCart, and Harmony cart all have ARM code controlling the data bus, and so their individual implementations may be different.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...