Cet émulateur est également le plus complet des outils de développements X68000 existant aujourd’hui. Il s’agit d’un fork de l’émulateur XM6 v2.05 de PI avec une pléthore de nouvelles fonctionnalités. Les changements sont pour la plupart liés à l’interface utilisateur et un accent a été mis sur le développement et les fonctions de débogage plutôt que sur l’exactitude de l’émulation, cependant il y a suffisamment d’améliorations pour qu’il soit recommandé d’utiliser cette version plutôt que XM6 v2.06 finale.
Les changements:
– State files now have run-length encoding (RLE) applied when saved to disk.
Under realistic circumstances, this significantly reduces the file size.
(Its design precludes expansion.) Furthermore, RLE-compressed state files
often save and load faster due to their smaller size, but even in cases
where they don’t, the increase is on the order of milliseconds and not
likely to be noticed. Finally, this particular implementation of RLE
is designed to be recompressible so that state files can subsequently
be archived (as by 7-Zip) with only a minor increase in size.
What this means for you…
– State files now take up less disk space.
– If you are already in the habit of archiving/compressing your state files, simply use the new menus (under File) to configure how heavily the RLE will be applied. The default was chosen under the assumption that most people won’t bother; it favors reducing file size but doesn’t hurt recompression too much. You should use a lighter setting to improve recompression.
Remember: you can still load state files from within a 7-Zip archive!
– As for the rest of you, « I have _begged_ you to install 7-Zip! » (Too obscure?)
– But if you absolutely refuse to save many megabytes of space by archiving your state files, you can at least use the heaviest RLE setting to make your state files significantly smaller. They won’t recompress very well but it’s still better than nothing.
– If you’re worried about the risk of data loss when using a custom compression scheme, fear not! This RLE implementation is done in a single pass and it calculates a CRC value of the original data en passant. If the reconstituted data does not match the original, loading the state file fails. Because this never happens, absent intentional corruption, you can be assured that your data is safe. It has been tested for months internally, and the debug version goes so far as to double-check the CRC and immediately decompress it into RAM. Also, temp state files (Alt-F5/F8) used RLE so you may have tested it already.
– Some more advice: quit the program or use Reset and Clear when switching games. This clears out the VM RAM, so RLE will perform better. (This also improves compression generally; the effects just aren’t as obvious without RLE.)
– The MBCS edition does not apply RLE to state files for compatibility reasons.
– The manual has additional information and details about the RLE implementation.
