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

[tschak909]

#FujiNet code is here in GitHub:

https://github.com/FujiNetWIFI

 

Patreon page here:

https://www.patreon.com/user?u=8255002 (funds here are used to take care of operational expenses such as shipping boards back and forth.)

 

Website Describing the Production Firmware is Here:

http://fujinet.online/

 

What is #FujiNet?

#FujiNet (formerly known at #AtariWiFi) is a network adapter that attaches to the SIO (Peripheral) port of an Atari 8-bit system. It currently (as of Rev3) consists of an NodeMCU 1.0 device attached to an interface board which electrically attaches the NodeMCU to the SIO bus and provides the needed SIO connectors.

 

What does it provide?

#FujiNet is planned to provide the following functionality:

• "D:" Emulation, to virtually mount, read, and write ATR disk images over a protocol borrowed from the Spectranet community called TNFS.
• "R:" Emulation, via Type 1 POLL handler, to provide a virtual Wi-Fi modem for use with existing Communications programs such as Ice-T, BobTerm, AMODEM, and PLATOTERM.
• "N:" A new device for establishing TCP and UDP communication with other hosts, as well as controlling the adapter (setting configuration, mounting images, etc.)
• More functionality to be available by future over-the-air (OTA) updates to the firmware, such as IPP printing.

 

Who can use it?

Hopefully, everyone! The "D:" emulation provides an immediate out-of-the-box use case, to mount disks over the network, whatever network that may be, such as your local one, or an internet host. The "R:" handler will allow anybody who wants to call internet BBSes and services like IRATA.ONLINE to immediately use the device, and the "N:" device will allow whole new programs to be written which can natively handle network traffic!

 

When will it be available?

#FujiNet development (as of November 2019) is proceeding rapidly. Since the firmware is being written in Arduino, the firmware functionality is being sketched out and tested in very rapid cycles. I will be optimistic and say that by this time next year, we will have something well polished and usable.

 

How much will it cost?

Too early to tell, but, given that it is based on NodeMCU hardware, and given that the interface board is wholly populated with passive components, we (those of us working on the hardware side) expect the cost to be inexpensive, comparable to an SDrive-MAX.

 

Still interested? More info:

Wasn't this called #AtariWiFi? 

Yes, it was. In response to the name change, I have asked that the original thread be locked, previous updates, and demo videos can be found here:

 

Where is the documentation?

The documentation is being stored here in Google Docs: https://docs.google.com/document/d/1dIKFuxmX9O9cckz0HLN_7GmDKrYcbHury7Mgoomzqtg/edit?usp=sharing

 

How are Disk Images Shared for "D:" Emulation?

Disk images are shared using a file sharing protocol called TNFS. It was developed by Dylan Smith, the man who developed the Spectranet interface for the ZX Spectrum. It was understood that protocols like NFS and SMB were way too heavyweight to implement on 8-bit microcomputers, protocols like FTP and HTTP had way too much overhead, and protocols like TFTP and BOOTP were far too simple. So a nice medium was developed which maps the underlying filesystem in a simple, easy to implement protocol that can be used over UDP or TCP that uses a single connection.

 

Where can I get a copy of tnfsd?

The TNFSD server can be downloaded here: http://spectrum.alioth.net/doc/index.php/TNFS_server , it is available for Windows, Mac, and Linux. Source code is also available.

 

Is the TNFS Protocol Information available?

Absolutely, it is being used to implement the Arduino firmware: http://spectrum.alioth.net/svn/filedetails.php?repname=Spectranet&path=%2Ftrunk%2Ftnfs%2Ftnfs-protocol.txt

 

What Atari-specific information is being used to implement the firmware?

@phaeron's excellent Altirra Hardware Reference Manual is being used for the SIO side of things: http://www.virtualdub.org/downloads/Altirra Hardware Reference Manual.pdf

 

Who is working on this?

