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

[Alfred]

35 minutes ago, tschak909 said:

The R: commands map exactly to the Atari 850's serial interface. The exception is the listen command that can be sent, which is shown here:

https://github.com/FujiNetWIFI/fujinet-config-tools/blob/master/rlisten/src/main.c#L29

 

There is no documentation for P: as it is literally just the already known documented bits.

 

-Thom

 

Ok, but how does Listen work on the R: ? Even for N: all it it says is that it listens, but nothing as to how you know when there's a connection pending. Does the N: XIO 41 also apply to the R: device ? Or does it have some other way of handling the Accept ? 

 

nm, I see the CIO status command sets bits for connection pending.

 

I don't see XIO 13 for N: documented apart from the example for retrieving your ip address.

Edited March 15, 2022 by Alfred

[tschak909]

11 minutes ago, Alfred said:

Ok, but how does Listen work on the R: ? Even for N: all it it says is that it listens, but nothing as to how you know when there's a connection pending. Does the N: XIO 41 also apply to the R: device ? Or does it have some other way of handling the Accept ? 

 

nm, I see the CIO status command sets bits for connection pending.

If listen is enabled, then the virtual modem will send RING result codes for a pending connection. ATA accepts.

 

The R: and N: devices are completely different entities, with different goals and designs.

 

-Thom

Edited March 15, 2022 by tschak909

[Alfred]

In the original N: handler  VProceed was enabled during the CIO Open call and left enabled while the channel was active. I see in NDEV.s you now enable and disable it within specific calls, like GET. Any particular reason for the change ? Can the interrupt be left enabled all the time or there was an issue that made you change it.

[tschak909]

44 minutes ago, Alfred said:

In the original N: handler  VProceed was enabled during the CIO Open call and left enabled while the channel was active. I see in NDEV.s you now enable and disable it within specific calls, like GET. Any particular reason for the change ? Can the interrupt be left enabled all the time or there was an issue that made you change it.

If I remember correctly, there was a race condition that was fixed by doing this.

-Thom

[Alfred]

 

51 minutes ago, tschak909 said:

If I remember correctly, there was a race condition that was fixed by doing this.

-Thom

Probably over the trip flag. Since the ESP doesn’t know what’s happening on the Atari side, what makes it trigger the Proceed interrupt ? Any data for any open N: channel ? Something else ?

[tschak909]

10 hours ago, Alfred said:

 

Probably over the trip flag. Since the ESP doesn’t know what’s happening on the Atari side, what makes it trigger the Proceed interrupt ? Any data for any open N: channel ? Something else ?

Yes.

 

An interrupt is also asserted on open:

https://github.com/FujiNetWIFI/fujinet-platformio/blob/master/lib/device/sio/network.cpp#L134

 

and Interrupt is also asserted when bytes are waiting or the connection flag is zero.

https://github.com/FujiNetWIFI/fujinet-platformio/blob/master/lib/device/sio/network.cpp#L735

 

There is an interruptEnable flag that can be set, this was used in earlier iterations to prevent recursive status calls from causing a race condition, but it isn't really used anymore.

 

To note, there is also a rate limiter on the interrupt, which I discovered was needed because triggering an interrupt transition too fast slows the Atari down into unusable territory. 

 

https://github.com/FujiNetWIFI/fujinet-platformio/blob/master/lib/device/sio/network.cpp#L863

https://github.com/FujiNetWIFI/fujinet-platformio/blob/master/lib/device/sio/network.cpp#L35

https://github.com/FujiNetWIFI/fujinet-platformio/blob/master/lib/device/sio/network.cpp#L1000

 

-Thom

[Alfred]

Has anyone ported the TNFS server code to a simple one that would run on a Atari ? Thinking of old 800’s with Axlon memory could find new purpose.

 

[tschak909]

52 minutes ago, Alfred said:

Has anyone ported the TNFS server code to a simple one that would run on a Atari ? Thinking of old 800’s with Axlon memory could find new purpose.

 

The code itself could possibly be compiled as-is using CC65 into an executable. The network I/O functions would need to be wrapped or replaced (mostly BSD socket calls)

 

