Jump to content
IGNORED

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


tschak909

Recommended Posts

39 minutes ago, tschak909 said:

Other news: @jamm has been a huge help in working on the firmware! He has implemented TYPE 1 SIO polling for the R: device, so that the R: device is loaded now exactly like an 850 interface. Thanks to @phaeron for his permission to use the Altirra R: handler firmware. :)

 

Also thanks to @phaeron for his incredible documentation and source code.  So many things would be 100x harder without all the effort he has put in and shared with the community over the years.

 

  • Like 1
Link to comment
Share on other sites

with that information,

polling is used to pull your handler in from fujinet device and not the standard altirra handler where 850 serial is concerned correct?

Does this then allow your interrupt/proceed/x to work as flow control in modem/rs232 mode or is that still going to be 850 in nature(my assumption is the status melee is gone with your custom handler and only block mode need exist when fujinet is told to wait while other sio devices do their thing.)

what baud rate is being used w/ network PLATO. can we use extrernal clock injection from fujinet to push it further...

 

did I seem a little bit excited? I'm not moving the goal posts just a remembering previous discussions and running with it. as you knock each piece down, someone always sets up another one for the team to take a whack at.

 

looks as if you're crossing the stuff we've all been yakking back and forth with over the years off the list...

 

Now this is where I express a concern....

 

currently I can use a dragon and an 850 at the same time... this allows tcp/ip/udp via dragon, while the 850 or MIO etc. is still using a modem or lantronix box.... pretty nifty....

 

If the fujinet is in network mode can 850 sio/serial or MIO pbi/serial still be used at same time...

as in would fujinet be using polling or boot  with it's own unique command number and respond to that... or is it taking over the already existing device command boot number... co opting 850, P:R:, MIO, and Black box handlers

The old devices use status while fuji is using int/cmd... not sure of overlap, but interfacewise they might still co/exist...

 

Is it possible fujinet already is doing network and modem at the same time... as in the terminal demo you had showing fujinet with mounted network disks, and then running a terminal from that disk, while using the terminal/modem fujinet is still acting as a network drive, and if that's the case.... modem emulation running, and other network connection at the same time including tnfs? or does it just look as if that's the case as the image is pulled off tnfs saved to sd and run from there?

 

Edited by _The Doctor__
  • Like 1
Link to comment
Share on other sites

Currently, the interrupt driven nature only applies to the 0x71 to 0x78 devices, which are used for network traffic.

 

The 850 has no concept of interrupt or proceed, and would need a special handler to deal with them...given that the 850 explicitly uses a stream command to take over the bus, changing this behavior will break a lot of stuff, and so you can't use the R: along with anything else. That's not #FujiNet's fault, but rather the nature of how the 850 works and how the R: handler must work. 

 

I was able to bypass this mess with the N: device, because I had a clean slate, and because the #FujiNet has oodles of RAM for buffers, as well as a well off-loaded TCP stack, I could literally deal with the network traffic in more packet-like terms. Because the 0x70 devices do not do a stream mode, they do not block the bus when in use, and the typical modes of handshaking simply aren't needed. The TCP stack applies proper window resizing if we're behind on draining the buffers.

 

