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.
Get rid of a couple of copies of the CC0 text. Add header comment to
CC0 files to remind people editing them what the terms are. Also add
some missing XML headers. The header comments in layouts won't bloat
the binary - they get stripped out before compressing, same as any other
comments.
* gameboy.xml - Update with info from No-Intro - A
* gameboy.xml - Update with info from No-Intro - B
* gameboy.xml - Update with info from No-Intro - C
* gameboy.xml - Update with info from No-Intro - D
* gameboy.xml - Update with info from No-Intro - E-F
* gameboy.xml - Update with info from No-Intro - G
* gameboy.xml - Update with info from No-Intro - H
* gameboy.xml - Update with info from No-Intro - I
* gameboy.xml - Update with info from No-Intro - J
* gameboy.xml - Update with info from No-Intro - K
* gameboy.xml - Update with info from No-Intro - L
* gameboy.xml - Update with info from No-Intro - M
* gameboy.xml - Update with info from No-Intro - N
* gameboy.xml - More documenetation of GB carts
* gameboy.xml - Document many more carts
* gameboy.xml - Update with info from No-Intro - P-Q
* gameboy.xml - Update with info from No-Intro - R
* gameboy.xml - Update with info from No-Intro - S
* More gameboy clean
* SGB info added to all
* SGB info added to all
* change endings, run formatter
* I think I fixed the broken indent
* But I also forgot to save
* revert commit 25e931611d31ab3de16db077e34dbdf00fea4282
* Remove tab/space mix
* superfluous space
* make compatibility a feature
This effectively reverts b380514764 and
c24473ddff, restoring the state at
598cd52272.
Before pushing, please check that what you're about to push is sane.
Check your local commit log and ensure there isn't anything out-of-place
before pushing to mainline. When things like this happen, it wastes
everyone's time. I really don't need this in a week when real work™ is
busting my balls and I'm behind where I want to be with preparing for
MAME release.
* cleaned up midvunit inputs and outputs. cleaned up seattle outputs.
* better motion inputs and sorted main buttons for midvunit
* keep case the same
* removed runtime tagmap lookup
* gameboy camera functional
* gameboy.xml: remove misleading comment
Sachen 4B-003 was recently added
Signed-off-by: Tauwasser <tauwasser@tauwasser.eu>
* gameboy: fix Super Game Boy VRAM transfer
A basic implementation of VRAM transfer. It fixes a number of games and removes
the SGB border hack. However, it's very likely that the bahvior is much more
complex. The old implementation was good enough for the majority of games,
so this should suffice until such time when SGB is implemented on top of SNES.
The attribute data was resized to 4096 bytes, so a whole VRAM transfer can take place
even though only 4050 bytes are used. The idea is that the whole 4096 bytes are
_probably_ transferred to WRAM and a game might theoretically upload a small executable
and use that data. However, running native SNES code is currently unsupported anyway.
Signed-off-by: Tauwasser <tauwasser@tauwasser.eu>
* gameboy: various code style/comment fixes
- return GB_MBC_NONE instead of magic 0 value
- add MLT_REQ case in sgb code and mention where it's actually handled
- add PAL_PRI to list of known SGB commands (not implemented)
- fix two comments
Signed-off-by: Tauwasser <tauwasser@tauwasser.eu>
* gameboy: coding style fixes for gb_lcd
Signed-off-by: Tauwasser <tauwasser@tauwasser.eu>
Miscellaneous Game Boy changes:
* gameboy: add Super Chinese Land 1.2.3' to MBC1 Collection check code
* gameboy: fix MMM01 zero-adjust logic for ROM bank
New working software list additions
--------------------------------
* gameboy.xml: Sachen 4 in 1 (Euro, 4B-003) [Tauwasser]
M161 is used as mapper, M12 is just a PCB revision.
M01 PCB uses a discrete ROM IC
M12 PCB uses a glob top COB ROM
Signed-off-by: Tauwasser <tauwasser@tauwasser.eu>
