Jump to content
tschak909

#FujiNet - a WIP SIO Network Adapter for the Atari 8-bit

Recommended Posts

3 minutes ago, Fred Olivas said:

TNFS GitHub software for Windows7 32 bit doesn't work. My PC refuses to run it even as Administrator. 

it's a 64 bit build.

-Thom

Share this post


Link to post
Share on other sites

#Atari8bit #ESP32 #FujiNet - Thanks to @stmiddleditch's excellent libtelnet, TELNET connections are now supported in the R: device, shown here connecting to a Linux host.


 

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites
20 minutes ago, 8bitguy1 said:

So is this a new R: device we'd need to get from somewhere? 

We will do a new build soon (probably later today, we just did one yesterday), once we do that...

 

Grab the fujinet flasher from http://fujinet.online/

 

It will grab the latest build of the software and flash the device.

 

-Thom

  • Like 1

Share this post


Link to post
Share on other sites

#Atari8bit #FujiNet In the N: re-write, there is an N: Protocol adapter, which works exactly like the counterpart in the R: device.

 

  • Like 3

Share this post


Link to post
Share on other sites

Some of you have been asking me, “Why is there both an R: and an N: device, when you have to implement the same protocol twice?” There is a reason, for that:

The R: and N: devices work differently, addressing two different needs, which, while there is some overlap, they have different strengths and weaknesses.

The R: device represents the Wi-Fi MODEM in #FujiNet. It is literally a fusion of the Atari 850 Interface, with a Hayes command subset Wi-Fi MODEM. It is meant for compatibility with existing Atari communications programs such as AMODEM, BobTerm, ICE-T, FlickerTerm, and the like. You can use it to “dial” into existing text driven hosts that run over TCP sockets.

But R: also has the very same limitations as an Atari 850: By default, it runs in BLOCK WRITE mode, and once you set it to CONCURRENT mode to get both input and output, it takes over the bus. The R: handler must close the channel, before other devices can safely use the bus again.

The R: device is also very much constrained by the architectural constraints of a traditional MODEM, that is, only able to handle a single connection, at a time. Even with multiple R: ports, the limitation of CONCURRENT mode only allows for one of these ports to be active on the SIO bus at one time.

The R: device, as it is, also has no concept of specifying protocols or paths, limiting its ability to access network filesystems and the like.

But it works well as a MODEM, and is meant to work well with what’s existing to act as a MODEM, and the large input and output buffers mitigate the need for hardware flow control, which is, admittedly very difficult on an Atari 850, as you can’t manipulate the flow control signals in concurrent mode.

The N: device, on the other hand, was designed from the get-go, to bring the TCP/IP network to the Atari. Unlike the R: device, it maps SIO transactions to atomic network operations, each READ and WRITE contains a length, which essentially specifies a series of bytes to read or write as a block of data to and from the Atari. Since I/O on the N: device is framed within the context of SIO transactions, it means that you can use N: while also reading and writing to other devices.

The N: devicespec provides four distinct deivices, and the concept of protocol, host, path, and query, so that a wide variety of network protocols (currently TCP, UDP, HTTP, FTP, TNFS, and TELNET, with more coming such as SSH, SMB, NFS, etc.) can be read and written to using the same existing I/O idioms as other Atari files. This means, you can transparently do local to network, network to local, or even network to network reads and writes, transparently.

In addition, the N: device utilizes the PROCEED and INTERRUPT lines, heretofore rarely utilized, to notify the Atari when the #FujiNet has something of interest, thus greatly minimizing status polling.

All of this ultimately means, that while there are common protocols such as TCP, TELNET, and SSH in the MODEM side of things, and while it is possible for example to do an HTTP GET inside the MODEM, the two devices are two very different animals, with completely different behaviors and uses. They exist to bring the wider TCP/IP network to the Atari, in both a very compatible, and a very new way. -Thom

  • Like 4
  • Thanks 3

Share this post


Link to post
Share on other sites

I'm having trouble with connecting to BBS's. I connect to Alcatraz using Bobterm. It shows connect 9600. Then it asks for translation. I press enter. The screen begins to paint ATASCII, but hangs. I've seen similar results connecting with ATASCII on other BBS's. ASCII appears to work fine on Alcatraz and other BBS's. My Fujinet is running the 11/14/2020 firmware update.

