FujiNet exposes several devices to your ATARI computer. One of them is the network device, which can access local or Internet network resources. While we provide a handler that adds an N: device, certain programs (such as the DUP.SYS in ATARI DOS 2.0) write over the handler when they load into memory, making the N: device unusable within DUP.

To work around this, a series of tools exist which access the FujiNet network device directly via SIO, thus do not require the presence of the N: handler (also called NDEV.COM).

Each tool has been tested in every possible DOS, and have been made to adapt accordingly. Since SpartaDOS, OS/A+ / DOS XL, and XDOS all support command line parameters, the tools automatically fetch parameters if they are present. The tools fall back to interactive mode if no parameters are given on the command line.

Each tool (with the exception of NCOPY) has been written to assume that no use of N: means to refer to N1:. There are 8 such N[x]: devices, numbered N1: to N8:. Both the N: handler (NDEV.COM) and the N tools refer to the network devices in this same way.

Furthermore, the companion disk, fnc-tools-doc.atr contains documentation for each tool mentioned below.

The Tools

The tools themselves are not only present on the fnc-tools.atr disk on the apps.irata.online TNFS server, they are also present on each and every disk in the DOS folder on the same server. They are called the N tools, because they all begin with the letter ‘N‘:

• NCD. Changes the directory pointed to by the selected N[x]: device. It’s useful so you don’t have to type the full path to a URL, each and every time you refer to an N[x]: device. So you can type N:FROG.EXE instead of N:FTP://ftp.pigwa.net/stuff/collections/holmes cd/Holmes 2/Atari Archives/Antic Files/88/FROG.EXE each time! In other words, this tool affects all of the other N tools, as well as the N: device.
• NCOPY. Copies files. Takes a source, and a destination. Either source or destination can be a local device (D:, E:, P:, whatever.), or the network (N[x]:). It supports wildcards.
• NDEL. Deletes a file from the network.
• NDEV. Loads the N: handler into memory. Can be AUTORUN.
• NDIR. Lists the directory of a network location. It asks the FujiNet for a long directory listing, which preserves case, spacing, and wraps the output every 31 characters. File size is shown approximated to bytes, kilobytes, or megabytes, as needed.
• NLOAD. Loads and runs any standard ATARI binary load file, directly from any network endpoint.
• NLOGIN. Sets login and password credentials for network protocols that need them, such as SMB.
• NMKDIR. Tells a supported network protocol to create a new directory at the given path.
• NPWD. Prints the current directory pointed to by the N[x]: device.
• NREN. Renames an existing file, to a new name, separated by a comma. This is analogous to a move on some protocols.
• NRMDIR. Removes a directory pointed to by the N[x]: device. Depending on the protocol, the directory may need to be empty beforehand.
• NTRANS. Sets the translation mode for a given N[x]:, allowing you to convert text files to and from ATASCII into a compatible ASCII format, and back again. Setting a value of 0 turns off translation.

Relationship to NDEV.COM and the N: Handler

Both NDEV.COM and the N tools use the same network device on the FujiNet, in exactly the same way.

The N tools do not require NDEV.COM to be loaded, but the N tools help navigate network file systems, because the DOS you may be using may not know how to do so. NDEV.COM and the N tools work hand-in-hand to provide a transparent way to access network resources.

But the N: handler has some shortcomings:

• ATARI DOS 2, and DOS 2.5’s Disk Utility Package (DUP.SYS) is loaded into a fixed location in memory, which happens to overwrite where NDEV.COM loads, obliterating the N: handler. In addition, MEM.SAV must be enabled if you want to go back and forth between the DUP and another program, so that the handler can be restored on exit from the DUP. The N tools provide a sensible alternative to access the same network resources even though the handler can’t be used.
• MyDOS does not obliterate NDEV.COM in memory, so it can be used in its Disk Utility Package, so you can list directories and manipulate files using the usual commands. However, since the BINARY LOAD command has been moved to DOS.SYS, it is only accessible via the “D:” device, and calls it via CIO call #39, which NDEV.COM does not implement yet. The N tools provide NLOAD.COM, which can BINARY LOAD from the network.
• SpartaDOS (disk and X) has the same BINARY LOAD issue as MyDOS. In addition, SpartaDOS X’s command processor thinks of N: as “DN:” instead of device N:. While there will be a SpartaDOS driver for FujiNet’s network device in the future, the N tools can be used to access the network device from the SpartaDOS X command processor. (Disk based SpartaDOS can actually use N: directly, with some quirks.)
• NDEV.COM does not yet implement burst mode (anyone want to help implement it?)

