Jump to content
tschak909

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

Recommended Posts

YouTube embedding seems to be playing intermittently, selecting the Youtube button to play on youtube seems to work better.

 

Am guessing they're a bit overloaded... wonder why that could be? ;)

 

-Thom

 

Edited by tschak909

Share this post


Link to post
Share on other sites
1 hour ago, tschak909 said:

YouTube embedding seems to be playing intermittently, selecting the Youtube button to play on youtube seems to work better.

 

Am guessing they're a bit overloaded... wonder why that could be? ;)

 

-Thom

 

You'd think all the traffic would be at pron hub :)

  • Like 1
  • Haha 1

Share this post


Link to post
Share on other sites

I think of the AtariMax APE Loader, SpartaDos PClink methods... possibly TIVO Spigot map methods as a way to page through or parse folders and their contained files...

Edited by _The Doctor__
  • Like 1

Share this post


Link to post
Share on other sites

What I have in TNFSD:

 

* readdir

* stat

 

What I have added, but not tested in TNFSD:

 

* seekdir

* telldir

 

Each of these is a separate protocol transaction, requiring its own UDP request and response.

 

What I do NOT have:

 

* scandir (that can be attached to a sorting comparator)

 

It took tons of persistent discussions upstream to add seekdir/telldir to the protocol. They do not agree that scandir should be added, at all.

 

The Arduino FS code does not have seekdir/telldir for the SD card, so I would have to simulate it with a rewinddir().

 

-Thom 

  • Like 1

Share this post


Link to post
Share on other sites
20 minutes ago, tschak909 said:

It took tons of persistent discussions upstream to add seekdir/telldir to the protocol. They do not agree that scandir should be added, at all.

 

Would it help at all in terms of performance to implement scandir in the FujiNet firmware?  You'd still have to transfer lots of data back and forth, but at least you could take the caching/processing work off the 6502.   (I don't know if that isn't already what you were doing...)

Edited by jamm
  • Like 1

Share this post


Link to post
Share on other sites

Implementing the function in fujinet would require enough memory to hold the entire directory structure, as well as the time taken to transfer all of the directory entries 2 fujinet. As I said in the video doing this for 2300 entries took almost 2 minutes. If anybody wants to take a whack at this, go ahead.

Share this post


Link to post
Share on other sites

Forward error correction (FEC) is a light weight method to handle the dropped or out of time packets without retry... this is used in broadcast methods (think satellite and broadcast television)

you only would need two sectors or so at a time to do it.

  • Like 1

Share this post


Link to post
Share on other sites

Coincidentally, with the latest code (and the retry/duplicate code in), everything is rock solid for me, even @Fuji-Man's TNFS server, which is on the other side of a quantum singularity. :)

 

-Thom

Share this post


Link to post
Share on other sites

@jeffpiep has been hard at work implementing the unique sideways printing mode present on the Atari 820. Due to the unique orientation, it's implemented as a custom sideways font. Shown here is actual printer, and emulated PDF.

89120424_10216139221173624_6141993861108465664_o.png

 

unknown.png

  • Like 3

Share this post


Link to post
Share on other sites

Sorry to ask too many stupid questions. I just want to get clarification on one thing: Can I set up FujiNet to print DIRECTLY 1:1 (or maybe $9B -> CR) to a TCP/IP Network printer? I have a Dell M5200N that is NOT a GodDamnedIdiot (GDI) printer. This is a real printer that understands ASCII characters.

 

Edit: I was lucky enough to find this SWEET Workgroup printer at a thrift store for $10.00.

:)

I checked the page count on it and it was less than 20. Those must have been factory test pages. The toner cart was still wrapped in plastic.

This is a really nice printer!

 

Edited by Kyle22

Share this post


Link to post
Share on other sites

@jeffpiep may want to speak up, but, one of our output formats will indeed be ASCII. We're just trying to make useful emulations and a relatively universal output format that can easily be sent to any modern output device. This is why we are rendering to PDF and SVG, it becomes trivial with modern printing APIs to take those outputs and send directly to a printer.

 

-Thom

  • Like 1

Share this post


Link to post
Share on other sites

Epson JX80 translation to HP PC/GL or whatever it is that will work on my DesignJet 510? That would be SWEET!

:)

 

Share this post


Link to post
Share on other sites

*deeeeeeeep-breath*

 

okay then.

 

You do realize that most people don't spend years setting up such convoluted paths to printing, right? ;) This is why we are explicitly doing things the way we are. :)

 

-Thom

Share this post


Link to post
Share on other sites
26 minutes ago, tschak909 said:

@jeffpiep has been hard at work implementing the unique sideways printing mode present on the Atari 820. Due to the unique orientation, it's implemented as a custom sideways font. Shown here is actual printer, and emulated PDF.

89120424_10216139221173624_6141993861108465664_o.png

 

