horizontal scrolling on ST

[troed]

So, there's of course been an additional reason for my interest in this thread - the discussion about wakestates and cold/warming/warm modes etc. When the discussions started I was already writing on a 12 sync line lengths syncscroller for a screen that I've now just released (SYNC's first screen in 22 years .. ).

http://www.youtube.com/watch?v=jtvu3vtl-C4 (.ST image download link in description)

I had already studied the 2006 thread where the new line sizes were researched in detail - but it was really difficult to find stable sync line combinations when I only knew about wakeup 1 and wakeup 2. The additional wakestate knowledge was just what I needed - and the screen thus contains a 3+1 syncscroller with constant screen address (20 combinations, dual playfield-capable) that's been tested on STE, ST WS1/WS2/WS3/WS4 - cold and warm*.

Many thanks to everyone involved in this research, especially Paolo.

(I "only" have a single STF and STE to test with myself, and I'm slightly worried about the different clocks in older STFs and the top border timing I use. While top border stability due to jitter can be increased immensely by adding suitable EXG instructions - knowing about +2 lines - the screen does play a SID Sound Designer tune which doesn't make things easier ... )

/Troed of SYNC

*) Known issues - at some point I simply had to stop testing: Line combination 514 creates a banded bitmap on the following line in WS2 warm. Line combination 610 needs a 54 byte first line in STE, WS2 and WS4 - else I tried to avoid that since my first syncscroll line is also used for logo graphics (so for WS1/WS3 only 158, 160 and 204 are used).

[ljbk]

double click => double post

[ljbk]

@Troed

Nice !

You are now one of the few to have released a screen with a 1+3 lines hardscroll.
My first released one was the YM50Kx set of disks, in March 2005, but in fact there were only 8 different positions to allow a normal screen vertical scroll.

Regarding slower CPUs, you can estimate the CPU speed via timer tests assuming a fixed crystal for the MFP at 2.4576 MHz and so adapt the number of nops following in the timer handler. You can also reduce to the minimum the timer part: start at the end of the lower border part up to a bit before the top border spot.
This was how i did it in 1990 without STOP instructions. If you use STOPs it is even more secure since you can reduce very much the jitter.
I remember i was in shock back then in 1990 when i tried my first version of the big earth (Overscan demos / F1) on a friend STF with spanish TOS and the top border was not open: he had a slightly faster CPU ... But as i made that timer test, i managed to have this "auto-cleaning-sprite" screen running on both machines.
I am now also using this CPU estimation for replay accuracy in Hextracker.


Paulo.

[troed]

Nice !

Thanks - it was fun re-implementing everything from your information in the 2006 thread (and this thread for the wakestate-detection, the screen displays the wakestate in DL-notation in the FAQ part)

Regarding slower CPUs, you can estimate the CPU speed via timer tests assuming a fixed crystal for the MFP at 2.4576 MHz and so adapt the number of nops following in the timer handler. You can also reduce to the minimum the timer part: start at the end of the lower border part up to a bit before the top border spot.
This was how i did it in 1990 without STOP instructions. If you use STOPs it is even more secure since you can reduce very much the jitter.

The "SYNC way" since 1989 is to use two timers, Timer C and Timer A. I'm quite sure the STOP way is equally good, but I gambled that reusing our old border code would increase compatibility. We'll have to see if that was the right choice.

(VBL sets up both Timer C and Timer A, where Timer C triggers first and does STOP 2500 waiting for Timer A - that reduces the jitter. Both the top border and the bottom border then contains self-calibrating code, checking to see if they succeed and changes built-in delays if not. The bottom border is also synclocked)

I will probably take a break from power cycling Ataris for a short while - but I'm still intrigued by the wakestates. I would love to be able to find a way to detect cold/[warming]/warm - and write a better synccombo finder (I use a Java program on my Mac) using knowledge about Shifter words in->out instead of just bruteforcing. Also, when trying to find new syncline lengths (actually, variants of the 14-byte line that wouldn't mess up sync) I think I stumbled upon some of your 4-bit shifts which I want to look into more as well.

/Troed

[Steven Seagal]

@Troed,
Dude you've got some explaining to do, especially about this:

003 - 056:S0000 068:S0002 512:R0002 512:T1000
004 - 012:R0000 120:R0002 392:R0000 440:R0001 456:R0000 512:R0002 512:T22001
(in "emulator cycles")

Is this a new shifter trick? Can you really run so many cycles of "DE" in high res (392-120=272 cycles)?

In Steem I should do this to get correct display:

Shifter counter +54
Next scanline: black line

Right now I don't see the logic, but obviously it works.

[troed]

Dude you've got some explaining to do

, especially about this:

003 - 056:S0000 068:S0002 512:R0002 512:T1000
004 - 012:R0000 120:R0002 392:R0000 440:R0001 456:R0000 512:R0002 512:T22001
(in "emulator cycles")

Is this a new shifter trick? Can you really run so many cycles of "DE" in high res (392-120=272 cycles)?

In Steem I should do this to get correct display:

Shifter counter +54
Next scanline: black line

Right now I don't see the logic, but obviously it works.

Yeah the screen is well tested on target hardware, but it shouldn't contain any new tricks*. I'm not sure about next scanline being black - that's a "normal" 80-byte line (you see the left border having been opened before) - but the rest of it after the switch is blanked. What might seem confusing is that the switch for "stop middle" is different in 80 compared to 54 and 56. That's simply due to the fact that 80 existed in the original SYNC 1989 syncscroller** but the others didn't and were implemented later. I seldom rewrite code that works Code snippets below for comparison - the first instruction is at emulator cycle 500. Since we're only messing with a state machine the line isn't really in high res.

Code: Select all

* 54 byte line - stop middle

_s54			* 5 nop jsr	
	dcb.w 44,$4e71
	move.b d1,(a0)
	nop
	move.b d0,(a0)
	dcb.w 70,$4e71
	rts		* 4 nop rts

Code: Select all

* Rout for 80-byte scanline (left border + stop middle)

_s80			* 5 nop jsr	
	dcb.w 3,$4e71
	move.b d1,(a0)		* left
	nop
	move.b d0,(a0)
	dcb.w 25,$4e71
	move.b d1,(a0)		* interrupted line
	dcb.w 66,$4e71
	move.b d0,(a0)
	dcb.w 10,$4e71
	move.b d2,(a0)	* ULM
	nop
	nop
	move.b d0,(a0)
	rts		* 4 nop rts

