ASM: Wait for Vertical Blank

[hooverphonique]

Originally Posted by StingRay

Nothing wrong with that, one advantage is that you don't have to care about acknowledging the IRQ (and thus you don't have to deal with interrupt related bugs that can occur on A4000's f.e.) because the OS does that for you.

Back in the day I experienced problems with the vbi running at twice the frequency in many demos and games.. In my own code this could be fixed by either moving the vbr to chipram (my utility "Embedder" does this) or clear the intreq bit twice, iirc - is that the sort of thing you're talking about? I never found any documentation on this stuff back then (something like 15 years ago).

[mc6809e]

Originally Posted by Toni Wilen

Where is this documented? Never heard or noticed when I was checking interrupt cycle usage.

Discussion of autovector operation is found in appendix B of the MC68000 reference manual.

The relationship between /VPA (which indicates an autovectored interrupt) and the E clock determines the length of the autovector read cycle.

I might have been confused about the 18 cycle latency figure, though. I think the E clock potentially adds up to 18 states of latency rather than 18 CPU cycles.

Here's a link to the ref manual that includes appendix B: http://www.freescale.com/files/32bit.../MC68000UM.pdf

[Thorham]

Originally Posted by StingRay

It can make quite a difference not to use interrupts in time critical situations.

Fair enough I suppose that in demos everything is fair game when it comes to these things.

[Toni Wilen]

Originally Posted by mc6809e

Discussion of autovector operation is found in appendix B of the MC68000 reference manual.

I was too tired yesterday, I forgot that Amiga does not use autovectored interrupts, it uses "normal" interrupt acknowledge cycles.

Normal: normal memory cycle and fetches exception vector (from 0xfffff0 + interrupt number * 2 = end of ROM in Amiga)
Autovectored: E cycle and fetches interrupt number.

[StingRay]

Originally Posted by hooverphonique

Back in the day I experienced problems with the vbi running at twice the frequency in many demos and games.. In my own code this could be fixed by either moving the vbr to chipram (my utility "Embedder" does this) or clear the intreq bit twice, iirc - is that the sort of thing you're talking about? I never found any documentation on this stuff back then (something like 15 years ago).

Yep, that's exactly what I was talking about. This problem only happens on 68040/60 machines and can be avoided by writing to INTREQ twice. Might also be that just another access to a custom register is enough after writing to INTREQ but I always used the "write to INTREQ twice" approach.

[hooverphonique]

Originally Posted by StingRay

Yep, that's exactly what I was talking about. This problem only happens on 68040/60 machines and can be avoided by writing to INTREQ twice. Might also be that just another access to a custom register is enough after writing to INTREQ but I always used the "write to INTREQ twice" approach.

right... do you know if this is due to a bug on the A4000 mobo or is the problem "caused" by Motorola on the 040/060? also, if you stick a 040 in an A1200, will it have the same problem?

cheers..

[StingRay]

I think it's an A4000 only problem. I do not know why it happens though.

[Toni Wilen]

AFAIK it happens because 68040/060 is "too fast", write to INTREQ don't reset physical CPU IPLx lines until after small delay (I think it was 1.5 CCK cycles).

040/060 is fast enough to restore SR from stack before Paula has cleared interrupt lines if complete exception stack frame was in data cache.

[phx]

That's interesting. I already wondered about the stupid double INTREQ access in some sources, because I never had any problems with it (A3000 with 68060/50).

I always thought that the "nop" is enough to synchronize the pipeline and to make sure that all write-accesses have been performed.

But maybe I was just lucky, because often my code looks like:

        move.w  d0,INTREQ(a6)
        movem.l (sp)+,d0-d7/a0-a6
        nop
        rte

So the movem provides the required delay?

[Leffmann]

I concur with Toni. I think Mikael Kalms has explained the same thing in an older post here in the coders forum, and there's a document on the Aminet going into this as well; some 040/060 systems simply outrun the motherboard.

I think the only guaranteed solution is a chipset access, f.ex move.w d0, noop(a6) or tst.w dmaconr(a6), perhaps simply tst.w (a6) will work if reading from bltddat doesn't screw something up.

There could be some weird CPU expansion that caches chip memory (fastchip option on the buggy ACA boards perhaps?) so something like tst.w 0.w may not always be enough.

[hooverphonique]

Originally Posted by Leffmann

There could be some weird CPU expansion that caches chip memory (fastchip option on the buggy ACA boards perhaps?) so something like tst.w 0.w may not always be enough.

I certainly hope not - chipram should *never* be cached, that's just asking for problems

[Asman]

Originally Posted by Wepl

ok, but what should be the advantage of this?