Demo Video

Here is a demo video showing why the N tools are important. Chapter Index below.

https://youtu.be/BUR_KRTRWk0

Chapter Index for Video

00:00 The DOS folder
01:10 What happens when you try to use N: in DOS 2.0 DUP?
04:40 DOS 2.0…What happens when you try to go back to BASIC without MEM.SAV?
05:20 Creating MEM.SAV so we can preserve the handler for BASIC and other applications.
07:45 The N tools
10:20 using NCOPY to copy from the network, to a floppy.
12:00 using NCOPY to copy from a floppy, to the network.
14:30 using NLOAD to load Cyclod on DOS 2.
15:30 Comparing to MYDOS 4.53
16:40 comparing Viewing directory via the N: device
16:58 comparing Copying via the N: device
17:55 Whoops! can’t load a binary file in MYDOS via the N: device.
19:08 Loading binary file with NLOAD.
19:55 Using N tools in SpartaDOS X

Hi guys, reaching out for anyone who may be able to help implement a feature missing from the N: handler, “burst mode”

Specifically, when more than 1 byte is requested by an IOCB, set up a read for that many bytes directly into the buffer specified by the IOCB.

The nice thing is, that an intermediate buffer will no longer be required (it’s only required for disk because of the fact that you must read at least a whole sector’s worth of data at a time), however on the N: device, you use DAUX1/DAUX2 in tandem with DBYT to specify how many bytes to read at a time, with DBUF pointing to a target buffer.

I did implement this in an early draft of the NDEV handler 5 years ago, but was unable to fully debug it.

If you can help, the current code is here: https://github.com/FujiNetWIFI/fujinet-nhandler/blob/master/handler/src/ndev.s

CIO GET: https://github.com/FujiNetWIFI/fujinet-nhandler/blob/master/handler/src/ndev.s#L224

CIO PUT: https://github.com/FujiNetWIFI/fujinet-nhandler/blob/master/handler/src/ndev.s#L431

The above two routines are currently built to use a 128 byte buffer RBUF, and an index RLEN,X, but with burst they would hopefully be simpler.

Atari 8-bit FujiNet users: The N: Device handler (NDEV) has been updated.

STATUS calls will now return the total number of bytes waiting (up to 65535) in DVSTAT.

fujinet-nhandler.atr, and the entire DOS folder has been updated in the Atari_8-bit folder on apps.irata.online.

The following YouTube video shows how to create your own SpartaDOS X cartridge with the FujiNet tools, from scratch, using the SpartaDOS X Imager (SDXImager) tool.

For this video, I installed a fresh copy of Ubuntu Linux Desktop using default options, and added the following packages via a terminal:

sudo apt install build-essential git wine

Once everything is built, you can transfer it to the nearest FujiNet via WebDAV, by selecting Network in Files, and Connecting to the address of your FujiNet:

DAV://192.168.1.21/dav/

Links Used in the video

Ubuntu Linux: https://ubuntu.com/download/desktop

CC65 Compiler: https://github.com/cc65/cc65

MAD Assembler: https://github.com/tebe6502/Mad-Assembler

FujiNet Tools: https://github.com/FujiNetWIFI/fujinet-tools

FujiNet N: Handler: https://github.com/FujiNetWIFI/fujinet-nhandler

Altirra Emulator: https://www.virtualdub.org/altirra.html

The FNCTOOLS-U1MB-ROM.ATR disk image on apps.irata.online, which provides a ROM of SpartaDOS X for Ultimate 1MB users, that includes the FujiNet tools, has been updated to SpartaDOS 4.50, and is available on the apps.irata.online server. The UFLASH tool is also provided on the disk.

Three versions of the ROM are provided:

• 192K, which contains most of the tools.
• 256K, which contains all of the tools.
• 320K, which contains all of the tools, as well as their corresponding MAN pages.

You can use FujiNet to grab code directly to your Atari 8-bit computer, from GitHub, without any intermediate steps. It’s easy!

