Jump to content

apc

New Members
  • Content Count

    87
  • Joined

  • Last visited

Posts posted by apc


  1. On 11/23/2021 at 8:42 PM, a8isa1 said:

    Can all this be done from linux,  Altirra running under wine and netsio-hub launched natively?

    Yes!

     

    On 11/23/2021 at 8:42 PM, a8isa1 said:

    I ask because I see the following things:

    30967363_Screenshotfrom2021-11-2601_59_55.thumb.png.d61ca44fc36d478cfba17aa7ff6f52be.png

     

    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:

    1342473230_Screenshotfrom2021-11-2602_12_55.thumb.png.2d53457e0aa1c27e8948a6349bd94d75.png

    @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:Selection_038.thumb.png.e1a57d7a2d8aff47759569cf242c9d2b.png

     

    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. On 11/23/2021 at 8:42 PM, a8isa1 said:

    ah. thanks.  names had me confused. when I saw FujiNet I thought this meant the physical device, having forgotten that the executable for Fujinet-PC is called "fujinet"

     

    On 11/24/2021 at 1:15 AM, _The Doctor__ said:

    yep it's hard to find the right or correct item when it's named the same...

    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 ... ;-)

     

    • Like 1

  3. 8 hours ago, computergui said:

    Any way to confirm that I'm having an issue with the SIO port?

    SIO communication looks OK, no issue there.

     

    8 hours ago, computergui said:

    Boots up, and I can get to the web interface.

    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


  4. 46 minutes ago, _The Doctor__ said:

    so what was or is the final solution so folks don't get hit with crazy logfills exactly?

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

    • Like 2

  5. 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.


  6. 1 hour ago, phaeron said:

    the raw bus commands on the SIO class require raw mode to be turned on ($sio.enable_raw(true)).

    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:

    Quote

    In particular, the $timestamp variable is thread-local. In an SIO script, it always gives the timestamp of the start of script execution regardless of suspend points within the script.

     

     

    1 hour ago, phaeron said:

    That's a bug, unfortunately -- the script compiler is not throwing an error as it should here.

    Ok, I see.

     


  7. 33 minutes ago, phaeron said:

    $timestamp should work in either case, it's set whenever a thread resumes execution

    $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);
        }
    }
    Quote

    Both methods will block execution, as emulation is single-threaded due to synchronization and determinism.

    OK.

    36 minutes ago, phaeron said:

    The main difference between using an event handler and a thread is that event handlers can't do anything that requires emulation to pass, so they can't execute asynchronous calls like send_raw_byte(). The event handler has to delegate to a thread to do this.

    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.

     


  8. 31 minutes ago, mozzwald said:

    compile it without DEBUG ?

    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()?


  9. 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

     

    • Like 1

  10. 4 hours ago, JohnBuell said:

    Thom was kind enough to show me where to alter the code. From the root directory in fujinet-pc, it's /lib/http/httpService.cpp - change "8000" and recompile the file for each instance you want to run. Now I have one instance with a web service on 8881, and a second on 8882, both running over SIO2PC/USB cables.

     

    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 http://0.0.0.0:8881
    
    # to serve web interface only on specific interface/address, on port 8882
    ./fujinet -u http://192.168.192.168:8882
    
    # to limit the web interface only for machine which is running fujinet
    ./fujinet -u http://127.0.0.1:8000
    # or
    ./fujinet -u http://localhost:8000
    

    :-)

    • Like 4

  11. @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

    • Like 1

  12. On 7/1/2021 at 4:05 PM, pirx said:

    cannot wait to see it in atari800 and altirra :))))))))))))))))

    quick & dirty attempt:

    Altirra-CUSTOMDEV-1600.thumb.png.c4f20d87bcf83b0f4915d9543db7fa1f.png

     

    Altirra-CUSTOMDEV2-1600.thumb.png.c21316329b5184cfe4566e14796f97cc.png

     

    It's proof of concept, trying to make SIO over UDP exposed by Altirra custom device and FujiNet connected to this "NetSIO bus".

     

    🙂 Jan

    • Like 9
    • Thanks 1

  13. 3 hours ago, a8isa1 said:

    Is fujinet-pc at the point of development where it can support Bill Kendrick's ISS.XEX?

    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


  14. Thank you for nice feedback, support from AA members and to all interested into making FujiNet the real thing!

    On 4/21/2021 at 12:26 AM, apc said:

    Credits: @xxl for ZX0 decompression port to 6502 and boot loader @HiassofT for high speed SIO @bocianu for FujiNet banner @pirx for compression ideas

    🙂 Jan

     

    11 hours ago, Mazzspeed said:

    Now, if only my coding skills were better!

    You can start anytime! I am always surprised I can do LDX addr,Y ;-)

    • Like 4

  15. On 4/25/2021 at 1:36 PM, Mazzspeed said:

    Is this part of Fujinet-PC yet? Don't crucify me, just askin'. ;)

    Yes ... for couple of last minutes ;-)

    You can just grab above attached file and replace old autorun.atr file - rename autorun-zx0.atr to autorun.atr and put it into fujinet-pc/build directory (if running fujinet from there)

     

    • Like 1
×
×
  • Create New...