Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Everything posted by apc

  1. Yes! Current netsio.atdevice works with 3.90 and 4.00-testNN (same custom device file). The things has changed slightly with Altirra 4.00 release. It stopped to work in 4.00 release due to small workaround for 3.90: @phaeron not sure, if I am doing something wrong ^^^ It looks like thread in 3.90 is created but not switched into, waiting for next switch. Thread.sleep() helped me to switch. But this is guarded now 🙂 Any idea for better solution? @a8isa1 For quick fix you can edit the netsio.atdevice file and comment out "Thread.sleep(400)" on lines 265 and 271: If I will not find a better way, I will prepare netsio.atdevice in two versions, for 3.90 and for 4.00. Jan
  2. Yes, FujiNet is correct. The code is prepared for both FujiNet-PC as well for the hardware FujiNet 🙂 The firmware with this code has not been released yet. Coming soon ...
  3. The windows port is most challenging one for me. Lack of programming experience in windows, many traps I enter. But I'm still learning and making progress slowly. 🙂 Jan
  4. Maybe you can connect other 2 PINs of your FTDI based adapter, COMMAND and PROCEED. Then you can use hi-speed SIO and you can play with FujiNet too 🙂
  5. SIO communication looks OK, no issue there. How did you get there? Was the CONFIG working for some time to allow you to select the WiFi+password? Could you mount some known ATR disk image as D1: via web interface and then press "Option" on Atari to try to boot into it. If booted after pressing Option key the issue could be with setting up the display at CONFIG startup... interesting, no others reported this, AFAIK. Anyone with A800/48K can check and report? Jan
  6. Happy emulating with 4.00-test39 🙂 CUSTOMDEV: Hi CUSTOMDEV: event CMD ON 58910483 CUSTOMDEV: thread CMD ON 58910484 CUSTOMDEV: event CMD OFF 58917924 CUSTOMDEV: thread CMD OFF 58917925 CUSTOMDEV: event CMD ON 58976893 CUSTOMDEV: thread CMD ON 58976894 CUSTOMDEV: event CMD OFF 58983871 CUSTOMDEV: thread CMD OFF 58983872
  7. Take care when making your TNFS server reachable from wild world. Ensure only UDP port 16384 is exposed. In general, follow security practices: - restrict TNFS to vm/container/jail/chroot/etc. - run it with dedicated user - limit the permissions on files/dirs to allow only read access - be prepared, bad ass will exploit it - do backups I am not security expert, I'm sure someone can add more rulz
  8. Time to move to 4.00 🙂 Thanks a lot for helping on this topic! Jan
  9. It looks like a bug in tnfs/tnfsd/datagram.c I can trigger crazy tnfsd output with netcat (or telnet) to TCP port 16384 (which is open by tnfsd): $ nc localhost 16384 # just hit ctrl+c to close the connection ^C $ And you will get: DEBUG: rx of tcpmsg: 0 bytes: � DEBUG: rx of tcpmsg: 0 bytes: � DEBUG: rx of tcpmsg: 0 bytes: � DEBUG: rx of tcpmsg: 0 bytes: � ... Currently, if you are running any network probes to the TCP port 16384 (network scanning or service monitoring) it will make tnfsd very unhappy.
  10. I am calling $sio.enable_raw(true) in cold_reset (only there). I believe, it is running in raw mode, the waits are working. The output corresponds to SIO activities. It is not like one shot and stop (by VM). Only $timestamp is not updated. Running this test... function void command_thread_handler() { Debug.log("Hi"); loop { $sio.wait_command(); Debug.log_int("thread CMD ON ", $timestamp); $sio.wait_command_off(); Debug.log_int("thread CMD OFF ", $timestamp); } } event "sio_command_changed": function { if ($sio.command_asserted()) { Debug.log_int("event CMD ON ", $timestamp); } else { Debug.log_int("event CMD OFF ", $timestamp); } }; ...is producing result like this. Only $timestamp in thread is not changing but waits in thread corresponds with command level changes captured by event handler. CUSTOMDEV: Hi CUSTOMDEV: event CMD ON 82819965 CUSTOMDEV: thread CMD ON 46135568 CUSTOMDEV: event CMD OFF 82828552 CUSTOMDEV: thread CMD OFF 46135568 CUSTOMDEV: event CMD ON 82870396 CUSTOMDEV: thread CMD ON 46135568 CUSTOMDEV: event CMD OFF 82877359 CUSTOMDEV: thread CMD OFF 46135568 ... Maybe it is expected behavior. From help: Ok, I see.
  11. Wait, in sample device rverter.atdevice in "network_interrupt" handler the send_raw_byte() is called. I am confused now. Is network_interrupt handler different from other handlers as the source of the event is not emulator (but device server)?
  12. $timestamp variable was not changing when used in thread, not sure what can be wrong: function void command_thread_handler() { loop { $sio.wait_command(); $network.post_message($11, 0); Debug.log_int("CMD ON ", $timestamp); $sio.wait_command_off(); $network.post_message($10, 0); Debug.log_int("CMD OFF ", $timestamp); } } OK. Oops, I have to fix my "network_interrupt" handler which is calling send_raw_byte() directly! (but it was working somehow). I assume to set a PIN with set_proceed() or set_command() should be fine from event handler.
  13. It will not help in this case, ... tnfs/tnfsd/datagram.c printf("DEBUG: rx of tcpmsg: %d bytes: %s\n", sz, buf); I am wondering are you connecting to or listening on TCP? NTFS runs usually over UDP. Edit: Hmm, tnfsd seems to be listening always on both, UDP and TCP. The question is what triggers TCP handler in your case (as there is 0 bytes available from your logs)? Strange select()?
  14. I am trying to debug and understand some timing issues. @phaeron I have a dilemma, better to use event handler, like "sio_command_changed" or separate thread with loop doing $sio.wait_command(); ... $sio.wait_command_off(); ... ? To be able to use $timestamp I switched from thread/loop to event handler... not sure is there any significant difference between above two methods. Event handler blocks the emulator execution, thread based handler does not? Jan
  15. Missing hardware buttons on fujinet-pc ... at least I added Restart button into web interface. 2021-08-23_20-26-12.mp4 If interested, pick the code from GitHub, build it and run it with: ./run-fujinet run-fujinet is simple wrapper script to start fujinet executable and to restart it if it previously exited with specific exit code. 🙂 Jan
  16. Command line option was added -u URL , to specify URL the web server should listen on. Updated code is available as usually on https://github.com/FujiNetWIFI/fujinet-pc After new build, you can start fujinet with -u option like this: # to serve web on all available interfaces/addresses, on port 8881 ./fujinet -u # to serve web interface only on specific interface/address, on port 8882 ./fujinet -u # to limit the web interface only for machine which is running fujinet ./fujinet -u # or ./fujinet -u http://localhost:8000 :-)
  17. @phaeron I started to play with this. Found your sampledevices and deviceservers (+ Altirra help) very helpful to make first steps. Thanks for it! I am dealing now with serial port speed change and how to detect it. Altirra always provides proper output bytes to custom device - provided output does not depend on speed. On FujiNet side the toggle between standard speed and high speed is based on detecting checksum errors in received frames - but this does not happen with custom device. Do you have some idea how to detect the serial output speed change in custom device? Then it would be possible to notify the receiver to toggle its speed too. Jan
  18. quick & dirty attempt: It's proof of concept, trying to make SIO over UDP exposed by Altirra custom device and FujiNet connected to this "NetSIO bus". 🙂 Jan
  19. I guess you are running some older version. HTTP protocol handler was added later in April. Try it with latest code https://github.com/FujiNetWIFI/fujinet-pc As a bonus APOD - http://www.newbreedsoftware.com/fujinet-apod/ should work too 🙂 Jan
  20. Yes. It should work. Plain HTTP request-response called by ISS.XEX is handled by fujinet-pc just fine. You should get similar output in terminal to each ISS update (Open, Status, Read, Close): CF: 71 4f 04 00 c4 sioNetwork::sio_process 0x4f 'O': 0x04, 0x00 sioNetwork::sio_open() write: 1 ACK! Deleting existing rateTimer <-SIO read 256 bytes read: 0 read: 24 read: 30 read: 30 read: 31 read: 30 read: 30 read: 30 read: 30 read: 21 read: 1 write: 1 ACK! sioNetwork::parseURL(N:HTTP://api.open-notify.org/iss-now.json) sioNetwork::parseURL transformed to (N:HTTP://api.open-notify.org/iss-now.json, HTTP://api.open-notify.org/iss-now.json) Parse and instantiate protocol: N:HTTP://api.open-notify.org/iss-now.json NetworkProtocol::ctor() sioNetwork::open_protocol() - Protocol HTTP opened. NetworkProtocolHTTP::mount(HTTP://api.open-notify.org/iss-now.json) mgHttpClient::begin "http://api.open-notify.org/iss-now.json" NetworkProtocolFS::resolve(/iss-now.json,/,iss-now.json) Resolved to http://api.open-notify.org/iss-now.json NetworkProtocolHTTP::open_file_handle() write: 1 COMPLETE! SIO CMD processed in 149 ms +read: 0 read: 5 CF: 71 53 00 00 c4 sioNetwork::sio_process 0x53 'S': 0x00, 0x00 write: 1 ACK! sioNetwork::sio_status_channel(0) PROTOCOL Channel mode is 0 mgHttpClient::GET 000b2d39 _perform Connected Status: 200 Received: 295 Header0: Server = nginx/1.10.3 Body: 113 bytes 000b2e9f _perform status = 200, length = 0, chunked = 0 sio_status_channel() - BW: 113 C: 1 E: 1 ->SIO write 4 bytes write: 1 COMPLETE! write: 4 write: 1 SIO CMD processed in 369 ms -read: 0 read: 5 CF: 71 52 71 00 35 sioNetwork::sio_process 0x52 'R': 0x71, 0x00 sioNetwork::sio_read( 113 bytes) write: 1 ACK! NetworkProtocolFS::read_file(113) NetworkProtocolHTTP::read_file_handle(0x55bbcef9eb90,113) NetworkProtocolHTTP::read_file_handle_data() ::read from buffer 113 NetworkProtocol::read(113) ->SIO write 113 bytes write: 1 COMPLETE! write: 113 write: 1 SIO CMD processed in 66 ms +read: 0 read: 5 CF: 71 43 00 00 b4 sioNetwork::sio_process 0x43 'C': 0x00, 0x00 sioNetwork::sio_close() write: 1 ACK! NetworkProtocolHTTP::close_file_Handle() mgHttpClient::close NetworkProtocolHTTP::umount() mgHttpClient::close 2021-06-30 16:27:56 I mongoose.c:2091:mg_mgr_fr All connections closed write: 1 COMPLETE! NetworkProtocol::dtor() SIO CMD processed in 6 ms Jan
  21. Nice! Thx NB: C'est la Vie - happy to make money like this 🙂
  22. Thank you for nice feedback, support from AA members and to all interested into making FujiNet the real thing! 🙂 Jan You can start anytime! I am always surprised I can do LDX addr,Y
  • Create New...