What is "sync scrolling"?

All about ST/STE demos

Moderators: lotek_style, Mug UK, Moderator Team

User avatar
npomarede
Atari God
Atari God
Posts: 1328
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Re:

Postby npomarede » Fri Feb 27, 2009 11:55 pm

rdemming wrote:Sorry for the confusion. With "it doesn't use any borders" I meant it doesn't display graphics in any border. So it is not full screen. Actually the visible height of the screen is about 16! lines smaller because the hardware scroll snoops away the top lines.
Robert


Yes, strange one. Although the code is synchronizing with the shifter, all freq / res switches are made 16 cycles too soon than the expected value. As the right border for example really needs a 4 cycles precision, this can't work.

The code only does NOP after syncing before the first hi/lo switch to remove left border, so I don't think the error comes from there.
Perhaps the game is using a kind of bugged self calibration routine similar to Enchanted Lands, but I didn't see anything like that too.

shifter=0x02 video_cyc_w=33780 line_cyc_w=500 @ nHBL=65/video_hbl_w=65 pc=bffe instr_cyc=8
shifter=0x00 video_cyc_w=33788 line_cyc_w=508 @ nHBL=65/video_hbl_w=65 pc=c000 instr_cyc=8
sync=0x00 video_cyc_w=34152 line_cyc_w=360 @ nHBL=66/video_hbl_w=66 pc=c0b4 instr_cyc=8
sync=0x02 video_cyc_w=34160 line_cyc_w=368 @ nHBL=66/video_hbl_w=66 pc=c0b6 instr_cyc=8
shifter=0x02 video_cyc_w=34220 line_cyc_w=428 @ nHBL=66/video_hbl_w=66 pc=c0d2 instr_cyc=8
shifter=0x00 video_cyc_w=34232 line_cyc_w=440 @ nHBL=66/video_hbl_w=66 pc=c0d6 instr_cyc=8

So the technique used is quite the usual way to achieve hardware scroll by removing left/right border, it's just that the code is not correctly synchronized with the shifter when using emulators (right border timings should be 376/384 not 360/368).


Nicolas

ijor
Hardware Guru
Hardware Guru
Posts: 3960
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Re:

Postby ijor » Fri Mar 06, 2009 9:00 pm

rdemming wrote:When I was experimenting with left/right border removal, I discovered 0 bytes lines by using the 70/50 Hz switch...I used this technique on the "Lemmings color shock"


Hi rdemming,

In first place, let me tell you that the Lemmings demo is awesome and impressive, hats off!

But, IMHO, your technique is not fully "kosher". You are altering sync, and this should be avoided. I think it is ok every trick "inside" the computer", but the sync signals should never be messed with. Otherwise you depend on the specific monitor/tv. Your screen probably works with most (perhaps all) ST monitors, but it might break with some third-party ones, and/or scan-doublers.

For years I was wondering why it seems that I am the only one who used the 0 byte line technique (Does somebody know another demo screen that uses 0 byte lines?). But now I read that Paulo and Alien state that this method is very time critical and might not work stable on all STs/STEs. So that might be the reason.


Paulo's technique (not sure about which one Alien is talking about) is different than yours, and it is the correct one. It doesn't alter sync. It was rarely used (if at all), because at the time it was difficult to make it stable. The timing is very critical and then it is wakeup dependant. Currently we know much more about this, so we know how to make it fully stable. There is some other thread were we exchanged ideas with Paulo about this, if you are interested it should be somewhere in the coding section (I believe).

P.S. I read everywhere that there are lots of GLUE/Shifter combinations for STF computers that make it difficult to get a full screen working on every STF.


Personally I believe this is a bit of a mythos. Coders were confused by a few things, mainly by the wakeup issue. E.g.: (IIRC, Leonard might remember better) the main menu of that NOSTALGIC demo, doesn't work in all wakeups.

ijor
Hardware Guru
Hardware Guru
Posts: 3960
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Re:

