#1948 xscpu.exe - factory reset does not reset everything the first time

[radius75]

My sample config and link to the video

https://mega.nz/file/2cQ3lbCL#-i7THqhWHI8vocV2mW3HKe7Wri7Z3y8LQqFK2gyrcPs

[SCPU64]
KeymapIndex=1
SCPU64Name="D:\Gry\_Commodore64\JiffyDOS-full\scpu-dos-2.04.bin"
VICIIExternalPalette=1
VICIIFilter=0
AutostartWarp=0
AutostartDelay=5
Drive8RTCSave=1
DriveSoundEmulation=1
DriveSoundEmulationVolume=205
DosName1541ii="D:\Gry\_Commodore64\jiffydos_1541\JiffyDOS_1541-II_6.00.bin"
DosName1571="D:\Gry\_Commodore64\jiffydos_1571\JiffyDOS_1571_6.01_(310654).bin"
DosName1581="D:\Gry\_Commodore64\jiffydos_1581\JiffyDOS_1581_6.01.bin"
DosName2000="D:\Gry\_Commodore64\JiffyDOS-full\CMD FD-2000 DOS V1.40 CS 33CC6F.bin"
DosName4000="D:\Gry\_Commodore64\JiffyDOS-full\cmd fd-4000 dos v1.40 fd-350022.bin"
DosNameCMDHD="D:\Gry\_Commodore64\JiffyDOS-full\CMD HD BOOTROM v280.bin"
Drive8Type=4844
Drive9Type=1542

[gpz]

Would be great if you could narrow it down by removing as much as possible from that config to still produce the problem.

Really weird bug though - does it only happen in xscpu64?

[radius75]

I will try to test this tomorrow.

[radius75]

This happens for FD2000, FD4000 and CMDHD, in any SCPU configuration.

1st restore to default:
delete CBM drives and FD2000 ROMs links, but FD2000 can still be selected in Periphelar/Drive (FD4000 & CMDHD - did not delete ROMs link)

2nd restore:
delete FD4000 ROM link, but FD2000,FD4000 can still be selected in Periphelar/Drive, (CMDHD - did not delete ROM link)

3rd restore:
delete CMDHD ROMlink, but FD2000,FD4000,CMDHD can still be selected in Periphelar/Drive

4th.restore: I think I managed to restore the default now :) but FD2000,FD4000,CMDHD can still be selected in Periphelar/Drive :O

--
Each of these CMD devices requires restore to be performed twice (last, 3rd and 4th step), and interrupts restore for the next CMD device on the list.

I can only test the ROMs I have.
Perhaps the problem also applies to other roms. You would have to have them all linked at once and test them.

I will also test on x64sc.

[radius75]

On x64sc it behaves the same way

[radius75]

Although links to CMD ROMs have been removed, you can still enable emulation of these devices.
A bit confusing. It seems to work, but if we save the configuration to the .ini file at this point, after restarting the emulator and loading the .ini it will turn out that the CMD device does not work.

[radius75]

A question, but that's for another ticket:
Why when changing the Drive type (e.g. for Dev8, from CMDHD to 1541 Drive change)
Mounted disk "image" (.dhd) remains selected?
Shouldn't it be deleted/freed (set to -NO IMAGE ATTACHED)? When changing the drive type to another either to -None- or after restoring default settings, then for all drives?
This applies to changing any type of drive to another type. Or restore default settings.

e.g. I had 1.dhd mounted in CMDH Dev8, set Dev8 to None, and set CMDHD in Dev9. I couldn't get 1.dhd for him then. The emulator crashed once while trying, no responses.
To do this, you need to restore CMDHD on Dev8, unmount 1.dhd and then mount it in Dev9.

[gpz]

I can not reproduce this - have you tried the development build?

If you can reproduce it in the development build, please try to reproduce it starting with a clean config, and tell each step you did (enabling as few drives and attaching as few extra roms as possible)

[radius75]

Then this must be Windows specific:

-delete vice.ini
-then run x64sc.exe as default
-set manually ROM for FD2000, FD4000, CMDHD
-sed dev8 as CMDHD, FD2000 or FD4000 (no need to insert .dhd or d2m/d4m image)
-reset to default 4 times, observe on each restore: ROM/DriveROM option page, and Dev8 type.

