- --
Viewing Issue Advanced Details
ID | Category [?] | Severity [?] | Reproducibility | Date Submitted | Last Update |
---|---|---|---|---|---|
07705 | Media Support | Minor | Always | Jul 12, 2020, 18:23 | Oct 27, 2022, 18:14 |
Tester | M.A.S.H. | View Status | Public | Platform | MAME (Official Binary) |
Assigned To | Resolution | Open | OS | Windows 10 (64-bit) | |
Status [?] | Confirmed | Driver | |||
Version | 0.222 | Fixed in Version | Build | 64-bit | |
Fixed in Git Commit | Github Pull Request # | ||||
Summary | 07705: guab [gaub3], tenup [tenup]: File save error | ||||
Description |
Give us a Break and Ten Up show 'File save error' at start (see "MAME 0.222 Give us a Break - Ten Up.png" snapshots). MAME 0.222: * Improved HLD behavior, always activating output at start of type II & III commands (machine\wd_fdc.cpp) [AJR]. * Improved HLD/HLT handling, fixed FD1771 timings and enable spinup_on_interrupt. Do not delay SEEK with no Verify flag. Improved write protection. Set BUSY during initial restore to make it correctly interruptable. Accept new commands while in busy state, workaround for spurious recursive calls if HLD used for drive motor control, don't change track and data registers during reset (machine\wd_fdc.cpp) [MetalliC]. * READ/WRITE macros removal [Osso]. |
||||
Steps To Reproduce | mame guab -flop D:\Softwarelist\guab\guab3.zip | ||||
Additional Information | |||||
Github Commit | |||||
Flags | |||||
Regression Version | 0.222 | ||||
Affected Sets / Systems | guab [gaub3], tenup [tenup] | ||||
Attached Files
|
MAME 0.222 Give us a Break - Ten Up.png (19,961 bytes) Jul 12, 2020, 18:23 Uploaded by M.A.S.H.
| ||||
Relationships
There are no relationship linked to this issue. |
Notes
4
No.17825
Tafoid Administrator
Jul 12, 2020, 19:29
|
Very odd it seems to It seems to work fine if loaded as a software list item without a path, with or without the media identifier (-flop) Working: mame64 guab gaub3 mame64 guab -flop gaub3 mame64 tenup tenup mame64 tenup -flop tenup Not Working: mame64 guab -flop d:\software\guab\gaub3.zip mame64 tenup -flop d:\software\guab\tenup.zip |
---|---|
No.17826
Tafoid Administrator
Jul 12, 2020, 19:32
edited on: Jul 12, 2020, 19:32 |
Likely issue here as only noticed used device which saw changes on the day of breakage for me (June 2, 2020): https://github.com/mamedev/mame/commit/28108a27b98bad1b266971ff1432be1710e47a2e wd_fdc.cpp honor write protection (nw) |
No.20667
M.A.S.H. Senior Tester
Oct 26, 2022, 19:47
|
Many new changes to wd_fdc.cpp, but bug is still happend! https://git.redump.net/mame/commit/?id=99b3304c5ba49471065e4bc4b9ea23669c2f3021 https://git.redump.net/mame/commit/?id=f5eeb2681d2cc1af975cd5cbd161b78644d68d51 https://git.redump.net/mame/commit/?id=b5a7c3025a14b4152e00b80d56f795ba1c924046 https://git.redump.net/mame/commit/?id=48eee89e3cff2f5a1ce190904a457cc8c136be39 |
No.20672
Haze Senior Tester
Oct 27, 2022, 18:14
|
Direct path access to disk images stored in zip files is likely write-protected by default, as not to modify images etc. (destructive behaviour is undesirable, and MAME wouldn't know where to write image file changes anyhow) I'd say this is working as designed. That said, I don't really think these machines should be using the software lists for game revisions anyway, it tends to not be how arcade games are handled in MAME as this was never consumer hardware, and the user would not be expected to change the game media, nor would the operator even be changing it unless they were sent an upgrade kit. |