Jump to content
apc

Need help with N device / handler

Recommended Posts

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

 

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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 ;-)

Share this post


Link to post
Share on other sites
1 minute ago, _The Doctor__ said:

confusing isn't it...

Sorry, stuff moving very fast. 😢

 

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Nominally, this would be an invalid address, but he's hosting the firmware on his PC (in a patched form).

-Thom

 

 

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

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.

 

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

I honestly have no problem with, and support this, something interesting might just come of it :)

 

-Thom

 

  • Like 2

Share this post


Link to post
Share on other sites
Posted (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 by _The Doctor__

Share this post


Link to post
Share on other sites

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 🙂

 

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...