Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Everything posted by apc

  1. Hi, I put some asm code together to make Config loader: It uses HSIO routines by HiassofT for faster load (on not modded Atari). Short video: https://youtu.be/kgvbemvtdDg In case of interest I will prepare disk image to test and share the code. Jan
  2. Ops, would be more precise. @_The Doctor__ thanks for pointing this out. Any signal from regular RS232 cannot be connected directly to SIO. I meant RTS signal from USB to TTL converter. When planning to share SIO port with other devices, better to use diode, similar to the one for TxD signal on provided link (TheMontezuma replied to rcamp48)
  3. Yes. For most of emulated devices (disks, printer, modem) and FujiNet config the regular SIO2PC should work. N: device handler (network access) needs one extra link/signal which is likely not present on old style SIO2PC (attaches to serial port on PC, I had to extend my old SIO2PC to pass this extra signal). I have no exp. with modern devices like SIO2USB or SIO2BT, there is some chance the signal is carried. Another option would be to build cable similar to: ...and connect RTS to PROCEED pin on SIO Jan
  4. @a8isa1 Was your XEX file (without the file extension) working before? If you can rename the file, to end with ".xex" (or ".com" or ".bin") will it work? The code is (I guess for long time) detecting the XEX based on above listed file extensions.
  5. 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...
  6. 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
  7. 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?
  8. 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
  9. Working on N device protocols ...
  10. 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
  11. 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 🙂
  12. 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.
  13. Not yet. PROC is used by N device handler and I am at the beginning to make N protocols working on PC.
  14. 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
  15. 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
  16. 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
  17. 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.
  18. which seems was wrong / old handler, I will work with DOS folder from now
  19. 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?
  20. 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
  21. 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?
  22. 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
  23. 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
  24. Almost forgot to mention, I have succeeded with macOS build 🙂 Running fujinet on macOS inside KVM
  • Create New...