Postby ijor » Sat Mar 07, 2009 3:03 am

npomarede wrote:So the technique used is quite the usual way to achieve hardware scroll by removing left/right border, it's just that the code is not correctly synchronized with the shifter when using emulators (right border timings should be 376/384 not 360/368)


Nicolas, you are looking at the "small picture". Look at the "big picture" and you will find the answers.

User avatar
rdemming
Atariator
Atariator
Posts: 27
Joined: Wed Jul 04, 2007 9:55 pm
Location: Amstelveen / The Netherlands
Contact:

Re: Re:

Postby rdemming » Fri Mar 13, 2009 1:29 pm

ijor wrote:But, IMHO, your technique is not fully "kosher". You are altering sync, and this should be avoided. I think it is ok every trick "inside" the computer", but the sync signals should never be messed with. Otherwise you depend on the specific monitor/tv. Your screen probably works with most (perhaps all) ST monitors, but it might break with some third-party ones, and/or scan-doublers.

Paulo's technique (not sure about which one Alien is talking about) is different than yours, and it is the correct one. It doesn't alter sync. It was rarely used (if at all), because at the time it was difficult to make it stable. The timing is very critical and then it is wakeup dependant. Currently we know much more about this, so we know how to make it fully stable. There is some other thread were we exchanged ideas with Paulo about this, if you are interested it should be somewhere in the coding section (I believe).



Hi ijor,

I read some of the other topics on the forum about overscan, scrolling, 68000 cycle timing as well. Very interesting read. I believe you did lots of research into the ST hardware and your discussions with paulo, alien, gunstick, leonard and others clarified a lot.

According to Hatari's source, I do the switch to 70-50 at cycle 28 which is position 7 in Alien's article (thus after the position for opening the right border but before the beginning of the normal screen. Coincidentally it seems to be precisely in the middle of this). So you are saying that this alters the H-Sync output signal on the monitor port. I wished I had a oscilloscope to actually see this. Too bad that Alien's pseudo code doesn't specify what happens at position 7. The processing of h-sync is according to Alien's article at position y/y+1 at the end of the scan line. From Aliens pseudo code, I don't see how a switch at position 7 can influence the h-sync signal that occurs much later or much earlier. Maybe you have an explanation for this?
Anyway it works for me on an Atari monitor and on TV sets (both scart RGB and RF) but I would like to hear if someone has a set where it doesn't work..

At that time I also found that you could create a 0-byte line by performing the 70-50 switch earlier, at the beginning of a Timer-B interrupt (see my earlier post). This gave indeed distortion and it wouldn't surprise me that here the switch occurs around h-sync processing at position y/y+1 in Alien's article. If someone is interested I can post the source code for that but it shouldn't be used since it doesn't work on every monitor.

So I suppose the correct position for a 0-byte line is a 60-50 switch at cycle 56 (Hatari's source) / position 13 (in Alien's article)?

Someone should extend Alien's article with the other found oddities (paulo's black line, Enchanted Land extra right border, start up states, etc.). :D

Robert
There are 10 kinds of people. Those who understand binary and those who don't.

ijor
Hardware Guru
Hardware Guru
Posts: 3960
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Re:

Postby ijor » Sat Mar 14, 2009 5:00 am

rdemming wrote:So you are saying that this alters the H-Sync output signal on the monitor port. I wished I had a oscilloscope to actually see this. Too bad that Alien's pseudo code doesn't specify what happens at position 7. The processing of h-sync is according to Alien's article at position y/y+1 at the end of the scan line. From Aliens pseudo code, I don't see how a switch at position 7 can influence the h-sync signal that occurs much later or much earlier. Maybe you have an explanation for this?


Alien describes a basic interpretation of the model, it is not complete neither 100% exact. It is a great article, and it let many of us understand the main idea. But we learnt quite some since then.

