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

[E474]

Hi,

 

   I was just skimming the most recent post from @mozzwald - the bit about the SIO connectors being the most difficult bit.

 

   

[tschak909]

From the original post:

 

I hope everybody making devices takes note of this, it is a solid path forward for a connector that is not only very reliable (it has withstood hundreds of insertions and pulls with my current test board, thus far), it is also very inexpensive to make.

 

-Thom

[+Mr Robot]

Also, the SIO23V3 board that is pictured in post one of that thread was designed by @mozzwald from the poor mans sio connector that @atari8warez designed. We've come full circle

[tschak909]

will say it here: @mozzwald is a frickin' hardware genius.

 

-Thom

[tschak909]

paging @ClausB what do you think of all this insanity?

 

-Thom

[jc13]

6 hours ago, tschak909 said:

From the original post:

 

I hope everybody making devices takes note of this, it is a solid path forward for a connector that is not only very reliable (it has withstood hundreds of insertions and pulls with my current test board, thus far), it is also very inexpensive to make.

 

-Thom

 

Hey Thom - I was working on making one of these to play around with and haven't found a part number for the pins themselves - can you share that info if you have it?

 

Thanks - John

 

[ClausB]

2 hours ago, tschak909 said:

paging @ClausB what do you think of all this insanity?

 

-Thom

Shiney!

[mozzwald]

9 hours ago, E474 said:

   If you are planning on making a custom PCB, have you considered incorporating the "poor man's SIO" edge connector, which is just a matter of having the SIO edge connectors on the top and bottom of the PCB, and wedging it into the SIO pins on the 8-bit.

That board looks familiar  That's how I got the idea for using the pins soldered to the edge connector. You could use that same "poor mans SIO" connector on a FujiNet board, but I wanted to make this a real peripheral.

6 hours ago, tschak909 said:

will say it here: @mozzwald is a frickin' hardware genius.

Genius ideas don't have to come from a genius (for I am not even close). I just saw a problem and found a solution.

2 hours ago, jc13 said:

I was working on making one of these to play around with and haven't found a part number for the pins themselves - can you share that info if you have it?

The Plug side pins are 7-745288-2 and Receptacle pins are 5-745287-4

[tschak909]

#FujiNet can handle UDP packets, useful for games. tests/tictactoe is a test case written in #ATARI #BASIC which shows how UDP can be used.

 

[Wrathchild]

Is see where you're going with this... "How about Global Thermonuclear War?"... "Wouldn't you prefer a nice game of chess?"

 

Fantastic work, great to be seeing how it evolves ?

[tschak909]

Now that tic-tac-toe has been checked in (it needs to be tested by others and debugged), I am working on Test #22, which is testing the INTERRUPT/PROCEED lines.

 

These lines have been a part of SIO from the beginning, but absolutely nothing uses them for their intended purpose: To signal the computer when a peripheral needs something done.

 

If you look on the Atari hardware, these SIO lines are attached to one of the PIA's, and they generate an interrupt when asserted.

 

While the OS ROM provides vectors for these two lines, they normally point to a single RTI instruction. So they don't do anything.

 

for this test, the CIO handler will attach to the INTERRUPT line, and simply put a 1 into a temporary memory location in page 2 (there are a couple unused) when the interrupt line goes low. The running program can check this and do e.g. a STATUS call. It is then the program's responsibility to clear this value back to 0.

 

The code on the arduino side:

 

 

now am working on the Atari side of it.

-Thom

[jc13]

16 hours ago, mozzwald said:

The Plug side pins are 7-745288-2 and Receptacle pins are 5-745287-4

Thanks!

[tschak909]

The #FujiNet adapter has a connection to, and can utilize the SIO INTERRUPT and PROCEED lines, which were provided by Atari to allow peripherals to signal something of importance to the computer; Avoiding expensive repeated polling.

 

 

[Kyle22]

Nice demo. I think your problem may doing it all in BASIC. ISRs are normally in ML.

 

