| |
Cybernator
Registered: Jun 2002
Posts: 154 |
VIC interrupts
Can anyone tell me: In which cycle the VIC is, when a raster interrupt occurs? (on normal line, badline, if there're sprites...)
Any help is appreciated. |
|
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
Get the VIC Article. www.fairlight.to has it in the docs section. Funet also has it. This will answer almost all VIC II questions you have got. I'd be guessing first cycle. you then have issues of what the CPU is doing then doing the IRQ cycled. The IRQ operations are documented by some text by Marko, also found on funet. I think it's call 64doc or something. |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
Stryyker: I've already done all the things you said, but I couldn't find the answer. Something crossed my mind: Maybe the processor needs 7 cycles to store all the neccessary stuff on stack and load the PC with the IRQ vector.
I guess I have to experiment on my own. |
| |
yago
Registered: May 2002
Posts: 333 |
Quote: Can anyone tell me: In which cycle the VIC is, when a raster interrupt occurs? (on normal line, badline, if there're sprites...)
Any help is appreciated.
Well, switch the screen off,
and within the irq,change the border color twice.
Now you can see, where the raster interrupt occurs.
Or did I misunderztood ya?
For the details with sprites etc, the VIC-Article has also
some ASCII-Diagrams.
Zed Yago
--
If everything is worth money
money is worth nothing |
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
If you did read the 2 texts you would of found it is the first cycle of a line (VIC Article). The IRQ sequence takes 7 cycles (64doc), pushing SR, PC (16 bits), getting IRQ vector etc. I'm unsure how you counted by the INC or STx commands are 6 cycles for non indexed absolute. |
| |
CyberBrain
Administrator
Posts: 392 |
Just a little add-on..
As far as i remember the cpu also 'waits' for the instruction currently being run to finish, before it starts the IRQ sequence (it can't break in the middle of an instruction), so you can't be sure your code will start excatly on the 8th cycle of the rasterline.
(the slowest opcode on the C64 is BRK which takes 7 cycles, so if you're unlucky (or whatever you wanna call it) i think it could start on the 8+(7-1)=14th cycle, and if you're lucky it will start on the 8th cycle (well... the extream case - why would you use BRK for anything?))
But all this is what accurate IRQ-interrupts are made for...
(just don't remember how they work)
NOTE!! This is just what i remember, but i think it's correct - if not, somebody gimme a kick!! (pretty interesting topic - allmost forgot all these thinx) |
| |
QuasaR
Registered: Dec 2001
Posts: 145 |
Hi there!
In a C=Hacking was once written an article about a stable raster interrupt. The clue was you had to do a RAM-access in the mainloop (like INC $somewhere) and put the last line of the first (or any sprite, I guess..) sprite to the rasterline you wanna have the IRQ and voila you get a really stable IRQ. The author also wrote why this "bug" occurs and I think it explains the cyles VIC is using then, too. |
| |
Puterman
Account closed
Registered: Jan 2002
Posts: 188 |
Getting a stable interrupt by using a sprite + inc only works if you're not doing anything outside the interrupt handler. Otherwise you'll have to use the double interrupt method, which is documented in several places on the net. |
| |
CyberBrain
Administrator
Posts: 392 |
As far as i remember there was a third way too... I think i called it "$D011 Crash" in the past :) - don't know if that was the official name :)
Again taken compleately from my memory, but it was something like this (if it's wrong please correct me):
1] Make the IRQ start on a non-badline (but on the screen - not in the border)
2] In the middle of this line change $D011 so that the line becomes a badline.
3] Wee.. The VIC will take over for some cycles like it allways does on a badline, and the cpu will regain control at excatly the same cycle every time.
4] (remember to change $D011 back at some point, so that the rasterline on which the IRQ starts won't be a bad line next time - coz' then it won't work as i wrote under 1])
This method ofcause makes the screen look a little fucked up around the rasterline on which you made the $D011-crash, but that can be hidden. :)
The best method is ofcause putermans! (but this one is pretty easy to code) |
| |
Cybernator
Registered: Jun 2002
Posts: 154 |
CyberBrain: If you generate a badline somewhere in the middle, this would produce DMA Delay, right? If I'm correct, the misalignment continues for the rest of the screen, not just one rasterline. Though, it's nice a trick.
I've started this topic because of some problems I have with stable rasters (the double interrupt technique). I get the main idea. Now, when it comes to compare the rasterline (cmp $d012) this should happen in cycle 60, right? Because "cmp $d012" takes 4 cycles, and the actual read access to $d012 will happen in the last (the 4th) cycle of the op-code. Because the raster will be off my most of 1 cycle, the comparement will either happen in cycle 63 of the current rasterline, or in the next line. When I've used sprites (8 of them on a line) this didn't work. Of course, because VIC needs additional cycles to fetch the sprite pointers. According to "Pal timing" by Marko, the last free cycle (in this case) is 56. So cmp should go into cycle 53, right? In CCS, I've noticed what I was expecting. CMP would go in two different rasterlines, but the rasters were unstable again. When I've moved the cmp back for 3-4 cycles, it worked. Yes, my routine works, but I need to know what the heck is going on.
Puterman: You said I can find docs about this tech. at more places. I only know about the C=Hacking mag. Will you drop some more links? (in case it's not the same doc by Marko).
And finaly the sprite + inc method: I think I understand the principle. But I think that Pasi has made some mistakes. He said the INC does not need the bus during cycle 5 of the op-code. According to "64doc" the processor makes a write access. Since Pasi used INC and DEC, this means that we have two write cycles (from the INC) and then three read cycles (from the DEC). This opcodes should execute somewhere when the VIC needs to fetch the sprite pointer. During the 'Bus Request Pending' it can only execute the write cycles and stops on first read cycle (the DEC). So DEC will execute after the VIC has finished fetching the sprite pointer. (This is the way I understand the trick. Plz correct me if I'm wrong).
|
| |
Puterman
Account closed
Registered: Jan 2002
Posts: 188 |
Cybernator: I think there's some example code at http://www.ffd2.com/fridge/. |
| |
CyberBrain
Administrator
Posts: 392 |
@cybernator: damn, i must have messed those 2 up then. It's been too long.. Gotta check my sources. |
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
I never thought of using $D011 method. The DMA delay issue doesn't always happen as easy as it seems. I had to do it in a FLD gap (idle gfx state). Another method is to use the CIA timer registers. I haven't figured out how they get it started. Lightpen X register can be used. It got messed up if space was pressed. Maybe some DDR of $DD02/$DD03 might fix that. I use the simpler double interrupt with first padded with NOPs.
With 8 sprites on screen check the timing charts - you need to simply shift the read forward some bytes. C= Hacking has it. I think 64doc or some other Marko text had it. I did plan to do this in a disk magazine but the coder who was to write about the methods I don't know has been very busy. I know in the past some writes to memory have made getting an interrupt stable a nightmare. Some effort and it'll all work out fine. Don't try to be too complex. If Singles Collection volume 2 was released then you would see a very simple double interrupt with $D012 comparing for the scroller stretcher. |