There are several spots where you can alter sync, and there are several different types of sync alterations. Some switches affect the video process at a later time. That is, most switches affect only changes that are processed at the time of the switch, but not all of them. Some switches, especially those affecting sync, have a delayed effect.

So I suppose the correct position for a 0-byte line is a 60-50 switch at cycle 56 (Hatari's source) / position 13 (in Alien's article)?


The exact position is not fixed, it depends on the current wake up. You have to implement wakeup detection and adapt your code at run-time.

User avatar
npomarede
Atari God
Atari God
Posts: 1328
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Re:

Postby npomarede » Sun Mar 15, 2009 2:08 pm

ijor wrote:
npomarede wrote:So the technique used is quite the usual way to achieve hardware scroll by removing left/right border, it's just that the code is not correctly synchronized with the shifter when using emulators (right border timings should be 376/384 not 360/368)


Nicolas, you are looking at the "small picture". Look at the "big picture" and you will find the answers.


No, not another riddle ;-)

Do you mean that it could be the function that compute the value of $ff8209 that is wrong and gives this 16 cycles shifting ? But this would be the first case I see where it's wrong since a long time.
Or some CPU features not correctly emulated (I don't see possible instructions pairing, and 16 cycles is quite a lot of opcode that would need to pair) ?

I tried to look for possible 60 Hz switching that would make the line different from the usual 512 cycles, but no such one found.

The fact that it doesn't work with any emulator is certainly interesting ; Ijor, any additionnal hint would be appreciated :)

Nicolas

User avatar
npomarede
Atari God
Atari God
Posts: 1328
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Re:

Postby npomarede » Sun Mar 15, 2009 2:18 pm

ijor wrote:
rdemming wrote:So I suppose the correct position for a 0-byte line is a 60-50 switch at cycle 56 (Hatari's source) / position 13 (in Alien's article)?


The exact position is not fixed, it depends on the current wake up. You have to implement wakeup detection and adapt your code at run-time.


Yes, Hatari's timings for the 0 byte line are not the exact ones compared to an STF.

Hatari currently doesn't support emulating the exact position of the write cycle of an instruction (this is a planned features but would require a lot of changes to the cpu core), so timings are adapted to the fact that memory write is considered to be on a 4 cycles boundary (while on STF, it could be on a 2 cycles boundary, as discussed in another thread regarding wakeup states and others).

0 byte timings in Hatari were adapted to make those demos works, but the real way to do it would be to use proper STF timings and make hatari work on 2 cycles write accesses too.

Nicolas

ijor
Hardware Guru
Hardware Guru
Posts: 3960
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Re:

Postby ijor » Tue Mar 17, 2009 8:13 pm

npomarede wrote:No, not another riddle ;-)


It's not a riddle, it's and advice :) I have the feeling that Leonard might realize what's going on. If so, he deserves to fix Saint first.

Ijor, any additionnal hint would be appreciated :)


There is a huge hint, mentioned more than once, and you still don't see it...

User avatar
npomarede
Atari God
Atari God
Posts: 1328
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Re:

Postby npomarede » Mon Mar 23, 2009 9:19 pm

ijor wrote:
npomarede wrote:No, not another riddle ;-)


It's not a riddle, it's and advice :) I have the feeling that Leonard might realize what's going on. If so, he deserves to fix Saint first.

Ijor, any additionnal hint would be appreciated :)


There is a huge hint, mentioned more than once, and you still don't see it...


Ijor, assuming no one find the explanation, can we expect an answer in one week for instance ? :)

In the same list of badly emulated program, any idea on why Seven Gates Of Jambala is not correctly emulated under Hatari/Steem (locks on the intro with Saint) during game ?
The timer B interrupt are delayed 2 lines later on each VBL, creating some kind of "scrolling" rasters.
From the point of view of what is written in fffa21, the expected result should indeed be that rasters are delayed by 2 lines on each VBL ; but a real ST doesn't show this problem and the rasters are stable.
Only "strange" thing I see is that the game is changing bit 3 of fffa03 twice per VBL during the timer B interrupt handler. Bit 3 is normally blitter related, and I don't see indication in the MFP doc about a relation between this bit and timer B.

