Author Topic: Potential New Addition (with rough draft DATs)  (Read 381 times)

Offline auncollective

  • Newbie
  • *
  • Posts: 1
    • Email
Potential New Addition (with rough draft DATs)
« on: January 08, 2022, 10:59:34 PM »
I've been using TOSEC-inspired DATs for many collections in our archive that aren't currently part of TOSEC. I've started sorting through them and figured I'd upload what I have for the LEMZ AGAT-7 & 9, a relatively interesting piece of Soviet history.

One question I have is what is considered a compilation versus a stand-alone product? I followed the rule of 3 or more unrelated games bundled together as the bare minimum requirement and just used best judgment from that point.

If this is useful, just let me know if anything needs fixed and I'll do it. I can also upload one for the Amstrad PCW-8256/8512 (Games) and a few other hardware platforms yet to be included in TOSEC.

I've also spent over two decades amassing software for various m68k, PPC, SPARC, and x86 architectures. Is there a specific plan of how to document software designed for different OSes within the same architecture family, and the same OS across different architectures? I have a NeXTstep/OpenStep collection spanning m86k, PPC, x86, and SPARC, a BeOS collection spanning PPC and x86, Solaris software for SPARC and x86, as well as games and other software for another 30+ x86-based OSes (QNX, Plan 9, Snowdrop OS, TempleOS are a few examples) that aren't Windows, DOS, Linux, or a major BSD variant.

Keep up the great work and hopefully I have something of value to give back!



Offline NLS

  • Full Member
  • ***
  • Posts: 101
  • It's too personal.
    • NLS Blog
Re: Potential New Addition (with rough draft DATs)
« Reply #1 on: January 09, 2022, 12:43:41 AM »
Seems interesting.
---
NLS
My Blog

Offline mictlantecuhtle

  • Global Moderator
  • Full Member
  • *****
  • Posts: 143
Re: Potential New Addition (with rough draft DATs)
« Reply #2 on: January 10, 2022, 12:50:17 PM »
Quote
I've been using TOSEC-inspired DATs for many collections in our archive that aren't currently part of TOSEC. I've started sorting through them and figured I'd upload what I have for the LEMZ AGAT-7 & 9, a relatively interesting piece of Soviet history.

One question I have is what is considered a compilation versus a stand-alone product? I followed the rule of 3 or more unrelated games bundled together as the bare minimum requirement and just used best judgment from that point.

If this is useful, just let me know if anything needs fixed and I'll do it. I can also upload one for the Amstrad PCW-8256/8512 (Games) and a few other hardware platforms yet to be included in TOSEC.

I've also spent over two decades amassing software for various m68k, PPC, SPARC, and x86 architectures. Is there a specific plan of how to document software designed for different OSes within the same architecture family, and the same OS across different architectures? I have a NeXTstep/OpenStep collection spanning m86k, PPC, x86, and SPARC, a BeOS collection spanning PPC and x86, Solaris software for SPARC and x86, as well as games and other software for another 30+ x86-based OSes (QNX, Plan 9, Snowdrop OS, TempleOS are a few examples) that aren't Windows, DOS, Linux, or a major BSD variant.

Keep up the great work and hopefully I have something of value to give back!

Hey, thanks so much for taking the time to put these together, more contributions are always welcome and especially for systems like this where we don't currently have the expertise. I'm fascinated by this era of computing history, but not knowing Russian makes it hard for me to tackle these kinds of systems.

The DATs are a really good starting point, there's just a few things that need to be changed or fixed so that they're standardised with the current TOSEC DATs.

Headers

DAT headers always follow a standardised format - see an example from Apple II below to give you an idea of how these should be structured:

Code: [Select]
<header>
<name>Apple II - Games - [WOZ]</name>
<description>Apple II - Games - [WOZ] (TOSEC-v2021-12-11)</description>
<category>TOSEC</category>
<version>2021-12-11</version>
<author>mictlantecuhtle</author>
<email>contact@tosecdev.org</email>
<homepage>TOSEC</homepage>
<url>http://www.tosecdev.org/</url>
</header>