/Troed

*) Well. At boot I separate wakestates by first doing a right border using a resolution switch, which is 2 cycle dependent, looking for either ws2 (default), if that doesn't work I try ws3/ws4 (-2) and if that also fails I conclude I'm in ws1 (-4). I think this is exactly the same as Paolo's wakestate-program posted before although I haven't verified. To then separate ws3 from ws4 I perform two 0-byte lines and see if video address middle byte has changed or not. I also do each step above 11 times in sequence since I had issues with stability. At least Hatari doesn't emulate the 204res switch at all (and since I'm on Mac I haven't tested Steem).

**) The SYNC syncscroll in SNYD2 (but written long before), one of the patched screens in this demo, was a 9 scanline one. The source contained an 80-byte line but it wasn't used - don't ask me why - and I have no idea how we could have code for an 80-byte line but not a 54 byte one I do know this was written very shortly after TCB's and theirs was many more lines, 15 IIRC, and only used right/left borders so the technique was very much in its infancy.

edit: And to add to historic knowledge, ours used _s158,_s160,_s184,_s186,_s204,_s230 (no _s80 even though the code existed) with the following insight: Conclusion of analysis => all lines not using s158 will be n bitplanes shifted/or all lines ending in s158 are ok.. And, looking at the source, all combos indeed end with s158. This was all Redheads stuff btw, and he went hunting for a 4-bit syncscroller shortly after. I do not know if it was fullscreen or not.

[Steven Seagal]

Hmm... 54+26=80, so yes it's a -106 effect (or -80 without the left border).
Since I made +54 instead of -106 there was a bad scanline, so no the next scanline doesn't need to be black.
False alert.
I was confused because the switch to R2 happens so soon, at 120 instead of 160-164. I think Hatari also tests at around 160.
Current version of Steem doesn't display the intro but next version should [I'll do this tomorrow!].
As for the demos they run in STE mode.

[Steven Seagal]

As promised, there's support for The LoSTE screens in latest Steem beta.
Works best with wake-up state 1 option (for the moment).

[troed]

As promised, there's support for The LoSTE screens in latest Steem beta.
Works best with wake-up state 1 option (for the moment).

Cool, thanks! Although I'm slightly confused whether Steem is (still?) STE only or if it's selectable. The screen will try writing to $ffff8901 to detect whether it runs on STE or ST (bus error). If the result is ST, and the screen detects WS1 or WS3 correctly (which can be seen as DL6 or DL5 respectively in the FAQ part) it will look superior to in Hatari currently - since only 158, 160 and 204 lines will be used on the first syncscroll line. If it detects STE it will skip wakestate probing completely since I've only seen one wakeup (which fits with Ijor's and Paolo's findings) and one combination will use a 54 byte first line.

Oh, come to think of it, it would be interesting to know what the DL-number for an STE is. When it comes to syncline combos the STE doesn't really behave like ST DL5/DL6. Imho.

/Troed

[Steven Seagal]

Cool, thanks! Although I'm slightly confused whether Steem is (still?) STE only or if it's selectable.

The STE/STF switch was the first big departure from original Steem, for the satisfaction of many.

The screen will try writing to $ffff8901 to detect whether it runs on STE or ST (bus error).

This test is handled. It's the same as ST-Connexion in 'Punish your Machine'.

If the result is ST, and the screen detects WS1 or WS3 correctly (which can be seen as DL6 or DL5 respectively in the FAQ part) it will look superior to in Hatari currently - since only 158, 160 and 204 lines will be used on the first syncscroll line. If it detects STE it will skip wakestate probing completely since I've only seen one wakeup (which fits with Ijor's and Paolo's findings) and one combination will use a 54 byte first line.

In Steem, wake-up states 1 and 2 cycle differences work only in STF mode too.

[troed]

The STE/STF switch was the first big departure from original Steem, for the satisfaction of many.

Right, sorry about that. Since I'm on Mac I simply didn't know.

In Steem, wake-up states 1 and 2 cycle differences work only in STF mode too.

I sent off a mail to the Hatari devel list with some quirks I've found with sync switched lines yesterday, and today I read through your wonderful notes in SSEShifter.cpp regarding LoSTE. I've realized that it would be of immense help for the emulator community if someone where to use Paolo's most excellent Excel sheet as a guide to make a modified Alien state machine description - and then implement that into code for use by emulator developers.

Examples, using your notes:

Code: Select all

Must be taken as +2:
Forest:
-28 - 012:R0000 160:R0002 172:R0000 376:S0002 384:S0002 444:R0000 456:R0000 512:T2005
-27 - 036:S0000 054:S0002 376:S0000 384:S0002 444:R0002 456:R0000 512:T2012

Mustn't be taken as +2:
loSTE screens:
004 - 040:S0000 052:S0002 512:R0002 
199 - 484:S0000 512:T0200
200 - 056:S0002 

What's 004? It looks like a line that ends with opening of a left border, which would mean it's one of my syncscroll lines. But a sync switch at cycle 40 and 52 is an STE 0-byte line - +2 can only ever happen when switching back at cycle 54 and 56 respectively in different wakestates so the emulator code should indeed never be able to trigger a +2 there. Now, thanks to the knowledge about how sensitive a +2 line is what the screen does it to check wakeupstate and then push the top border switch back (or switches rather, there are two) by 2 cycles so that it will never be possible for the top border line to be a +2 line. I also use the same trick for STE, it'll never switch _to_ 60Hz at cycle 36)

I realise from your description that I didn't put this into use with the bottom border, and apparently that works because I switch to 60Hz on the line before. I did see strangeness in Hatari when the bottom border timing was slightly off that can be explained by it thinking I had a +2 line there. So, this has me slightly worried. According to Paolo's XLS a switch to 60Hz at cycle 378 or after on the previous line, as long as it then switches back at exactly cycle 54/56 (wakestate dependent) should create a +2. However, I haven't seen it happening on real hardware so there might be something else at play here with my long lower border switch.

So, many of the triggers I see in emulator code for sync switches could really be simplified with a state machine implementation that would probably work a lot like the real thing. In the end I'm quite sure it would make for a lot simpler code, and if anyone's crazy enough to use these new techniques today (as I was, instead of just writing "new school" chunky2planar stuff ) they could do a lot more work inside the emulators as well.

It's only the "switch points" where the state machine can move between states that are of importance. What happens inbetween doesn't really matter - that's why our old 80 byte line works:

Code: Select all