Nicolas

ijor
Hardware Guru
Hardware Guru
Posts: 3960
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Re:

Postby ijor » Mon Mar 23, 2009 10:40 pm

npomarede wrote:Ijor, assuming no one find the explanation, can we expect an answer in one week for instance ? :)


Nicolas, why do you think they are trying to opening the border?

7 days to go :)

In the same list of badly emulated program, any idea on why Seven Gates Of Jambala is not correctly emulated under Hatari/Steem (locks on the intro with Saint) during game ?...Only "strange" thing I see is that the game is changing bit 3 of fffa03 twice per VBL during the timer B interrupt handler. Bit 3 is normally blitter related, and I don't see indication in the MFP doc about a relation between this bit and timer B.


If you don't see the relation, then you are not reading the docs.

7 days to go :)

User avatar
npomarede
Atari God
Atari God
Posts: 1328
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Re:

Postby npomarede » Mon Mar 23, 2009 11:28 pm

ijor wrote:
npomarede wrote:Ijor, assuming no one find the explanation, can we expect an answer in one week for instance ? :)


Nicolas, why do you think they are trying to opening the border?

7 days to go :)


I haven't counted the bytes per line, but this looks to me like doing a 160 bytes vertical hardscroll using a combination of 7 normal or 230 bytes overscan lines. Since there's what look like a hi/lo stabilizer after the 60/50 switch, this looks like a normal 230 overscan line to me (minus the timing), but it seems I'm wrong.

In the same list of badly emulated program, any idea on why Seven Gates Of Jambala is not correctly emulated under Hatari/Steem (locks on the intro with Saint) during game ?...Only "strange" thing I see is that the game is changing bit 3 of fffa03 twice per VBL during the timer B interrupt handler. Bit 3 is normally blitter related, and I don't see indication in the MFP doc about a relation between this bit and timer B.


If you don't see the relation, then you are not reading the docs.

7 days to go :)


Regarding this one I think I won't have to wait that long :), I opened a thread in viewtopic.php?f=16&t=16213 and as pointed by Hans and you I was indeed reading the wrong doc. I had the feeling changing bit 3 was causing a decrement on the timer b count, but reading an official pdf data sheet was much clearer on this point.
What do you think on the possibility to have the interrupt trigger when DE is enabled for timer B ? Have you ever tested such mode (I should get my real ST to test this in fact ...). Feel free to answer on this other thread if you wish.

Nicolas

ijor
Hardware Guru
Hardware Guru
Posts: 3960
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Re:

Postby ijor » Tue Mar 24, 2009 3:06 am

npomarede wrote:I haven't counted the bytes per line, but this looks to me like doing a 160 bytes vertical hardscroll using a combination of 7 normal or 230 bytes overscan lines.


The problem is not that you didn't count the bytes per line. The problem is that you didn't count the lines. That's (one of the reasons) why I said you should look at the "big picture".

But I used "big picture" in a differente sense as well, absolutely non-technical, not hardware (or software) related at all.

6 days to go :)

User avatar
npomarede
Atari God
Atari God
Posts: 1328
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: What is "sync scrolling"?

Postby npomarede » Sun Mar 29, 2009 10:54 pm

Time's up :)
I now have a working version of Hatari for this game and the scrolling method used is working fine and smooth.

Well, I still don't get the clue you tried to give in your latest message :), but after looking again at the game, I noticed that it never used ff8201/03 which are usually needed to first adapt screen address to the closest multiple of 256, then using different line width to get a sub 256 bytes precision (when doing "traditional" hardware scroll on STF).

