Not done with Panther findings just yet...
Rob Nicholson, software development manager of Hand Made Software giving his views on it and the Jaguar :
Rob:"The display was built up from a display list of bit-maps (or sprites).
Each entry in the bit-map said "Display the bit-map at x,y". On each
scan line, the object processor scanned through the list and determined
which bit-maps were visible on the current line. It then filled a single
line video "buffer" which was then output to the video hardware on the
next scan line. It alternated between two scan line buffers.
The Lynx has a simple 160 x 102 pixel video buffer (4 bits / pixel) so
generates the display in a very different manner.
It could also scale and mirror the bit-maps (by reading right to left
and bottom to top) but it *couldn't* rotate. AFAIK, the bit-maps were in
varying bit-resolutions. I can't remember if the single line buffers
were 16 bit per pixel or 8 bit per pixel.
This display list type of system was pioneered in early arcade systems
and was used in the Atari VCS and 7600. It has the advantages that you
can have a mixture of a standard video buffer (except see below) and
"hardware" sprites. The bit-maps could be pretty much any size (aligned
to 16 bit boundary I think). The downside of the system was that if you
tried to display too much on one scan line, the system went crazy. The
screen started jumping all over the place. On the Panther, you soon hit
this limit - maybe 4 or 5 16 bit full-width sprites on each line. It was
certainly nowhere near 83,000 sprites on a real game.
The Panther had a pathetic amount of RAM. Maybe 128K. Certainly not
enough to create two bit-maps as big as the whole screen and implement
standard double buffering. I think there was 32K of static RAM for the
display list. This was a good idea as it sped up generation of the
display. The same system was used on the Jaguar but the object processor
was beefed up and made more flexible to handle other features such as
read-modify write (for shadows etc). Unfortunately, on the Jaguar the
display list was in normal DRAM which meant the whole system stopped
when the video processor wanted to access memory. It also meant that on
the Jaguar, the advantages of page mode RAM where accessing the next
byte/word along was often defeated as different devices (display,
blitter, 68k and GPU etc) kept reading from different pages.
The Jaguar was packed full over excellent ideas but the problems were
never weeded out. A shame really. As I said, a neat piece of hardware.
(except for the CD-ROM...)"
I found that online.
Thought it would compliment the personal views Jim Gregory gave me via my rather crude interview a while back