1
clrmame Discussion / Re: Scanner: trackfld ROM disappears at scan/fix
« on: 27 September 2023, 19:03 »
Aha, that explains it. Interesting.
Thanks for that.
With kind regards,
NU.
Thanks for that.
With kind regards,
NU.
- 20 April 2024, 12:33
- Welcome, Guest
News:
The new forum is online, hope you enjoy it!
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1] 2
2
clrmame Discussion / Re: Scanner: trackfld ROM disappears at scan/fix
« on: 27 September 2023, 05:34 »
Well, simplicity rules, however I'm not so sure if that goes for MAME and it's exceptions 
I'm interested to know why you couldn't reproduce it on the one machine.
If it was a timing issue, I can understand, but to me this looked very much like a repeatable sequence.
With kind regards,
NU.
I'm interested to know why you couldn't reproduce it on the one machine.
If it was a timing issue, I can understand, but to me this looked very much like a repeatable sequence.
With kind regards,
NU.
3
clrmame Discussion / Re: Scanner: trackfld ROM disappears at scan/fix
« on: 26 September 2023, 15:55 »
Any time
Thanks for fixing (confirmed), Roman.
NU.
Thanks for fixing (confirmed), Roman.
NU.
4
clrmame Discussion / Re: Scanner: trackfld ROM disappears at scan/fix
« on: 26 September 2023, 06:04 »
Well, that's weird and interesting indeed.
I constantly end up with this:
missing rom: hipoly\2.4a [size: 8192] [CRC32: 2d6fc308] [SHA1: 1ff95384670e40d560703f2238998a8e154aa4cf]
It's not in my backup folder.
I get this, when I do a scan/fix all answering with "yes" only:
Do you want to rename the following wrong named ROMs?
hyprolymb\2764.1 -> hipoly\1.11d
hyprolymb\3.a4 -> hipoly\2.4a
Set: Track & Field
Name: trackfld
File: D:\temp\cmp_trackfld_test\rebuild\trackfld\hipoly\1.11d
Do you want to add the missing ROM?
Set: Track & Field
Name: trackfld
File: D:\temp\cmp_trackfld_test\rebuild\trackfld\hipoly\1.11d
Do you want to remove the file?
Set: Track & Field
Name: trackfld
File: D:\temp\cmp_trackfld_test\rebuild\trackfld\hipoly\2.18a
Do you want to remove the file?
Set: Track & Field
Name: trackfld
File: D:\temp\cmp_trackfld_test\rebuild\trackfld\hipoly\2.4a
Do you want to remove the file?
Missing
·Sets 0/1
·ROMs 2/57
·CHDs -/0
·Samples -/0
·Bytes 16kb/1mb
New Scan
Set: Track & Field
Name: trackfld
File: D:\temp\cmp_trackfld_test\rebuild\trackfld\hipoly\1.11d
Do you want to add the missing ROM?
Missing
·Sets 0/1
·ROMs 1/57
·CHDs -/0
·Samples -/0
·Bytes 8kb/1mb
Ending up with this:
missing rom: hipoly\2.4a [size: 8192] [CRC32: 2d6fc308] [SHA1: 1ff95384670e40d560703f2238998a8e154aa4cf]
In backup there is:
hipoly\1.11d SHA-1: 057981ad3b04239662bb19342e9ec14b0dab2351
hipoly\2.4a SHA-1: 4fbb2fcdf9bc7a3d273dbc27b8157f163ff9bf11
hipoly\2.18a SHA-1: b6827592095543c92384a7e8b817a741d249cff8
hyprolymb\3.a4 SHA-1: d031b033d23d50a5f708f630945602e61d52d1e4
hyprolymb\2764.1 SHA-1: 057981ad3b04239662bb19342e9ec14b0dab2351
Do you get these exact same steps?
My guess is that is goes wrong in the very first rename hyprolymb\3.a4 -> hipoly\2.4a
3.a4 is the 2.4a one missing in the end and 2.4a is already there before the rename.
After the rename hipoly\2.4a is still there, but is the wrong one (SHA-1: 4fbb2fcdf9bc7a3d273dbc27b8157f163ff9bf11)
That's why I get this step later:
Set: Track & Field
Name: trackfld
File: D:\temp\cmp_trackfld_test\rebuild\trackfld\hipoly\2.4a
Do you want to remove the file?
hyprolymb\3.a4 (the one I need)is gone after the first rename.
So it looks like the rename/move step fails here.
I tested it on 2 different systems, same result.
Regards, NU.
I constantly end up with this:
missing rom: hipoly\2.4a [size: 8192] [CRC32: 2d6fc308] [SHA1: 1ff95384670e40d560703f2238998a8e154aa4cf]
It's not in my backup folder.
I get this, when I do a scan/fix all answering with "yes" only:
Do you want to rename the following wrong named ROMs?
hyprolymb\2764.1 -> hipoly\1.11d
hyprolymb\3.a4 -> hipoly\2.4a
Set: Track & Field
Name: trackfld
File: D:\temp\cmp_trackfld_test\rebuild\trackfld\hipoly\1.11d
Do you want to add the missing ROM?
Set: Track & Field
Name: trackfld
File: D:\temp\cmp_trackfld_test\rebuild\trackfld\hipoly\1.11d
Do you want to remove the file?
Set: Track & Field
Name: trackfld
File: D:\temp\cmp_trackfld_test\rebuild\trackfld\hipoly\2.18a
Do you want to remove the file?
Set: Track & Field
Name: trackfld
File: D:\temp\cmp_trackfld_test\rebuild\trackfld\hipoly\2.4a
Do you want to remove the file?
Missing
·Sets 0/1
·ROMs 2/57
·CHDs -/0
·Samples -/0
·Bytes 16kb/1mb
New Scan
Set: Track & Field
Name: trackfld
File: D:\temp\cmp_trackfld_test\rebuild\trackfld\hipoly\1.11d
Do you want to add the missing ROM?
Missing
·Sets 0/1
·ROMs 1/57
·CHDs -/0
·Samples -/0
·Bytes 8kb/1mb
Ending up with this:
missing rom: hipoly\2.4a [size: 8192] [CRC32: 2d6fc308] [SHA1: 1ff95384670e40d560703f2238998a8e154aa4cf]
In backup there is:
hipoly\1.11d SHA-1: 057981ad3b04239662bb19342e9ec14b0dab2351
hipoly\2.4a SHA-1: 4fbb2fcdf9bc7a3d273dbc27b8157f163ff9bf11
hipoly\2.18a SHA-1: b6827592095543c92384a7e8b817a741d249cff8
hyprolymb\3.a4 SHA-1: d031b033d23d50a5f708f630945602e61d52d1e4
hyprolymb\2764.1 SHA-1: 057981ad3b04239662bb19342e9ec14b0dab2351
Do you get these exact same steps?
My guess is that is goes wrong in the very first rename hyprolymb\3.a4 -> hipoly\2.4a
3.a4 is the 2.4a one missing in the end and 2.4a is already there before the rename.
After the rename hipoly\2.4a is still there, but is the wrong one (SHA-1: 4fbb2fcdf9bc7a3d273dbc27b8157f163ff9bf11)
That's why I get this step later:
Set: Track & Field
Name: trackfld
File: D:\temp\cmp_trackfld_test\rebuild\trackfld\hipoly\2.4a
Do you want to remove the file?
hyprolymb\3.a4 (the one I need)is gone after the first rename.
So it looks like the rename/move step fails here.
I tested it on 2 different systems, same result.
Regards, NU.
5
clrmame Discussion / Scanner: trackfld ROM disappears at scan/fix
« on: 24 September 2023, 05:46 »
Hi Roman,
Got one for you to check.
crlmamepro 4.047 used, default settings.
Scan/fix "MAME 0.258 ROMs (merged)" to "MAME 0.259 ROMs (merged)" loses a ROM for the trackfld set.
Content and steps (text file) to reproduce are in the zipfile.
With kind regards,
NU.
Got one for you to check.
crlmamepro 4.047 used, default settings.
Scan/fix "MAME 0.258 ROMs (merged)" to "MAME 0.259 ROMs (merged)" loses a ROM for the trackfld set.
Content and steps (text file) to reproduce are in the zipfile.
With kind regards,
NU.
6
clrmame Discussion / Re: Trimming of a leading space in a filename
« on: 22 December 2022, 16:33 »
Neat, thanks!
Works like a charm.
Happy holidays!
Works like a charm.
Happy holidays!
7
clrmame Discussion / Re: Trimming of a leading space in a filename
« on: 17 December 2022, 08:12 »
Ah, great, good catch.
Would it be possible to add a warning to the parser?
Would it be possible to add a warning to the parser?
8
clrmame Discussion / Re: Trimming of a leading space in a filename
« on: 15 December 2022, 14:35 »
Everything default, no 7z involved, just zip.
Yes, the OS kills the leading space.
Yes, the OS kills the leading space.
9
clrmame Discussion / Re: Trimming of a leading space in a filename
« on: 15 December 2022, 13:20 »
The ROM entries in the generated (not with CMP but with SabreTools) datfiles are 1-on-1 copies of the original raw XML file entries.
Hence the reference to the commit that fixes the original XML, which contained the leading space in the first place.
After rebuilding with CMP, the filename in the zipfile does not have the leading space.
Apparently with RomVault it does.
So somewhere in the process, the leading space is lost.
Hence the reference to the commit that fixes the original XML, which contained the leading space in the first place.
After rebuilding with CMP, the filename in the zipfile does not have the leading space.
Apparently with RomVault it does.
So somewhere in the process, the leading space is lost.
10
clrmame Discussion / Re: Trimming of a leading space in a filename
« on: 15 December 2022, 10:27 »
No, it's something clrmamepro changes from source to end result, so the warning should be there IMO.
The generated entry (filename) is the same as the RAW source XML.
The generated entry (filename) is the same as the RAW source XML.
11
clrmame Discussion / Re: Trimming of a leading space in a filename
« on: 15 December 2022, 10:07 »
It was an entry from a generated merged XML, not the raw XML
12
clrmame Discussion / Trimming of a leading space in a filename
« on: 15 December 2022, 08:33 »
Hi Roman,
We ran into this issue with the dogfight entry in SoftList msx1_cass.xml.
<rom name="dogfights\ zero fighter - dog fighter (1985)(microbyte)(es)[bload'cas-',r].cas" size="8534" crc="94a480e2" sha1="da0f4e2660ca03e3403e7d22945ea9bae89ab571" />
Notice the leading space before the "zero".
I agree it being a bug (reported) that needs trimming, but is there a way for CMP to (always) warn if this is the case instead of doing it silently?
It would be easier to notice and report bugs like these.
It now took someone using RomVault (not trimming) to notice the 2 byte difference in result between the datfile and the ROMs set.
Also referring to:
https://www.emulab.it/forum/index.php?topic=5942
https://github.com/mamedev/mame/commit/f898e47c0335fd5469645dc0e6a1b8df2b67fae1
With kind regards, NU.
We ran into this issue with the dogfight entry in SoftList msx1_cass.xml.
<rom name="dogfights\ zero fighter - dog fighter (1985)(microbyte)(es)[bload'cas-',r].cas" size="8534" crc="94a480e2" sha1="da0f4e2660ca03e3403e7d22945ea9bae89ab571" />
Notice the leading space before the "zero".
I agree it being a bug (reported) that needs trimming, but is there a way for CMP to (always) warn if this is the case instead of doing it silently?
It would be easier to notice and report bugs like these.
It now took someone using RomVault (not trimming) to notice the 2 byte difference in result between the datfile and the ROMs set.
Also referring to:
https://www.emulab.it/forum/index.php?topic=5942
https://github.com/mamedev/mame/commit/f898e47c0335fd5469645dc0e6a1b8df2b67fae1
With kind regards, NU.
13
clrmame Discussion / revx.zip scanner weirdness
« on: 24 October 2022, 09:11 »
Hi Roman,
I ran into this little weirdness while scanning/fixing the split and non-merged sets.
The zipfile revx.zip contains 4 duplicate ROMs that exist in the zipfile with different names.
"revx.u51" CRC(9960ac7c) SHA1(441322f061d627ca7573f612f370a85794681d0f)
"revx.u52" CRC(fbf55510) SHA1(8a5b0004ed09391fe37f0f501b979903d6ae4868)
"revx.u53" CRC(a045b265) SHA1(b294d3a56e41f5ec4ab9bbcc0088833b1cab1879)
"revx.u54" CRC(24471269) SHA1(262345bd147402100785459af422dafd1c562787)
In the 0.249 datfile, these 4 files are being renamed, but same files are already present in the zipfile with these name.
The clrmamepro (4.046b) scanner (all fix options enabled) shows an error that it failed to unpack revx.u53 and revx.u54.
The zipfile test OK and I can unpack these files with no problem.
This commit makes the changes:
https://github.com/mamedev/mame/commit/23c7f300965c5ea374ff0aad9d58d74c14f18961
Any idea what's causing the scanner to produce these errors?
Files to reproduce attached.
With kind regards, NU.
I ran into this little weirdness while scanning/fixing the split and non-merged sets.
The zipfile revx.zip contains 4 duplicate ROMs that exist in the zipfile with different names.
"revx.u51" CRC(9960ac7c) SHA1(441322f061d627ca7573f612f370a85794681d0f)
"revx.u52" CRC(fbf55510) SHA1(8a5b0004ed09391fe37f0f501b979903d6ae4868)
"revx.u53" CRC(a045b265) SHA1(b294d3a56e41f5ec4ab9bbcc0088833b1cab1879)
"revx.u54" CRC(24471269) SHA1(262345bd147402100785459af422dafd1c562787)
In the 0.249 datfile, these 4 files are being renamed, but same files are already present in the zipfile with these name.
The clrmamepro (4.046b) scanner (all fix options enabled) shows an error that it failed to unpack revx.u53 and revx.u54.
The zipfile test OK and I can unpack these files with no problem.
This commit makes the changes:
https://github.com/mamedev/mame/commit/23c7f300965c5ea374ff0aad9d58d74c14f18961
Any idea what's causing the scanner to produce these errors?
Files to reproduce attached.
With kind regards, NU.
14
clrmame Discussion / Re: pc8801_flop ROM shuffle scan/fix/rebuild fails
« on: 31 March 2022, 13:21 »
Thanks for the fixed version.
Besides my old configuration, I've also tested it with a newly generated cmpro.ini.
In both cases, the very first thing I got was the resize question.
The scan/fix/rebuild after that now went flawless.
N.B. The question for a resize of a ROM sounds weird (nasty) to me.
Not sure why it would even consider asking that.
In this case, it's just a swap/rename of 2 ROMs.
Can you enlighten me about the reason for the question?
What would it result in, besides deviating from the original dump?
Regards, NU.
Besides my old configuration, I've also tested it with a newly generated cmpro.ini.
In both cases, the very first thing I got was the resize question.
The scan/fix/rebuild after that now went flawless.
N.B. The question for a resize of a ROM sounds weird (nasty) to me.
Not sure why it would even consider asking that.
In this case, it's just a swap/rename of 2 ROMs.
Can you enlighten me about the reason for the question?
What would it result in, besides deviating from the original dump?
Regards, NU.
15
clrmame Discussion / Re: pc8801_flop ROM shuffle scan/fix/rebuild fails
« on: 30 March 2022, 19:23 »
Yeah, rebuilding from backup is standard practice when something is missing
Any idea where the mysterious resize I encountered, and you couldn't reproduce, came from?
It's a bit strange when we can't replicate the same behavior.
Thanks for taking the time to fix this.
Regards, NU.
Any idea where the mysterious resize I encountered, and you couldn't reproduce, came from?
It's a bit strange when we can't replicate the same behavior.
Thanks for taking the time to fix this.
Regards, NU.
16
clrmame Discussion / Re: pc8801_flop ROM shuffle scan/fix/rebuild fails
« on: 28 March 2022, 14:31 »
Settings attached, check PM.
17
clrmame Discussion / Re: pc8801_flop ROM shuffle scan/fix/rebuild fails
« on: 28 March 2022, 11:52 »
Yes, I'm using the latest version 4.044b.
If I load the attached XML and point it at the folder with the 2 sets,
the very first dialog I get when I scan with all fix options enabled:
Then:
Then:
I end up with:
Rebuild from backup:
I end up with:
Regards, NU.
If I load the attached XML and point it at the folder with the 2 sets,
the very first dialog I get when I scan with all fix options enabled:
Quote
Set: Tokyo Joshikosei Sailor-fuku Nyumon Dai-2-kanYes to all
Name: tokyojn2
File: D:\temp\pc8801_flop\tokyojn2\tokyo joshikosei sailor-fuku nyumon dai2kan.d88
Wrong Size: 348848
Right Size: 348576
Do you want to resize the ROM?
Then:
Quote
Set: Tokyo Joshikosei Sailor-fuku Nyumon Dai-2-kanYes to all
Name: tokyojn2
File: D:\temp\pc8801_flop\tokyojn2\tokyo joshikosei sailor-fuku nyumon dai2kan.d88
Do you want to remove the file?
Then:
Quote
Set: Tokyo Joshikosei Sailor-fuku Nyumon Dai-3-kanYes to all
Name: tokyojn3
File: D:\temp\pc8801_flop\tokyojn3\tokyo joshikosei sailor-fuku nyumon dai3kan.d88
Do you want to add the missing ROM?
I end up with:
Quote
Tokyo Joshikosei Sailor-fuku Nyumon Dai-2-kan [folder: tokyojn2 - size: 340kb]
missing set: Tokyo Joshikosei Sailor-fuku Nyumon Dai-2-kan
missing rom: tokyo joshikosei sailor-fuku nyumon dai2kan.d88 [size: 348576] [CRC32: 1b66be31] [SHA1: bea94b35a43b402e9b8b8d1faefadc1cc7b1802a]
Tokyo Joshikosei Sailor-fuku Nyumon Dai-3-kan [folder: tokyojn3 - size: 341kb]
missing set: Tokyo Joshikosei Sailor-fuku Nyumon Dai-3-kan
missing rom: tokyo joshikosei sailor-fuku nyumon dai3kan.d88 [size: 348848] [CRC32: 870dbb9c] [SHA1: 08c07cb445dbfacc0086f6bde19b09bd11b09b34]
Rebuild from backup:
Quote
Analyzed Files: 2
Created Files: 1
Matched Files: 2
Skipped Files: 1
I end up with:
Quote
Tokyo Joshikosei Sailor-fuku Nyumon Dai-2-kan [folder: tokyojn2 - size: 340kb]
missing set: Tokyo Joshikosei Sailor-fuku Nyumon Dai-2-kan
missing rom: tokyo joshikosei sailor-fuku nyumon dai2kan.d88 [size: 348576] [CRC32: 1b66be31] [SHA1: bea94b35a43b402e9b8b8d1faefadc1cc7b1802a]
Regards, NU.
18
clrmame Discussion / pc8801_flop ROM shuffle scan/fix/rebuild fails
« on: 28 March 2022, 09:10 »
Hi Roman,
Rebuilding the 0.241 pc8801_flop set with the pc8801_flop 0.242 XML ends up in losing a ROM.
Attached both sets in 0.241 configuration and the stripped 0.242 XML to reproduce.
The 2 ROMs are being swapped between these sets.
Scan/fix the 2 sets will result in an attempt to resize, remove and and adding the missing ROM.
You would expect the ROMs to be placed in and being able to rebuilt from backup.
However 1 ROM has disappeared, even when you choose not to resize.
Rebuilding from a copy of the 2 sets results in 0 missings.
With kind regards, NU.
Rebuilding the 0.241 pc8801_flop set with the pc8801_flop 0.242 XML ends up in losing a ROM.
Attached both sets in 0.241 configuration and the stripped 0.242 XML to reproduce.
The 2 ROMs are being swapped between these sets.
Scan/fix the 2 sets will result in an attempt to resize, remove and and adding the missing ROM.
You would expect the ROMs to be placed in and being able to rebuilt from backup.
However 1 ROM has disappeared, even when you choose not to resize.
Rebuilding from a copy of the 2 sets results in 0 missings.
With kind regards, NU.
19
clrmame Discussion / Re: CMP trims trailing dot in ROM name
« on: 28 July 2021, 18:19 »You cant have a file in windows which ends with a dot if I remember correctly.You're correct, but Windows cuts it off by itself.
Can it have that name in the zipfile?
Perhaps (also) an "Invalid filename" warning?
Thanks, NU.
20
clrmame Discussion / CMP trims trailing dot in ROM name
« on: 28 July 2021, 15:46 »
Hi roman,
In regard to:
https://github.com/mamedev/mame/commit/56ef8b14a2af3117decb113a78c4efb7ab182e56
Line 131 "jp1_mpr0.2c." ends up "jp1_mpr0.2c" in the zipfile.
Even though a (now fixed) bug in the MAME source, IMO the trailing dot should not be trimmed.
Regards, NU.
In regard to:
https://github.com/mamedev/mame/commit/56ef8b14a2af3117decb113a78c4efb7ab182e56
Line 131 "jp1_mpr0.2c." ends up "jp1_mpr0.2c" in the zipfile.
Even though a (now fixed) bug in the MAME source, IMO the trailing dot should not be trimmed.
Regards, NU.
Pages: [1] 2