Only option left is that it used in fact a technique I even already think about some times ago (but completly forgot it...) which is also quite similar to the technique used in the Lemmings screen to scroll up/down the bottom part of the screen.
But the switches they used in their "synchronised" lines are quite misleading, as most of them are useless in fact ; I just never encountered this switch before at this position and didn't know it had this effect.

Ijor, thanks for your message anyway, even if I didn't get your hint, at least it convinced me that I needed to search harder :)

Nicolas

User avatar
rdemming
Atariator
Atariator
Posts: 27
Joined: Wed Jul 04, 2007 9:55 pm
Location: Amstelveen / The Netherlands
Contact:

Re: What is "sync scrolling"?

Postby rdemming » Tue Mar 31, 2009 7:46 am

So you mean it uses 0-byte lines for hardware scrolling? Does it use a new technique or uses it the already known 70-50 or 60-50 switch methods but was the emulation confused because of the unnecessary switches around it?

Before Hatari & SaintT supported 0-bytes lines I suspected No Buddies land was using 0-byte lines like my screen. But when I tried No Buddies Land on the new versions that supported 0-byte lines it still didn't work, so it made me wondering what it uses instead.

It good to see that Atari ST emulation is getting closer and closer to the real thing.

Robert
There are 10 kinds of people. Those who understand binary and those who don't.

User avatar
npomarede
Atari God
Atari God
Posts: 1328
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: What is "sync scrolling"?

Postby npomarede » Tue Mar 31, 2009 8:14 am

rdemming wrote:So you mean it uses 0-byte lines for hardware scrolling? Does it use a new technique or uses it the already known 70-50 or 60-50 switch methods but was the emulation confused because of the unnecessary switches around it?

Before Hatari & SaintT supported 0-bytes lines I suspected No Buddies land was using 0-byte lines like my screen. But when I tried No Buddies Land on the new versions that supported 0-byte lines it still didn't work, so it made me wondering what it uses instead.

It good to see that Atari ST emulation is getting closer and closer to the real thing.

Robert


Yes, it's a 0 byte line, but it's done by switching to hi/lo at cycle 500/508 (end of previous line). Cycle 508 is a very particular position in STF, as this is already the limit where you must switch 60/50 to remove top/bottom border.
So, I would say it's a 3rd way to get a 0 byte line (other 2 methods are switching while in the left border of the line to shut down).

I don't know if this method has been talked about somewhere in this forum or if it's used in other games/demos (never saw it anyway)

Nicolas

User avatar
rdemming
Atariator
Atariator
Posts: 27
Joined: Wed Jul 04, 2007 9:55 pm
Location: Amstelveen / The Netherlands
Contact:

Re: What is "sync scrolling"?

Postby rdemming » Tue Mar 31, 2009 2:45 pm

npomarede wrote:Yes, it's a 0 byte line, but it's done by switching to hi/lo at cycle 500/508 (end of previous line). Cycle 508 is a very particular position in STF, as this is already the limit where you must switch 60/50 to remove top/bottom border.
So, I would say it's a 3rd way to get a 0 byte line (other 2 methods are switching while in the left border of the line to shut down).


The 70-50 switch at cycle 28 alters the sync signal,
The 60-50 switch at cycle 56 is very time sensitive and depends on the start-up state.
So the question is whether the 70-50 switch at position 500/508 doesn't alter the sync signal and is not so time sensitive as the 60-50 switch.

It is amazing that after all this time, there are still new sync "tricks" (re)discovered.

Robert
There are 10 kinds of people. Those who understand binary and those who don't.

User avatar
npomarede
Atari God
Atari God
Posts: 1328
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: What is "sync scrolling"?

Postby npomarede » Tue Mar 31, 2009 2:54 pm

rdemming wrote:The 70-50 switch at cycle 28 alters the sync signal,
The 60-50 switch at cycle 56 is very time sensitive and depends on the start-up state.
So the question is whether the 70-50 switch at position 500/508 doesn't alter the sync signal and is not so time sensitive as the 60-50 switch.


