WHDLoad MantisBT - Subwar2050
View Issue Details
0004302Subwar2050[All Projects] Generalpublic2019-11-26 10:562020-04-06 23:39
Assigned ToJOTD 
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
ChipMem2 MB
FastMem8 MB
WorkbenchOS 3.1
KickROM45 - Kick 3.1.4
Summary0004302: Problem: Game seems not to be saved after completing a mission. The manual
DescriptionGameVersion: german,pal,2 cd32
SlaveVersion: 1.3 from 08.04.2017

Problem: Game seems not to be saved after completing a mission.
The manual states: "At the end of a mission your game will be saved to the CD32 Save Area. Please ensure that no more than 70 slots are locked...before loading the game for the first time"
I'm running the CD32 install of the game under Wb3.1 on a TF328 with 8MB Fast RAM.
I've set up my system that nonvolatile.library saves into the directory dh0:nv_stores instead using the non volatile memory:
- created the file sys:prefs/env-archive/sys/nv_location
- put the line "dh0:nv_stores" into that file
Now whenever a game is saving to non volatile memory a directory with the game name is created in dh0:nv_stores.
Now the saved items can be explored using some tools from aminet, e.g. nvcontrol or nv_editor.
But after I played the Subwar 2050 CD32 install I noticed that there wasn't anything saved in dh0:nv_stores.
And each time I start the game again I'll have to re-enter the pilot name and start from the 1st mission.
TagsNo tags attached.
Attached Filesjpg IMG_20200207_111108107.jpg (90,550) 2020-02-07 11:42

? nvram (78) 2020-02-08 12:09
? nvram_2020-02-16 (78) 2020-02-16 12:35
zip Subwar2050.zip (5,034) 2020-03-31 11:24

2020-02-04 22:16   
what about the attached slave? I have changed nonvolatile to Bert implementation, much simpler
2020-02-07 11:42   
Sadly now it crashes when starting the game for the 2nd time.

I've played the first short mission, then rebooted the CD32 to check if the game state has been saved.

When starting the game again, an exception occurred. I've attached a screenshot of the situation.
2020-02-07 22:54   
there should be a new file created. Can you attach that one?
2020-02-08 12:09   
I found one new created file: 'nvram' - see the attachment. It is created by the new slave inside 'data' directory of the game.

I also noticed, that this file always is created inside the 'data' dir, it doesn't matter what is set in:






After renaming / deleting the 'nvram' file, the new slave is starting again for one time without throwing an exception. Then it creates the file again and the next start of the slave isn't possible because the exception is thrown again.
2020-02-08 13:24   
But maybe the problem isn't due the slave but rather to my 'exotic' configuration..running the game from the Workbench on a real CD32?

Regarding this I noticed the follwoing:

Yesterday I played Reshoot-R. When I started it again today I saw that my yesterdays highscores where displayed. They were saved properly. But I didn't see, where. No 'nvram' file, and no trace of Reshoot-R in my global dh0:nv_stores (which is set in env:sys/nv_location).

They must be saved in the 'real' cd32 nv memory.

I verified that in my other environment, a WinUAE A1200 emulation, the Highscores are saved into env:sys/nv_location.

So, maybe being run a real CD32 might be reason, not so much the slave.

I'll doing some more testing tomorrow.
2020-02-08 20:13   
(Last edited: 2020-02-08 20:14)
no, whdload doesn't use real nonvolatile library. it's not related to CD32.

BTW: if you reboot (and don't quit cleanly) it's not surprising that the game isn't saved. You have to quit whdload, not reboot.

2020-02-13 18:46   
Bert fixed an issue with the new nv system. Slave attached. I have tested with your nvram file and it indeed starts in german. Without the file, it asks for language.

And it doesn't seem to be saved unless you complete a mission, as you said. Can you test the new attached slave and report?
2020-02-15 19:39   
The new version doesn't crash when reloading. But sadly it also doesn't save game after the first mission. I had just started it, entered a pilot name and finishend the first, short mission which is called "Navigation test". After re-starting the CD32 all these infos are gone.

But I made the test on my CD32 where the nvram file had been created by former slave already. (I haven't been asked for language when started the game today). So tomorrow I'll delete that nvram file and give it another test.
2020-02-16 03:51   
if by "re-starting the CD32" you mean rebooting with the reset button without quitting whdload cleanly, that's expected. Save files are cached and only written when quitting (or at once only if the file didn't exist)

It's a known limitation with whdload (and with Windows, Linux ... :)). You cannot quit by switching off or you may lose info.

Can you confirm that you're quitting whdload BEFORE resetting/turning off the CD32?
2020-02-16 12:35   
Quitting properly still did't fix it. The following steps I performed:

1) Assigned QuitKey=$100 to be able to exit the game with the left mouse button.

2) Renamed {game_dir}/data/nvaram to nvram.bak

