Problems accessing files on the LynxGD

[Nop90]

After waiiting for about a year I received my card two days ago and I love it. It has a wondeful design.

 

It works fine with commercial roms and most of the homebrews, but has problems with the homebrews that save on the SD like the ones based on my mod of Karri's cart template.

 

My cart has the firmware v1.03 and tested it on two unmodified lynx (a Lynx I and a Lynx II, both with original screen and powered by a regulated 9v power supply).

 

Don't know if it's a problem only with my cart or if it's a general problem. I kindly ask to the other owners of the cart to test it with games like 4ttude, nutmeg or lawnmower, that used to work fine on the old version of the cart. Remember to place the sav file in the /saves folder to test the games.

 

I made a sample program to check what causes the problem, and seems that reading the SD causes some memory leak. If the problem is confirmed on other carts I can share the test program and the sources.

 

 

[SainT]

It's a known issue. The library used for these games had a bug which is stopping it working with the new LynxGD cart, although it works with the old Lynx cart of mine (rather mysteriously really, it really shouldn't).

 

I have made changes to the library and updated GitHub code and pointed out the update is available in the original gamedev thread. @Igor was going to coordinate getting new versions compiled, but I don't think that's happened yet?

[Nop90]

If you refer to the change in the sd init, I already fixed it for most of my games and in the cart template on my github.

 

I'm testing the games with the updated roms. Not to say that the test rom I made uses the last lib on you github (that other than that single line change in the init code, has only the funcions names changed from SD to GD)

 

Attached my test rom with sources and the 128 bytes sav file.

 

Pressing A loads a sound file from cart to memory and plays it.

 

Pressing OPT1: try to save and read (to check the witten values) to EEPROM, but with the value 65 (64 for SD + 1 for EEPROM) in the header file it fails. Works fine with a value of 1 in the header.

 

Pressing OPT2: inits the SD if not done previously, writes values on the SD (that seems to work analyzing the file on the SD) but than reads bad values and corrupts memory. After this printing on screen with TGI gives garbage on the screen and loading from cart hangs the system.

 

I whant to point out that using the value 65 in the header is not the cause. Tested also with 64 and it's the same.

 

Please let me know if the problem is only with my cart or is common to others.

testHQ.zip

[Igor]

9 hours ago, SainT said:

It's a known issue. The library used for these games had a bug which is stopping it working with the new LynxGD cart, although it works with the old Lynx cart of mine (rather mysteriously really, it really shouldn't).

 

I have made changes to the library and updated GitHub code and pointed out the update is available in the original gamedev thread. @Igor was going to coordinate getting new versions compiled, but I don't think that's happened yet?

Thanks for reminding me, I will need to send an email out to all the participants. @Nop90 thanks for sharing that code. I might write up an guide on how to change from one to the other.

[Nop90]

Ok, but the code is not working, like all other games of mine.

 

Could you test it on your lynx GD

[SainT]

On 7/17/2020 at 6:37 AM, Nop90 said:

Ok, but the code is not working, like all other games of mine.

 

Could you test it on your lynx GD

Ah, fantastic, I’ll check that out next week and get it fixed! ?

[Nop90]

I'm making other test, my feeling is that there is something in the way cc65 handles cart segments that conflicts  with the cart.

 

Yesterday i made a sample app that reads and writes correctly on the sd, today i'm goong to convert the same app in a cart rom with segments and I'll check again.

 

I'll try to give you more infos possible before you start checking.

[Nop90]

I made a sample program to better show you the problem (attached a zip with sources and a lnx file).

 

A: init the SD

B: test SD R/W

UP: load chipper data from a cart segment and play a sound

 

the SD seems to work fine in this app (in other test that I made SD operations fail from the second one).

 

Loading from cart and playing chipper sound works fine before the SD init. After SD init the system becomes instable, and the more you acess the SD the worse the system works.

 

Things that can happen:

 - TGI font gets corrupted (garbage chars written to screen) without hanging the code

 - The system loads from carts but doesn't play any sound

 - Loading from cart hangs the system

 - The lynx turns off (really scaring)

 