In addition to simulating existing Atari disk drives, FujiNet opens up a new possibility for Atari 8-bit users: The ability to use files stored on networked file systems directly, without needing to use a disk image file as an intermediary. The NOS is a self booting ATR which can be mounted into device slot 1 and booted in place of a typical DOS. While at version 0.7.1, it is not yet complete, it is already quite usable, thanks to the consistent efforts of Michael Sternberg, who has done a fantastic job, so far.

Booting NOS

A copy of NOS 0.7.1 can be found in the /Atari-8-bit/DOS/ folder of the apps.irata.online TNFS server, and mounted into device slot 1:

Once booted, you will be transferred to a cartridge, if present. The usual DOS statement in BASIC will transfer you to NOS, just like with DOS, if you do not have a cartridge installed, NOS will take control immediately, putting us on device N1 (of which there are 8 such N: devices that you can use independently):

Getting Help

Yes. NOS is a command line DOS, in the same spirit as DOS XL, XDOS, and SpartaDOS. Thankfully, there is a comprehensive HELP system that reads its data from GitHub, just type HELP:

Each of these subsections give not only references for the built-in commands, but are also comprehensive references for software developers:

This will allow all of us as a community to add documentation for things we can add and do with NOS.

Where is the D: device?

There is no D: device. Since NOS does not load a file system of its own into memory, and relies on the FujiNet to do filesystem things, there is no D: device driver, and thus no way to access either physical drives or disk images mounted in FujiNet device slots.

Instead of providing a disk drive oriented file system, NOS provides the same N: device that is provided by NDEV in the FujiNet Network tools that are a part of every DOS disk in the Atari_8-bit/DOS/ folder on apps.irata.online.

What you can access is any individual file, over any protocol that the N: device can use. This means protocols such as:

• TNFS
• FTP
• SMB (Windows File Sharing)
• HTTP/S (Web, including WEBDAV)
• SD (direct access to individual files on the SD card slot)

As a convenience, the N: device is also mapped to the D: device in HATABS, so that programs that only allow D: devicespecs can still work.

Let’s Load a Game!

In order to demonstrate how NOS works, and what makes it different from e.g. SpartaDOS, or MyDOS, or Atari DOS, let’s load a game directly from the Pigwa FTP server. To do this, we’ll iteratively change the directory using CD, and observing where we are with DIR. Once we get to our destination, we’ll load the game.

We’ll wind up here:

N1:CD "N:FTP://FTP.PIGWA.NET/stuff/collections/holmes cd/Holmes 2/Atari Archives/Antic Files/88/"

Of course, we can indeed type this all in at once, if we wanted, or we can change the path starting at the host name:

N1:CD N:FTP://FTP.PIGWA.NET/

We can see that the path has changed, by using the PWD (aka NPWD) command. This command can be issued to see the current path:

N1:PWD

And we can use the DIR command to get a directory at this location:

N1:DIR

We can continue to traverse the path above, by passing the next part of the path to the CD command, and looking at the resulting directory, which we can double check with the PWD command:

N1:CD stuff

N1:PWD

N1:DIR

You don’t have to put each path component individually, you can concatenate path components together, seperated by a slash:

N1:CD “collections/holmes cd/Holmes 2/”

Note: Since the path contained a space, double-quotes are used to indicate that it’s all part of the path, and are only needed if the desired path contains any spaces.

You can see the result with the PWD command:

Also note: Many modern file systems are case-sensitive, and you must type names exactly as the system expects them.

Once we get to the target path:

N:TNFS://FTP.PIGWA.NET/stuff/collections/holmes cd/Holmes 2/Atari Archives/Antic Files/88/

We can look for specific files beginning with F:

N:DIR F*.*

Let’s load FROG.EXE:

N1:LOAD FROG.EXE

There we go. A game that was loaded directly from an FTP server, onto the Atari, courtesy of the FujiNet doing all the heavy lifting behind the scenes.

N: Works Everywhere

As a bonus, re-boot your Atari computer with BASIC inserted or enabled. If your FujiNet was powered off during this process, go back to the same path:

N:TNFS://FTP.PIGWA.NET/stuff/collections/holmes cd/Holmes 2/Atari Archives/Antic Files/88/

