Jump to content

apc

New Members
  • Content Count

    87
  • Joined

  • Last visited

Everything posted by apc

  1. oh yes, the look at diff scares me. I am not sure how to do it, if to add dozens of #ifdefs into the code and how to include sometimes completely different files into the build process...
  2. Give it a chance 🙂 https://github.com/a8jan/fujinet-mount-and-boot User still can sit and wait as before, if he likes (on PAL the boot is delayed by 5 sec.). Those impatient like me can start pressing some buttons to boot
  3. Nice 🙂 Random idea, some images requires OPTION button pressed at boot. Small enhancement would be to allow OPTION to start booting immediately without a need to wait with OPTION held down. It can work like this: detect OPTION is being pressed, write some message, wait short time (to allow user to release OPT in case BASIC must stay enabled) and cold start. What do you think?
  4. What about to add new SIO command into FujiNet, kind of mount all? This would move the work from Atari to Fuji and save quite amount of SIO calls for quicker mount & boot. Jan
  5. Working on N device protocols ...
  6. 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
  7. 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 🙂
  8. Sorry for confusion with 127.0.0.1 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 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.
  9. Not yet. PROC is used by N device handler and I am at the beginning to make N protocols working on PC.
  10. 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
  11. 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
  12. 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
  13. 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.
  14. which seems was wrong / old handler, I will work with DOS folder from now
  15. 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?
  16. 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
  17. 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?
  18. 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
  19. Added basic browser into web interface. Click host name to open host browser: "Navigation bar": To upper directories To root directory Back to main page Mounting and unmounting images: Downloading file: Jan BTW WOW to Albert !!! I thought my XE is 8-bit
  20. Almost forgot to mention, I have succeeded with macOS build 🙂 Running fujinet on macOS inside KVM
  21. For now I placed sources here: https://github.com/a8jan/fujinet-pc We can move it to fujinet sub-repo if the offer is still valid ... after you will see the mess I did in a code 😇
  22. Disable Config boot in web interface? Oh, you don't like the web interface 🙂 On the other hand I understand your point the Config boot should be controllable just with minimal effort, like pressing the button, etc. - but isn't it already (not sure, I am not owner yet)? In my post I described additional changes I did while working on PC port. They are not necessary for original FujiNet. As mentioned, without FN hardware, without buttons, the web interface is the way to control some configuration and maybe someone can find it interesting for original FN too
  23. (again, seems I lost the post before submitting) I need this functionality for my PC port of FujiNet too E.g. without Fuji HW, on PC version I have no button to rotate images... I need to add some CLI or TextUI or use existing WebUI. I have started with WebUI already. So far it is possible browse local SD and remote TNFS and download files. For some time I was struggling with serial port on macos, but now I am again working on "mount page" with options to select drive slot and mount mode to mount the image. If interested, I think this feature/hack can be ported back to fujinet-platformio. Jan
  24. I agree with the idea of simple Config tool and the file manager as a separate program. Currently provided copy feature bundled with Config tool is a good compromise until file manager will be written by some nice volunteer. For the file manager, set of SIO commands to watch/control the copy progress would be nice to have. This would allow to update progress bar, do background copy, etc. - just ideas for future, nothing to worry now Thanks for current copy feature Previously, I tried to copy some disk image from remote to local and the process was ... not very smooth. (seems I should improve TNFS in Linux port I started or to order real hardware :-)
×
×
  • Create New...