| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
bad lines how many cycles
how many cycles on a bad line
when i do for example a routine to open the sideborders i do:
delay 44 cycles + 4 sprites = 52 cycles
stx $d016 good line
sta $d016,x
stx $d016 bad line
sta $d016
at the bad line there are 8 cycles used by stx $d016 sta $d016, 1 cycle by the x index at the good line and 8 cycles for the 4 sprites. . this means 17 cycles are used
but when i make fli grafix witch use a bad line each line by making the 3 lower bits of $d012 and $d011 equal
i count 23 cycles..
lda tabel1,x 4
sta $d011 8
lda tabel2,x 12
sta $d018 16
bit $ea 19
nop 21
inx 23 cycles
etc
why are 17 cycles used in the example of the borderroutine and 23 cycles in the example of the fli grafix..
i am coding for several years now and i still dont get this
what do i miss here... (i hope no braincells ... hehe)
greetings from mcd
|
|
| |
Oswald
Registered: Apr 2002
Posts: 5028 |
63-40=23 without sprites. 40 extra cycles are needed for the VIC on bad lines to read the characer pointer data.
sprites do steal cycles aswell, thats why you get less where they're used. they steal 1-2 cycle as VIC runs effectively at 2Mhz when reading sprite data,thus it can read 3 bytes for one line of sprite in less than 2 1 mhz cycles. using consecutive sprites will steal less cycles, as the CPU needs some time to stop and give the bus over to the VIC. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11148 |
sprites steal 2 cycles, plus 1 for initial setup :) |
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
thanks for your reply but i still dont get where the missing 6 cycles in the example of the borderroutine are.
stx $d016
sta $d016 = 8 cycles
sta $d016,x = steals 1 cycle
4 sprites = 8 cycles
40 cycles for reading char data
= 57 cycles and not 63 cycles...
|
| |
Oswald
Registered: Apr 2002
Posts: 5028 |
4 sprites <> 8 cycles. if you can do a stable raster you can measure how many cycles they steal exactly with a cleverly positioned inc/dec d021. then put/remove 4 sprites on top if it and measure. |
| |
Oswald
Registered: Apr 2002
Posts: 5028 |
another topic we havent touched is the bus takeover mechanism of the VIC which can steal up to 3 cycles from the cpu.. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11148 |
that doesnt work accuratly, since the actual cpu cycles which are left also depend on the type of instruction(s) used in that line :) |
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
thanks man... things get clear now... very cool!! |
| |
Oswald
Registered: Apr 2002
Posts: 5028 |
delay 44 cycles + 4 sprites = 52 cycles + ~3 bus takeover for charptrs+ 1 bus takeover for sprites + 9 instruction = ~63
groepaz, when removing sideborders u always use the same opcodes
btw, the bus takeover mechanis is the same for sprites iirc, thus it can be up to 3 cycles aswell... lets wait for jackasser to lighten us up ;) |
| |
Testa
Account closed
Registered: Oct 2004
Posts: 197 |
why are there in the fli example no bus takeover cycles for char pointers needed... or has that something to do with sprites on that line.... i get it for 99% now...
very interesting matery.....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11148 |
Quote:groepaz, when removing sideborders u always use the same opcodes
he uses stx/sta in his example, you want to measure with dec/inc. very different. the "cycles" measured by inc/dec wont apply to a routine using sta/stx at all :) |
| |
Oswald
Registered: Apr 2002
Posts: 5028 |
Quote: why are there in the fli example no bus takeover cycles for char pointers needed... or has that something to do with sprites on that line.... i get it for 99% now...
very interesting matery.....
The division of accesses between 6510 and VIC is basically static: Each clock cycle (one period of the ø2 signal) consists of two phases. The VIC accesses in the first phase (ø2 low), the processor in the second phase (ø2 high). The AEC signal closely follows ø2. That way the 6510 and VIC can both use the memory alternatively without disturbing each other.
However, the VIC sometimes needs more cycles than made available to it by this scheme. This is the case when the VIC accesses the character pointers and the sprite data. In the first case it needs 40 additional cycles, in the second case it needs 2 cycles per sprite. BA will then go low 3 cycles before the VIC takes over the bus completely (3 cycles is the maximum number of successive write accesses of the 6510). After 3 cycles, AEC stays low during the second clock phase so that the VIC can output its addresses.
==> the first read cycle of the cpu after BA goes low will stop the cpu
I must admit that I dont completely understand this either :P |
| |
Oswald
Registered: Apr 2002
Posts: 5028 |
https://sh.scs-trc.net/vic/
read here the whole article |
| |
Copyfault
Registered: Dec 2001
Posts: 467 |
Quote: why are there in the fli example no bus takeover cycles for char pointers needed... or has that something to do with sprites on that line.... i get it for 99% now...
very interesting matery.....
Understanding the VIC_timing is not _that_ easy at first, but things will be the clearer the more often you look at them;))
In a nutshell: _any_ bus_takeover takes three cycles, no matter if there's a sprite or a bl to come...
the spritedata_read_cycles are at fixed pos in a rasline (for spr0 at cycle 58/59 in the line BEFORE, spr1 at cyc60/61, spr2 at 62/63, and for spr3-spr7 at cyc0/1 - 9/10 in the line where the sprites will appear). So basically every sprite eats two cycles, but before it takes these two over from the cpu, there are three 'takeover cycles'. These are special in the following way: if there is a write_cycle during such a takeover cycle, it will be executed, but as soon as there comes a read_cycle from the cpu, the bus is halted. Thus an INC-instruction (=4 read_cycles + 2 write_cycles) beginning at a 'good cycle' (e.g. at cyc51) effectivly only steals 4 cycles from the cpu.
ex1: (only) spr0 active on rasline1 -> there will be takeover_cycles on rasline0, cycle 55/56/57 and spritedata_read_cycles at cycle 58/59. Considering the INC-instruction from above the two write_cycles happen at cyc55/56 of line0 and will be executed, as these cycles are takeover_cycles!
ex2: spr0 and spr7 active on line1 -> takeover_cycles for spr0 as above, same with spritedata_read, and takeover_cycles for spr4 in line1 at cyc6/7/8, spritedata_read at cyc9/10.
This shows it really matters which sprites are used (use of consecutive sprites won't need more takeover_cycles as the bus is already reserved for teh vic).
Now some words to the comment above: FLI only works when creating a badline_condition at cycle14 (or later) of a rasterline. Compared to a 'normal' badline (where the badline_condition for that line is given before reaching this line) the takeover_cycles are shifted as they depend on the bl_cond (normal bl -> takeover_cycles at cyc12/13/14, FLI=three cycles delayed bl -> takeover cycles at cyc15/16/17).
Have a look at AAY64 for the timing schemes - they're really enlightening!
Putting all this together hopefully explains why the two examples from mcd are conformal;))
Sorry for having failed to stick to 'in a nutshell' ;))
CF |
| |
Barbarossa
Registered: May 2007
Posts: 31 |
What happens when the processor does an internal operation, at the time that the BA line goes low. The schematics say the processor still reads the bus. Is it blocked?
For example when an implied instruction is started at cycle 54 (let's say cli), is its second cycle (internal operation) still finished or is it halted? |
| |
Copyfault
Registered: Dec 2001
Posts: 467 |
Internal cycles are always read_cycles - in your example the second cycle of the CLI-command will halt the bus for the cpu and it will not be executed at cyc55, but on the next free cycle. Continuing ex1 from my last post, a CLI beginning at cyc54 of line0 will be executed as follows:
line0,cyc54 - first CLI cycle (a read cycle)
-----,cyc55 - bus halted for CPU (2nd CLI cycle is a read_cycle)
-----,cyc56 - 2nd takeover_cycle, bus alread halted
-----,cyc57 - 3rd takeover_cycle
-----,cyc58 - 1st spritedata_read_cycle for spr0
-----,cyc59 - 2nd spritedata_read_cycle for spr0
-----,cyc60 - second CLI cycle (a read cycle)
-----,cyc61 - next free cycle for the cpu
IIRC, write cycles only occur at the end of store_commands (usually the last cycle is a write_cycle here) and at the end of RMW-instruction (here the last 2 are write_cycles). Also, certain stack_operations will ofcourse have write_cycles (max. 3) - see AAY64 for dirty details. |
| |
Barbarossa
Registered: May 2007
Posts: 31 |
Thanks! |
| |
Codey
Registered: Oct 2005
Posts: 79 |
I always opened the side-borders by using $d020 as a visual guide and then swapping $d016 for $d020 when I was finished. I never understood cycle counts at the time. |
| |
JackAsser
Registered: Jun 2002
Posts: 1994 |
Quote: I always opened the side-borders by using $d020 as a visual guide and then swapping $d016 for $d020 when I was finished. I never understood cycle counts at the time.
Even when you do understand cycle count the method u mention is by far the most effective for me. ;D |
| |
Mace
Registered: May 2002
Posts: 1799 |
Ah! Huh? Oh! Hmm.... Errr... Aha...
Ok, time to finally write something with open side borders.
I never did that, although I kind of understand how it works.
And this whole cycling stuff (not the bicycles) helped! :) |
| |
Codey
Registered: Oct 2005
Posts: 79 |
Quote: I always opened the side-borders by using $d020 as a visual guide and then swapping $d016 for $d020 when I was finished. I never understood cycle counts at the time.
Oops, $d021 actually. |
