As your case is very hopeless, I send you my disk image of the demo, with DOS 1 and an autoexec.bat. No any problem in NLMSX !!! 8)

I'm not really interested in specifically THAT demo, I've seen it on my real MSX this evening. I just want to know what I am doing wrong, so I can change it. Or maybe I'm not doing something wrong and there simply is a bug in something (except for my brains ) Could someone please have a look at that DSK-image and boot an MSX2 config in NLMSX and try it?

Thx!

Anyway, thanks for your image. And indeed, it works without problems

Latok, when I view the diskimage you supplied with DskExplorer, I can see that the archive-bits of the files are not set (except for MSXDOS.SYS & COMMAND.COM, which is why the disk is still booting to DOS). So, I extracted those files (archive bit was set automagically), copied them back again, and voila, a working snowfall demo!

I did some checks on that diskimage... The files which didn't have the archive bit set, have the attribute byte set to 128 (which doesn't have any meaning, IIRC). The files with archive bit set are correctly, attribute byte of those is set to 32 which matches the archive bit.

It might be possible that those disk-utilities copy the attribute byte directly to the disk, without doing any checks on the values. Also, it might be possible that the attribute byte might have a different value depending on the OS. This is pure speculation though...

The problem seems to have a link with the used OS.
I use Win98SE and DiskManager gives me good working disk images.
Latok uses Win2k and WinXP : on these systems, DiskManager seems to give bad working disk images. The sizes of the files are the same than with use on Win98SE, but if you check the total occupied space on the disk image, then comes a strange surprise : less occupied space on the Latok's image than on my disk image created on Win98SE ...

Arjan and mars2000you, thank you for helping to find out what's wrong. I have some new info. When I add textfiles which are on my HD, then I see in Diskmanager that they are being given automatically an Archive attribute. AND it also works perfectly in NLMSX, booted in whatever config I choose. They are readable, the txt-files!

I'm starting to think in a totally different way now! The snowfalldemos are all in ZIP format. I use Winrar3.20 to extract the files. I usually never have problems with this extractor, but COULD it be that Winrar gives some strange Attribute to the files in the ZIP archive?

Maybe THAT is what causing my problem, instead of the OS I use?

Sorry, I mean they are in LZH format. And guys, that IS the problem. I now have unpacked the LZH-archive with LHA in a dosbox and it works PERFECTLY now.

Conclusion of these 2 days: it was all just WinRAR 3.20 which has problems unpacking LZH-archives...

you could call it a problem with winrar (extracting files from RAR directly to a diskimage works fine (archive bit set), but from LZH directly to diskimage not (archive bit not set). I don't know DiskManager, but in the case of DskExplorer the problem is caused when the archive bit is not set.

I don't think that the problem comes from WinRar. I have version 2.90 and I've just checked the result on dsk images by using 2 differents ways :
- start WinRar, open the LZH archive, drag and drop the files from the WinRar window to a new image in Disk Manager
- rightclick on the LZH archive, choose "Extract to ..." with the WinRar logo (I have also Winzip), drag and drop from the new directory to a new image in Disk Manager
In both cases, the attribute A comes with the file in DiskManager and the disk image works perfectly in NLMSX
Conclusion : the problem is the Operating System ....

No, the problem is not the operating system. The operating system just exposes a BUG in DiskManager. It's BETA software afterall!

/me doesn't understand why people want fancy GUI's, when most of the time they are more limited than command lines and/or are buggy beyond belief.

Quote:

No, the problem is not the operating system. The operating system just exposes a BUG in DiskManager. It's BETA software afterall!

You can indeed say that last version of DiskManager (0.08) was released on 13/02/2000 and that it's probably not adapted for Win2000 / XP.

I know that in some versions of RuMSX (written by the same author), there were serious problems with WinXP that are now resolved

Quote:

If you know something about MSX, you'd be able to work a commandline. So the ancient RDDSK.EXE and WRDSK.EXE should be all you need.

GuyveR800, are these utils available all over the internet? Do they also handle subdirectories? I thought these utils were sectorbased and not suitable for file managing.

And about the problem. It is the Archive bit which should be set in the image to make the image work. And how you do it, that's your 'problem'. Just make sure that the Archive bit IS set when you've copied the files into some Diskimage. Can this be the conclusion?

Quote:

GuyveR800, are these utils available all over the internet? Do they also handle subdirectories? I thought these utils were sectorbased and not suitable for file managing.

Yeah, they were (are?) distributed with fMSX.
http://members.tripod.com/~szanella/rdwrdsk.htm
has a MS-DOS/Windows port.

Quote:

And about the problem. It is the Archive bit which should be set in the image to make the image work. And how you do it, that's your 'problem'. Just make sure that the Archive bit IS set when you've copied the files into some Diskimage. Can this be the conclusion?

The archive bit stuff is just a work-around. There's a bug in DskExplorer/manager (whatever it's called ^^ that makes it only function correctly on a Win9x system. My guess is it will work on WinXP too if the file is located on a FAT partition.

Cheers GuyveR800. And I like the utils. Already using them and they work just fine. No support for subdirectories, but indeed, don't really need them when using emulators. Prefering my real MSX anyway.