tschak909 Posted March 10, 2020 Author Share Posted March 10, 2020 If anyone hasn't seen it, I have a video that I made regarding Spectranet, and by extension TNFS, on its original platform: You can see that already, the #FujiNet UI is a lot more in-reaching, than ZX Spectrum BASIC. -Thom 3 Quote Link to comment Share on other sites More sharing options...
jamm Posted March 10, 2020 Share Posted March 10, 2020 I was thinking that you have plenty on your plate now without worrying about making it the best imaginable UI --- at least not at this stage in development! Quote Link to comment Share on other sites More sharing options...
jamm Posted March 10, 2020 Share Posted March 10, 2020 6 minutes ago, tschak909 said: The problem here, is that TNFS's implementation is very 1:1 to POSIX, with each protocol verb mapping directly to a POSIX call. This means that returning each directory entry requires one full UDP round trip. It means doing a stat() to get ANY information about the file, is ALSO one separate full UDP round trip. This does not count the SIO round trip to the Atari for any information ready for the Atari to process. I am having to take some hard knocks and bruises to try and find a solution that works well for image selection. this in addition to ..........everything else I am working on. -Thom When I did some protocol work years ago, we had several different versions of list queries, each returning blocks with more detailed data. This allowed for the same basic code to handle both cases where the UI simply needed to show a list of objects, and others where the UI either had to show more detailed information, or needed to be prepared to without another round trip and delays for more details. So "DirV1" would only return a list filenames, for example, and "DirV2" would return a list of filenames, timestamps, and ownership rights. Trying to stick too closely with an extremely simple protocol would've completely derailed our ability to deliver a good product. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted March 10, 2020 Author Share Posted March 10, 2020 yeah, am familiar with that approach. -Thom Quote Link to comment Share on other sites More sharing options...
jamm Posted March 10, 2020 Share Posted March 10, 2020 On 1/18/2020 at 5:29 PM, tschak909 said: #FujiNet successfully running the ESP32 at the #Atari SIO rate at 125,984 baud (POKEY Divisor 0, fastest possible.), at that rate, the beeps literally are just buzzes. Don't blink. Just reading through the entire thread, and I'm impressed that you were able to go from the ESP32 being a bit slower than the ESP8266 to being able to go full-on "divisor 0". Where there other changes after @TheMontezuma's significant contributions? Quote Link to comment Share on other sites More sharing options...
tschak909 Posted March 10, 2020 Author Share Posted March 10, 2020 basically, adding a flush() after ack, so that the complete/error timing was within the acceptable range. It should be tighter, but it can't, because flush() is an extremely expensive call, and because of the buffering that the esp serial port does, it's unavoidable. The ESP32 is still a bit slower than the ESP8266 because of this. -Thom Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted March 10, 2020 Share Posted March 10, 2020 On 3/9/2020 at 6:12 PM, 8-bit and more said: I recorded the last hour or so since I was walking in and out of the room and wanted to replay it. If everyone who was there gives the ok i'll put it up for download OK from me (to be honest I was also walking in and out of the room). Quote Link to comment Share on other sites More sharing options...
jamm Posted March 10, 2020 Share Posted March 10, 2020 On 2/29/2020 at 2:09 PM, mozzwald said: There have been requests for an ESP32 based FujiNet schematic/BOM/pinout and I have previously directed everyone to the Google Sheet for the pinout. I've now created a schematic that you can use to build one with a ESP32-DEVKITC / NodeMCU32 or the like. The switch can be replaced with something else (or removed if you like), it's there to enable/disable powering FujiNet from the Atari SIO 5V. For the SD Card socket, you probably want a breakout board like this or this. Note: I have not actually used this schematic to build anything. It's based off the FujiNet Dev board I made and *should* work. I found a pretty cheap Micro SD PCB: https://www.aliexpress.com/item/32791255542.html There are a bunch of cheap PCB's meant for Arduinos, but I imagine the extra resistors (?) they have would make them inapplicable for use with the ESP32? Example: https://www.aliexpress.com/item/32867572635.html Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted March 11, 2020 Share Posted March 11, 2020 That explains why I haven't received an ESP32 Fujinet from you yet! Is everyone still using the Mars bars? Quote Link to comment Share on other sites More sharing options...
tschak909 Posted March 11, 2020 Author Share Posted March 11, 2020 Hey, Steve! The PLATFORM.IO code hasn't been back-ported to the ESP8266, yet (there are filesystem API differences at the very least, to account for.), so Jeff, Mozz, and I are using Ice Cream Sandwiches as our primary devices at the moment, and @mozzwald is hard at work doing the next iteration of the hardware. -Thom Quote Link to comment Share on other sites More sharing options...
ivop Posted March 11, 2020 Share Posted March 11, 2020 Is there a specific reason you opted to use platform.io with all its C++ classes and overhead, instead of staying closer to the bare metal? Just asking. 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted March 11, 2020 Author Share Posted March 11, 2020 @ivop a very good question. First, I do need to make a distinction here: PLATFORM.IO doesn't predicate C++. Arduino does. It is altogether possible to write in Espressif-IDF, which can either be C or C++, and we very well may do this, yet. We went with PLATFORM.IO, because: * Much easier to scale out and keep things modular, than in Arduino. * Unit testing is possible, and will be done. * Actual debugging facilities * Finer grained control over memory partitions, which we will need as we are trying to shove a LOT of functionality under one umbrella. There are others, but those are the big ones. -Thom 1 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted March 12, 2020 Author Share Posted March 12, 2020 Does anyone know of any Polish #Atari8Bit forums that can be joined to start a discussion on #FujiNet? Quote Link to comment Share on other sites More sharing options...
manterola Posted March 12, 2020 Share Posted March 12, 2020 Not sure but it looks like atarionline.pl is the biggest and more important one. That what is looks from here at least. Quote Link to comment Share on other sites More sharing options...
+ZuluGula Posted March 12, 2020 Share Posted March 12, 2020 Another one is http://www.atari.org.pl/forum/index.php and most suitable subforum is http://www.atari.org.pl/forum/viewforum.php?id=24 "Fabryka - 8bit", which means factory. It's dedicated to new software and hardware projects. Most users can communicate in English, but don't be surprised to get response in Polish. You would have to translate it. Some one already mentioned your work over there http://www.atari.org.pl/forum/viewtopic.php?id=16351 Quote Link to comment Share on other sites More sharing options...
+ZuluGula Posted March 12, 2020 Share Posted March 12, 2020 @tschak909, you could also try Facebook. Recently, I discovered Atari Chile group with over 2200 members that seems to be pretty active. https://www.facebook.com/groups/840633719349481/ Quote Link to comment Share on other sites More sharing options...
tschak909 Posted March 14, 2020 Author Share Posted March 14, 2020 #FujiNet What do we have here? @jeffpiep has been hard at work implementing #Atari 1020 plotter emulation! This is awesome! 4 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted March 14, 2020 Author Share Posted March 14, 2020 Status for 2020-03-14: * @jeffpiep is hard at work implementing the Atari 1020 plotter emulation. This emulation is unique in that the output is not PDF, but an SVG. * There are a few more testers of ESP32 boards popping up, and bug reports are coming in. * The TNFS filesystem implementation is accidentally sending back successes when all retries have been exhausted. It comes from an inconsistent mis-match of return values that happened when we ported the code to use the standard Arduino FS API. Whoops. * In addition, the TNFS retry timings need to be further tuned, as currently there are more retry attempts than there is time for in the SIO timeout allotted by the OS for most disk operations (5 retries, 5000ms, 25 seconds, compared to 15 seconds for the OS.), We need to decrease the time between timeouts, and do more retries. To this end, I have moved timeout values to #define constants in lib/sio/sio.h * The N: handler is being debugged, lots of work needing to be done there. OPEN works now, after a complete rewrite of the device spec tokenizer. Other operations currently fail due to stack smashing. I need to re-think how buffers are passed between protocol functions. Any insight anyone can offer for this, please check out the code and dip into sio/network* I did write a theory of operation in the wiki, if anyone is interested. This is the muck of the project, we’ve done the huge flurry of “ain’t it cool?!” demos, and now we’re rolling up our sleeves, and working through the mix of technical debt and functionality testing. Not to mention writing unit tests -Thom 3 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted March 17, 2020 Author Share Posted March 17, 2020 #Atari8bit #FujiNet one of the newly added features to the #platformio version of the firmware is "Disk Rotate" which rotates disk images into the next contiguous drive slot clockwise. This allows programs that take up more than one disk, but only support a single disk drive, to work with #FujiNet. 5 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted March 17, 2020 Author Share Posted March 17, 2020 I work out, every day using #Atari's Personal Fitness program. Previously, I had kept my copy of both the program and data disk that I used every day on two separate floppies, because Personal Fitness only supported one disk drive. With #FujiNet, I can put the program and data disks in the first two drive slots, and rotate them when needed, to run the program entirely from my local file server or from #FujiNet's local file storage. 2 Quote Link to comment Share on other sites More sharing options...
jamm Posted March 17, 2020 Share Posted March 17, 2020 1 hour ago, tschak909 said: I work out, every day using #Atari's Personal Fitness program. Previously, I had kept my copy of both the program and data disk that I used every day on two separate floppies, because Personal Fitness only supported one disk drive. With #FujiNet, I can put the program and data disks in the first two drive slots, and rotate them when needed, to run the program entirely from my local file server or from #FujiNet's local file storage. No one could ever doubt your dedication to Atari 8bits ? 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted March 17, 2020 Author Share Posted March 17, 2020 If anyone wants to help with performance tuning of the read cache on #FujiNet, take a look at this issue: https://github.com/FujiNetWIFI/atariwifi/issues/162 I believe the read cache can be more intelligently implemented as a ring buffer, which can consistently be appended as sectors are pushed out. Details in the ticket, including link to source code of current implementation. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted March 21, 2020 Author Share Posted March 21, 2020 #FujiNet uses TNFS, which principally communicates over UDP. This means that the firmware has to be able to handle networks with less than ideal conditions which can cause timeouts, dropped packets, and even duplicate packets. I have spent the last week refactoring the TNFS code to simplify it, and provide a single code path for sending packets, receiving responses, and handling timeouts. This allowed me to better see what was happening and to alter the retry logic over the last day and a half to make it more robust, using a test network generously provided by a user who built his own #FujiNet! more status reports are coming soon! 2 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted March 22, 2020 Author Share Posted March 22, 2020 (edited) For anyone who wants to contribute, another easy enhancement is needed to improve TNFS network performance when the cache is off (e.g. during development): An enhancement ticket: https://github.com/FujiNetWIFI/atariwifi/issues/165 Given a sector number coming into sio_read(): https://github.com/FujiNetWIFI/atariwifi/blob/master/platformio/FujiNet/lib/sio/disk.cpp#L44 Determine if the sector to be read is the very next sector. If yes, DO NOT SEEK, otherwise perform a seek. Sector size needs to be taken into account, as well (first three sectors 128 bytes, we do not currently account for 256 byte or 512 byte sectors). For TNFS, this will remove one round trip communication, and speed up network access. Edited March 22, 2020 by tschak909 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted March 22, 2020 Author Share Posted March 22, 2020 #Atari8bit #FujiNet Currently for development, disk image selection is very simplistic. No subdirectories, and a max of 16 entries returned. What should we do going forward? How should it look to the user? Who can help make a better implementation? Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.