.dol files aren't currently supported by rom-properties. shared-mime-info
is misidentifying them as image/vnd.microsoft.icon, which is clearly
wrong, so add this to fix the identification.
qoi.h is used for upstream, instead of writing a custom decoder.
I may write a custom decoder later to decode the Qoi data directly
into an rp_image without having an intermediate step.
If the file is a .zip, it will be handled as .jar. Otherwise, it will be
handled as .jad, which is just MANIFEST.MF.
Improved MANIFEST.MF parsing:
- Skip the UTF-8 BOM, if present.
- Handle multi-line entries. If a line starts with a space, then it's
part of a multi-line entry, so add it to the previous entry.
- Ignore .jad file digest tags.
- Add some more tags.
All of the .jad files I've tested work, and with the MANIFEST.MF parsing
improvements, the following .jar files now work:
These .jar files are missing at least one of the the MicroEdition-*
tags, but do have Manifest-Version and/or MIDlet-1:
- Atomic-88641.jar
- Football_Quiz_128x128-425421.jar
These .jar files had the MicroEdition-* tags, but also have multi-line
entries, which may be why they work now with the multi-line
implementation:
- Snow_Rally_City_Stage_240x320-532400.jar
- Super-G_Stunt_240x320-532401.jar
These .jar files have a newline in one of the entries, which broke
parsing of a MicroEdition-* tag:
- Stalker_3D_240x320S40v3-80779.jar
- Wallbreaker_2_Deluxe_240x320_Nokia_N73-446777.jar
These .jar files have Unicode text in MANIFEST.MF, including a UTF-8 BOM
at the beginning, which prevented "MIDlet-1" from being read, hence no
icon showing up, but they *were* detected as J2ME applications:
- Anger_Veyron_240x320Foreign-68651.jar
- Interest_Blade_Soul_Edition_240x320Japanese-59959.jar
- Lament_Island_240x320-96946.jar
- Mad_Boxing_Beast_240x320Foreign-79836.jar
- The_Evil_One_Fighting_176x208-63758.jar
J2ME application packages are standard Java .jar files (zip archives)
with MicroEdition tags in MANIFEST.MF. These files are detected first
by checking for the zip magic number, then reading tags from the
MANIFEST.MF file.
TODO:
- More general JAR parser for APK later.
- Get the icon.
- Show metadata.
Forgot to do this before...
NOTE: v2.4.1 isn't being added here because that's a Windows-only
bugfix release. It will be added after the next Linux release.
shared-mime-info uses application/x-discjuggler-cd-image,
while KDE seems to use application/x-cdi.
[libromdata] Dreamcast: Add application/x-discjuggler-cd-image and
use it as the MIME type for CDI images.
This is essentially the GameCube class's wii_loadOpeningBnr() and
wii_addBannerName() functions extracted into its own class.
TODO: Update the GameCube class to make use of WiiBNR.
NintendoLanguage::getWiiLanguage(): As a special case, 'hant' should be
handled as WII_LANG_JAPANESE, since Nintendo used JPN-region Wiis in
Taiwan instead of releasing a separate TWN-region Wii.
[xdg] Add unofficial MIME type "application/x-wii-bnr".
As per FreeDesktop.org's shared-mime-info.
[tracker] 14-rp-executables.rule: Add it, and also sort the MIME types
alphabetically, since apparently I forgot to do that for this file
when it was added initially.
This was added to FreeDesktop.org's shared-mime-info for 16-bit Windows
executables in v2.4. (released 2023/11/12)
It *should* only be detecting as such for 16-bit executables, but
`mimetype` is showing this type for 32-bit and 64-bit, which is breaking
tracker (and possibly other rom-properties plugins).
FIXME: Even though it's in no-thumbnail, KDE is still using rom-properties
to thumbnail TGAs on my system. (Which might be a good thing, since Qt's
TGA plugin appears to be busted...)
Possibly for other Nintendo systems too, e.g. DSi and 3DS.
Currently displays the following fields:
- Title ID
- Issuer
- Title version
- OS version (if non-zero) (identifies IOS and IOSU)
- Access rights (for Wii and Wii U only; but not Wii IOS)
wii_structs.h: Some updates for TMD.
wiiu_structs.h: Add CMD v1 structs.
[xdg] Add WiiTMD with "application/x-nintendo-tmd".
Possibly for other Nintendo systems too, e.g. DSi and 3DS.
Currently displays the following fields:
- Title ID
- Console ID
- Issuer (raw data, not converted to "retail" or "debug")
- Key index
Title ID is used as the metadata "title" property.
wii_structs.h: Add some more fields and RVL_Ticket_v1.
[librpbase] RomData: Add FileType::Ticket.
WiiTicket doesn't really work as any other FileType.
[kde] ExtractorPlugin: Update the assertion for RomData::FileType::Ticket.
[xdg] Add WiiTicket with "application/x-nintendo-ticket".
Currently reads the internal name and creator ID.
TODO:
- Read the icon. There's a lot of different formats, starting with the
initial 1-bpp format.
- Read the application name and version resources.
There's a bit of weirdness with Intellivision due to its unusual word
size. The General Instrument CP1610 is a 16-bit CPU, but uses 10-bit
opcodes. Because of this, Mattel used 10-bit ROMs. Some of the fields
in the ROM header use 16-bit addresses, split up into two 10-bit words.
The ROM file uses 16-bit big-endian for words, so in order to decode
these addresses, we have to take two 16-bit big-endian values, read
the low 8 bits of each, and combine it into a 16-bit value.
NOTE: ROM images must have a .int or .itv file extension, since the
Intellivision ROM header doesn't have a magic number.
TODO: Maybe we should switch to application/vnd.commodore.* ?
[xdg] rom-properties.xml: Remove a duplicate D71 definition.
Added aliases for the old MIME types, plus:
- application/x-c64-datadisk (D64)
- application/x-c64-rawdisk (G64)
ColecoVision ROMs have a short magic number, either AA 55 or 55 AA,
so the file extension is used for detection.
For ROMs that have AA 55, the ColecoVision logo is displayed on startup,
and the game name is displayed. The game name is stored at 0x0024,
and is formatted using three lines. The first two lines are displayed
in reverse order, and the last line is a 4-digit year.
TODO:
- Improve formatting.
- Add more fields.
These are sparse disc images created by the official SDKs.
Note that unlike the other sparse disc image formats we support,
DPF and RPF both have byte granularity instead of block granularity.
Therefore, we're not using SparseDiscReader as a base class.
RomDataFactory: Use IDiscReader instead of SparseDiscReader as the base
class in order to be able to use DpfReader.
Added DPF and RPF MIME types and file extensions for the GameCube class.
Also added the MIME types to the xdg/ directory.
FIXME: memset() in read() is causing an Internal Compiler Error when
compiling with gcc-13.2.0. Using a (slower) `for` loop instead.
TODO:
- RPF images don't start at virt=0, phys=0. Need to add a fake block for
phys=0 and adjust all the virtual offsets.
- Pre-adjust all phys offsets by adding the data start offset? Doing this
might just waste cycles if we don't read that much data from the disc.
The main difference compared to DOS 2.x is the second zone has 20
sectors per track instead of 19. This proved to be unreliable in
practice, which is why it was reduced to 19 in DOS 2.x.
Currently using a rather quickly thrown together GCR parser.
Since the G64 format stores an entire track without provisions for
random sector access without parsing the entire track, our code
decodes an entire track at once and caches it.
TODO:
- Use the track count and track length from the GCR-1541 header.
- Parse GCR tracks on the bit level instead of the byte level.
- Better error handling.
80 tracks, 40 sectors. No variable zones here.
Note that it's not actually 40 physical sectors; the actual disk uses
10 512-byte sectors, for 20 sectors per track; and both sides of the
disk are counted as a single trac.k
C8050 and C8250 are quad-density drives.
C8050 is single-sided; C8250 is double-sided.
Compared to C1541, the header sector is different (and doesn't have
the BAM), but the directory entries are the same. To compensate for
this, the header parser has been reworked to get the offsets from
the header sector based on disk type.
Basically the same as C1541, but with 70 tracks (and different offsets
compared to 40-track C1541 images) and a double-sided flag. There's also
some BAM changes, but those aren't important here.
A pointer to the track_offsets array is now stored in the private class.
TODO:
- Add support for G64/G71 images. These images have their own track
offset table instead of fixed addresses, so we'll need to convert
the fixed addresses for D64/D71 to a similar format.
- Add support for D81 images. D81 uses a physical format similar to
PC 3.5" floppy disks, but a logical format closer to C1541/C1571.
- Other CBM disk formats, e.g. D80/D82.
Needed for .d64 to be associated properly in KDE Dolphin and other
Linux file browsers.
FIXME: KDE Breeze doesn't have an icon for application/x-raw-disk-image .
This was added in shared-mime-info 2.3.
[xdg] mime.thumbnail.types: Add this MIME type.
- ...and remove a duplicate "files." in the header.
mime.no-thumbnail.types: Remove the generic CD-ROM MIME types
that are also in mime.thumbnail.types.
This should fix issues on Linux systems where Nintendo 3DS files weren't
detected by rom-properties due to Citra registering its own MIME types.
See issue #382: Errors in KDE
This particular issue was diagnosed by @dnmodder.
Internet access is recommended in order to make use of RPDB, but
rom-properties does work without constant Internet access. If an
RPDB image is cached locally, then it will be used without accessing
the RPDB server. Filetypes that have internal images that don't need
RPDB will also work without any issues.
Since I first implemented support for GodotSTEX v4, two major breaking
changes were introduced to the format:
1. PVRTC pixel formats were removed. The formats following PVRTC were
renumbered, which breaks compatibility. Godot 4 hasn't been released
yet, so this isn't a "breaking" change per se, but it breaks handling
of STEX v4 ETCn textures in rom-properties.
2. ETC no longer has swapped RB channels.
Other changes in the format:
- Godot now supports ASTC. (4x4 and 8x8, and HDR versions)
I added in the ASTC format IDs and it appears to "just work".
- The main file extension is now .ctex for "compressed texture".
TODO: Add more test images.
KDE doesn't detect these normally.
[libromdata] PlayStationDisc: Add the new MIME type,
application/x-raw-cd-image.
Not adding to MegaDrive or SegaSaturn because the MIME type
definitions handle the 2352-byte boot sector for these systems.