As they used this technique in a commercial game, I think they couldn't take the risk to release a game with a video technique that would not work on all STF models.
Also, I didn't see any code that take care of the "wake up" state, so I think the switch can work on a standard 4 cycle boundary.
So I would say this switch must be stable (as for altering the sync, I don't know, but as it's just before the hbl anyway, perhaps the eventual sync alteration is "cancelled" by the hbl signal generation and doesn't have many impact)

Nicolas

ijor
Hardware Guru
Hardware Guru
Posts: 3960
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: What is "sync scrolling"?

Postby ijor » Thu Apr 02, 2009 2:40 pm

npomarede wrote:Time's up :)
I now have a working version of Hatari for this game and the scrolling method used is working fine and smooth.


Well done !

I noticed that it never used ff8201/03 which are usually needed to first adapt screen address to the closest multiple of 256, then using different line width to get a sub 256 bytes precision (when doing "traditional" hardware scroll on STF).


Exactly, that was my point. You were too focused (and blinded) by the switches being apparently 16 cycles off, but you missed the overall technique, which obviously wasn't trying to open the borders.

Well, I still don't get the clue you tried to give in your latest message :)


Not even now ! ? You are so great a coder, but seems you are not so good a detective :)

Who raised the issue of this game not working under emulation? What else he mentioned and what else he talked about? It was rdemming, and he talked all the time about zero-bytes lines. Furthermore, he mentioned this technique used for vertical scrolling. Wasn't that such a huge hint?

I didn't know which was exactly the relation between rdemming and "No Buddies" (until now that he explained the relation), but it was obvious that there was one. Either he knew the coders, or he suspected that they used a similar technique (or the very same one) as his one. Whatever, it would have been too much of a coincidence that he raised both issues just by chance, without both being related in any way.

rdemming wrote:So the question is whether the 70-50 switch at position 500/508 doesn't alter the sync signal and is not so time sensitive as the 60-50 switch.


It does alter sync, it is not wake-up sensitive.

User avatar
npomarede
Atari God
Atari God
Posts: 1328
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: What is "sync scrolling"?

Postby npomarede » Thu Apr 02, 2009 3:46 pm

ijor wrote:
npomarede wrote:I noticed that it never used ff8201/03 which are usually needed to first adapt screen address to the closest multiple of 256, then using different line width to get a sub 256 bytes precision (when doing "traditional" hardware scroll on STF).


Exactly, that was my point. You were too focused (and blinded) by the switches being apparently 16 cycles off, but you missed the overall technique, which obviously wasn't trying to open the borders.

Yes, very strange they left the "right" border switch as well as the "stabilizer". In fact, I wonder if it wasn't made on purpose to obfuscate the code in the case someone tried to rip their routine to make him believe this is a 230 overscan line.

Well, I still don't get the clue you tried to give in your latest message :)


Not even now ! ? You are so great a coder, but seems you are not so good a detective :)

Who raised the issue of this game not working under emulation? What else he mentioned and what else he talked about? It was rdemming, and he talked all the time about zero-bytes lines. Furthermore, he mentioned this technique used for vertical scrolling. Wasn't that such a huge hint?

I didn't know which was exactly the relation between rdemming and "No Buddies" (until now that he explained the relation), but it was obvious that there was one. Either he knew the coders, or he suspected that they used a similar technique (or the very same one) as his one. Whatever, it would have been too much of a coincidence that he raised both issues just by chance, without both being related in any way.

I had the feeling rdemming didn't know the game was using 0 byte line, so for me it's a coincidence, but only him can tell :)
But as 0 byte lines were rarely used anyway and not always correctly emulated, it's not such a coincidence in fact that the remaining demos/games with issues could use this technique.

rdemming wrote:So the question is whether the 70-50 switch at position 500/508 doesn't alter the sync signal and is not so time sensitive as the 60-50 switch.


It does alter sync, it is not wake-up sensitive.


