gwpt Posted February 25, 2021 Share Posted February 25, 2021 1 hour ago, mozzwald said: I added email notifications to the product page that you can subscribe to. Excellent! thanks for doing that Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4762658 Share on other sites More sharing options...
Kyle22 Posted February 26, 2021 Share Posted February 26, 2021 Please put CP/M @ 19200 baud. This is important. 1 Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4763609 Share on other sites More sharing options...
tschak909 Posted February 26, 2021 Author Share Posted February 26, 2021 1 hour ago, Kyle22 said: Please put CP/M @ 19200 baud. This is important. If I do that, it breaks DT80. -Thom Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4763679 Share on other sites More sharing options...
_The Doctor__ Posted February 26, 2021 Share Posted February 26, 2021 (edited) Maybe make it configurable? Since not everyone is DT80 user, but will use their favorite terminals instead. I know the worry but, so long as it ships as default for DT80 speed that should be good. If a 'power user' changes a things they should know what they are doing. Just put a note in the manual about fixed terminal speeds for something like DT80, just in case. Just some ideas. Some terms can be fast, others slow... some are weird in that they were written for the iNdus GT and might do changing speeds depending on drive usage. (GT Drive is full speed but external to the GT SIO drives bounce up and down on SIO to get stuff done. Edited February 26, 2021 by _The Doctor__ 2 Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4763862 Share on other sites More sharing options...
Atari8guy Posted February 28, 2021 Share Posted February 28, 2021 The slot to slot copy feature doesn't work for me. At least for external TNFS servers. I get the message that I should wait for the activity light to go out before pressing any key but it never goes out. (I've let it sit for hours). When I do hit a key anyway, there is an image with the correct name, but any attempt to boot it just goes to self-test. My machine is a U1MB (Atari 800XL). I had similar issues with XEGS however. Has anyone else experienced this? Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4765980 Share on other sites More sharing options...
tschak909 Posted February 28, 2021 Author Share Posted February 28, 2021 2 hours ago, 8bitguy1 said: The slot to slot copy feature doesn't work for me. At least for external TNFS servers. I get the message that I should wait for the activity light to go out before pressing any key but it never goes out. (I've let it sit for hours). When I do hit a key anyway, there is an image with the correct name, but any attempt to boot it just goes to self-test. My machine is a U1MB (Atari 800XL). I had similar issues with XEGS however. Has anyone else experienced this? I will try to make another pass at the copy feature. I tried to get a minimal feature out because people were clamoring for it... -Thom Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4766091 Share on other sites More sharing options...
tschak909 Posted March 7, 2021 Author Share Posted March 7, 2021 #Atari8bit #FujiNet working through adding wildcard support to the NCOPY tool, which will make it a lot more useful... 3 Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4771511 Share on other sites More sharing options...
tschak909 Posted March 9, 2021 Author Share Posted March 9, 2021 A Mount All command has been added to the Fuji SIO device ($70), so that it can be much easier to implement mount all functionality in a boot loader. https://github.com/FujiNetWIFI/fujinet-platformio/wiki/SIO-Command-%24D7-Mount-All 5 Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4773401 Share on other sites More sharing options...
tschak909 Posted March 13, 2021 Author Share Posted March 13, 2021 N: filesystem base class rewrite attempt #4... sigh... 1 1 Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4776372 Share on other sites More sharing options...
Xebec Posted March 13, 2021 Share Posted March 13, 2021 9 hours ago, tschak909 said: N: filesystem base class rewrite attempt #4... sigh... Good luck! What you're doing for us is awesome! Thank you!! 2 Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4776631 Share on other sites More sharing options...
cathrynm Posted March 16, 2021 Share Posted March 16, 2021 Trying to understand, why is there both ddevice 0x71-0x78 and a unit # 1-8? If ddevice= 0x71 unit= 3 -- is that N3? But what about ddevic 0x73 and dunit=1? Does unit take precedence? The examples I looked at all use 0x71. OS.dcb.ddevic=0x71; OS.dcb.dunit=unit; Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4779531 Share on other sites More sharing options...
tschak909 Posted March 16, 2021 Author Share Posted March 16, 2021 18 minutes ago, cathrynm said: Trying to understand, why is there both ddevice 0x71-0x78 and a unit # 1-8? If ddevice= 0x71 unit= 3 -- is that N3? But what about ddevic 0x73 and dunit=1? Does unit take precedence? The examples I looked at all use 0x71. OS.dcb.ddevic=0x71; OS.dcb.dunit=unit; Heh, it's...an interesting little quirk of the SIO routines in the OS. Basically unit is decremented by 1 when it enters SIOV. So 0x71 with unit 1, is 0x71. 0x71 with unit 2 is 0x72 and so on. Yeah, I have no idea why they did it this way, but that's how it rolls out. If you set ddevic 0x73 and dunit=1 then you'll get a target device of 0x73. -Thom 1 Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4779536 Share on other sites More sharing options...
cathrynm Posted March 16, 2021 Share Posted March 16, 2021 10 hours ago, tschak909 said: Heh, it's...an interesting little quirk of the SIO routines in the OS. Basically unit is decremented by 1 when it enters SIOV. So 0x71 with unit 1, is 0x71. 0x71 with unit 2 is 0x72 and so on. Yeah, I have no idea why they did it this way, but that's how it rolls out. If you set ddevic 0x73 and dunit=1 then you'll get a target device of 0x73. -Thom Oops, well, that's sillier than I thought. There's not a lot out there on SIO. I google this, and most of the results are you, asking questions about it. Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4779777 Share on other sites More sharing options...
tschak909 Posted March 16, 2021 Author Share Posted March 16, 2021 SIO knowledge links: http://www.virtualdub.org/downloads/Altirra Hardware Reference Manual.pdf https://www.atariarchives.org/dere/chapt08.php https://www.atarimax.com/freenet/freenet_material/12.AtariLibrary/2.MiscellaneousTextFiles/showarticle.php?42 https://atariwiki.org/wiki/Wiki.jsp?page=Atari 800 ROM OS Source Listing Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4779791 Share on other sites More sharing options...
cathrynm Posted March 16, 2021 Share Posted March 16, 2021 "WARNING: There is a bug in SIO that causes incorrect actions when the last byte of a buffer is in a memory address ending in $FF, such as 13FF, 42FF, etc." I saw this in the Atari OS manual (which I have my original printed copy of). It says 'íncorrect actions' but I have no idea what that is. Is irritating to avoid this. Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4779888 Share on other sites More sharing options...
wildstar87 Posted March 17, 2021 Share Posted March 17, 2021 Tried signing up for e-mail notifications on when it's back in stock. I'm getting an error "Something went wrong, please try after sometime" 1 Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4780385 Share on other sites More sharing options...
mozzwald Posted March 17, 2021 Share Posted March 17, 2021 5 hours ago, wildstar87 said: Tried signing up for e-mail notifications on when it's back in stock. I'm getting an error "Something went wrong, please try after sometime" It should be working again Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4780475 Share on other sites More sharing options...
tschak909 Posted March 22, 2021 Author Share Posted March 22, 2021 #Atari8bit #FujiNet grinding through adding wildcard support to NCOPY. It must support three different path separator types used across DOS 2.0, MyDOS, and SpartaDOS. -Thom 4 Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4784077 Share on other sites More sharing options...
tschak909 Posted March 22, 2021 Author Share Posted March 22, 2021 Currently, the wildcard support is somewhat inefficient: I need to do a directory read (and parse) for each filename. For CIO devices, this happens over CIO. For N:, this happens over SIO. In Atari DOS, OSA/DOS XL, MyDOS, and many others, you can't open a CIO IOCB to a directory AND do a read and write at the same time. Turns out, there are some intersecting buffers, and the three IOCBs will clobber each other, with bits of directory winding up in destination files, and bits of the source file winding up in the directory listing. So I either have to, for CIO source devices: (a) for each new file, re-read the directory from beginning to directory position, parse the result, call the copy. Uses least amount of memory, but it takes a bit longer with each file transferred. (b) Read the whole directory into memory, parsing each entry and putting it into an array. For 127 filenames, this takes 1,651 bytes, so may be okay. I will probably continue implementing (a) and debugging it, and then move it over to (b). I haven't even dived into recursive copies yet, which, given that most DOSes don't even support subdirectories, I may just say fuck it and not bother. 1 Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4784486 Share on other sites More sharing options...
_The Doctor__ Posted March 22, 2021 Share Posted March 22, 2021 (edited) are you talking about the esp side of life in some instances and the Atari in others? why would you leave the cio open? https://www.atarimagazines.com/v3n8/AllAbout_IO.html https://www.atariarchives.org/cfn/12/02/0010.php https://www.atariarchives.org/mmm/iocbs.php http://www.atarimania.com/faq-atari-400-800-xl-xe-how-is-the-input-output-subsystem-of-the-atari-os-organized_73.html some DOS have issues with note and point depending on version as well, since it's their fault and not yours code like it does, let the DOS be fixed, you don't need to do end runs around them but using the fujinet to address some issues as a middle man might work,- or might drive you insane. You might consider teaming up with some DOS specializing coding guru's, reach out for some help. The idea of your own buffer or array might have some possibilities, not sure about all the different DOS variants though. Sometimes I wonder if #Fujinet needs a DOS type flag it can set then choose an entirely different method or subprogram to deal with some issues. Would work for most cases and Sparta would have it swapping out the helper monsters when you access all the different types / structures out there with it's Not one big monster, but a bunch of little beasts to do your grunt work called when needed and talking to each other. passing iocb data to each other and the cio utility when in basic etc. Hopefully if any of this helps all of the readers maybe some ideas may come from it. Edited March 22, 2021 by _The Doctor__ Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4784548 Share on other sites More sharing options...
tschak909 Posted March 25, 2021 Author Share Posted March 25, 2021 Spent the last week grinding through and debugging a very disturbing problem with N:, writing data with the filesystem adapters. Reading is stable. Writing seems to introduce glitches into the output. This doesn't happen if I use the TCP and UDP adapters, only when I use those derived from the FS class, e.g. HTTP and TNFS. To repeat, TCP and UDP read and write stably, and I can verify with over a thousand test passes against ordered test data, that this is the case. (My test involves a file of 23,040 32-bit long numbers in sequence, little-endian, to a file, and then copying that file using NCOPY to the Atari, afterwards reading the file back with a companion test program that reads each number and compares with a counted loop to find errors. This works well also for a visual inspection as two 32-bit numbers fit nicely on a hex dump display, and you can quickly see glitches in the output data.) Over the last two days, I made a parallel TNFS2 class that was patterned after the TCP class as much as possible, only to find the problem still exists with the re-implemented class. I am genuinely confused, and am continuing to try and investigate where this transmit buffer corruption is coming from. -Thom 1 Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4786956 Share on other sites More sharing options...
tschak909 Posted March 25, 2021 Author Share Posted March 25, 2021 #Atari8bit #FujiNet FNC-TOOLS now updated to include wildcard support for NCOPY, as well as fixing FLS. DOS directory and Ultimate1MB ROMs also updated. Everything is on TNFS atari-apps.irata.online in /. -Thom 7 Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4787026 Share on other sites More sharing options...
cathrynm Posted March 26, 2021 Share Posted March 26, 2021 On 3/25/2021 at 8:24 AM, tschak909 said: Spent the last week grinding through and debugging a very disturbing problem with N:, writing data with the filesystem adapters. Reading is stable. Writing seems to introduce glitches into the output. This doesn't happen if I use the TCP and UDP adapters, only when I use those derived from the FS class, e.g. HTTP and TNFS. To repeat, TCP and UDP read and write stably, and I can verify with over a thousand test passes against ordered test data, that this is the case. (My test involves a file of 23,040 32-bit long numbers in sequence, little-endian, to a file, and then copying that file using NCOPY to the Atari, afterwards reading the file back with a companion test program that reads each number and compares with a counted loop to find errors. This works well also for a visual inspection as two 32-bit numbers fit nicely on a hex dump display, and you can quickly see glitches in the output data.) Over the last two days, I made a parallel TNFS2 class that was patterned after the TCP class as much as possible, only to find the problem still exists with the re-implemented class. I am genuinely confused, and am continuing to try and investigate where this transmit buffer corruption is coming from. -Thom That's pretty weird. And you see the same issue with http? HTTP we know works, I don't know how robust tnfs is, you're sure it's not a bug in tnfs server then. Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4787813 Share on other sites More sharing options...
tschak909 Posted March 26, 2021 Author Share Posted March 26, 2021 3 hours ago, cathrynm said: That's pretty weird. And you see the same issue with http? HTTP we know works, I don't know how robust tnfs is, you're sure it's not a bug in tnfs server then. An error in my test procedure contaminated the HTTP test. It's okay. The error with TNFS has been traced to the fact that the TNFS_MAX_PAYLOAD size was set to 532 bytes, which, while tnfsd does specify this is the max payload size, this is much too big for practical UDP usage, because it may (And probably will) fragment. In this case, it was leaking some other bit of memory into the transmit buffer. Resetting the TNFS_MAX_PAYLOAD constant to 512 fixed the issue. -Thom 1 Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4787955 Share on other sites More sharing options...
tschak909 Posted March 26, 2021 Author Share Posted March 26, 2021 #FujiNet #Atari8bit Now that libssh2 is embedded into the code and is compiling, I have added a ticket to add an SSH protocol adapter, if anyone wants to try their hand at it. https://github.com/FujiNetWIFI/fujinet-platformio/issues/439 I especially want someone else to do this, so that they can point out to me how incredibly brain damaged my approach is, and hopefully we can make it better. 2 2 Quote Link to comment https://forums.atariage.com/topic/298720-fujinet-a-wip-sio-network-adapter-for-the-atari-8-bit/page/85/#findComment-4787964 Share on other sites More sharing options...
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.