Blank publisher names
As you've identified, we don't always have a publisher name and so in that case we just use a dash in brackets to show that. The only thing is that it doesn't need spaces either side, so rather than
Code: [Select]
( - ) we can just use
Code: [Select]
(-)
Flag order

The TOSEC Naming Convention lays out an order for each of the flags - this needs to be followed to allow for automatic parsing and error checking of DAT entries. I notice in a couple of entries you have

Code: [Select]
(ru)(AGAT-9)
I'm assuming that (AGAT-9) is a system flag, in which case it should come before (ru) as a language flag.

Multiple dates/publishers for compilation entries

Compilations are always kind of a pain here, there are really two approaches that you can take:

1) Try and give a date/publisher for each entry on the compilation

If we take here your example of
Code: [Select]
Groom (1992), Leo (1993), MineSweeper(1992), Rock Stalker(1989), & Rock Stalker II (1991)(FaMe Software) -(ru)(AGAT-9) using this format we would have something like
Code: [Select]
Groom (1992)(-) & Leo (1993)(-) & MineSweeper (1992)(-) & Rock Stalker (1989)(-) & Rock Stalker II (1991)(FaMe Software)(AGAT-9)(ru)
It looks like (ru) and (AGAT-9) apply to all the entries, so these are what we would call "global flags" and can be left to the very end, which saves us a bit of space

2) Give one date/publisher for the compilation disk as a whole

Sometimes it's simply not possible given the limits of filesystems to include all the information for every title on a large compilation disk. In this case we might do something like:

Code: [Select]
Groom & Leo & MineSweeper & Rock Stalker & Rock Stalker II (19xx)(-)(AGAT-9)(ru)
It's a bit less preferable really because as you can see we lose some information, but sometimes it's the only option

Use of brackets in software names

Again this is partly to enable accurate parsing of the DAT entries - for the moment, we can't use ( ) or [ ] brackets as part of the name of the software. There are a couple of instances where you've used e.g.

Code: [Select]
Pango (aka Rango) (1989)(Elektrostal)(ru)
The simplest solution is to change this as follows:

Code: [Select]
Pango (1989)(Elektrostal)(ru)[aka Rango]
Spacing / capitalisation / file order

I noticed a few entries where the spacing isn't quite right e.g.
Code: [Select]
Baba-jaga, Bjurokrat, Pilot, Football(19xx)(USR SoftWare)(ru)(AGAT-9) should be
Code: [Select]
Baba-jaga, Bjurokrat, Pilot, Football (19xx)(USR SoftWare)(ru)(AGAT-9) (space between software title and year)

Similarly there's a little inconsistency in terms of the capitalisation of the file extensions e.g. some have .AIM and some .aim. My personal preference is to use lowercase file extensions unless there's a good reason to do otherwise, and in general these should be consistent throughout.

Finally, I noticed that the entries are in an odd order in some of the DATs - looking at Compilations - [DSK], for example, the first entry is "Star Patrol..." and the second "LabiRB...". Generally it's best if the entries are in alphabetical order - makes it a lot easier to scan through manually and check for inconsistencies.

I'm not sure what tool you used to generate the DATs or if you did the whole thing manually (in which case, good effort!). I generally use clrmamepro's dir2dat tool, which does a lot of the heavy lifting for you - just set the appropriate options, point it at a directory full of files and run.


Sorry, I know that's been a lot of picking at things but I really do appreciate the effort you've put into these and I'd love to see more contributions from you for these and any other hardware platforms.

In terms of documenting software across architecture families and same OSes across different architectures, this is on my long-term plan for the project but we currently don't have a definite solution. I've run across a similar case for CP/M software which works across a potentially vast range of different machines, but haven't come up with a real solution as yet. If you have any ideas for how best to do this I'd be happy to discuss them with you and the rest of the team and see if we can come up with something!