Directory Service for publicly-accessible #FujiNet sites

[apc]

On 1/29/2022 at 2:34 AM, mozzwald said:

Now we need that atr with the fast loader  

autotnfs-zx0.atr

 

sure ?

[tschak909]

@trent I think we'll fold this into the main config program.

 

-Thom

[xxl]

there is a new version of zx0 v2 compressor - new version of decompressor on my website

[E474]

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

[mozzwald]

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.

[E474]

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.

[apc]

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.

 

[E474]

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

[trent]

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.

[tschak909]

just do a PR and I'll go from there.

-Thom

 

[tschak909]

Merged!

-Thom

[E474]

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

[apc]

@E474 I will take a look. Let's move to another thread for this topic.

[+x=usr(1536)]

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.

[+x=usr(1536)]

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 ?

[tschak909]

0xD5 is fine.

-Thom

 

[+x=usr(1536)]

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.

[mozzwald]

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.

[trent]

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

[+x=usr(1536)]

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.

[+x=usr(1536)]

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.

[tschak909]

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

 

[+x=usr(1536)]

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:

 

 

[tschak909]

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

[+x=usr(1536)]

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.