[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
Title: | AMIGA NOTES |
Notice: | Join us in the *NEW* conference - HYDRA::AMIGA_V2 |
Moderator: | HYDRA::MOORE |
|
Created: | Sat Apr 26 1986 |
Last Modified: | Wed Feb 05 1992 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 5378 |
Total number of notes: | 38326 |
1290.0. "ST Spectrum 512 picture format" by BAGELS::BRANNON (Dave Brannon) Fri Apr 01 1988 21:45
This will probably be only of interest to those curious about picture
file formats on that "other" computer. Spectrum 512 is a paint
program that will do 512 colors on the screen at the same time (the
ST color pallette is only 512 colors, not 4096).
It appears they are doing this with the ST version of custom copper
lists (critical timing of raster interrupts). That eats up a bit
of the 68000, but then that kind of thing doesn't have the limitations
of HAM mode. Maybe it's time to start doing that kind of thing
for the Amiga (at least picture viewers).
modes needed:
1. 256 colors - Compuserve GIF format, IBM VGA
2. 512 colors - ST Spectrum 512
3. 4096 colors - Amiga in all resolutions? (not just HAM)
Newsgroups: comp.sys.atari.st
Path: decwrl!labrea!agate!ucbvax!WATDCS.BITNET!DMIHOCKA
Subject: (none)
Posted: 29 Mar 88 04:44:33 GMT
Organization: The Internet
In the last message that I replied to Wayne Knapp regarding 512 color displays,
I mentioned a bit about how Spectrum does it and about how I did it in a
slideshow program I wrote. I received a few messages from people that wanted:
- Spectrum file format info
- see the code
So here is part of my code, written in Megamax v1.1, that contains the VBI
routine, and the file reader. Note that this code won't compile as is, since
it is only a small fragment, but it shows most of the most important piece: the
display routine.
A few points:
- when dispaying a Spectrum picture, I found it necessary to turn off
the mouse (with Bconout(4,0x12)) otherwise the mouse interrupts interfere
with the display. Remember, this code is super time critical and must
always execute in the exact same number of clock cycles
- When installing the VBI routine, it is not necessary to turn off the other
VBI's. i.e. install it properly into the VBI table, don't just brute force
the vector in. This assumes that all other VBI's are pretty short.
- the code here is not identical to Spectrum's code. The main difference is
that since Spectrum pictures always have a black background color, there is
no need to update color register 0. I use this time then, to update the
screen resolution register so that I can get both low rez and medium rez
being displayed in the same 512 color picture.
- to do true 640x200 x 512 color displays, and get 32 colors per scan line,
the routine can be optimised to only update 4 register, not 16 as this
routine does. This routine only gives you 8 colors in medium rez.
- note that there are no clock cycles left over in the scan line.
The last two routines decode a Spectrum file (.SPC) format and convert it into
something the VBI can use. This just happens to be identical to the .SPU format.
SPU is easy to describe, SPC isn't. Since the file on Compuserve describing
it is probably (c), I won't upload it, but hopefully my code is clear enough. ha
I'll have a try at explaining it:
SPU:
- first 32000 bytes is the video image.
- since the first scan line is lost for syncing, only 199 scan lines are
displayed in a Spectrum picture. Thus, there are 199 blocks of 48 words
= 19104 bytes of color information. Each block contains 3 color palettes
in a row.
- thus, the total length of an SPU file is 32000+19104 = 51104 bytes.
- note that for my version, I use the info for color register 0 (normally
000 = black) to store resolution info. A normal Spectrum picture is
in lo res anyway, so it works out.
SPC:
- the video image is run length encoded bit plane by bit plane, similar to
how Degas Elite does it. see the code below.
- the color palettes are encoded in delta fashion. Each block is now variable
in size, with the first word containing a bit mask of which of the 16
color registers are actually changed, followed by up to 16 words containg
the color values. again, see the code below for more info.
Note: some people have said that using MOVEM instead of MOVE.L is faster. It is.
You could even get more than 48 colors per scan line that way. However,
the moment you do this, your display routine then becomes incompatible with
Spectrum files. This may be no big deal, but why not stick to one standard
instead of seeing a dozen new 512 color formats emerge, sort of what happene
with regular lo rez pictures (.NEO, .TNY, .PI1, .PC1, etc).
/****************************************************************
** VBI related routines **
****************************************************************/
extern foo(), VBI(), RegA4(), RegA7();
#define RegQ_Table A0
#define RegQ1 A1
#define RegQ2 A2
#define RegQ3 A3
#define RegQ_Rez A5
foo()
{
register int qCol0, qCol1;
register int cloop; /* count of scan lines */
asm
{
RegA4: dc.l 0
RegA7: dc.l 0
VBI:
move.l RegA4(PC),A4 ; now we can access C globals
move.w SR,-(A7)
ori.w #0x0700,SR ; turn off interrupts for sure
move.w #199,cloop
move.l #0x8260,RegQ_Rez ; pointer to resolution register
move.l #0x8240,qCol0 ; pointer to color register 0
move.l #0x8242,qCol1 ; pointer to color register 1
clr.w 0x8240 ; make screen background black
move.l vqpalSPX(A4),RegQ_Table
move.w 32(RegQ_Table),(RegQ_Rez)
clr.w D0
tst.b 0x8209 ; wait for end of frame (should happen)
bne exitVBI
LSsync2:
tst.b 0x8209 ; wait for start of next frame (1st scan line)
beq.s LSsync2
move.b 0x8209,D0 ; read position of electron beam
jmp 0(PC,D0.w) ; and sync with it
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop ; now at end of scan line #0
move.l qCol0,RegQ1 ; stuff first 16 colors
move.l (RegQ_Table)+,(RegQ1)+
move.l (RegQ_Table)+,(RegQ1)+
move.l (RegQ_Table)+,(RegQ1)+
move.l (RegQ_Table)+,(RegQ1)+
move.l (RegQ_Table)+,(RegQ1)+
move.l (RegQ_Table)+,(RegQ1)+
move.l (RegQ_Table)+,(RegQ1)+
move.l (RegQ_Table)+,(RegQ1)+
LColor: ; main loop
move.l qCol1,RegQ1 ; 3 pointers to the color registers
move.l qCol0,RegQ2
move.l qCol0,RegQ3
move.w (RegQ_Table)+,(RegQ_Rez) ; stuff resolution
move.w (RegQ_Table)+,(RegQ1)+ ; stuff color #1
move.l (RegQ_Table)+,(RegQ1)+
move.l (RegQ_Table)+,(RegQ1)+
move.l (RegQ_Table)+,(RegQ1)+
move.l (RegQ_Table)+,(RegQ1)+
move.l (RegQ_Table)+,(RegQ1)+
move.l (RegQ_Table)+,(RegQ1)+
move.l (RegQ_Table)+,(RegQ1)+
move.l (RegQ_Table)+,(RegQ2)+ ; stuff next 16 colors
move.l (RegQ_Table)+,(RegQ2)+
move.l (RegQ_Table)+,(RegQ2)+
move.l (RegQ_Table)+,(RegQ2)+
move.l (RegQ_Table)+,(RegQ2)+
move.l (RegQ_Table)+,(RegQ2)+
move.l (RegQ_Table)+,(RegQ2)+
move.l (RegQ_Table)+,(RegQ2)+
move.l (RegQ_Table)+,(RegQ3)+ ; stuff last 16 colors of scan line
move.l (RegQ_Table)+,(RegQ3)+
move.l (RegQ_Table)+,(RegQ3)+
move.l (RegQ_Table)+,(RegQ3)+
move.l (RegQ_Table)+,(RegQ3)+
move.l (RegQ_Table)+,(RegQ3)+
move.l (RegQ_Table)+,(RegQ3)+
move.l (RegQ_Table)+,(RegQ3)+
dbf cloop,LColor
exitVBI:
move.w (A7)+,SR ; enable interrupts
rts
}
}
/* qbRLE is the pointer to the run length encoded data */
/* cb is the size, (from SPC file header) */
/* qbTo is a buffer to decompress it in */
/* vqscrSPX is a pointer to video memory, used as scratch space since the
the screen is blacked out during this process anyway */
RLDecode(qbRLE, cb, qbTo)
register char *qbRLE, *qbTo;
register int cb;
{
register int i, n, b;
char *qbTo0 = qbTo;
int *qw;
while (cb--)
{
if (cb<1)
{
break;
}
n = (int)*qbRLE++;
if (n>=0)
{
for (i=-1; i<n; i++) /* n+1 loops */
{
*qbTo++ = *qbRLE++;
}
cb -= n+1;
}
else
{
n = -n + 2;
b = *qbRLE++;
for (i=0; i<n; i++)
*qbTo++ = b;
cb--;
}
}
/* unscramble bit planes */
blitscr(qbTo0, vqscrSPX);
qw = (int *)vqscrSPX;
for (b=0; b<4; b++) /* 4 bit planes */
{
qbTo = qbTo0;
for (i=0; i<3980; i++)
{
*(int *)qbTo = *qw++;
qbTo += 8;
}
qbTo0 += 2;
}
}
/* decode the colro palette into */
SPCDecode(qwSPC, cw, qwTo)
register int *qwSPC, *qwTo;
register int cw;
{
register int wMask, cb;
cw /= 2;
while (cw--)
{
if (cw<1)
{
break;
}
wMask = *qwSPC++ & 0x7FFE;
for (cb=0; cb<16; cb++)
{
if (wMask & 0x0001)
{
*qwTo++ = *qwSPC++;
cw--;
}
else
*qwTo++ = 0;
wMask >>= 1;
}
}
}
By the way, I've given up on updates to SPX. No time, and exams are coming up.
Deluxe Slideshow 2.0 does quite a nice job of displaying most file formats,
including Spectrum, but I just wish they had a GEM interface.
- Darek
BIX: darek
CIS: 73657,2714
DELPHI: DAREKM
GEnie: DAREKM
OS/2 is great! Who said it isn't????? Show yourself. Have you ever seen it?
T.R | Title | User | Personal Name | Date | Lines |
---|
1290.1 | nah... | MTBLUE::PFISTER_ROB | Steak knife, puta hole in my head | Sat Apr 02 1988 16:05 | 17 |
| > It appears they are doing this with the ST version of custom copper
> lists (critical timing of raster interrupts). That eats up a bit
> of the 68000, but then that kind of thing doesn't have the limitations
> of HAM mode. Maybe it's time to start doing that kind of thing
> for the Amiga (at least picture viewers).
If this could be done entirely with the Blitter on the Amiga it would be worth
it. Otherwise it would so seriously labotomize the Amiga OS you couldn't use
all the nice features we take for granted, not to mention how useless such a
picture format would be since you cant use any Amiga tools on such a picture..
From seeing with Butcher, Digi-view, et all. The Amiga's graphics mode
with proper dithering could do a respectable enough job without these
inner muckings..
Robb
|
1290.2 | ST is absolutely ___________ | WJG::GUINEAU | | Mon Apr 04 1988 09:06 | 14 |
|
(warning - ST fun made here...)
> move.l #0x8260,RegQ_Rez ; pointer to resolution register
> move.l #0x8240,qCol0 ; pointer to color register 0
> move.l #0x8242,qCol1 ; pointer to color register 1
>
> clr.w 0x8240 ; make screen background black
Hmmm, Is that how it's done on an Atari - All those *absolute* references!
|
1290.3 | | BAGELS::BRANNON | Dave Brannon | Mon Apr 04 1988 21:34 | 21 |
| re: .1
The Amiga's copper lists are constantly being played with by the
OS. That's how it can do things like pull down screens. There
is support for merging a custom copper list in with the OS's lists.
The Copper should be fast enough to do the palette changes without anybody
having to resort to 68000 or Blitter mucking about.
The standard Amiga tools had to be taught about HAM, overscan,
extra-halfbrite, etc. The trick is to get a standard format or
way of doing things. First you need to have have a reason for
doing it, like HAM for digitizing pictures. Spectrum 512 is
being used for that in the ST world (the one with all the hardcoded
addresses :-) ).
Besides, the Apple IIGS supports 256 colors in 320x200 and
64 colors in 640x200 out of a palette of 4096. Why must the Amiga
have max 32 or 4096? Isn't there room for something in between?
-Dave
|
1290.4 | some have it, some don't | HYSTER::DEARBORN | Trouvez Mieux | Tue Apr 05 1988 11:14 | 7 |
| There is, using extra halfbright mode.
Express Paint 2.0 uses this to acheive 64 colors. Only problem
is, I have a very old Amiga, that doesn't have this feature.
Randy
|
1290.5 | ?? | LEDS::ACCIARDI | | Tue Apr 05 1988 11:43 | 17 |
|
I'm a bit confused about the Apple's color capabilities. I think
the paint programs I've seen for it use 16 colors in 320 x 200 or
640 x 200 (no 400 line mode; wimps).
However, the Apple press releases claimed that up to 16 colors
per scanline were allowed. Is this a software trick that current
paint programs aren't exploiting?
I agree with Dave; until we either get a 640 x 400 HAM mode (probably
requires new hardware) a trick is needed to display more colors
in hi-res. Even if we could get 256 colors, we could (with overscan)
produce even higher quality pictures without the restrictions of
HAM.
Ed.
|
1290.6 | Ick! | TLE::RMEYERS | Randy Meyers | Tue Apr 05 1988 15:41 | 37 |
| Re: .5
The Apple IIGS does use palette register swapping to increase the number
of colors on the screen by changing the color palette between scan lines.
(It's basically using the trick being discussed.) Thus it does have the
limitations of the small number of colors available per scan line. Also,
I believe that the GS cannot completely swap palettes between scan lines.
The scan line for the new palette contains 8 new colors and 8 old colors.
Can someone answer a question for me? Are the ST paint programs displaying
these 512 color pictures synchronizing reloading the color registers with
the beginning of a new scan line, or are they changing the color registers
as the scan line being drawn. In the first case, the ST is limited to
displaying 16 (low res) colors per scanline. In the second case, all
512 colors are available per scan line, but the problem is more complex.
(I suspect that these ST programs are doing this harder case.)
By the way, the Amiga's copper can only load 8 color registers per scan
line reliably (in time for the line to be drawn completely using the
new register values). All 32 color registers can reliably loaded in
three scan lines time. If you notice, when you pull down an Intuition
screen, there are three scan lines above the lower screen that are
always drawn in color 0. These three blank lines are padding inserted
by Intuition to allow it to swap the color palettes between drawing the
different screens.
So, I believe that the Amiga can show an 512 color ST file, but it will
be reduced to displaying it the same way the ST does. The display program
takes over the entire computer and uses very critically timed 68000
instructions to manipulate the color registers in real time. At least
a properly written implementation will be able to restore the system
when it exits.
Ugh. Might be interesting as a novelty, but I don't think it will catch
on.
I take it
|
1290.7 | Not coming soon to an Amiga near you! | TLE::RMEYERS | Randy Meyers | Tue Apr 05 1988 15:48 | 12 |
| Re: .5
> I agree with Dave; until we either get a 640 x 400 HAM mode (probably
> requires new hardware) a trick is needed to display more colors
> in hi-res.
Don't hold your breath for high res HAM. It would require 150% of the
total memory bandwidth during video access time.
Maybe on the Amiga 3000?
|
1290.8 | ST changes colors within scan lines. | ROLLIN::BAILEY | Steph Bailey | Tue Apr 05 1988 17:44 | 9 |
| I'm pretty sure the ST (Spectrum-512) does the color changes in mid scan
line. I saw somebody's attempt at reverse engineering this code,
and it was a bunch of critically timed MOVs which were executed
at the beginning of each scan line.
I believe the timing is such that there are some restrictions on
the arrangement of the colors on a line, but I don't remember.
Steph
|
1290.9 | | BAGELS::BRANNON | Dave Brannon | Tue Apr 05 1988 18:52 | 27 |
|
Spectrum is using 3 color palettes, for a total of 48 colors per
scan line. Since there is no position info for those color changes,
I assume that means they divided the scan line into thirds, with
a separate 16 color palette per section.
I haven't heard of any IIGS programs that do 256 colors, but I haven't
been reading IIGS magazines. Just was standing in the local computer
store reading a book about IIGS graphics. Apples basically put
the data structures for the raster interrupts for 256 colors into
the OS. The catch is how much memory lots of colors requires.
One of the fish disks had a demo program, 2 pages in length, that
played with the copper list. The header said that during his testing
he found that he could change the color register every word.
Note, there is difference between having to update the copper list
with the screen is being dragged up/down and simply displaying
a static picture. Maybe the copper can handle more than 8 for
that.
Any comments on mixing 320 and 640 scan lines? (80 column text &
32 colors on the same screen) Is there a need for that? I assume
a custom short screen could do it, but why a screen if you don't
want to drag it.
-dave
|
1290.10 | More than 8 Copper Register Loads? | TLE::RMEYERS | Randy Meyers | Tue Apr 05 1988 19:40 | 15 |
| Re: .9
> One of the fish disks had a demo program, 2 pages in length, that
> played with the copper list. The header said that during his testing
> he found that he could change the color register every word.
> Note, there is difference between having to update the copper list
> with the screen is being dragged up/down and simply displaying
> a static picture. Maybe the copper can handle more than 8 for
> that.
You may be right about the ability to load more than 8 color registers
per line. My source of the information was RJ, and I remember that
mumbled something like, the padding scan lines between screen changes
on the display started out at one line, then became two lines, and then
three lines as Intuition slowed down during development.
|
1290.11 | 4096 colors on the ST | BAGELS::BRANNON | Dave Brannon | Wed Apr 06 1988 19:02 | 76 |
|
Some more details on ST programs that are doing raster interrupts
to get more colors.
-dave
=====================================================================
Newsgroups: comp.sys.atari.st
Path: decwrl!decvax!mcnc!gatech!udel!rochester!cornell
!uw-beaver!tektronix!tekig5!wayneck
Subject: Quantum
Posted: 4 Apr 88 22:08:28 GMT
Organization: Tektronix Inc., Beaverton, Or.
I just bought Quantum this weekend. It is a paint program that allows the
user to paint in upto 4096 colors. I guess the program is okay, it seems to
work but I'm not over impressed by it. I may just be tainted by Spectrum
which really impressed me. I paid arount $40 for it.
Anyway you get the following:
1. four display modes
32 colors - medium res. 4 colors changed 8 times over the picture
128 colors - low res. 16 colors changed 8 times over the picture
512 colors - kind of like Spectrum, gives 32 to 40 colors a scan line
4096 colors - adds flicking inbetween shades to the 512 mode
2. Lots of drawing tools with a fairly easy to use interface. (easier
than Spectrum, but not a flexible and fewer tools than Spectrum I
think).
3. A set of animation tools that allow one to make flip book style
animation. (I haven't use these)
Seems like a lot of bang for the buck? Well here is what I don't like:
1. Key work copy protection, key word is better than most kinds but I
think all copy protection is a big pain in the butt for a honest
user.
2. Spectrum gives me 48 colors per scan line, I need even more, but
32 is often too low. Even thought the manual says "There are some
limitations to the number of different colors that can occur in a
small area of screen - but depending on the sort of images are
being drawn anywhere from 32-40 colors are available on EACH SCREEN
LINE - hardly a limitation, really!" That kind of statment dosen't
sit well with me, what do they know about what I need. Spectrum
gives you upto 15 new colors before the scan line and gives you a
new color every 10 pixels. This program only seems to give you a
new set of 10 colors every 80 pixels. Not quite the same. Still
it is a lot better than nothing.
3. In the 512 and 4096 modes you can only select one color at a time
to work with. There is no color selection table and you can't
look at the picture while selecting the color. There are tools for
setting the color but it real hard for me to compare with only one
color to work with. I just don't have a good color memory.
4. You can't draw with the 512 or 4096 colors displayed. You have
to draw on a 16 color version instead. Sometimes colors just go
away while drawing. Kind of like using ms to make a nice document.
5. Won't flood fill in 512 and 4096 color modes. Just rings a bell at
me.
6. A warning in the manual stating that you can't use Quantum pictures
in your own programs if you want to sell them. They are putting
together a Software House Site Licence and Source Code Kit that you
can buy so that then your program can use Quantum pictures. I think
they are nuts! If I make a picture I can't use it! Why should I
pay than anything so that I can use MY pictures.
Anyway I'm not a artist so while I think Spectrum is better, this program
might be better after some updates and basic changes in attitude.
Wayne Knapp
|
1290.12 | | LEDS::ACCIARDI | | Thu Apr 07 1988 09:05 | 7 |
| If the ST pallett only supports 512 colors, how can Quantumpaint
provide 4096? Unless they're refering to placing two colors next
to each other, and the eye blends them into a new color. DigiView
ads claim over 100,000 'apparent' colors on screen.
Sounds a little fishy to me.
|
1290.13 | I heard a claim. (Probably how I would do it) | ROLLIN::BAILEY | Steph Bailey | Thu Apr 07 1988 13:03 | 5 |
| I think they switch colors on alternate frames--so there are two
pallette entries per pixel.
Steph
|
1290.14 | | LEDS::ACCIARDI | | Thu Apr 07 1988 13:48 | 3 |
| Ah, maybe they try to create an interlaced display; that would explain
the flickering I've heard of.
|
1290.15 | Joke | TLE::RMEYERS | Randy Meyers | Thu Apr 07 1988 18:56 | 6 |
| Re: .13, .14
Their 4096 color mode is a sham. They really display "Drink Coke!" every
other frame.
:-)
|
1290.16 | Old Amiga's can be upgraded | MEIS::FONSECA | I heard it through the Grapevine... | Thu Apr 21 1988 12:38 | 6 |
| Re: .4
By the way, you can have a new chip dropped in so that
your Amiga will display extra-half-bright mode colors.
I had it done to my dinasaur about a year ago, I forget
the cost (under $100)
|