And from BASIC type:

READY
RUN"N:SUNSET.BAS"

Cool, huh? 🙂

N1: N2: N3: …

As has been alluded to before, there are 8 network devices defined in the FujiNet firmware, and NOS can use them all.

Note: N8: is used by NOS to handle features such as HELP.

You can change network devices in NOS by typing N1: to N8: at the prompt.

N1:N2:

The prompt will change to indicate the new default device:

N2:

This means each N: device can point to a different path:

In this case, N2: points to a local TNFS file server that I use for software development.

And I can easily copy files from one N: device to another, such as transferring the FROG.EXE we loaded earlier from FTP in N1:, onto my local TNFS file server, now in N2:

N2:COPY N1:FROG.EXE,N2:FROG.EXE

File management tasks such as renaming, deleting, as well as making and removing directories are also possible:

N2:REN FROG.EXE,TOAD.EXE

N2:MKDIR WORK

N2:DEL kantiks.xex

Automatic Boot Script

Any text file can be assigned as an automatic boot script using the AUTORUN command, giving the full path to the script:

N1:AUTORUN N:TNFS://TMA-2/AUTO.TXT

To accomplish this, NOS sets an AppKey on your FuijNet, which NOS will read when booted. This feature is useful for setting up a consistent environment with the N: devices pointed to your preferred network locations.

The Road to 1.0

While work on NOS is progressing, part of this post is a call to bring interested people in to help work on NOS and polish it up, and make it better. There are still many weird little bugs that can crop up during use, so we ask that users be patient, and if developers can help, feel free to grab a copy of the source code, and improve upon it.

The source code can be fetched from GitHub in the fujinet-nhandler repository:

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

And NOS is written in Assembler, using the mads assembler. The resulting build from the makefile generates the bootable ATR disk image automatically.

Thank you all for reading, I hope NOS will at the very least inspire new ways to think about how FujiNet can access networked files, unencumbered by legacy disk drive file systems, and hopefully maybe it can inspire some much needed improvements or totally new ideas in this space. -Thom

If you are not already familiar, YAIL is Yet Another Image Loader for Atari 8 Bit computers that works with FujiNet. Server software running on this website automatically converts and feeds images to the YAIL app on the Atari. All you need to do is set your graphics mode and enter a search term for the server to stream images from the internet to your Atari.

The YAIL app and YEET server were written by Brad Colbert and the source code is available on Github. YAIL can be mounted from the fujinet.online TNFS server located at ATARI/FujiNet-Apps/YAIL.XEX. For users with a VBXE upgraded Atari, you can set the graphics mode to 20 in YAIL (command: gfx 20) which enables the high resolution image streaming. Below is a demo video of the app in action.

A work in progress User’s Guide and Programming Reference for ATARI based FujiNets is being written. The effort is led by Thomas Cherryhomes. The goal is to provide both a comprehensive user’s and a programmer’s guide.

You can download the most recent render here: https://github.com/FujiNetWIFI/fujinet-manuals/releases/download/fujinet-atari-users-guide-0.0.2/fujinet_for_atari_users.pdf

The source material is being written in XML using the DocBook 5.1 grammar, which is well suited for writing technical documentation. You can get it here on GitHub: https://github.com/FujiNetWIFI/fujinet-manuals

While the User’s Guide revolves around showing new and experienced ATARI users what they can do with their FujiNet, the Programmers guide gives both a reference of how to control the FujiNet from languages such as Atari BASIC, FastBasic, ACTION!, C, and Assembler, but give a consistent set of examples that can be used as a “Rosetta Stone” for each, namely NETCAT, a terminal emulator, and MASTODON, a program which fetches the latest post from a Mastodon server and displays it.

As with everything in FujiNet land, anyone can help! If you want to participate in making this user’s guide, feel free to contact us, leave us a comment below, or join us on Discord!

Work continues on the FujiNet Game Lobby and support for the Commodore 64 platform has begun. The Atari 8 platform gets an updated version of the FujiNet enabled Reversi BASIC game client and is now available to play from the Lobby. We are working on a new chat server for the Lobby so people can get acquainted before starting a new game.

Check out Andy’s post at atariorbit.org for more info and pictures of the new game clients and lobby