EMULAB Forum

Please login or register.

Login with username, password and session length
Advanced search  

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.

Messages - emulajavi

Pages: [1]
1
Great! With the latest version it no longer happens.

Thank you very much!!

2
Hi,

About these two ‘systems’ (DATs from Dat-O-Matic:

Nintendo - Nintendo DSi (Digital) (CDN) (CDN)
Nintendo - Nintendo DSi (Digital) (CDN) (CDNdec)


Examining the DATs I see it expects the date/time of the files inside the .zip to be between 2010 and 2012 aproximately….

But when I load the DAT and scan my collection with clrmamepro it reports a lot of time/date errors because it says the correct ones should be 1970-01-01 00:00:00

This is a file:

(see attachment)

This is what the DAT says:

<?xml version="1.0"?>
<!DOCTYPE datafile PUBLIC "-//Logiqx//DTD ROM Management Datafile//EN" http://www.logiqx.com/Dats/datafile.dtd>
<datafile>
             <header>
                           <name>Nintendo - Nintendo DSi (Digital) (CDN) (CDN)</name>
                           <description>Nintendo - Nintendo DSi (Digital) (CDN) (CDN)</description>
                           <version>20210217-055105</version>
                           <author>Hiccup and zedseven, Icyelut</author>
                           <homepage>No-Intro</homepage>
                           <url>http://www.no-intro.org</url>
             </header>
             <game name="10 Byou Sou (Japan)">
                           <description>10 Byou Sou (Japan)</description>
                           <rom name="titlePass.txt" size="8" crc="12EC7F82" md5="7D9AD0211D6493E8D55A4A75DE3F90A1" sha1="891A4AC3F0101A20236B7F3DBE519F0CD38413C4" status="verified"/>
                           <rom name="FFFFFFFE" size="0" crc="00000000" md5="D41D8CD98F00B204E9800998ECF8427E" sha1="DA39A3EE5E6B4B0D3255BFEF95601890AFD80709" status="verified" date="2010-04-06"/>
                           <rom name="tmd.0" size="2312" crc="85EE6011" md5="63F6D0E38D89055C2DB9A63C8C7CBCC0" sha1="44B03D20C330105E2562C9D5F9C09A34A41A6899" status="verified" date="2010-04-06" serial="000300044B4A554A"/>
                           <rom name="00000000" size="5332992" crc="A37D2952" md5="A45B846F7644A5F9FBF684DD07A33F33" sha1="72324CD81A68D3A3245848F8917AE131C0D2B8F9" status="verified" date="2010-04-06" serial="KJUJ,10SECRUN"/>
                           <rom name="FFFD0000" size="1060" crc="848F1E52" md5="5C490CACE022981C1C4B0E4DBA97C8E1" sha1="A2DAD37ACB882A745F37C77AE8861604D660CA2A" status="verified" date="2010-04-06"/>
                           <rom name="FFFD0001" size="1498" crc="07397E5A" md5="EA4ECDF5B627ADE14613CF4632A40DD0" sha1="052063417784E95F474EC1E9FE8CBD22902C60CF" status="verified" date="2010-04-06"/>
                           <rom name="FFFD0002" size="1443" crc="C6BAD356" md5="0F73446C75468721B55C2D1F19DB2AD0" sha1="9CC3767BFCC9670A41A25CC95E6043E4798F8660" status="verified" date="2010-04-06"/>
                           <rom name="FFFD0003" size="1721" crc="11F1481C" md5="F52F7882BC467BC27FB1A660C055D9F9" sha1="E9EB34B0018100B4082EDC661718DF81E496EB09" status="verified" date="2010-04-06"/>
                           <rom name="FFFD0004" size="4059" crc="C932E6A4" md5="CA9949C152514370998B35F727AD9F31" sha1="FF9DD22E646470B7A863EFBF4F1BD4CD128C6098" status="verified" date="2010-04-06"/>
                           <rom name="FFFD0005" size="2371" crc="8C23CA0A" md5="7BFFE5A9ECD7CA46332551DCAED07BEF" sha1="DA88099F62C5A477281A2FDEC1C514547B74F05D" status="verified" date="2010-04-06"/>
                           <rom name="FFFEFFFF" size="2312" crc="85EE6011" md5="63F6D0E38D89055C2DB9A63C8C7CBCC0" sha1="44B03D20C330105E2562C9D5F9C09A34A41A6899" status="verified" date="2010-04-06"/>
                           <rom name="titleKey.bin" size="16" crc="23E383DC" md5="8E63D778E79EB78780F5216DD566B4C9" sha1="7C3B58D9EA237B5488884760F359AFD70BB65006" status="verified"/>
             </game>
             


This is what clrmamepro reports when scanning:

10 Byou Sou (Japan) [folder: 10 Byou Sou (Japan) - size: 5mb]
wrong date/time: 00000000 [wrong: 2010-04-05 22:00:00] [right: 1970-01-01 00:00:00]
wrong date/time: FFFD0000 [wrong: 2010-04-05 22:00:00] [right: 1970-01-01 00:00:00]
wrong date/time: FFFD0001 [wrong: 2010-04-05 22:00:00] [right: 1970-01-01 00:00:00]
wrong date/time: FFFD0002 [wrong: 2010-04-05 22:00:00] [right: 1970-01-01 00:00:00]
wrong date/time: FFFD0003 [wrong: 2010-04-05 22:00:00] [right: 1970-01-01 00:00:00]
wrong date/time: FFFD0004 [wrong: 2010-04-05 22:00:00] [right: 1970-01-01 00:00:00]
wrong date/time: FFFD0005 [wrong: 2010-04-05 22:00:00] [right: 1970-01-01 00:00:00]
wrong date/time: FFFEFFFF [wrong: 2010-04-05 22:00:00] [right: 1970-01-01 00:00:00]
wrong date/time: FFFFFFFE [wrong: 2010-04-05 22:00:00] [right: 1970-01-01 00:00:00]
wrong date/time: tmd.0 [wrong: 2010-04-05 22:00:00] [right: 1970-01-01 00:00:00]



Do you know what could be happening?? Is it something related to the DAT?? Or to clrmamepro??

Thank you very much!!

Regards,

Javier

3
clrmame Discussion / Re: ClrMamePro says 'wrong name' wrongly?
« on: 23 January 2021, 18:49 »

Regarding software lists: I strongly recommend to keep them separated. So 1 profile per software list. This has various reasons:
- not all software lists are actually listed in MAME's -listsoftware output
- setting up 1 profile for all software lists plus MAME is a pain
- hard to actually differ between them if everything is in one
- slow
- etc...

So for each file in MAME's hash folder (these are the software list 'datfiles') create a profile. Scan them with cmpro's batcher all in a row...

Ok perfect



What merge mode are you using?

Split mode


Ah ok...I now know what might have happened...
Indeed the uk6 rom is obsolete since it now belongs to a refenced device. So it should be placed in the belonging device set and not in the set itself.

Now you got it in your zipfile and cmpro detects the file where the name doesn't belong to the set, so it looks more closely by checking its hash to see if it is just a wrong named file.
Unfortunately this set also holds a hash identical file which does belong to the set (5c). The name check finds a matching hash and says that the file is wrongly named and should be named like the 5c one. It doesn't see that this file already exist. Fixing the name will most likely fail since the file already exist.

So...the name check works, the proposed name is also ok, the fact that the file is already there is not taken into account during the check.

Pretty rare case...in this case you need a little manual involvement to get rid of the file (or you turn off the "name" check and only keep the "unneeded" check).

If new sets are added via the rebuilder, such things won't happen. But it happens when the set exists in that form from a previous MAME version and MAME decided to separate a file as device or bios or parent etc....but such affect only happens when in addition you have the hash collision here...

So...actually I wonder why the .5c file is not defined as device rom as the .uk6 rom....maybe this should be double-checked by MAME devs.

Yes. That seem to have been the problem. For whatever reason I had the uk6 file inside the rom .zip.... instead on the separate device .zip.

Since the uk6 file hash was identicial to the 5c, cmpro treated it as a wrong named file. If I clicked on fixing it, it would report that it can't fix it (because there's already the 5c on the rom's .zip).

So as you said, cmpro worked correctly and it's up to mame devs to probably remove the 5c file from the rom set and only keep the uk6 file on the device set.


Thanks!!

4
clrmame Discussion / Re: ClrMamePro says 'wrong name' wrongly?
« on: 21 January 2021, 23:51 »
Hi Roman,

Thank you for you quick reply.

I took the sfd10001.zip (which contains the six 6 files, as you can see in the image above) and rebuild it, and it created a sfd10001.zip with only 5 files.

It seems that 901467.uk6 which is identical to 901467-01.5c is inside c8050fdc.zip and it's so not needed in sfd10001.zip

Because both 901467.uk6 and 901467-01.5c are identical, and 901467.uk6 'belonging to another place' what ClrMame wanted to do is simply rename it as 901467-01.5c, and so it what it wanted to do was correct.


One question about software lists..... The proper way to add them to my current MAME setup would be

1.- Point ClrMame to mame64.exe to create a new dat file and when it prompts a message about Software Lists say Yes
2.- Place all Software List roms and chds inside the 'roms' folder, alongside my current MAME roms and CHD
3.- Scan with ClrMame and fix if needed

????? Is that correct?? Or is it possible to keep MAME roms & CHDs and Software Lists ROMS & CHDs on separate directories?

5
clrmame Discussion / ClrMamePro says 'wrong name' wrongly?
« on: 21 January 2021, 18:29 »
Hi Roman,

When using clrmame to check MAME 227 (dat obtained with clrmame from mame64.exe), it reports one file as wrongly named... but it seems that's it's a file that according to the set information, has to exist twice with different names. What could be happening?

See attached pic


Thank you!

6
Thank you very much Roman!

The scan tree window is empty so I got the full .210 correctly.

7
Hi,

I've got the .210 Split set complete and clrmamepro Scan statistics say:






But the Miss List shows this:

 You are missing 14 of 40411 known MAME_v210 sets (+ BIOS sets)

fantasy_sound
monsterb_sound
nes_bandai_pt554
nes_jf13
nes_jf17_pcm
nes_jf19_pcm
nes_jf23
nes_jf24
nes_jf29
nes_jf33
s97271p
sasuke_sound
satansat_sound
vanguard_sound

8
It says this:

Due to merging differences, some sets are (currently) not reproducible using the MAME binary or -listxml output.
In order to reproduce the available full sets with any Rom Manager, it's highly recommended to use the attached datfiles.

And then they post the datfiles below

I've put them in my OneDrive if you want to check them:

https://1drv.ms/f/s!Al0KjcezUqKng4wMx4a43jQ_ewayCg


Maybe this datfiles are different than generating them from mame.exe or maybe not…..

Thanks!

9
Hi,

Thank you very much for your quick reply!

About the setting to change the compression…. last time I 'updated' my set was on MAME .149 so it's been a long time


.210 was released two days ago and while I was looking to update my .209 to .210 roms, I've seen these post:

https://forum.pleasuredome.org.uk/index.php?showtopic=35012#entry303333

Where it says that 'Due to merging differences, some sets are (currently) not reproducible using the MAME binary or -listxml output.
In order to reproduce the available full sets with any Rom Manager, it's highly recommended to use the attached datfiles.'

So what's better…. to create the .210 datfile using clrmamepro with the mame64.exe binary...or use the datfile that PD provides?

Thanks!

10
Hi,

I have Clrmamepro 4.035 and .209 full set (merged). Only the .zips, without the chds.

I think split is better.... so pointed clrmamepro to the .209 binary and created a dat file (saying ‘no’ to software lists and then ‘ok to all’)

On the rebuilder option, selected as the source path the folder that contains all the zips of the merged roms, and as the destination path a new folder in other place.

I have two questions:

1.- On clrmamepro Settings->compression, there’s no ‘zip’ tab to select the compression level. (I think there is supposed to be a selector to select from 1 to 9) So what will the compression level that clrmamepro use when rebuilding?

2.- For example, now the rebuilding process is at 32% and says:
168244 matched
54500 created
2350 skipped

Why are there so many skipped things? I think that if I have a merged set, which is all files parent+clones on the same zip, and to convert it to split what clrmamepro does is create separate parent and clone sets, why it says it skipping things? Aren’t all the files of a merged full set useful for a split full set?

Thank you!

11
clrmame Discussion / Re: Problem on CRC of darkhors
« on: 07 January 2010, 01:27 »
Hi Roman,

thank you

so i asume that this eeprom was changed from 135 to 136 right?? size is 128??

i think i have found it!
only one question: could someone who didn't find it have created a file "eeprom" with the correct CRC, Size and Hash, with nothing in it, only to have clrmamepro saying he has the complete set?


thank you, happy new year!

12
clrmame Discussion / Problem on CRC of darkhors
« on: 03 January 2010, 00:53 »
Hi,

i have got a problem on eeprom rom on darkhors
Dark Horse (bootleg of Jockey Club II) [folder: darkhors - parent: jclub2 - size: 6mb]

clrmame pro says its  missing
i have eeprom with crc:
45314fdb

and it says
missing rom: eeprom [size: 128] [CRC32: 1f434f66] [SHA1: e1bee11d83fb72aed9c312bdc794d8b9a6645534]

i cant find one with the correct crc

is it a problem of the dat? of clrmame? mine?
i made the dad with clrmamepro pointing to mameui32 version 136

thank you!!


Pages: [1]

Page created in 0.079 seconds with 22 queries.