| |
oziphantom
Registered: Oct 2014
Posts: 490 |
Super Stable(tm) NMIs
Before I go tumbling down a rabbit hole, though I would check with people in the know if this is sane..
I have a need for stable raster ( doesn't need to be to the clock stable, but stable ish <4 ) with potential sprites and maybe some samples playing...
To which I was thinking if doing my IRQ stuff in NMI, where I can use TIMER A to clock the point I want, then use the Inverse X cycle counter in Timer B to stabilise it. A Pal Frame is 19,656 cycles right, which easily fits into 65,536.
Since I can set the cycle to start me in the char area ( on a good line) the fact there are sprites is neither here nor there right? And I can support NTSC by having a different Next NMI timer value table?
The I get the Sample routine ( which are traditionally on NMI ) to use the other CIA, so it fires on IRQs.
So I can had stable rasters that change a register during the "write cycle" before the VIC enables Sprite DMA, and optionally have and not have sprites around, and play samples, as it starting to get a bit too good to be true.. |
|
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Yes, you can use the timers although I didn't fully understand the timer B part you describe. Using the inverted LSB of the triggering timer is usually sufficient. Both NMI or IRQs work.
The interrupt routine needs to be really fast though. When you enable sprites the window the routine must fit in shrinks a lot. The more stable you need the interrupt, the larger the execution time of the correcting code is going to be. |
| |
Mixer
Registered: Apr 2008
Posts: 452 |
You probably mean that the NMI Timer B is the timer that sets the interrupt flag and Timer A just runs from 8-0 for the jitter stabilization, ok that works. I do not get the super stable part unless you imply that there is a way to make the jitter smaller? |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
The NMI will still have a jitter because of the CPU, so I can use http://codebase64.org/doku.php?id=base:using_a_timer_as_an_inve.. to lock it again. Which thinking about it more, I will need as I'm then going to set the next NMI in clocks, so if there is a cycle of jitter then the whole thing will slide around...
The critical parts of the NMI are open border, closer border, toggle multi colour to hires, so basically store a value into one VIC location. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
perhaps look at the "Ninja method" as well, since you waste a lot less cycles with that |
| |
algorithm
Registered: May 2002
Posts: 705 |
Indeed, also utilised in sounddemons cycle exact sample replay. Based on the jitter, it directly jumps to for example (can be changed) $0100,$0200,$0300,$0400.. and relevant delays in each section to ensure that the nmi routine starts from exactly the same position |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
For convenience:
https://codebase64.org/doku.php?id=base:nmis_and_distributed_ji.. |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
The Ninja method is amazing, but in a Video game where I'm going to have at least 3 splits, and maybe dynamically add in/remove some splits with a bitmap and sprites. So that takes out 64 pages, ZP, Stack, 66 pages. Data storage of extra sprites and level data, game code and well having bits for lets say 6 splits, at 8 pages each = 48 pages, its starting to get to be a real pain to manage. So at this stage I would rather pay the clocks, but thanks for the info anyway. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
It only eats 7 pages (or 8 if you treat diffierent CIA versions as jitter). Which pages depends on the relation between the IRQ-source and the timer |
| |
HCL
Registered: Feb 2003
Posts: 728 |
If you want several different IRQ:s (or NMI:s) with stable timing, you may of course use the lo-byte of the jmp to address different locations on each page. ..but i think that is included in the so called "Ninja-method".
Besides i will refuse to start a discussion on who was really the first to invent the so called "Ninja-method" :). |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
so, HCL method ? :) |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Don't discuss it! |
| |
HCL
Registered: Feb 2003
Posts: 728 |
Nono.. I was definitely *not* the first. Perhaps the last. |
| |
lft
Registered: Jul 2007
Posts: 369 |
Quoting HCLIf you want several different IRQ:s (or NMI:s) with stable timing, you may of course use the lo-byte of the jmp to address different locations on each page. ..but i think that is included in the so called "Ninja-method".
I'm not so sure. Those locations would have to be one byte apart, and later calls would go to earlier addresses. So you would have to construct some kind of inverted clockslide. Maybe it is possible somehow, but it seems really difficult. Game on? |
| |
Mixer
Registered: Apr 2008
Posts: 452 |
Like HCL said.
From the top of my head, you can do
dc02 4c
dc03 lowbyte, Any value, the stable routine lo
dc04 hibyte , == timer from 8 to 0, the stable routine hi
dc05 0
dc06 your event timer lo
dc07 your event timer hi
dc0d 02 // timer B causes interrupt, A does not.
dc0e 01 // timer A just runs.
dc0f 01 // timer B just runs. must be started in sync with timer A
fffe 02 // IRQ vector to $dc02
ffff dc //
The stable routine then has the nops or other delays depending on how many cycles to compensate on each page/timer value.
But getting back to the Oziphantom original problem, I think there is no need for such a complex system, if one just needs one or two timed events per frame. |
| |
lft
Registered: Jul 2007
Posts: 369 |
Oh, right. I misunderstood HCL. Yes, the lo-byte can be anything as long as it's fixed. I was thinking of having a dynamic lo-byte and a fixed hi-byte. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
but can you change the lowbyte using sprite collisions? |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Quoting HCLNono.. I was definitely *not* the first. Perhaps the last.
I still haven't used that method. :-) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Is this the thing that jumps to $3c00, $3d00 etc? Then it's the Horizon-method :) |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quote: It only eats 7 pages (or 8 if you treat diffierent CIA versions as jitter). Which pages depends on the relation between the IRQ-source and the timer
Hmm, if I understood this "use timer lo-byte as hi-byte of the irq-jump-vector"-method (or should we call it Ninja-rizon-method;)?) correctly it needs 8 pages even when sticking to a fixed CIA version (and without the use of unintended opcodes).
As discussed before (e.g. in Stable Raster via Timer) jitter causes 8 different timer values resulting in eight different jump adresses. Or do I mix things up here??? |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Hehe.. I was also reminded about that discussion when I read that and thought "hey, uh... what was the conclusion of that old thread again?". |
