Having problems doing a copy from H1: to an ATR disk.

[Docwiz]

Hi all,

 

I am using Spartados 3.2d on ATR disk and it works fine and then I am also using Atari800Win Plus 4.0 (the real release and not beta).

I can copy files out of a disk and put them to H1: but I cannot do the reverse.

 

for example:

I have a file on D2:example.bas I can copy this file to H: and it works fine.

However, when I try to copy files back on a disk image ATR it does not work.

 

It says FILE NOT FOUND. I do a DIR and it is there, but when I try to copy it it will not go back to the .ATR disk image and this image is NOT compressed.

In fact it will not copy to any ATR image that I have tried. It just says file not found.

 

I have tried several files and typing in *.DCM wildcards and doing it without and it still does not work.

 

I think it may be a bug of some sort, but I am not sure how to fix it. Has anyone seen this before?

I have even tried 3.2g of spartados on a different image and still the same issue.

 

My DCM to ATR converters will not work probably because the disk is a spartados disk.

 

oh and yes I have used an 8-bit before. Ran a BBS back in the day in Missouri.

I have tried to search and have not found anything.

 

So, if you know how to fix this, please help.

[Heaven/TQA]

i have no problem doing this but have you tried another dos? even dos 2.5 can do the work.

 

i would try to boot dos 2.5, mount a single or enhanced disc to d1, format the disc and then copy the file over with

 

C

H:FILENAME.BAS,D:FILENAME.BAS

 

please have in mind that you have to specify the destination filename as well as it is not like in the ms dos where the original file name is taken...

[Docwiz]

i have no problem doing this but have you tried another dos? even dos 2.5 can do the work.

 

i would try to boot dos 2.5, mount a single or enhanced disc to d1, format the disc and then copy the file over with

 

C

H:FILENAME.BAS,D:FILENAME.BAS

 

please have in mind that you have to specify the destination filename as well as it is not like in the ms dos where the original file name is taken...

 

I will try MyDOS and see if I can get it to work. I have not used Dos 2.5 because it does not see the H#: (hard drives) only D#:

 

Thanks for the help

Edited March 24, 2008 by Docwiz

[Heaven/TQA]

dos 2.5 can not display the directory but you can copy files over when you are knowing the filename...

[Urchlay]

I seem to recall the H: device not supporting wildcards... you tried copying a single file, typing its full name, instead of just *.DCM?

[Big_Mo]

I seem to recall the H: device not supporting wildcards... you tried copying a single file, typing its full name, instead of just *.DCM?

 

I was having a similar problem, and, as per your suggestion, I had to type out the full filenames, as in H1:README.TXT,D2:README.TXT, and then it worked.

 

If I didn't write out the full filenames, I would get ERROR 165.

[Shannon]

If you do a dir H:* in does 2.5 it will display the directory.

 

The H: device is weird and the way diffferent DOS's handle it is even weirder (I've actually traced the commands trying to track down a bug).

[thorfdbg]

If you do a dir H:* in does 2.5 it will display the directory.

 

The H: device is weird and the way diffferent DOS's handle it is even weirder (I've actually traced the commands trying to track down a bug).

 

This is due to several factors. For once, H: is an emulated device and it is up to the emulator to support it correctly. That said, the H: in atari++ had a long history of bug fixes, too, now hopefully resolved. However, another problem is, as you state completely correctly, within the DUP used to address H:. The problem with some DUPs is that they assume that everything that is a filename is handled by D: Specifically, for Dos 2.0s for example, the DUP interacted with the FMS (the "DOS.SYS") rather badly in the sense that it "peeked" into the FMS internal structures for example to resolve wild-cards. That is, a wild-card source file name for "duplicate file" would first open that file, and then go to the addresses *within the FMS* to extract the complete, resolved file name to put it into the destination. Needless to say, this doesn't work if another handler besides D: is the source of the copy operation.

 

Funny enough, the often critized Dos 3 introduced a XIO command for that (to resolve wild cards), and is a much cleaner implementation in many respects, though it's probably not a very useful disk organization with its 8 sectors per block for the notoriously small Atari disks. The "atari++" built-in Dos (Dos 2.++) again uses a similar XIO to resolve wild-cards, and the same XIO as Dos 3 used, which then again supported by the built-in H: handler. Thus, copying from wild-card sources will work if you a) use the built-in FMS, or b) with DOS 3 (urgh) or any other Dos that uses a "clean" access to the file names (probably not Dos 2.5, definitely not 2.0S). It's interesting to see how many "constructional" errors 2.0S has, this one, plus the lack of any "load binary file" XIO.

 

Greetings,

Thomas

 

(PS: Received your requests. It's being worked on, but I'm now in a conference, and will be on another one next week, so it might take longer, even though its almost done. Please stand by).

[Shannon]

Well thanks for the detailed info. In my particular example that I mentioned I was tracing the "delete" command. But it is really interesting to see the "unlogical" things DOS's do out of the logical neccessity of using less "resources", or to be more effecient, so to speak.

 

But yeah I'm sure there are numerous issues regarding the H: emulation. Please not any references I made to "H:" emulation was referring to atari800. Which is what atarixlbox is based off of. I may try other emu's in the future if I feel there is an advantage but at this point I'm still learning.