• @tschak909 working on Firmware
• @mozzwald working on Hardware and Firmware, did first pass of enclosure.
• @jeffpiep working on Hardware and Firmware
• @Mr Robot working on Hardware and enclosure
• @Bill Lange Helping test.
• @48kRAM helping test.
• @a8isa1 helping test with his own board/interface
• @ivop helping test with his own board/interface
• Joe Decuir will also have a board for testing, soon.

 

How is the hardware being implemented?

The Hardware is being implemented in two pieces, a NodeMCU 1.0 comprises the majority of the hardware, providing the microcontroller, the WiFi interface, and a USB UART and power connection. The other major piece of hardware is the interface board which consists of a series of passive components which not only connect the board to the SIO bus, but also sufficiently isolate it where needed.

 

This is a Rev2 board and its associated NodeMCU:

 

 

I see an SIO connector on there, how is that being managed?

@mozzwald and @Mr Robot have come up with an ingenious method of fabricating a connector that will not only fit the existing Molex sockets and cables, but also be easy to produce, which involves 3D printing a sandwich shell containing in-line pins that are soldered to a board-edge connector on the 'hole' side to provide a male pin for an SIO socket, or on the pin side to provide a female socket for the cabling, as seen here:

 

 

 

How is the firmware being implemented?

The firmware is being implemented as a series of small test programs. Each test program implements one piece of functionality (or a sub-functionality), and is used to determine where the problems may lie. Each test program typically involves one piece of Arduino firmware running on the device itself, and one piece of software running on the Atari. Each test is in its own directory in tests/ under the github repo. 

Does this mean there will be a lot of test programs?

Yes. A lot. I estimate roughly a couple hundred test programs may be written over the course of development. The advantage to this is that everyone will see functionality develop quickly, in very small increments.

What does DONE look like for 1.0?

• (D) emulation, read, write, mount disk images
• (R) emulation, CIO handler with baud rate/comms parameter configuration, and hardware handshaking for those that can use it via unused PROCEED line.
• (N) emulation, network scan and  connect, TCP connect, stream, and read/write packets, UDP read/write packets, incoming packets trip INTERRUPT line, UDP multicast
• OTA updates for future updates.

I want to help! What can I do?

• Contribute to this thread.
• Contact @tschak on twitter if you want to participate in the inner discussions (highly technical, very active.)
• Can you help write Arduino code?
• Can you help write example programs for the Atari in BASIC, Assembler, and/or C?
• Can you help improve the hardware?
• Can you help work out production logistics?
• And when we get hardware distributed, can you help test?

 

Excited? So are we.

 

-Thom

Edited August 9, 2020 by tschak909
Patreon mention.

[Faicuai]

Just F-amazing, by all means...

 

Finally, the last missing link on the chain is being put in place: ubiquitous, inexpensive network access for any Atari user with an SIO port... which means, basically everyone on this planet (!)

 

Bring it on!

[Bill Lange]

One issue that I ran into, and it took me a few days to figure out, is that the ESP8266 works with a 2.4Ghz wireless network, but doesn't seem to operate in 5Ghz. It will connect to 5Ghz, but it will not work, at least for me. 

 

If you have issues trying to connect to the tnfsd server, try using 2.4Ghz.

[manterola]

Amazing and super FAST job Thom. 

Thank you, all

[ivop]

That new SIO connector is incredible! Don't know how I missed it. Way better than before, struggling to get those genderless pins inside the holes and having to solder wires to them.

 

Also, very good summary by @tschak909. Note that the most up-to-date schematic is in the documentation linked from the first post.

 

I expect to receive a NodeMCU within a week and after that I hope I'll can contribute some code, test stuff, et cetera...

 

[a8isa1]

tschak909,  could you please re-post your BASIC version of your wifi scanner on github or alter the C version to re-scan at the press of a key.  I need to be able to try multiple times without cycling power or doing a RESET.

 

I don't think I can use the one posted in [EDIT] in your #atariwifi thread.  Line 290 has embedded ATASCII characters in the USR() parameters.

 

-SteveS

