Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

45 Excellent

About apc

  • Rank
    Space Invader

Profile Information

  • Location
    Czech Republic

Recent Profile Visitors

81 profile views
  1. Working on N device protocols ...
  2. 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
  3. 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 Yes, hopefully FujiNet 🙂
  4. Sorry for confusion with The result would be the same if there would be "real" IP address of my PC. 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 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.
  5. Not yet. PROC is used by N device handler and I am at the beginning to make N protocols working on PC.
  6. 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 --> --> local TNFS] Thanks! Jan
  7. Nice! Cross compiled on x86 or compiled on Raspberry/arm? DTR or RTS converted to TTL to SIO PIN 9 (http://mixinc.net/atari/pinouts/sio.htm) Jan
  8. 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
  9. 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.
  10. which seems was wrong / old handler, I will work with DOS folder from now
  11. 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?
  12. 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://" 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:// sioNetwork::parseURL transformed to (N:TNFS://, TNFS:// Parse and instantiate protocol: N:TNFS:// NetworkProtocol::ctor() sioNetwork::open_protocol() - Protocol TNFS opened. NetworkProtocolTNFS::mount(,/MISC/TEST.TXT) TNFS >> TX cmd: MOUNT, len: 6 [0000 00 00] 00 01 2f 00 00 00 Resolving hostname "" Resolved to address 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 "" Resolved to address 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:// 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 "" Resolved to address 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 "" Resolved to address 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 "" Resolved to address 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 "" Resolved to address 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
  13. Why it would be necessary to load mini-boot to do a mount all? With mount-all option enabled, wouldn't be FN adapter able to mount the hosts/images upon startup without being told by Atari? Or maybe instead of mounting all at startup, if there would be some auto-mount enable option, the host/image could be auto-mounted when first accessed by Atari. Commands which do not access media (disk image) can be handled based on what is in configuration file (like STATUS?) and commands which needs to access the media will trigger the mount, if not yet mounted. Would that be possible?
  14. Oh yes me too :-) That's the reason I have started with it! The small issue with N: is that it uses one extra signal (PROCEED PIN) which is not carried by standard SIO2PC adapter (at least not on my home made from 90's). I think, for the old MAX232 it would be possible to wire unused receiver. I am not sure if some more recent SIO2USB adapters (available on the internet) can pass this signal? Anyone knows? Jan
  • Create New...