wayneck@tekig5.TEK.COM (Wayne Knapp) (03/09/88)
Lets do a software upgrade to the ST's graphics. I'm willing to work on a
program that will allow more than 16 colors per scan line and release it to
the public domain so that it can be used by anyone. Some time ago I wrote a
program that loaded the palette registers every scan line based on the line
return interrupt. (Horizontal blanking interrupt) It had some problems due
to sloppy timing, but it did get the job done. I had hoped that it would
leave plenty of free time for other processing, but actually due to saving and
restoring the registers it only left a few microseconds per scan line over.
Later I bought ColorBurst (some of you may remember), I was very disapointed.
Then I bought Spectrum and I was very impressed. So seeing that spectrum had
licked the timing problem I got to thinking again. Wouldn't it be great if I
could use Spectrum pictures in my own code! So I need two things, first the
file format of Spectrum pictures and second some code to allow more than 16
colors a scan line. Maybe someone out in netland can give us the file format.
By the way I highly recommend Spectrum, and in no way would hope to reduce
the value of that product. In fact if other programs could use Spectrum
pictures I would hope that it would enhance the sales of Spectrum. If any of
the Spectrum programmers are out there I would be interested in their input.
Anyway lets get down to business. After seeing Spectrum I knew it could be
done so I thought about it some more. Then I wrote a program that ran a very
tight loop and just look at the value of the screen pointer and saved the values
in an array. Sort of an built in logic analyize. I going to do a better one
in assembly, still the data I got back was interesting. There are 60 frames
a second and 200 scan lines a frame. There is 2 to 3 milliseconds dead time
between frames and each scan line in about 85 microseconds long. On the scan
line 60 microseconds is spent during the display of the graphics information
and about 25 microseconds is horizontal retrace. The ST already has some code
executing during vertical retrace, but about 1.8 milliseconds if free.
Armed with that data I have a plan, and this is where I ask for help, maybe
some of you will have better ideas. Remember I plan to release this code to
the public domain, which means anyone can use it in any program, even for
programs that they plan to sell.
Here is the plan. Since using the horizontal retrace interrupt gained me so
little I decide to just use the whole screen time. (I sure this is how spectrum
must work). The program would consist of the users program running in the
vertical retrace period (about 10% of the time) and the display code running the
rest of the time. It may be possible to strip out the current vertical blank
code and get more time. Of course you may lose some things like the clock, but
so what. During the screen refresh time all interrupts would be turned off and
the code would be written so that the number of cycles through the color
changer code would equal the number of cycles per scan line. Something like
the following:
User Program
Wait for vertical retrace free time
Set timer for 1.8 milliseconds (could be different than 1.8)
User code
Timer Program
Put ST is supervisor mode
Turn off all interrupts (ori.w #0700,SR)
watch the screen memory pointer until it starts counting
use the first scan line to sync code
for 199 lines
reload color registers as much as possible
Turn on interrupts
Wait for vertical retrace free time
Set time for 1.8 milliseconds
return to user code
There are several ways to do the color register reloading. The one I favor is
to wait until the first horizontal retrace and then blast in new vales as fast
as possible. Maybe use move multiple during retrace and move (a1)+,(a2)+
during the actual screen refresh to get even timing some one would know where
on the line which color registers are valid. This would be simple and means
that the file formate would be color register values for 320X199 picture and
the pixels values for a 320X199 picture. Another way would be to use move
quicks and actually have the program write a the color register changer
routine. This is a couple of cycles faster per color change, but the code
is much longer, plus the setup time would be longer.
So here are the ideas so far:
movq.l D0,#color data for 2 registers (18 cycles)
move.l D0,(A0)+ a0 points to color registers
etc.
Or just
move.l (A1)+,(A0)+ (20 cycles)
etc.
Also during horizontal retrace to get a full change over
move.m (A1)+,register set (104 cycles)
move.m register set (A0)+
I think there are about 680 cycles to work with, unless my spy program has
a bug. Anyway it will be easy to find out.
Anyway any more ideas?
Thanks,
Wayne Knapp