apc Posted January 31, 2022 Share Posted January 31, 2022 On 1/29/2022 at 2:34 AM, mozzwald said: Now we need that atr with the fast loader autotnfs-zx0.atr sure ? 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted January 31, 2022 Share Posted January 31, 2022 @trent I think we'll fold this into the main config program. -Thom 2 Quote Link to comment Share on other sites More sharing options...
xxl Posted February 1, 2022 Share Posted February 1, 2022 there is a new version of zx0 v2 compressor - new version of decompressor on my website 1 Quote Link to comment Share on other sites More sharing options...
E474 Posted February 1, 2022 Share Posted February 1, 2022 Hi, I tried the autotnfs-zx0.atr on my FujiNet-PC setup (on a RPi 1), but didn't see any difference, apart from the (new) purple background. I'm not actually sure what the new atr provides, what would be a good test? Specifically, what operations are now hi speed, etc.? Also, I thought I would try a disk image with the FujiNet-PC that I knew would boot at high speed (an AlphaLoad menu disk, attached), but it refuses to boot past the first few sectors. I also tried it on the RPi 1 with @HiassofT's atariserver: atariserver -C test_alpha.dd.atr But got the same failure to boot, so I'm guessing it might be a hardware issue/setting on my RPi? I'm using the P5 header for CTS (pin 5) setup with a 26 pin GPIO header, using the dt-overlay described in README.RPi in atarisio-210714.tar.gz on https://www.horus.com/~hias/atari/atarisio/ From what I can tell, I should be able to get Hi Speed IO working on a RPi with atariserver, at least according to: A benefit of the Raspberry Pi UART and most USB serial adapters is that they can match the non-standard Pokey baudrates closely enough to get low Pokey divisors and Happy/Speedy ultraspeed modes working. -- which is from the README.md on https://github.com/HiassofT/AtariSIO The AlphaLoad disk works fine with an emulator (atari800 version 4.1.0). Not sure how to proceed/trouble shoot the issue. Can anyone with a "real" ESP-32 FujiNet confirm that the AlphaLoad disk will boot? Maybe @apc or someone else can see if it boots on a FujiNet-PC on a Raspberry Pi (or other Linux box)? Thanks! test_alpha.dd.atr Quote Link to comment Share on other sites More sharing options...
mozzwald Posted February 1, 2022 Share Posted February 1, 2022 19 minutes ago, E474 said: I'm not actually sure what the new atr provides, what would be a good test? Specifically, what operations are now hi speed, etc.? The high speed loader just boots the config disk faster. The only difference with this config vs the config currently in firmware is the new option to follow tnfs host links. You can browse the fujinet.online tnfs 'links' dir to test out the new feature. Quote Link to comment Share on other sites More sharing options...
E474 Posted February 1, 2022 Share Posted February 1, 2022 Thanks, I will try the links feature out tomorrow, also build FujiNet PC on a newer generation RPi (3 or 4), just in case that makes a difference. Quote Link to comment Share on other sites More sharing options...
apc Posted February 1, 2022 Share Posted February 1, 2022 9 hours ago, E474 said: I tried the autotnfs-zx0.atr on my FujiNet-PC setup (on a RPi 1), but didn't see any difference, apart from the (new) purple background. for zx0 version - no difference in what it does, but how it get loaded (HSIO and inline zx0 decompression) 9 hours ago, xxl said: there is a new version of zx0 v2 compressor - new version of decompressor on my website yup, noticed some time ago, it's on the list 9 hours ago, E474 said: Can anyone with a "real" ESP-32 FujiNet confirm that the AlphaLoad disk will boot? Maybe @apc or someone else can see if it boots on a FujiNet-PC on a Raspberry Pi (or other Linux box)? Tested to boot with Atari+FujiNet@ESP and Atari+FujiNet-PC@Linux box - no success Test with Altirra+FujiNet-PC revealed... CUSTOMDEV: Disk STATUS CUSTOMDEV: Disk READ 1 CUSTOMDEV: Disk READ 4 CUSTOMDEV: Disk READ 5 CUSTOMDEV: NetSIO from Atari @ 52640 CUSTOMDEV: Disk READ 6 CUSTOMDEV: Disk READ 6 CUSTOMDEV: NetSIO to Atari @ 125000 CUSTOMDEV: Disk READ 6 CUSTOMDEV: Disk READ 6 CUSTOMDEV: NetSIO to Atari @ 19200 CUSTOMDEV: Disk READ 6 CUSTOMDEV: Disk READ 6 CUSTOMDEV: NetSIO to Atari @ 125000 ... @E474 that disk is trying to talk on fixed speed 52kb. In WebUI you can change the pokey divisor down to 10 (in HSIO settings) to match the speed. Quote Link to comment Share on other sites More sharing options...
E474 Posted February 1, 2022 Share Posted February 1, 2022 Hi @apc, Thanks for trying the disk out. I changed the HSIO setting to 10 and restarted the FujiNet-PC (via the webpage). When I booted the FujiNet config program, it loaded at maybe 1/3 normal speed (according to progress bar). When I tried to boot the test_alpha.dd.atr disk, it still wouldn't boot. This is all from the SD card, so there aren't any network latencies involved. I also got the same problem loading the AlphaMenuUtilitiesSideA.atr (attached) which I saved from post #17 of this thread: Courtesy tagging @tschak909 as this might be a FujiNet bug? AlphaMenuUtilitiesSideB.zip AlphaMenuUtilitiesSideA.zip Quote Link to comment Share on other sites More sharing options...
trent Posted February 1, 2022 Share Posted February 1, 2022 16 hours ago, tschak909 said: @trent I think we'll fold this into the main config program. -Thom Oh, ok, cool :-). I had some whitespace/tab issues that my editor introduced that I've fixed in my repo so it should line up with yours. Anything you need me to do in github or will you just grab the changes from my forked repo? Trent. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted February 1, 2022 Share Posted February 1, 2022 just do a PR and I'll go from there. -Thom Quote Link to comment Share on other sites More sharing options...
tschak909 Posted February 1, 2022 Share Posted February 1, 2022 Merged! -Thom 1 Quote Link to comment Share on other sites More sharing options...
E474 Posted February 2, 2022 Share Posted February 2, 2022 Hi, I tried the alpha load disk with @HiassofT's atariserver at HSIO rate 10, and it worked without issue (so the Raspberry Pi hardware is good): atariserver -S 10 -C sd/test_alpha.dd.atr When I tried the original and high speed+zx0 autoruns, neither could load the Alpha Load disk, and both seemed to have problems loading the FujiNet config program. I had already set the HSIO value to 10 in the web-page. Logs attached of both attempts: I'm kind of stuck as I don't have an ESP32 based FujiNet to test with, and am new to actually using the FujiNet, so am unsure if this is in part user error. Hope this helps! alpha_load_boot_original_loader.txt alpha_load_boot_hs.txt Quote Link to comment Share on other sites More sharing options...
apc Posted February 3, 2022 Share Posted February 3, 2022 @E474 I will take a look. Let's move to another thread for this topic. Quote Link to comment Share on other sites More sharing options...
+x=usr(1536) Posted February 5, 2022 Author Share Posted February 5, 2022 On 1/27/2022 at 8:20 AM, trent said: Any news on this? I'm looking to do something similar - much simpler, but I don't want to duplicate effort. From my end, no. After nixing the LDAPfuse idea, time and other new and shiny things have kept me away from it. Quote I'm just thinking support could be added for gopher style directories to TNFS. This would allow site owners to provide browsable lists of TNFS hosts that a user could jump to. This I am 100% in agreement with, and an ARCHIE server or two would also be useful. However, there really does need to be a way for a directory of TNFS servers to exist that every FujiNet can point to. One thing I have heard in relation to the FujiNet is that users have a hard time finding more than just the default servers that it ships with, or believe that those servers are all that both are and ever will be out there. Granted, there is @mrrobot's FujiNet Status Page - but there's no good way for new users to know that it exists. It also can't be accessed directly from the FujiNet. Quote As a POC this would take the form of a specially formatted filename that the built-in TNFS client recognizes (i.e. <host>:<port>:<site name>), but I think the right way to do it is to add support for this to TNFS. I'll strongly recommend against filename formatting. While it could work, the possibility of having to deal with filesystems not liking (or escaping) certain characters properly, etc. that point to other TNFS URIs has the likelihood of becoming a problem. Better IMHO to treat a certain type of URI as equivalent to a hyperlink and follow it. Maybe use '.tnfs' as a resource extension, where it's just a text file with the URI inside of it? This would also allow for registering the MIME type with an HTTP server, which would open the possibility of browser-based TNFS access for modern clients. Note that I did see this working a little further back in the thread ? By no means am I knocking the effort or idea; it's just my $0.02. Quote Link to comment Share on other sites More sharing options...
+x=usr(1536) Posted February 5, 2022 Author Share Posted February 5, 2022 On 1/27/2022 at 9:29 AM, tschak909 said: If you want to see the other side of it, this is from the firmware side: https://github.com/FujiNetWIFI/fujinet-platformio/blob/master/lib/device/sio/fuji.cpp Config basically makes calls to the fuji.cpp device. Dumb question: I'm looking at the list of commands defined in fuji.cpp, and wanted to ask if there's a specific range to steer clear of or use? It looks like the defines for the current command set stop at 0xD6, so would 0xD5 be the next one to use, or could any unused 1-byte value be selected? Have an idea for something and want to play with it a bit this evening. Zero promises ? Quote Link to comment Share on other sites More sharing options...
tschak909 Posted February 6, 2022 Share Posted February 6, 2022 0xD5 is fine. -Thom 1 Quote Link to comment Share on other sites More sharing options...
+x=usr(1536) Posted February 6, 2022 Author Share Posted February 6, 2022 Spitballing an idea: a dedicated TNFS host slot (slot 0?) that contains a user-definable URI pointing to the 'master' TNFS directory server. This would keep the eight existing slots open for SD card access and speed-dialing favourite servers as it is now. My thought is that slot 0 could be used as the default destination for TNFS browsing, switchable between it and the standard view depending on what the user wanted to see at boot or during a session. The concern I have with this approach is that it would require changes to CONFIG, and last I checked there wasn't any breathing room there. I'm trying to keep all of this as backend-centric as possible in order to prevent CONFIG from ballooning, but am not 100% certain that this approach would fit. The master TNFS server would also have to sit somewhere with high availability, meaning an AWS / Azure / etc. cloud or similar. I can offer testing from our home fibre circuit, but that can't be a long-term solution. 1 Quote Link to comment Share on other sites More sharing options...
mozzwald Posted February 6, 2022 Share Posted February 6, 2022 11 minutes ago, x=usr(1536) said: The master TNFS server would also have to sit somewhere with high availability, meaning an AWS / Azure / etc. cloud or similar. I can offer testing from our home fibre circuit, but that can't be a long-term solution. fujinet.online is is running on a Digital Ocean droplet. If you come up with a solution we can host it there. 1 Quote Link to comment Share on other sites More sharing options...
trent Posted February 10, 2022 Share Posted February 10, 2022 (edited) On 2/5/2022 at 3:07 PM, x=usr(1536) said: I'll strongly recommend against filename formatting. While it could work, the possibility of having to deal with filesystems not liking (or escaping) certain characters properly, etc. that point to other TNFS URIs has the likelihood of becoming a problem. Better IMHO to treat a certain type of URI as equivalent to a hyperlink and follow it. Maybe use '.tnfs' as a resource extension, where it's just a text file with the URI inside of it? This would also allow for registering the MIME type with an HTTP server, which would open the possibility of browser-based TNFS access for modern clients. Note that I did see this working a little further back in the thread ? By no means am I knocking the effort or idea; it's just my $0.02. I admit to having the same concerns when I was suggesting it, and was thinking about more complicated schemes. I got comfortable with it because it is very low friction, both in terms of adding support in the client and for TNFS operators. I went down the rabbit hole of having CONFIG be able to render files, so that something like an index resource could be created (I'm still working on this, but for other reasons...). That would have been a big change to the client and required a firmware change. Not touching the firmware has the advantage that this is easy to try & easy to back out of if people don't end up liking it or something better comes along. I suspect that is why Tom threw it in - low risk ? [Edit] Not to say I don't think it is the "right" solution for this problem. Like I said, it is easy to adopt both on client and server, and I think it's lack of complexity is probably appropriate for the platform. If the idea is to start having HTTP like functionality, there is HTTP and leveraging the ESP32, not sure that is right for CONFIG. Edited February 10, 2022 by trent Quote Link to comment Share on other sites More sharing options...
+x=usr(1536) Posted February 10, 2022 Author Share Posted February 10, 2022 12 minutes ago, trent said: I admit to having the same concerns when I was suggesting it, and was thinking about more complicated schemes. Ditto. KISS is the principle I've been trying to adhere to, because it's easy to let imagination run slightly too wild ? 12 minutes ago, trent said: I got comfortable with it because it is very low friction, both in terms of adding support in the client and for TNFS operators. I went down the rabbit hole of having CONFIG be able to render files, so that something like an index resource could be created (I'm still working on this, but for other reasons...). That would have been a big change to the client and required a firmware change. Agreed that it is a low-drag way of doing it. More on that a bit further down. 12 minutes ago, trent said: Not touching the firmware has the advantage that this is easy to try & easy to back out of if people don't end up liking it or something better comes along. I suspect that is why Tom threw it in - low risk ? True. By the same token, however, we should (IMHO) be taking the longer-term into account as well. Not saying that you're seeing this as a temporary measure by any means, but given that FujiNet is now multi-platform, it makes sense to begin looking at how decisions made on one side can affect the others as a whole. 12 minutes ago, trent said: [Edit] Not to say I don't think it is the "right" solution for this problem. Like I said, it is easy to adopt both on client and server, and I think it's lack of complexity is probably appropriate for the platform. If the idea is to start having HTTP like functionality, there is HTTP and leveraging the ESP32, not sure that is right for CONFIG. I hear you re: HTTP-alike functionality. Frankly, that is something that I think would be overkill to try to implement in CONFIG and really isn't needed to be there since the ESP32 could potentially handle that sort of thing and just pass the results along to CONFIG. This is where I was thinking that parsing the .tnfs file for the URI could work: have the ESP32 retrieve the file, check its contents, and pass the URI on to CONFIG to handle the actual change to and display of the URI's contents. This is definitely a case where there's no better or worse way to achieve the end result, because all of them have relative pros and cons. 1 Quote Link to comment Share on other sites More sharing options...
+x=usr(1536) Posted April 20 Author Share Posted April 20 On 1/28/2022 at 6:31 PM, trent said: You can add 'links' to your own tnfs site by creating files in the form "+<hostname>". These will appear as ordinary files to normal Fujinet users. Just curious - does anyone know what happened to this feature? It was working at one time, but now appears to not be. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted April 20 Share Posted April 20 5 minutes ago, x=usr(1536) said: Just curious - does anyone know what happened to this feature? It was working at one time, but now appears to not be. Where was it implemented? in firmware or in CONFIG? -Thom Quote Link to comment Share on other sites More sharing options...
+x=usr(1536) Posted April 20 Author Share Posted April 20 11 minutes ago, tschak909 said: Where was it implemented? in firmware or in CONFIG? -Thom Looks like it was in CONFIG, and out of a forked repo: Quote Link to comment Share on other sites More sharing options...
tschak909 Posted April 20 Share Posted April 20 2 minutes ago, x=usr(1536) said: Looks like it was in CONFIG, and out of a forked repo: Crap, then it may have fallen out, when we finally shifted to using the common config. -Thom Quote Link to comment Share on other sites More sharing options...
+x=usr(1536) Posted April 20 Author Share Posted April 20 No, I was mistaken. It's still appearing in diskulator_select.c (line 363): Spoiler // Handle if the selection is a TNFS host else if (context->filename[0]=='+') { // set the current host context and replace host_slot 8 with the // selected TNFS host. strcpy(context->host, context->filename+1); strcpy(context->hostSlots.host[7], context->host); context->host_slot = 7; fuji_sio_write_host_slots(&context->hostSlots); // update directory to point root and clear the filename strcpy(context->directory, "/"); memset(context->filename,0,sizeof(context->filename)); // mount the selected host context->state=DISKULATOR_SELECT; fuji_sio_mount_host(context->host_slot,&context->hostSlots); if (fuji_sio_error()) { error(ERROR_MOUNTING_HOST_SLOT); wait_a_moment(); context->state=CONNECT_WIFI; } *ss=DONE; } So... Not sure what's up. Quote Link to comment Share on other sites More sharing options...
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.