Emulated Amiga gives Guru Meditation when DMS file is renamed

Hello all.

I'm using WinUAE 2.4.1 32bit running on Windows 7 64bit to emulate a stock A500 with 512KB Chip RAM, 512KB Slow RAM, OCS and a single floppy drive. From Aminet I downloaded the old demo Amazing Tunes II by SAE in DMS format.

By default the modified 1MEG version of this demo comes as three DMS files, AmazingTunes1a.dms, AmazingTunes2a.dms and AmazingTunes3a.dms (there are also three additional files ending in 1b, 2b and 3b which according to the ReadMe should be the original 512KB only versions, but I can't confirm this since Disk 1 of this set will not boot).

If I leave these DMS files with their default names, everything is fine. But if I rename Disk 1 in Windows Explorer -- either outside of WinUAE or within its Load/Save dialogs -- then try to load track 2 (Get Down Em) the emulated Amiga Gurus immediately after the tune is loaded and unpacked with error #00000003.00C01570.

It took me ages to discover this, since renaming the files was the first thing I did after downloading them and I didn't even entertain the possibility that it could be related. I spent hours playing with emulation settings before renaming the files back "just to eliminate the option". I still can't quite believe that this was the cause. I just can't understand how the name of a file container in the host OS can affect operation of the emulated code, but it's 100% repeatable.

I'm the first to admit that I don't understand the inner workings of DMS files and after searching in here it does seem they're a little more complex than it might at first appear, so perhaps there's something I'm missing. A checksum related to encryption perhaps?

The only thing I could find in here that had anything related to DMS and renaming was an old thread from 2002 warning that excessive filename length can cause issues, but what I'm seeing goes beyond that. It doesn't seem to matter what the file is renamed to, be it short, long, with spaces, without spaces, with or without special characters. About the only thing I can get away with is case changes. Anything else, either addition or removal of characters, results in a Guru Meditation when I try to load that second track.

Absolutely bizarre.

It's actually made me wonder whether other problems I've had with various incarnations of UAE and DMS files over the years might have been related to this issue, since giving files more meaningful names is often one of the first things I did when downloading them. In most cases I just tried a few emulation options and gave up.

For what it's worth I tried using XDMS under a virtual 32bit XP to convert the DMS files to ADF files and use those in the emulator. In that case the Guru Meditation upon loading track 2 happened every time regardless of the Windows filename. Might this suggest the DMS is somehow corrupt and is causing problems with both XDMS' and WinUAE's unpacking routines? But if so, why would leaving the filename alone 'cure' the corruption?

Any pointers as to what's going on here would be appreciated. I'm no expert but I thought I at least understood the relationship between the host file system and the emulated code within it (i.e. that there shouldn't really be any).

Apparently I was wrong.

[Toni Wilen]

My crystall ball says both AmazingTunes1a.dms and AmazingTunes1b.dms are needed to create complete AmazingTunes1.adf. (a = first half, b = second half)

WinUAE will automatically detect and load missing parts if files are using "standard" naming (<name>a.dms and <name>b.dms or similar)

D'oh!

It's so obvious once someone points it out. Renaming both the 'a' and 'b' portions with the same root does, of course, let the file load.

A combination of not understanding the nature of DMS split files and the misleading information in the ReadMe about the two versions led to this confusion. Well that's my excuse anyway.

A bit embarrassing, but at least my sanity has been restored and I no longer believe my Amiga and Windows file systems to be talking to each other and conspiring behind my back.

Thanks!

[StingRay]

The Aminet images are not 100% working! If you want to have fully working images, download them from my FTP, you can find the link in the readme for the WHDLoad patch.

Originally Posted by StingRay

The Aminet images are not 100% working! If you want to have fully working images, download them from my FTP, you can find the link in the readme for the WHDLoad patch.

Thanks for that. The ones on Aminet actually seemed OK once I understood about the filenames, but the ones on ftp.amigascne.org (that both Pouet and Exotica link to) are definitely broken. The dancer animation is corrupt and it wouldn't surprise me to find one or two damaged music tracks in there too. ISTR my 'original' floppies of this demo had bad data back in the 90s. Selecting the track Lost In Time used to crash the Amiga.

I'll keep your versions of Amazing Tunes II though 'cos they're easier to manage than the DMS versions.

Actually when I first got into Amiga emulation I was amazed at the number of corrupted demos that I'd always assumed were caused by my own damaged discs, but that had the exact same errors when I downloaded them from the archives years later. I guess it was the nature of the scene back in the day that disk copying was more common than downloading straight from BBSes. It took me ages to find a copy of Hardwired that didn't have a corrupted toilet sequence

Finally, a bit off-topic but I just want to say a big thank you to everyone involved in developing WinUAE. It's been a few years since I really played around with this emulator, and I had many a bad memory of messing around with graphics options and filter settings trying to find a compromise that looked good with various Amiga screenmodes but didn't use insane numbers of CPU cycles. I invariably ended up with multiple configurations for each machine type, one for Workbench, one for games, one for demos, sometimes one for each specific demo...

The latest versions are a revelation. Set the native resolution, apply aspect correction, fullscreen or full-window, and pretty much everything looks fine by default. An amazing achievement given the complexities of both the Amiga hardware and the Windows PCs running the emulation.

Kudos to all involved. It's all very impressive.