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

[tschak909]

#Atari8bit #FujiNet All of the DOS disks on the apps.irata.online TNFS have been updated and tested with the latest N: handler. Is there a DOS we missed? help me add it!

 

 

The DOS disks in the folder include:

* Atari DOS 2.0S
* Atari DOS 2.0D
* Atari DOS 2.5
* Atari DOS 3
* BeweDOS 1.3
* MyDOS 4.53
* OSS DOS XL 2.30p
* OSS DOS XL 2.30X (XL/XE)
* OSS OS/A+ 2.10
* OSS OS/A+ 4.10
* SpartaDOS 1.1HS
* SpartaDOS 3.2d
* TOP-DOS 1.5
* Turbo DOS XE 1.0
* XDOS 2.43

[kenp]

Alright.  Found my way here from a suggestion on another thread about the NOS.  Connected to the SpartaDOS image (because I have a bunch of old floppies in SpartaDOS DSDD format) from this list and have a D1: prompt, did a change to N: and got a new N1: prompt.  From the N1: prompt I did a DIR D2: and got the directory from my physical disk 2.  This seems to be the direction I'm looking for but I cannot find a set of directions for connecting the N: device to a remote file system.  (in my case that would be a file system on my Linux machine and, hopefully, a file system and not a container .ATR file.  The FujiNet lets me do that but I want to bring the full strength of my Linux system to bear on sorting and storing the files as I copy them from the floppies.) 

 

Is there a list of the commands used to direct the N: device to that remote file system and which protocols it understands.?  Please, if there is just point me there and I'll see what I can do.  Yeah, I'm trying to catch up years in as little time as possible (before the dang mould eats any more of my floppy disks. 🙂 )

[+DjayBee]

Check the chapter regarding the setup of a TNFS server.

 

https://github.com/FujiNetWIFI/fujinet-platformio/wiki

[tschak909]

The available filesystem adapters:

N:FTP://<host>/<path>
N:SMB://<host>/<path>
N:TNFS://<host>/<path>
N:HTTP[S]://<host>/<path>

 

NLOGIN can be used to set a username and password for adapters/hosts that need it.

 

The one that will be of most use to you, is the TNFS adapter:

 

you can e.g.

NCD N:TNFS://TMA-2/

 

SpartaDOS makes some _REALLY_ silly assumptions, namely that any filenames will be converted to and from uppercase, and that filenames DO NOT HAVE SPACES. This can make using the CD command not work as intended in some cases. This is one reason why the N* tools exist.

 

This wiki page has a lot more information:

https://github.com/FujiNetWIFI/fujinet-platformio/wiki/Using-the-N%3A-Device

 

-Thom

[kenp]

Yes, I've run into some SpartaDOS foibles as I've been relearning all the things I've forgotten from 35 years ago.  I already have a TNFS server and I see your example points to a directory and not an .ATR file.  I'll be looking very closely at that soon.  There are instances where having a container for something like an image of a factory disk is a good idea but there are other thing, like the collected games files that just sit on floppy after floppy that, I think, would be just as efficiently gathered up into one directory somewhere.  This will be a good start and If I can translate some of the SpartaDOS floppies to something else that will be good as well.

 

Ah ha.  I see in a quick glance that there can be several N: devices just as there can be several floppy drives.  Very good.  This looks better and better.  And I'll look for the N* Tools as well.

 

Thanks for the pointers.

 

You know when I started this with no looking ahead to see what there was already done I was thinking I might end up using a Raspberry Pi or Arduino to make a floppy disk emulator.  Then I started to run into things like the SIO2XX cables, device emulation software for PCs and the FujiNet.  Dang, that FujiNet makes my old ATR8000 look like a sorry old tank by comparison.  And now a Network driver for talking to PC file systems directly.  Amazing.

[+DjayBee]

11 minutes ago, kenp said:

I already have a TNFS server and I see your example points to a directory and not an .ATR file. 