After the fourth restore, we only have Dev8 type 1541-II
Even though the ROM links have been deleted, you can still select these CMD devices in Devices/Drive options.

[gpz]

Is that really the minimal set that is needed? That seems very odd

[radius75]

build 3.7.1 r44554

[radius75]

Conclusion:
After performing restore to default and deleting the link to the CMD device each time, the procedure for restoring default settings for ROMs is interrupted and we do not have 1541-II restored for Dev8.
Only after removing the last CMD ROM link, the restore routine can freely restore 1541-II for Dev8.

--
This is what it looks like from the user's perspective.

[gpz]

Could you also try using the SDL port? It might be a GUI (frontend) issue

[radius75]

I have exactly the same problem on SDL2VICE. Each restore-to-default deletes one path link to the CMD ROM. And only after deleting the last one is it possible to completely restore the default settings.

[radius75]

It seems like it has always existed.
Configuring, for example, CMDHD usually ends with saving it to .ini and, preferably, running it from .bat to immediately connect .dhd.
Nobody switches CMD this way every time.
Just close and restart the emulator.
No one noticed or considered it a significant problem.

[gpz]

OK i could reproduce it now - the key is to name the files different than the default names - else it will work fine. It fails at resetting the settings, because that will try to load the file using the default name - which then fails, and that aborts resetting. Tricky to fix unfortunately.

[radius75]

What are the default names for these files?
Because I changed it to: bootromCMDHD-v2-80.bin, dos2000-cs-33cc6f.bin, dos4000-fd-350022.bin
And it didn't help...
Maybe it's a matter of locating these files in a folder different from Vice?

[radius75]

OK, I know now.
So the only correct place for CMD ROMs is the VICE/DRIVES folder.
And the names must be changed as Vice has by default.
Because it sets default CBM ROMs in the same way.
Can't restore default settings to >none< for CMD ROMs :)

[gpz]

fixed in r44562 - thanks for the report! :)

[radius75]

Thanks.
r44562
Restore-to-default now runs without interruption. :)

Shouldn't it also disable the option to select these drives in the Peripheral Device/Drive section?
Despite the default configuration, they can still be run as if those deleted CMD ROMs were still loaded for CMD device emulation.
This confuses the user, the config.ini saved at this point (without the path to the CMD ROMs) will not work after restarting Vice and loading it.

After restore-to-default I can save this config, which is an error.

[Version]
ConfigVersion=3.7.1

[SCPU64]
Drive9RTCSave=1
Drive9Type=4844

--
There is also the issue of freeing mounted images of data carriers (d64, dhd, etc.) after turning off or changing the type of device assigned to a specific drive ID.
Even after Restore-to-default, the media remains stuck in the non-existent drive. And it cannot be loaded into a drive with a different number.

[gpz]

Shouldn't it also disable the option to select these drives in the Peripheral Device/Drive section?
Despite the default configuration, they can still be run as if those deleted CMD ROMs were still loaded for CMD device emulation.
This confuses the user, the config.ini saved at this point (without the path to the CMD ROMs) will not work after restarting Vice and loading it.

That seems weird indeed - and could be a GUI issue. @compyx can tell perhaps :)

There is also the issue of freeing mounted images of data carriers (d64, dhd, etc.) after turning off or changing the type of device assigned to a specific drive ID.
Even after Restore-to-default, the media remains stuck in the non-existent drive. And it cannot be loaded into a drive with a different number.

These should be fixed in r44570 - please test

[Querino]

That seems weird indeed - and could be a GUI issue. @compyx can tell perhaps :)

i see the same issue in the old winvice gui. it checks fordrive_check_type(DRIVE_TYPE_4000, num - 8)

maybe the driveroms aren't unloaded.

[gpz]

good catch - the flag that indicates that a ROM could be loaded was only ever set to 1, never to 0 again :) r44571 fixes this

I think there is still another problem now... when a ROM can not be loaded, and that particular drive is active, we should probably set the drive type to something else....

Now the GUI behaves a bit odd - the drive will disappear from the list, and the drop down list item that is currently selected will be empty.

Anyway, please test again :)