Version 0.9.1beta5 released for testing!

[Scorpei]

......
M3lite (just got it, kernel V29)
SuperCard SD (v163, not the newest one but with lattice chip)
........
-Scor

Tested card:Working?:save:version
------------------------------
M3lite_: yes! : yes! : FAT
SC-SD : nope : nope : FAT

[Shadow_Zero]

This release works with the Transcend 1gb mini-sd card!
With the L-button that is.
And save games work straight away with Monkey Island 2

Unfortunately it doesn't work with my Kingston 1gb mini-sd card!
So I guess I'll have to give up on that one boohoo...

To others who have problems booting with L, are you pressing it on time? I had a few occasions I apparently wasn't fast enough. I press L even before the red loading bar appears, so basically right after booting SCUMMVM.

EDIT:
Formatted the Kingston to FAT16 and it seems to work now *keeps fingers crossed*

Right. It seem like whenever I have booted Monkey Island 2 (or made a save game, not sure which is the case) the next time I boot SCUMMVM it hangs at the infamous "zip" part.
I'll do some testing if deleting and re-copying has some effect and if not if a format has any effect.
I knew it was too good to be true

[agentq]

Is is perhaps losing the M3 Mode setting?

[agentq]

Your explanation: When pressing the L-key ScummVM stores in the SRAM that a M3 is used. With the next start ScummVM recognizes in the SRAM that the M3 is used.

That would mean that you can recognize, if a SRAM is present. How would it thus be, if you indicate a menu in the case when starting, if still no appropriate data lie in the SRAM?

Because as mentioned before, the GBAMP, MMD, and NinjaDS don't have SRAM, so those cards must boot without an SRAM setting present to avoid having a menu on each boot.

[kedest83]

But so the detection of holding the L-key isn't working for everyone. I've tried many times now.
Can't this procedure be changed? Perhaps something like a small 2 second countdown (Press a button now to load M3 driver...2...1....button press detected, loading M3

[tetzlaff]

Supercard Lite, v1.63, 2GB Micro Sandisk:
Beta 5 hangs after "Flash card reader not found!"
Beta 5 w/"Moonshell patch" hangs after "Flash card reader not found!"
Beta 4 hangs after "Zip file check...Not in use!"
Beta 4 w/"Moonshell patch" hangs after "Zip file check...Not in use!"
Beta 3 hangs after "Flash card reader not found!"
Beta 3 w/"Moonshell patch" gets to main menu. After choosing "passport", it exits with the following error "(3:1:0x32A): Room 3 missing object code block(s)". It should be noted that the scummvm.ini file was successfully created.
v0.6 Loaded Monkey Island Dos. Saved a game. Saved game in list, but could not be loaded. After trying to reload, my flash card contents were lost.

Supercard, v1.63, 2GB PQI:
Beta 5 hangs after "Flash card reader not found!"
Beta 4 hangs after "Zip file check...Not in use!"
Beta 3 gets to main menu. After choosing "passport", it exits with the following error "(3:1:0x32A): Room 3 missing object code block(s)". It should be noted that the scummvm.ini file was successfully created.
v0.6 Loaded Passport to adventure. Saved a game. loaded the save.

I think my 2GB Sandisk is toast. I can't reformat it. Its hanging up my windows now.

[tetzlaff]

I no longer think its broken. Its toasted.

-Edit

I just fixed the card. My work laptop has a built in SD card reader, and it was able to reformat the card using the dos format command.

[Scorpei]

Beta5 FAT works like a charm on my GBAMP.
EZflash IV lite sadly not (haven't tried to run it through the patcher though).
Logically DSlink doesn't work...

[Scorpei]

Right. It seem like whenever I have booted Monkey Island 2 (or made a save game, not sure which is the case) the next time I boot SCUMMVM it hangs at the infamous "zip" part.
I'll do some testing if deleting and re-copying has some effect and if not if a format has any effect.
I knew it was too good to be true

I've just tested with my M3lite, when I boot up Monkey Island 2 and reset it (via quit in the menu) I am able to boot again (without pressing L again). Also when I save (Monkey Island2 or any other game for that matter) I am still able to get beyond the zip part.

[JackTF]

Because as mentioned before, the GBAMP, MMD, and NinjaDS don't have SRAM, so those cards must boot without an SRAM setting present to avoid having a menu on each boot.

That's why I suggested only to show a menu if an SRAM is present. Only if you can recognize it at first start.

[sittingduck]

I will have to agree. Holding the L button yields bad results for me. Most of the time it doesn't detect that the L button is held down. However, a couple of times it workd although it lost the setting on next boot. This is on the *a.nds build. The *b.nds never detects the L button. The *.gba.ds builds never detects although renamed to *.nds. This is on an M3 Lite with a SanDisk 1 gig card.

[Metal_Spirit]

sittingduck, for the m3 to remember the settings on the next boot you have to install scummvm using the game manager (just install, don´t change any parameters).

Have you done this??

[Scorpei]

sittingduck, for the m3 to remember the settings on the next boot you have to install scummvm using the game manager (just install, don´t change any parameters).

Have you done this??

Huh, I've never run scummvmDS fat through the M3 manager and the settings are always remembered (or do you mean the GBA-flash version?).

[Metal_Spirit]

Are you shure? Are you using a version that requires pressing L to detect the m3?
Have you runned other .nds app in the meantime? Oh and remember... no zip method can be used!.

The M3 keeps the data in memory untill other .nds app is runned, so if you run scumm several times in a row, it should work ok, but if you run another nds (not gba) app, like a game, in the midle, data should be lost (you will know when data is in memory because at boot m3 will report an error saying it cannot save. While this error remains, data is in memory and scumm will use it, but the only way to keep it for good is by creating the .dat file with the game manager).

I really don´t know how agentq implemented the storage of the m3 choice, but I really don´t see any other way except saving in the .dat file. The problem relyes on the fact that untill the m3 driver is initialized there is no way to acess the card for a second time, so, nothing can be saved on the ini file simply because she cannot be read until the driver is initialized. I see no alternative except the .dat file.

[JackTF]

Are you shure? Are you using a version that requires pressing L to detect the m3?
Have you runned other .nds app in the meantime? Oh and remember... no zip method can be used!.

The M3 keeps the data in memory untill other .nds app is runned, so if you run scumm several times in a row, it should work ok, but if you run another nds (not gba) app, like a game, in the midle, data should be lost (you will know when data is in memory because at boot m3 will report an error saying it cannot save. While this error remains, data is in memory and scumm will use it, but the only way to keep it for good is by creating the .dat file with the game manager).

I really don´t know how agentq implemented the storage of the m3 choice, but I really don´t see any other way except saving in the .dat file. The problem relyes on the fact that untill the m3 driver is initialized there is no way to acess the card for a second time, so, nothing can be saved on the ini file simply because she cannot be read until the driver is initialized. I see no alternative except the .dat file.

I think so. Thats the reason because he don't wanted to show a menu on first start. It is impossible to detect wether it is the first start when no SRAM is present. The SRAM is filled by the GameManager-Client on NDS with the dat-file. That's why it must be possible to detect wether there is a SRAM. And so it must be possible to show the menu on first start only if there is a SRAM.