If you use the N-tools, the TNFS is your filesystem and you can move files directly into directories of your server. 

 

However if you mount an ATR from the TNFS server into one of Fujinet's drive slots, it looks to the Atari like a full disk (and you don't need any N-tool to access this virtual disk). 

[tschak909]

The FujiNet also does CP/M, too.

[kenp]

1 hour ago, tschak909 said:

The FujiNet also does CP/M, too.

Oh, yes, I've seen that, too.  But right now I'm just working on trying to copy stuff off the What used to be hundreds of floppies.  I say used to be because a bunch of disks have become mouldy over time and will have to be cleaned before they can be read again.

 

Hey, I was trying to do a dup disk from the Irata server to a physical floppy so I'd have a new SpartaDOS boot disk with the N: device.  How do you read bad sectors in a transfer like this?  🙂  

edit:  it reports bad sectors when trying to dupdsk to a local .ATR file as well.   Bad sectors in a .ATR file?

Edited March 17, 2023 by kenp

[tschak909]

14 minutes ago, kenp said:

Oh, yes, I've seen that, too.  But right now I'm just working on trying to copy stuff off the What used to be hundreds of floppies.  I say used to be because a bunch of disks have become mouldy over time and will have to be cleaned before they can be read again.

 

Hey, I was trying to do a dup disk from the Irata server to a physical floppy so I'd have a new SpartaDOS boot disk with the N: device.  How do you read bad sectors in a transfer like this?  🙂  

edit:  it reports bad sectors when trying to dupdsk to a local .ATR file as well.   Bad sectors in a .ATR file?

I think you're conflating things slightly.

 

The N: device doesn't deal in sectors at all, it opens a stream, and characters come through.

 

Are you trying to duplicate disks that you've mounted on a drive slot to a real disk? that should just work. Network errors do happen, and we try our best to recover from them (5 retries of a command, before failing).

 

-Thom 

[kenp]

11 minutes ago, tschak909 said:

I think you're conflating things slightly.

 

The N: device doesn't deal in sectors at all, it opens a stream, and characters come through.

 

Are you trying to duplicate disks that you've mounted on a drive slot to a real disk? that should just work. Network errors do happen, and we try our best to recover from them (5 retries of a command, before failing).

 

-Thom 

Used to work in networks support and can certainly agree that networks have transmission failures but networks have been so fast and reliable these days that one can forget they still can have hiccoughs.

 

So, that brings up the question of what message would be shown if the transfer was considered to have failed completely because I was getting bad sector messages for intermittent sector reads along the way and that made me concerned that the transfer may not be complete. 

 

btw, I been using the SpartaDOS dupdsk command because most of the disks I've been working with so far have been SpartsDOS DSDD 368K type formats.  I've been trying to remember what sector copier I might have used in the old days but not sure which one was preferred now.  Something that really doesn't pay attention to the file system and just does the work of copying sector by sector would be useful, I think.  Of course, perhaps not all of them would realize that there are bigger than SSDD from one of the Atari floppy drives.

 

Anyway, this is a great idea and the capacity to work with the TNFS server and floppy disks at the same time is something I'm going to worry like a dog with a bone until it works.  🙂  

 

Thanks.

[kenp]

Wait.  I'm not using the N handler and the N commands yet.  I've been mounting and booting from the SpartaDOS 3.2d on apps.irata.online through the FujiNet as D1: and then trying to do a SpartaDOS dupdsk from the D1: remote mounted .ATR file to a D3: mounted .ATR file on my system so I can boot SpartaDOS3.2d with the N Handler locally.  When I try this dupdsk command it reports bad sector reads when trying to do the copy.  I've watched and the bad sector numbers are different in each attempt.

 

