Jump to content
IGNORED

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


tschak909

Recommended Posts

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

  • Like 2
Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

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.

 

  • Like 1
Link to comment
Share on other sites

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! :D colors are a bit washed out, but it's blue and orange LEDs

 

 

  • Like 8
Link to comment
Share on other sites

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

  • Like 3
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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;
  }
}

 

  • Like 1
Link to comment
Share on other sites

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 by tschak909
  • Like 2
Link to comment
Share on other sites

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!

  • Like 1
Link to comment
Share on other sites

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

  • Like 2
Link to comment
Share on other sites

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.

 

-Thom1aicU4X.jpg

 

RVMFdkg.jpg

 

VWicYs0.jpg

 

Edited by tschak909
  • Like 4
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...