unknown.png

When you get a chance, try re-attaching those images.  We didn't get much but text over here on this end. :)

Share this post


Link to post
Share on other sites

#FujiNet - Shown here is a picture of my local TNFS server that I use for my own file storage. While there are internet-accessible public TNFS file servers, this one is for my own files.

 

It is a Raspberry Pi 3, inside a FLiRC case, with 64GB of flash, running Raspbian Lite, and the tnfsd software as a systemd service. I am powering it off one of the USB connectors on my power strip.

 

Total setup time: 30 minutes.
 

20200323_135405.thumb.jpg.671359fa515205fea3d62952dab9cafe.jpg

 

I did a quick set of install instructions on the wiki:

https://github.com/FujiNetWIFI/atariwifi/wiki/Setting-up-TNFS-on-a-Raspberry-Pi

  • Like 3

Share this post


Link to post
Share on other sites

2020-03-26 Status Report:

to coders itching for a project or a way to help: I really could use some help trying to implement the ATX support, as I am busy trying to shore up other parts of the code.

 

I spent the last week working through the TNFS code:

* Remove the re-caching code, as it was buggy, in preparation for refactor.

* Fix retry logic so that duplicate packets don't cause issues, they are ignored.

* Refactor to properly handle timeouts and to only fail outright if all retry attempts fail.

* Implement SIO command for Write with Verify (no longer just an alias for P).

* Implement seek optimization, only seek when needed, thereby reducing the number of UDP round trip packets significantly for linear reads.

 

Rick Lopez has been working on the R: code, taking it apart to understand it, and making improvements. His current set of experiments are taking the Altirra R: handler and embedding it into #FujiNet firmware to be passed across via Type 1 poll. (We have permission from @phaeron

Buffering improvements are also being tried to compensate for the characteristically small RX buffers specified by the Atari during concurrent mode by most MODEM programs, in an effort to get most modem programs to be able to work at higher speeds.

An idea I proposed here is to modify the R: handler to emit an additional command before the STREAM command which returns the size of the requested IOCB buffer length. This can be used as a secondary buffer, only filled when drained, to throttle the connection even at higher baud rates when the buffer is much too small to handle higher transmission rates.

 

We hack onward through the mud. :)

 

 

  • Like 2

Share this post


Link to post
Share on other sites

Does this R: Handler use the interrupt lines? is there flow control? I believe it is possible, it may require some thinking outside the box, though.

:)

 

Share this post


Link to post
Share on other sites

I would to know that since the FujiNet I built I got lazy and I only connected dout, din and command signals

  • Like 1

Share this post


Link to post
Share on other sites

No, it doesn't. and most likely won't. We are in somewhat of a unique situation where we may very well be able to solve the problem with a secondary fill-only-on-empty buffer that is sized according to the requested buffer into concurrent mode. We'll need to add a few lines of code to the altirra handler first.

 

INTERRUPT and PROCEED will eventually be used for the N: handler, as we really need it to avoid the use of needing a streaming mode.

 

-Thom

 

p.s. to further explain what I mean:

 

when an XIO 40 to R: is encountered, this results in a couple of things happening via the resident handler:

 

* POKEY input/output interrupts disconnected from their usual SIO logic, and connected to a routine which just bit-bangs in/out what's pending.

* An SIO STREAM 'X' command is sent to the peripheral, which returns a payload of bytes intended to be poked directly into POKEY control registers to set the baud rate clock.

* The values are set via the handler, and the handler now operates in stream mode.

* If the COMMAND line is raised, then the interrupt routine is stopped, disconnected, and normal SIO operation resumes.

 

I propose to add an additional command (e.g. 'W'), which will take the ICBLL and ICBLH values making up the calling IOCB, and send them to the peripheral, before the stream starts. This will allow the #FujiNet firmware to allocate a buffer before streaming starts.

 

So the main loop in stream mode on the ESP will fill the buffer when there are no bytes in the buffer, AND there is data waiting at the socket. Buffer is filled up to the max specified by the 'W' command and reads will drain from this buffer. Buffer will not re-fill UNTIL the buffer is completely drained; thus acting as a throttle for situations where modem programs only ask for e.g. a 256 byte buffer (most things)

 

because these problems do not present themselves when a large enough receive buffer is requested (e.g. with PLATOTERM or ICE-T)

 

-Thom

Edited by tschak909
  • Like 1

Share this post


Link to post
Share on other sites

I ordered the microcontroller with the LCD attached to build one.  Will give it a solid try once I get all the parts together!

Share this post


Link to post
Share on other sites

You really don't need the LCD. We explicitly aren't requiring one, or utilizing one. This is a deliberate design decision to keep the unit simple, use as little power as needed (it can currently reliably be powered over SIO).

 

-Thom

  • Like 1

Share this post


Link to post
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.

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