But, wait, I'm booted from the SpartaDOS 3.2d on apps.irata.online.  That has the N handler and commands so I should be able to do an NCOPY of the .ATR file itself from an Nx: device to a local Nx: device, yes?  My local Nx: device can be a directory on the TNFS server, for example, /work/ATARI/ so I'd do an  "NCD N3:TNFS://Socrates/work/ATARI/" to set the destination.  But what would be the directory designation for the directory where the SpartaDOS3.2d.atr can be found?  It'll be an "NCD N2:TNFS://apps.irata.online/<somedirectory>".  Then I'd be doing a straight stream NCOPY of the .ATR file from the apps.irata.online server to my server.  AND this should get around the bad sector reads being reported in the dupdsk command.  (unless there are bad sectors in the .atr file on the server.)  I'd like to try it but need the directory designation for the directory where the SpartaDOS3.2d.atr is.

 

I'm assuming you can do this safely because all the directories and files are set to be read only so changes cannot be made to the server's file system.

 

Thanks.

[kenp]

nope. this isn't going to work.  I've tried to mount the Socrates/work/atari directory as a N3: device but get errors when I try to do things like ndir n3:, nmkdir n3:test/.  the npwd n3: gives the right result. 

Maybe I'll try the NOS just to see how that behaves.  If I can get a connection to two TNFS servers, a remote and a local, that would be progress.

[kenp]

Moved this away from the NOS thread.

Did the firmware upgrade to the Fujinet, now current to Mar 18 release.  Some of the mounting of .ATR files seems a bit perkier.  but the N: device stuff is till lost to me.

 

Tried booting the SpartaDOS 3.2d with the N: handler and commands.  I do a NCD of N1: to a local TNFS directory and the NPWD returns the same directory name so that seems to be okay.  But when I do a NDIR N1: from the regular D1: prompt the return is SIO ERROR.  I can change to the N1: device by entering N1: and get the prompt N1: back but then the plain NDIR command returns and Error 146.  Granted this is at the moment an empty directory.

 

Just tried putting something in the directory, a print.pdf file from earlier but still get the same return messages. 

 

And to satisfy an old thought, I'd reduced the number of files in the storage directory down to less that 12.

 

Not having much luck so I'm going back to just to copying disks to .ATR files.  If the N: device stuff comes around again I can still move stuff from .ATR files to plain filesystem storage.

[Teapot]

I just got this working after pulling a drive out of storage.

 

I booted the OS/A+ 4.10 DOS from irata.

 

Set the real drive to D2:

 

NCD TNFS://hostname/test/

NCOPY D2:*.* N:

 

I was able to watch the files show up in the host file viewer (Mac Finder).

 

Note that the capitalization is important.  The protocol (TNFS) must be upper case and the path must match the host requirements (case sensitive or not).

 

You also have to have the slash at the end or things act funny. Including SIO ERROR.

 

 

I got it to work with the DOS 2.5 ATR too but it's soooo tedious that way.

 

The SpartaDOS 3.2 ATR wouldn't boot for me but I'll need to get some version working if I want all my files. I'm still working on getting it functional in the U1MB SpartaDOS. There's maybe a problem with Sparta having its own idea of an N: drive.

[_The Doctor__]

Try N1:

maybe?

since N: = Drive 14

Sparta needs to see N1:

as Nx: is a device but N: could be a drive like A: thru O:    for SpartaDOS X,   up to drive 9 in 3.2g etc without modification

 

Certain Sparta versions may track lasted logged drive as 'D:' but certainly has no ability to do so with an external device handler if it isn't part of that handler

 

 

Edited March 21, 2023 by _The Doctor__

[Teapot]

27 minutes ago, _The Doctor__ said:

Try N1:

maybe?

since N: = Drive 14

Sparta needs to see N1:

as Nx: is a device but N: could be a drive like A: thru O:

 

I've tried variations with N: and N1: with various filenames and wildcards and all I get is:

COULD NOT PARSE FILESPEC.

 - or -

138 Device does not respond

 

I get the first one from the FujiNet default disk image on D1: and I get the second one from the latest fnc-tools.atr

 

NCD, NPWD and NDIR all work.

 

