NOS version 0.4.2 released

[tschak909]

Michael Sternberg @16kRAM has released NOS version 0.4.2 alpha:

 

You can use it on TNFS apps.irata.online:/Atari_8-bit/DOS/nos-v0.4.2-alpha.atr

 

"Very minor feature update to NOS.
The AUTORUN  batch file can be bypassed by holding the OPTION console switch when:
1. (if booting with BASIC disabled) the FUJINET NOS banner appears - or -
2. (if booted with BASIC enabled) switching from BASIC to DOS the first time.

This might be useful if you have an AUTORUN batch file configured that you know will raise an error or timeout in your current environment. "

 

For those that do not know. NOS is a bootable disk containing only the N: device, and a simple command parser, replacing a typical DOS for #FujiNet use.

 

And as with everything else on the #FujiNet project, source code is available in this github repo: 

https://github.com/FujiNetWIFI/fujinet-nhandler

Edited March 8, 2023 by tschak909

[kenp]

I've just run into this and haven't found too much about it so some dumb statements and questions to try and get up to speed.  The idea, from the bits I've seen, makes this appear to be a new device handler that can replace the floppy disk with connections to storage on other devices over the network allowing the Atari to boot from that remote storage and open, read and write files over the network as well.  It looks that it can connect to several devices or file systems at once.   saw a video where it was said that it could connect to NFS, SMB , FTP and a couple of other remote storage protocols.

 

BUT it does replace the floppy disk device so you cannot use the floppy drives while the N: is in operation.  Is that right?

 

If you connect to a remote file source are you connecting only to .ATR files or to folders with files in them?

 

If it connects to remote file systems with actual files this might be very interesting as one could move files from the native Atari File system to a plain file system and be able to work with the files directly in that other systems environment.  But most useful if it were able to connect to both a floppy disk and the N: device.

 