Right now, the N: devices run at the standard 0x28 pokey divisor (19200 baud), only because the OS does not have high speed routines to speed up the devices in the 0x7X range, if there were, the FujiNet would gladly shift 62Kb/s or more, maybe 127Kb/s (I say the last part nervously because I am now understanding the tight timing and shortcuts needed in the immediate vertical blank interrupt to get the cycle count whiddled down enough. It should work, because I run the disk part of #FujiNet at that speed constantly now, thanks to the U1MB's PBI BIOS which patches in the high speed routines for disk devices) DOES SOMEONE WANT TO HELP MAKE THE 0x70 DEVICES RUN AT FULL SPEED? Simply implementing the 0x3F high-speed command isn't sufficient, Hias's code simply doesn't check high speed for devices in that range.

 

The N: device is NOT an RS232 device, it's a whole different animal, its whole reason for existing is to provide a CIO and SIO abstraction for all sorts of network protocols, TCP, UDP, HTTP, FTP, TNFS, SSH, translating them on the fly to Atari I/O idioms, giving a sort of fixed length transaction interface at the SIO level, and providing the needed character by character interface at the CIO level (with burst I/O where possible), into OPEN, CLOSE, READ, WRITE, STATUS, and SPECIAL.

 

For imperative I/O operations that don't fall into OCRWS, SPECIAL allows for each protocol to define a set of controls that can change the context of the READ, WRITE and STATUS operations, think of it like treating XIO like ioctl() in POSIX.

 

It takes a LOT of work, but users will be rewarded with a consistent interface to the modern network outside, with the ability to write software in whatever language or environment wanted.

 

(some not nice things about the Dragon Cart said below, feel free to skip)

 

This was my biggest criticism about the Dragon Cart, they were being awfully narrow minded about the obsession of putting an Ethernet interface onto the Atari, and writing a TCP stack in 6502. Ok, great, you plugged a CS8900 up to the bus, great, and you have now spent 3/4ths of your visible address space JUST HOUSING THE BARE MINIMUM OF A TCP/IP STACK, ___NOW WHAT?!?!!___ it was a thought experiment made manifest, and they made it, but when you're using almost all of your RAM to hold a TCP/IP stack that still to this day does not do proper window resizing, that requires you to either use C or assembler to code to a sort of BSD sockets implementation (that does not integrate well to existing Atari I/O subsystems AT ALL), and you get NO encryption on top of that, so there are a whole host of programs you simply can't write with it, I ask again, WHAT...WAS...THE...POINT? sigh. At some point you have to cut your losses and realize that the approach was a dead end, and you have to re-think your most basic assumptions. This is what I did, and why #FujiNet is able to go where other networking projects aren't able to.

 

-Thom

 

  • Like 3
Link to comment
Share on other sites

You are completely correct in that dragon cart did exactly those things, and for those purposes....  what got me into trouble during that project was pointing out almost every machine for years had the nic handle most of this stuff... even in todays windows soft driven devices there's still enough of the device to offload stuff to them and not burden the computer.

  • Like 1
Link to comment
Share on other sites

believe it or not, telnet/irc, and serving some rudimentary web pages, a little browsing a few years back... but today the web pages are terrible for such things as memory was limited with all the crap running in the Atari for the cart....

 

1 online game that was fun to be a part of... 8 bit slicks...

 

http://www.atari8ethernet.com/

 

http://8bit-slicks.com/

 

https://atariage.com/forums/topic/161158-atari-8-bit-ethernet-and-contiki-want-your-help/

 

Edited by _The Doctor__
Link to comment
Share on other sites

I pointed these things out to the Dragon Cart developer...pissed him right off... he called me an ignorant ass. (snicker) and brought them up again to a2retrosystems when they decided to use the W5100 for the second revision. The W5100 does offload, yes, but why in the hell would you use a chip that has been EOL'd for almost a decade (AND YOU ALSO HAVE NO CHANCE FOR ENCRYPTION!) ? It boggles the mind. And when you cram it onto a cart, you have to take a chunk of your cart's space to provide some sort of a handler ROM... PBI is nice, but you lose half of your market share, with it.

 

And I posit finally, that what's the point of a high speed networking interface running at bus speeds, on a computer that nominally runs at just under 2 MHz, with a 64K address space? 

 

The Spectranet project showed me, that unless your network interface provides something immediately useful out of the box, it's dead in the water.. and by going SIO, #FujiNet is able to leverage the entirety of the Atari OS to do all sorts of amazing stuff.

 

-Thom

Edited by tschak909
  • Like 2
Link to comment
Share on other sites

2 minutes ago, _The Doctor__ said:

believe it or not, telnet/irc, and serving some rudimentary web pages, a little browsing a few years back... but today the web pages are terrible for such things as memory was limited with all the crap running in the Atari for the cart....

 

1 online game that was fun to be a part of... 8 bit slicks...

 

http://www.atari8ethernet.com/

 

 

That's not a bad looking game!  I'm definitely looking forward to playing either MIDIMaze itself (which @mozzwald has already gotten running on FujiNet as a proof of concept) or a modified version over the internet someday soon!  :)

 

  • Like 1
Link to comment
Share on other sites

I will say one disadvantage of the SIO bus, is that you will have to be very creative with sound channels during network traffic, as two of your sound channels will be used to clock the network data being shifted out. This is one reason why being interrupt driven is so critical.

 

-Thom

Edited by tschak909
  • Like 2
Link to comment
Share on other sites

midi device will drive the external clock for the established midi software base then?

midi track iii etc...

I'm sure there's more info. but a precise clock is needed for the core purpose of midi devices and networks to be fulfilled,(synchronization)

Edited by _The Doctor__
Link to comment
Share on other sites

Just now, _The Doctor__ said:

midi device will drive the external clock for the established midi software base then?

midi track iii etc...

I'm sure there's more info. but a precise clock is needed for the core purpose of midi devices and networks to be fulfilled,(synchronization)

The CLKIN is connected to the FujiNet, and is used in MidiMate mode, we've already been here, done that. MIDI traffic works well enough over UDP. @mozzwald did it.

 

 

-Thom

 

  • Like 1
Link to comment
Share on other sites

3 minutes ago, _The Doctor__ said:

midi device will drive the external clock for the established midi software base then?