The other thing is that tnfsd could be compiled as is to run on the FujiNet as well, providing a way for a fujinet to provide tnfs services to other fujinets.

 

-Thom

 

[Alfred]

The protocol link http://spectrum.alioth.net/svn/filedetails.php?repname=Spectranet&path=%2Ftrunk%2Ftnfs%2Ftnfs-protocol.txt  on the first page is dead. Looks like a good link is

https://github.com/spectrumero/spectranet/blob/master/tnfs/tnfs-protocol.txt

[chad5200]

On 7/16/2020 at 12:19 PM, tschak909 said:

#Atari8bit #FujiNet shown here running Carina II BBS on the R: device. Since it is a large BBS, it is shown here being copied into ram disk before use. Also shown here are two complete call sessions, showing that it does indeed work very well.

 

 

Hi @tschak909

 

Can you share your copy of Carina II's WAITCALL program that you got working as seen in that video?  It would be greatly appreciated!  Or better yet, share the entire Carina ATR files you were working with... even if it's still a WIP.  A friend and I are looking into running a Carina BBS on FujiNet but are having issues with the WAITCALL portion of the BBS.  Carina is responding to the Telnet connection, but then the FujiNet just keeps pumping RING(ctrl-M) over and over with no end.  I suspect the FujiNet is not processing the CONNECT that would follow so forever pumps out RING(ctrl-M).

 

Thank you,

Chad

 

 

 

[tschak909]

13 minutes ago, chad5200 said:

 

Hi @tschak909

 

Can you share your copy of Carina II's WAITCALL program that you got working as seen in that video?  It would be greatly appreciated!  Or better yet, share the entire Carina ATR files you were working with... even if it's still a WIP.  A friend and I are looking into running a Carina BBS on FujiNet but are having issues with the WAITCALL portion of the BBS.  Carina is responding to the Telnet connection, but then the FujiNet just keeps pumping RING(ctrl-M) over and over with no end.  I suspect the FujiNet is not processing the CONNECT that would follow so forever pumps out RING(ctrl-M).

 

Thank you,

Chad

 

 

 

I did a quick search, and haven't been able to find it.

-Thom

[chad5200]

1 hour ago, tschak909 said:

I did a quick search, and haven't been able to find it.

-Thom

Darn.

 

Any thoughts around the process where when a telnet session is started, the FujiNet starts sending RING(ctrl-m) constantly?  I assume this is where the FujiNet is looking for an ATA or a CONNECT message as part of the handshake. You can watch the log on process run on Carina II and when it gets to any prompt (logon name, phone number, password), you can see it inputting the RING that it is looping (until reset or power cycle).

 

[_The Doctor__]

1 hour ago, chad5200 said:

 

Hi @tschak909

 

Can you share your copy of Carina II's WAITCALL program that you got working as seen in that video?  It would be greatly appreciated!  Or better yet, share the entire Carina ATR files you were working with... even if it's still a WIP.  A friend and I are looking into running a Carina BBS on FujiNet but are having issues with the WAITCALL portion of the BBS.  Carina is responding to the Telnet connection, but then the FujiNet just keeps pumping RING(ctrl-M) over and over with no end.  I suspect the FujiNet is not processing the CONNECT that would follow so forever pumps out RING(ctrl-M).

 

Thank you,

Chad

 

 

 

dunno maybe this?car_bbs_fuji.arc

always hard to find anything these days...

[chad5200]

4 hours ago, _The Doctor__ said:

dunno maybe this?car_bbs_fuji.arc

always hard to find anything these days...

This helps immensely. Thank you!

 

[YSG2020]

Just received my Fujinet. Undoubtedly THE be all end all  ‘killer app’ for the A8s. Phenomenal. Thank-you to the genius team and contributors who created and are still growing this quality masterpiece.  The possibilities are endless!

[kenp]

Been experimenting with my new FujiNet and have a question.  About the most standard SD card these days is 32G.  That would likely be enough room for every piece of Atari software ever written and much more.  But how many files can the FujiNet handle on an SD card before its little mind gives up and cannot keep track of them?

[mozzwald]

11 hours ago, kenp said:

But how many files can the FujiNet handle on an SD card before its little mind gives up and cannot keep track of them?

The google says:

Quote

The maximum number of files within a directory of a FAT file system is 65,536 if all files have short filenames (8.3 format).

 

[kenp]

1 hour ago, mozzwald said:

The google says:

 

That's in the FAT file system.  In an exFAT file system which would be used to access all of a 32Gb SD card the number is significantly higher, 2,796,202 per directory.  But the question was about how many files can the FujiNet device keep track of.  Is there an upper limit to how many files that the FujiNet device can keep track of before it starts to get confused?  Is there a maximum number of files in any individual directory that will confuse it?  I ask because I'm going to be transferring some several hundred floppies worth of stuff to an SD card or cards if there are limits.  Much of that is going to be duplicates, I'm sure, and I'll be looking for tools to look inside atr files to examine contents within Linux or Windows, sort of like looking into or decompressing a ZIP file.

[+DjayBee]

10 minutes ago, kenp said:

In an exFAT file system which would be used to access all of a 32Gb SD card the number is significantly higher, 2,796,202 per directory.

This is a quite academic approach since FujiNet can only handle FAT32 filesystems.

[tschak909]

This is something that somebody could work out and contribute the resulting data, as we don't have it.

 

-Thom

[+x=usr(1536)]

29 minutes ago, kenp said:

I ask because I'm going to be transferring some several hundred floppies worth of stuff to an SD card or cards if there are limits.

You may have already considered this, but I would strongly suggest against transferring directly to SD card.  Best bet is to land the files on an SSD or spinning disk, then copy them off to SD from there.  There are just too many QC issues with even reputable manufacturers' SD cards to risk using them as primary storage.

29 minutes ago, kenp said:

Much of that is going to be duplicates, I'm sure, and I'll be looking for tools to look inside atr files to examine contents within Linux or Windows, sort of like looking into or decompressing a ZIP file.

This is something that is being worked on.  See the following thread for details (and it does need some updating, which I hope to take care of next week).

 

[kenp]

1 hour ago, DjayBee said:

This is a quite academic approach since FujiNet can only handle FAT32 filesystems.

TIL something.  And I'll look into the transfer to a HDD again.  I ordered both the FujiNet and a cable to build a SIO2USB adapter.  Surprised that the FujiNet got here first.  Still waiting on the cable.

[_The Doctor__]

SIO2PC USB cable...

this is a SIO2USB

http://www.realdos.net/sio2usb.html

 

check out abbuc,

making mathy proud

Edited January 28, 2023 by _The Doctor__

[kenp]

4 hours ago, _The Doctor__ said:

SIO2PC USB cable...

this is a SIO2USB

http://www.realdos.net/sio2usb.html

 

check out abbuc,

making mathy proud

Nope, not that.  I looked back and what I'm getting the cable for is a SIO2PC but it uses a USB cable to plug into the PC.  That's why I thought of it as a SIO2USB.

And the question of which FAT on what SD cards looks to be more complex that I thought.  I found several articles outside of the Atari world about using FAT32 on 64G or even 128G SD cards.  There's a utility but they don't say how they trick the FAT32 system into handling the extra space.  The 64G card I have looks to be considered as FAT in one Linux utility but FAT32 in a different one.  BUT even FAT32 properly shouldn't be handling a 64G SD card.  There's something fishy going on here and I doubt I'm going spend the time to get to the bottom of it.  I'll just make sure I use 32G or smaller and not play around with funny tricks.  I found a couple of 2GB and 8GB microSD cards so they'll have more than enough space but even at that how many files can a FujiNet keep track of in its memory at one time?

 

This is going to be quite the rig if I can get all the bits working together, Atari 130XE RAM upgraded to 320K, two 360K 5.25" floppies, two 8" floppies (and I really don't remember what they formatted out to), the FujiNet and the SIO2PC connection and all centred on one wee little 8 bit 6502 CPU wondering where in the universe it's landed.

[_The Doctor__]

Your 8 inch drives could be 720k or near double that, but on the atr8000 with the Atari, usually 720K depends on what tricks you were up to bitd.