/*  A shift mode switch to 2 before cycle 166 (end of HIRES line) causes 
    the line to stop there. 106 bytes are not fetched.
    Just Buggin: 152:R0002 172:R0000
    ST-CNX: 160:R0002 172:R0000
    loSTE screens: 120[!]:R0002  392:R0000 
*/

As long as res was 0 at cycle 58 it's free to change to 2 at any point in time before cycle 166 - and then back to 0 at any point in time afterwards. If it stays at 2 until after cycle 188 it will additionally cause blanking of the rest of the line. Cycle 166 is key here - as long as res is 2 at that exact point the line will stop. If it's set to 2 just two cycles later it's instead a normal line with a possibility to open the right border (as long as it's not switched back to 0 until cycle 380).

So, if the code had implemented a state machine our old 80 byte line wouldn't have tripped up Steem at all to start with. All those different positions would've just worked.

Ijor's old table based on Aliens article from 2006:

Code: Select all

IF Position ==  13   AND display_freq=60 THEN Activate signal H
IF Position ==  14   AND display_freq=50 THEN Activate signal H
IF Position ==  93   AND display_freq=60 THEN de-activate signal H
IF Position ==  94   AND display_freq=50 THEN de-activate signal H
IF Position ==   Y   AND display_freq=60 THEN Activate Hsync
IF Position == Y+1   AND display_freq=60 THEN de-activate Hsync, start new line
IF Position == Y+2   AND display_freq=50 THEN Activate Hsync
IF Position == Y+3   AND display_freq=50 THEN de-activate Hsync, start new line

That, updated, would become a state machine.

(I also recommend reading Ijor's further comments later in that thread: http://www.atari-forum.com/viewtopic.ph ... 0&start=83 )

Sorry, long post, I just found it interesting to read the comments you made while getting LoSTE to work.

/Troed

[Steven Seagal]

The STE/STF switch was the first big departure from original Steem, for the satisfaction of many.

Right, sorry about that. Since I'm on Mac I simply didn't know.

Of course you couldn't know.

I sent off a mail to the Hatari devel list with some quirks I've found with sync switched lines yesterday, and today I read through your wonderful notes in SSEShifter.cpp regarding LoSTE. I've realized that it would be of immense help for the emulator community if someone where to use Paolo's most excellent Excel sheet as a guide to make a modified Alien state machine description - and then implement that into code for use by emulator developers.

Examples, using your notes:

Code: Select all

Must be taken as +2:
Forest:
-28 - 012:R0000 160:R0002 172:R0000 376:S0002 384:S0002 444:R0000 456:R0000 512:T2005
-27 - 036:S0000 054:S0002 376:S0000 384:S0002 444:R0002 456:R0000 512:T2012

Mustn't be taken as +2:
loSTE screens:
004 - 040:S0000 052:S0002 512:R0002 
199 - 484:S0000 512:T0200
200 - 056:S0002 

What's 004? It looks like a line that ends with opening of a left border, which would mean it's one of my syncscroll lines. But a sync switch at cycle 40 and 52 is an STE 0-byte line - +2 can only ever happen when switching back at cycle 54 and 56 respectively in different wakestates so the emulator code should indeed never be able to trigger a +2 there. Now, thanks to the knowledge about how sensitive a +2 line is what the screen does it to check wakeupstate and then push the top border switch back (or switches rather, there are two) by 2 cycles so that it will never be possible for the top border line to be a +2 line. I also use the same trick for STE, it'll never switch _to_ 60Hz at cycle 36)

I realise from your description that I didn't put this into use with the bottom border, and apparently that works because I switch to 60Hz on the line before. I did see strangeness in Hatari when the bottom border timing was slightly off that can be explained by it thinking I had a +2 line there. So, this has me slightly worried. According to Paolo's XLS a switch to 60Hz at cycle 378 or after on the previous line, as long as it then switches back at exactly cycle 54/56 (wakestate dependent) should create a +2. However, I haven't seen it happening on real hardware so there might be something else at play here with my long lower border switch.

In fact I was confused a lot for the "line +2" test, and still am.
Here's what the first screen gives in Steem, STE mode:

Code: Select all

-30 - 424:S0000 512:S0002 512:T0100 512:#0160
-29 - 084:S0000 116:S0002
002 - 376:S0000 384:S0002 512:R0002 512:T0010 512:#0204
003 - 012:R0000 376:S0000 384:S0002 440:R0001 456:R0000 512:T2011 512:#0230
004 - 040:S0000 052:S0002 512:R0002 512:T1000 512:#0000
005 - 012:R0000 120:R0002 392:R0000 440:R0001 456:R0000 512:T2005 512:#0080
020 - 128:j0006
172 - 336:V000E 372:M0000
199 - 484:S0000 512:T0200 512:#0160
200 - 056:S0002

Normally line 200 should be +2 according to those values (056:S0002), but line 199 ends after 508 cycles, yet Steem sees the end at 512 due to its way of setting frame timings (internal issue). In consequence the switch to 50hz really happens at 52, not 56. At least that's what I think right now!

So, many of the triggers I see in emulator code for sync switches could really be simplified with a state machine implementation that would probably work a lot like the real thing. In the end I'm quite sure it would make for a lot simpler code, and if anyone's crazy enough to use these new techniques today (as I was, instead of just writing "new school" chunky2planar stuff ) they could do a lot more work inside the emulators as well.

It's only the "switch points" where the state machine can move between states that are of importance. What happens inbetween doesn't really matter - that's why our old 80 byte line works:

Code: Select all

/*  A shift mode switch to 2 before cycle 166 (end of HIRES line) causes 
    the line to stop there. 106 bytes are not fetched.
    Just Buggin: 152:R0002 172:R0000
    ST-CNX: 160:R0002 172:R0000
    loSTE screens: 120[!]:R0002  392:R0000 
*/

As long as res was 0 at cycle 58 it's free to change to 2 at any point in time before cycle 166 - and then back to 0 at any point in time afterwards. If it stays at 2 until after cycle 188 it will additionally cause blanking of the rest of the line. Cycle 166 is key here - as long as res is 2 at that exact point the line will stop. If it's set to 2 just two cycles later it's instead a normal line with a possibility to open the right border (as long as it's not switched back to 0 until cycle 380).

So, if the code had implemented a state machine our old 80 byte line wouldn't have tripped up Steem at all to start with. All those different positions would've just worked.

It was my fault really, I introduced a minimal value for R2 that was useless. What is really tested now is resolution at cycle 164 and if the switch happened after 56, not all positions in the comment are tested.

