fujinet #FujiNet Testing and Bug Reporting Thread

[tschak909]

6 minutes ago, FreddieBear said:

I still have a broken FujiNet and refuses to boot up.  This is a major problem (software problem I'm guessing) that renders the device useless.  I wish someone could offer a solution other than purchasing another one.

These are my thoughts for today.

From the debug output you're sending, your device is in Bluetooth mode. A recent change to the firmware persists that, even over cold start.

 

If you hold down button A, do the lights change?

-Thom

 

Edited January 24, 2021 by tschak909

[tschak909]

I spent today working on CONFIG, with @mozzwald.

 

Some of you have been asking for the ability to SKIP the networking configuration, and to use the device’s local SD card storage in certain situations. To address this, a Skip option had to be added to the SET_WIFI screen.

 

We also made it so that if the SSID becomes empty (NULL), the SET_WIFI screen will appear.

 

Mozzwald noticed that we were indeed wasting time trying to connect to the WIFI network, both during the cold start, and during CONFIG startup. Seeing as we absolutely need the FujiNet to connect during cold start so that a user can properly access the web admin, he decided to try a fix to skip past the CONNECT_WIFI state to the DISKULATOR_HOSTS page if the ssid was already set. This was pushed out and users came back with a few problem reports.

 

This is how we fixed it:

 

* change the hosts page functions to use the program’s “context” structure, instead of explicitly fanning out the device slots and host slots that this object keeps. This allowed the various functions in the hosts screen to access members like “net_connected” which is set false by default, and is set true if we detect that a WiFi connection is present.

* Only allow the select page, if the selected slot is SD (meaning local storage), or if a network connection is actually present. This does mean that if you want to set up a network connection after CONFIG has loaded, you either need to use the Set SSID inside the [C]onfig page, or you need to RESET the computer to load CONFIG again. This prevents the system from accidentally hanging, if a network connection is selected, and there is no network connection to service a host slot.

* The red/green bar is now a good indicator if a network connection is present when CONFIG starts.

 

It seems to be stable, and I’ve been testing it by wiping my FujiNet configuration (pressing button B while powering on the FujiNet), and testing the various possible states.

 

If we’ve somehow missed something, it’s important that if you decide to tell us, that you give enough detail for us to reproduce the problem, such as:

 

* Computer used

* Are you using Ultimate 1MB or another ROM expansion?

* Is the #FujiNet powered by the Atari, or externally?

* Do you have other peripherals connected on the serial bus?

* Can you provide a step by step to reproduce the problem?

 

We do apologize for the inconveniences caused by people tripping over bugs as we work on the firmware. It is our hope that by dealing with these bugs head on, both on our own systems, and with the users, we can find and squash these bugs faster. Thankfully we are not making mission critical firmware.

Edited January 24, 2021 by tschak909

[FreddieBear]

43 minutes ago, tschak909 said:

From the debug output you're sending, your device is in Bluetooth mode. A recent change to the firmware persists that, even over cold start.

 

If you hold down button A, do the lights change?

-Thom

 

Yes holding down the A (white LED) button switches between Bluetooth (blue LED) and WiFi (white LED).  While the white LED is still on (USB powered), I switch on my Atari and it still refuses to boot.  Also it doesn't matter if I am powering the FujiNet via USB power or internally via the Atari 800XL.  The results are identical - no boot up.

[Gunstar]

22 hours ago, 8bitguy1 said:

I've noticed since the last (or potentially previous) update that when I boot Fujinet now, it never connects to my network any longer.  I go into config and "reconnect" and its fine for the duration of the session but it used to just connect automagically.  Anyone else notice this?

This just started happening to me today, except it doesn't work at all, there's no "fine for the session." I was in the config menu (with the TNFS and drives) and I inadvertently pushed something, and it crashed. I shut down and restarted everything and suddenly nothing loaded when I tried to restart, SD card, all other TNFS stuff, all comes back with an SIO or some kin of fail to load error, I forget now as it's been several hours, then Fujinet restarts the initial Wi-Fi detection and my wi-fi host (I forget atm what the official terms are atm, too tired to think.)  I'll post all details when I try again tomorrow) shows up in red and will not connect.

 

