Use of XADML Files in Amiga Forever
This article gives a general overview of the rationale, function, content and implementation of XADML files as used in Amiga Forever.
This information is not current. The concepts outlined in this page evolved and were implemented in Amiga Forever 2008. Please refer to the RetroPlatform Technical Reference for additional information.
XADML is used:
For caching the content of the individual player lists
For user-defined description and configuration data
In the RP9 manifest
Before the launch of Amiga Forever 2005 several parties, including users, emulation developers and supporters of the preservation of "Classic" Amiga applications, felt the need to associate standard configuration information to Amiga application images (e.g. disk sets in ADF, DMS or other format, CD images, etc.) Without such information, as memory fades away with the original hardware, carefully preserved Amiga application media images risk becoming next to unusable, given a complete lack of information about the system they were supposed to run on. XADML aims to address this problem, and several more (e.g. automatic organization of random collections of unstructured application images, easier access to application images available online, etc.)
In their simplest form, XADML files provide an XML-structured short description of a single application, saying something like "This software ideally requires an A1200 with 8 MB of Fast RAM and two floppy disk drives, but it also runs on an ECS system. Insert disk image 1 in drive 0 and disk image 2 in drive 1. The application supports features such as accelerated CPUs and accelerated floppy drives." Having this information, an application front-end can list the application, the user can click on it, and an Amiga emulator can set up the proper hardware configuration, load the correct ROM and operating system, and then load the application from floppy in less than one second, and run it at least 10 times faster than on an A1200. No configuration is required by the user. Because XADML describes configurations in terms of "real" combinations of reference hardware, ROM and operating system, the architecture is shielded from emulation settings, which are likely to be implementation and version-specific.
A XADML file contains one or more instances of several logical parts, including:
- Compact Application Description (for display purposes only: minimal information for front-ends, for maintaining lists of applications, etc., e.g. title, publisher, year, 160x120 thumbnail)
- Media Identification Data (e.g. file name, size and CRC32s of disk images, etc.)
- Configuration Data (describes the system requirements, e.g. for emulation packages)
- Cataloging Data (unique application OID, and OIDs of entities involved in development and publishing)
- Extended Application Description (extended additional information)
XADML Usage Scenarios
XADML files are not Amiga-specific. Although the "A" in "XADML" do bring to mind "Amiga" systems, the "A" may also stand for a more generic "Application".
XADML files are not emulation-specific. In the simplest implementation they simply describe an application and a real computer on which they best run. Actually, they can describe both an ideal configuration and a fallback one, e.g. an AGA system and an OCS one, if a game provides enhanced experience on the former, but also works on the latter, or two Amiga ROM versions, if a demo works perfectly with a 1.1 Amiga ROM, but it also works with minor visual problems on a more common 1.3 system. It is then up to an emulation application (e.g. WinFellow, WinUAE) or to the launcher to convert this information to internal emulation settings. A few additional tags which may be interpreted as being emulation-specific are supported in XADML, simply because emulation is the only means to get certain features that are very useful (e.g. faster CPUs, faster drives) and have no equivalent in the original hardware.
Within the specific Amiga context, it is estimated that over 90% of games available for download can run using only a handful of different XADML hardware configuration descriptions. "Classic" Amiga preservation sites are likely to easily and automatically be able to convert their current configuration instructions, which are often based on different emulation packages and versions, to more neutral XADML files.
Although usually an XADML file is included with one application and its related files (e.g. ADF disk image files), it is possible to use XADML files without disk images, or a special XADML "advertising" files describing 100s of games that can be downloaded from a site.
Because XADML files can optionally contain checksum information of the application image files (e.g. ADFs) they refer to, it becomes possible to create simple programs that scan an entire hard disk and automatically associate the correct ADFs with the correct XADML file, removing duplicates and moving the files in a more organized and structured way, if so desired.
Conversely, the Compact Application Description and Media Identification Data were designed in such a way that 100% of the minimum information they should contain can be generated automatically, based on existing data, by well-known Amiga game and demo resources.
Using XADML, a game or demo download site can "advertise" the titles it hosts, so that a front-end application can list all games or demos even if they are not installed on the local computer. Installation and running the application then takes only two mouse clicks. The user does not need to select a download location, extract the game, or configure the emulation software. Because some download sites are advertising-supported, or otherwise prefer their website not to be bypassed from this process, the XADML specification provides for different ways to respect this, allowing for XADML-specific links to reside on a web page, which can be opened in a web browser by the front-end.
XADML in Amiga Forever
XADML as described here is the result of years of experience, work and exchanges of ideas between, among others, emulation developers, application preservation experts, and users, and has a first implementation in Amiga Forever 2005. The success of XADML, which is at this point is hoped for, would not be possible without the ideas and material support of Toni Wilen, the lead maintainer of the WinUAE emulation software, and of numerous additional contributors (e.g. feedback from the SPS Team). XADML can be seen at work in the new Demos and Games front-ends of the Amiga Forever 2005 launcher. As emulation developers, download sites and other interested parties work to better support this, free updates for Amiga Forever will be made available to extend support for the system.
Amiga Forever 2005 introduced a new organization of directories and files on Windows, which includes an "Amiga Files" folder (support for which was also added by WinUAE 1.0, among others). In addition to other ROM and operating system files shared by various emulation engines, Amiga Files contains a "Games" directory and a "Demoscene" directory. Whereas before applications were grouped by file type, e.g. "ADFs", each game or demo application now has its own unique folder (directory) inside Games or Demoscene, regardless of whether it is based on ADFs, Amiga file system files, or other types of images or archives. This more application-centric approach in Amiga Forever 2005 reflects an increasing diversity and fragmentation of application distribution formats, and an increased focus on the application itself. Each application-specific directory contains a flat (no subdirectories, no external items) set of files (e.g. "application.xadml", ADFs, visual thumbnail).
It is safe to link to this page.