Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

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.

1

clrmame Discussion / Re: clrmamepro 4.028 released

« on: 10 February 2016, 18:12 »

A minor issue, the softlist option creates a DTD/XML validation error. See https://github.com/mamedev/mame/commit/cd1d9b7a2b997350ff548741808356206630bca4

2

clrmame Discussion / Re: Dir2Dat for softlists

« on: 27 January 2016, 21:20 »

The update is now working to my requirements, and will save me many hours in creating these softlists. Thanks.

3

clrmame Discussion / Re: Dir2Dat for softlists

« on: 27 January 2016, 18:26 »

Thanks for the new release, it will already save many hours creating softlists. A couple of comments though:
- still need offset="0" after the sha1 as discussed previously.
- would be nice to add a <year> tag, which can be

Code: [Select]

<year>????</year> by default.
- I couldn't get the manufacturer option to do anything, didn't add a publisher tag with or without 'From Folder' selected.

4

clrmame Discussion / Re: Dir2Dat for softlists

« on: 06 January 2016, 11:01 »

Yeah, but why would you want to create a software list for an arcade board? The board roms are documented internally.

5

clrmame Discussion / Re: Dir2Dat for softlists

« on: 06 January 2016, 10:30 »

1 rom inside 1 dataarea inside 1 part element.....*sigh* what a waste ;-) but well.....if you really want it that way...

Each part represents a physical media of a software release, take a look at my bbcb_z80_flop.xml in mame/hash folder for an example of software released on multiple floppies. If each floppy was not a part then MAME would try to mount all floppies in a set at the same time, the part makes them independently selectable but still within the same set.

6

clrmame Discussion / Re: Dir2Dat for softlists

« on: 06 January 2016, 00:26 »

feel free to comment on the part/dataarea blocks...

A nice start, couple of comments:
- all <dataarea> should be wrapped with <part>
- all <rom> should contain an offset attribute, which is usually 0.

Code: [Select]

<part name="" interface="">
<dataarea name="rom" size="32768">
<rom name="10107-1.epr" size="32768" crc="3b67cce3" sha1="95f71526c236262ff985148ba7ea057f07fadbe8" offset="0"/>
</dataarea>
</part>
<part name="" interface="">
<dataarea name="rom" size="16384">
<rom name="10107-2.epr" size="16384" crc="89d08795" sha1="dc75502580d681d9b4dc878b0d80346bcef407ae" offset="0"/>
</dataarea>
</part>Looking forward to testing this.

7

clrmame Discussion / Re: coming up

« on: 21 December 2015, 21:30 »

It "knows" that the same way as it currently does. A found folder or an archive forms a set...If it contains more than one file, it collects the files as roms for that set.

Makes sense to keep that functionality, does it also treat zip files as folders?

I currently have a folder containing over 3000 floppy images waiting to be added to a softlist. This folder contains a folder for each Publisher. Could we have an option to handle this, to populate Publisher according to folder name?

8

clrmame Discussion / Re: coming up

« on: 21 December 2015, 20:19 »

So...assuming dir2dat finds multiple roms connected to one set....what is the most common way to export them....each rom in a single part / dataarea / rom path or one part / dataarea path with all roms below it?

How would dir2dat know that multiple roms/floppies/cassettes are associated with a single set?

I would expect this to simply export a directory with each file being a single part:

<software name="filename">
   <description>filename</description>
   <year>?</year>
   <publisher>&lt;unknown&gt;</publisher>
   <part name="flop1" interface="floppy_5_25">
      <dataarea name="flop" size="filelength">
         <rom name="filename" size="filelength" crc="filecrc" sha1="filesha1" offset="0" />
      </dataarea>
   </part>
</software>

The dataarea name 'flop' and interface 'floppy_5_25' could be manually entered and applied to all items in the list, as they can be unique per machine/list.

The export would substitute filename, filelength, filecrc, filesha1 for the values for that particular file.

After export, the softlist creator would then have to manually amend software name, description, publisher, year but would at least have a significant portion of the softlist pre-generated.

9

clrmame Discussion / Re: Dir2Dat for softlists

« on: 27 October 2015, 20:01 »

Appreciate it, no rush!

10

clrmame Discussion / Dir2Dat for softlists

« on: 27 October 2015, 19:17 »

The dir2dat option is very useful for getting the initial rom tag info required for creating softlists. But this still requires lots of additional processing to add all other tags (software, description, year, publisher, part, dataarea).
Any chance of adding an option to create a xml in softlist format? Obviously the tag contents will still require manually editing but software and description could default to the rom filename as a starting point.

Thanks.