(I'm starting to copy disks to .ATR files but that still locks the files away inside this special container.  It would be very useful to just be able to work with the files as files on the PC. )

 

[tschak909]

21 minutes ago, kenp said:

I've just run into this and haven't found too much about it so some dumb statements and questions to try and get up to speed.  The idea, from the bits I've seen, makes this appear to be a new device handler that can replace the floppy disk with connections to storage on other devices over the network allowing the Atari to boot from that remote storage and open, read and write files over the network as well.  It looks that it can connect to several devices or file systems at once.   saw a video where it was said that it could connect to NFS, SMB , FTP and a couple of other remote storage protocols.

 

BUT it does replace the floppy disk device so you cannot use the floppy drives while the N: is in operation.  Is that right?

 

If you connect to a remote file source are you connecting only to .ATR files or to folders with files in them?

 

If it connects to remote file systems with actual files this might be very interesting as one could move files from the native Atari File system to a plain file system and be able to work with the files directly in that other systems environment.  But most useful if it were able to connect to both a floppy disk and the N: device.

 

(I'm starting to copy disks to .ATR files but that still locks the files away inside this special container.  It would be very useful to just be able to work with the files as files on the PC. )

 

A typical Atari DOS is (other than a disk utility package) a handler that implements the "D:" device.

 

NOS does not have a filesystem of its own, at all, and instead loads an entry for the "N:" device, (and adds an entry for "D:" that also points to "N:" for programs that can't possibly fathom that anything besides "D:" exists.) 

 

In other words, it loads the N: handler into memory, and provides a command processor invoked by "DOS"

 

The N: device deals with network end-points. For protocols that deal with a filesystem, like TNFS, SMB, NFS, FTP, etc. this means that those protocol adapters do all the work to expose a file oriented interface (and providing a directory, when applicable.), but other things can be used. 

 

So yes, for filesystem endpoints, it allows you to deal with files on a file by file basis, rather than needing them inside images.

 

This means that the following device specs are valid for file-endpointy things:

N:TNFS://APPS.IRATA.ONLINE/Atari_8-bit/
N:FTP://FTP.PIGWA.NET/
N:SMB://WINDOWSSERVER/PUBLIC/

 

but there are other protocol adapters as well, that can also be used with N:, regardless of what adapter is used, it is utilized in exactly the same fashion, this is the point.

N:TCP://192.168.1.1:6502/ (TCP connection to 192.168.1.1 port 6502)
N:UDP://192.168.1.1:6503/ (UDP connection to 192.168.1.1 port 6503)
N:TELNET://BBS.FOZZTEXX.COM:23/ (TELNET connection)

and so on.

 

Because NOS does not provide a filesystem of its own, this means that disk drives can't be used. Believe it or not, this is not a bad thing. The FujiNet can't communicate with existing disk drives, so there's no way for NOS to ever support them, because all of the heavy lifting is done with the ESP32.

 

It means, that as more protocol adapters are written, NOS automatically supports them (and ironically, anything that uses the N: device, including the N* tools and the N: handler.)

[_The Doctor__]

and for funzies a raw connection to //BBS.BESTESTEVER.NET:800/

would be done in what fashion? same as your IP address examples or different?

Edited March 16, 2023 by _The Doctor__

[tschak909]

40 minutes ago, _The Doctor__ said:

and for funzies a raw connection to //BBS.BESTESTEVER.NET:800/

would be done in what fashion? same as your IP address examples or different?

N:TCP://BBS.BESTESTEVER.NET:800/

 

[kenp]

But you can use a FujiNet and a floppy disk drive at the same time.  That's how I'm copying physical disks into .ATR files on my Linux TNFS server. 

The option of working with floppy disks and remote file systems would be very handy.

(I'm too used to being able to use the local file systems and remote file systems together under Linux, I guess.  But I'm just a few months into the project of bring the Atari back to life so lots to do yet.  I'll find out more about it all as things move along.  AND there's a lot to catch up on.)

 

 

 

 

Edited March 17, 2023 by kenp

[+DjayBee]

You can do this with Fujinet but not with NOS, which was explicitly designed to be N:only. 

You need to boot any of the standard DOS images with an included N-handler. 

If you use Thom's TNFS server, you can find many of these. I only don't know the directory OTOH. 

[kenp]

11 hours ago, DjayBee said:

You can do this with Fujinet but not with NOS, which was explicitly designed to be N:only. 

You need to boot any of the standard DOS images with an included N-handler. 

If you use Thom's TNFS server, you can find many of these. I only don't know the directory OTOH. 

Found my way to a list of N: handler capable DOSes so I'll pursue that lead. 

 

I'm using my old 130XE at the moment but the vision of upgrading my older 800 with a 1 meg memory upgrade and a few other things and then having just the 800 with the FujiNet connecting to the LAN for everything else is very tempting.  There's been so much development with the old 8-bit system it just boggles the mind.

 

I do see the value of a NOS only but I'm in the transition stage where I still have a bunch of floppies to recover and move the data from.  And, of course, I've made it more complicated by having an old ATR8000 and a lost of disks in SpartaDOS DSDD formats.

[kenp]

That should be "lots of disks".  I've lost some disks to mould that I might be able to clean but we'll see what I can recover from the working disks first.

[desiv]

As someone who is not only new to Fujinet, but also to Atari in general, I have a question and pointers to docs are more than welcome...

 

I finally got this working (after some user errors on my Windows tnfsd setup) and can manually map N to my tnfs server.

I read in the OP about an AUTORUN file...

 

So, does that mean I should be able to just create a text file that has my NCD command named AUTORUN (or would that be AUTORUN.SYS or AUTORUN.AR0 or something else??  Been searching on this board and have seen a few options, but not sure they all apply here.)

 

So, in theory, I could create a file called AUTORUN (or whatever) that just had this in it:

NCD N:NTFS://192.168.0.195/

... and place that file on the NOS image or create it on the Atari on that image (have no idea how to do that yet, but thinking I can find an Atari text editor or something... Still learning Atari...)?

It's not a big deal to type that every time, but if I could have that happen automatically after I boot that image, it would be a bit nicer...

 

Thanx!

[desiv]

(First off, just noticed my NTFS typo above.  I meant TNFS)

OK, I almost thought I had it figured out.
I didn't realize AUTORUN was a command.  Found it in the HELP NOS commands.

Decided to try that, so I created a file on the root of my TNFS server called NOS.BAT.

In it is:

NCD N:TNFS://192.168.0.195/

 

And then I copied the NOS disk to the root of my TNFS folder and mounted it so I could write to it (doesn't look like that is necessary, but...).

Mounted it and booted.  Typed:

AUTORUN TNFS://192.168.0.195/NOS.BAT

 

Rebooted, but no automounting...

Typed "AUTOMOUNT ?" and I did see my automount still in there... 
So I am thinking maybe autorun BAT files have to be BASIC commands or ???  Not sure, just still poking... 

 

[16kRAM]

You have the right idea - NOS.BAT should just contain NOS commands such as NCD. It can not parse BASIC commands.

My first thought is it has something to do with the end-of-line (EOL) character in the file NOS.BAT.
The last byte of the file NOS.BAT needs to be either a $0A (Unix EOL) or $9B (Atari EOL). Windows EOL ($0D $0A) doesn't work well as it results in a garbage character when being read by the Atari. I'm unsure what Apple uses. If there is no EOL character at all, NOS will just continuously beep searching for an end-of-line.

For example, here I'm using hexdump from my modern computer to examine the bytes in the file

$ hexdump -C NOS.BAT 
00000000  4e 43 44 20 4e 3a 54 4e  46 53 3a 2f 2f 31 39 32  |NCD N:TNFS://192|
00000010  2e 31 36 38 2e 30 2e 31  39 35 2f 0a << Unix EOL  |.168.0.195/.|

$ hexdump -C NOS.BAT 
00000000  4e 43 44 20 4e 3a 54 4e  46 53 3a 2f 2f 31 39 32  |NCD N:TNFS://192|
00000010  2e 31 36 38 2e 30 2e 31  39 35 2f 9b << ATARI EOL |.168.0.195/.|

 

If you edit NOS.BAT from a text editor on the Atari, then you will be assured the end-of-line character is $9B.

I'm attaching the T:EDIT editor for the Atari below. You can drop it in your TNFS-shared folder and run it on the Atari using the example below:
( Note: T:EDIT apparently uses the same address space as BASIC in ROM, so be sure BASIC is not resident (if 800XL/XE, etc boot while holding the OPTION key) or use the NOS command NOBASIC to release BASIC's address space back to RAM. )

 

N1: NCD N1:TNFS://192.168.0.195/
N1: LOAD TEDIT.COM

Once in T:EDIT, Enter the NOS commands to be executed when NOS is loaded.
 

@SCREEN
NCD N1:TNFS://192.168.0.195/   (be sure to hit ENTER here - EOL char appears as left arrow)

CTRL+S to Save, Save as N1:NOS.BAT  (Note: If you ever encounter an application that complains about the Nn: device, substitute Dn:)

CTRL+Q to Quit to DOS
CTRL+L will load (if you need to make changes later)
INSERT adds spaces

The @SCREEN command will print the batch file statements as they are being parsed. This may help troubleshoot if all this turns out to be the wrong answer.

 

TEDIT.COM

[16kRAM]

This reminds me that my intent is for the byte $0D to be ignored during batch file parsing so that $0D $0A is treated the same as $0A.
I'll take a look at the code to understand why it isn't behaving correctly.
 

[desiv]

12 hours ago, 16kRAM said:

My first thought is it has something to do with the end-of-line (EOL) character in the file NOS.BAT.
The last byte of the file NOS.BAT needs to be either a $0A (Unix EOL) or $9B (Atari EOL). Windows EOL ($0D $0A) doesn't work well as it results in a garbage character when being read by the Atari. I'm unsure what Apple uses. If there is no EOL character at all, NOS will just continuously beep searching for an end-of-line.

 

Yep, that was it!

I used Notepad++ to convert the EOLs to Unix style and it worked!

[Peter Kmet]

If I understand it correctly N: can not be used along with D : due to fact standard DOS interacts with devices on block (sector) level while NOS interacts with device on higher-level (logical files). DOS accesses raw blocks of data and assembles it to provide file streams to application using main CPU. In contrast, NOS is actually a DOS replacement which does the same except assembling of raw blocks of data outsources to external CPU (ESP32) which provides file streams out of the box from the device. So it looks like if NOS should work with floppy it would need to implement this sector-to-file management functionality. I wonder if under regular DOS it is allowed to use multiple different "file-management" routines which would let N and D coexist.

[tschak909]

Just now, Peter Kmet said:

If I understand it correctly N: can not be used along with D : due to fact standard DOS interacts with devices on block (sector) level while NOS interacts with device on higher-level (logical files). DOS accesses raw blocks of data and assembles it to provide file streams to application using main CPU. In contrast, NOS is actually a DOS replacement which does the same except assembling of raw blocks of data outsources to external CPU (ESP32) which provides file streams out of the box from the device. So it looks like if NOS should work with floppy it would need to implement this sector-to-file management functionality. I wonder if under regular DOS it is allowed to use multiple different "file-management" routines which would let N and D coexist.

You're conflating things a bit. Let me see if I can untangle and clarify.

 

"D:" and "N:" are each addressed with different handlers, and both funnel through the CIO. This means that N: and "D:" can coexist together at the same time.

 

You can, for example, load the NDEV.COM  driver on any of the DOS disks on apps.irata.online, and suddenly get the N: device alongside the "D:" device.

 

The issue is that NOS does not provide any filesystem of its own, at all, and thus no "D:"

We do also map "D:" to "N:"'s handler table in HATABS, because some programs simply can't fathom  that anything but "D:" can  handle file names.

 

NOS is literally meant to try and and provide an environment that entirely works with the FujiNet, and saving memory in the process, while trying to escape from the limitations of Atari filesytstems.

 

Because protocol adapters could be made that peer into filesystem images, this means that once they are made, NOS could read and write inside those images. This is something I hope somebody would be interested in trying to implement (and I will always help)

 

-Thom

 

 

[Peter Kmet]

I understand NDEV is accessing raw blocks (thus need reading/writing to remote ATR image). I just wonder if standard DOS can work in the same way as now while N handler bypass DOS file-system and talk to SIO in such a way that filesystem on ESP32 is processed, in the same time. Probably I need to read more how CIO to SIO works but since "D:" and "C:" can coexist having radically different means of provisioning file streams, I thought this could be doable.
I like idea of using "virtual" filesystem, removing the need of Atari to keep track with physicals properties of storage medium and let external CPU to do it. This way we could forget about ATRs and its limitations, densities and other non interesting properties.

[+DjayBee]

3 hours ago, Peter Kmet said:

I understand NDEV is accessing raw blocks (thus need reading/writing to remote ATR image).

It does not. NDEV has no idea of blocks, it only sends commands to FujiNet which the handles whatever NDEV wants (and FujiNet supports certainly). Thus it can coexist with any Atari DOS because it only implements a new device, named N:

To put it in a different way: NOS basically is NDEV with an added command processor and without any underlying DOS and therefore without the capability to access "D:" devices (but also without the memory requirements needed to implement "D:").

 

3 hours ago, Peter Kmet said:

I just wonder if standard DOS can work in the same way as now while N handler bypass DOS file-system and talk to SIO in such a way that filesystem on ESP32 is processed, in the same time.

This is exactly what NDEV does.

Edited March 19, 2023 by DjayBee

[kenp]

Does NDEV need a particular level of code in the FujiNet?  I've been having some trouble and getting messages like FujiNet device not ready.  Mine has the 1.6 version code and I might look for a later one if it's needed.  (everything I've done so far has been good but this is starting to push the envelope again. 🙂 )

 

[tschak909]

13 minutes ago, kenp said:

Does NDEV need a particular level of code in the FujiNet?  I've been having some trouble and getting messages like FujiNet device not ready.  Mine has the 1.6 version code and I might look for a later one if it's needed.  (everything I've done so far has been good but this is starting to push the envelope again. 🙂 )

 

The debug messages like "FUJINET NOT READY" have been removed. Are you using the DOS disks on apps? They all have a copy (and most of them autorun it)

 

-Thom

 

[kenp]

34 minutes ago, tschak909 said:

The debug messages like "FUJINET NOT READY" have been removed. Are you using the DOS disks on apps? They all have a copy (and most of them autorun it)

 

-Thom

 

Pardon me, the exact response if "FujiNet not responding"  but this is the return from trying to do a NMKDIR N3:TEST/ after using  NCD N3:TNFS://192.168.123.19:/WORK/ATARI.  I do get the same link back if I do a NPWD N3:.  In the same session I can link to an .ATR file and work with that so the FujiNet is responding to some calls.  If I try a similar plain SpartaDOS command to CREDIR N3:TEST/  the return is an Error 138.

 

The idea of simply using the file system on the Linux machine as the file system for the Atari is so tempting for some of the migration.  Like a whole set of disks with just a bunch of DOS load games.  Not boot disks just files.

 

Just had a thought but it will take a bit to test it.  Again it has to do with how many files there are for the FujiNet to deal with but I'll need to migrate some stuff around and I have to leave for an appointment in a minute.  Still would like to have your comments about this so far, though

 

(Of course, part of the problem is likely that I'm trying to get this all to work through SpartaDOS because I have a bunch of SpartaDOS formatted floppy disks from the old days I'm trying to migrate stuff off of.  AND, to complicate things, I guess, I'm using a Linux machine for the FujiNet server with the tnfsd.linux64 daemon.)

[kenp]

4 hours ago, kenp said:

Just had a thought but it will take a bit to test it.  Again it has to do with how many files there are for the FujiNet to deal with but I'll need to migrate some stuff around and I have to leave for an appointment in a minute.  Still would like to have your comments about this so far, though

More thought about this.  In this mode the FujiNet isn't looking at files, I don't think.  It should just be passing the bytes back and forth and the OS in the Atari would be counting files.  The old floppy disk file system imposed a certain number of files on each floppy disk (which we hardly ever reached with the small file spaces available.)  SpartaDOS may have allowed for more with its larger file system space.

[kenp]

So much detail I'm losing it here. 

 

What I have, according to it web interface, is version 1.6 hardware.  It looks like the firmware is still 0.5.c68d21b5 2022-11-06 21:20:11.  I see there is a thing called the 1.4.1 FujiNet  Flasher but I'm not sure what version of the firmware that will flash.  I'm also concerned about which hardware I have as I got it from a different source than the one where you had a choice of three different styles of the FujiNet depending on which style matched your computer.

 

Took a chance and opened the flasher and see there is a newer firmware from just yesterday  (and the firmware I'm running seems to be a Beta version from last November.)  Now I just need to find the instructions for flashing the FujiNet, which I'm betting means connecting the FujiNet to the PC running the Flasher using the USB connection but can it still be powered by having it plugged into the Atari?  Hmmm?

 

Tell you what.  Let's just bully on through and see what happens.

Edited March 20, 2023 by kenp

[tschak909]

Yes, you can flash the device, while plugged in to the Atari.

 

-Thom

[kenp]

It worked.  My FujiNet is now updated and I'll have to try all these things I've been kvetching about and see if they work now.

 

Hey, them updates come pretty frequently, too.  Gonna have to keep an eye on that.

 

It got enough power through the USB cable and the Flasher program has a nice little message window to say what is happening.  It's even got it's HTTP server running so I can check it via the web browser and see that the update has happened.  Very good work on the part of everyone involved.  My thanks for such a great product.