Stumped (entry level ASM, gah)

Page 5/6
1 | 2 | 3 | 4 | | 6

By MSX_Noob

Resident (51)

MSX_Noob's picture

21-08-2014, 00:55

It worked! of course it worked! Smile

So I played a bit further with it and created this moving box that bounces over the screen
showing what's on page 1 at same coordinates ,a bit like a "see through" window.

It uses 3 HMMM's, the window and 2 to store what's in the background of the visible page and recover again.

Question: Is it one of those things every VDP coder has to cope with that my moving box flickers on the first 32 lines on top? Everywhere else on the screen it moves ok.

oh yes, I used a "halt" command to slow it down, next challenge (appart from the flickering): put in HTMI hook

By Grauw

Ascended (10581)

Grauw's picture

21-08-2014, 01:29

Sounds cool Smile.

The reason for the screen tearing is that the TV’s beam “catches up” with the draw command. You need to either make sure to stay ahead of it, or stay behind it.

Putting it in the H.TIMI hook will help to reduce or eliminate the flicker, because then your code will execute at the start of the vertical blanking period (VDP commands are also faster during this period). This will help to stay ahead of the beam. If you use halt to wait, the BIOS ISR will execute and this takes quite a while to complete, so there’s less (or no) time left before the display starts again.

Another approach is to use double buffering, render on page 1 and switch screen pages on the H.TIMI interrupt, then render on page 0, etc. This way you do not need to worry about staying ahead or bind the beam.

Finally, you can “follow the beam”, i.e. to make sure the beam always stays ahead of the copy. This is requires some more advanced techniques and knowledge about the VDP though, so I won’t elaborate on that for now Smile.

By ro

Scribe (4698)

ro's picture

21-08-2014, 07:52

When using the page-flip technique, make sure you do that on vblank (bottom of the screen interupt).Otherwise you'll "see" the flipping in progress, for the same reason as mentioned.

By MSX_Noob

Resident (51)

MSX_Noob's picture

21-08-2014, 10:48

LOL, the HTMI hook made me realize that order of sequence is very important...

When I ran this now I saw nothing.

Because the last copy in the loop is the restore of the background.... Big smile

to say it with euphemism:
Where there was color 0,0,0 , there's now color 1,0,0 with a small bright dot... Smile

By Driehoogvoor

Resident (52)

Driehoogvoor's picture

21-08-2014, 11:24

Haha, grats. It's always nice when it's working, but you can also explain why it's working. Smile

By hit9918

Prophet (2923)

hit9918's picture

21-08-2014, 22:18

the starfield is cool.

"loop" seems to be called by interrupt. is it allowed to do EI in H.TIMI?
I thought it is disallowed to do EI in interrupt servers.
else other servers may face unexpected double interrupt. and the own one, too.

even when the code is short and nothing else running in the system,
the diskette with its DI EI business may make the first interrupt that you get end up in an odd location.
like near the bottom border and then whoops VDP makes another one, double interrupt.

one could prevent the odd position with saying HALT before installing the server.

By Grauw

Ascended (10581)

Grauw's picture

21-08-2014, 22:50

hit9918 wrote:

"loop" seems to be called by interrupt. is it allowed to do EI in H.TIMI?
I thought it is disallowed to do EI in interrupt servers.
else other servers may face unexpected double interrupt. and the own one, too.

I’m pretty sure it is, as H.TIMI itself also enables the interrupt shortly after the hook.

However, unless you’re expecting other interrupts, there is little benefit to doing so. If you do, you indeed have to worry about double interrupts. Simple to solve (just add a flag + check), but if you don’t, unexpected behaviour may arise.

By hit9918

Prophet (2923)

hit9918's picture

21-08-2014, 23:13

when bios does it afterwards, that isnt giving information.
mhm, do the H.TIMI example codes need to get added a mutex? Smile

now that I think of it, maybe one could even do EI in fd9a if it was the own device who made interrupt.
and then return with DI.
maybe returning with DI is also recomended in h.timi to not shock other servers.

with the EI business I am especially thinking of calling bios codes that do EI.
like keyboard and PSG.
and PSG read is not shielded by DI. I am puzzled.

By Grauw

Ascended (10581)

Grauw's picture

21-08-2014, 23:24

Yeah.

I looked into the BIOS ISR a while ago, and if I’m not mistaken indeed it isn’t fully resistant against double interrupts. There’s no flag to guard against it and e.g. if I recall correctly in the keyboard handling there could be minor problems in the interpretation of key presses if a double interrupt happens in the wrong place.

By hit9918

Prophet (2923)

hit9918's picture

21-08-2014, 23:50

I think apps calling RDPSG got to disable interrupt.
Else couldn't have sound players in interrupt.
Bios interrupt server doing sticks, at 0c99 is a call to 120c where a DI is done.

a sidenote, in your docs, phydio #0144, the drive number in the akku is missing.
and on format maybe, too?

Page 5/6
1 | 2 | 3 | 4 | | 6