apc

- 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

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

Good! I will add dependencies to the build instructions. Jan

OK. http://<your_pi_address>:8000 at the bottom of the page Jan

I worry, my skills is limited to do that

@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

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

@billkendrick IMHO your DLI routine takes too much time. Your DLI must be very fast to handle DL interrupt on every line. Jan

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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?

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

Working on N device protocols ...