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

[+mytek]

17 hours ago, tschak909 said:

One problem with knocking out these tests so fast, is I worry that I won't be able to keep up this pace, as the problems get harder.

This is not a problem. It's just the way things work when doing R&D. Sometimes things are happening lickey-split, and sometimes it slows down for a bit as the design gets taken to another level. So long as it keeps moving forward towards the goal is really all that is truly important.

 

“Patience you must have.” Yoda

[tschak909]

oh I know, I've been doing this type of work for a very long time, I'm just worried that people will lose patience.

-Thom

[jeffpiep]

On 12/9/2019 at 11:30 PM, mozzwald said:

Ahh, LCD. Could be handy, but the goal is to configure the device from the Atari as shown by @tschak909 with the config example sketch (and/or via WiFi) so the LCD would be just an added cost.

 

I also envision an http:\\ server on the ESP so you can connect with your phone and configure it from there. No need for LCD. Buttons and displays are more expensive than the ESP32 itself.

[tschak909]

Yup, no LCD, all config will be handled either from the atari config program (which will always be on spiffs), or an http server it exposes.:)

-Thom

[Kyle22]

This is all wonderful. Have you investigated UltraSpeed yet? It is simple. Computer requests divisor from device using SIO command $3F, Device responds w/ divisor.  When device receives 19.2KBaud data, it responds @ 19.2Kbaud. If the computer sends a command at the US divisor rate, then the drive believes it has received rubbish, it switches to agreed upon divisor UltraSpeed rate and syncs up.

 

That's my understanding of US protocol.

 

 

It just toggles back & forth until it gets an ACK.

 

IF this is possible, and I think it is, get in contact w/ Hias and Jon.

 

I see no reason we can't do at least 38.4 KBaud or more with a BBS or BobTerm.

 

[tschak909]

not yet, not there yet, still doing way too many fundamental pieces of research.

-Thom

[tschak909]

#FujiNet was featured on The ANTIC Podcast! @Savetz @rkindig Brad and I talk about it.

http://ataripodcast.libsyn.com/antic-episode-63-sillyventure-and-fujinet

 

-Thom

[tschak909]

Formal apology: I had posted a Twitter log for the dev team here, in the interests of transparency into the whole thing, and it hadn't been sufficiently scrubbed. It has been pulled down. 

 

Sorry about that.

 

-Thom

 

[flashjazzcat]

Yeah it was pretty interesting.

[Kyle22]

It was.

:)

 

[+x=usr(1536)]

Only just seeing this thread now.

 

HOLY.  BALLS.

 

It's going to be *very* interesting to see how this progresses.

[Kyle22]

18 minutes ago, x=usr(1536) said:

Only just seeing this thread now.

 

HOLY.  BALLS.

 

It's going to be *very* interesting to see how this progresses.

I think this going to be an amazing device when finished and all the bells and whistles are added.

So much possibility.

 

[mozzwald]

Short hardware update for the FujiNet ESP32 prototype.. I tested the SD Card socket for the first time last night and it's working. Booted the Atari from and ATR on SD Card. Also added light pipes and buttons to the 3D printed case. Now we can has blinky!  colors are a bit washed out, but it's blue and orange LEDs

 

 

[tschak909]

Hi, 

 

Am in the middle of writing down documentation for SIO commands that have been implemented across various tests, thus far. 

 