Hope this helps to find the problem (but maybe it's only my cart to be defective).

testGD.zip

[Nop90]

forgot to say you need a 128 bytes named game.sav in the forlder /saves

[Nop90]

any news?

[+karri]

Perhaps the proper solution is to abandon SD saves. The better alternative is the El Cheapo approach with a real eeprom.

Especially now as we have two SD carts incompatible with each other.

[Nop90]

The LynxGD can emulate eeprom saves, the problem is that the eeprom flag in the rom header must be 1.

 

If you set it to 65 (64 for the SD + 1 for the eeprom) the eeprom emulation is disabled.

 

I dislike this for several reasons:

 - first it behaves differently from Handy emulator, that enables saves with 65 too. I could be wrong, but I consider Handy behaviour as a de facto standard

 - second this makes code for the new cart incompatible with the old RetroHQ cart. fixing only this flag, I could use a workarond to disable the SD write on game boot (on an unreleased version of my template I already can disable it pressing Pause on boot)

 - i have some ideas for programs to be used only with the Lynx GD that uses both SD writes and emulated eeprom saves, if the two flags can't be used together this is impossible

 

Abandoning SD save  is an option, but a lot of people have the old cart...

[Nop90]

@SainT do yo think this problem is fixable?

 

[SainT]

Taking a look now, the only thing the init call does is this --

 

*IODIR = 0;

 

So if that's causing thigns to mis-behave, I'm guessing this value is not correct for your usage. Looking at the EEPROM code it's using $A to set AUDIN to input, which is what this is doing. Give that a try -- it's likely the underlying code to load from the cart expects this register to be a specific value.

Edited September 4, 2020 by SainT

[+karri]

On 8/4/2020 at 5:54 PM, Nop90 said:

64 for the SD + 1 for the eeprom

This is the way I have written my games also. I prefer to release only one binary that works on real eeprom carts, the old SD cart and hopefully the new LynxGD. I see no benefit in requiring separate builds.

[Nop90]

On 9/4/2020 at 12:33 PM, SainT said:

Taking a look now, the only thing the init call does is this --

 

*IODIR = 0;

 

So if that's causing thigns to mis-behave, I'm guessing this value is not correct for your usage. Looking at the EEPROM code it's using $A to set AUDIN to input, which is what this is doing. Give that a try -- it's likely the underlying code to load from the cart expects this register to be a specific value.

I already tried to backup the IODIR state before the SD init, and restore it before reading again from the cart.

 

I think the cause is in the LynxGD internal state.

[SainT]

On 9/6/2020 at 3:58 PM, Nop90 said:

I already tried to backup the IODIR state before the SD init, and restore it before reading again from the cart.

 

I think the cause is in the LynxGD internal state.

 

Rather than backing it up, though, have you tried using $A instead of $0? I happened to use 0 just because I didn't need to acess the cart again through the normal access mechanism and that set everything to input.

 

It can't be anything to do with the LynxGD as such, as all the init call (which is causing the issue) is doing is changing one register on the Lynx. This doesn't affect the microcontroller or other aspects of the LynxGD in any way.

 

[SainT]

I've tried recompiling the test code so I could have a mess around with it, but it's been developed with an old version of CC65. I've made a few changes to get it compiling, but it's not running. The issue is not with the LynxGD hardware side. As I say, if --

 

*IODIR = 0;

 

is causing the program to start mis-behaving, it is ONLY a change to the state of the Lynx hardware. It does not affect the cartridge in any way, it just allows the Lynx to read the AUDIN pin being driven by the cart.

 

Using $A (input, needed for LynxGD) and $1A (output.... shouldnt be required) to change the state of the AUDIN pin seem to be the preferred values (looking at crt0.s in CC65 for the Lynx). Backing up and restoring this register will also NOT WORK. It's a WRITE ONLY register, reading will just get you all 0's I think, there is a shadow you can use to read in CC65 called __iodir -- this could always be manipulated correctly as well --

 

__iodir &= 0xf;  // input

*IODIR = __iodir;

__iodir |= 0x10;  // output

*IODIR = __iodir;

 

I would test these myself, but I'm lacking a good way of doing so. I'm pretty sure this will solve it for you, as IODIR needs to be setup correctly to write to the shift register to set the block for cart access. IODIR being set to 0 means there will be no data going out to the shift register.

[SainT]

Any luck with this?

[+karri]

As I do not have a LynxGD I wonder if you can use my stuff on the LynxGD?
onduty.lnx

onduty.sav

onduty.lsd

 

The code tries to use /saves/onduty.sav for storing the data.

 

The question is: does it store progress on the SD cart when you turn the Lynx off/on?

[Nop90]

2 hours ago, SainT said:

Any luck with this?

I was busy. I'll try to find time to make more test in the week end.

[Nop90]

1 hour ago, Nop90 said:

I was busy. I'll try to find time to make more test in the week end.

Had some free time and made a quick test: seems that restoring IODIR val to 16 (0xa) everything works fine.

 

I'll update my template with this fix and rebuild my old games. I'm going to add a LynxGD_Deinit() function in the Lynx_GD.c file.

[SainT]

4 hours ago, Nop90 said:

Had some free time and made a quick test: seems that restoring IODIR val to 16 (0xa) everything works fine.

 

I'll update my template with this fix and rebuild my old games. I'm going to add a LynxGD_Deinit() function in the Lynx_GD.c file.

 

Awesome, I had a feeling that would be the issue! I dont *think* anything else modifies the IODIR register, so you should be good just changing the init to 0xa and be done with it. If anything does change it, though, the init would need to be called before any GD calls.

[Nop90]

You are right, in LynxGD_Init() setting IODIR to 0xa instead of setting it to 0 fixes everything.

 

Now I love your SD cart ?

[thefred]

11 hours ago, karri said:

As I do not have a LynxGD I wonder if you can use my stuff on the LynxGD?
onduty.lnx

onduty.sav 128 B · 0 downloads

onduty.lsd 8.2 kB · 0 downloads

 

The code tries to use /saves/onduty.sav for storing the data.

 

The question is: does it store progress on the SD cart when you turn the Lynx off/on?

Looks it froze after the mission, I get a shadow of a person and it doesn't get past that point. Is that where it saves? Music continues. Buttons don't seem to do anything.

I turned it off and back on and it started from the beginning. That is with the new gd. Ill try on the elchepo and see if I get the same results.