So then I reinitialize at that screen and re-scan for wi-fi signals, and mine shows up, asks for the password again, and then it does turn green and re-connects, but every time I try to access any TNFS option they fail to load and my wi-fi disconnects and it's back to the wi-fi screen where mine shows up red again, rinse, repeat. I just shut if off for now as I got tired of going through this with no change. I have no idea what button I initially hit on the keyboard to cause this, but I was on my SD card slot at the time. I will try to start over tomorrow going through all the initial process like I did when I first got the Fujinet and more carefully read your reply @tschak909 in post #327 above, I'm just tired right now and can't really concentrate and just don't feel like doing it all now.

Edited January 25, 2021 by Gunstar

[Kyle22]

On 1/23/2021 at 6:28 AM, DjayBee said:

I see a huge conspiracy around the corner. ?

Instead of making fun of me, why don't you look into the problem and help fix it?

 

[+Stephen]

On 1/23/2021 at 6:28 AM, DjayBee said:

I see a huge conspiracy around the corner. ?

Q.anon bastards.

[Gunstar]

Well, I got my Fujinet connected to my Wi-Fi again. The problem had to do with my SSID password. I absolutely, positively know I was entering the right password, I redid it all on my PC just to make sure it wasn't my Wi-Fi, and yes, it still works with the same password. I do have the latest Firmware installed. The full story/explanation is below.

 

