DOS disks with N: Handler updated on apps.irata.online.

[kenp]

Took a side trip to NOS to see if NCOPY works there but there isn't an NCOPY there yet.

 

So back to SpartaDOS and very carefully trying something very, very basic. 

 

Boot Spartados 3.2d from Irata,   NCD N1:TNFS//192.168.123.19/  (my local server), NPWD N1: and NDIR N1:  give the expected results including a file named FARKLE3.

 

(Now this is the closest I've gotten to seeing an NCOPY command work.)  Used   NCOPY N1:FARKLE3,N1:FARKLE4   to try making a new copy of a file with a new file name.  The new file name appears on a new file in the directory but the file is 0 bytes long.  No error message was generated.

 

Adding another network connection on N2: with   NCD N2:TNFS//192.168.123.13/  (a second server on another machine), tested with   NPWD N2:   and   NDIR N2:   and getting the correct results for the second machine.

 

But the attempt to   NCOPY N1:FARKLE3,N2:   results in an ERROR- 144.

 

The directories serving as the roots for the TNFS servers are both set to be able to read and write, create and destroy new files and directories.

 

If I can get a local NCOPY working then I can try again for NCOPY of files from remote locations.

 

Take care and thank you for any help.

 

[Teapot]

I was able to NCOPY files from a 1050 to my local server. But I haven't been able to then NCOPY those server located files to a FujiNet mounted disk image.

 

[just attempted]

D8:NCOPY N:DRAW.ASM, D1:

ERROR- 163

 

This is from SDX4.49 because the SD3.2d ATR won't boot for me on this U1MB 800XL.

 

If you are looking to copy files from remote servers to local servers, like the DOS+FujiNet ATRs, there's a Copy command in the FujiNet Config file browsing UI (as pointed out above by tschak909). So instead of mounting a file you can copy it to a local server or the SD card.

[Teapot]

I pulled out a stock 130XE and figured out the SD3.2d boot problem was the FujiNet HSIO setting.

 

Subsequent testing of NCOPY has had unpredictable results. Includes success and various failures. I'm going to have to be more methodical before posting any details.

 

[kenp]

3 hours ago, Teapot said:

If you are looking to copy files from remote servers to local servers, like the DOS+FujiNet ATRs, there's a Copy command in the FujiNet Config file browsing UI (as pointed out above by tschak909). So instead of mounting a file you can copy it to a local server or the SD card.

Copying files from a remote server to a local server would be good but the real aim (and, of course the one thing I realize in the typing that I haven't tried) is copying files from local floppy disks to a local server but If I cannot copy a file from N1: to N1: with a different file name then moving files from a floppy to the local server doesn't look good.  And, of course, most of my old floppies are in SpartaDOS format which no other DOS understands.  As mentioned somewhere, SpartaDOS was a great thing at the time with my ATR8000 but now feels a little like a jail.  Moving files from SpartaDOS file system floppies straight to a file system on the Linux machine would be so liberating.  (at least, so I hope.)

 

I'll look again for the COPY command in the Config screen. 

 

So, intent on making some progress, I tried it before I finished hit Submit.  Yes, there's a COPY option.  A whole mess of TNFS_WRITEs show in the TNFS log.  Don't see any indication of Read Errors which appeared when I tried to do a SpartaDOS DUPDSK to download a copy of SpartaDOS 2.3d.  I'll do some work with this downloaded copy and see where it goes. 

 

Thanks for pointing out the earlier comment again.  Gotta admit I get focused in one direction and it's hard to change direction sometimes.

[_The Doctor__]

The clipping of SIO limit capacitors and setting the SIO port speed index is covered. So if you haven't done those things, you are in for problems. 3x SIO is the upper limit for most old unmodified DOS variants or DOS that do not have high speed filter drivers.

Double check your index setting and make sure on the XL/XE line of machines the SIO caps are clipped out of circuit.

[Teapot]

I knew about the SIO capacitors. This is just a stock 130XE that I had stored away. The U1MB 800XL that I usually use works with the FujiNet at HSIO 0 with SDX4.49 and all the other DOSes I tried (2, 2.5, OS/A++) even if not at top speed. I do recall reading about SD being problematic but it didn't connect until I switched machines and the FujiNet Config acted very strange when trying to load. And then I remembered I should slow down the FujiNet for the stock system.

 

[kenp]

31 minutes ago, _The Doctor__ said:

The clipping of SIO limit capacitors and setting the SIO port speed index is covered. So if you haven't done those things, you are in for problems. 3x SIO is the upper limit for most old unmodified DOS variants or DOS that do not have high speed filter drivers.

Double check your index setting and make sure on the XL/XE line of machines the SIO caps are clipped out of circuit.

This is something I'd not run into, before, I think.  SpartaDOS seemed to want to change the SIO speed is I set it down to what it was trying to set as it's regular speed, 55K.  I haven't done any hardware changes with capacitors.  I'll look for more about that.

 

This newly downloaded copy of SpartaDOS cannot even do an NCD successfully, returns an Error 139.  I was able to do that from the remotely mounted SpartaDOS.

 

I think I'd better drop the N: handler and go back to just using the basic FujiNet .ATR type connections.  Although, I begin to wonder If the problems with the N: commands might be telling me that the other data moves might be off as well.

 

But it's getting late and the dog is starting to wonder why we not getting the last walk done.  Take care.  Good night.

[Teapot]

I was ready to methodically go through various combinations of 800XL(U1MB)/130XE and SD/SDX and HSIO speeds and real drives to get an understanding of the problem.

 

But it's just not failing today. I couldn't get full success at all yesterday and today I've run through many permutations on the 800XL and only 3 things have come out of it.

 

• SD3.2d requires HSIO 9 to even load (with U1MB providing only stock 800XL features). But the NCOPY worked repeatedly.
• HSIO 9 is faster than HSIO 0 for NCOPY ~70K from N: to D2:(TNFS) in SDX4.49
• Sporadic freezing during NCOPY that is fixed by pressing [Break] with nothing special showing up in the FN log.

 

I haven't checked but I think the files come through OK after a freeze. My evidence is the several times it froze while loading the NCOPY program and it still all worked.

 

I was even able to copy files from an XF351 (XF551 with a 3.5" drive (installed 30 years ago)) to N: at high speeds just by attaching the drive. 578K from a Sparta formatted floppy in one try.

 

I haven't pulled the SIO data line capacitors yet. I was going to get error data with them in place first. Now it looks like I maybe only need to do it for the very fast HSIO settings.

 

Sorry kenp, I was hoping to have some kind of solution or at least breakdown of problems. Have you tried reattaching it to the SIO port? Maybe it's a bad connection. That's the only thing that changed for me when I moved it between machines.

 

Good luck.

[kenp]

3 hours ago, Teapot said:

I was ready to methodically go through various combinations of 800XL(U1MB)/130XE and SD/SDX and HSIO speeds and real drives to get an understanding of the problem.

 

But it's just not failing today. I couldn't get full success at all yesterday and today I've run through many permutations on the 800XL and only 3 things have come out of it.

 

• SD3.2d requires HSIO 9 to even load (with U1MB providing only stock 800XL features). But the NCOPY worked repeatedly.
• HSIO 9 is faster than HSIO 0 for NCOPY ~70K from N: to D2:(TNFS) in SDX4.49
• Sporadic freezing during NCOPY that is fixed by pressing [Break] with nothing special showing up in the FN log.

 

I haven't checked but I think the files come through OK after a freeze. My evidence is the several times it froze while loading the NCOPY program and it still all worked.

 

I was even able to copy files from an XF351 (XF551 with a 3.5" drive (installed 30 years ago)) to N: at high speeds just by attaching the drive. 578K from a Sparta formatted floppy in one try.

 

I haven't pulled the SIO data line capacitors yet. I was going to get error data with them in place first. Now it looks like I maybe only need to do it for the very fast HSIO settings.

 

Sorry kenp, I was hoping to have some kind of solution or at least breakdown of problems. Have you tried reattaching it to the SIO port? Maybe it's a bad connection. That's the only thing that changed for me when I moved it between machines.

 

Good luck.

I do have a problem with trying to do too much with SIO speeds and such.  My floppies are mostly locked into the SpartaDOS format and I'm using, because it's what I had in the old days, an ATR8000.  I can't be certain that the ATR8000 is one of those HSIO devices.  I'm just going to have to keep plugging along with the basic FujiNet functions that are compatible with using the very old floppy disk interface I'm stuck with.  There are hints of other PC and maybe Linux utilities for unlocking files from the .ATR files.  I think I'd best just get along until I cannot find any way to transfer more stuff from the floppies then I'll explore the other options.  For surety, there might be some disk utilities that would be handy.  Programs that just work with sectors and are not concerned about the type of file system in encoded in them.  I found Copymate which seems to have options for formatting disks and verifying the copy and seems to just be working at the sector level.  Then some sector editors, maybe to inspect raw sectors and the file systems for errors.  Interesting to think that our PCs now have so much memory that we could just keep multiple images of floppy disks in memory to work on now.

 

Holy Doodle.  A 578K formatted floppy.  What type, tracks and sectors was that sucker?  I'll do it better if I ever get around to getting one of my 8" floppy drives working.  I've some 8" floppies that will need recovering as well.  They may be redundant but I'll never know if I don't get it working.

 

Thank you for trying to duplicate my problem.  I do appreciate the work you are doing to bring the old Atari into the future.

[Teapot]

I went reading back to find any other info about the ATR8000 and I came across this:

On 3/23/2023 at 4:22 PM, kenp said:

NCD N1:TNFS//192.168.123.19/

You are missing a colon here. There should be two. The first for the device name (N1:) and the second one for proper URL structure. It should be after the protocol - TNFS: like HTTPS:

 

NCD N1:TNFS://192.168.123.19/

 

 

I've been using Altirra with the H: device (works like N: but just a local host directory) to get files on and off of ATRs.

 

I also used it to make a few blank ATRs in various formats with and without DOS files that I just duplicate, rename and drop into the TNFS directory for FujiNet to mount.

 

1 hour ago, kenp said:

Holy Doodle.  A 578K formatted floppy.  What type, tracks and sectors was that sucker?  I'll do it better if I ever get around to getting one of my 8" floppy drives working.  I've some 8" floppies that will need recovering as well.  They may be redundant but I'll never know if I don't get it working.

 

It's just a standard 720K 3.5" floppy. That particular disk has 6 DCM disk image files (4 SD, 2 ED) and a few other files. I think I collected files at work via whatever network was available in 1990 and these disks were R/W natively by an Atari and a PC somehow.

 

1 hour ago, kenp said:

Thank you for trying to duplicate my problem.  I do appreciate the work you are doing to bring the old Atari into the future.

Oh, I'm not working on the project (yet). I'm just another user trying to get files off of ooooold disks and getting errors. Very coincidental timing that this was when I reached the point of pulling out the drives.

[kenp]

Just now, Teapot said:

I went reading back to find any other info about the ATR8000 and I came across this:

You are missing a colon here. There should be two. The first for the device name (N1:) and the second one for proper URL structure. It should be after the protocol - TNFS: like HTTPS:

 

NCD N1:TNFS://192.168.123.19/

 

This was a typo but only in transcribing what I'd typed into the Atari. 

Once I get everything in a form not dependent on real floppy disks I'll likely explore the Altirra.  That will likely be the quickest way to do the survey of what I moved from the floppies.  I was thinking of how fast an Altirra emulation might boot and run programs on the new processors compared to the original 6502 but your mention of a H: device makes it more interesting.

Seems to be more options to do a thing than I'd ever guess these days.  I hope there's a good manual for the Altirra around somewhere.

There's a vision of the far flung future with an entire Atari environment residing on a NVME drive in a little USB3 external case that can easily be moved between systems.