By the way, do you have more info on this switch ? Do you know what happens at cycle 508, it looks like an important position regarding video tricks and Alien's articles are not refering it ?

Nicolas

User avatar
leonard
Moderator
Moderator
Posts: 660
Joined: Thu May 23, 2002 10:48 pm
Contact:

Re: What is "sync scrolling"?

Postby leonard » Thu Apr 02, 2009 6:57 pm

Hi all,

Interesting 0 byte line new switch position. I added that feature in SainT, but strangely, the switch appair at position 0 of the line (and not 508 of the previous line). So two possibilities:

a) we don't have the same starting position to cound "offset" in SainT and HATARI. To be sure, SainT right border open occurs at offset cycle 388. Is it the same for HATARI?

b) SainT or HATARI has a bug in cycle counting and this produce two different offsets (508 and 0) for that game.

Could you tell me if you use 388 cycle offset for right-border opening?

Cheers,
Arnaud
Leonard/OXYGENE.

User avatar
npomarede
Atari God
Atari God
Posts: 1328
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: What is "sync scrolling"?

Postby npomarede » Thu Apr 02, 2009 7:20 pm

leonard wrote:Hi all,

Interesting 0 byte line new switch position. I added that feature in SainT, but strangely, the switch appair at position 0 of the line (and not 508 of the previous line). So two possibilities:

a) we don't have the same starting position to cound "offset" in SainT and HATARI. To be sure, SainT right border open occurs at offset cycle 388. Is it the same for HATARI?

b) SainT or HATARI has a bug in cycle counting and this produce two different offsets (508 and 0) for that game.

Could you tell me if you use 388 cycle offset for right-border opening?

Cheers,
Arnaud


Yes, it seems we don't use the same position.
In Hatari, I tried to emulate the cycle where the write occurs, so for example with move.b d0,(a0) at cycle 300, the write occurs at cycle 304. It seems you're using 308 in your case, which is the end of the instruction ? But in the case of more "complex" opcodes than a move.b dx,(ay), the write can be "validated' before the end of the instruction (as described by Ijor in his prefetching articles), so considering the write position is the end of the instruction is wrong.

Hatari's timing match the ones in Alien's article for example, so if I take a right border removal (the one from Nostalgic-o-demo :) ), I have :

sync=0x00 video_cyc_w=101240 line_cyc_w=376 @ nHBL=197/video_hbl_w=197 pc=1ee84 instr_cyc=8
detect remove right
sync=0x02 video_cyc_w=101248 line_cyc_w=384 @ nHBL=197/video_hbl_w=197 pc=1ee86 instr_cyc=8

(this implies in 50 Hz display starts at cycle 56 and ends at cycle 376.)

the corresponding asm code would be :
move.b d0,(a0) at cycle 372 ; 60 Hz
move.b d1,(a0) at cycle 380 ; 50 Hz

So Hatari and Saint are not counting position on the same base, but this should help you to do the translation.

Nicolas

User avatar
leonard
Moderator
Moderator
Posts: 660
Joined: Thu May 23, 2002 10:48 pm
Contact:

Re: What is "sync scrolling"?

Postby leonard » Thu Apr 02, 2009 7:41 pm

Hi Nicolas

Thanks for the fast reply :-) Ok we don't use the same reference. Btw you're absolutly right regarding the exact writing cycle position in the middle of an instruction. SainT does not support this, because the 68k emulation core engine rely on Starscream 68k emulator, and does not support such enhanced feature. SainT support some "prefetch" weird stuff with some hack in the Starcream code. (and hopefully I don't know any fullscreen routine opening borders with weird instruction such as add.l #2,(a0) :-)

Btw did you write the 68k emulation core in HATARI? I never had courage to remove starscream from SainT. It was cool at the time I had my Pentium 2 at 233Mhz coz fullscreen worked at 50hz on my PC. But today, starscream and its native x86 assembly code is a pain for SainT :-)

