Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Everything posted by apc

  1. 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
  2. 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
  3. Nice! Thx NB: C'est la Vie - happy to make money like this 🙂
  4. 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
  5. 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)
  6. I do not see much difference. It is so fast capture device cannot get it It must be true. It's on YouTube! Config loader presented in a format which young generation can understand. 🙂 Jan
  7. workaround: mkdir tools/pack/a8 going to put some placeholder file there to keep the a8 dir in git
  8. ok, give me a minute, i guess, git does not store empty directory ...
  9. - mount as D1: and boot - CONFIG should load - mount as D2: with some DOS disk in D1: boot DOS and load CONFIG - CONFIG should load - replace autorun.atr with autorun-zx0.atr (rename to autorun.atr), build firmware image, test with firmware @mozzwald can you test if the loader build process works (git clone ... make dist) on your side? then we can test if build process works on WSL .. would be nice
  10. Config loader update! After exercising with all the helper scripts and tools, here is an image which contains loader & FujiNet CONFIG (and config tools): autorun-zx0.atr As the name indicates the new ZX0 compression is used. With ZX0 the compressed CONFIG is smaller and it loads a bit quicker compared to LZ4 variant. ZX0 decompression routine was embedded into boot loader. Both Config loader and CONFIG are decompressed while being read from disk. As it was before, HISIO is enabled as soon as possible to speedup SIO transfers and CONFIG is loaded with banner and growing progress bar. Build process was automated, "make dist" should do all the hard work. For this purpose I prepared Python script which acts as very simplified SuperPacker (and other script to prepare somehow relocatable code and other script to update final ATR, and ... it was interesting to get all this working together) As a bonus, once the CONFIG is compressed with ZX0 the file segments are "decorated" to make the result Atari DOS compatible/loadable again. However DOS cannot decompress file segments (there are some exceptions ) so decompression routine is bundled and called prior passing the control to CONFIG. I.e. Same CONFIG file can be loaded by ZX0 capable loader (during boot) with inline decompression and it can be loaded as a regular DOS program later from disk. Credits: @xxl for ZX0 decompression port to 6502 and boot loader @HiassofT for high speed SIO @bocianu for FujiNet banner @pirx for compression ideas 🙂 Source code: https://github.com/a8jan/fujinet-config-loader - branch "zx0" (If everything works fine, will be glad to move into FN repos) Jan
  11. Good! I will add dependencies to the build instructions. Jan
  12. OK. http://<your_pi_address>:8000 at the bottom of the page Jan
  13. I worry, my skills is limited to do that
  14. @billkendrick I believe DLI problem can be addressed 🙂 This is your linked display list with DLI running (+fixed start of screen to work with 4K boundaries), overlapping R-G-B stripes: APOD picture vs Atari (my green seems over saturated): vs vs apod-changed-files.tar.gz Jan
  15. Yes, this is our case. For the combination of display list with interrupt on every scan line the routine must be really quick otherwise it will be entered again and again (new DLIs coming with each new line). Stack will be overwritten many times. Maybe at the end of the screen (no more DLIs) the end of DLI routine will be finally reached, but PLA and RTI is unlikely to get proper data from stack...
  16. @billkendrick IMHO your DLI routine takes too much time. Your DLI must be very fast to handle DL interrupt on every line. Jan
  17. Updated disk image with handcrafted Config Loader using LZ4 boot code aka "Frankenstein loader" 🙂 autorun-lz4.atr Config load time: 3.5s with divisor 0 or 4.5s with divisor 8 Big thanks to @xxl 🙂 for his LZ4 boot code! Jan NB: Need to find a way to automate the build process of this baby and think how to make it runnable (not only boot-loaded) under Frankenstein not-ready DOSes
  18. Attached LZ4 is winner in decompression speed, but the file is slightly larger. EX4 is smaller but slower to decompress (seems it does not work with BASIC ON). Now it's hunt for deci-seconds 🙂 ATR with the above LZ4 packed Config: autorun-cloader-lz4.atr Agree, further optimization possible - banner is currently loaded as uncompressed bitmap, sector 361 is read twice (by PicoBoot, then by Loader), etc. On the other hand, I am not sure I want to spend much time with fine tuning... E.g. If bundled together, the result might not be able to run as standalone program from DOS anymore, PicoBoot routines called by Loader will not be present in memory. Solution would be to include those routines into Loader, increase it's size, compress it, etc. etc .. Looks like extra effort with some chance to save 1 sec. Will keep it on TODO list and glad to support if anyone can explore and progress in this area of improvements @pirx Can you provide packer program command line parameters? @tschak909 for the config/autorun.atr build process, if some utility should be added (like packer), do you need Linux, WSL or native Windows binaries? Jan
  19. Hi Mathy, Understand. Some code for detection can be prepared, tested, etc. The point is, I hope, I don't really need to detect it for the purpose of the Config Loader (as explained above). I thought it would be nice to detect and skip routines bundled with Loader. For now I will keep it as nice to have if no arguments to change it to must have Jan
  20. There is a version with loader and compressed Config: autorun-cloader-zapped.atr However I'm no sure I used SP properly. Compressed config: config.xex The result is.. we saved 3 seconds to load smaller file and it takes 2 seconds to get it decompressed (divisor 0) Some measured numbers to load the Config: original Config at 19200 = 15s compressed Config at 19200 = 8s Loader + compressed Config at 19200 = 9s (cost of banner) Loader + Config, divisor 0 = 6s Loader + compressed Config, divisor 0 = 5s Loader + Config, divisor 8 = 10s Loader + compressed Config, divisor 8 = 7s Both methods nicely boosts the Config loading, best when combined 🙂 Jan
  21. Config Loader should work on 400/800 as far as there is enough RAM for Config itself I cannot test myself, I am not owner of those diamonds. At least I tested with Altirra. The Config was successfully fast loaded by Config Loader on 400 with 48K RAM. I like the idea but the attached crunched COM file does not work for me. I am trying to load it as regular COM/XEX. I'm doing something wrong? Yes, check one by one all possible specific speed code routines 🙂 Really not sure if it's doable (in simple way) to detect all possible routines. It may not be necessary to check at all ... The Config Loader bundled with HiassofT's routines is calling those routines only when loading Config, bypassing ROM routines (stock or modded) just to get this one program loaded. No patch is installed, no vector is modified. When Config is started, ROM routines (stock or modded) are used again. Is it a problem? Jan
  22. If nothing else I am thinking about this (similar to this post, but with proceed line connected): * Arduino 6PIN FTDI USB TO TTL RS232RL 5V cable (e.g. ebay) - key parameters: FTDI chip, USB to TTL 5Volt variant, 6pins * SIO PLUG (https://lotharek.pl/productdetail.php?id=103) * 2x Shottky diode Connect TxD to "data in" (SIO PIN 3) via diode (for example 1N5817) this way: Connext RxD to "data out" (SIO PIN 5) Connect CTS to "command line" (SIO PIN 7) Connect RTS to "proceed line" (SIO PIN 9) via diode (same way as TxD was connected to data in) Connect GND to "ground" (SIO PIN 4) DO NOT CONNECT 5V to the SIO port !!! (http://mixinc.net/atari/pinouts/sio.htm) Jan
  23. I am glad you are interested into FujiNet and FujiNet-PC 🙂 FujiNet is about new hardware and new software/firmware for this hardware. FujiNet-PC is work in progress port of the software part to Linux, Mac (and TODO Win) and it communicates with Atari via SIO2PC/USB cable. The "ready to go cable" topic is quite new and I don't think you will get now the simple answer about SIO2PC/USB cable or adapter that will work. Some research is still needed. I am waiting for answer from Lotharek's shop about their SIO2PC. It might be similar with SIO2PC by Atarimax. There is always DIY option... On Fujinet-PC most of the emulated peripherals (disk, printer, modem) will work with regular SIO2PC/USB cable - it works in similar way as APE, AspeQt, RespeQt, atariserver, ... The difference is with network device/s and it's handler (N:). To get it working the PROCEED signal is required. I believe @phigan can help you with RPi as he already succeeded Jan
  24. To test it, attached are versions with high speed SIO autorun-cloader.atr included and without it autorun-cloader-nohs.atr. Put it on your TNFS server or SD card and insert image into disk slot 1 and boot. I think for the version with HSIO included it would be nice to detect if the SIO is already patched, and then skip bundled routines if patched SIO is detected. How to easily detect patched SIO, check the content on $E459, other location(s)? Source code: https://github.com/a8jan/fujinet-config-loader Jan
  • Create New...