Edited November 20, 2019 by a8isa1

[Gavin1968]

Is there a gerber for the board or the design files so we can have some made for our own testing?

Thanks,

Gavin

 

[Mr Robot]

5 minutes ago, Gavin1968 said:

Is there a gerber for the board or the design files so we can have some made for our own testing?

Thanks,

Gavin

 

Not yet it's still WIP, we decided it wasn't a good idea to have too many potentially problematic boards out there.

 

The schematic is available if you want to make a board; if you know how, you're the sort of person who won't have a problem with probable problems.

 

[Mr Robot]

1 hour ago, ivop said:

That new SIO connector is incredible! Don't know how I missed it. Way better than before, struggling to get those genderless pins inside the holes and having to solder wires to them.

Note the picture shows the socket just turned around for the pins. We are actually using the right pins. I didn't have a model of it last night when I sent Thom that picture so I had to make do. 

 

Now I have the right model it looks correct. 

 

Note 2: the SIO connector and socket are currently very sharp, there will eventually be curves. 

[myriadcs]

Thanks for working on this, It's great idea!

 

After fighting with my set up for some time, finally I got something more or less working for initial testing.

 

I've tried tnfsBoot test and it was failing until I changed

https://github.com/tschak909/atariwifi/blob/master/tests/tnfsBoot/tnfsBoot.ino#L17

from GPIO2 to GPIO3. I see all debug messages and it seems be booting ESP8266 ok.

What difference does it make? Can it stay with 3?

 

When connected to Atari, I see a lot messages but computer is not booting up image,

I have following in Debug Log

 

Seek requested to offset: 16
Req packet: 67 45 2 25 0 0 10 0 0 0
Resp packet: 67 45 2 25 0
Successful.
Reading from File descriptor: 0
Req Packet: 67 45 3 21 0 80 0
Resp packet: 67 45 3 21 0 80 0 0 3 0 7 40 15 4C 14 7 3 3 0 7C 1A 1 BF 1 7D CB 7 AC E 7 F0 36 AD 12 7 85 43 8D 4 3 AD 13 7 85 44 8D 5 3 A
D 10 7 AC F 7 18 AE E 7 20 6C 7 30 17 AC 11 7 B1 43 29 3 48 C8 11 43 F0 E B1 43 A8 20 57 7 68 4C 2F 7 A9 C0 D0 1 68 A A8 60 18 A5 43 6D
11 7 8D 4 3 85 43 A5 44 69 0 8D 5 3 85 44 60 8D B 3 8C A 3 A9 52 A0 40 90 4 A9 50 A0 80 8D 2 3 8C
SIO READ OFFSET: 16 - 144
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
SIO CMD TIMEOUT: 0
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
SIO CMD TIMEOUT: 0
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 32
CMD DEVC: 31
CMD CMND: 3F
CMD DEVC: 31
CMD CMND: 3F
CMD DEVC: 31
CMD CMND: 3F
CMD DEVC: 31
CMD CMND: 3F
CMD DEVC: 31
CMD CMND: 3F
CMD DEVC: 31
CMD CMND: 3F
CMD DEVC: 31
CMD CMND: 3F
CMD DEVC: 31
CMD CMND: 3F
CMD DEVC: 31

 

What may be wrong with this? Am I missing something? Any reason why it's timing out?

 

[tschak909]

32? that would be trying to talk to D2: are you swapping drives around e.g. with the U1MB?

 

-Thom

[myriadcs]

Hmm, don't think so. In U1MB I have D1: Redirect: Disabled

 

using SIO2PC / aspeqt allows me to boot from D1

[tschak909]

1 hour ago, a8isa1 said:

tschak909,  could you please re-post your BASIC version of your wifi scanner on github or alter the C version to re-scan at the press of a key.  I need to be able to try multiple times without cycling power or doing a RESET.

 

I don't think I can use the one posted in [EDIT] in your #atariwifi thread.  Line 290 has embedded ATASCII characters in the USR() parameters.

 

-SteveS