Arnaud
Leonard/OXYGENE.

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 5215
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: What is "sync scrolling"?

Postby simonsunnyboy » Thu Apr 02, 2009 7:59 pm

Hatari uses a patched UAE CPU core.
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

User avatar
rdemming
Atariator
Atariator
Posts: 27
Joined: Wed Jul 04, 2007 9:55 pm
Location: Amstelveen / The Netherlands
Contact:

Re: What is "sync scrolling"?

Postby rdemming » Fri Apr 03, 2009 10:04 am

ijor wrote:Who raised the issue of this game not working under emulation? What else he mentioned and what else he talked about? It was rdemming, and he talked all the time about zero-bytes lines. Furthermore, he mentioned this technique used for vertical scrolling. Wasn't that such a huge hint?

I didn't know which was exactly the relation between rdemming and "No Buddies" (until now that he explained the relation), but it was obvious that there was one. Either he knew the coders, or he suspected that they used a similar technique (or the very same one) as his one. Whatever, it would have been too much of a coincidence that he raised both issues just by chance, without both being related in any way.


npomarede wrote:I had the feeling rdemming didn't know the game was using 0 byte line, so for me it's a coincidence, but only him can tell :)
But as 0 byte lines were rarely used anyway and not always correctly emulated, it's not such a coincidence in fact that the remaining demos/games with issues could use this technique.


No, I don't know the programmers. Besides that they are also Dutch, there is no relation. The people behind No Buddie Land (Eternal Software) also made the SynthDream (anti mad-max) sound demo and are also the people behind cracking/demo crew Hotline.

Some time ago, when I was playing with the ST emulators, I already noticed that No Buddies Land was not scrolling, just like my own demo. Since other hardware scrollers did work in the emulators, I indeed assumed that they use a similar technique as mine as they had vertical scrolling only. Especially since in Hatari the screen was scrolling with 8 lines at the time which is what you would expect when 0-byte lines are not emulated. When they did use left/right border tricks, you would expect that the screen would be flipping all around (horizontal offsets). But the strange thing was that in SainT and in STeem, the screen was indeed flipping around, so I was in doubt.

After also Leonard added 0-byte line support to SainT I tried No Buddies Land in Hatari and SainT again to see if it worked now. Since it still didn't work I doubted even more about that they used 0-byte lines and I raised the topic here.

So in short, yes I suspected they used 0-byte lines but I was in doubt because of the flipping in SainT. Now I think the flipping was caused by the unnecessary switches Nicolas was talking about and were interpreted by SainT as border opening switches.

Robert
There are 10 kinds of people. Those who understand binary and those who don't.

Gunstick
Captain Atari
Captain Atari
Posts: 289
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

Re: What is "sync scrolling"?

Postby Gunstick » Sun Apr 05, 2009 11:46 pm

when I was experimenting overscan and scrolling my test program was using + and - keys to move the switches on the screen. So I wrote down all possibilities I found (but can't find the paper right now). What I discovered was 2 types of 0 byte lines. One which was displaying the background color, and so not increasing the screen counter. And another one was displaying nothing. A really black line (I think that's what you mean by changing sync signals) where even color 0 was not shown. I called that a second VBL. I think even timer B is not triggered in that line.

I have to say that the second VBL is a quite stable signal as long as it's not over too many lines. My old Thompson CRT was very useful for this. It shows (when you blow up brightness) all border switches in nice grey/black patterns on the right HBL. It also shows all distorted sync signals, and that 2nd VBL did nothing like this, it was just an additional line. It also caused the screen to be completely shifted down (so gaining 1 line at the bottom). But I did not explore the whole consequences of this.

The other type of 0 byte line was just pausing the shifter and showing color 0 but I think timer B was still working and the screen did not gain lines at the bottom.


Social Media

     

Return to “Demos - General”

Who is online

Users browsing this forum: No registered users and 10 guests