Ijor's old table based on Aliens article from 2006:

Code: Select all

IF Position ==  13   AND display_freq=60 THEN Activate signal H
IF Position ==  14   AND display_freq=50 THEN Activate signal H
IF Position ==  93   AND display_freq=60 THEN de-activate signal H
IF Position ==  94   AND display_freq=50 THEN de-activate signal H
IF Position ==   Y   AND display_freq=60 THEN Activate Hsync
IF Position == Y+1   AND display_freq=60 THEN de-activate Hsync, start new line
IF Position == Y+2   AND display_freq=50 THEN Activate Hsync
IF Position == Y+3   AND display_freq=50 THEN de-activate Hsync, start new line

That, updated, would become a state machine.

(I also recommend reading Ijor's further comments later in that thread: http://www.atari-forum.com/viewtopic.ph ... 0&start=83 )

Sorry, long post, I just found it interesting to read the comments you made while getting LoSTE to work.

/Troed

Those discussions are always interesting.
The problem with such an algorithm is that it must be run every 4 cycles, in emulation tests are event-driven.

[troed]

In fact I was confused a lot for the "line +2" test, and still am.
Here's what the first screen gives in Steem, STE mode:

Code: Select all

199 - 484:S0000 512:T0200 512:#0160
200 - 056:S0002

Normally line 200 should be +2 according to those values (056:S0002), but line 199 ends after 508 cycles, yet Steem sees the end at 512 due to its way of setting frame timings (internal issue). In consequence the switch to 50hz really happens at 52, not 56. At least that's what I think right now!

Well, the decision if a line is 508 or 512 cycles is taken at the beginning of the line so that can't happen with line #199. Also, while the following is true for STE mode the code path for STE and STF is the same for the bottom border so the concern is still valid, but, on an STE it's not the switch back to 50Hz that decides whether the line becomes +2 but when the switch _to_ 60Hz happens.

(And this is all Ijor/Paolo knowledge btw - I take no credit in being able to follow their reasoning, testing and documentation .. )

From the 2006 thread:

a) the + 2 bytes effect

On STF, the switch back to 50Hz (second move.b of the pair) has to be done at pixel -27 or -29 depending on the wake-up state: 11 nops or 9nop+1exg after pixel -71
On STE, for wake-up state 1 (it is not clear if there is a second one on STE), the switch to 60 Hz has to be done at pixel -47: 6 nops after pixel -71
=> So a combination 47/27 or 47/29 works on both !

... and translation between Paolo-timings and emulator (which are the same as mine) is easiest done via the Excel-sheet posted earlier

STF: The switch _back_ to 50Hz has to happen at cycle 54 or 56, depending on wakeup.
STE: The switch _to_ 60Hz has to happen at cycle 36.

For the top border I use wakeup and STE-detection to make sure the switches will never hit those cycles (aligning them on opposite 2-cycle boundaries), but I made no such effort for the bottom border since I never saw it fail on real hardware. However, for STE mode I'm quite sure there cannot be a +2 line since it's opened (and automatically verified within the border routine) on the previous line - nowhere near cycle 36.

Now, the interesting part I guess is on STF - whether a +2 line can be triggered when coming back from 60Hz that was initiated on the previous line. According to Paolo's Excel-sheet the answer is yes (cycle 378/380+), but it didn't show up in my testing.

/Troed

(Several hundred people have watched the LoSTE screens - but I'm curious as to how many have done it on real hardware .. hah )

[Steven Seagal]

Well, the decision if a line is 508 or 512 cycles is taken at the beginning of the line so that can't happen with line #199.

Yes it's not Steem being confused it's me. I should know that.

Also, while the following is true for STE mode the code path for STE and STF is the same for the bottom border so the concern is still valid, but, on an STE it's not the switch back to 50Hz that decides whether the line becomes +2 but when the switch _to_ 60Hz happens.

(And this is all Ijor/Paolo knowledge btw - I take no credit in being able to follow their reasoning, testing and documentation .. )

From the 2006 thread:

a) the + 2 bytes effect

On STF, the switch back to 50Hz (second move.b of the pair) has to be done at pixel -27 or -29 depending on the wake-up state: 11 nops or 9nop+1exg after pixel -71
On STE, for wake-up state 1 (it is not clear if there is a second one on STE), the switch to 60 Hz has to be done at pixel -47: 6 nops after pixel -71
=> So a combination 47/27 or 47/29 works on both !

... and translation between Paolo-timings and emulator (which are the same as mine) is easiest done via the Excel-sheet posted earlier

STF: The switch _back_ to 50Hz has to happen at cycle 54 or 56, depending on wakeup.
STE: The switch _to_ 60Hz has to happen at cycle 36.

This, on the other hand, would explain it. The switch to 50hz at cycle 56 in loSTE screens doesn't produce a line +2 on a STE because the switch to 60hz didn't happen at cycle 36!
You know I think I've read that thread sometime but I didn't draw all the conclusions. The test is different for STE & STF.

For the top border I use wakeup and STE-detection to make sure the switches will never hit those cycles (aligning them on opposite 2-cycle boundaries), but I made no such effort for the bottom border since I never saw it fail on real hardware. However, for STE mode I'm quite sure there cannot be a +2 line since it's opened (and automatically verified within the border routine) on the previous line - nowhere near cycle 36.

Now I understand, it makes sense. Before, I thought your program maybe didn't work on all STE.

Now, the interesting part I guess is on STF - whether a +2 line can be triggered when coming back from 60Hz that was initiated on the previous line. According to Paolo's Excel-sheet the answer is yes (cycle 378/380+), but it didn't show up in my testing.

/Troed

