S•Y•N•C•H•R•O•N•I•C•I•T•Y
When we want a change of palette (CSS) at a certain byte on one line, we must count CPU cycles so that the opcode that modifies the palette hits
on the exact cycle that corresponds to the desired screen byte.
We need to know some figures before we put our hands on the calculator …
Here comes a series of data from the VDG MC6847 datasheet. Simon helped me finding and explaining it.
In page 7 of that technical document we can find this information as note 6 in figure7:
One full scanline lasts 227,5 cycles of the chroma clock that runs at 3,5795MHz.
As we know that the MC6809 CPU runs at 0,8948MHz (exactly one fourth of the chroma clock), we can tell that one screen scanline lasts 227,5/4 CPU cycles,
that gives roughly 57 cycles.
In figure 11 on page 9 of the same datasheet, we could read that the visible line lasts 128 chroma cycles or 32 CPU cycles.
This gives 25 cycles (bytes) for the ‘non visible’ part of the line which is composed of parts like:
Horizontal sync pulse (/HS), front porch, back porch, left border, right border, colour burst.
The duration of each one of these components can be seen on the table on page 5 of that document.
So it seems that from the HS detection until the beginning of the visible area there are 13 cycles, so the part on the right of the visible area
should sum up to 12 cycles that together with the 32 of the line result in the known 57 cycles.
Now we see that in order to change palette at byte ‘one’ we should hit cycle 13+1
For byte 2 it will be 13+2 and so on until byte 32 that would be 13+32= cycle 45
Let’s imagine we want 8 vertical bars equal width, so 4 bytes each, then we should hit these
cycle numbers: 14, 18, 22, 26, 30, 34, 38 and 42 corresponding to bytes 1,5,9,13,17,21,25,29 on the line
Let’s write a small assembly routine that does exactly that:
Assuming we have loaded previously register D with values $e8e0 for CSS1 and CSS0 and DP=$FF
Code: Select all
hloop nop ; (02)(02)
exg a,a ; (08)(10)
sta <$22 ; (04)(14) CSS=1
stb <$22 ; (04)(18) CSS=0
sta <$22 ; (04)(22) CSS=1
stb <$22 ; (04)(26) CSS=0
sta <$22 ; (04)(30) CSS=1
stb <$22 ; (04)(34) CSS=0
sta <$22 ; (04)(38) CSS=1
stb <$22 ; (04)(42) CSS=0
tfr a,a ; (06)(48)
tfr a,a ; (06)(54)
bra hloop ; (03)(57)
The first number in parenthesis is the number of cycles used by that opcode, the second is the accumulated cycle count along the routine.
You see that every ‘st’ opcode to $ff22 is exactly on the cycle count pre-calculated.
This would show that image:
![09-Example_8_Bars-small.jpg](./download/file.php?id=2317)
- 09-Example_8_Bars-small.jpg (14.25 KiB) Viewed 8843 times
Besides the exact cycle count to hit the correct byte to have the right switching, you can see that we have added ‘dummy’ cycles to sum a total of 57 cycles so that without any synchronization of interrupts the program will be processing all of the lines … even the non visible, of course, if this doesn’t matter as is the case.
The cycle counts here are ONLY for the Dragons. If you wanted to do the same in a CoCo2 PAL, then you would have to reduce that cycle count by 4, so we should hit instead these other cycle numbers: 10, 14, 18, 22, 26, 30, 34 and 38.
This implies that we’d have to adjust the time-waster opcodes before the first change and after the last one.
EXG a,a should be converted into two NOPs (2+2 cycles instead of 8) and the two TFR a,a converted into two EXG a,a (8+8 instead of 6+6) because the loop must sum a total of 57 cycles in any case.