twh/f2 Posted April 3, 2021 Share Posted April 3, 2021 (edited) Hi everyone, hope this is the right way to report or discuss a Fujinet bug. (At least I suppose it's a bug or some kind of incompatibility). To reproduce: A lot of XEX games in the Fandal archive (e.g. Galaxian) perform a warm start (e47e) in order to start a game. Many programs actually do this to initialize the computer. Typically it was called by tape games which displayed custom loading screens. So have a look at my set of Galaxian. 1) # Galaxian Fandal Orig -> Performs a reboot right after game was loaded 2) # Galaxian Fandal Fixed -> works (fixed) 3) # Galaxian Homesoft -> works For many years I used Rasters SDrive with Fandals games archive. I never experienced any issues with these games. Fandal said he has 400+ XEX games that are probably incompatible to the Fujinet XEX bootloader. Any opinions on this? grüße, \thomas Galaxian Fandal: http://a8.fandal.cz/detail.php?files_id=1942 Galaxian Homesoft: http://www.mushca.com/f/atari/index.php?dl=041|GALAXIAN #6 - Galaxian Fandal Fixed.xex #6 - Galaxian Fandal Orig.xex #6 - Galaxian Homesoft.xex Edited April 3, 2021 by twh/f2 Quote Link to comment Share on other sites More sharing options...
xxl Posted April 3, 2021 Share Posted April 3, 2021 44 minutes ago, twh/f2 said: Any opinions on this? actually, I am an opponent of this, but if you absolutely want it to work, just add in the loader: lda #$00 sta $0244 Quote Link to comment Share on other sites More sharing options...
twh/f2 Posted August 20, 2021 Author Share Posted August 20, 2021 Hi in direction of @mozzwald @tschak909 could you please comment this issue? Should I create a bug or do you believe it works as designed? Fandals Collection is pretty popular and I believe many Atarians will use these binaries, that are effectivly incompatible with Fujinet at this stage. Therefore I would be really interested to see a little pro/con discussion here. grüße \thomas Quote Link to comment Share on other sites More sharing options...
mozzwald Posted August 20, 2021 Share Posted August 20, 2021 3 hours ago, twh/f2 said: could you please comment this issue? I don't know enough about this to give a useful comment. I did try booting the Galaxian Original XEX you post and it just boot loops. This is FujiNet debug output from when it loops: Spoiler 07:39:24.184 > CF: 31 52 91 01 16 07:39:24.184 > disk sio_process() 07:39:24.184 > ACK! 07:39:24.184 > XEX READ (401) 07:39:24.184 > requesting 253 bytes from XEX 07:39:24.189 > received 253 bytes 07:39:24.189 > ->SIO write 256 bytes 07:39:24.189 > COMPLETE! 07:39:24.335 > 07:39:24.335 > CF: 31 52 92 01 17 07:39:24.335 > disk sio_process() 07:39:24.335 > ACK! 07:39:24.335 > XEX READ (402) 07:39:24.335 > requesting 253 bytes from XEX 07:39:24.336 > received 111 bytes 07:39:24.336 > ->SIO write 256 bytes 07:39:24.338 > COMPLETE! 07:39:25.936 > 07:39:25.936 > CF: 31 53 00 00 84 07:39:25.936 > disk sio_process() 07:39:25.936 > ACK! 07:39:25.936 > disk STATUS 07:39:25.936 > response: 0x00, 0xff, 0xe0 07:39:25.938 > ->SIO write 4 bytes 07:39:25.938 > COMPLETE! 07:39:25.950 > 07:39:25.950 > CF: 31 52 01 00 84 07:39:25.950 > disk sio_process() 07:39:25.950 > ACK! 07:39:25.950 > XEX READ (1) 07:39:25.950 > copying 128 bytes from bootloader 07:39:25.951 > setting PicoBoot double density flag 07:39:25.953 > ->SIO write 128 bytes 07:39:25.953 > COMPLETE! note the last READ before reset is requesting 253 bytes but only receives 111 bytes from the file Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted August 20, 2021 Share Posted August 20, 2021 (edited) Maybe the information in this thread maybe of use as the XEX loader was tweaked there Edited August 20, 2021 by Wrathchild Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 20, 2021 Share Posted August 20, 2021 For those who want to see what's going on at the firmware side, here is the XEX loader: https://github.com/FujiNetWIFI/fujinet-platformio/blob/master/lib/sio/diskTypeXex.cpp We are basically using Hias's picoboot. Maybe there's something more we need to do ? -Thom Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted August 21, 2021 Share Posted August 21, 2021 (edited) Had a look into this last night and I think may benefit from a tweaked picoboot which sets the BOOT? register to 1. There's 6 bytes spare in the 3 sectors so I'll download sources and try building that. Edit, done, can someone try the attached? picoboot.bin Edited August 21, 2021 by Wrathchild Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 21, 2021 Share Posted August 21, 2021 Just tested. didn't seem to work. (kept resetting) -Thom Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted August 21, 2021 Share Posted August 21, 2021 oh well, thanks for trying, worth a go Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted August 22, 2021 Share Posted August 22, 2021 Took a dive into the diffs between the binaries in post #1. The ONLY different between Fandal's fixed and original versions are that the INI entry point is $5500 rather than $5580 respectively. The code at $5580 is a simple snippet to set the DOSINI $5500 and is setting BOOT? to 1 as per the fix, hence that not being enough. So the warmstart call is supposed to transfer the code to $5500 as per what the fixed version jumps immediately to. 5580: A9 01 LDA #$01 5582: 85 09 STA $09 5584: A9 00 LDA #$00 5586: 85 0C STA DOSINI 5588: A9 55 LDA #$55 558A: 85 0D STA DOSINI+1 558C: A9 00 LDA #$00 558E: 85 08 STA WARMST 5590: 4C 74 E4 JMP WARMSV In Altirra's XEX boot the OS is doing this, and so the program runs: C4EE: A5 08 LDA WARMST C4F0: F0 09 BEQ $C4FB C4F2: A5 09 LDA $09 C4F4: 29 01 AND #$01 C4F6: F0 30 BEQ $C528 C4F8: 6C 0C 00 JMP (DOSINI) The WARMST setting to zero seems to have no effect here as the OS is is setting it to $FF shortly after the WARMSV call and hence the BEQ at $C4F0 in the above snippet doesn't take place. E474: 4C 90 C2 WARMSV JMP $C290 C290: 78 SEI C291: AD 44 02 LDA COLDST C294: 30 32 BMI $C2C8 C296: AD 13 D0 LDA TRIG3 C299: CD FA 03 CMP GINTLK C29C: D0 2A BNE $C2C8 C29E: 6A ROR C29F: 90 05 BCC $C2A6 C2A6: A9 FF LDA #$FF C2A8: D0 21 BNE $C2CB C2CB: 85 08 STA WARMST So I made an ATR in Altirra as a blank DOS.2.0/2.5 disk and copied the original version to this. Saved it and then hex edited it along with the picoboot.bin to overwrite the bootloader. This simulates what what the FujiNet xex loader is doing. When running this in Altirra it is seen that at $C291 the value of COLDST is $FF and so the boot sequence takes a different path, resulting in the boot taking place again. So to counter that, as per @xxl's suggesting, if COLDST is set to 1 (zero seems to be OK too as the check is if the high bit is set) then the game will load. Attached is the new version, so again if someone can be so kind as to test it out. picoboot.bin 1 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 22, 2021 Share Posted August 22, 2021 same thing from me again, recycled reboot. can someone else test to verify? You just need to copy picoboot.bin to your data directory and use the upload device filesystem task in vs.code. -Thom 1 Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted August 22, 2021 Share Posted August 22, 2021 How do these ATRs fair? The 'OK' is with the one from post #10 and the 'REBOOT' contains the original. TEST - REBOOT.ATR TEST - OK.ATR Quote Link to comment Share on other sites More sharing options...
twh/f2 Posted August 23, 2021 Author Share Posted August 23, 2021 But I'm uncertain if I really can follow the your discussion. ? Anyway at this point; thank you for your time - its awesome to see people in action with such skills. I would love to beta test / help out here too. Am I right that I would have to build / flash the fujinet firmware in order to test the "picoboot.bin" adjustements? grüße \thomas Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted August 23, 2021 Share Posted August 23, 2021 For the test ATRs it would just be a case of mounting and running those as in theory running the original XEX version with either the current or post #10 picoboot.bin files deployed to the FujiNet should exhibit the same behaviour. For getting picoboot.bin to your FujiNet I'll leave that for others to describe as I don't have the h/w. I thought it may be a case of having that file at a specific place on an SD card but seems more involved. Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted August 30, 2021 Share Posted August 30, 2021 Still curious if anyone has booted those ATRs via fujinet yet as only 1 download each? One should continuously reboot and the other launch Galaxian. If that is the case then the post #10 replacement binary should make the original file/xex version work correctly. 1 Quote Link to comment Share on other sites More sharing options...
twh/f2 Posted September 1, 2021 Author Share Posted September 1, 2021 On 8/30/2021 at 9:48 PM, Wrathchild said: Still curious if anyone has booted those ATRs via fujinet yet as only 1 download each? One should continuously reboot and the other launch Galaxian. If that is the case then the post #10 replacement binary should make the original file/xex version work correctly. I really would like to test. But please . can somebody give me instructions how I could repalce the fujinet bootloader? Quote Link to comment Share on other sites More sharing options...
mozzwald Posted September 1, 2021 Share Posted September 1, 2021 On 8/30/2021 at 2:48 PM, Wrathchild said: Still curious if anyone has booted those ATRs via fujinet yet as only 1 download each? I can try it and report back. 1 hour ago, twh/f2 said: I really would like to test. But please . can somebody give me instructions how I could repalce the fujinet bootloader You could test by attempting to boot the two ATR files posted above and report what happens with each. This does not require changing the FujiNet XEX bootloader at all. 1 Quote Link to comment Share on other sites More sharing options...
mozzwald Posted September 9, 2021 Share Posted September 9, 2021 On 8/30/2021 at 2:48 PM, Wrathchild said: Still curious if anyone has booted those ATRs via fujinet yet as only 1 download each? One should continuously reboot and the other launch Galaxian. I (finally) tried them tonight and both boot loop Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted September 9, 2021 Share Posted September 9, 2021 (edited) Great, in a way , as if under emulation or on your h/w via other devices (mounted via sio2xx device or on a multi-cart) these images behave differently then that would pinpoint an error in how Fujinet is handling ATR loading. Edited September 9, 2021 by Wrathchild Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.