compatibility issue with some ROMs

[xhul]

Hello there =]

 

I found a couple ROMs that work fine on emulator, but crash on the GD:

https://atarigamer.com/lynx/game/Lawnmower/858330648 > endless loop right after loading

https://atarigamer.com/lynx/game/OnDuty/317461693 > endless loop right after first level

 

I investigated a bit, and partially found why.

Basically, it seems the GD expects bit 6 of byte $3C to be clear, in the LNX header.

If that bit happens to be set, when the game is supposed to interact with the EEPROM, something goes wrong.

At least when it comes to those 2 games, having the bit clear (changing the byte from $41 to $01) solves the problem (and saves are processed correctly, i checked).

 

I'd say it's likely that more ROMs have that bit set, to specify SD save (i guess that was a thing on some early gamedrives or something).

At least firmware 1.06 is concerned, sorry in advance if it was already fixed in a more recent one.

Edited February 5, 2023 by xhul

[+karri]

The thing is that the "crashing" games try to interact with the previous version of the game cart in order to use the SD cart for saving eeprom stuff. But the specs have changed since...

[xhul]

2 hours ago, karri said:

The thing is that the "crashing" games try to interact with the previous version of the game cart in order to use the SD cart for saving eeprom stuff. But the specs have changed since...

Fortunately, the code of those ROMs itself seems to interact with EEPROM in an accurate way, despite they never saw a physical release.

So to make them work as expected on the GD, only clearing the SD flag is needed.

But that's a dirty fix, because that would potentially break the save functionality on older carts.

Instead, updating the GD firmware to simply ignore that flag would also preserve the compatibility with all carts.

Edited February 5, 2023 by xhul

[+karri]

29 minutes ago, xhul said:

Instead, updating the GD firmware to simply ignore that flag would also preserve the compatibility with all carts.

That was Gisbertos suggestion also.

[xhul]

57 minutes ago, karri said:

That was Gisbertos suggestion also.

Oh, didn't know it was a known issue, my bad.

 

I found at least 4 other titles that freeze upon EEPROM interaction, in their LNX form.

As expected, they all have byte $3C set to $41.

For the record, here is the updated list:

 

https://atarigamer.com/lynx/game/4TTUDE/559890370

https://atarigamer.com/lynx/game/4TTUDEv12/547608456

https://atarigamer.com/lynx/game/GrowingTies/492191462

https://atarigamer.com/lynx/game/Lawnmower/858330648

https://atarigamer.com/lynx/game/Nutmeg/912236623

https://atarigamer.com/lynx/game/OnDuty/317461693

Edited February 5, 2023 by xhul

[+karri]

I checked my OnDuty sources and the SDcart support is still there. It fails on GD because something has changed in the firmware.

 

This support was added in the template by @Nop90. And pretty much everyone was using it at the time.

 

So there will just be a bunch of games that are not compatible...

[xhul]

43 minutes ago, karri said:

I checked my OnDuty sources and the SDcart support is still there. It fails on GD because something has changed in the firmware.

 

This support was added in the template by @Nop90. And pretty much everyone was using it at the time.

 

So there will just be a bunch of games that are not compatible...