Share this post


Link to post
Share on other sites
29 minutes ago, gs80065xe said:

I'm having trouble with connecting to BBS's. I connect to Alcatraz using Bobterm. It shows connect 9600. Then it asks for translation. I press enter. The screen begins to paint ATASCII, but hangs. I've seen similar results connecting with ATASCII on other BBS's. ASCII appears to work fine on Alcatraz and other BBS's. My Fujinet is running the 11/14/2020 firmware update.

This is a known issue being worked on.

https://github.com/FujiNetWIFI/fujinet-platformio/issues/371

Share this post


Link to post
Share on other sites
15 minutes ago, tschak909 said:

I'm working on something... :)

Ooooh...  Thank you.  That's been a *big* want for me (and, I'm sure, others).

Share this post


Link to post
Share on other sites

TNFSD builds 2020.1115 and later now have a 6 hour session time-out. This means that if you leave something mounted overnight, you'll probably find it not booting the next morning. 

 

We had to do this to deal with the fact that TNFS connections were exhausting the session ID tables to the point where after a few days of heavy public use, it would stop accepting connections.

 

While this solves the session leak problem on our servers, we do need to modify the firmware code so that if for some reason, an INVALID SESSION ID is returned, then we should attempt to re-mount the host (and/or device slot).

 

If anyone wants to help out in the firmware potentially addressing and correcting this problem, reach out, we could use all the help we can get.

 

Ticket URL here:
https://github.com/FujiNetWIFI/fujinet-platformio/issues/399

 

Share this post


Link to post
Share on other sites
36 minutes ago, tschak909 said:

TNFSD builds 2020.1115 and later now have a 6 hour session time-out. This means that if you leave something mounted overnight, you'll probably find it not booting the next morning. 

 

We had to do this to deal with the fact that TNFS connections were exhausting the session ID tables to the point where after a few days of heavy public use, it would stop accepting connections.

 

While this solves the session leak problem on our servers, we do need to modify the firmware code so that if for some reason, an INVALID SESSION ID is returned, then we should attempt to re-mount the host (and/or device slot).

 

If anyone wants to help out in the firmware potentially addressing and correcting this problem, reach out, we could use all the help we can get.

 

Ticket URL here:
https://github.com/FujiNetWIFI/fujinet-platformio/issues/399

 