(Several hundred people have watched the LoSTE screens - but I'm curious as to how many have done it on real hardware .. hah )

There aren't so many cases of 'line +2'.
I only know:
Forest
Mindbomb/No s***
loSTE screens
and the "bee" programs discussed in this thread.

Look at Mindbomb:

Code: Select all

-30 - 420:S0000 512:T0100 512:#0160
-29 - 240:S0002 508:T0002 508:#0162

The 162 bytes line is necessary or the screen is broken.
Doesn't it vindicate Paolo?
By the way, this screen should be STF-only according to those rules.

[troed]

Look at Mindbomb:

Code: Select all

-30 - 420:S0000 512:T0100 512:#0160
-29 - 240:S0002 508:T0002 508:#0162

The 162 bytes line is necessary or the screen is broken.
Doesn't it vindicate Paolo?
By the way, this screen should be STF-only according to those rules.

How interesting! I just ran it in Hatari as well and sure - that screen does trigger a +2. From your info above it's when opening the top border.

(Both it and the Mindbomb main menu use "TCB style" sync scrollers only using left/right border removal I see. Tss tss. Our SNYD2 screen using six line lengths had been out for many months by this time - and it was written almost a year before Mindbomb).

Anyway I also see a possible STE detection when that screen starts, but I don't know what if anything it's used for. In any case that +2 is not of the same kind Paolo and Ijor researched here on the forum in 2006 - it's apparently connected to the scanline being a 508 cycle (60Hz) line. I'd say it's a pure artefact of an attempt to make a very stable top border removal (looooong switch).

Since there's a line in 60Hz that screen could possible "bend" on certain TV-sets, similar to (but likely not as severe as) the XXX International one.

While I haven't really thought about what the state machine looks like in 60Hz, I'm going to make a stab at guessing correctly right now That 162 byte line in 60Hz is similar to a 158 byte line in 50Hz. I.e, the line starts out as a 160 byte 60Hz line, but switches to 50Hz before the right border causing the state machine to fail to finish at the 60Hz position and instead finish at the 50Hz-position, which is 2 bytes later (a "long right"). Thus, a 162 byte line.

detect left+2 52<->376

So, the above --trace output from Hatari, while creating the desired effect, would then be in error.

/* 2007/12/29 [NP] Better support for starting line 2 bytes earlier (if the line starts in */
/* 60 Hz and goes back to 50 Hz later), when combined with top border */
/* removal (Mindbomb Demo - D.I. No poo).

[Hatari video.c]

And I would also write that as "ending 60Hz lines 2 bytes later"

(Of course, if my guess is correct. In any case that +2 byte line is not at all related to or created the same way as the wakeup-mode dependent 50Hz version)

/Troed

[npomarede]

And I would also write that as "ending 60Hz lines 2 bytes later"

(Of course, if my guess is correct. In any case that +2 byte line is not at all related to or created the same way as the wakeup-mode dependent 50Hz version)

/Troed

Hello
yes, it's possible some lines mixing long 60 Hz switches are not yet correctly identified as they should. In that case, the important part is that the line must be 162 bytes in the end, but as you said it could be because it's a right+2, not a left+2.
For another screen that stays too long in 60 Hz and that bends the video on TV, the TCB "nearly fullscreen" in SNY is another example ; if I recall correctly top border removal is a little messy and stays in 60 Hz for 2 whole HBL, which also affects the shifter's state machine (it's not correctly emulated in Hatari at the moment, the corresponding line's length is not correct, which results in the TCB logo not being centered as it should).

Nicolas

[troed]

yes, it's possible some lines mixing long 60 Hz switches are not yet correctly identified as they should. In that case, the important part is that the line must be 162 bytes in the end, but as you said it could be because it's a right+2, not a left+2.

It's almost only a matter of viewpoint really since in both 50Hz-162 and 60Hz-162 the start position is 60Hz-left and the end position is 50Hz-right - but since the cycle length of the line differs it's for me easiest to think of it as "left+2" in the 50Hz case and "right+2" in the 60Hz.

For another screen that stays too long in 60 Hz and that bends the video on TV, the TCB "nearly fullscreen" in SNY is another example ; if I recall correctly top border removal is a little messy and stays in 60 Hz for 2 whole HBL, which also affects the shifter's state machine (it's not correctly emulated in Hatari at the moment, the corresponding line's length is not correct, which results in the TCB logo not being centered as it should).

I'm now reaching back 24 full years into the distant past but I think that's probably wakemode dependent. I'm saying that because I'm under the belief that I reacted already then to the TCB screen sometimes having a centered logo, sometimes not. Of course, then there's was no explanation known.

(Which makes me wonder which line length they managed to trigger since I remember the offset to be somewhat substantial)

[troed]

I'm now reaching back 24 full years into the distant past but I think that's probably wakemode dependent. I'm saying that because I'm under the belief that I reacted already then to the TCB screen sometimes having a centered logo, sometimes not. Of course, then there's was no explanation known.

(Which makes me wonder which line length they managed to trigger since I remember the offset to be somewhat substantial)

Fear my memory.

WS3: Logo offset to the left.
WS2: Logo centered.

Visual inspection:

Line #1: Regular PAL 160
Line #2: NTSC 160 in WS2, PAL(? NTSC) 184 in WS3

(So I'm slightly confused - but it really looks like an opened left border on line #2 in WS3. I almost posted this claiming it was PAL 158 but .. )

A quick'n'dirty test with measurement tape supports a 48 pixel offset.

edit: If TCB knew about this being different between boots or at least between different STs, it's even possible they elected to purposely run the second line in NTSC since a 186 byte line would've created bitplane shifts and the necessity to handle that in code. Now I guess I need to go and disassemble the screen, again*, to find out.

edit2: Alright, so, looking at the code nothing really stands out**. The top border is opened with a single 60/50 switch with a 16 nop gap - followed by synclock and then they wait until it's time for the left border (so no try to open right border on first line) and do 228 fullscreen scanlines. 13 nops between right border and stabilizer, 13 nops between stabilizer and left border (so I assume it's done at cycle 4) - and the left border is a short no-gap switch.

Let's pretend they messed up and waited one nop too little after the first regular top border line. The left border would now happen at cycle 0, switch back at cycle 8 which would fail in WS2 but work in WS1/WS3/WS4. It would also cause the right border to become a short right (-2) - so - this seems almost consistent with what I see. What I don't have an explanation for is how the failed left border (switching back too soon) can create an NTSC 160 but there's visibly four pixels to the left of the line above (and four less on the right) - and that line being 508 cycles is what would then explain how come all the other lines are correct afterwards. And, equally strange, even the 184 byte line in WS1/3/4 needs to be 508 cycles then since the right border opens correctly on all other lines.

There must be something I'm missing, still [edit3: found it. wow]. Code below ..

/Troed

*) I did that already a year or so back when I investigated who was first with stabilized fullscreen lines and saw that the TCB screen had the exact same switches as Level 16. I'm positive that's where they got it from, and that the reason the SNYD screen isn't a fullscreen was to not steal Level 16's thunder in the Union Demo.

**)

Code: Select all

top border
$00ddd0 : 4238 820a                            clr.b     $ffff820a.w
$00ddd4 : 7003                                 moveq     #3,d0
$00ddd6 : 4e71                                 nop       
$00ddd8 : 51c8 fffc                            dbra      d0,$ddd6
$00dddc : 31fc 0002 820a                       move.w    #2,$ffff820a.w

synclock etc
$00dde2 : 31fc 0000 8240                       move.w    #0,$ffff8240.w
$00dde8 : 1010                                 move.b    (a0),d0
$00ddea : 67fc                                 beq.s     $dde8
$00ddec : 9440                                 sub.w     d0,d2
$00ddee : e569                                 lsl.w     d2,d1
$00ddf0 : 4df8 8800                            lea       $ffff8800.w,a6
$00ddf4 : 4e71                                 nop       
$00ddf6 : 4e71                                 nop       
$00ddf8 : 4e71                                 nop       
$00ddfa : 4e71                                 nop       
$00ddfc : 4e71                                 nop       
$00ddfe : 4e71                                 nop       
$00de00 : 4e71                                 nop       
$00de02 : 4e71                                 nop       
$00de04 : 4e71                                 nop       
$00de06 : 4e71                                 nop       
$00de08 : 4e71                                 nop       
$00de0a : 4e71                                 nop       
$00de0c : 4e71                                 nop       
$00de0e : 4e71                                 nop       
$00de10 : 4e71                                 nop       
$00de12 : 4e71                                 nop       
$00de14 : 4e71                                 nop       
$00de16 : 4e71                                 nop       
$00de18 : 4e71                                 nop       
$00de1a : 4e71                                 nop       
$00de1c : 4e71                                 nop       
$00de1e : 4e71                                 nop       
$00de20 : 4e71                                 nop       
$00de22 : 4e71                                 nop       
$00de24 : 4e71                                 nop       
$00de26 : 4e71                                 nop       
$00de28 : 4e71                                 nop       
$00de2a : 700e                                 moveq     #$e,d0
$00de2c : 4e71                                 nop       
$00de2e : 51c8 fffc                            dbra      d0,$de2c
$00de32 : 41f9 00ff 820a                       lea       $ff820a,a0
$00de38 : 303c 00e3                            move.w    #$e3,d0

fullscreen lines loop begins here
$00de3c : 4e71                                 nop       
$00de3e : 1283                                 move.b    d3,(a1)
$00de40 : 1284                                 move.b    d4,(a1)
$00de42 : 720c                                 moveq     #$c,d1
$00de44 : 4e71                                 nop       
$00de46 : 51c9 fffc                            dbra      d1,$de44
$00de4a : 4e71                                 nop       
$00de4c : 4bfa 044e                            lea       $e29c(pc),a5
$00de50 : 7a00                                 moveq     #0,d5
$00de52 : 1a1c                                 move.b    (a4)+,d5
$00de54 : e74d                                 lsl.w     #3,d5
$00de56 : 2c35 5000                            move.l    (a5,d5.w),d6
$00de5a : 3a35 5004                            move.w    4(a5,d5.w),d5
$00de5e : 4bf8 8800                            lea       $ffff8800.w,a5
$00de62 : 0dcd 0000                            movep.l   d6,0(a5)
$00de66 : 0b8d 0000                            movep.w   d5,0(a5)
$00de6a : 4e71                                 nop       
$00de6c : 4e71                                 nop       
$00de6e : 4e71                                 nop       
$00de70 : 1084                                 move.b    d4,(a0)
$00de72 : 1083                                 move.b    d3,(a0)
$00de74 : 4e71                                 nop       
$00de76 : 4e71                                 nop       
$00de78 : 4e71                                 nop       
$00de7a : 4e71                                 nop       
$00de7c : 4e71                                 nop       
$00de7e : 4e71                                 nop       
$00de80 : 4e71                                 nop       
$00de82 : 4e71                                 nop       
$00de84 : 4e71                                 nop       
$00de86 : 4e71                                 nop       
$00de88 : 4e71                                 nop       
$00de8a : 4e71                                 nop       
$00de8c : 4e71                                 nop       
$00de8e : 1283                                 move.b    d3,(a1)
$00de90 : 4e71                                 nop       
$00de92 : 1284                                 move.b    d4,(a1)
$00de94 : 4e71                                 nop       
$00de96 : 4e71                                 nop       
$00de98 : 4e71                                 nop       
$00de9a : 4e71                                 nop       
$00de9c : 4e71                                 nop       
$00de9e : 4e71                                 nop       
$00dea0 : 4e71                                 nop       
$00dea2 : 4e71                                 nop       
$00dea4 : 4e71                                 nop       
$00dea6 : 51c8 ff94                            dbra      d0,$de3c

[npomarede]

Line #1: Regular PAL 160
Line #2: NTSC 160 in WS2, PAL(?) 184 in WS3

(So I'm slightly confused - but it really looks like an opened left border on line #2 in WS3. I almost posted this claiming it was PAL 158 but .. )

A quick'n'dirty test with measurement tape supports a 48 pixel offset.

edit: If TCB knew about this being different between boots or at least between different STs, it's even possible they elected to purposely run the second line in NTSC since a 186 byte line would've created bitplane shifts and the necessity to handle that in code. Now I guess I need to go and disassemble the screen, again*, to find out.

/Troed

*) I did that already a year or so back when I investigated who was first with stabilized fullscreen lines and saw that the TCB screen had the exact same switches as Level 16. I'm positive that's where they got it from, and that the reason the SNYD screen isn't a fullscreen was to not steal Level 16's thunder in the Union Demo.

I saw the same thing when trying to debug this one some times ago. Hatari will trigger a left/right border removal, but the line requires to be a 60 Hz 160 bytes line for the logo to be centered. In Hatari, the wakeup state is fixed for now, so you always get the same result, but I never paid attention if the logo was always centered or not on my STF.

Here're the switches they use :

sync=0x00 video_cyc_w=17352 line_cyc_w=456 @ nHBL=33/video_hbl_w=33 pc=dde2 instr_cyc=16
shifter=0x02 video_cyc_w=17916 line_cyc_w=0 @ nHBL=34/video_hbl_w=35 pc=de40 instr_cyc=8
shifter=0x00 video_cyc_w=17924 line_cyc_w=8 @ nHBL=35/video_hbl_w=35 pc=de42 instr_cyc=8
detect remove left 0<->372
sync=0x00 video_cyc_w=18288 line_cyc_w=372 @ nHBL=35/video_hbl_w=35 pc=de72 instr_cyc=8
sync=0x02 video_cyc_w=18296 line_cyc_w=380 @ nHBL=35/video_hbl_w=35 pc=de74 instr_cyc=8
detect right-2 0<->372

shifter=0x02 video_cyc_w=18940 line_cyc_w=4 @ nHBL=37/video_hbl_w=37 pc=de40 instr_cyc=8
shifter=0x00 video_cyc_w=18948 line_cyc_w=12 @ nHBL=37/video_hbl_w=37 pc=de42 instr_cyc=8
detect remove left 0<->376

We can see that the hi/lo switch on hbl 35 is made at cycle 0/8 while freq is already 60 Hz. Does this switch gives a different result if freq is 50 Hz or 60 Hz ?
If we want the logo to be centered, we must consider that hi/lo at 0/8 has no effect to remove left border, so the line will start in 60 Hz and the 60/50 at 372/380 will have no effect, because the line is already at 60 Hz (this is the result I often get on my STF).

But those timings are really like the ones when you want to remove left/right border (maybe there was also a hi/lo stabilizer on line 35, I didn't note it at the time I saved some traces) ; so did this screen worked just by luck with no plane being shifted but only the logo moved from 48 pixels depending on the WS ?
Maybe they found this combination to be good in the different WS but without having no real explanation ?

Nicolas

[troed]

(See my major edit after disassembling just now - sorry - didn't check to see if anyone had posted in between)

We can see that the hi/lo switch on hbl 35 is made at cycle 0/8 while freq is already 60 Hz. Does this switch gives a different result if freq is 50 Hz or 60 Hz ?

Well if that line is in 60Hz then it explains the 508 cycles I need for the math to add up - but I don't see why it's in 60Hz

edit: Oh, lol, now I do. Wow. That just cannot have been done on purpose.

If we want the logo to be centered, we must consider that hi/lo at 0/8 has no effect to remove left border, so the line will start in 60 Hz and the 60/50 at 372/380 will have no effect, because the line is already at 60 Hz (this is the result I often get on my STF).

hi/low at 0/8 will indeed fail in WS2 (only) according to Paolo's Excel-sheet.

Maybe they found this combination to be good in the different WS but without having no real explanation ?

Could be - since the logo is centered only in WS2 I'm almost assuming that's what their ST defaulted to - but I'm sure any WS2-liking machine gets into WS1 every so often as well.

[npomarede]

Well if that line is in 60Hz then it explains the 508 cycles I need for the math to add up - but I don't see why it's in 60Hz

edit: Oh, lol, now I do. Wow. That just cannot have been done on purpose.

My guess is that they really wanted to do a left/right removal just after removing top border, but this one looks just like a usual left/right removal done 4 cycles too soon.
It happens 4 cycles too soon because previous line is 60 Hz for too long and only has 508 cycles.
As you say, their ST probably was always in WS2, so I think they applied the usual solution in such case : adapt the gfx in memory to get the correct result on screen, even if you don't know why

[troed]

(Btw, all lurkers, the current discussion about TCB's SNYD-screen is likely extremely on-topic, I'll get back to that at the end of this post)

My guess is that they really wanted to do a left/right removal just after removing top border, but this one looks just like a usual left/right removal done 4 cycles too soon.
It happens 4 cycles too soon because previous line is 60 Hz for too long and only has 508 cycles.

Well, I agree they wanted to do regular fullscreen lines and failed due to the quite critical typo in the top border switch - but - my visual inspection tells me the first line isn't in 60Hz (it's visibly four pixels to the right of the 60Hz line below) and also if it was 508 cycles it would have the effect of all the following lines being one nop too late, not too early. (That's what saves the alignment of the whole screen after the 508-cycle #2 line). I believe it's a combination of the typo _and_ being one nop too early after the sync lock.

So, I'm guessing that when starting out in 50Hz removing the top border, in that failed way, the state machine cannot (?) create a 60Hz first line. This would of course have to be verified but I cannot really explain why it's in 50Hz otherwise just by looking at the top border switch position.

Anyway, so about the fact that we're on topic: I believe this screen is the origin of the TCB sync scroller (which was one of at least two concurrent and independently invented*) - since it so very visibly by accident shows that by doing sync line combinations you can "move" the screen with stable bitmap appearance by 48 pixels. It also shows a line ending that's different from the regular 160, and even though TCB never used that in a syncscroller (not in Cuddly, not in SoWatt and not in Enchanted Lands) 158 and 184 were used by SYNC already in the spring of 1989.

/Troed

*) One other was by The Flying Egg/Omega - never released. I'm still hoping to be able to rescue code from Redhead's crashed hard drives before stating too certainly what SYNC did and when. Currently I have a lot of scroll texts written for the Synchron Mega Demo in march 1989 (never released then nor later) but not the most interesting screens themselves ...

[Steven Seagal]

Fear my memory.

WS3: Logo offset to the left.
WS2: Logo centered.

Visual inspection:

Line #1: Regular PAL 160
Line #2: NTSC 160 in WS2, PAL(? NTSC) 184 in WS3

(So I'm slightly confused - but it really looks like an opened left border on line #2 in WS3. I almost posted this claiming it was PAL 158 but .. )

A quick'n'dirty test with measurement tape supports a 48 pixel offset.

edit: If TCB knew about this being different between boots or at least between different STs, it's even possible they elected to purposely run the second line in NTSC since a 186 byte line would've created bitplane shifts and the necessity to handle that in code. Now I guess I need to go and disassemble the screen, again*, to find out.

edit2: Alright, so, looking at the code nothing really stands out**. The top border is opened with a single 60/50 switch with a 16 nop gap - followed by synclock and then they wait until it's time for the left border (so no try to open right border on first line) and do 228 fullscreen scanlines. 13 nops between right border and stabilizer, 13 nops between stabilizer and left border (so I assume it's done at cycle 4) - and the left border is a short no-gap switch.

Let's pretend they messed up and waited one nop too little after the first regular top border line. The left border would now happen at cycle 0, switch back at cycle 8 which would fail in WS2 but work in WS1/WS3/WS4. It would also cause the right border to become a short right (-2) - so - this seems almost consistent with what I see. What I don't have an explanation for is how the failed left border (switching back too soon) can create an NTSC 160 but there's visibly four pixels to the left of the line above (and four less on the right) - and that line being 508 cycles is what would then explain how come all the other lines are correct afterwards. And, equally strange, even the 184 byte line in WS1/3/4 needs to be 508 cycles then since the right border opens correctly on all other lines.

There must be something I'm missing, still [edit3: found it. wow]. Code below ..

/Troed

*) I did that already a year or so back when I investigated who was first with stabilized fullscreen lines and saw that the TCB screen had the exact same switches as Level 16. I'm positive that's where they got it from, and that the reason the SNYD screen isn't a fullscreen was to not steal Level 16's thunder in the Union Demo.

**)

Thx a lot dude!
I asked here before what the TCB screen was supposed to be but never got an answer.
Thanks to your precise findings, this behaviour according to wake-up state 1/2 will soon be emulated in Steem.

One difficulty in Steem is the confusion due to 508 cycles scanlines in a 50hz frame.
In Steem the timings of all HBLs are prepared for each frame using the "event" system.
In a 50hz frame, when there are 60hz (508 cycles) scanlines, Steem will be off by 4 cycles in its reckoning of the start of the HBL (linecycle 0).
Because scanlines -29 and -30 are 60hz in "TCB", Steem got the wrong cycles: R2 at 4 instead of 0 on line -28.
It's hard to fix without messing other timings (like CPU, MFP...) but I finally found a simple way.

Code: Select all

fix: Steem cycle confusion with 508 cycles lines

TCB before fix, ignore WU

-30 - 376:S0000 460:S0000 512:T0100 512:#0160
-28 - 004:R0002 012:R0000 376:S0000 384:S0002 444:R0002 456:R0000 508:T2009 508:#0184
-27 - 004:R0002 012:R0000 376:S0000 384:S0002 444:R0002 456:R0000 512:T2011 512:#0230

TCB after fix, WU1

-30 - 368:S0000 452:S0000 512:T0100 512:#0160
-28 - 000:R0002 008:R0000 372:S0000 380:S0002 440:R0002 452:R0000 508:T2009 508:#0184
-27 - 004:R0002 012:R0000 376:S0000 384:S0002 444:R0002 456:R0000 512:T2011 512:#0230

TCB after fix, WU2 (CPU timing)

-30 - 372:S0000 458:S0000 512:T0100 512:#0160
-28 - 000:R0002 008:R0000 372:S0000 380:S0002 440:R0002 452:R0000 508:T2000 508:#0160
-27 - 004:R0002 012:R0000 376:S0000 384:S0002 444:R0002 456:R0000 512:T2011 512:#0230

TCB after fix, WU2 (when registers are hit)

-30 - 370:S0000 454:S0000 512:T0100 512:#0160
-28 - 002:R0002 010:R0000 374:S0000 382:S0002 442:R0002 454:R0000 508:T2000 508:#0160
-27 - 006:R0002 014:R0000 378:S0000 386:S0002 446:R0002 458:R0000 512:T2011 512:#0230

[troed]

Thx a lot dude!
I asked here before what the TCB screen was supposed to be but never got an answer.
Thanks to your precise findings, this behaviour according to wake-up state 1/2 will soon be emulated in Steem.

Thanks - although I'm still slightly confused over how -29 and -28 are not vertically aligned (WS2) nor right-aligned (WS1/3/4) when they both are 508 cycle lines according to this theory (which seems to pan out). My visual judgment was that -29 is PAL 160 and -28 is NTSC 160, but the code shouldn't be able to produce that due to the failed top border switch to 50Hz.

I'll probably keep pondering it but as long as it emulates correctly I guess it's fine

TCB after fix, WU1
TCB after fix, WU2 (CPU timing)
TCB after fix, WU2 (when registers are hit)

You're opening up a big can of worms I think if emulation wants to go down the way of supporting the known wakestates a proper state machine must be implemented. I don't think it'll be slower than the current tests.

(I use "WU1" and "WU2" notation for the old Ijor wakeup modes myself, and WS1/2/3/4 for the new Paolo ones. In LoSTE I elected to use Dio's DL3-6 notation instead since it's less likely to cause confusion between the two)

Your current implementation if I read the tables correctly, while working for this screen, is a mixture between WU and WS support. I guess it's a choice between emulating known code properly or emulating the hardware as closely as possible.

It's relatively straight forward to convert Paolo's Excel-sheet into a pseudo-code state machine. I might do that later.

/Troed

[Steven Seagal]

Thanks - although I'm still slightly confused over how -29 and -28 are not vertically aligned (WS2) nor right-aligned (WS1/3/4) when they both are 508 cycle lines according to this theory (which seems to pan out). My visual judgment was that -29 is PAL 160 and -28 is NTSC 160, but the code shouldn't be able to produce that due to the failed top border switch to 50Hz.

I'll probably keep pondering it but as long as it emulates correctly I guess it's fine

What matters is what you see. This line -29 should be 60hz (NTSC) but you see that it starts at the 50hz position (PAL), so that's what happens, right?
You couldn't know, but there's a hack in Steem for precisely this program at this scanline, when the shifter counter is read, the value has to be as for a 50hz line (starting at cycle 56), if it's 2 bytes higher (starting at cycle 52), the screen is broken.
I thought it had something to do with Steem internal problems, but your visual inspection implies that it's a ST issue.

Not working:
-30 - 364:S0000 450:S0000 472:r0900 492:r0900 512:r0900 512:T0100 512:#0000
-29 - 020:r0900 040:r0900 060:r0900 080:r0908 512:R0002

Working:
-30 - 388:S0000 474:S0000 496:r0900 512:T0100 512:#0000
-29 - 004:r0900 024:r0900 044:r0900 064:r0900 084:r0908

(r09=read $FF8209, XX=value)

You're opening up a big can of worms I think if emulation wants to go down the way of supporting the known wakestates a proper state machine must be implemented. I don't think it'll be slower than the current tests.

(I use "WU1" and "WU2" notation for the old Ijor wakeup modes myself, and WS1/2/3/4 for the new Paolo ones. In LoSTE I elected to use Dio's DL3-6 notation instead since it's less likely to cause confusion between the two)

Your current implementation if I read the tables correctly, while working for this screen, is a mixture between WU and WS support. I guess it's a choice between emulating known code properly or emulating the hardware as closely as possible.

It's relatively straight forward to convert Paolo's Excel-sheet into a pseudo-code state machine. I might do that later.

/Troed

I call it WU because it's the symbol for wake-up in some devices (HD6301), but I try to enforce WS1 & WS2 of Paolo, ignoring WS3 & WS4 for now.
But you're right that the current implementation is still a mixture.