15 August 2012, 22:02 | #41 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,643
|
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).
|
15 August 2012, 23:05 | #42 | |
Registered User
Join Date: Jan 2012
Location: USA
Posts: 373
|
Quote:
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 |
|
15 August 2012, 23:40 | #43 |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,862
|
|
16 August 2012, 08:04 | #44 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,575
|
Quote:
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. |
|
16 August 2012, 11:12 | #45 | |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,865
|
Quote:
|
|
16 August 2012, 11:19 | #46 | |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,643
|
Quote:
cheers.. |
|
16 August 2012, 11:29 | #47 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,865
|
I think it's an A4000 only problem. I do not know why it happens though.
|
16 August 2012, 11:49 | #48 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,575
|
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. |
16 August 2012, 12:25 | #49 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,553
|
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 |
16 August 2012, 12:48 | #50 |
Join Date: Jul 2008
Location: Sweden
Posts: 2,269
|
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. |
16 August 2012, 13:32 | #51 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,643
|
|
16 August 2012, 21:40 | #52 |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
|
16 August 2012, 23:18 | #53 | |
Registered User
Join Date: Jan 2012
Location: USA
Posts: 373
|
Quote:
Turns out the Amiga designers were even more clever than I had given them credit for. |
|
19 August 2012, 16:30 | #54 | |
Registered User
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 213
|
Quote:
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 |
|
19 August 2012, 17:44 | #55 |
Moderator
Join Date: Nov 2001
Location: Germany
Posts: 876
|
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. |
22 August 2012, 19:57 | #56 | |
Registered User
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 213
|
Quote:
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) |
|
21 July 2017, 06:04 | #57 |
Posts: n/a
|
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? |
21 July 2017, 09:38 | #58 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,365
|
Just use graphics.library/WaitTOF() unless you have really really tight timing requirements (which is less often than it looks).
|
21 July 2017, 19:43 | #59 | |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,696
|
Quote:
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. |
|
22 July 2017, 00:10 | #60 |
Registered User
Join Date: Feb 2017
Location: fastmem
Posts: 53
|
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 |
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 |
|
|