[_The Doctor__]

there are syntax limitations,

NCOPY D2:*.* N:

maybe

NCOPY D2:*.*,N:

maybe the coma is needed?

maybe it can't do a wild card?

maybe it needs a further wild card?

NCOPY D2:*.*,N:*.*

 

I suggest a quick watch of the video and a quick read of the instructions for the variant you are using. differences are slight but they matter.

 

 

Each DOS may have slight differences in the way N is spoken to, I can tell you when I had a fujinet I used a comma, that being missing might be what is messing a few people up.

 

Once you are sure you have the SYNTAX correct then you might watch the whole video and make sure all of the required Fujinet files are in the SpartaDOS X image you are using etc.   When you know you are using the correct syntax and the files are there, if it still fails then you might approach folks with your findings.

 

depending on your cartridge source there are some things for usability to do. see this video

 

Edited March 21, 2023 by _The Doctor__

[kenp]

SpartaDOS X is the one that requires a cartridge, yes?  Haven't got it.  Been sticking to the 3. versions.  The 3.2d with N Handler came from Irata.  In fact I usually just boot straight from there.  I'm not at trying to use NCOPY commands when I cannot even get a valid response from a NDIR command.  The comment about the where the drives are, slot number 14 for N:, is likely part of the problem since I'm still using these older version of SpartaDOS.  Sometimes I see problems with the old SpartaDOSes when trying to get above the fourth drive slot.

 

I'd love to try some other OS but the dang floppies I'm trying to shift stuff off of are mostly in SpartaDOS file system formats.  I USED TO love that OS but now it feels like being in a jail.  It was like being in CP/M with all of the commands rather than the menu systems.  (CP/M was my first environment.)

 