3) Started the game. Have been asked for language, set it to German.

4) Entered Changed name of the pilot from default "Pilot 1" to "Oscott" and changed the face image, too.

5) Completed first mission "Navigation test"

6) Checked the pilots roaster and verified that pilot "Oscott" got the $1.500,- reward for the first mission.

7) Exit the game with left mouse buton.

8) Waited a little on Workbench; not rebooting the CD32 this time.

9) Started the game again. Being not asked aked for language anymore. Entered the pilots roaster and my pilot "Oscott" doesn't exist anymore.

Thereby the file {game_dir}/data/nvaram was newly created. I've attached it, in case it could be helpful.
2020-03-31 09:20   
@JOTD: can you please build/attach a Slave using the latest nonvolatile.s?
2020-03-31 11:24   
@Wepl done.
@oscott can you test the latest attached slave?
2020-03-31 21:39   
@JOTD but when saving did not work with the old Slave using disk nonvolatile.library there must be other reason for not saving.
The created nvram contains one slot with Options only. I assume there will be other slots one for each Pilot.
2020-03-31 22:15   
@oscott how do you quit your game after having saved it? rebooting amiga doesn't guarantees that the last write to the file works.

Did you notice some "flashing" when saving the mission progress?
2020-04-01 20:08   
Sadly with the new slave the same results as in ~7745.

Over the weekend I'll test some more things, e.g. burning the ISO image file and play the game once from CD. I'll try to find out if the pilot name and mission state is saved at all after the first short 'mission' Navigation test.

@JOTD The flashing I notice only when starting the game for the first time after having deleted the file data/nvaram. Then it flashes right after entering the pilot name and leaving the pilot menu. But not after completing the mission.
2020-04-01 20:12   
@JOTD PS I quit the game after the first mission from main screen using the WHDLoad quit key which I've set to LMB, as I'm not always having a keyboard connected to the CD32.
2020-04-06 11:33   
I played the game directly from CD on CD32 with enough free slots for saving the game.

Exactly the same result as with WHDload.

Language selection is saved. Pilot name is not saved after completing the first mission mission Navigation test. So I don't know at which point the game actually does save the pilots name / mission state.

But it seemingly has nothing to do with the whdload slaves.

I'm very sorry but it seems I've wasted your time:-(
2020-04-06 23:39   
don't worry about this! you can ask for help at eab forum

Issue History
2019-11-26 10:56administratorNew Issue
2019-11-26 10:56administratorStatusnew => assigned
2019-11-26 10:56administratorAssigned To => JOTD
2020-02-04 22:16JOTDFile Added: Subwar2050.zip
2020-02-04 22:16JOTDNote Added: 0007686
2020-02-07 11:42oscottFile Added: IMG_20200207_111108107.jpg
2020-02-07 11:42oscottNote Added: 0007688
2020-02-07 22:54JOTDNote Added: 0007696
2020-02-08 12:09oscottFile Added: nvram
2020-02-08 12:09oscottNote Added: 0007698
2020-02-08 13:24oscottNote Added: 0007699
2020-02-08 20:13JOTDNote Added: 0007703
2020-02-08 20:14JOTDNote Edited: 0007703bug_revision_view_page.php?bugnote_id=7703#r1095
2020-02-13 18:44JOTDFile Deleted: Subwar2050.zip
2020-02-13 18:45JOTDFile Added: Subwar2050.zip
2020-02-13 18:46JOTDNote Added: 0007710
2020-02-15 17:28JOTDStatusassigned => feedback
2020-02-15 19:39oscottNote Added: 0007724
2020-02-15 19:39oscottStatusfeedback => assigned
2020-02-16 03:51JOTDNote Added: 0007740
2020-02-16 03:51JOTDStatusassigned => feedback
2020-02-16 12:35oscottFile Added: nvram_2020-02-16
2020-02-16 12:35oscottNote Added: 0007745
2020-02-16 12:35oscottStatusfeedback => assigned
2020-03-31 09:20WeplNote Added: 0008013
2020-03-31 11:23JOTDFile Deleted: Subwar2050.zip
2020-03-31 11:24JOTDFile Added: Subwar2050.zip
2020-03-31 11:24JOTDNote Added: 0008015
2020-03-31 21:39WeplNote Added: 0008018
2020-03-31 22:15JOTDNote Added: 0008020
2020-03-31 22:15JOTDStatusassigned => feedback
2020-04-01 20:08oscottNote Added: 0008023
2020-04-01 20:08oscottStatusfeedback => assigned
2020-04-01 20:12oscottNote Added: 0008024
2020-04-06 11:33oscottNote Added: 0008064
2020-04-06 23:39JOTDStatusassigned => closed
2020-04-06 23:39JOTDResolutionopen => no change required
2020-04-06 23:39JOTDNote Added: 0008068