[hatari-devel] Re: Some findings from "SYNC - The LoSTE screens" develop

Nicolas, #2 below is the answer to the question about RESET and the floppy problem ("Possible 1.7 regression") ;) Glad you found it! I was wondering how come a problematic image suddenly started working just as I was about to release the demo - now I know :)

Also, with regards to #3, I think Hatari does the same as STeem and assumes a specific location for a 60/50 switch as causing +2 lines, for both ST and STE. See this post for more information on why those two are very different: http://www.atari-forum.com/viewtopic.php?f=16&t=24855&start=337

/Troed

On Sun, Sep 8, 2013 at 10:55 AM, Troed Sångberg <troed@xxxxxxxxxxx> wrote:

Hi all,

I spent the summer creating SYNC's first demo screen in 22 years :P During that time I found a few quirks in Hatari that I've documented. Sorry in advance for not having code or screenshots for everything, just take the comments as FYI in those cases.

(However, which shows as credits in the screen, I'm amazed as to how well Hatari emulates the real thing. Great work, everyone involved in the development!)

1) See attached PNG.. When I created the release video of the screen I had to run Hatari in ST mode. The syncscroller is of the latest-and-greatest kind with 12 different line lengths and runs different combinations for STE, ST wakestate 1/3 and wakestate 2/4. In STE mode, some of the line lengths show colors from the palette where border color should be shown instead. This might also be related to Hatari not emulating "blanking" behaviour on 54, 56 and 80 byte lines.

2) On Hatari and real ST hardware, our use of the RESET instruction when exiting the menu (launching the screens) caused no issues.. On STE hardware the video memory address was changed. (I don't see this is something that should be changed in the emulation, but it took me a while to figure that one out so this is just documentation for the future. Solved by not using RESET .. )

3) When opening the lower border Hatari in some cases (when the timing was slightly off, I think) displayed what looked to be a 16 pixels/one word wider & earlier first border line - which of course then threw the rest of the lines off. I couldn't see a reason for this in video.c - and it happened both in ST and STE mode (but not on real hardware of course). I should be able to provoke that to happen again from my final codebase if no immediate "aha!" stands out.

4) Hatari does not emulate opening the right border with a resolution switch. This is 2-cycle dependent and is used by the demo (and Paolo's wakestate-display program I believe) to figure out which wakestate the hardware is in. This is not important, just as with the old wakestate detection (used for +2 and 0-byte switches discovered in 2006) demo makers just need to keep track of their default values being emulator suitable :P You'll see my screen doing 11 VBLs of resolution switching right border tries at one position, then 11 new ones 2 cycles earlier if the first didn't work. If you want to emulate this, I recommend discussing it with me and Paolo in the current atari-forum thread ;)

5) Hatari defaults to "wakestate 2/4" when it comes to +2 and 0-byte lines. The wakestate 1/3 versions of +2 are not emulated correctly (2 cycle difference). I had to take care to make sure that my hardware detection code defaulted correctly for Hatari.

6) FYI, The development version of Hatari emulates the STE version of the 0-byte line, the released v1.7.0 doesn't (Nicolas knows this since we discussed this during the summer - thanks for the quick implementation).

I think that was it, I hope it's of any use. I appreciate all the work that has gone into this emulator immensely - most development was done inside of it on my Macbook Pro (except the upwards of a thousand (!) power cycles of my STF that I had to do to create the syncscroll tables ... ). I'm quite sure this screen never would've seen daylight if it wasn't for Hatari.

regards,
Troed of SYNC