wayneck@tekig5.TEK.COM (Wayne Knapp) (03/10/88)
Yesterday I had a couple of misstakes in my posting of how to do a software
graphics upgrade on the ST.
Last night I did some more work on a spy program I have to determine the
timing of things in the ST. Basically I rewrote the part that was doing the
spying into assembly. Then I looked at the screen pointer. Here is what I
found. There are 80 increments by 2 spaced 4 cycles apart, then there is a
horizontal retrace time of 188 cycles. This means that each scan line takes
508 cycles total or 64.5 microseconds. I believe these figures to be pretty
close to true. Using the computer to spy on it's self worked out really well.
Much easier than trying to use a logic anailizer or an oscilloscope.
The other misstate was that I didn't realize that the movq only give you 8 bits
of data. So now it would that I limited my choices on how to update the color
registers. I'm still thinking some combination of movm and move using the
address registers will be best. Also I still believe that the only way to
sync up the system is have limited colors on the first scan line. Since the
update is four cycles per update and nop's are 4 cycles long it may be possible
to use a code sequence like the following to get started. (numbers in comments
are the cycle count.
interrupts turned off and all registers except for A7 saved, giving
15 registers to work with
waitv tst.b $FF8209 # 4 the video counter always starts at zero
beq waitv # 12 wait until not zero
move.b $FF8209,A0 # 28 get the current count
jmp PC@(0,A0) # 42 do a relative jump based on the video addr
nop # video address of 2
nop # video address of 4
nop # video address of 6
nop # video address of 8
nop # video address of 10
nop # video address of 12
nop # video address of 14
nop # video address of 16
nop # video address of 18
nop # video address of 20
nop # video address of 22
nop # video address of 24
nop # video address of 26
nop # video address of 28
nop # video address of 30 260 cycle to hor. retrace
- at this point the system should be with in a window of +/- 2 cycles.
which means that as long as we keep a window of 4 pixcel before a color
change we should be safe. Actually since a move (a0)+,(a1)+ takes 20 cycles
I think it would be best to wait 24 cycles before using a new color. If one
could used a movm to load some registers a move d0,(a1)+ take 14 cycles.
Anyway I'm open to ideas. Some things I toying around with is not changing
all the color registers during the scan line. Maybe all at first then only
some later. Also all the moves will be long so that all the registers will
change is pairs. Anyway I want this to be good and useful so input is welcome.
If you didn't follow the above, in simple terms, changing the color
registers in 20 cycles means two new colors every 10 pixels in 320X200 16 color
mode.
Thanks,
Wayne Knapp