midi track iii etc...

I'm sure there's more info. but a precise clock is needed for the core purpose of midi devices and networks to be fulfilled,(synchronization)

 

I was joking about a MIDI emulator!  Not that it's not possible, but it's not currently on the 1.0 feature list.

Taking the MIDIMaze networking code an converting it into UDP traffic is another matter - that's what @mozzwald demonstrated.

 

Edited by jamm
Link to comment
Share on other sites

On 4/8/2020 at 5:04 PM, Fierodoug5 said:

Also I guess the fujinet has to be plugged in directly to the Atari. I tried hooking up to my Lothark SIO hub and it does not boot that way on either the 800 or 800xl.

There was 1 other report of this back in November that was never resolved. Can you verify that Lotharek's SIO hub is providing 5V to FujiNet? With and without external power to the hub.

  • Like 1
Link to comment
Share on other sites

just tried without external power to the Lotharek SIO hub(dont have adaptor for it)

It is putting 5 volts to the Fujinet through the 5V/Ready pin on the sio connector to SIO_5V at the R2 resistor

It works fine on the 800XL, Fujinet boots as normal

Does not work on the 800(one quick SIO flash on Fujinet, computer boots to Memopad(or basic with cartridge installed)

Fujinet powered from USB for both tests

Link to comment
Share on other sites

8 minutes ago, Fierodoug5 said:

just tried without external power to the Lotharek SIO hub(dont have adaptor for it)

It is putting 5 volts to the Fujinet through the 5V/Ready pin on the sio connector to SIO_5V at the R2 resistor

It works fine on the 800XL, Fujinet boots as normal

Does not work on the 800(one quick SIO flash on Fujinet, computer boots to Memopad(or basic with cartridge installed)

Fujinet powered from USB for both tests

I can't find a schematic for it so I will have to 'guess' how it works (unless someone else knows). Can you read the part number on the IC between the Atari SIO port and the 4 other ports?

Link to comment
Share on other sites

sound pretty simple to me externally power the buffered sio splitter... this same thing has happened in other threads... I'm to lazy to check if it's been noted in any of the fujinet threads... seems pretty straight forward... if it still fails then we have a mystery to track down...

Link to comment
Share on other sites

BTW, yesterday I tried the latest version and for the first time I connected it to a computer with Hias modified OSROM for high speed, and it was amazing. I guess I got divisor 0 speed.

Then I tried that "COMM" disk image and tried icet and plato , but i could not connect to anything.. Is there something I need to do previously to get connected (using the modem emulation).. I did atdt telnetserver:port   I got the "connecting" but then it timeout.

Thank you for the great device!

 

Edited by manterola
Link to comment
Share on other sites

On 4/23/2020 at 6:05 AM, Fierodoug5 said:

Can someone put a little tutorial on how to use the printer emulation on the fujinet? 

@jeffpiep Has been refactoring the printer emulation code recently, so I think the current version still needs some adjustment.

 

31 minutes ago, manterola said:

Then I tried that "COMM" disk image and tried icet and plato , but i could not connect to anything.. Is there something I need to do previously to get connected (using the modem emulation).. I did atdt telnetserver:port   I got the "connecting" but then it timeout.

Thank you for the great device!

 

I believe ICET needs an RS232.COM stub to be available to talk to the R: device.  Are you able to type "AT?" and get a help screen?  What's your source for the COMM disk image?

 

If you download an ATR of BobTerm and either boot directly into that or boot DOS and load it separately, it should just work, as it will pull the R: handler directly from FujiNet.

 

Link to comment
Share on other sites

1 hour ago, manterola said:

BTW, yesterday I tried the latest version and for the first time I connected it to a computer with Hias modified OSROM for high speed, and it was amazing. I guess I got divisor 0 speed.

Then I tried that "COMM" disk image and tried icet and plato , but i could not connect to anything.. Is there something I need to do previously to get connected (using the modem emulation).. I did atdt telnetserver:port   I got the "connecting" but then it timeout.

Thank you for the great device!

 

Can you mount atari-apps.irata.online and load plato.atr? This version uses the network device.

-Thom

Link to comment
Share on other sites

On 4/23/2020 at 6:05 AM, Fierodoug5 said:

Can someone put a little tutorial on how to use the printer emulation on the fujinet? 

To follow up on my last reply: the current FujiNet build is creating a simple "file printer" where anything you send to the "P:" device is stored in a file.  To retrieve the contents of the file, open a web browser to http://your-fujinet-ip-address and click on the printer icon to download its current contents.

 

The functionality is to emulate Atari dot-matrix printers is already there and at least partially tested, as you can see in previous posts in this thread.

 

All of this is in flux, of course, and the current functionality is very much in development.

Edited by jamm
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...