fujinet #FujiNet - a WIP SIO Network Adapter for the Atari 8-bit

[tschak909]

#atari8bit #FujiNet While text translation options can be passed in via the AUX2 parameter in OPEN, NTRANS gives the opportunity to set this parameter e.g. when accessing network files, allowing text formats to be easily converted between Atari and other computer text formats.

 

 

[tschak909]

@mozzwald has begun the final assembly of the first 50 units!

 

This means that I need to bring up testing.

 

Currently, the tests I've written up thus far, are here:

https://github.com/FujiNetWIFI/fujinet-platformio/wiki/Testing-Plan

 

I will continue writing up tests as I think of them, and since we're heading in that direction, that's where I will be spending my time, pausing on the N: device, for now.

 

CONFIG is currently usable at this point in time, but things can be better, RIGHT NOW:

• only supports one page of file listing, 16 entries.
• 36 characters max for the full path of a filename.
• ATR images only at the moment, no ATX yet, no direct loading of XEX files, yet.

Anybody who can help make this better, feel free to jump in and help.

 

P: is pretty much feature complete, @jeffpiep is working on Okimate 10 support, but we already support a huge range of printers, and I'm using it almost daily for listings.

 

R: is pretty much feature complete, I tried to improve support so that a single line BBS can be run off it, but will need to work with people who give a damn about this, to make it better.

 

SAM voice support is in there, it works.

 

N: support is on-going, it's usable, but understand that the code for this is on-going and will be for some time (due to its complexity).

 

I ask, of everyone who is getting a unit, to please run the testing plans, submit issues to the issues tracker (same place as the testing plan above), and above all to exercise an infinite amount of patience (that goes for those of us testing, and developing), we will make the best #FujiNet we can, but it all depends on the priorities of its users, while I am constantly showing what's possible, we need to know what you all will use most, and also what's missing.

 

Thanks so much for your interest, this project has been a blast, so far.

-Thom

[tschak909]

Added the ability to re-set the SSID by going into the Configuration page.

 

which bounces back to the SSID page.

 

 

-Thom

[tschak909]

I am now focusing on the CONFIG program, until further notice.

 

It needs, first and foremost, a massive re-factor, as it has become a massive bowl of pasta.

 

