Second Life demo (Lamers) on Atari800Mac 5.0.1

[Marius]

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

[TGB1718]

Don't have a MAC, but it works fine under Windows/Altirra set as PAL, 130XE, 1088K RAM

So the XEX looks ok

[Mclaneinc]

File is fine, obviously the emulator isn't as up to date as others, works on Altirra fine..

[flashjazzcat]

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.

[+skr]

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.

[flashjazzcat]

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.

[Marius]

On real a8 this is the moment where the screen expands. It seems that it is this feature that is not supported by Atari800mac.

 

[Mclaneinc]

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

[+skr]

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.

[ivop]

Just tested on atari800 4.2.0, Linux 64-bit, and it crashes at the same spot.

 

[Mclaneinc]

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

[+skr]

All I can see is, that is caught in that loop, where it never reaches the condition to jump at the BNEs:

[phaeron]

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.

[frogstar_robot]

Atari++ 1.81 crashes as well.

[ajcek]

demo source code is here: https://github.com/ajcekg/LMS_SLS

[Rybags]

There'd be a fair bit of cycle-exact stuff going on there which would be a decent acid test for any emulator.

[dmsc]

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

[phaeron]

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.

 

[Marius]

Wow people! This is amazing analysis. Is there any chance someone can fix the emulator? So interesting this!

[+skr]

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.