_The Doctor__ #601 Posted March 22, 2020 error during playback Quote Share this post Link to post Share on other sites
tschak909 #602 Posted March 22, 2020 (edited) 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 March 22, 2020 by tschak909 Quote Share this post Link to post Share on other sites
+Stephen #603 Posted March 22, 2020 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 1 1 Quote Share this post Link to post Share on other sites
_The Doctor__ #604 Posted March 22, 2020 (edited) 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 March 23, 2020 by _The Doctor__ 1 Quote Share this post Link to post Share on other sites
tschak909 #605 Posted March 23, 2020 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 1 Quote Share this post Link to post Share on other sites
jamm #606 Posted March 23, 2020 (edited) 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 March 23, 2020 by jamm 1 Quote Share this post Link to post Share on other sites
tschak909 #607 Posted March 23, 2020 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. Quote Share this post Link to post Share on other sites
_The Doctor__ #608 Posted March 23, 2020 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. 1 Quote Share this post Link to post Share on other sites
tschak909 #609 Posted March 23, 2020 mm, good idea. am familiar with it. will experiment -Thom 1 Quote Share this post Link to post Share on other sites
tschak909 #610 Posted March 23, 2020 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 Quote Share this post Link to post Share on other sites
tschak909 #611 Posted March 23, 2020 @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. 3 Quote Share this post Link to post Share on other sites
Kyle22 #612 Posted March 23, 2020 (edited) 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 March 23, 2020 by Kyle22 Quote Share this post Link to post Share on other sites
tschak909 #613 Posted March 23, 2020 @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 1 Quote Share this post Link to post Share on other sites
Kyle22 #614 Posted March 23, 2020 Epson JX80 translation to HP PC/GL or whatever it is that will work on my DesignJet 510? That would be SWEET! :) Quote Share this post Link to post Share on other sites
tschak909 #615 Posted March 23, 2020 *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 Quote Share this post Link to post Share on other sites
jamm #616 Posted March 23, 2020 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. When you get a chance, try re-attaching those images. We didn't get much but text over here on this end. Quote Share this post Link to post Share on other sites
tschak909 #617 Posted March 23, 2020 See attached. -Thom Quote Share this post Link to post Share on other sites
jamm #618 Posted March 23, 2020 That looks awesome! 2 Quote Share this post Link to post Share on other sites
tschak909 #619 Posted March 23, 2020 #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. I did a quick set of install instructions on the wiki: https://github.com/FujiNetWIFI/atariwifi/wiki/Setting-up-TNFS-on-a-Raspberry-Pi 3 Quote Share this post Link to post Share on other sites
tschak909 #620 Posted March 26, 2020 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. 2 Quote Share this post Link to post Share on other sites
Kyle22 #621 Posted March 27, 2020 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. :) Quote Share this post Link to post Share on other sites
manterola #622 Posted March 27, 2020 I would to know that since the FujiNet I built I got lazy and I only connected dout, din and command signals 1 Quote Share this post Link to post Share on other sites
tschak909 #623 Posted March 27, 2020 (edited) 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 March 27, 2020 by tschak909 1 Quote Share this post Link to post Share on other sites
leech #624 Posted March 27, 2020 I ordered the microcontroller with the LCD attached to build one. Will give it a solid try once I get all the parts together! Quote Share this post Link to post Share on other sites
tschak909 #625 Posted March 27, 2020 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 1 Quote Share this post Link to post Share on other sites