English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General > Coders. Tutorials

 
 
Thread Tools
Old 10 April 2010, 21:37   #21
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 628
Quote:
Originally Posted by StingRay View Post
Maybe a better way would be to set a flag in the VBI and poll that flag in the mainloop?
As far as I remember some games uses this technique ( For example unfinished polish game Robbo, http://korin.ppa.pl/ ). Rare example of using VERTB as main loop is GordianTomb ( all things are done in VERTB and main loop only drawscreen as I remember ).
Asman is offline  
AdSense AdSense  
Old 10 April 2010, 21:43   #22
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,586
Quote:
Originally Posted by Asman View Post
Rare example of using VERTB as main loop is GordianTomb ( all things are done in VERTB and main loop only drawscreen as I remember ).
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.
StingRay is offline  
Old 11 April 2010, 00:41   #23
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,452
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
Photon is offline  
Old 11 April 2010, 01:39   #24
pmc
rebooting...
pmc's Avatar
 
Join Date: Apr 2007
Location: Elsewhere
Posts: 1,595
Quote:
Originally Posted by StingRay
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.
Just like all my stuff does.

My good old days are today! \o/

pmc is offline  
Old 12 April 2010, 16:40   #25
TheDarkCoder
Registered User
 
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 210
Quote:
Originally Posted by Toni Wilen View Post
First waits for line 0, second waits for line 256. (it can also wait for line 512, 1024 and so on but I think this was about standard video modes )



Technically byte read from custom register is "illegal" but has always worked perfectly fine. Everyone did that

Byte writes to custom registers may not work properly with all accelerator models (Blizzard 1260 for example, only to odd or even bytes, if I remember correctly)
I don't remember any Official docs saying that byte read/writes are illegal. Are you sure?

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.
TheDarkCoder is offline  
Old 12 April 2010, 17:38   #26
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,934
Quote:
Originally Posted by TheDarkCoder View Post
I don't remember any Official docs saying that byte read/writes are illegal. Are you sure?
I said "technically" illegal, as "illegal" as word or long CIA accesses and because byte writes can have different results on different Amigas:

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)
Toni Wilen is offline  
Old 13 August 2012, 12:06   #27
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 628
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
can be changed to (more legal)
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
Any comments are welcome especially If I am wrong.
Asman is offline  
Old 13 August 2012, 21:12   #28
mc6809e
Registered User
 
Join Date: Jan 2012
Location: USA
Posts: 281
Quote:
Originally Posted by Asman View Post
Any comments are welcome especially If I am wrong.
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.
mc6809e is offline  
Old 14 August 2012, 23:14   #29
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 640
Quote:
Originally Posted by Asman View Post
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
can be changed to (more legal)
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
Any comments are welcome especially If I am wrong.
ok, but what should be the advantage of this?
Wepl is offline  
Old 15 August 2012, 10:20   #30
dalton
tulou
dalton's Avatar
 
Join Date: Jun 2006
Location: Gothenburg / Sweden
Posts: 68
I usually set a flag in the vblank isr, like this:

Code:
	bset.b	#0,flags(pc)
and then poll it inside the main loop, like this:

Code:
.wait	bclr.b	#0,flags(pc)
	beq.b	.wait
It's nice because I know that the main loop will not continue until after vblank isr is finished (maybe that's guaranteed anyway, but I'm not sure about that), and also the wait-code is guaranteed to finish only once per vblank because it clears the flag in conjunction with the test.
dalton is offline  
Old 15 August 2012, 11:10   #31
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,019
Quote:
Originally Posted by dalton View Post
Code:
    bset.b    #0,flags(pc)
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.
phx is offline  
Old 15 August 2012, 11:20   #32
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,586
Quote:
Originally Posted by phx View Post
Your approach is recommendable
The disadvantage is that you need a level 3 interrupt which is not always what you want.
StingRay is offline  
Old 15 August 2012, 12:09   #33
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 2,972
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
Thorham is offline  
Old 15 August 2012, 12:24   #34
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,586
It can be done "properly" without a VBL interrupt too! And there are situations where you just don't want any interrupts at all.
StingRay is offline  
Old 15 August 2012, 14:34   #35
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 2,972
Quote:
Originally Posted by StingRay View Post
It can be done "properly" without a VBL interrupt too!
Of course, but it's peecee like and therefore uncool

Quote:
Originally Posted by StingRay View Post
And there are situations where you just don't want any interrupts at all.
Interesting, which situations are those (serious question )?
Thorham is offline  
Old 15 August 2012, 18:23   #36
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,586
Quote:
Originally Posted by Thorham View Post
Of course, but it's peecee like and therefore uncool
So you call more than 50% of the old and classic demos "uncool"?


Quote:
Originally Posted by Thorham View Post
Interesting, which situations are those (serious question )?
Interrupt processing needs CPU time, need I say more?
StingRay is offline  
Old 15 August 2012, 18:46   #37
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 2,972
Quote:
Originally Posted by StingRay View Post
So you call more than 50% of the old and classic demos "uncool"?
Not saying that, I'm saying that peecee style VBL handling is uncool.

Quote:
Originally Posted by StingRay View Post
Interrupt processing needs CPU time, need I say more?
Does it take up so much time you'd use polling? That sucks

Maybe I'm missing the point
Thorham is offline  
Old 15 August 2012, 21:18   #38
mc6809e
Registered User
 
Join Date: Jan 2012
Location: USA
Posts: 281
Quote:
Originally Posted by Thorham View Post
Not saying that, I'm saying that peecee style VBL handling is uncool.


Does it take up so much time you'd use polling? That sucks

Maybe I'm missing the point
Autovectored interrupts on the 68000 have the annoying property that the 68000 must sync with an internally generated E-clock running at CLK/10 during interrupt handling. This can add up to 18 cycles on top of the time needed to push state onto the stack -- up to 44 cycles total.

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.
mc6809e is offline  
Old 15 August 2012, 21:39   #39
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,934
Quote:
Originally Posted by mc6809e View Post
Autovectored interrupts on the 68000 have the annoying property that the 68000 must sync with an internally generated E-clock running at CLK/10 during interrupt handling.
Where is this documented? Never heard or noticed when I was checking interrupt cycle usage.
Toni Wilen is offline  
Old 15 August 2012, 21:45   #40
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,586
Quote:
Originally Posted by Thorham View Post
Does it take up so much time you'd use polling? That sucks

Maybe I'm missing the point
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.
StingRay is offline  
AdSense AdSense  
 


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 09:31
'Wait' program that checks for a joy button press instead of 'Return' key... Heavy Stylus request.Apps 7 10 May 2009 20:01
timed wait using CIAs jotd support.Other 3 23 March 2008 15:55
HD won't boot now..wait failed returncode? Amigan25 project.ClassicWB 2 08 June 2007 19:21
Wait a sec - what about Macs? Computolio Amiga scene 10 02 June 2004 08:23

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 20:45.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.27818 seconds with 13 queries