And the ATR8000 is beginning to feel something like an albatross as well.  Again it was a great thing at the time because of the full DSDD floppies (and the 8" drives which have faded into the background for now) it gave me but now only a few OS or copy programs understand DSDD so that's a difficulty and, of course, SpartaDOS file systems are only understood by SpartaDOS.

 

I'll have a look at the videos to see if there's anything that I can apply but I think I'm going to have to leave the idea of a network file system behind for now and just work on copying stuff to the .ATR files.  At least the mould can't get to .ATR files on HDD.  🙂

 

Here's a really dumb question.  If you are using Altirra and have an SIO2PC(USB) cable can you connect a real world floppy drive to the Altirra emulation?  I probably shouldn't even think of such a thing in the state I am.  Imagine the abomination of an Altirra connected to an ATR8000 but I bet SpartaDOS X runs on the Altirra with an emulated cartridge, eh?  Dang, there's just so much to really catch up on here.

 

Thanks for all the help received so far and for all the help you're still doing for people.  Take care.

[kenp]

There was something interesting in those videos, the F commands.  Just meant to make the managing of .ATR files easier, I think.  But very useful.

 

As an example, I did use the FNEW command to create a new .ATR file, although looking back I didn't actually name it with the .ATR extension and it created a new file in the local server which I was able to format.  As it was created in a particular slot and formatted right there is was already to go and showed the right DIR and CHKDSK return.  That's handy as i don't need to go back to the web interface to change things around.  And its a quick way to create a new disk image file, meaning I don't need to create and have on hand a bunch of .ATR files ahead of time.  Good stuff.

 

BUT, ( and you just knew this as coming, didn't you? 🙂 )  after the FNEW command returned CREATING DISK and chirped on the speaker for a bit it returned FUJINET NOT READY.

 

Hold on, I just tried it again to make sure I had the correct diagnostic and the return for another FNEW command came back with D4: (8) (W) FARKLE4 which matches the place I wanted the new disk created and the name I gave it.  Okay, tried again and got what looks to be the proper return for a successful creation again.  Well, bugger, is Mercury in retrograde or something?  🙂

 

Anyway, don't know about the N commands and whether they'll ever work for me but these F commands are going to be helpful.  Need to make a little notebook and put a list of them in it.  So glad someone else got into this project and created the FujiNet.  Saved me so much time as I was thinking that I might try to do something the like, not knowing that there were so many other crazy people already or, maybe, still working on these old machines.

 

Take care.  Thanks for the work you're doing.

[Teapot]

Speaking of the F commands, I was just trying to use them to copy one of these DOS ATRs to my local TNFS server and/or the SD card.

 

FCD worked as expected.

FLS works with slightly odd syntax ("FLS 3," instead of just "FLS 3").

FCOPY doesn't work. From SDX4.49 it just locks up with no feedback (not even "Copying..."). From DOS 2.5 it starts copying but quickly shows SIO ERROR.

 

Is there a way to copy these augmented DOS ATR files from the irata.online TNFS server to other, local locations? Like maybe via a web browser?

Edited March 21, 2023 by Teapot

[tschak909]

9 minutes ago, Teapot said:

Speaking of the F commands, I was just trying to use them to copy one of these DOS ATRs to my local TNFS server and/or the SD card.

 

FCD worked as expected.

FLS works with slightly odd syntax ("FLS 3," instead of just "FLS 3").

FCOPY doesn't work. From SDX4.49 it just locks up with no feedback (not even "Copying..."). From DOS 2.5 it starts copying but quickly shows SIO ERROR.

 

Is there a way to copy these augmented DOS ATR files from the irata.online TNFS server to other, local locations? Like maybe via a web browser?

Use the [c]opy command from inside config, when you're looking at a slot's directory.

-Thom

 

[Teapot]

6 minutes ago, tschak909 said:

Use the [c]opy command from inside config, when you're looking at a slot's directory.

Well, that's an appropriately obvious place for it. I wish it had bit me.

 

So is FCOPY not expected to work? Does having no DOC file mean don't use it?

[kenp]

Well, when you've finally watched the dang videos for the umpteenth time and looked at the tnfsd log for also the umpteenth time, something finally clicks.

 

When I start the tnfsd program on the Linux machine I tell it the directory to use as root,  /WORK/ATARI/,  So IT ALREADY KNOWS WHERE THE ROOT IS.  Then when I'm doing an NCD to link a device name, like N1: to the server,  I DON"T HAVE TO TELL IT AGAIN.    I was linking to the server with "NCD  N1:TNFS:/192.168.123.19/WORK/ATARI/".  That meant I was trying to connect to /WORK/ATARI/WORK/ATARI/ which, of course, doesn't exist.  That's why it was giving me all this grief.  I finally noticed that the guy in the video on YouTube only gave the server name, just the name, not a directory, just the server name, right?   Right. 

 

Man, this would all make so much more sense if I were drunk instead of just tired beyond reason.

 

Anyway, when that clicked I did and "NCD N1:TNFS//192.168.123.19/" and there it was in all its glory.  The directory I've been trying to reach for the last week.  Boy, do I feel stupid.

 

Again, this is a great piece of work and I can appreciate it even better now that I have a better idea of what I'm supposed to be doing.  🙂

 

(I was using the NOS when I found this little error on my part.  Now I can't wait to try it in SpartaDOS, but I'm being called for dinner and the dog has come to remind me I'm not upstairs where I should be so I gotta go.  🙂 )

[_The Doctor__]

Don't feel stupid, just write up some docs that explain where it goes wrong and where it goes right. That way the rest of the silent majority will have some answers.

If it doesn't make the main document it could end up as a side panel tip and tricks thing or part of a Q&A item.

You are not the first person to go through this sort of thing. So chin up, you may help others to avoid the issue in time.

Edited March 22, 2023 by _The Doctor__

[tschak909]

33 minutes ago, Teapot said:

Well, that's an appropriately obvious place for it. I wish it had bit me.

 

So is FCOPY not expected to work? Does having no DOC file mean don't use it?

FCOPY uses an SIO command for the Fuji device that isn't implemented yet.

-Thom