Marius Posted January 3, 2020 Share Posted January 3, 2020 Hi All, Yesterday I saw the fabulous demo on my real atari 8bit computer. Today I tried it on the Atari800Mac emulator (version 5.0.1). Checked every setting twice: enough memory, Pal, no 'weird' patches... and the demo keeps crashing. I run it as XEX file (attached here). Anyone that can test it on their Mac and tell me whether it works there? Is there something wrong with my file? Thanks Marius LMS.XEX Quote Link to comment Share on other sites More sharing options...
TGB1718 Posted January 3, 2020 Share Posted January 3, 2020 Don't have a MAC, but it works fine under Windows/Altirra set as PAL, 130XE, 1088K RAM So the XEX looks ok Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted January 3, 2020 Share Posted January 3, 2020 File is fine, obviously the emulator isn't as up to date as others, works on Altirra fine.. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 3, 2020 Share Posted January 3, 2020 33 minutes ago, Marius said: Is there something wrong with my file? Tested in Atari800MacX (under Catalina, admittedly) and demo crashes on a green screen. Nothing wrong with your file, however: loads in eight seconds from SIDE2 using my loader. Quote Link to comment Share on other sites More sharing options...
+skr Posted January 3, 2020 Share Posted January 3, 2020 Same here, the screen is blue, logo on bottem right ,then the blue expands to the borders and it hangs, making a sound. Looks like it hangs, when the sound routine starts or so. Sadly I am not good in debugging, especially with Atari800MacX. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 3, 2020 Share Posted January 3, 2020 1 minute ago, skr said: Sadly I am not good in debugging, especially with Atari800MacX. I didn't know where to begin with the monitor, and then the emulator became unresponsive so I force quit it. Quote Link to comment Share on other sites More sharing options...
Marius Posted January 3, 2020 Author Share Posted January 3, 2020 On real a8 this is the moment where the screen expands. It seems that it is this feature that is not supported by Atari800mac. Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted January 3, 2020 Share Posted January 3, 2020 (edited) Is it still just Richard Bannister doing all the dev? He has / had his fingers in a lot of emulator pies iirc.. Edited January 3, 2020 by Mclaneinc Quote Link to comment Share on other sites More sharing options...
+skr Posted January 3, 2020 Share Posted January 3, 2020 1 hour ago, Marius said: On real a8 this is the moment where the screen expands. It seems that it is this feature that is not supported by Atari800mac. Actually, Mark Grebe created Atari800MacX based on atari800, which was just updated to v4.2.0. Mark published all sources on GitHub and I got them, but again, I am lacking some skills with Xcode. Even being a MacUser, I was educated using MS VisualStudio and created some Windows-Apps, but never MacApps. I´m trying to understand all the code for some while now and slowly get better, but I don´t know how long I need, until I am really able to make real changes to the source and compile a new version. I am working on it, yes. But don´t expect results too early. Quote Link to comment Share on other sites More sharing options...
ivop Posted January 3, 2020 Share Posted January 3, 2020 Just tested on atari800 4.2.0, Linux 64-bit, and it crashes at the same spot. Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted January 3, 2020 Share Posted January 3, 2020 (edited) 1 hour ago, skr said: Actually, Mark Grebe created Atari800MacX based on atari800, which was just updated to v4.2.0. Mark published all sources on GitHub and I got them, but again, I am lacking some skills with Xcode. Even being a MacUser, I was educated using MS VisualStudio and created some Windows-Apps, but never MacApps. I´m trying to understand all the code for some while now and slowly get better, but I don´t know how long I need, until I am really able to make real changes to the source and compile a new version. I am working on it, yes. But don´t expect results too early. Yep sorry, I knew Richard Bannister had an Atari connection, twas Rainbow and he handled the Mac port of Handy, the lynx emu.. Edited January 3, 2020 by Mclaneinc Quote Link to comment Share on other sites More sharing options...
+skr Posted January 3, 2020 Share Posted January 3, 2020 All I can see is, that is caught in that loop, where it never reaches the condition to jump at the BNEs: lms.mov Quote Link to comment Share on other sites More sharing options...
phaeron Posted January 3, 2020 Share Posted January 3, 2020 There's something going on with DLI timing. At that point, the demo is running a DLI which hits a bunch of hardware registers but also decrements a counter to proceed. The demo has a bug with a dirty screen switch which is causing the DLIs to nest wildly; on Altirra it eventually makes it out but for some reason on Atari800 it never hits the X=$00 condition to proceed, and I can't see enough of history to figure out why. Forcing the counter at $1827 to $00 unblocks it, but only for a short time until it gets stuck again. 2 Quote Link to comment Share on other sites More sharing options...
frogstar_robot Posted January 3, 2020 Share Posted January 3, 2020 Atari++ 1.81 crashes as well. Quote Link to comment Share on other sites More sharing options...
ajcek Posted January 4, 2020 Share Posted January 4, 2020 demo source code is here: https://github.com/ajcekg/LMS_SLS 2 Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 5, 2020 Share Posted January 5, 2020 There'd be a fair bit of cycle-exact stuff going on there which would be a decent acid test for any emulator. 1 Quote Link to comment Share on other sites More sharing options...
dmsc Posted January 5, 2020 Share Posted January 5, 2020 (edited) Hi! Quote There's something going on with DLI timing. At that point, the demo is running a DLI which hits a bunch of hardware registers but also decrements a counter to proceed. The demo has a bug with a dirty screen switch which is causing the DLIs to nest wildly; on Altirra it eventually makes it out but for some reason on Atari800 it never hits the X=$00 condition to proceed, and I can't see enough of history to figure out why. Forcing the counter at $1827 to $00 unblocks it, but only for a short time until it gets stuck again. This is the Altirra trace after a breakpoint at $1826: (3341: 23, 3) A=62 X=62 Y=62 S=F3 P=35 ( I C) 1826: A2 1C LDX #$1C (3341: 23, 5) A=62 X=1C Y=62 S=F3 P=35 ( I C) 1828: D0 0A BNE $1834 (3341: 23, 10) A=62 X=1C Y=62 S=F3 P=35 ( I C) 1834: CE 27 18 L1834 DEC $1827 [$1827] (3341: 23, 16) A=62 X=1C Y=62 S=F3 P=35 ( I C) 1837: A5 1C LDA $1C [$1C] = $90 (3341: 23, 31) A=62 X=1C Y=62 S=F0 P=35 ( I C) 1790: 85 1C L1790 STA $1C [$1C] (3341: 23, 43) A=62 X=1C Y=62 S=F0 P=35 ( I C) 1792: 86 1D STX $1D [$1D] (3341: 23, 55) A=62 X=1C Y=62 S=F0 P=35 ( I C) 1794: 84 1E STY $1E [$1E] (3341: 23, 63) A=62 X=1C Y=62 S=F0 P=35 ( I C) 1796: A9 62 LDA #$62 (3341: 23, 67) A=62 X=1C Y=62 S=F0 P=35 ( I C) 1798: A2 62 LDX #$62 (3341: 23, 71) A=62 X=62 Y=62 S=F0 P=35 ( I C) 179A: A0 62 LDY #$62 (3341: 23, 75) A=62 X=62 Y=62 S=F0 P=35 ( I C) 179C: 8D 0A D4 STA WSYNC [$D40A] The DLI hits just after the DEC, allowing the next LDX to see the updated value. But in Atari800, the same trace is: (breakpoint at 1826) 23 7 A=62 X=62 Y=62 S=F5 P=--*--I-C PC=1826: A2 1C LDX #$1C 23 9 A=62 X=1C Y=62 S=F5 P=--*--I-C PC=1828: D0 0A BNE $1834 23 12 A=62 X=1C Y=62 S=F5 P=--*--I-C PC=1834: CE 27 18 DEC $1827 23 22 A=62 X=1C Y=62 S=F2 P=--*--I-C PC=1792: 86 1D STX $1D ;ABUFPT+1 23 30 A=62 X=1C Y=62 S=F2 P=--*--I-C PC=1794: 84 1E STY $1E ;ABUFPT+2 23 42 A=62 X=1C Y=62 S=F2 P=--*--I-C PC=1796: A9 62 LDA #$62 23 50 A=62 X=1C Y=62 S=F2 P=--*--I-C PC=1798: A2 62 LDX #$62 23 58 A=62 X=62 Y=62 S=F2 P=--*--I-C PC=179A: A0 62 LDY #$62 23 64 A=62 X=62 Y=62 S=F2 P=--*--I-C PC=179C: 8D 0A D4 STA $D40A ;WSYNC Here, the DLI hits just before the DEC, so the next LDX will see the same value, so the BNE will always be taken. After the DLI nesting ends, the value on $1827 will be $FF, so it never would test as zero. This is probably a bug in the Atari800 core, but I don't understand why, as cycle counting on display lines should be exact. It could be that the result depends on the exact cycle of the VBI or other side effect. Have Fun! Edited January 5, 2020 by dmsc 3 Quote Link to comment Share on other sites More sharing options...
phaeron Posted January 5, 2020 Share Posted January 5, 2020 Figured it out, it's a bug in Atari800 regarding the timing of NMIs concurrent with the end of a taken branch. Very nasty edge case. In fact, I had to fix a bug recently in Altirra with this case, in the other direction. Under normal circumstances, a DLI handler would try to begin executing at cycle 10, two cycles after the end of the LMS fetches, whenever the next instruction border occurs. However, if a taken branch is right before that, it delays interrupt acknowledgment and in this case it allows the DEC $1827 instruction that dmsc noted above to sneak in. This instruction is critical in this case because (1) the DLI routine is too long and keeps interrupting itself and (2) the DLI is also responsible for revectoring the NMI vector to the VBI handler based on this counter. With that instruction being skipped, the DLI code doesn't ever branch to the code to set up the VBI. The CPU does eventually run all of the decrements when the stack unwinds at the end of the frame when the DLIs stop, but all of the decrements run back-to-back without the checks in between, so the X=$00 condition is never seen by the branch. The situation is a bit sub-optimal since the interrupt handler prologue/epilogue is non-reentrant and is corrupting registers in the mainline loop, which just happens to work. There is plenty of CPU time in the WSYNCs, but not enough time after the last color change to cleanly exit the interrupt. Probably would be better just to merge all the DLIs together and run one loop, since the CPU isn't getting to run any other code anyway. This would also remove a lot of overhead when the nested DLIs are unwound -- but there's no telling what the rest of the code will do once the ~400 cycles that this takes up are freed. 6 1 Quote Link to comment Share on other sites More sharing options...
Marius Posted January 5, 2020 Author Share Posted January 5, 2020 Wow people! This is amazing analysis. Is there any chance someone can fix the emulator? So interesting this! 1 Quote Link to comment Share on other sites More sharing options...
+skr Posted January 5, 2020 Share Posted January 5, 2020 47 minutes ago, Marius said: Wow people! This is amazing analysis. Is there any chance someone can fix the emulator? So interesting this! As the project is on GitHub, I´ve written an Issue there, using phaeron´s description of the problem and linking to this thread. Let´s hope, some of the coders there is able to do something. 3 1 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.