My bet is that the current firmware assumes there's no EEPROM interaction on the ROM if byte $3C isn't $01>$05 (which is unfortunately the case if it's $41).

So when the actual interaction happens, the read|write occurs at the wrong place.

If that's true, ANDing the content of byte $3C with %10000111 before checking it would solve the problem.

Edited February 5, 2023 by xhul

[+karri]

The Lynx ROM knows nothing about the header. If you can make the GD ignore the eeprom completely so that the handshake won't start then the Lynx tries to access the physical eeprom on cart. In my games like OnDuty the eeprom is copied to RAM at startup. So the game works the same with or without eeprom.

[xhul]

25 minutes ago, karri said:

The Lynx ROM knows nothing about the header.

Yeah, i know that, what i suggested was a potential fix for the GD code.

25 minutes ago, karri said:

If you can make the GD ignore the eeprom completely so that the handshake won't start then the Lynx tries to access the physical eeprom on cart.

I believe that's what causes the freeze, most probably because the access to the GD EEPROM is protected (hopefully, otherwise what a nice way to corrupt a firmware).

[+karri]

The BenVenn cart has a real eeprom that is saved at exit to SD. At start it copies the content from th SD and puts it in th eeprom.All games work with saves.

[SainT]

I’m not quite clear on the problem — is this code which is expecting eeprom support without the bit correctly set in the header? Or is it the game is trying to use the GD features using old code which isn’t compatible with the newer version of the cart?

 

There was a bug with the original code for accessing memory card features which means it does not work correctly with the newer cart. To be fair, it shouldn’t have worked with the older version either, but due to certain factors it did. Ideally whatever code being used should be updated to use the latest version which works properly with the current LynxGD cart. I could also use the cheat system to detect and modify games which use the old code to fix them.

[xhul]

4 minutes ago, karri said:

The BenVenn cart has a real eeprom that is saved at exit to SD. At start it copies the content from th SD and puts it in th eeprom.All games work with saves.

Interesting, if it does it at exit, i assume it has a way to give the control back to the cart at some point.

On my mind, i was imagining something pretty twisted, like once the ROM is copied to RAM, the GD adjusts the read|write instructions to point to the SD instead, right before executing the ROM code.

[SainT]

5 hours ago, karri said:

The thing is that the "crashing" games try to interact with the previous version of the game cart in order to use the SD cart for saving eeprom stuff. But the specs have changed since...

I just wanted to make clear nothing has changed as such from a logical perspective, it was purely a bug in the original code which had caused the problem. The AUDIN pin direction was set incorrectly in the original code, but just happened to work due to driver strength and resistor values. 🙄

[SainT]

16 minutes ago, karri said:

The BenVenn cart has a real eeprom that is saved at exit to SD. At start it copies the content from th SD and puts it in th eeprom.All games work with saves.

The LynxGD has absolutely no problems with EEPROM saves. The issue here sounds like the issue which has been around since the LynxGD release with memory card write support. There is updated library code out there on GitHub, all that is required is a code update and recompile. If the game supports memory card save and EEPROM, then just enabling the EEPROM via the header and disabling GD support should work just fine for the GD.

 

it does sound like the most reliable / foolproof fix here though would be for me to go back and patch all the above games with issues on load.

 

I’ll add to the list of things to get on with post 7800GD release.

[SainT]

10 minutes ago, xhul said:

Interesting, if it does it at exit, i assume it has a way to give the control back to the cart at some point.

On my mind, i was imagining something pretty twisted, like once the ROM is copied to RAM, the GD adjusts the read|write instructions to point to the SD instead, right before executing the ROM code.

No, the LynxGD simulates the EEPROM. All read and write access to the EEPROM work unmodified but are persisted directly to the memory card. No requirement for an actual EEPROM on the cart. The additional mode for memory card support is the issue — this was added on the original Lynx cart I released due to lack of EEPROM support!

[xhul]

15 minutes ago, SainT said:

I’m not quite clear on the problem — is this code which is expecting eeprom support without the bit correctly set in the header? Or is it the game is trying to use the GD features using old code which isn’t compatible with the newer version of the cart?

 

There was a bug with the original code for accessing memory card features which means it does not work correctly with the newer cart. To be fair, it shouldn’t have worked with the older version either, but due to certain factors it did. Ideally whatever code being used should be updated to use the latest version which works properly with the current LynxGD cart. I could also use the cheat system to detect and modify games which use the old code to fix them.

Here is my understanding of the issue:

On LNX files, bit 6 of byte $3C was previously used to specify SD save (on other carts, or maybe on previous GD firmwares, not sure about the whole history).

Anyway, it seems that bit is just an indicator telling the cart code what to do, cause in practice, the interactions with the EEPROM are processed normally.

Indeed, according to my tests with 2 of the problematic ROMs, simply resetting the bit fixes the freeze, and the .e2p files are read|write correctly on the SD.

In short, when processing the header, if the firmware ignores bit 6 (along with the unused bits 3,4,5), those ROMs won't freeze anymore, while at the same time maintaining compatibility with older carts.

[SainT]

13 minutes ago, xhul said:

In short, when processing the header, if the firmware ignores bit 6 (along with the unused bits 3,4,5), those ROMs won't freeze anymore, while at the same time maintaining compatibility with older carts.

This would also mean any newer ROMs which use the correct code will no longer be able to access the memory card, so this isn’t a solution.

 

Unless people recompile and rerelease the ROMs which are not working, I will have to patch them.

[xhul]

3 minutes ago, SainT said:

This would also mean any newer ROMs which use the correct code will no longer be able to access the memory card, so this isn’t a solution.

I'm probably missing something here, does that bit really change the way the GD code (latest cart) processes SD saves?

I mean, if ROMs with the bit reset work perfectly fine, and ROMs with it set always freeze, why ignoring the bit would break anything?

[SainT]

2 minutes ago, xhul said:

I'm probably missing something here, does that bit really change the way the GD code (latest cart) processes SD saves?

I mean, if ROMs with the bit reset work perfectly fine, and ROMs with it set always freeze, why ignoring the bit would break anything?

The freezing is trying to access the GD features and hanging. Some homebrew uses the memory card for accessing data from the memory card and does not otherwise use EEPROM.

 

Ultimately it’s two different operating modes, just because the ROMs you have found have support for both, it does not mean all software will.

[xhul]

34 minutes ago, SainT said:

The freezing is trying to access the GD features and hanging. Some homebrew uses the memory card for accessing data from the memory card and does not otherwise use EEPROM.

 

Ultimately it’s two different operating modes, just because the ROMs you have found have support for both, it does not mean all software will.

Oh, i think i understand now.

You're saying that some ROMs may have the SD flag set, but the EEPROM type field reset.

I don't know why, but i was convinced that having the SD flag set would necessarily imply a non-zero EEPROM field.

I guess i thought it was handled as a redirection.

 

EDIT:

Then how about: if EEPROM_type_field not 0 and SD_bit not 0 as well, treat SD_bit as 0.

Edited February 5, 2023 by xhul

[SainT]

16 minutes ago, xhul said:

Oh, i think i understand now.

You're saying that some ROMs may have the SD flag set, but the EEPROM type field reset.

I don't know why, but i was convinced that having the SD flag set would necessarily imply a non-zero EEPROM field.

I guess i thought it was handled as a redirection.

 

EDIT:

Hhow about: if EEPROM type field not 0 and SD bit not 0 as well, treat SD bit as 0.

You cannot use both GD memory card features and EEPROM at the same time, it’s one or the other. In the case of the specific ROMs noted above which have support for both types of save then you can simply disable GD features via the bit in the header and they will work fine. However, as was stated above in another reply, this will then break the save functionality for the original cart.

 

As I stated before, the only proper fix is to have the ROM use the correct code, not the old code with wrong AUDIN setting. There are two ways to go about this, 1) the original author release a new version of the rom (the updated code is on GitHub) or 2) I patch these known ROMs using the old code to fix them on load or just disable GD functionality (for these specific ROMs ONLY) in the case of EEPROM support existing as well.

 

There is no solution which involves blindly ignoring header settings which won’t break something.

Edited February 5, 2023 by SainT

[xhul]

19 minutes ago, SainT said:

or just disable GD functionality (for these specific ROMs ONLY) in the case of EEPROM support existing as well.

If a LNX with both SD & EEPROM support (on the header) can work without freezing, i guess that's not as easy as i thought, indeed.

All i know is that the 6 ROMs i tested have both, and they all freeze.

But i must confess i have no idea what's the purpose of the AUDIN setting.

Anyway, thanks for your time, and good luck figuring that out =]

Edited February 5, 2023 by xhul