This is a wiki, if there are issues, they can be changed (either directly or via pull request depending on how you're connected to the project), and that pretty much goes for anything: Yes, there will be bugs, everywhere. Hopefully when they're caught, step up and try to fix them, and we'll all benefit

 

Example page, for UDP Status, a command that returns various bits of UDP status based on the AUX1 byte:

https://github.com/FujiNetWIFI/atariwifi/wiki/SIO-Command-$D1---UDP-Status

 

-Thom

[E474]

Hi,

 

   Would it be possible to just set DBYTLO and DBYTHI for length of the packet in the Read or Write functions (that is, not having to set AUX1 and AUX2 to the same values too)?

[tschak909]

No, because SIOV has to know the size of the payload ahead of time, and the only way to send that across is via AUX1/AUX2.

 

-Thom

[tschak909]

1 hour ago, tschak909 said:

No, because SIOV has to know the size of the payload ahead of time, and the only way to send that across is via AUX1/AUX2.

 

-Thom

To further explain:

 

DAUX1/DAUX2 literally become part of the command frame when sent to the peripheral. DBYT is wholly an SIOV variable that either determines:

 

* When DSTATS is 0x40, how many bytes to expect from the peripheral during the data frame

* When DSTATS is 0x80, how many bytes will be sent by SIOV to the peripheral during the data frame

 

These values have to be known BEFORE the command is executed, and thus must be carried over during the COMMAND frame, which means, it has to be one of:

 

* DDEVIC+DUNIT

* DCOMND

* DAUX1/DAUX2

and well, checksum is, the ...checksum. so..

 

-Thom

[tschak909]

I have updated the documentation on the WIKI to reflect the currently in use SIO commands for the #FujiNet device ID (0x70)

https://github.com/FujiNetWIFI/atariwifi/wiki/SIO-Commands-for-Device-ID-%2470

 

-Thom

[AtariGeezer]

This is what I'm using for TNFS:

void Process_N_Dev(byte nDev, byte nCmd, byte Aux1, byte Aux2) {

  switch (nDev) {
    case 0x70:
      switch (nCmd) {
        case 'S': // 
          Process_NDev_Status(Aux1, Aux2);
          break;
        case 'M': // 
          Process_NDev_Mount(Aux1, Aux2);
          break;
        case 'U': // 
          Process_NDev_UnMount(Aux1, Aux2);
          break;
        case 'O': // 
          Process_NDev_OpenDir(Aux1, Aux2);
          break;
        case 'R': // 
          Process_NDev_ReadDir(Aux1, Aux2);
          break;
        case 'C': // 
          Process_NDev_CloseDir(Aux1, Aux2);
          break;
        case 'K': // 
          Process_NDev_MakeDir(Aux1, Aux2);
          break;
        case 'V': // 
          Process_NDev_RemoveDir(Aux1, Aux2);
          break;
        case 'o': // 
          Process_NDev_Open(Aux1, Aux2);
          break;
        case 'r': // 
          Process_NDev_Read(Aux1, Aux2);
          break;
        case 'w': // 
          Process_NDev_Write(Aux1, Aux2);
          break;
        case 'c': // 
          Process_NDev_Close(Aux1, Aux2);
          break;
        case 's': // 
          Process_NDev_Stat(Aux1, Aux2);
          break;
        case 'l': // 
          Process_NDev_LSeek(Aux1, Aux2);
          break;
        case 'd': // 
          Process_NDev_UnLink(Aux1, Aux2);
          break;
        case 'm': // 
          Process_NDev_ChgMode(Aux1, Aux2);
          break;
        case 'n': // 
          Process_NDev_Rename(Aux1, Aux2);
          break;
        case 'Z': // 
          Process_NDev_Size(Aux1, Aux2);
          break;
        case 'F': // 
          Process_NDev_Free(Aux1, Aux2);
          break;
      }
      break;
  }
}

 

[tschak909]

Most excellent. I think that we can fold both the file based TNFS and disk image mounting over TNFS functionality ultimately into the same firmware. 

I think the trick will be, especially from a CIO standpoint, discerning what is essentially the following modalities:

 

* Device control (mounting/unmounting disk images, establishing sockets, etc.)

* Accessing TNFS file stores directly

* Communicating with established TCP and UDP sockets.

 

It becomes a bit more goofy when dealing with the N: device over CIO because while CIO itself can handle large filenames (as big as the specified buffer length), DOS 2 REALLY doesn't like it when you try to specify file names longer than 8.3+2 device spec characters + colon, and deliberately traps that as an error. grrrr....

 

(because there really is a perverse part of me that wants to be able to e.g. copy a file in DOS 2.0 to a socket, or copy a file from HTTPS onto a disk)

 

so basically, there will have to be an out of band method for mounting a host and directory for direct TNFS usage.

 

(This is ironically one of the reasons I chose to concentrate first on mounting disk images)

 

-Thom

Edited December 18, 2019 by tschak909

[tschak909]

Received the 8266 Rev3 #FujiNet board from Steve Boswell. It works great, am waiting on the ESP32 board from @mozzwald, now. (Yes, we are spinning boards, THAT fast!) Last pic is alongside my Rev2 board.

 

[E474]

Hi,

 

    Thanks very much for the detailed explanation, that makes a lot of sense if you aren't using fixed size packets. With D : SIO transfers, you can get the sector size from the sector number and the percom block setting, e.g. no percom block then sector size = 128 bytes, percom block present, then sector size = 128 bytes for sectors 1-3, thereafter sector size is given by percom block values. 

 

    It's a pity you can't do something like a set default packet length function, then just read/write calls until you do another set packet length function (to a new value).

 

    Also, I was wondering if it makes more sense to combine ip4 address and port# into a 6 byte value and return that, as otherwise you end up doing 2 calls, but I'm not sure how often you would be making these requests anyway.

 

    Btw, can you generate audio in on SIO pin 14 with the esp32 chipset?

 

     Great to see this project progressing!

[tschak909]

4 minutes ago, E474 said:

Hi,

 

    Thanks very much for the detailed explanation, that makes a lot of sense if you aren't using fixed size packets. With D : SIO transfers, you can get the sector size from the sector number and the percom block setting, e.g. no percom block then sector size = 128 bytes, percom block present, then sector size = 128 bytes for sectors 1-3, thereafter sector size is given by percom block values. 

 

    It's a pity you can't do something like a set default packet length function, then just read/write calls until you do another set packet length function (to a new value).

 

    Also, I was wondering if it makes more sense to combine ip4 address and port# into a 6 byte value and return that, as otherwise you end up doing 2 calls, but I'm not sure how often you would be making these requests anyway.

 

    Btw, can you generate audio in on SIO pin 14 with the esp32 chipset?

 

     Great to see this project progressing!

 

Audio is a possibility with the ESP32, dunno how it'll be done yet, but it might be doable. we shall see.

 

As far as the ip/port calls, it was only because I am fitting it into an existing buffer space allocated by the OS (DVSTAT), which is 4 bytes long.

 

-Thom

[tschak909]

I did mention that my development cycles are getting longer, this is still true.

 

Right now, I am working on the next pass of the Diskulator, (called the Multilator), which adds the following features:

 

* Connect to Hidden SSID

* Multiple Disk Image mounting support

* Multiple TNFS support

* Search filter when asking for image

 

The program flow is now (from FujiNet cold start):

 

* boot CONFIG

* Check network config, if configured, try to connect and go to diskulator, if SELECT held, fall through to network config

* If not configured, get SSID and PASSWORD.

 

Once in Diskulator, the following loop is done:

 

* Check for OPTION, if held, cold start. If you want BASIC, let go.

* Select/Edit host

* Connect to TNFS, get directory, select image

* Select Drive slot (1-8 to mount to)

* rinse and repeat

 

Currently, for the sake of getting something working, I have imposed the following temporary limitations:

 

* 36 character filenames

* no subdirs on TNFS

* max of 16 files to display, no pagination

 

It must be understood that I am MAKING myself do fast release cycles with small changes each cycle, so I can keep my head above water, and to keep the feedback loop nice and tight. This is part of the reason that even though things appear to be moving fast, it will still take a long time to get things firmed up. I hope you all understand.

 

-Thom

 

 

 

Edited December 19, 2019 by tschak909

[+x=usr(1536)]

Are there any plans for TLS support?  This looks like it could be perfect for WAN-based file repositories, but, having a rather nosy ISP, I'd prefer to not send anything in cleartext if it can be avoided.