English Amiga Board Amiga Lore


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

 
 
Thread Tools
Old 15 August 2012, 22:02   #41
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 694
Quote:
Originally Posted by StingRay View Post
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).
hooverphonique is online now  
AdSense AdSense  
Old 15 August 2012, 23:05   #42
mc6809e
Registered User
 
Join Date: Jan 2012
Location: USA
Posts: 281
Quote:
Originally Posted by Toni Wilen View Post
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
mc6809e is offline  
Old 15 August 2012, 23:40   #43
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 2,963
Quote:
Originally Posted by StingRay View Post
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.
Thorham is offline  
Old 16 August 2012, 08:04   #44
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,663
Quote:
Originally Posted by mc6809e View Post
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.
Toni Wilen is online now  
Old 16 August 2012, 11:12   #45
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,529
Quote:
Originally Posted by hooverphonique View Post
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.
StingRay is offline  
Old 16 August 2012, 11:19   #46
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 694
Quote:
Originally Posted by StingRay View Post
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..
hooverphonique is online now  
Old 16 August 2012, 11:29   #47
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,529
I think it's an A4000 only problem. I do not know why it happens though.
StingRay is offline  
Old 16 August 2012, 11:49   #48
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,663
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.
Toni Wilen is online now  
Old 16 August 2012, 12:25   #49
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 996
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:
Code:
        move.w  d0,INTREQ(a6)
        movem.l (sp)+,d0-d7/a0-a6
        nop
        rte
So the movem provides the required delay?
phx is offline  
Old 16 August 2012, 12:48   #50
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,017
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.
Leffmann is offline  
Old 16 August 2012, 13:32   #51
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 694
Quote:
Originally Posted by Leffmann View Post
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
hooverphonique is online now  
Old 16 August 2012, 21:40   #52
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 627
Quote:
Originally Posted by Wepl View Post
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.
Asman is offline  
Old 16 August 2012, 23:18   #53
mc6809e
Registered User
 
Join Date: Jan 2012
Location: USA
Posts: 281
Quote:
Originally Posted by Toni Wilen View Post
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.
mc6809e is offline  
Old 19 August 2012, 16:30   #54
TheDarkCoder
Registered User
 
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 207
Quote:
Originally Posted by StingRay View Post
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
TheDarkCoder is offline  
Old 19 August 2012, 17:44   #55
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 633
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.
Wepl is offline  
Old 22 August 2012, 19:57   #56
TheDarkCoder
Registered User
 
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 207
Quote:
Originally Posted by Wepl View Post
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)
TheDarkCoder is offline  
Old 21 July 2017, 06:04   #57
CptShlockler
Registered User

 
Join Date: Jul 2017
Location: Queensland / Australia
Posts: 1
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?
CptShlockler is offline  
Old 21 July 2017, 09:38   #58
meynaf
68k wisdom
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon (France)
Age: 44
Posts: 2,380
Just use graphics.library/WaitTOF() unless you have really really tight timing requirements (which is less often than it looks).
meynaf is offline  
Old 21 July 2017, 19:43   #59
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,437
Quote:
Originally Posted by CptShlockler View Post
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.

Last edited by Photon; 21 July 2017 at 19:51.
Photon is offline  
Old 22 July 2017, 00:10   #60
pants
Registered User

 
Join Date: Feb 2017
Location: fastmem
Posts: 36
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...

Last edited by pants; 22 July 2017 at 00:27. Reason: clarity: frame-accurate -> every-frame
pants 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 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

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 11:02.


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