[tschak909]

sigh.

 

The ISR _IS_ in ML.

 

I am merely checking the result from BASIC.

 

-Thom

[Kyle22]

Sorry, I kind of skimmed it over without reading completely.

 

[tschak909]

Arduino hackers, I need help:

 

Ok, so I've checked in what i've done so far for the PLATOTERM port, it's in tests/platoterm in the github repo.

 

I have borrowed a FIFO class (really I should have just written my own, I spent more time looking for one that was just right than if I had just banged it out), and hooked it up to the TCP I/O (sioclient), and am using the feeding of that FIFO to exercise the INTERRUPT line in reponse to data being available or not.

 

It starts to work, I get an initial burst of data, but the buffer never gets refilled after its initial drain.

 

https://github.com/tschak909/atariwifi/blob/master/tests/platoterm/platoterm.ino#L836 <- producer

 

https://github.com/tschak909/atariwifi/blob/master/tests/platoterm/platoterm.ino#L553 <- consumer

 

Essentially, the INTERRUPT line is checked ($D303 bit 7), and if set, the computer issues a status to get a buffer length, and then an sio_tcp_read() is done to drain the resulting buffer to SIO using the length passed in via the status, the interrupt bit is then re-asserted.

 

New data should cause the FIFO to reinflate, and cause the interrupt line to subsequently re-assert...

 

This will be great, once it works, because it will avoid the need for a stream mode.

 

-Thom

[massiverobot]

My daily Atari Prayer: Please FujiNet, let me replace this mess with your amazing abilities...

 

 

[tschak909]

 

@mozzwald just got the latest #FujiNet board revision back and assembled. The board now has an ESP32 on board, and is surface mounted. Also note the SD card slot intended for local storage (and file serving)

[mozzwald]

54 minutes ago, tschak909 said:

@mozzwald just got the latest #FujiNet board revision back and assembled. The board now has an ESP32 on board, and is surface mounted. Also note the SD card slot intended for local storage (and file serving)

Only had enough time to build and do a quick test. I was able to boot from tnfs server while SIO powered. Will do more testing this weekend. Case needs some more work, but it fits  Here's a couple more photos. The two large holes are for RESET and FLASH buttons, the smaller two are for LED's.

 

 

Edited December 13, 2019 by mozzwald
Add another image

[tschak909]

I have opened up the #FujiNet wiki, migrating from the original Google Doc. Of special interest is the Hacker List, if you have a board, please go in and add an entry for yourself, board you have, and where it came from. https://github.com/tschak909/atariwifi/wiki/Hacker-List

[tschak909]

A small administrative announcement:

 

The GitHub repository has been moved to its own organization:

https://github.com/FujiNetWIFI/atariwifi

 

 

[tschak909]

apologies, github seems to have flagged the org repo. Have sent off a support req, to try and resolve.

-Thom

 

[tschak909]

resolved.

[tschak909]

So, current status:

 

I am in the middle of trying to port PLATOTERM to the FujiNet, as a way to work out bugs in the TCP socket code.

 

This has taken two days longer than expected, already, due to the fact that I have now confirmed that both WiFiClient.write() and Serial.read() have different timings depending on the version of the ESP8266 Board Library used.

 

I had been using 2.4.0 for all tests up to this one, and had tuned the code to work best with this version of the library.

 

However, with the aforementioned version, TCP connections stop inflating the RX buffer after the first initial drain.

 

Upgrading to 2.6.2 makes the TCP read work, but virtually any SIO write (that is, computer to peripheral) fails due to malformed timing, and it is really fucking up my week.

 

I will try to work through the timing issue.

 

GOOD news: Interrupt driven RX does indeed work, have tried with both the INTERRUPT and PROCEED lines. It's very nice, because SIO calls only happen when they need to!  I am so glad that Joe and co put this feature in, as it is making this network card a feasible idea.

 

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.

 

-Thom