apc Posted March 3, 2021 Share Posted March 3, 2021 I started to play with N: device for FujiNet-PC (FujiNet running on PC and communicating via SIO2PC/USB). I am not sure if the observed behavior is the expected one. I need some help to understand it. On PC currently I have only TEST and TNFS protocols. Doing tests with this basic prog on Atari: 5 REM READFILE.BAS 10 REM OPEN #1,4,0,"D2:TEST.TXT" 15 REM OPEN #1,4,0,"N:TEST://BLAH/BLA" 20 OPEN #1,4,0,"N:TNFS://127.0.0.1/MISC/TEST.TXT" 30 REM TRAP 70 40 GET #1,C 50 PRINT CHR$(C); 60 GOTO 40 70 CLOSE #1 Lines 10, 15, 20 opens different path/file, only one open is used for test, other two are commented out. Open at line 10 and 15 followed by read byte at line 40 works as expected. I can get the file content (from D2:TEST.TXT) or generated text (from N:TEST). I have trouble to read byte from TNFS file. Open does not report error but any read ends with error 136 - end of file. Here is the OPEN# command observed on FujiNet end: I am not sure why the file is read by FujiNet immediately after open. File is loaded into FujiNet and EOF is reached on TNFS server. Can be, ok. CF: 71 4f 04 00 c4 sioNetwork::sio_process 0x4f 'O': 0x04, 0x00 sioNetwork::sio_open() write: 1 ACK! <-SIO read 256 bytes read: 0 read: 23 read: 30 read: 30 read: 30 read: 31 read: 30 read: 30 read: 30 read: 22 read: 1 write: 1 ACK! sioNetwork::parseURL(N:TNFS://127.0.0.1/MISC/TEST.TXT) sioNetwork::parseURL transformed to (N:TNFS://127.0.0.1/MISC/TEST.TXT, TNFS://127.0.0.1/MISC/TEST.TXT) Parse and instantiate protocol: N:TNFS://127.0.0.1/MISC/TEST.TXT NetworkProtocol::ctor() sioNetwork::open_protocol() - Protocol TNFS opened. NetworkProtocolTNFS::mount(127.0.0.1,/MISC/TEST.TXT) TNFS >> TX cmd: MOUNT, len: 6 [0000 00 00] 00 01 2f 00 00 00 Resolving hostname "127.0.0.1" Resolved to address 127.0.0.1 TNFS << RX cmd: MOUNT, len: 5, response (0): Success [6a57 00 00] 00 02 01 e8 03 _tnfs_transaction completed in 2 ms NetworkProtocolFS::resolve(/MISC/TEST.TXT,/MISC/,TEST.TXT) TNFS >> TX cmd: STAT, len: 15 [6a57 01 24] 2f 4d 49 53 43 2f 54 45 53 54 2e 54 58 54 00 Resolving hostname "127.0.0.1" Resolved to address 127.0.0.1 TNFS << RX cmd: STAT, len: 23, response (0): Success [6a57 01 24] 00 a4 81 e8 03 e8 03 2a 00 00 00 04 ad 3f 60 2d ac 3f 60 c9 ac 3f 60 _tnfs_transaction completed in 2 ms Resolved to TNFS://127.0.0.1/MISC/TEST.TXT TNFS >> TX cmd: STAT, len: 15 [6a57 02 24] 2f 4d 49 53 43 2f 54 45 53 54 2e 54 58 54 00 Resolving hostname "127.0.0.1" Resolved to address 127.0.0.1 TNFS << RX cmd: STAT, len: 23, response (0): Success [6a57 02 24] 00 a4 81 e8 03 e8 03 2a 00 00 00 04 ad 3f 60 2d ac 3f 60 c9 ac 3f 60 _tnfs_transaction completed in 2 ms TNFS open file: "/MISC/TEST.TXT" (0x0001, 0x0000) TNFS >> TX cmd: OPEN, len: 19 [6a57 03 29] 01 00 00 00 2f 4d 49 53 43 2f 54 45 53 54 2e 54 58 54 00 Resolving hostname "127.0.0.1" Resolved to address 127.0.0.1 TNFS << RX cmd: OPEN, len: 2, response (0): Success [6a57 03 29] 00 00 _tnfs_transaction completed in 2 ms File opened, handle ID: 0, size: 42, pos: 0 write: 1 COMPLETE! SIO CMD processed in 157 ms NetworkProtocolFS::read_file(42) tnfs_read fh=0, len=42 _tnfs_read_from_cache: buffpos=0, cache_start=0, cache_avail=0, dest_size=42, dest_used=0 _tnfs_read_from_cache - nothing in cache _TNFS_FILL_CACHE fh=0, file_position=0 _tnfs_fill_cache requesting 512 bytes TNFS >> TX cmd: READ, len: 3 [6a57 04 21] 00 00 02 Resolving hostname "127.0.0.1" Resolved to address 127.0.0.1 TNFS << RX cmd: READ, len: 45, response (0): Success [6a57 04 21] 00 2a 00 54 65 73 74 20 74 65 78 74 20 6c 69 6e 65 20 31 9b 6c 69 6e 65 20 32 9b 6c 69 6e 65 20 33 9b 6c 61 73 74 20 6c 69 6e 65 2e 9b _tnfs_transaction completed in 2 ms _tnfs_fill_cache got 42 bytes, 470 more bytes needed _tnfs_fill_cache requesting 470 bytes TNFS >> TX cmd: READ, len: 3 [6a57 05 21] 00 d6 01 Resolving hostname "127.0.0.1" Resolved to address 127.0.0.1 TNFS << RX cmd: READ, len: 1, response (33): End of file [6a57 05 21] 21 _tnfs_transaction completed in 2 ms _tnfs_fill_cache got EOF _tnfs_read_from_cache: buffpos=0, cache_start=0, cache_avail=42, dest_size=42, dest_used=0 TNFS cache providing 42 bytes NetworkProtocol::read(42) Here is the GET# command observed on FujiNet end: Get status and then data read is initiated from Atari. FujiNet sends data to Atari, but error 136 (EOF) is returned even with the first byte read. I would expect to read 42 bytes of data and then EOF. CF: 71 53 00 00 c4 sioNetwork::sio_process 0x53 'S': 0x00, 0x00 write: 1 ACK! sioNetwork::sio_status_channel(0) PROTOCOL sio_status_channel() - BW: 42 E: 136 ->SIO write 4 bytes write: 1 COMPLETE! write: 4 write: 1 SIO CMD processed in 10 ms read: 0 read: 5 CF: 71 52 2a 00 ed sioNetwork::sio_process 0x52 'R': 0x2a, 0x00 sioNetwork::sio_read( 42 bytes) write: 1 ACK! NetworkProtocolFS::read_file(42) NetworkProtocol::read(42) ->SIO write 42 bytes write: 1 COMPLETE! write: 42 write: 1 SIO CMD processed in 36 ms Any idea why N handler does not return bytes obtained from N device? Thanks, Jan Quote Link to comment Share on other sites More sharing options...
tschak909 Posted March 3, 2021 Share Posted March 3, 2021 Can you please use the N:handlers that are a part of the latest fnc-tools or from the DOS folder on atari-apps? Also, are you properly synthesizing the proceed interrupt? you can see where the error 136 is synthesized from inside NetworkProtocolFS (and NetworkProtocolTNFS) -Thom Quote Link to comment Share on other sites More sharing options...
apc Posted March 3, 2021 Author Share Posted March 3, 2021 For the test I was using n-handler-dosxl.atr from atari-apps.irata.online from tests directory. I will focus on proceed signal as it looks like suspect. Maybe I was just too optimistic to see TEST protocol coming out with data easily Is the N handler working in a way it expects proceed interrupt for any incoming data? I mean even for traditional request / wait / response exchange? Quote Link to comment Share on other sites More sharing options...
apc Posted March 3, 2021 Author Share Posted March 3, 2021 39 minutes ago, apc said: For the test I was using n-handler-dosxl.atr from atari-apps.irata.online from tests directory. which seems was wrong / old handler, I will work with DOS folder from now Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted March 3, 2021 Share Posted March 3, 2021 confusing isn't it... Quote Link to comment Share on other sites More sharing options...
tschak909 Posted March 3, 2021 Share Posted March 3, 2021 1 minute ago, _The Doctor__ said: confusing isn't it... Sorry, stuff moving very fast. ? Quote Link to comment Share on other sites More sharing options...
apc Posted March 3, 2021 Author Share Posted March 3, 2021 well, it's WIP and if something goes wrong there is a good place to ask now I am not getting anymore error 136, now it seems it's hanging somewhere ... only reset helps Is it this? GET: JSR GDIDX ; Unit into X LDA RLEN,X ; Get current RX len from last STATUS BNE GETDRN ; If RLEN > 0 then drain. ;; Otherwise, we wait for something to happen. GETWAI: JSR ENPRCD ; Enable Proceed LDA TRIP ; Did trip change? BEQ GETWAI ; Nope, not yet... Maybe break key handling can be added to get outside the loop. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted March 3, 2021 Share Posted March 3, 2021 Yes, it's waiting for bytes to show up via the PROCEED interrupt. -Thom Quote Link to comment Share on other sites More sharing options...
apc Posted March 3, 2021 Author Share Posted March 3, 2021 Ok, I have to think about it. I knew the PROCEED line is utilized by FujiNet to notify the Atari when there is something to receive. I thought about notification when some asynchronous data arrives but it seems it's used more that I thought. Which means, to be able to use N device with FujiNet-PC port, "slightly" enhanced SIO2PC must be used. Not sure how much attractive the PC version will be then. I hoped to get at least some N device functionality (FS protocols) available with standard SIO2PC... stop *peQt, start FujiNet and enjoy new dimensions Jan Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted March 3, 2021 Share Posted March 3, 2021 The AtariMax SIO 2 PC usb provides a path to extra control lines such as this... it is also fast enough to switch baud rates for certain SIO protocols like the XF551 etc... So your dream still lives. Steven Tucker might appreciate your endeavor and help out, might not... @classics any thoughts? Quote Link to comment Share on other sites More sharing options...
Dr Memory Posted March 5, 2021 Share Posted March 5, 2021 Dumb question. 127.0.0.1 is normally the loopback address, which tells a network stack to connect to the local host. Is that really what you want it to do? I would think this would be the Atari itself in this case, and that you'd want this to be the address of the PC running TNFS. But I could very well be entirely wrong, as I haven't tried TNFS yet and am basing this suggestion on decades of experience with IP networking. Maybe they did it that way on purpose, and there is configuration somewhere that tells Fujinet to route such connections to another IP address, I dunno. I'm keying off of the statement that you're trying to connect to a PC using a protocol running atop IP and the address used only. Sorry if this turns out to be a dumb comment. Quote Link to comment Share on other sites More sharing options...
apc Posted March 6, 2021 Author Share Posted March 6, 2021 Yes, it's address for loopback interface. Not on Atari itself, it is not running IP stack, but it can be FujiNet HW module and if TNFS server would be running on it, loopback can be used to connect FujiNet with local TNFS server. In my case it is like this: [Atari] --> SIO2PC --> [PC "doing" FujiNet --> 127.0.0.1 --> local TNFS] Thanks! Jan Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted March 6, 2021 Share Posted March 6, 2021 so what happens when a program on the Atari itself tries to do loopback? Quote Link to comment Share on other sites More sharing options...
Dr Memory Posted March 6, 2021 Share Posted March 6, 2021 On 3/3/2021 at 12:36 PM, apc said: I started to play with N: device for FujiNet-PC (FujiNet running on PC and communicating via SIO2PC/USB). So when the OP says that, and tries this 20 OPEN #1,4,0,"N:TNFS://127.0.0.1/MISC/TEST.TXT" Does that mean that the file he is trying to open is on a TNFS: server running on the same PC he's running FujiNet on? I guess I got confused when he mentioned he was communicating via SIO2PC/USB. It seemed like one end or the other should be on an Atari, but maybe he's looping back to the PC? Not sure I am visualizing this properly. I only posted because I find IP/routing/protocol stuff pretty easy to debug usually, but then I usually have a better idea of how things are configured and what is being attempted. I'll shut up now. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted March 6, 2021 Share Posted March 6, 2021 Nominally, this would be an invalid address, but he's hosting the firmware on his PC (in a patched form). -Thom Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted March 6, 2021 Share Posted March 6, 2021 I should think anything I send to to 127.0.0.1 from the Atari to the fujinet should be transferred from the fujinet out buffer to the fujinet in buffer and fed back to the Atari... how the fujinet handles it's own 127.0.0.1 should be as per usual... since the fujinet is a middle box translator for the Atari of sorts that pseudo step might be needed for certain things of the future to work... who knows what people are going to do Quote Link to comment Share on other sites More sharing options...
apc Posted March 6, 2021 Author Share Posted March 6, 2021 Sorry for confusion with 127.0.0.1 The result would be the same if there would be "real" IP address of my PC. 5 hours ago, _The Doctor__ said: I should think anything I send to to 127.0.0.1 from the Atari to the fujinet should be transferred from the fujinet out buffer to the fujinet in buffer and fed back to the Atari... Not necessarily, each IP can be used by many services/programs, each service accepting connections on it's own port. There is usually some default port, which is used when port is not explicitly specified. In case of TNFS, port 16384 is used by default. Fujinet out buffer goes to 127.0.0.1 port 16384 which is handled by NTFS server/program. With another port (explicitly specified), out buffer will go to another program, e.g. 80 will end up on web server. Back to topic. My hardware skills are very limited. Small victory was to adapt MAX232 SIO2PC adapter to pass PROCEED signal Now reading the file via N: from NTFS server works! So to answer my own question: Yes, expected behavior. By design, N: device handler relies on PROCEED signal, without that it does not work. 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted March 6, 2021 Share Posted March 6, 2021 The point is anything that opens a port on the Atari itself using ip 127.0.0.1 should connect to that port on the Atari...The fujinet should handle it that way... but the fujinet has it's own layer for itself and should handle it's own 127.0.01 connections as per usual... since it is acting as an access controller for itself and the Atari. You are forgetting the Atari can serve it's own web pages... are you going to let fujinet stop this from happening and intercept certain ports from working on the Atari itself? There already are web servers and and telnet servers for the Atari. The fujinet has to allow the Atari to work like any other machine would and connect to it's own Atari ports. The TNFS server has it's own ip and port... why would 127.0.0.1 connect to it? I could see fuji making that happen to the local hard drive storage on the sd card if it's serving, or a local on the fujinet server of any kind but not a somewhere on the network file server(any other server for that matter out on the network)... I guess the problem is saying this all correctly and actually having a visual aid to help with the process. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted March 6, 2021 Share Posted March 6, 2021 oh hell, your doing this as the on the pc ported fujinet... I still think it's best to keep them all as if they were individual devices as if they are the real thing though... this can become a bit messy for the masses. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted March 6, 2021 Share Posted March 6, 2021 I honestly have no problem with, and support this, something interesting might just come of it -Thom 2 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted March 6, 2021 Share Posted March 6, 2021 (edited) I support it, with the caveat that it's still acting as its' own virtual device on the pc, like any other simulated or emulated item. I could see it leading to working with altirra or real machine via usb or rs232 port. The plumbing being outside the virtual device if at all possible or if fixes need to be, it may benefit the real fujinet device uncovering things that are needed to move fujinet forward. Edited March 6, 2021 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
apc Posted March 6, 2021 Author Share Posted March 6, 2021 There is not so big difference between them. First one is small computer attached to SIO port and the second one is big computer connected to SIO port Some differences are in hardware like CPU, IO ports, etc., running different Operating Systems 1 hour ago, tschak909 said: I honestly have no problem with, and support this, something interesting might just come of it Yes, hopefully FujiNet ? Quote Link to comment Share on other sites More sharing options...
apc Posted March 7, 2021 Author Share Posted March 7, 2021 I was playing with FTP protocol: https://github.com/FujiNetWIFI/fujinet-platformio/wiki/Testing-against-FTP-Server. Wiki navigates user to final directory in 3 steps, NCD command is used 3 times. This works OK. I have just noticed, when trying to go there in one step, like: NCD N:FTP://FTP.PIGWA.NET/stuff/collections/holmes cd/Holmes 2/Atari Archives/Antic Files/88/ it does not work, display is broken (display list to random stuff), Atari not responding, reset helped. Seems it is DOS XL problem with long command line. Good to be aware of. No problem when running NCD in interactive mode (without command line parameters). When prompted by NCD, the long prefix can be entered and it is changed. Seems interactive mode is safe way. Please can someone confirm if listing FTP with NDIR in above directory does work for him? D1:NCD ENTER PREFIX OR ... FTP://FTP.PIGWA.NET/stuff/collections/holmes cd/Holmes 2/Atari Archives/Antic Files/88/ D1:NPWD FTP://FTP.PIGWA.NET/stuff/collections/holmes cd/Holmes 2/Atari Archives/Antic Files/88/ D1:NDIR At this moment I am not sure the issue is on my end only or if it's present in main FuJinet code too. log: 20:20:21.986722 Name: CLASSMAK.BAS filesize: 2688 )0:20:21.986766 fnFTP::read_directory(-rwxrwxr-- 1 5002 6504 5708 Nov 10 2002 COCKTAIL.DAT 20:20:21.986809 Name: COCKTAIL.DAT filesize: 5708 )0:20:21.986851 fnFTP::read_directory(-rwxrwxr-- 1 5002 6504 7684 Nov 10 2002 COCKTAIL.MIC 20:20:21.986894 Name: COCKTAIL.MIC filesize: 7684 20:20:21.986954 fnFTP::read_directory(-rwxrwxr-- 1 5002 6504 ) 20:20:21.987001 terminate called after throwing an instance of 'std::logic_error' 20:20:21.987046 what(): basic_string::_M_construct null not valid from some reason read_directory (fnFTP.cpp) gets incomplete line (file size, date and name are missing), without file name the function ftpparse does not set the parse.name, std::string fails on null pointer and program is terminated. I only hot fixed read_directory function to prevent crash: name = string(parse.name ? parse.name : "???"); Jan Quote Link to comment Share on other sites More sharing options...
tschak909 Posted March 7, 2021 Share Posted March 7, 2021 FTP protocol adapter is very broken at the moment. -Thom Quote Link to comment 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.