I don't see any advantages , both examples should eats same amount of cycles as long as my calculation was correct. But I personally don't like odd custom registers ($dff005) especially when I disasembling something.

[mc6809e]

Originally Posted by Toni Wilen

I was too tired yesterday, I forgot that Amiga does not use autovectored interrupts, it uses "normal" interrupt acknowledge cycles.

Normal: normal memory cycle and fetches exception vector (from 0xfffff0 + interrupt number * 2 = end of ROM in Amiga)
Autovectored: E cycle and fetches interrupt number.

Thanks for this, Toni! All this time I thought "autovector" interrupts were genuine autovector interrupts. I see now from an old post of yours just how the method used by the Amiga works. The vector table entries for the autovector interrupts are simply reused for user interrupts.

Turns out the Amiga designers were even more clever than I had given them credit for.

[TheDarkCoder]

Originally Posted by StingRay

Yep, that's exactly what I was talking about. This problem only happens on 68040/60 machines and can be avoided by writing to INTREQ twice. Might also be that just another access to a custom register is enough after writing to INTREQ but I always used the "write to INTREQ twice" approach.

AFAIR, I did many tests working on P61 610.6, and it resulted that just an access to a custom register, or a CIA register, gives a delay long enough to allow the clearing in INTREQ to "propagate" to the SR of the CPU. Maybe an access in chip ram is enough, too. That sound reasonable, since the speed of those accesses is fixed by Agnus and does not depend on the CPU speed

[Wepl]

Also my experience: a single custom register access is enough.
I don't would use a cia access because these are slower than custom ones (running on slower clock) and sync is required with custom chips.

[TheDarkCoder]

Originally Posted by Wepl

Also my experience: a single custom register access is enough.
I don't would use a cia access because these are slower than custom ones (running on slower clock) and sync is required with custom chips.

yep, a custom register access make sense also because it is Agnus performs it in sequence with the access that cleared INTREQ. It is reasonable to assume that Agnus is designed so that "side effects" of one access (clear INTREQ that propagate to the SR of the CPU) are completed before the following access is performed.
I would also prefer custom access over an access to a CIA register, but there can be cases where it is necessary to access CIA anyway. An example is the interrupt routines for interrupt requests generated by the CIA timers.
So if you first write to INTREQ and then to CIA registers, you are safe without introducing a dummy access to a custom register (like the double write to INTREQ)

Was the best solution ever decided upon during this discussion? There seems to be a few different options, all with positive / negatives:

(a) Waiting for the raster to reach the end of the screen
(b) Polling the vblank intreq bit with vblank interrupts disabled
(c) Setting a flag in the vblank interrupt routine and polling in the main loop

What is the most widespread and accepted use for detecting the vertical blanking period as used by the majority of games?

[meynaf]

Just use graphics.library/WaitTOF() unless you have really really tight timing requirements (which is less often than it looks).

[Photon]

Originally Posted by CptShlockler

Was the best solution ever decided upon during this discussion? There seems to be a few different options, all with positive / negatives:

(a) Waiting for the raster to reach the end of the screen
(b) Polling the vblank intreq bit with vblank interrupts disabled
(c) Setting a flag in the vblank interrupt routine and polling in the main loop

What is the most widespread and accepted use for detecting the vertical blanking period as used by the majority of games?

Thread necromancy!!

The best way is the one that fits what you're developing. Meynaf's suggestion is sensible if you're using libraries or not taking over the hardware, but can be used anytime. (If you want games to support 512k RAM A500s, though, there could be so little memory left that you have to overwrite libraries.)

There are many ways to do it, and there's a place for busy-waiting for (and leaving) a rasterline, too. I use it often.

For software that takes over the hardware, I think the best way is to put the stuff that should happen every frame - in a Vblank interrupt. Normally that would just be a stub with the screen setup code before the raster comes on-screen at the top. (Sprite collision and mouse reads can go here too.)

But from joystick input all the way to buffer updates and switching (the "meat" of the game) could stay in main(), which would then also be throttled to a framerate to not run rogue on fast Amigas.

[pants]

Overkill for most situations, but a 'cover all bases' pattern:

- regular, not-interrupt-triggered cpu, sits in a mostly-idle loop waiting for multi-frame/multi-second tasks (eg background loading/decrunching/pre-processing)
- level3 blitter for blit queue
- level3 vbl increments a global framecount and fires a level1 int (only).
- level3 copper used for *short* line-specific (copper munging) tasks.
- level1 soft for 'mainloop'

this allows for
- line-accurate tasks (also small every-frame/non-vbl tasks like audio replay)
- every-frame global framecount/sync
- variable-frame, but still frame synchronized, mainloop
- many-frame background tasks

Not mine, I saw this again recently but can't remember where...