[solved] Perihelion tutorial #9 (overscan) problem

[LynXX]

Hi,

I'm going through the excellent 68000 assembler tutorials by Perihelion, and I'm having a problem with #9, about removing the top and bottom border of the screen.

With the listing as-is, the borders are not removed and the picture palette is all wrong:

tut-as-is.png

If I edit the code to just attempt to remove the bottom border (by making sure I'm triggering the PAL/NTSC switch on line 199 instead of 228), the bottom border goes away but the palette on the last line is wrong too:

tut-bottom-border.png

Not sure what's going on, the code makes sense to me but it's just not happening. Perhaps the timers are wrong somehow? Or is it an issue with emulation (Hatari), although I tried a couple of overscan demos and they work fine.

Any help would be appreciated I'm attaching the source from the tutorial for reference (as a .TXT file as .S don't seem allowed).

Cheers,

Nico

[troed]

The most common cause for bitplane errors in the lower border when removing it is due to either going to 60Hz too early, thus doing a 60Hz line end (one word less) or staying in 60Hz for too long on the next line thus doing a 60Hz line start (one additional word).

[AtariZoll]

Most likely it is because different CPU clocks in diverse ST(E) machines. There are slight differences which affect exactly this type of overscan.
Maybe you should use Steem SSE instead Hatari - there you can fine tune CPU clock.
I made CPU clock test in my overscan displaying code, what is used in hard disk adapted games intro cover scan displaying. It uses Timer-C, which is clocked via MFP chip with same freq. in all ST, STE models, therefore can measure CPU speed pretty accurately.
If want, can post src. of it here.

[spiny]

the original code from the tutorial seems to work fine in Steam:

Screenshot 2017-08-02 13.27.07.png

[LynXX]

Thanks for your answers,

From what I understand the top border timing is pretty broad / forgiving, so I would have assumed that this one at least would work?

I'm using Hatari because I'm on Linux and Steem is not available. Interestingly I tried it on Steem SSE once I gained access to a Windows machine, and it still doesn't work for me: The palette is correct and the picture displays, but the borders are still there.

I've tried different emulation settings (ST/STe), TOS versions, etc, to no avail (from your screenshot you seem to use a TOS 2.06 on a STe with 1MB ram, correct? I tried that too...).

So:

• Would you mind sharing your Steem config file?
• Are you using the source I posted, or another source? If so would you be able to share it?

Thanks!

Nico

[spiny]

attached steem.ini - renamed as the foum won't allow sme file types.

the source code I used is the one in the tutorial, I just downloaded it from the thread in this forum and compiled it.

I'm using Devpac 3.1

[spiny]

one thing to check, in steem, you can turn off borders, I believe they are on by default though, but worth checking in settings > display > and set the border dropdown to 'normal'

[ST Graveyard]

Great to read these things are still useful! Rip Andreas "Perihelion" Wahlin.

[troed]

From what I understand the top border timing is pretty broad / forgiving, so I would have assumed that this one at least would work?

They're almost the same The check is done at cycle 502 on the line before first new graphics line you can create this way - and you only need to be in 60Hz over that exact spot. You cannot be in 60Hz sooner than cycle 376 on the line before for the lower border, and you must be back at 50Hz at the latest at cycle 36 on the next line (if you want to be STE compatible, else 52) for both.

However, for the top border, there is no "previous line" and so you're correct that it doesn't matter if you're in 60Hz earlier than cycle 376 on the line of the switch.

If you use Timer B to count down the lines there should be no real issues with this. However, if you use Timer A/C to wait until the lower border the different CPU clock speeds (8.007/8.01/8.02/8.05) will indeed cause quite large differences.

(I have not studied the source you're using, sorry)

[spiny]

Great to read these things are still useful! Rip Andreas "Perihelion" Wahlin.

yes, his tutorials are great, i printed a second copy yesterday to keep at work, still trying to get my head round bitplanes

peri.jpg

[LynXX]

So, after a lot of experimentation (involving the setup of a Windows VM to be able to run Steem!), I finally found the culprit!

It has to do with the TOS. If I use an European TOS (e.g. UK), it works fine. If I use a US TOS, or EmuTOS, it doesn't. I assume that's because the US TOS (and EmuTOS) "are" in 60Hz whereas the European ones are 50Hz?

Does that make sense? And if yes, out of curiosity, how can one remove the borders on a US machine / US TOS with a 60Hz monitor? Or would the border removal only work on 50Hz monitors?

[troed]

This is best explained by stating that the top border is never "removed" You can start the screen either at the 60Hz position, or the 50Hz position. The 60Hz position is earlier. What's known as a "removed top border" for 50Hz demo coders is simply a screen starting at the 60Hz position.

Since no earlier position exists, a top border cannot be "removed" in 60Hz.

The lower border can, but all the logic and timing that's valid for 50Hz is different in 60.

[FedePede04]

I'm using Hatari because I'm on Linux and Steem is not available. Interestingly I tried it on Steem SSE once I gained access to a Windows machine, and it still doesn't work for me: The palette is correct and the picture displays, but the borders are still there.

have you try to see if it run using wine linux

[LynXX]

Thanks for the explanation troed! I think I made sense of it especially after having read the overscan article in ST Mag #51 (translated in English there for those who don't read French)

Regarding Steem and Wine, I haven't tried. I tend to stay clear of Windows stuff if I can Hatari worked fine in the end, with the right TOS.

[spiny]

cool, easy fix