The screenshot looks like:

 

This generates the equivalent assembler: PLA; JSR $E459; RTS

 

-Thom

[tschak909]

8 minutes ago, tschak909 said:

The screenshot looks like:

 

This generates the equivalent assembler: PLA; JSR $E459; RTS

 

-Thom

@a8isa1 I have also updated the C program to re-scan at a keypress.

-Thom

[Gavin1968]

1 hour ago, Mr Robot said:

The schematic is available if you want to make a board

Is this the most recent/current schematic? 

[tschak909]

1 minute ago, Gavin1968 said:

Is this the most recent/current schematic? 

Yup.

-Thom

[a8isa1]

44 minutes ago, tschak909 said:

@a8isa1 I have also updated the C program to re-scan at a keypress.

-Thom

Thanks. 

 

I seem to be getting garbage sectors but don't have a means to intercept them.   I either get lots of sectors in a steady stream but Antic goes crazy *OR* I get 2 I/O bleeps and then one weird sound and crash.  The weird sound resembles one bang on bongo drums.   (Yes, I know how crazy and pointless that description is but it is somewhat amusing to hear).

 

It seems somehow I simply am getting incorrect boot sectors.

 

My plan is to leave AUTORUN.ATR out of the build, run the wifi scanner from another source, plug in the #fujinet (homebrew) and see if it responds then.

 

Can my problems stem from my insistence to stick with GPIOs 1 and 3?  [EDIt] I do disable Serial.Swap() in the source.

 

-SteveS

Edited November 20, 2019 by a8isa1

[tschak909]

That would be a @mozzwald question.

-Thom

[mozzwald]

6 minutes ago, a8isa1 said:

Can my problems stem from my insistence to stick with GPIOs 1 and 3?  [EDIt] I do disable Serial.Swap() in the source.

 

-SteveS

The only issue with using GPIO 1 & 3 for TX/RX is the esp8266 bootloader messages at startup. If you power up the FujiNet externally before turning on the Atari, it should not be a problem.

[a8isa1]

1 minute ago, mozzwald said:

The only issue with using GPIO 1 & 3 for TX/RX is the esp8266 bootloader messages at startup. If you power up the FujiNet externally before turning on the Atari, it should not be a problem.

Are the messages flushed from the buffer at the start?   I mean could they be queued to send as soon as the Atari connects?

 

-SteveS

[mozzwald]

I managed to pull the SIO command functions from Thom's tests into my ZIModem Atari Fork and have successfully booted Bobterm from SPIFFS while still allowing the modem to work. The repo is updated here:

 

https://github.com/mozzwald/Zimodem/tree/atari

[mozzwald]

3 minutes ago, a8isa1 said:

Are the messages flushed from the buffer at the start?   I mean could they be queued to send as soon as the Atari connects?

 

-SteveS

It's just spewing out bootloader messages on TX. If the Atari is off, nothing is there to read it so they go into the black hole of nothingness  no buffering

[777ismyname]

Those SIO connectors are awesome. If someone makes a run of these I definitely want several.

 

FujiNet is even cooler!

[tschak909]

@777ismyname the connectors are deliberately designed to mate directly to boards as seen in the above photos.

 

Meanwhile, I have implemented a first pass of TNFS directory listing, which will be required for mounting disk images. Test program is in tests/tnfsDirList. I leave it as an exercise to someone to do a BASIC version. (a hint, the strings are C strings that end with $00).

 

 

-Thom 

[a8isa1]

Loading CONFIG.BAS externally wasn't successful.  Timeout error communicating with #fujinet.  Do I need an earlier firmware for this test?

 

C version of SCANWIFI did work!  However, wifi sensitivity must be low.  Only found the two routers in the house.

 

@tschak909, scanning gets stuck in a loop.  It repeats the last access point in the list about every 2 minutes.   Can't  re-scan from that condition.

 

I don't know how to troubleshoot what's going wrong with the disk boot function.  Any suggestions?

 

-SteveS