What was happening was my Wi-Fi would show up when I scanned for it, but it would be highlighted in red, and it would just simply fail to connect. But, I turned on my smart phone hot-spot and it would show up and when I connected to it, it would work, everything would work through my smartphone SSID. Then I would go to the config screen from the host list screen  and I would press S to change SSID, then my regular Wi-Fi  SSID would show up highlighted in green again, I would enter my password, it would connect, load up the TNSF host list, but the white Wi-Fi light would go out immediately after and nothing would load on the TNFS host screen including my own SD card (but if I didn't try to connect to Wi-Fi at all, just choose the SKIP option, then at least my SD card would work). I would go back to the config SSID screen, select change SSID, and my Wi-Fi SSID would be highlighted in red again, I would select it and enter the password, but it would fail to connect. I would then select my smart phone SSID, it would connect and highlight in green, and everything worked again. This all started, as I said in the post above, when I inadvertently hit some key or combination of keys when I was in the TNSF host list screen and everything initially crashed. 

 

I finally got my regular Wi-Fi to work again completely, as I said at the beginning of this post, and continues to auto-connect too, BUT, I had to remove my security password and make it an open/public Wi-Fi to get it to work right again. I have not tried to reinstall my security and try with a password again at this point. My smartphone Wi-Fi that was working I also had no security password enabled, as I never use it, and just didn't turn on security and enter a password in the first place. I have not tried as of yet to turn on security in either one and enter a password.

 

I live in the middle of nowhere, where I really don't have to worry about anybody using them anyway, as nobody ever comes out there but the USPS, Amazon deliveries and garbage man, so I'm fine not having passwords, but others may not have that option, should this issue come up for someone else when they inadvertently hit some wrong keys on the keyboard, or combination, or if their cat walks on it or something. 

 

I can turn on security again, enter a password, and see what happens with Fujinet again, while running the flasher software, if you want me too, @tschak909 . Maybe it will all just work again, or maybe not. But if it does just work again, that's fine, except we'll probably never know what went wrong in the first place through the debugger, so I'm kind of hoping it won't work right again, just to see what the debugger shows.

 

It doesn't seem like, based on what @FreddieBear, has said, that his issue is the same as mine, since his won't boot up at all. At least my Fujinet would still boot up.

 

I hope you can understand my long explanation above @tschak909

Edited January 25, 2021 by Gunstar

[Atari8guy]

On 1/23/2021 at 8:38 PM, 8bitguy1 said:

I've noticed since the last (or potentially previous) update that when I boot Fujinet now, it never connects to my network any longer.  I go into config and "reconnect" and its fine for the duration of the session but it used to just connect automagically.  Anyone else notice this?

The latest firmware update has rectified this for me.  Thank you!

[MrFSL]

6 hours ago, FreddieBear said:

Yes holding down the A (white LED) button switches between Bluetooth (blue LED) and WiFi (white LED).  While the white LED is still on (USB powered), I switch on my Atari and it still refuses to boot.  Also it doesn't matter if I am powering the FujiNet via USB power or internally via the Atari 800XL.  The results are identical - no boot up.

Now that you are out of bluetooth mode - if you attach logs it will now give us more information to try and help you.

[GreyHobbit]

On 1/20/2021 at 8:19 PM, tschak909 said:

Thanks for the merges. Curious, was there a reason you did each tool change as a separate pull req?

 

Ah ok, you answered it. So long as I know what was happening.

 

-Thom

 

@tschak909 I just noticed that I missed one of the 'i<=argc' typos in NREN.COM.  I have submitted another pull request.  I think I got the hang of it this time

 

Geoff

[GreyHobbit]

[mention=9462]tschak909[/mention] I just noticed that I missed one of the 'i  
Geoff

I think the editor didn't like my last message!
I was trying to say I missed one of the argc loop typos in NREN.COM. I submitted a new pull request.
Geoff

Sent from my AC2003 using Tapatalk

[+DrVenkman]

Something in the last couple CONFIG versions (maybe further ago than that?) broke something about loading this disk image.

Four or five years ago, someone on this forum made this disk image for me after lamenting that I had no way to load one of my favorite early "games" from cassette, the APX title SCRAM. This disk image did at one time work under FujiNet, or at least I *think* it did; it loads fine from the XEL Loader on my 1088XLD and the SIDE3 loader in my 1200XL+U1MB, both of which I just checked right now. Pretty sure it used to work under FujiNet too but currently both my devices load a few sectors sectors, then make a record-scratching screech noise. Nothing else plugged into the SIO bus.

This is on my 1088XLD, my beta 576NUC+ board, and my 1200XL. The program requires BASIC to be enabled in case anyone wants to check it out for themselves.

SCRAM.ATR

[tschak909]

Some analysis shows that this high speed loader abuses the status bits to try and shift into XF-551 high speed mode incorrectly:

 

SIO: Device $31[1], command $53, buffer $02EA, length $0004, aux $0000 timeout  7.5s | Disk: Get status
SIO: Device $31[1], command $52, buffer $0400, length $0080, aux $0001 timeout  7.5s | Disk: Read sector
SIO: Device $31[1], command $52, buffer $0400, length $0080, aux $0002 timeout  7.5s | Disk: Read sector
SIO: Device $31[1], command $52, buffer $0400, length $0080, aux $0003 timeout  7.5s | Disk: Read sector
SIO: Device $31[1], command $D2, buffer $09E0, length $0080, aux $0004 timeout  5.3s | Disk: Read sector (high speed)
SIO: Device $31[1], command $D2, buffer $0A5D, length $0080, aux $017D timeout  5.3s | Disk: Read sector (high speed)
 

If I set the drive type to XF551 in Altirra, it freezes in exactly the same manner.

 

 

[tschak909]

21 minutes ago, DrVenkman said:

Something in the last couple CONFIG versions (maybe further ago than that?) broke something about loading this disk image.

Four or five years ago, someone on this forum made this disk image for me after lamenting that I had no way to load one of my favorite early "games" from cassette, the APX title SCRAM. This disk image did at one time work under FujiNet, or at least I *think* it did; it loads fine from the XEL Loader on my 1088XLD and the SIDE3 loader in my 1200XL+U1MB, both of which I just checked right now. Pretty sure it used to work under FujiNet too but currently both my devices load a few sectors sectors, then make a record-scratching screech noise. Nothing else plugged into the SIO bus.

This is on my 1088XLD, my beta 576NUC+ board, and my 1200XL. The program requires BASIC to be enabled in case anyone wants to check it out for themselves.

SCRAM.ATR 90.02 kB · 1 download

Problem shown above, am curious what loader was used to make that, as it does some very naughty things. It's also failing on Altirra... I'll put together a SCRAM disk that doesn't do stupid things in the loader...  Stay tuned.

 

p.s. the reason it was working before, was because we were not acknowledging the high speed commands with bit 7 set (52 becomes D2 etc.)... I added support for these so that XDOS could boot correctly... Looks like I will have to refine things a bit more... 

 

-Thom

[tschak909]

@DrVenkman here you go, a nice corrected disk image without any funny boot loaders. It still automatically loads SCRAM, and I corrected the bug in the splash screen. 

 

SCRAM.atr

 

-Thom

[+DrVenkman]

10 minutes ago, tschak909 said:

@DrVenkman here you go, a nice corrected disk image without any funny boot loaders. It still automatically loads SCRAM, and I corrected the bug in the splash screen. 

 

SCRAM.atr 90.02 kB · 1 download

 

-Thom

Damn, that’s what I call service. Thanks, Thom!

 

[_The Doctor__]

is there or will there be a toggle to turn off that speed selection bits detection or some other such method, sort of like other devices where you can limit the speed or set it for the device.

[tschak909]

This would be a good thing for somebody who wants to dip their fingers into the firmware for the first time, to do, there is already a variable in the firmware that we use to prevent engaging high-speed when ATX images are being used, that can be exposed to the web service.

 

(yes, I know nothing will probably come of it, but I don't usually get help I don't ask for, and I am trying like hell to focus on getting N: in shape.)

 

-Thom

 

[_The Doctor__]

Time for Thom to go dark until that N device is nailed down...

[StefanD]

Fujinet Version: 0.5.e6b3e94e 2021-01-22 01:42:35 (as displayed by the Fujinet webserver)
Computer: Unmodified 800XL
Fujinet power: By Atari (no external power)
Other connected peripherals: none

 

1. In CONFIG, mount all 8 drives in the drive list (no "Empty" in the drive list), drive 1 should be DOS
2. Press OPTION to boot the DOS in D1:
3. Press the Disk Rotate Button 8 times.
Problem: The 8th press and all further presses don't work. The blue LED flashes, but SAM doesn't say anything and all drives respond with Error 138.

 

1. Configure a working WiFi connection (selection bar in CONFIG green)
2. Press Fujinet Reset Button and reboot Atari with SELECT key hold down
3. The CONFIG WiFi selection screen appears (with red selection bar). Now press 'S' (without configuring a WiFi connection)
Problem: Selection bar in the host/drive list is red. Should be green, since the WiFi connection still works.

 

[Xebec]

Dumb question time - My Fujinet for some reason can no longer connect to any servers (have tried at least:  fujinet.pl, fujinet.atari8bit.net, atari-apps.irata.online, atari8.us) without success.  The UI will sit there for several seconds, then eventually revert back to reconnecting to my AP (which is successful), showing the list of servers and drives again after doing so.  

 

Are websites such as:  http://www.cacaculopedopis.net/   the only real way (or best way) for me to test connectivity to TNFS or is there a piece of software I can use to get more information about why the connections are failing?  (and if I'm on my AP with a Chromebook, and that webpage is able to connect to Fujinet.pl - then safe to assume it's not my network but something with the Atari?)

 

EDIT, additional troubleshooting completed:  IP Address / [C]onfig info in Fujinet looks legit.  Weather.ATR is unable to connect to retrieve info (loaded from SD card).  Tried both APs that I have available.  I *also* have a condition where the Fujinet fails to connect to wireless (or see any APs) every other boot, but I'm not sure why.

 

Info:

Atari 800, Incognito,  XL ROM, 1088KB

Wifi connectivity IS successful from Fujinet - I've tried both of my Access Points

Powered by Atari 800, no other peripherals detected

SD card works flawlessly

 

Thanks all! 

P.S.  I think i'll take the 'extra' troubleshooting step of ordering a second one of these for another 8bit since they're..  AWESOME! 

P.P.S.  Good Morning Atarians! 

Edited January 30, 2021 by Xebec
Added troubleshooting

[Mr Robot]

Are you using high speed io?

 

[tschak909]

5 hours ago, Xebec said:

Dumb question time - My Fujinet for some reason can no longer connect to any servers (have tried at least:  fujinet.pl, fujinet.atari8bit.net, atari-apps.irata.online, atari8.us) without success.  The UI will sit there for several seconds, then eventually revert back to reconnecting to my AP (which is successful), showing the list of servers and drives again after doing so.  

 

Are websites such as:  http://www.cacaculopedopis.net/   the only real way (or best way) for me to test connectivity to TNFS or is there a piece of software I can use to get more information about why the connections are failing?  (and if I'm on my AP with a Chromebook, and that webpage is able to connect to Fujinet.pl - then safe to assume it's not my network but something with the Atari?)

 

EDIT, additional troubleshooting completed:  IP Address / [C]onfig info in Fujinet looks legit.  Weather.ATR is unable to connect to retrieve info (loaded from SD card).  Tried both APs that I have available.  I *also* have a condition where the Fujinet fails to connect to wireless (or see any APs) every other boot, but I'm not sure why.

 

Info:

Atari 800, Incognito,  XL ROM, 1088KB

Wifi connectivity IS successful from Fujinet - I've tried both of my Access Points

Powered by Atari 800, no other peripherals detected

SD card works flawlessly

 

Thanks all! 

P.S.  I think i'll take the 'extra' troubleshooting step of ordering a second one of these for another 8bit since they're..  AWESOME! 

P.P.S.  Good Morning Atarians! 

Before you do anything, please ensure that you are running the latest firmware, use the FujiNet flasher to flash to the latest firmware, as there was an experiment tried recently on optimizing network connectivity time, which didn't initially work. @mozzwald and I went back and fixed it in the latest build.

 

-Thom

 

[Xebec]

On 1/30/2021 at 12:41 PM, tschak909 said:

Before you do anything, please ensure that you are running the latest firmware, use the FujiNet flasher to flash to the latest firmware, as there was an experiment tried recently on optimizing network connectivity time, which didn't initially work. @mozzwald and I went back and fixed it in the latest build.

 

-Thom

 

 

Thank you - forgot to check for the firmware, and this resolved it!  Thanks again! 

[NISMOPC]

On 1/22/2021 at 6:59 PM, NISMOPC said:

Interesting observation with my modified 130XE and SIO power vs. USB power on Fujinet 1.0.

 

I've added 512K SRAM, DUAL Pokey and 4in1 OS switch and am using a S-Video cable to LCD.

 

If I power the Fujinet from SIO, I get minor vertical lines in display and the display has a slight dimness to it.

 

If I power the Fujinet from USB, vertical lines completely disappear and the display is nice and crisp.

 

I know the 130XE has poor shielding, but any thoughts why powering the Fujinet off USB would resolve that?

On 1/22/2021 at 7:44 PM, NISMOPC said:

I'm thinking the same. If I remove the Fujinet all together, the picture is also very crisp and super clean. 

 

Not an issue. I'll continue to power it separately and either get a USB cable with built in switch OR add on/off switch to the Fujinet. I originally opted to buy the Fujinet w/o the switch.

Just an update on my issues above. Apparently, they resolved themselves. ?

 

I am not quite sure what corrected this, but here are a few things I recently did. Re-arranged my "Atari" room. Moved my shelving with my CRT TV, Atari 7800, Atari Video Music and carts to other side (right side instead of left), but left my 8-bit set-up alone. Same power supply, same S-video cable, same location, etc.

 

I updated the firmware yesterday to the latest version and removed the USB power to FujiNet.

 

All I can say is WOW! Picture quality is super clean. There are no drops in power with FujiNet being powered off 130XE. I am confused and overjoyed at the same time...

 

Not the best pictures and they do not do it justice.