trent

You can't really say that - you no longer own the data that backs this site, you work for the company that owns it. A company with a spotty reputation in the community, if we're all being honest here. This was a good move for Atari IMO but the future of this site is now firmly in their hands.

This is the most interesting & positive thing that any owner of the Atari brand has done since they went off-script w/ JTS in the late 90s.

Hi @tschak909 Just saw this. That was a pretty simple change made on the config side, if no one has done it yet I'm happy to do another PR with the changes applied to the new config code. I also have a firmware-side change that implements the gopher-like menu functionality that I had originally talked about in a thread here. It is a small change, backwards compatible with the existing config applications, but can be activated with a small change on the config side. I'll try and find a few minutes to throw up a video of how it works to gauge interest.

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.

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.

My comment on the code sprang from working with it - I had assumed that making the change I was thinking of was going to be difficult, I was pleasantly surprised to find things were well laid out and easy to understand. Looks like with the new code you are shooting to be platform agnostic which has added some indirection. Still looks straight forward though. It is interesting to see what you are expecting the "lowest common denominator" to be. I know those are hard decisions to make, they end up being long lived :-).

My TNFS server is hosted on a well-worn AWS free tier instance so I guess mileage may vary. I tried from your site and it works well - thanks! A proper implementation would not override the #8 host slot, but that will require some small changes to the firmware, which would make it a lot harder to try out the POC so I'll leave it as is for now. The link format could probably be more well thought out to make sure the format is unlikely to collide with real filenames. There isn't much in the way of code changes, but I'm keeping them here temporarily: https://github.com/diggerbonk/fujinet-config/tree/file_links_poc

I read through the #meatballs thread - much bigger idea than mine ? I like that Fujinet is as simple as can be - plug it in, add a couple TNFS hosts, and you are off to the races. TNFS seems capable of delivering the sort of discovery functionality that is being discussed in this thread, and has the advantage that it is already part of the Fujinet ecosphere. The default TNFS host list can be seeded with key sites, and from there a user can jump off to other sites. Curating and organizing site lists would be up to TNFS operators, and the important ones would be baked into the firmware or referenced from one of the sites that is. I've updated the POC if anyone would like to try it out themselves: * Adding 54.88.43.54 to your TNFS host list (don't add it as host #8, that slot is used by the demo) * open 53.88.43.54 and download the 'autorun.atr' image, boot into it (this will not overwrite your config or firmware, you just load it like any other disk image) * When Fujinet comes back up, open the 54.88.43.54 host again and browse to the "/sites" directory * Sites will have an up arrow icon to the left. Select a site - the browser will open the site and it will be set as #8 in your TNFS host list. 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.

Thanks! I'll poke my head in later tonight. I'm tvi910.

Yeah - there isn't much code changed. Whoever wrote/conceived of the config shell program did a fantastic job making a useful and intuitive interface and the code is very easy to understand. I've just for a while wished it had the capability to jump to different hosts like this.

There isn't much to it, other than access to a TNFS server is required. 1) Put the 'autorun.atr' file I attached in the previous post on your TNFS server. 2) Also on your TNFS server, create an empty file starting with a '+' and ending in the TNFS host you want to link to (e.g. "+fujinet.pl") 3) Boot up fujinet with the default config program 4) Navigate to the new 'autorun.atr', mount it on drive one and reboot (you will now be using the modified config program) 5) Navigate to the special file you created (e.g. "+fujinet.pl") and select it. This will cause you to jump to fujinet.pl, and if you look at your host list, #8 will be "fujinet.pl" I'm working on a couple of additional changes that hide the magic prefix and show a little globe icon or some such in the file list, and doesn't hijack slot #8. I might have that ready tonight, if not then over the weekend.

First go attached. If a file starts with a '+', it assumes the rest is a fujinet tnfs hostname, writes it to slot 8 and opens it. Next iteration I'll get rid of the slot 8 stuff - looks as if that is going to require messing with the firmware. autorun.atr

Hmm. I was hoping for the POC I could avoid messing with the firmware, but I can see this will be more of a hack than I'd thought. When the host selection is made the current host list and the selection index is passed to fuji_sio_mount_host(), which means upon selection I'm going to have to have to fudge it by replacing one of the host slots ahead of that. For now I'm just going to hijack slot 8 and feel dirty about it. If that goes smoothly I'll dig a bit deeper for a better solution.

Thanks, I'll give it a go then. Looks like all the magic happens between these couple of files: https://github.com/FujiNetWIFI/fujinet-config/blob/master/src/diskulator_select.c https://github.com/FujiNetWIFI/fujinet-config/blob/master/src/diskulator_hosts.c Most time consuming part is going to be setting up a build environment.

Any news on this? I'm looking to do something similar - much simpler, but I don't want to duplicate effort. 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. 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.