(for anyone who wants to see CONFIG as it is right now, pre-refactor: https://github.com/FujiNetWIFI/fujinet-config/blob/master/src/diskulator.c)

 

What does this involve?

 

* removing all unneeded global state

* splitting up the large functions that comprise the program (diskulator_* config_*) into much smaller idempotent functions.

* making typedefs out of union/structs to make them easier to reference

* remove the gotos that have crept into the code

* rework flow of program to remove bugs that crept up due to quick fixes.

* document the damned thing

 

Not fun, but the program has reached the point where I must do this, to make the program readable again, as I need to add one big chunk of functionality.

 

Why did it get like this? The program was written quickly so that we could have enough to get the fujinet configured and up so that we could write the rest of the functionality.

 

There was also a great deal of premature optimization (global state and lots of weird re-use to minimize code space), and as Don Knuth always pointed out, "premature optimization is the root of all evil."

 

So I have to fan it all out, make it clear and concise, get the program functionally complete, and then it can be optimized (within reason, the program does not have an urgent need to be fast or small, except maybe to be able to fit and run on 16K machines...)

 

-Thom

Edited July 23, 2020 by tschak909

[tschak909]

#FujiNet software development refactoring theme song:

 

[tschak909]

#FujiNet #Atari8bit Here we see the CONFIG program being re-factored into something much easier to maintain and read. I take a small dive through the code and show what's being changed, and why.

 

[+DrVenkman]

I just got my hardware module today from @mozzwald and I'm fooling around getting things configured. So far I've got my LAN ID'd and connected, and I can access remote TNFS hosts. I've pulled my SD card from my SDrive-MAX into the thing, created a host called "SD" and can browse (some) of my ATR files, but it seems limited to one screen's worth, and I get a lot of errors when I try to mount disk images. Unsure if this is due to current firmware limitations or an issue with my card. I'll pick up a new SD card this weekend and start clean going forward in any case.

I've also downloaded the TNFS applications for Windows and pointed it at a test folder of about a dozen ATRs but although I see access messages in my Windows shell when the Config file accesses the server, Config on the FujiNet just shows an empty screen. Any of the existing early testers or developers use Windows who might be able to get me going in the right direction there?  

Thanks.

[tschak909]

2 minutes ago, DrVenkman said:

I just got my hardware module today from @mozzwald and I'm fooling around getting things configured. So far I've got my LAN ID'd and connected, and I can access remote TNFS hosts. I've pulled my SD card from my SDrive-MAX into the thing, created a host called "SD" and can browse (some) of my ATR files, but it seems limited to one screen's worth, and I get a lot of errors when I try to mount disk images. Unsure if this is due to current firmware limitations or an issue with my card. I'll pick up a new SD card this weekend and start clean going forward in any case.

I've also downloaded the TNFS applications for Windows and pointed it at a test folder of about a dozen ATRs but although I see access messages in my Windows shell when the Config file accesses the server, Config on the FujiNet just shows an empty screen. Any of the existing early testers or developers use Windows who might be able to get me going in the right direction there?  

Thanks.

Hey Herb! Glad you got your unit, and it's working!

 

Right now CONFIG only does one screen's worth of disk images. This is because we needed to do changes to the TNFS protocol to add directory seeking, which have now been folded into our fork of TNFSD (https://github.com/FujiNetWIFI/spectranet/tree/master/tnfs/tnfsd), and now need to be added into CONFIG. This is why I am refactoring and cleaning up CONFIG, as I need to make lots of changes that I've been putting off (because I've been implementing lots of other stuff), and can no longer kick that can down the road. So yes, this will be dealt with.

 

If you have disk images that will not load, attach them to this ticket: 

https://github.com/FujiNetWIFI/fujinet-platformio/issues/314 .. we will analyze them together and get them to work.

 

ATX disk support is forthcoming. We have all the info, and two reference implementations to draw from, so it will get done.

 

As for the TNFS server, Thanks for pointing out that we need to fix the link to the TNFS server, as we have now diverged from the original implementation (to improve performance and make it usable in the way we need it), @jamm has built binaries for Windows and Linux here: https://github.com/FujiNetWIFI/spectranet/tree/master/tnfs/tnfsd/bin (as an aside, it's on my list to open a dialog with the TNFS folks upstream to discuss folding in our improvements)

 

It's freaky booting things over the ether, isn't it?

 

-Thom

 

 

 

 

[+DrVenkman]

17 minutes ago, tschak909 said:

As for the TNFS server, Thanks for pointing out that we need to fix the link to the TNFS server, as we have now diverged from the original implementation (to improve performance and make it usable in the way we need it), @jamm has built binaries for Windows and Linux here: https://github.com/FujiNetWIFI/spectranet/tree/master/tnfs/tnfsd/bin (as an aside, it's on my list to open a dialog with the TNFS folks upstream to discuss folding in our improvements)

 

It's freaky booting things over the ether, isn't it?

It's amazeballs.

 

I'll try out the new Win binary for the TNFS server.

 

I'm just fooling around haphazardly today in my excitement but I'll try working through all the suggested tests in order through the week/upcoming weekend.

[Fierodoug5]

If you are getting mount errors, it is usually cause the filename is too long. That's the only times I have ever gotten mount errors. Rename to something shorter and it should mount fine.

[tschak909]

There is a current limitation of 36 characters for both path + filename at the moment. This is yet another reason for the refactor.

 

(current implementation needs to keep filenames for the page in memory, with proper seek/telldir support as alluded to above, I can remove that limitation and increase filename limit to 256 characters for path + filename.)

 

-Thom

[+DrVenkman]

The new Windows binary for TNFSD.exe works great.  

 

(Booted locally from my Win10 laptop. I need to get one of my RPi boxes back into action as a dedicated file server.)

 

[tschak909]

Excellent. Yup, it works great on the RPi, I have one just sitting on a corner of my desk as my TNFS file server.

 

-Thom

[+DrVenkman]

So I ran into an odd issue with The Print Shop - I can't get it to boot over FujiNet, either from the internet or from my own TNFS server. It hangs on the title screen after what sounds like most of a regular boot. However, I *was* able to boot a cracked copy of The Print Shop from my Incognito's SIDE Loader, then print to the FujiNet virtual Epson printer.  

 

I've tried all kinds of combos in my Incognito BIOS - XL/XE hardware, Colleen hardware, extended memory or stock, PBI BIOS and high-speed I/O on and off ...  Can't get it to boot off the network. And to be clear, the ATRs I'm using on my local server are copies of the very same ATRs that will boot from the SIDE Loader.  

[jamm]

1 minute ago, DrVenkman said:

So I ran into an odd issue with The Print Shop - I can't get it to boot over FujiNet, either from the internet or from my own TNFS server. It hangs on the title screen after what sounds like most of a regular boot. However, I *was* able to boot a cracked copy of The Print Shop from my Incognito's SIDE Loader, then print to the FujiNet virtual Epson printer.  

 

I've tried all kinds of combos in my Incognito BIOS - XL/XE hardware, Colleen hardware, extended memory or stock, PBI BIOS and high-speed I/O on and off ...  Can't get it to boot off the network. And to be clear, the ATRs I'm using on my local server are copies of the very same ATRs that will boot from the SIDE Loader.  

Would you either upload that particular ATR or get an MD5 checksum so we can be sure we're using the same version when we're testing to see what the issue is?

 

[+DrVenkman]

Just now, jamm said:

Would you either upload that particular ATR or get an MD5 checksum so we can be sure we're using the same version when we're testing to see what the issue is?

 

Sure. But the same hang occurs even when I load the version from atari-apps.irata.online as recommended in the Github test sequence. 

 

Just for reference though, these cracks work when loaded from the Incognito SIDE Loader but do not work when loaded from a local TNFS server. However, these files do work when loaded from the FujiNet device's SD card. 

Print Shop (Side A).atr Print Shop (Side B).atr

[tschak909]

Wow, hm, I load print shop from the network all the time. I'll test in a bit (I currently have an rpi4 on my bench getting it ready for Nina)

-Thom

 

[+DrVenkman]

7 minutes ago, tschak909 said:

Wow, hm, I load print shop from the network all the time. I'll test in a bit (I currently have an rpi4 on my bench getting it ready for Nina)

-Thom

 

Yeah it hangs at the same place when I load from irata.online or from my own little server directory. The same ATR that hangs when I load it from my LAN works when loaded from the SD card.

 

 

Maybe a quirk of the Incognito 800? Like I said, I've tried a lot of different settings without luck. I'll test it with my 1088XEL tonight or tomorrow, and an unmodified 800 and 1200XL tomorrow too.

 

 

 

[tschak909]

Ok, so, I've now verified that Print Shop is now failing, now that the read cache has been introduced.

 

-Thom

 

[+DrVenkman]

3 minutes ago, tschak909 said:

Ok, so, I've now verified that Print Shop is now failing, now that the read cache has been introduced.

 

-Thom

 

I'm good a breaking things.

 

(I believe you software boffins refer to this as a "regression." ? ) 

 

[tschak909]

Good. We need that. There is lots to break.

 

Don't worry, we'll get it all solid.

 

 

[tschak909]

We had a tester mention that the DOS 2.0 disk image provided for the local SD flash test:

https://github.com/FujiNetWIFI/fujinet-platformio/wiki/Testing-local-SD-Card-Storage

 

was corrupted.

 

This has been verified, and a replacement DOS 2.0S image has been placed inside the ZIP and tested, and noted on the test page.

 

Thanks! 

 

(p.s. I posted onto wrong thread, oops)

-Thom

[jamm]

6 hours ago, DrVenkman said:

I'm good a breaking things.

 

(I believe you software boffins refer to this as a "regression." ? ) 

 

Thanks for your breakage, @DrVenkman!  I've just posted a new commit to the fujinet-platformio project that should take care of the Print Shop issue.  It was reading to EOF, and there was a subtle bug with the way the caching code handled that situation. I also tweaked the TNFS timeout to make it less likely that it'll stop loading if some packets get lost while flying through the air.

 

 

[_The Doctor__]

There was an issue already mentioned about the buffer in some of Thom's postings, not detecting the end or some such thing...if it isn't that then...

Sorry but certain cracks still rely on SIO timings, they aren't fully cracked... any faster drives, or buffering mods (track/ disk or otherwise) will make incomplete software cracks that don't have timing checks removed fail... let's make sure that we don't hobble FujiNet over things that won't run from track buffered drives or from the multitude of mass storage devices from back in the day... buffering should be an option just like unhappy mode, hsio toggle, etc. on other floppy mods and mass storage devices. Best to make sure cracks already work on all devices before getting our programmers running in circles.

 

Edited July 28, 2020 by _The Doctor__

[tschak909]

2 minutes ago, _The Doctor__ said:

Sorry but certain cracks still rely on SIO timings, they aren't fully cracked... any faster drives, or buffering (track/ disk or otherwise) render incomplete software cracks that don't have timing checks removed will fail... let's make sure that we don't hobble FujiNet over things that won't run from track buffered drives or from the multitude of mass storage devices from back in the day... buffering should be an option just like unhappy mode, hsio toggle, etc. on other floppy mods and mass storage devices. Best to make sure cracks already work on all devices before getting our programmers running in circles.

In this case, a subtle bug was exposed that affected reading the very end of a disk image. This was a genuine bug that really needed to be fixed (it was also causing the last sector of a sector copy to be corrupted)

 

When we tackle ATX reading/writing, we will need to implement accurate disk timing as a consequence, so this will be coming.

 

-Thom