MrFSL Posted May 14, 2022 Share Posted May 14, 2022 NLOGIN crashes my system(s). To reproduce: boot to SDX type D1:NDEV type D1:NLOGIN N1: username password The result is a crash and an all white screen --- usually with some black artifacts on the left hand side. If using the IDE+, the onboard SDX cart gets disabled. To workaround: boot to SDX type D1:NDEV type D1:FCONFIG type D1:NLOGIN N1: username password Odd I know. But running FCONFIG prior allows NLOGIN to work. I have tested on 3 800xls and 1 130xe. I have tested with stock hardware, SYSCHECK memory upgrade, Antonia memory upgrade, AVG memory upgrade. I have tested with 3 different versions of fujinet hardware including the latest. I have tested with several versions of SDX running from Uno Cart, AVG Cart, IDE+ I have tested at just about all SIO speeds I have tested with old Fujinet firmware Quote Link to comment Share on other sites More sharing options...
tschak909 Posted May 14, 2022 Author Share Posted May 14, 2022 Thanks, will look into this. -Thom Quote Link to comment Share on other sites More sharing options...
SlagOMatic Posted April 6, 2023 Share Posted April 6, 2023 (edited) Referencing this elsewhere thread as a bug report here... I played around a bit and discovered that when FujiNet takes awhile to mount a disk, ALL mounted disks momentarily go offline -- and if you happen to be actively writing to a mounted disk at this time, then all remaining mounted disks go offline PERMANENTLY (until you reboot FujiNet and the Atari). And when it comes back up, none of your previously-mounted disks show up in the drive slot list. Example: I had CopyMate XE in D1, physical drive at D2, blank disk images in D3 and D4. I had copied a physical disk into D3. When it was complete, I flipped my physical disk over and started copying it to D4. While that was happening I ejected the D3 image (via the web interface), then mounted a new image into D3. FujiNet showed that delay while mounting D3 and immediately my Atari started making that "grumbling" noise and then threw up a write error -- just like it makes if you eject a physical disk in mid-write. Pressing START to try again brings up the same error. I tried re-mounting the images in D3 and D4. Both showed that delay, ultimately telling me it was successful and showing up in the FujiNet web interface, but CopyMate still didn't see it and continued to generate the error. Cold-booting my Atari did NOT boot from FujiNet, instead bringing me to Self-Test (w/OPTION). I rebooted FujiNet, then the Atari, and booted into FujiNet. All of my drive slots were empty except for CopyMate in D1. It "feels" like some kind of memory leak. When the FujiNet is rebooted I almost never have that "delay when mounting" issue, but the longer I swap virtual disks the more it crops up, and apparently if I do it too much the whole FujiNet needs to be rebooted. TZJB suggested running FujiNet Flasher in monitor mode to capture the gory details so I did. The accompanying report follows this workflow: Boot from CopyMate XE 3.7 mounted on virtual D1, hosted from my home server. Physical drive on D2. Using web interface, mount empty ATR images (hosted from my home server) on D3 and D4. Copy first disk (Jumpman, in this instance) from D2 to D3. Copy second disk (Paint, in this instance) from D2 to D4. Eject both mounted disks. In following this workflow, mounting Jumpman.atr to D3 took about 10 seconds but then reported "operation successful". Mounting Paint.atr to D4 was instant. Both D3 and D4 showed the appropriate ATR files in their respective drives. However, CopyMate did not see any disk in D3. At that point I ejected D3 and re-mounted Jumpman.atr (which was instant and successful), at which time CopyMate was able to see the disk. This 10 second delay with the successful-not-successful issue happens fairly regularly, and the longer I use the FujiNet without rebooting the more frequent it gets until eventually it seems like it's impossible to mount any disk images. At that point I have to reboot both the FujiNet and the Atari. When that happens and FujiNet comes back online, the web interface often shows different media mounted than what the Atari screen interface shows. Captured log from Flasher is here: https://www.dropbox.com/s/t91mnm4p78j1ifd/2023-04-06-19-00.txt?dl=0 PS: Running firmware 0.5.64f05da8 2023-03-18 20:36:30. Edited April 6, 2023 by SlagOMatic 2 Quote Link to comment Share on other sites More sharing options...
mozzwald Posted April 7, 2023 Share Posted April 7, 2023 @SlagOMatic Thanks for the detailed report, we are looking into it. Have you by chance tried with files on SD to see if it's tnfs related only? I've also encountered another bug while testing. Mount 4 disks, boot dos, do a listing for each disk from dos works, press disk swap button then D1 and D4 are not readable anymore 2 Quote Link to comment Share on other sites More sharing options...
SlagOMatic Posted April 9, 2023 Share Posted April 9, 2023 On 4/7/2023 at 9:16 AM, mozzwald said: @SlagOMatic Thanks for the detailed report, we are looking into it. Have you by chance tried with files on SD to see if it's tnfs related only? I've also encountered another bug while testing. Mount 4 disks, boot dos, do a listing for each disk from dos works, press disk swap button then D1 and D4 are not readable anymore Have not tried with SD but I will test and report back. In the meantime, I've noticed that when this issue happens there are notifications on the TNFS server. Here's a copy-paste of the TNFS command window output: Last login: Tue Apr 4 21:05:29 on ttys000 server@-Server ~ % sudo sh /Users/server/Desktop/Atari\ TNFS.sh Password: Starting tnfsd version 20.0813.1 using root directory "/Volumes/RAID5/Retro Gaming/ROMs & ISOs/Atari 8-bit" 192.168.2.18 s=41a7 c=17 q=41 | Invalid session ID 192.168.2.18 s=41a7 c=17 q=42 | Invalid session ID 192.168.2.18 s=41a7 c=17 q=43 | Invalid session ID 192.168.2.18 s=41a7 c=17 q=44 | Invalid session ID 192.168.2.18 s=41a7 c=17 q=45 | Invalid session ID Allocating new session for 0x00 Allocated new session for 0x41a7 Allocating new session for 0x00 Allocated new session for 0x3af1 Allocating new session for 0x00 Allocated new session for 0xacd9 Allocating new session for 0x00 Allocated new session for 0xc2a Allocating new session for 0x00 Allocated new session for 0xb782 Allocating new session for 0x00 Allocated new session for 0xdac8 Allocating new session for 0x00 Allocated new session for 0x8ed8 Allocating new session for 0x00 Allocated new session for 0x9fe Found we already 8 sessions for this IP - returning oldest entry 192.168.2.18 s=00 c=00 q=00 | Freeing existing session Allocating new session for 0x41a7 Allocated new session for 0x41a7 Found we already 8 sessions for this IP - returning oldest entry 192.168.2.18 s=00 c=00 q=00 | Freeing existing session Allocating new session for 0x41a7 Allocated new session for 0x41a7 Found we already 8 sessions for this IP - returning oldest entry 192.168.2.18 s=00 c=00 q=00 | Freeing existing session Allocating new session for 0x41a7 Allocated new session for 0x41a7 Found we already 8 sessions for this IP - returning oldest entry 192.168.2.18 s=00 c=00 q=00 | Freeing existing session Allocating new session for 0x41a7 Allocated new session for 0x41a7 (For reference, 2.18 is my FujiNet.) There seems to be a correlation here. Whenever there's an "Allocating new session..." message by itself there's a delay when mounting an ATR file but the mount is successful. But when there's a "Found we already 8 sessions..." message preceding the "Allocating new session..." message, there's a delay when mounting an ATR file but the mount IS NOT successful. 1 Quote Link to comment Share on other sites More sharing options...
mozzwald Posted April 26, 2023 Share Posted April 26, 2023 @SlagOMatic Here is a new firmware that I would like you to test when you have time. This is built with a newer ESP-IDF (v5.0.1) and also has a bug fix related to webui disk mounting. Previously, when a disk was mounted from the webui it only changed the file pointer but did not actually mount the disk. This build fixes that issue and I'm curious if it fixes the issues you are having. Thanks! fujinet-ATARI-0.5.1d0a0f52-BETA.zip 2 Quote Link to comment Share on other sites More sharing options...
mozzwald Posted April 26, 2023 Share Posted April 26, 2023 I fixed another bug related to TNFS. When a TNFS Timeout would occur, the packet sequence number was being increased when it should remain the same since it was not successfully transmitted. I've fixed this in the attached firmware file. @SlagOMatic or anyone else who is having TNFS issues, please test this build and report. Thanks fujinet-ATARI-0.5.1b7ccf31-BETA.zip 4 1 Quote Link to comment Share on other sites More sharing options...
chad5200 Posted April 30, 2023 Share Posted April 30, 2023 On 4/26/2023 at 1:37 PM, mozzwald said: I fixed another bug related to TNFS. When a TNFS Timeout would occur, the packet sequence number was being increased when it should remain the same since it was not successfully transmitted. I've fixed this in the attached firmware file. @SlagOMatic or anyone else who is having TNFS issues, please test this build and report. Thanks fujinet-ATARI-0.5.1b7ccf31-BETA.zip 1.81 MB · 0 downloads I'd like to test this out. But can someone tell me how to get this installed? I have the firmware flasher utility... and I see an option for Custom Firmware File. Do I just select this .ZIP file? Quote Link to comment Share on other sites More sharing options...
mozzwald Posted April 30, 2023 Share Posted April 30, 2023 7 minutes ago, chad5200 said: I'd like to test this out. But can someone tell me how to get this installed? I have the firmware flasher utility... and I see an option for Custom Firmware File. Do I just select this .ZIP file? Correct, just select the ZIP file and hit the Flash FujiNet Firmware button Quote Link to comment Share on other sites More sharing options...
chad5200 Posted April 30, 2023 Share Posted April 30, 2023 On 4/26/2023 at 1:37 PM, mozzwald said: I fixed another bug related to TNFS. When a TNFS Timeout would occur, the packet sequence number was being increased when it should remain the same since it was not successfully transmitted. I've fixed this in the attached firmware file. @SlagOMatic or anyone else who is having TNFS issues, please test this build and report. Thanks fujinet-ATARI-0.5.1b7ccf31-BETA.zip 1.81 MB · 1 download This update has absolutely fixed my issue which I detailed in this thread here: As you can see, my guess as to the issue was described as: 'I am really thinking there are occasions where the "TNFS OUT OF ORDER SEQUENCE" error occurs but the FujiNet does not actually attempt to correct the packet sequence request because the log isn't even showing the follow up "tnfs_lseek" message. Every time mine fails, it corresponds to that situation. However, every time that a "TNFS OUT OF ORDER SEQUENCE" event occurs and it is followed up by a "tnfs_lseek success" it succeeds.' Before this fix, it was easy for me to replicate the issue (as described in my thread) but now I have tried replicating it a couple hundred times and every time it is a success. I am very happy this was addressed! I think this is a HUGE fix and I'll bet some people don't realize they were experiencing it... and if they did, they just rebooted and tried again and it worked. But in my instance, I was trying to set up a Carina BBS for my friend which involves often loading files and it was very important that each file loaded successfully on demand. THANK YOU! 3 1 Quote Link to comment Share on other sites More sharing options...
mozzwald Posted April 30, 2023 Share Posted April 30, 2023 2 minutes ago, chad5200 said: As you can see, my guess as to the issue was described as: 'I am really thinking there are occasions where the "TNFS OUT OF ORDER SEQUENCE" error occurs but the FujiNet does not actually attempt to correct the packet sequence request because the log isn't even showing the follow up "tnfs_lseek" message. Every time mine fails, it corresponds to that situation. However, every time that a "TNFS OUT OF ORDER SEQUENCE" event occurs and it is followed up by a "tnfs_lseek success" it succeeds.' Before this fix, it was easy for me to replicate the issue (as described in my thread) but now I have tried replicating it a couple hundred times and every time it is a success. I am very happy this was addressed! I think this is a HUGE fix and I'll bet some people don't realize they were experiencing it... and if they did, they just rebooted and tried again and it worked. But in my instance, I was trying to set up a Carina BBS for my friend which involves often loading files and it was very important that each file loaded successfully on demand. THANK YOU! Thanks for testing and confirming it works. This has been a long standing issue and I'm glad it's fixed. This will be pushed to the flasher after some other things are fixed/changed and more testing is done. I'm working on having github build the firmware automatically and will be starting that with a v1.0 build. No more git hash for version numbers which should make it easier to see if you need an upgrade. 4 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted April 30, 2023 Share Posted April 30, 2023 (edited) Thank you chad5200 and mozzwald. It's a wonderful day for FujiNet owners the world over. Speaking if which, I will be owning again now that the more major usage issues are being addressed !! I am awaiting another one. The world of 'have a free from me FujiNet' may now be at an end, I just may be keeping this one. 😮 Edited April 30, 2023 by _The Doctor__ 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted May 6, 2023 Share Posted May 6, 2023 (edited) error 404 for last update mozzwald posted Downloading https://fujinet.online/firmware/releases_atari/fujinet-ATARI-v1.0-pre4.zip HTTP error: 404 Client Error: Not Found for url: https://fujinet.online/firmware/releases_atari/fujinet-ATARI-v1.0-pre4.zip @mozzwald Edited May 6, 2023 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
mozzwald Posted May 6, 2023 Share Posted May 6, 2023 23 minutes ago, _The Doctor__ said: error 404 for last update mozzwald posted Downloading https://fujinet.online/firmware/releases_atari/fujinet-ATARI-v1.0-pre4.zip HTTP error: 404 Client Error: Not Found for url: https://fujinet.online/firmware/releases_atari/fujinet-ATARI-v1.0-pre4.zip @mozzwald fixed. sorry about that 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted May 7, 2023 Share Posted May 7, 2023 (edited) @mozzwald Retrieving firmware Downloading https://fujinet.online/firmware/releases_atari/fujinet-ATARI-v1.0-pre4.zip sha256 88980e61bddfc425f8b38fcf27306e8aaa4fa2c7f292a6363ab300604fbbf782 OK Using 'COM3' as serial port. Using '921600' as baud rate. Starting firmware upgrade... File 1: bootloader.bin, Offset: 0x1000 File 2: partitions.bin, Offset: 0x8000 File 3: firmware.bin, Offset: 0x10000 File 4: spiffs.bin, Offset: 0x910000 FujiNet Version: v1.0-pre4 Version Date: 2023-05-01 00:40:20 Git Commit: b9957c2e Unexpected error: could not open port 'COM3': PermissionError(13, 'Access is denied.', None, 5) already set up new profile. it's the same on windows 10 and 8.1 Edited May 7, 2023 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
mozzwald Posted May 7, 2023 Share Posted May 7, 2023 (edited) 28 minutes ago, _The Doctor__ said: @mozzwald Retrieving firmware Downloading https://fujinet.online/firmware/releases_atari/fujinet-ATARI-v1.0-pre4.zip sha256 88980e61bddfc425f8b38fcf27306e8aaa4fa2c7f292a6363ab300604fbbf782 OK Using 'COM3' as serial port. Using '921600' as baud rate. Starting firmware upgrade... File 1: bootloader.bin, Offset: 0x1000 File 2: partitions.bin, Offset: 0x8000 File 3: firmware.bin, Offset: 0x10000 File 4: spiffs.bin, Offset: 0x910000 FujiNet Version: v1.0-pre4 Version Date: 2023-05-01 00:40:20 Git Commit: b9957c2e Unexpected error: could not open port 'COM3': PermissionError(13, 'Access is denied.', None, 5) already set up new profile. it's the same on windows 10 and 8.1 Running it as administrator? Something else on the system taking control of the serial port? Maybe reboot and run the flasher first thing Edited May 7, 2023 by mozzwald added Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted May 7, 2023 Share Posted May 7, 2023 Yes, both as admin, and as a regular user I just tried every cord in the house then I got pissed and hit the flash button like a madman nut... it says it flashed now we'll see Quote Link to comment Share on other sites More sharing options...
darwinmac Posted May 7, 2023 Share Posted May 7, 2023 26 minutes ago, _The Doctor__ said: @mozzwald Retrieving firmware Downloading https://fujinet.online/firmware/releases_atari/fujinet-ATARI-v1.0-pre4.zip sha256 88980e61bddfc425f8b38fcf27306e8aaa4fa2c7f292a6363ab300604fbbf782 OK Using 'COM3' as serial port. Using '921600' as baud rate. <snip> Unexpected error: could not open port 'COM3': PermissionError(13, 'Access is denied.', None, 5) already set up new profile. it's the same on windows 10 and 8.1 @_The Doctor__ - Have you updated your Fujinet-Flasher? A few months ago, @mozzwald created a new flasher program that defaults to a BPS rate of 460800. I don't know what other changes are in the updated flasher program. I was able to upload the new firmware, but I don't run Windows so I'll defer to another Windows user to see if the problem occurs with other Windows users. Bob C Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted May 7, 2023 Share Posted May 7, 2023 It was the latest download he provided. I changed the baud rate because it wouldn't respond til I did Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted May 7, 2023 Share Posted May 7, 2023 (edited) FujiNet version 0.5.aac1c104 2023-05-01 00:40:20 is the reported version via web interface now starting to wonder if the usb ports are not of the best quality or not always nicely soldered to the PCB it's up and running on the Atari, I hope it passed all the sanity checks if there are any. will be hitting the testing files on remote tnfs folders. @mozzwald Edited May 7, 2023 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
mozzwald Posted May 7, 2023 Share Posted May 7, 2023 @_The Doctor__ The error you reported Unexpected error: could not open port 'COM3': PermissionError(13, 'Access is denied.', None, 5) means something has the port open or you don't have permission to access the port. Probably not related to the USB port or cable. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted May 7, 2023 Share Posted May 7, 2023 (edited) means nothing because it works fine with everything else.... I got it to program if the web interface is correct in saying the update is from 5 1 2023 so 6 days ago 0.5.aac1c104 2023-05-01 00:40:20 is what the web config is showing. The flasher is quirky. I simply stop trying all kinds of different cords. stuck with one and kept hitting the flash button on the fujinet flasher repeatedly until it finally went through. Everything else works like it should in terms of the log being sent etc so clearly the usb port works fine. Beings 3 totally different Laptops from different manufacturers running different Windows versions with fresh user profiles all had issues, that leave use with a FujiNet device problem or the Flasher needing some work / probably both The device seems more reliable on some network connections but overall something else is different as well. I may have to bump the SIO divisor down one more notch for use with SDX... it was fine before the update but now it chokes sometimes. Over all I was able to use the device for a longer period of time tonight manipulating disks in and out of slots... will look at it some more tomorrow Does the Flasher software check what was sent to the device and verify the data against what it has sent in some way or does the device just check what was sent to it's local memory versus what was flashed? Edited May 7, 2023 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
MichaG Posted May 7, 2023 Share Posted May 7, 2023 I've flashed the new version, too. Everything seems to work fine, but my MyIP and the build in Config say it is version 0.5.aac1c104, not 1.0-pre4. 1 Quote Link to comment Share on other sites More sharing options...
mozzwald Posted May 7, 2023 Share Posted May 7, 2023 49 minutes ago, MichaG said: I've flashed the new version, too. Everything seems to work fine, but my MyIP and the build in Config say it is version 0.5.aac1c104, not 1.0-pre4. This is something that needs changed in the auto build. Will be fixed for the next release 2 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted May 10, 2023 Share Posted May 10, 2023 (edited) @mozzwald, @tschak909, Disk slots work... but... issue 1... now if you set all the host slots... with slot 1 as SD card and not acting as a remote host... and then go into and leave remote hosts one at a time... after the 5th one you go into and look at then leave... whatever 2 slots that are left WILL NOT work, it will instead take you to config... if you just leave config all is fine... IF YOU RECONNECT it will blank everything and you will have to manually fix it all. issue 2 when you set a disk from a server into a drive slot, it no longer returns you to where you were... you have to traverse all the way there again... perhaps we chose some earlier version to try the fix on and published it as the latest greatest with the fix applied? issue 3 is a group terminal emulation... AT? the screen has a number of items that don't work or are working but labelled incorrectly ATPHONEBOOKLIST... should be ATPBLIST ATPHONEBOOKCLR... should be ATPBCLEAR AT[UN]SNIFF... should be AT+SNIFF and AT-SNIFF ATA should be in the list etc etc... ATTERMVT52,ATTERMVT100,ATTERMDUMB,ATTERMANSI do nothing and should not be there... They are handled under AT+TERM= just fine The help listing could use a tweak with the atwificonnect stuck right at the blank spot just below, like ==================================== ATWIFICONNECT<ssid>,<key> Set up WIFI then the rest of the list ATA |Answer Ring/ANSWER Mode ATO |Answer Ring/Originate Mode ATS0=<0|1> |AutoAnswer Connect on/off and so on... information from setting ATPORT should not be padded with a line before or after it and should simply say Listening for connections on port ATPB without anything following it should not clear the phonebook!!! after setting a PB slot sometimes you have to AT? before ATPBLIST to see what you just set up? weird Edited May 10, 2023 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.