10 April 2010, 20:37 | #21 | |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
Quote:
|
|
10 April 2010, 20:43 | #22 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,865
|
Actually it is not that rare, a lot of demos from "the good old days" (i.e. 50FPS effects or die! ;D) do everything in the VBI and the only thing they do outside the VBI is checking left mouse button.
|
10 April 2010, 23:41 | #23 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,698
|
I execute "stuff to happen at Vblank" with a Vblank interrupt Or use a lib function. If you have a copper running you can write to INTREQ and poll a bit. If you have random ints running you can have a bhs-wait for a rasterline and a bhi-wait to make sure you leave it in case you do nothing that frame.
The Amiga is versatile |
11 April 2010, 00:39 | #24 | |
gone
Join Date: Apr 2007
Location: completely gone
Posts: 1,596
|
Quote:
My good old days are today! \o/ |
|
12 April 2010, 15:40 | #25 | |
Registered User
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 213
|
Quote:
I do remember that HRM says its legal to read/write a pair of registers with a long access, and that since many (or all?) registers are either read-only or write-only, it is illegal to access a register with a CPU instruction that perform both a read and a write on its operand like CLR on 68000, or BSET/BCLR. But BTST should only read its operand, I think. |
|
12 April 2010, 16:38 | #26 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,575
|
Quote:
A500: 0x12 byte write is written as 0x1212 but in some accelerators it can be 0x0012 or even 0x<garbage byte>12 or something similar. (afaik whdload AUDxVOL byte write fixes on 68060 are needed because of above "feature") (getting a bit offtopic, sorry) |
|
13 August 2012, 11:06 | #27 |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
Just for clarification. About byte read from custom register ($dff005). If I understand correctly below code
Code:
wait_vb_2 .1 btst #0,(_custom+vposr+1) bne .1 .2 btst #0,(_custom+vposr+1) beq .2 rts Code:
wait_vb_2 moveq #1,d0 lea (_custom+vposr),a0 .1 move.w (a0),d1 and.w d0,d1 bne .1 .2 move.w (a0),d1 and.w d0,d1 beq .2 rts |
13 August 2012, 20:12 | #28 |
Registered User
Join Date: Jan 2012
Location: USA
Posts: 373
|
A bit off-topic, but I'd give yourself some more processing time by waiting for the last displayable scanline instead of VB. The best place to begin running code for the next frame if single-buffering is often just after the last displayable line, especially if some memory needs to be cleared. You get almost double the normal memory bandwidth when there's no other DMA going on. Pairing MOVEM with a blitter memory clear is especially fast. A blit using channels BCD (a rectangular bitmap move, for example) runs nicely in parallel with the CPU during the overscan areas, even with blitter-nasty turned on.
If you're double buffering, beginning your processing at the first line is often best, especially if you're calling anything in ROM. |
14 August 2012, 22:14 | #29 | |
Moderator
Join Date: Nov 2001
Location: Germany
Posts: 876
|
Quote:
|
|
15 August 2012, 09:20 | #30 |
tulou
Join Date: Jun 2006
Location: Gothenburg / Sweden
Posts: 88
|
I usually set a flag in the vblank isr, like this:
Code:
bset.b #0,flags(pc) Code:
.wait bclr.b #0,flags(pc) beq.b .wait |
15 August 2012, 10:10 | #31 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,553
|
Your approach is recommendable, although the PC-relative addressing mode is not allowed here.
In Sqrxz I am incrementing a frame counter during a copper interrupt, caused at the bottom of the display. The rendering routine can then compare its frame counter with the hardware frame counter and decide to either drop the frame, when the hw-counter is higher, or wait until both are equal again. |
15 August 2012, 10:20 | #32 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,865
|
|
15 August 2012, 11:09 | #33 |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,866
|
Why not do it properly and use the VBL interrupt instead of doing it like they do it on the peecee? On the peecee polling is necessary, on the Amiga it's not
|
15 August 2012, 11:24 | #34 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,865
|
It can be done "properly" without a VBL interrupt too! And there are situations where you just don't want any interrupts at all.
|
15 August 2012, 13:34 | #35 |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,866
|
Of course, but it's peecee like and therefore uncool
Interesting, which situations are those (serious question )? |
15 August 2012, 17:23 | #36 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,865
|
So you call more than 50% of the old and classic demos "uncool"?
Interrupt processing needs CPU time, need I say more? |
15 August 2012, 17:46 | #37 | |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,866
|
Quote:
Does it take up so much time you'd use polling? That sucks Maybe I'm missing the point |
|
15 August 2012, 20:18 | #38 | |
Registered User
Join Date: Jan 2012
Location: USA
Posts: 373
|
Quote:
And then you have to worry about the time it takes for the current instruction to complete before interrupt handling can even begin. A DIVU can delay interrupt handling by 100+cycles. This can be helped by executing a STOP and waiting for an interrupt, but the E-clock still complicates things. There are even situations where an interrupt handler must be padded with a variable number of instructions based on the predicted phase of the E-clock so as to perfectly time 68000 writes to chip registers. This might happen when reprogramming the sprite registers with a MOVEM in the middle of a scanline. Polling is quick and simple. |
|
15 August 2012, 20:39 | #39 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,575
|
|
15 August 2012, 20:45 | #40 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,865
|
Well, you need 2x movem (if you do more than just just testing the VBL flag in the interrupt at least) plus the rte which take up a fair amount of processor time. It can make quite a difference not to use interrupts in time critical situations.
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Removing the IDE Wait on Kickstart 3.1 | Zetr0 | support.Hardware | 26 | 16 June 2010 08:31 |
'Wait' program that checks for a joy button press instead of 'Return' key... | Heavy Stylus | request.Apps | 7 | 10 May 2009 19:01 |
timed wait using CIAs | jotd | support.Other | 3 | 23 March 2008 14:55 |
HD won't boot now..wait failed returncode? | Amigan25 | project.ClassicWB | 2 | 08 June 2007 18:21 |
Wait a sec - what about Macs? | Computolio | Amiga scene | 10 | 02 June 2004 07:23 |
|
|