| |
Barbarossa
Registered: May 2007
Posts: 31 |
Sprite synchronisation
I am trying to get a stable raster with the help of sprite timing. I've read the articles in C=hacking about it, but it is not explained in full detail there. That is, when I look at the examples Missing Cycles and TechTech, I don't quite get it.
I've tried the timing of those examples in an emulator. I have found out that when the INC ends within the cycles that BA goes low, the intruction ends exactly after the sprite fetch. This would mean that the interrupt cannot be more off than 3 cycles and we all know that we have to deal with 2-9 cycles (7 cycles variance). So how can this trick be stable?
If someone could explain this to me (an article about this in Codebase would be really neat) I would be very grateful.
John
|
|
... 22 posts hidden. Click here to view all posts....
|
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Btw... What IS the *fastest* (and preferablly reasonably generally applicable - with any kind of "main loop" running etc) way of achieving a stable interrupt?
Is it to use a Timer and JMP/branch depending on the value of the timer? Are there other methods which are faster? No? |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Oswald: I don't think so, because that one sprite alone already eats at least 3*21 cycles - if you can use it for your actual raster routine, it may pay off though.. maybe :) But as groepaz already said, with a mainloop like jmp * irq's are pretty much nonsense.
Radiantx: Only if it's a raster irq. Different if it's a timer irq firing somewhere in the middle of a rasterline.
Frantic: According to my experience, the fastest way is a raster irq, followed by an indirect jump through one of the timer registers, with 8 differently timed routines to branch to. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
well, what if someone would write a code which makes sure to only use max 4 cycle long instructions :) just a funny idea ;) |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Krill: Yeah, as I hinted at. :-) But it's a dead end really. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Wonder what's the fastest (least cycle-consuming) way of getting a stable raster, if you don't have anything to do outside the IRQ (i.e. the jmp * scenario) and there's no use for any sprites that might be used for stabilizing it.
Also, I don't get all the talk about IRQ's being useless if you're jmping to * outside. Wouldn't you have to do cmp $d012 then, which leaves you in a more jittering condition than a raster IRQ with a jmp *, which if I recall correctly will jitter 0-2 cycles.
|
| |
Ninja
Registered: Jan 2002
Posts: 411 |
@Krill: Why indirect? Direct is faster, no?
@Oswald: Instead of limiting to 4 cycles, better generate parts, which have constant timing per frame :) (wasn't S:T Lars Meeting III - Invite something like it, Jackie?) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: @Krill: Why indirect? Direct is faster, no?
@Oswald: Instead of limiting to 4 cycles, better generate parts, which have constant timing per frame :) (wasn't S:T Lars Meeting III - Invite something like it, Jackie?)
Direct is ofcourse faster but require code in IO-space, ofcourse totally ok.
S:T Lars Meeting III - Invite did not use constant timing per frame... (how else could I have music?!? =D)
However, the 4x4 speed code had constant timing per 4x4-pixel and thus was multiplexable with the raster code to remove the sideborder.
I still used a timer to sync the cpu to the raster beam each frame. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:Also, I don't get all the talk about IRQ's being useless if you're jmping to * outside. Wouldn't you have to do cmp $d012 then, which leaves you in a more jittering condition than a raster IRQ with a jmp *, which if I recall correctly will jitter 0-2 cycles.
yes, but a) when irq is switched off everything becomes a lot more predictable b) the cycles which would be spent in the irq overhead can be used for another compare that removes the jitter :) |
| |
Danzig
Registered: Jun 2002
Posts: 440 |
Quote: I see a corrupt stack... Please enlighten me. :D
just take a look at the intro from one year crest... i was expecting corrupt stack aswell *G* i tried the trick myself years ago and it worked...
EDIT: iirc not very stable solution at all! |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Jackie: That qualifies as "something like it" in my terms :) If you have to get a stable raster just once per frame, then you can spare a dozen cycles on that. |
| Previous - 1 | 2 | 3 | 4 - Next |
