mame/hash/dgnalpha_flop.xml

175 lines
6.6 KiB
XML
Raw Permalink Normal View History

<?xml version="1.0"?>
<!DOCTYPE softwarelist SYSTEM "softwarelist.dtd">
<!--
license:CC0
-->
<softwarelist name="dgnalpha_flop" description="Dragon Alpha (Professional) diskettes">
<software name="ddosboot">
<description>DragonDOS 1.0 Boot</description>
<year>2004</year>
<publisher>Phill Harvey-Smith</publisher>
<part name="flop1" interface="floppy_3_5">
<dataarea name="flop" size="368652">
(nw) softlist_dev.cpp: validate ROM labels The free-for-all on labels in software lists is not working. There's no consistency, labels are getting excessively long, people are starting to use non-ASCII characters in labels making it harder for others to type them when manipulating files on the command line, and there's too much markup being put in labels. The length limit is 127 characters, same as for labels in MAME itself. This should be long enough to be descriptive. Remember that the Win32 path limit is 260 characters, and many applications and frameworks have issues with longer paths, including Windows Explorer and the .NET framework. Labels are used as filenames, so concessions need to be made for this. I have not abbreviated excessively long labels myself - they're currently causing 135 validity errors. Someone else can fix them. Printable ASCII characters are allowed, with a few exceptions. The exceptions are limited to characters most likely to cause issues for interactive shells and scripts: * ! - csh event substitution (very difficult to escape properly) * $ - sh varibale expansion * % - csh job control, cmd variable expansion * / - UNIX directory separator * : - sh path separator, Windows drive qualifier * \ - sh escape, Windows directory separator Most of the labels that had to be edited were using ! for markup, or using ! and % for titles in labels. Strangely, titles in labels are often forced to lower case, despite this never being enforced for software lists. There are also various other edits to titles used for labels, such as moving articles to the end (with or without a comma), or replacing spaces with underscores. As I already said, there's no consistency at all. There is far too much markup in labels. They're even being used for notes in some cases (e.g. at least one case where a dumper's name is in the label). The XML schema supports metadata - use it. For example, you can use part_id for an unrestricted display name for a software part. You can also use XML comments for notes. And while on the topic of metadata, vgmplay.xml is putting the same thing in the part_id as well as the label. The part_id should have the actual title, not the title mangled to make it more suitable for use as a filename. Addressing this would be a lot of work, given how large the file is. For now, empty data areas in software lists cause a verbose message rather than a validation warning. There are thousands of software lists using empty data areas to indicate the size/width of cartridge RAM/EEPROM/etc.
2020-04-15 21:05:16 +02:00
<rom name="Dragon Alpha(Professional) Dragon DOS 1.0 Boot (2004)(Phill Harvey Smith).vdk" size="368652" crc="ebbcf3b9" sha1="35a7a6381fdb516ac0dbf05ada1d9f1fce3d1ac0"/>
</dataarea>
</part>
</software>
<software name="ddos2boot">
<description>DragonDOS 2.F Boot</description>
<year>198?</year>
<publisher>Dragon Data</publisher>
<part name="flop1" interface="floppy_3_5">
<dataarea name="flop" size="368652">
(nw) softlist_dev.cpp: validate ROM labels The free-for-all on labels in software lists is not working. There's no consistency, labels are getting excessively long, people are starting to use non-ASCII characters in labels making it harder for others to type them when manipulating files on the command line, and there's too much markup being put in labels. The length limit is 127 characters, same as for labels in MAME itself. This should be long enough to be descriptive. Remember that the Win32 path limit is 260 characters, and many applications and frameworks have issues with longer paths, including Windows Explorer and the .NET framework. Labels are used as filenames, so concessions need to be made for this. I have not abbreviated excessively long labels myself - they're currently causing 135 validity errors. Someone else can fix them. Printable ASCII characters are allowed, with a few exceptions. The exceptions are limited to characters most likely to cause issues for interactive shells and scripts: * ! - csh event substitution (very difficult to escape properly) * $ - sh varibale expansion * % - csh job control, cmd variable expansion * / - UNIX directory separator * : - sh path separator, Windows drive qualifier * \ - sh escape, Windows directory separator Most of the labels that had to be edited were using ! for markup, or using ! and % for titles in labels. Strangely, titles in labels are often forced to lower case, despite this never being enforced for software lists. There are also various other edits to titles used for labels, such as moving articles to the end (with or without a comma), or replacing spaces with underscores. As I already said, there's no consistency at all. There is far too much markup in labels. They're even being used for notes in some cases (e.g. at least one case where a dumper's name is in the label). The XML schema supports metadata - use it. For example, you can use part_id for an unrestricted display name for a software part. You can also use XML comments for notes. And while on the topic of metadata, vgmplay.xml is putting the same thing in the part_id as well as the label. The part_id should have the actual title, not the title mangled to make it more suitable for use as a filename. Addressing this would be a lot of work, given how large the file is. For now, empty data areas in software lists cause a verbose message rather than a validation warning. There are thousands of software lists using empty data areas to indicate the size/width of cartridge RAM/EEPROM/etc.
2020-04-15 21:05:16 +02:00
<rom name="Dragon Alpha(Professional) Dragon DOS 2.F Boot (198x)(Dragon Data Ltd).vdk" size="368652" crc="ee4ffe2c" sha1="ff8d00a80d03452589e0db47944a121c9bd62332"/>
</dataarea>
</part>
</software>
<software name="nos9l1v325">
<description>NitrOS-9/6809 Level 1 v3.2.5</description>
<year>2004</year>
<publisher>Phill Harvey-Smith</publisher>
<part name="flop1" interface="floppy_3_5">
<dataarea name="flop" size="368652">
(nw) softlist_dev.cpp: validate ROM labels The free-for-all on labels in software lists is not working. There's no consistency, labels are getting excessively long, people are starting to use non-ASCII characters in labels making it harder for others to type them when manipulating files on the command line, and there's too much markup being put in labels. The length limit is 127 characters, same as for labels in MAME itself. This should be long enough to be descriptive. Remember that the Win32 path limit is 260 characters, and many applications and frameworks have issues with longer paths, including Windows Explorer and the .NET framework. Labels are used as filenames, so concessions need to be made for this. I have not abbreviated excessively long labels myself - they're currently causing 135 validity errors. Someone else can fix them. Printable ASCII characters are allowed, with a few exceptions. The exceptions are limited to characters most likely to cause issues for interactive shells and scripts: * ! - csh event substitution (very difficult to escape properly) * $ - sh varibale expansion * % - csh job control, cmd variable expansion * / - UNIX directory separator * : - sh path separator, Windows drive qualifier * \ - sh escape, Windows directory separator Most of the labels that had to be edited were using ! for markup, or using ! and % for titles in labels. Strangely, titles in labels are often forced to lower case, despite this never being enforced for software lists. There are also various other edits to titles used for labels, such as moving articles to the end (with or without a comma), or replacing spaces with underscores. As I already said, there's no consistency at all. There is far too much markup in labels. They're even being used for notes in some cases (e.g. at least one case where a dumper's name is in the label). The XML schema supports metadata - use it. For example, you can use part_id for an unrestricted display name for a software part. You can also use XML comments for notes. And while on the topic of metadata, vgmplay.xml is putting the same thing in the part_id as well as the label. The part_id should have the actual title, not the title mangled to make it more suitable for use as a filename. Addressing this would be a lot of work, given how large the file is. For now, empty data areas in software lists cause a verbose message rather than a validation warning. There are thousands of software lists using empty data areas to indicate the size/width of cartridge RAM/EEPROM/etc.
2020-04-15 21:05:16 +02:00
<rom name="Dragon Alpha(Professional) NitrOS9-6809-Level1-v030205-SS80 (2004)(Phill Harvey Smith).vdk" size="368652" crc="a417d3e2" sha1="823f72a98bd20128c84e20d47df9e0f205cd1fb8"/>
</dataarea>
</part>
</software>
<software name="nos9l1v325_51" cloneof="nos9l1v325">
<description>NitrOS-9/6809 Level 1 v3.2.5 (51 Column)</description>
<year>2004</year>
<publisher>Phill Harvey-Smith</publisher>
<part name="flop1" interface="floppy_3_5">
<dataarea name="flop" size="368652">
(nw) softlist_dev.cpp: validate ROM labels The free-for-all on labels in software lists is not working. There's no consistency, labels are getting excessively long, people are starting to use non-ASCII characters in labels making it harder for others to type them when manipulating files on the command line, and there's too much markup being put in labels. The length limit is 127 characters, same as for labels in MAME itself. This should be long enough to be descriptive. Remember that the Win32 path limit is 260 characters, and many applications and frameworks have issues with longer paths, including Windows Explorer and the .NET framework. Labels are used as filenames, so concessions need to be made for this. I have not abbreviated excessively long labels myself - they're currently causing 135 validity errors. Someone else can fix them. Printable ASCII characters are allowed, with a few exceptions. The exceptions are limited to characters most likely to cause issues for interactive shells and scripts: * ! - csh event substitution (very difficult to escape properly) * $ - sh varibale expansion * % - csh job control, cmd variable expansion * / - UNIX directory separator * : - sh path separator, Windows drive qualifier * \ - sh escape, Windows directory separator Most of the labels that had to be edited were using ! for markup, or using ! and % for titles in labels. Strangely, titles in labels are often forced to lower case, despite this never being enforced for software lists. There are also various other edits to titles used for labels, such as moving articles to the end (with or without a comma), or replacing spaces with underscores. As I already said, there's no consistency at all. There is far too much markup in labels. They're even being used for notes in some cases (e.g. at least one case where a dumper's name is in the label). The XML schema supports metadata - use it. For example, you can use part_id for an unrestricted display name for a software part. You can also use XML comments for notes. And while on the topic of metadata, vgmplay.xml is putting the same thing in the part_id as well as the label. The part_id should have the actual title, not the title mangled to make it more suitable for use as a filename. Addressing this would be a lot of work, given how large the file is. For now, empty data areas in software lists cause a verbose message rather than a validation warning. There are thousands of software lists using empty data areas to indicate the size/width of cartridge RAM/EEPROM/etc.
2020-04-15 21:05:16 +02:00
<rom name="Dragon Alpha(Professional) NitrOS9-6809-Level1-v030205-SS80-51 Column (2004)(Phill Harvey Smith).vdk" size="368652" crc="482048d2" sha1="beab9134a0ca4b1412a484f7c5caa7b62677a405"/>
</dataarea>
</part>
</software>
<software name="ccompiler">
<description>OS-9 C Compiler</description>
<year>198?</year>
<publisher>Dragon Data</publisher>
<part name="flop1" interface="floppy_3_5">
<dataarea name="flop" size="368673">
(nw) softlist_dev.cpp: validate ROM labels The free-for-all on labels in software lists is not working. There's no consistency, labels are getting excessively long, people are starting to use non-ASCII characters in labels making it harder for others to type them when manipulating files on the command line, and there's too much markup being put in labels. The length limit is 127 characters, same as for labels in MAME itself. This should be long enough to be descriptive. Remember that the Win32 path limit is 260 characters, and many applications and frameworks have issues with longer paths, including Windows Explorer and the .NET framework. Labels are used as filenames, so concessions need to be made for this. I have not abbreviated excessively long labels myself - they're currently causing 135 validity errors. Someone else can fix them. Printable ASCII characters are allowed, with a few exceptions. The exceptions are limited to characters most likely to cause issues for interactive shells and scripts: * ! - csh event substitution (very difficult to escape properly) * $ - sh varibale expansion * % - csh job control, cmd variable expansion * / - UNIX directory separator * : - sh path separator, Windows drive qualifier * \ - sh escape, Windows directory separator Most of the labels that had to be edited were using ! for markup, or using ! and % for titles in labels. Strangely, titles in labels are often forced to lower case, despite this never being enforced for software lists. There are also various other edits to titles used for labels, such as moving articles to the end (with or without a comma), or replacing spaces with underscores. As I already said, there's no consistency at all. There is far too much markup in labels. They're even being used for notes in some cases (e.g. at least one case where a dumper's name is in the label). The XML schema supports metadata - use it. For example, you can use part_id for an unrestricted display name for a software part. You can also use XML comments for notes. And while on the topic of metadata, vgmplay.xml is putting the same thing in the part_id as well as the label. The part_id should have the actual title, not the title mangled to make it more suitable for use as a filename. Addressing this would be a lot of work, given how large the file is. For now, empty data areas in software lists cause a verbose message rather than a validation warning. There are thousands of software lists using empty data areas to indicate the size/width of cartridge RAM/EEPROM/etc.
2020-04-15 21:05:16 +02:00
<rom name="Dragon Alpha(Professional) OS-9 C Compiler (198x)(Dragon Data Ltd)[OS-9].vdk" size="368673" crc="4c48a38f" sha1="8a2b58765cd7c8ec8725f90bef770d0e720ff3c2"/>
</dataarea>
</part>
</software>
<software name="dynacalc">
<description>OS-9 Dynacalc</description>
<year>198?</year>
<publisher>Dragon Data</publisher>
<part name="flop1" interface="floppy_3_5">
<dataarea name="flop" size="368671">
(nw) softlist_dev.cpp: validate ROM labels The free-for-all on labels in software lists is not working. There's no consistency, labels are getting excessively long, people are starting to use non-ASCII characters in labels making it harder for others to type them when manipulating files on the command line, and there's too much markup being put in labels. The length limit is 127 characters, same as for labels in MAME itself. This should be long enough to be descriptive. Remember that the Win32 path limit is 260 characters, and many applications and frameworks have issues with longer paths, including Windows Explorer and the .NET framework. Labels are used as filenames, so concessions need to be made for this. I have not abbreviated excessively long labels myself - they're currently causing 135 validity errors. Someone else can fix them. Printable ASCII characters are allowed, with a few exceptions. The exceptions are limited to characters most likely to cause issues for interactive shells and scripts: * ! - csh event substitution (very difficult to escape properly) * $ - sh varibale expansion * % - csh job control, cmd variable expansion * / - UNIX directory separator * : - sh path separator, Windows drive qualifier * \ - sh escape, Windows directory separator Most of the labels that had to be edited were using ! for markup, or using ! and % for titles in labels. Strangely, titles in labels are often forced to lower case, despite this never being enforced for software lists. There are also various other edits to titles used for labels, such as moving articles to the end (with or without a comma), or replacing spaces with underscores. As I already said, there's no consistency at all. There is far too much markup in labels. They're even being used for notes in some cases (e.g. at least one case where a dumper's name is in the label). The XML schema supports metadata - use it. For example, you can use part_id for an unrestricted display name for a software part. You can also use XML comments for notes. And while on the topic of metadata, vgmplay.xml is putting the same thing in the part_id as well as the label. The part_id should have the actual title, not the title mangled to make it more suitable for use as a filename. Addressing this would be a lot of work, given how large the file is. For now, empty data areas in software lists cause a verbose message rather than a validation warning. There are thousands of software lists using empty data areas to indicate the size/width of cartridge RAM/EEPROM/etc.
2020-04-15 21:05:16 +02:00
<rom name="Dragon Alpha(Professional) OS-9 Dynacalc (198x)(Dragon Data Ltd)[OS-9].vdk" size="368671" crc="dee40ac8" sha1="4835bc3a7bd42a34e0f8f24337dcf1f948c75c58"/>
</dataarea>
</part>
</software>
<software name="textedasm">
<description>OS-9 Macro Text Editor/OS9 Assembler/Debugger</description>
<year>198?</year>
<publisher>Dragon Data</publisher>
<part name="flop1" interface="floppy_3_5">
<dataarea name="flop" size="368678">
(nw) softlist_dev.cpp: validate ROM labels The free-for-all on labels in software lists is not working. There's no consistency, labels are getting excessively long, people are starting to use non-ASCII characters in labels making it harder for others to type them when manipulating files on the command line, and there's too much markup being put in labels. The length limit is 127 characters, same as for labels in MAME itself. This should be long enough to be descriptive. Remember that the Win32 path limit is 260 characters, and many applications and frameworks have issues with longer paths, including Windows Explorer and the .NET framework. Labels are used as filenames, so concessions need to be made for this. I have not abbreviated excessively long labels myself - they're currently causing 135 validity errors. Someone else can fix them. Printable ASCII characters are allowed, with a few exceptions. The exceptions are limited to characters most likely to cause issues for interactive shells and scripts: * ! - csh event substitution (very difficult to escape properly) * $ - sh varibale expansion * % - csh job control, cmd variable expansion * / - UNIX directory separator * : - sh path separator, Windows drive qualifier * \ - sh escape, Windows directory separator Most of the labels that had to be edited were using ! for markup, or using ! and % for titles in labels. Strangely, titles in labels are often forced to lower case, despite this never being enforced for software lists. There are also various other edits to titles used for labels, such as moving articles to the end (with or without a comma), or replacing spaces with underscores. As I already said, there's no consistency at all. There is far too much markup in labels. They're even being used for notes in some cases (e.g. at least one case where a dumper's name is in the label). The XML schema supports metadata - use it. For example, you can use part_id for an unrestricted display name for a software part. You can also use XML comments for notes. And while on the topic of metadata, vgmplay.xml is putting the same thing in the part_id as well as the label. The part_id should have the actual title, not the title mangled to make it more suitable for use as a filename. Addressing this would be a lot of work, given how large the file is. For now, empty data areas in software lists cause a verbose message rather than a validation warning. There are thousands of software lists using empty data areas to indicate the size/width of cartridge RAM/EEPROM/etc.
2020-04-15 21:05:16 +02:00
<rom name="Dragon Alpha(Professional) OS-9 Editor Assembler (198x)(Dragon Data Ltd)[OS-9].vdk" size="368678" crc="3c46119f" sha1="98d76fb1ba97877adba0caadbb090c42328814e8"/>
</dataarea>
</part>
</software>
<software name="os9l1v12">
<description>OS-9 Level 1 v1.2 System Disk (Release 8)</description>
<year>198?</year>
<publisher>Dragon Data</publisher>
<part name="flop1" interface="floppy_3_5">
<dataarea name="flop" size="368665">
(nw) softlist_dev.cpp: validate ROM labels The free-for-all on labels in software lists is not working. There's no consistency, labels are getting excessively long, people are starting to use non-ASCII characters in labels making it harder for others to type them when manipulating files on the command line, and there's too much markup being put in labels. The length limit is 127 characters, same as for labels in MAME itself. This should be long enough to be descriptive. Remember that the Win32 path limit is 260 characters, and many applications and frameworks have issues with longer paths, including Windows Explorer and the .NET framework. Labels are used as filenames, so concessions need to be made for this. I have not abbreviated excessively long labels myself - they're currently causing 135 validity errors. Someone else can fix them. Printable ASCII characters are allowed, with a few exceptions. The exceptions are limited to characters most likely to cause issues for interactive shells and scripts: * ! - csh event substitution (very difficult to escape properly) * $ - sh varibale expansion * % - csh job control, cmd variable expansion * / - UNIX directory separator * : - sh path separator, Windows drive qualifier * \ - sh escape, Windows directory separator Most of the labels that had to be edited were using ! for markup, or using ! and % for titles in labels. Strangely, titles in labels are often forced to lower case, despite this never being enforced for software lists. There are also various other edits to titles used for labels, such as moving articles to the end (with or without a comma), or replacing spaces with underscores. As I already said, there's no consistency at all. There is far too much markup in labels. They're even being used for notes in some cases (e.g. at least one case where a dumper's name is in the label). The XML schema supports metadata - use it. For example, you can use part_id for an unrestricted display name for a software part. You can also use XML comments for notes. And while on the topic of metadata, vgmplay.xml is putting the same thing in the part_id as well as the label. The part_id should have the actual title, not the title mangled to make it more suitable for use as a filename. Addressing this would be a lot of work, given how large the file is. For now, empty data areas in software lists cause a verbose message rather than a validation warning. There are thousands of software lists using empty data areas to indicate the size/width of cartridge RAM/EEPROM/etc.
2020-04-15 21:05:16 +02:00
<rom name="Dragon Alpha(Professional) OS-9 Level 1 v1.2 System Disk (Release 8) (198x)(Dragon Data Ltd)[OS-9].vdk" size="368665" crc="f46822c5" sha1="1799f7abf172cc03ef3d22bd953b576addb37337"/>
</dataarea>
</part>
</software>
<software name="pascal">
<description>OS-9 Pascal Compiler</description>
<year>198?</year>
<publisher>Dragon Data</publisher>
<part name="flop1" interface="floppy_3_5">
<dataarea name="flop" size="368677">
(nw) softlist_dev.cpp: validate ROM labels The free-for-all on labels in software lists is not working. There's no consistency, labels are getting excessively long, people are starting to use non-ASCII characters in labels making it harder for others to type them when manipulating files on the command line, and there's too much markup being put in labels. The length limit is 127 characters, same as for labels in MAME itself. This should be long enough to be descriptive. Remember that the Win32 path limit is 260 characters, and many applications and frameworks have issues with longer paths, including Windows Explorer and the .NET framework. Labels are used as filenames, so concessions need to be made for this. I have not abbreviated excessively long labels myself - they're currently causing 135 validity errors. Someone else can fix them. Printable ASCII characters are allowed, with a few exceptions. The exceptions are limited to characters most likely to cause issues for interactive shells and scripts: * ! - csh event substitution (very difficult to escape properly) * $ - sh varibale expansion * % - csh job control, cmd variable expansion * / - UNIX directory separator * : - sh path separator, Windows drive qualifier * \ - sh escape, Windows directory separator Most of the labels that had to be edited were using ! for markup, or using ! and % for titles in labels. Strangely, titles in labels are often forced to lower case, despite this never being enforced for software lists. There are also various other edits to titles used for labels, such as moving articles to the end (with or without a comma), or replacing spaces with underscores. As I already said, there's no consistency at all. There is far too much markup in labels. They're even being used for notes in some cases (e.g. at least one case where a dumper's name is in the label). The XML schema supports metadata - use it. For example, you can use part_id for an unrestricted display name for a software part. You can also use XML comments for notes. And while on the topic of metadata, vgmplay.xml is putting the same thing in the part_id as well as the label. The part_id should have the actual title, not the title mangled to make it more suitable for use as a filename. Addressing this would be a lot of work, given how large the file is. For now, empty data areas in software lists cause a verbose message rather than a validation warning. There are thousands of software lists using empty data areas to indicate the size/width of cartridge RAM/EEPROM/etc.
2020-04-15 21:05:16 +02:00
<rom name="Dragon Alpha(Professional) OS-9 Pascal Compiler (198x)(Dragon Data Ltd)[OS-9].vdk" size="368677" crc="1dc5f947" sha1="b7b239c503338e4724e48ca6c7f3a6de60e8130d"/>
</dataarea>
</part>
</software>
<software name="rms">
<description>OS-9 RMS</description>
<year>198?</year>
<publisher>Dragon Data</publisher>
<part name="flop1" interface="floppy_3_5">
<dataarea name="flop" size="368681">
(nw) softlist_dev.cpp: validate ROM labels The free-for-all on labels in software lists is not working. There's no consistency, labels are getting excessively long, people are starting to use non-ASCII characters in labels making it harder for others to type them when manipulating files on the command line, and there's too much markup being put in labels. The length limit is 127 characters, same as for labels in MAME itself. This should be long enough to be descriptive. Remember that the Win32 path limit is 260 characters, and many applications and frameworks have issues with longer paths, including Windows Explorer and the .NET framework. Labels are used as filenames, so concessions need to be made for this. I have not abbreviated excessively long labels myself - they're currently causing 135 validity errors. Someone else can fix them. Printable ASCII characters are allowed, with a few exceptions. The exceptions are limited to characters most likely to cause issues for interactive shells and scripts: * ! - csh event substitution (very difficult to escape properly) * $ - sh varibale expansion * % - csh job control, cmd variable expansion * / - UNIX directory separator * : - sh path separator, Windows drive qualifier * \ - sh escape, Windows directory separator Most of the labels that had to be edited were using ! for markup, or using ! and % for titles in labels. Strangely, titles in labels are often forced to lower case, despite this never being enforced for software lists. There are also various other edits to titles used for labels, such as moving articles to the end (with or without a comma), or replacing spaces with underscores. As I already said, there's no consistency at all. There is far too much markup in labels. They're even being used for notes in some cases (e.g. at least one case where a dumper's name is in the label). The XML schema supports metadata - use it. For example, you can use part_id for an unrestricted display name for a software part. You can also use XML comments for notes. And while on the topic of metadata, vgmplay.xml is putting the same thing in the part_id as well as the label. The part_id should have the actual title, not the title mangled to make it more suitable for use as a filename. Addressing this would be a lot of work, given how large the file is. For now, empty data areas in software lists cause a verbose message rather than a validation warning. There are thousands of software lists using empty data areas to indicate the size/width of cartridge RAM/EEPROM/etc.
2020-04-15 21:05:16 +02:00
<rom name="Dragon Alpha(Professional) OS-9 RMS (198x)(Dragon Data Ltd)[OS-9].vdk" size="368681" crc="61f9d523" sha1="aec0fed0a1eda2e14bbdcf44c6fb800c4ae35d92"/>
</dataarea>
</part>
</software>
<software name="sound">
<description>OS-9 Sound Demo</description>
<year>198?</year>
<publisher>Dragon Data</publisher>
<part name="flop1" interface="floppy_3_5">
<dataarea name="flop" size="368673">
(nw) softlist_dev.cpp: validate ROM labels The free-for-all on labels in software lists is not working. There's no consistency, labels are getting excessively long, people are starting to use non-ASCII characters in labels making it harder for others to type them when manipulating files on the command line, and there's too much markup being put in labels. The length limit is 127 characters, same as for labels in MAME itself. This should be long enough to be descriptive. Remember that the Win32 path limit is 260 characters, and many applications and frameworks have issues with longer paths, including Windows Explorer and the .NET framework. Labels are used as filenames, so concessions need to be made for this. I have not abbreviated excessively long labels myself - they're currently causing 135 validity errors. Someone else can fix them. Printable ASCII characters are allowed, with a few exceptions. The exceptions are limited to characters most likely to cause issues for interactive shells and scripts: * ! - csh event substitution (very difficult to escape properly) * $ - sh varibale expansion * % - csh job control, cmd variable expansion * / - UNIX directory separator * : - sh path separator, Windows drive qualifier * \ - sh escape, Windows directory separator Most of the labels that had to be edited were using ! for markup, or using ! and % for titles in labels. Strangely, titles in labels are often forced to lower case, despite this never being enforced for software lists. There are also various other edits to titles used for labels, such as moving articles to the end (with or without a comma), or replacing spaces with underscores. As I already said, there's no consistency at all. There is far too much markup in labels. They're even being used for notes in some cases (e.g. at least one case where a dumper's name is in the label). The XML schema supports metadata - use it. For example, you can use part_id for an unrestricted display name for a software part. You can also use XML comments for notes. And while on the topic of metadata, vgmplay.xml is putting the same thing in the part_id as well as the label. The part_id should have the actual title, not the title mangled to make it more suitable for use as a filename. Addressing this would be a lot of work, given how large the file is. For now, empty data areas in software lists cause a verbose message rather than a validation warning. There are thousands of software lists using empty data areas to indicate the size/width of cartridge RAM/EEPROM/etc.
2020-04-15 21:05:16 +02:00
<rom name="Dragon Alpha(Professional) OS-9 Sound demo (198x)(Dragon Data Ltd)[OS-9].vdk" size="368673" crc="b0b8f6a3" sha1="cb79c232d92e8bc3c9253b992dd159970200abe5"/>
</dataarea>
</part>
</software>
<software name="sourcerer">
<description>OS-9 Sourcerer</description>
<year>198?</year>
<publisher>Dragon Data</publisher>
<part name="flop1" interface="floppy_3_5">
<dataarea name="flop" size="368674">
(nw) softlist_dev.cpp: validate ROM labels The free-for-all on labels in software lists is not working. There's no consistency, labels are getting excessively long, people are starting to use non-ASCII characters in labels making it harder for others to type them when manipulating files on the command line, and there's too much markup being put in labels. The length limit is 127 characters, same as for labels in MAME itself. This should be long enough to be descriptive. Remember that the Win32 path limit is 260 characters, and many applications and frameworks have issues with longer paths, including Windows Explorer and the .NET framework. Labels are used as filenames, so concessions need to be made for this. I have not abbreviated excessively long labels myself - they're currently causing 135 validity errors. Someone else can fix them. Printable ASCII characters are allowed, with a few exceptions. The exceptions are limited to characters most likely to cause issues for interactive shells and scripts: * ! - csh event substitution (very difficult to escape properly) * $ - sh varibale expansion * % - csh job control, cmd variable expansion * / - UNIX directory separator * : - sh path separator, Windows drive qualifier * \ - sh escape, Windows directory separator Most of the labels that had to be edited were using ! for markup, or using ! and % for titles in labels. Strangely, titles in labels are often forced to lower case, despite this never being enforced for software lists. There are also various other edits to titles used for labels, such as moving articles to the end (with or without a comma), or replacing spaces with underscores. As I already said, there's no consistency at all. There is far too much markup in labels. They're even being used for notes in some cases (e.g. at least one case where a dumper's name is in the label). The XML schema supports metadata - use it. For example, you can use part_id for an unrestricted display name for a software part. You can also use XML comments for notes. And while on the topic of metadata, vgmplay.xml is putting the same thing in the part_id as well as the label. The part_id should have the actual title, not the title mangled to make it more suitable for use as a filename. Addressing this would be a lot of work, given how large the file is. For now, empty data areas in software lists cause a verbose message rather than a validation warning. There are thousands of software lists using empty data areas to indicate the size/width of cartridge RAM/EEPROM/etc.
2020-04-15 21:05:16 +02:00
<rom name="Dragon Alpha(Professional) OS-9 Sourcerer (198x)(Dragon Data Ltd)[OS-9].vdk" size="368674" crc="0352b280" sha1="98a7463f9be24753f7e665d455e87788c994839c"/>
</dataarea>
</part>
</software>
<software name="stylograph">
<description>OS-9 Stylograph</description>
<year>198?</year>
<publisher>Dragon Data</publisher>
<part name="flop1" interface="floppy_3_5">
<dataarea name="flop" size="368673">
(nw) softlist_dev.cpp: validate ROM labels The free-for-all on labels in software lists is not working. There's no consistency, labels are getting excessively long, people are starting to use non-ASCII characters in labels making it harder for others to type them when manipulating files on the command line, and there's too much markup being put in labels. The length limit is 127 characters, same as for labels in MAME itself. This should be long enough to be descriptive. Remember that the Win32 path limit is 260 characters, and many applications and frameworks have issues with longer paths, including Windows Explorer and the .NET framework. Labels are used as filenames, so concessions need to be made for this. I have not abbreviated excessively long labels myself - they're currently causing 135 validity errors. Someone else can fix them. Printable ASCII characters are allowed, with a few exceptions. The exceptions are limited to characters most likely to cause issues for interactive shells and scripts: * ! - csh event substitution (very difficult to escape properly) * $ - sh varibale expansion * % - csh job control, cmd variable expansion * / - UNIX directory separator * : - sh path separator, Windows drive qualifier * \ - sh escape, Windows directory separator Most of the labels that had to be edited were using ! for markup, or using ! and % for titles in labels. Strangely, titles in labels are often forced to lower case, despite this never being enforced for software lists. There are also various other edits to titles used for labels, such as moving articles to the end (with or without a comma), or replacing spaces with underscores. As I already said, there's no consistency at all. There is far too much markup in labels. They're even being used for notes in some cases (e.g. at least one case where a dumper's name is in the label). The XML schema supports metadata - use it. For example, you can use part_id for an unrestricted display name for a software part. You can also use XML comments for notes. And while on the topic of metadata, vgmplay.xml is putting the same thing in the part_id as well as the label. The part_id should have the actual title, not the title mangled to make it more suitable for use as a filename. Addressing this would be a lot of work, given how large the file is. For now, empty data areas in software lists cause a verbose message rather than a validation warning. There are thousands of software lists using empty data areas to indicate the size/width of cartridge RAM/EEPROM/etc.
2020-04-15 21:05:16 +02:00
<rom name="Dragon Alpha(Professional) OS-9 Stylograph (198x)(Dragon Data Ltd)[OS-9}.vdk" size="368673" crc="b20e4df5" sha1="6ab24c435208300497c2367fb2dfaea3b97617c5"/>
</dataarea>
</part>
</software>
<software name="sdose6boot">
<description>SuperDOS E6 Boot</description>
<year>2004</year>
<publisher>Phill Harvey-Smith</publisher>
<part name="flop1" interface="floppy_3_5">
<dataarea name="flop" size="368652">
(nw) softlist_dev.cpp: validate ROM labels The free-for-all on labels in software lists is not working. There's no consistency, labels are getting excessively long, people are starting to use non-ASCII characters in labels making it harder for others to type them when manipulating files on the command line, and there's too much markup being put in labels. The length limit is 127 characters, same as for labels in MAME itself. This should be long enough to be descriptive. Remember that the Win32 path limit is 260 characters, and many applications and frameworks have issues with longer paths, including Windows Explorer and the .NET framework. Labels are used as filenames, so concessions need to be made for this. I have not abbreviated excessively long labels myself - they're currently causing 135 validity errors. Someone else can fix them. Printable ASCII characters are allowed, with a few exceptions. The exceptions are limited to characters most likely to cause issues for interactive shells and scripts: * ! - csh event substitution (very difficult to escape properly) * $ - sh varibale expansion * % - csh job control, cmd variable expansion * / - UNIX directory separator * : - sh path separator, Windows drive qualifier * \ - sh escape, Windows directory separator Most of the labels that had to be edited were using ! for markup, or using ! and % for titles in labels. Strangely, titles in labels are often forced to lower case, despite this never being enforced for software lists. There are also various other edits to titles used for labels, such as moving articles to the end (with or without a comma), or replacing spaces with underscores. As I already said, there's no consistency at all. There is far too much markup in labels. They're even being used for notes in some cases (e.g. at least one case where a dumper's name is in the label). The XML schema supports metadata - use it. For example, you can use part_id for an unrestricted display name for a software part. You can also use XML comments for notes. And while on the topic of metadata, vgmplay.xml is putting the same thing in the part_id as well as the label. The part_id should have the actual title, not the title mangled to make it more suitable for use as a filename. Addressing this would be a lot of work, given how large the file is. For now, empty data areas in software lists cause a verbose message rather than a validation warning. There are thousands of software lists using empty data areas to indicate the size/width of cartridge RAM/EEPROM/etc.
2020-04-15 21:05:16 +02:00
<rom name="Dragon Alpha(Professional) Super DOS E6 Boot (2004)(Phill Harvey Smith).vdk" size="368652" crc="118e6529" sha1="f9265036feded52ea868b97cc98668d7ed4b79a9"/>
</dataarea>
</part>
</software>
<software name="viewdata">
<description>Viewdata Demo</description>
<year>1984</year>
<publisher>Telepost Systems</publisher>
<part name="flop1" interface="floppy_3_5">
<dataarea name="flop" size="368666">
(nw) softlist_dev.cpp: validate ROM labels The free-for-all on labels in software lists is not working. There's no consistency, labels are getting excessively long, people are starting to use non-ASCII characters in labels making it harder for others to type them when manipulating files on the command line, and there's too much markup being put in labels. The length limit is 127 characters, same as for labels in MAME itself. This should be long enough to be descriptive. Remember that the Win32 path limit is 260 characters, and many applications and frameworks have issues with longer paths, including Windows Explorer and the .NET framework. Labels are used as filenames, so concessions need to be made for this. I have not abbreviated excessively long labels myself - they're currently causing 135 validity errors. Someone else can fix them. Printable ASCII characters are allowed, with a few exceptions. The exceptions are limited to characters most likely to cause issues for interactive shells and scripts: * ! - csh event substitution (very difficult to escape properly) * $ - sh varibale expansion * % - csh job control, cmd variable expansion * / - UNIX directory separator * : - sh path separator, Windows drive qualifier * \ - sh escape, Windows directory separator Most of the labels that had to be edited were using ! for markup, or using ! and % for titles in labels. Strangely, titles in labels are often forced to lower case, despite this never being enforced for software lists. There are also various other edits to titles used for labels, such as moving articles to the end (with or without a comma), or replacing spaces with underscores. As I already said, there's no consistency at all. There is far too much markup in labels. They're even being used for notes in some cases (e.g. at least one case where a dumper's name is in the label). The XML schema supports metadata - use it. For example, you can use part_id for an unrestricted display name for a software part. You can also use XML comments for notes. And while on the topic of metadata, vgmplay.xml is putting the same thing in the part_id as well as the label. The part_id should have the actual title, not the title mangled to make it more suitable for use as a filename. Addressing this would be a lot of work, given how large the file is. For now, empty data areas in software lists cause a verbose message rather than a validation warning. There are thousands of software lists using empty data areas to indicate the size/width of cartridge RAM/EEPROM/etc.
2020-04-15 21:05:16 +02:00
<rom name="Dragon Alpha(Professional) Viewdata Demo (198x)(TelePost Systems Ltd)[OS-9].vdk" size="368666" crc="05344cf3" sha1="2044886a7c6c4985927dd0710a63bad3f34dd14e"/>
</dataarea>
</part>
</software>
</softwarelist>