If I want to update my tnfs server running on my Raspberry Pi (and I can't find the page that I used with step by step directions), can I just download the rPI version of the file from here: https://fujinet.online/download/ and replace the 'tnfsd' file in my /usr/local/sbin directory on the pi with this downloaded file? (renaming it from "tnfsd.armhf" to "tnfsd")?

 

Thanks.

Share this post


Link to post
Share on other sites
1 minute ago, tsom said:

If I want to update my tnfs server running on my Raspberry Pi (and I can't find the page that I used with step by step directions), can I just download the rPI version of the file from here: https://fujinet.online/download/ and replace the 'tnfsd' file in my /usr/local/sbin directory on the pi with this downloaded file? (renaming it from "tnfsd.armhf" to "tnfsd")?

 

Thanks.

Yes.

-Thom

Share this post


Link to post
Share on other sites

Oh dear, I installed the latest tnfs, but when I try to access it from my FujiNet, it errors with no directories listed and an error "ERROR OPENING DIRECTORY".

 

This is the error that's in /var/log/syslog on the rPI:
 

```

Nov 18 16:35:55 raspberrypi systemd[1]: Started TNFS Server.
Nov 18 16:35:55 raspberrypi tnfsd[1350]: Starting tnfsd version 20.1115.2 using root directory "/tnfs"
Nov 18 16:35:59 raspberrypi systemd[1]: Stopping TNFS Server...
Nov 18 16:35:59 raspberrypi systemd[1]: tnfsd.service: Main process exited, code=killed, status=15/TERM
Nov 18 16:35:59 raspberrypi systemd[1]: tnfsd.service: Succeeded.
Nov 18 16:35:59 raspberrypi systemd[1]: Stopped TNFS Server.
Nov 18 16:35:59 raspberrypi systemd[1]: Started TNFS Server.
Nov 18 16:35:59 raspberrypi tnfsd[1353]: Starting tnfsd version 20.1115.2 using root directory "/tnfs"
Nov 18 16:36:15 raspberrypi tnfsd[1353]: 192.168.7.95 s=00 c=00 q=00 | REQUEST cmd=0x00 TNFS_MOUNT
Nov 18 16:36:15 raspberrypi tnfsd[1353]: 192.168.7.95 s=00 c=00 q=00 | TNFS_MOUNT
Nov 18 16:36:15 raspberrypi tnfsd[1353]: Looking for existing sessions with IP 192.168.7.95
Nov 18 16:36:15 raspberrypi tnfsd[1353]: Allocating new session for 0x00
Nov 18 16:36:15 raspberrypi tnfsd[1353]: Allocated new session for 0x4567
Nov 18 16:36:15 raspberrypi tnfsd[1353]: validate_dir: Path='/tnfs/'
Nov 18 16:36:15 raspberrypi tnfsd[1353]: validate_dir: Directory OK
Nov 18 16:36:15 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=00 q=00 | Mounted / OK, SID=4567
Nov 18 16:36:15 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=01 | REQUEST cmd=0x17 TNFS_OPENDIRX
Nov 18 16:36:15 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=01 | opendirx: diropt=0x00, sortopt=0x00, max=0x0000, pat="", path="/"
Nov 18 16:36:15 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=02 | REQUEST cmd=0x17 TNFS_OPENDIRX
Nov 18 16:36:15 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=02 | opendirx: diropt=0x00, sortopt=0x00, max=0x0000, pat="", path="/"
Nov 18 16:36:15 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=03 | REQUEST cmd=0x17 TNFS_OPENDIRX
Nov 18 16:36:15 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=03 | opendirx: diropt=0x00, sortopt=0x00, max=0x0000, pat="", path="/"
Nov 18 16:36:16 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=04 | REQUEST cmd=0x17 TNFS_OPENDIRX
Nov 18 16:36:16 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=04 | opendirx: diropt=0x00, sortopt=0x00, max=0x0000, pat="", path="/"
Nov 18 16:36:16 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=05 | REQUEST cmd=0x17 TNFS_OPENDIRX
Nov 18 16:36:16 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=05 | opendirx: diropt=0x00, sortopt=0x00, max=0x0000, pat="", path="/"
Nov 18 16:36:16 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=06 | REQUEST cmd=0x17 TNFS_OPENDIRX
Nov 18 16:36:16 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=06 | opendirx: diropt=0x00, sortopt=0x00, max=0x0000, pat="", path="/"
Nov 18 16:36:16 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=07 | REQUEST cmd=0x17 TNFS_OPENDIRX
Nov 18 16:36:16 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=07 | opendirx: diropt=0x00, sortopt=0x00, max=0x0000, pat="", path="/"
Nov 18 16:36:16 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=08 | REQUEST cmd=0x17 TNFS_OPENDIRX
Nov 18 16:36:16 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=08 | opendirx: diropt=0x00, sortopt=0x00, max=0x0000, pat="", path="/"
Nov 18 16:36:16 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=09 | REQUEST cmd=0x17 TNFS_OPENDIRX
Nov 18 16:36:16 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=09 | opendirx: diropt=0x00, sortopt=0x00, max=0x0000, pat="", path="/"
Nov 18 16:36:17 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=0a | REQUEST cmd=0x17 TNFS_OPENDIRX
Nov 18 16:36:17 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=0a | opendirx: diropt=0x00, sortopt=0x00, max=0x0000, pat="", path="/"
Nov 18 16:36:56 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=0b | REQUEST cmd=0x17 TNFS_OPENDIRX
Nov 18 16:36:56 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=0b | opendirx: diropt=0x00, sortopt=0x00, max=0x0000, pat="", path="/"
Nov 18 16:36:57 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=0c | REQUEST cmd=0x17 TNFS_OPENDIRX
Nov 18 16:36:57 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=0c | opendirx: diropt=0x00, sortopt=0x00, max=0x0000, pat="", path="/"
Nov 18 16:36:57 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=0d | REQUEST cmd=0x17 TNFS_OPENDIRX
Nov 18 16:36:57 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=0d | opendirx: diropt=0x00, sortopt=0x00, max=0x0000, pat="", path="/"
Nov 18 16:36:57 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=0e | REQUEST cmd=0x17 TNFS_OPENDIRX
Nov 18 16:36:57 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=0e | opendirx: diropt=0x00, sortopt=0x00, max=0x0000, pat="", path="/"
Nov 18 16:36:57 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=0f | REQUEST cmd=0x17 TNFS_OPENDIRX
Nov 18 16:36:57 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=0f | opendirx: diropt=0x00, sortopt=0x00, max=0x0000, pat="", path="/"
Nov 18 16:36:57 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=10 | REQUEST cmd=0x17 TNFS_OPENDIRX
Nov 18 16:36:57 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=10 | opendirx: diropt=0x00, sortopt=0x00, max=0x0000, pat="", path="/"
Nov 18 16:36:57 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=11 | REQUEST cmd=0x17 TNFS_OPENDIRX
Nov 18 16:36:57 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=11 | opendirx: diropt=0x00, sortopt=0x00, max=0x0000, pat="", path="/"
Nov 18 16:36:58 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=12 | REQUEST cmd=0x17 TNFS_OPENDIRX
Nov 18 16:36:58 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=12 | opendirx: diropt=0x00, sortopt=0x00, max=0x0000, pat="", path="/"
Nov 18 16:36:58 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=13 | REQUEST cmd=0x17 TNFS_OPENDIRX
Nov 18 16:36:58 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=13 | opendirx: diropt=0x00, sortopt=0x00, max=0x0000, pat="", path="/"
Nov 18 16:36:58 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=14 | REQUEST cmd=0x17 TNFS_OPENDIRX
Nov 18 16:36:58 raspberrypi tnfsd[1353]: 192.168.7.95 s=4567 c=17 q=14 | opendirx: diropt=0x00, sortopt=0x00, max=0x0000, pat="", path="/"

```

 

Going to try re-downloading and re-installing. (Everything was working, so I know the configuration on the rPi is Ok.)

Share this post


Link to post
Share on other sites
18 minutes ago, orpheuswaking said:

without scrolling back through the pages of information, has anyone used a Fujinet with an Eclaire?

Yes. There is at least one user which has one, and we found an issue with its PROCEED and INTERRUPT lines, and worked with the eclaire developers to fix it. The device works just fine with it, now.

 

-Thom

 

Share this post


Link to post
Share on other sites
5 hours ago, tschak909 said:

Yes. There is at least one user which has one, and we found an issue with its PROCEED and INTERRUPT lines, and worked with the eclaire developers to fix it. The device works just fine with it, now.

 

-Thom

 

Excellent, good to know! I'll make sure to update both my eclaires before I get my Fujinet.

Share this post


Link to post
Share on other sites
3 hours ago, gs80065xe said:

Where can I find doc on the N device's aux1 and aux2 options for the Open and XIO commands as wells as the command options for XIO?

 

Thanks.

There is some documentation about the N: device on the github wiki. If what you're looking for isn't there, @tschak909 will have to answer.

Share this post


Link to post
Share on other sites
6 hours ago, gs80065xe said:

Where can I find doc on the N device's aux1 and aux2 options for the Open and XIO commands as wells as the command options for XIO?

 

Thanks.

Yup, the wiki shows what is possible. 

 

The CIO handler itself is still under heavy work (and I am actually in the process of completely rewriting the SIO part of N: in the network-rewrite branch of fujinet-platformio), but you can test it by loading n-handler.atr from atari-apps.irata.online/Networking/n-handler/n-handler.atr over TNFS.

 

You can also use the network adapter directly over SIO.

 

-Thom

 

Share this post


Link to post
Share on other sites
21 hours ago, tschak909 said:

Yup, the wiki shows what is possible. 

 

The CIO handler itself is still under heavy work (and I am actually in the process of completely rewriting the SIO part of N: in the network-rewrite branch of fujinet-platformio), but you can test it by loading n-handler.atr from atari-apps.irata.online/Networking/n-handler/n-handler.atr over TNFS.

 

You can also use the network adapter directly over SIO.

 

-Thom

 

 

 What is the aux2 option #3 in the open command? The wiki only lists 0 and 1. Your Dumbterm program uses it.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...