stephan@cup.portal.com (Stephen Derek Schaem) (07/02/89)
After some test I found that displaying 4096 colors in hires is
really easy.The only thing is you can only have 16 different colors per
scanlines (could be doubled) but one can make 6400 colors changes per screen
without a problem.
My question is how could I make a CCOP chunk for the IFF/ILBM
acceptable to everyone? Should I directly dumped the copperlist in the
junk or give a list of positions and registers to change?
We have the hardware why not use it!? I really want to see a
704x440 with 4096 on screen on a standard A500.I'm going to do it for myself
but if you want to see it spread a little ideas are welcome.
I still hope that my posting wont offend anybody.Believe me I never
try to do so.And maybe you can see that I put some effort in the next
message not to upset people reading com.sys.amiga.I still have a little
time to pass on usenet and don't want to make the worst out of it.
Thanks for peoples how took the time to decrypting my previews posting.
AGAIN, PLEASE POST ANY FLAME BY EMAIL.I DON'T FORCE ANYBODY TO AGREE WITH
WHAT I SAY.ALSO DO MAKE IT CLEAR DON'T WORK FOR ANYBODY.
Stephan.doug@xdos.UUCP (Doug Merritt) (07/03/89)
In article <20069@cup.portal.com> stephan@cup.portal.com (Stephen Derek Schaem) writes: > > After some test I found that displaying 4096 colors in hires is > really easy.The only thing is you can only have 16 different colors per > scanlines (could be doubled) but one can make 6400 colors changes per screen > without a problem. Hey, this was very easy to read! Congratulations on a well edited posting, Stephan! (To those who came in late, he's been flamed for the opposite recently.) > My question is how could I make a CCOP chunk for the IFF/ILBM > acceptable to everyone? Should I directly dumped the copperlist in the > junk or give a list of positions and registers to change? I would suggest that the most hardware-independent approach would be to simply specify the new set of color registers. Actually encoding the copperlist seems too hardware dependent. It is quite possible that future Amiga's will not use the current copper. > We have the hardware why not use it!? I really want to see a > 704x440 with 4096 on screen on a standard A500.I'm going to do it for myself > but if you want to see it spread a little ideas are welcome. Seems like a good idea. Oh, some people cringe at the thought, but it *can* produce good effects, so why not? And the Atari ST impressed a lot of people by adopting this approach in a popular paint program. > I still hope that my posting wont offend anybody.Believe me I never > try to do so.And maybe you can see that I put some effort in the next > message not to upset people reading com.sys.amiga. Yes indeed. The effort definitely shows, and I, for one, appreciate it very much. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
stephan@cup.portal.com (Stephen Derek Schaem) (07/04/89)
Let me explain a little more about 4096 hires display, how it work and
why nobody should cringe about it.To get the idea of what I'm doing open 2
hires screen with 16 different colors and drag one down so both are visible
at the same time.See my point? you now have 32 colors in hires:-).
If you change the colors registers (384,000 times a second) you get you 4096
colors screen, even if 640 time 200 is not equal to 384,000 you can still
get very low % of colors error.
You NEED a new way to store colors value since they involve a new
concept, R,G,B,T.You already now what is RGB but T:-) T stand for timg^I5 V-.]X7ce.
The amiga don't store images as RGB, if you wanted to do so in 'copper
mode' you would need 3 time the diskspace and alsoask each viewer to develop
their own copperlist builder...
I agree about the copperlist directly dump to the picture file.
A solution is to make a colortablle for each scan line, but it will be
waisting space and will not ' conform ' with future improvement like
changing color register value inside the visible area!But you could
create a new 'CMAP', a 'CCOP' with the RGBTP or RGBXYP. X,Y will correspond
to the value for Wait(x,y) and the P to the position in the Amiga ColorTable
when to store the RGB value.RGB value can be store in 4bits instead of 8bits.
Any good reason not too?
Hope the above make things more clear on the subject.
Stephan.doug@xdos.UUCP (Doug Merritt) (07/05/89)
In article <20112@cup.portal.com> stephan@cup.portal.com (Stephen Derek Schaem) writes: > > Let me explain a little more about 4096 hires display, how it work and > why nobody should cringe about it. The reason I said some people would cringe is that it's been discussed before, and some people felt that it was an esthetically "dirty" kind of approach. But that's esthetics for you; different people have different feelings. >If you change the colors registers (384,000 times a second) you get you 4096 > colors screen As I recall from previous discussions, you can't change that fast due to latency of response from the chip. Someone once said they'd calculated that you could change (I think) two colors in the palette per scan line in the horizontal retrace period, and if you tried to change more, you wouldn't finish in time for the next scan line. I never double checked this myself, but you certainly should check before committing to this approach. > You NEED a new way to store colors value since they involve a new > concept, R,G,B,T.You already now what is RGB but T:-) T stand for >timg^I5 V-.]X7ce. ^^^^^^^^^^^^^^^^^^^^^^^^^ Remarkably bad timing for line noise; I still don't know what T stands for. Was that just "timing"? > The amiga don't store images as RGB, if you wanted to do so in 'copper > mode' you would need 3 time the diskspace and alsoask each viewer to develop > their own copperlist builder... Actually, yes, I think that each viewer that supported this new IFF type *should* have its own copperlist builder, because the alternative is to dump the copperlist into the file, and that's too hardware dependent. > create a new 'CMAP', a 'CCOP' with the RGBTP or RGBXYP. X,Y will correspond > to the value for Wait(x,y) and the P to the position in the Amiga ColorTable > when to store the RGB value.RGB value can be store in 4bits instead of 8bits. If you mean to create a copperlist that waited until some certain (x,y) position on the screen, and then switched to the next color map, then I think that chip latency will screw you up. In other words I really do think that you need to switch colors between scan lines, during the horizontal retrace interval, and so you may as well just specify which color registers to reload on each scan line. And as I mentioned above, you may be limited to two register changes per scan line. If this "two new colors per scan line" assumption is true, then at 400 lines per screen you'd get 16 + 399 * 2 == 814 colors per screen. Another old idea is to time average colors, so that on one frame you have color X in some pixel, on the next color Y, then back to X, etc, so that you time average the colors to look like (X+Y)/2 at that pixel. In hi res the refresh cycle would be 15 hertz (30 hertz / 2 frames per complete set of colors), so it would help for colors X and Y to be similar shades to reduce additional flicker. Besides which, if you do a few experiments on paper using shades of grey as a model, you'll see you can't get anything better than a new hue midway between two existing hues even by using highly contrasting colors, so you may as well use similar colors when possible. Using this approach you can (ideally) double the number of apparent on-screen colors, which would give 814 * 2 == 1628 colors. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
jwright@atanasoff.cs.iastate.edu (Jim Wright) (07/05/89)
A little bit off the track, but what the heck... I've no doubt that a greater number of colors can be displayed in HIRES by using the tricks described. And coming up with some sort of IFF spec for it is good. But just where are the images to be displayed coming from? :-) Having a viewer is half the story. When developing the spec it might be good to also consider the needs of the programs that will generate these pics. Maybe having a "Ted Turner" program would be the solution --- it takes in a standard HIRES pic and then colorizes it. :-) -- Jim Wright jwright@atanasoff.cs.iastate.edu
cullip@unc.cs.unc.edu (Timothy Cullip) (07/05/89)
Actually the 4096 color mode in HIRES can be quite useful. I have recently modified a ray tracer I wrote that used to use 320x400 HAM to now also use 640x400 HIRES with the ability to change the color registers every scanline. I have found that with 4 bitplanes the bus is too busy during the scanline to get any color registers changed through copper instruction, but during horizontal blank I can easily change 13 of the 16 registers. You end up with one very long copper list, but it works just fine. I even have it behaving quite well under Intuition (but screen drags are very slow!). The limit of 16 colors per scan line can be somewhat of a problem in a ray tracer, but for the most part my pictures turn out much nicer looking than the old 320x400 HAM pictures I was generating. I would be very interested in an IFF standard that incorporated this mode since right now I use a crude double file format that kept the color info separate from the IFF picture. T. J. Cullip
kevin@arnor.UUCP (Kevin Goroway) (07/05/89)
I worked on a similar project about two years ago. It involved a small program that took command line arguments to set up a copper list however you wanted it. It would then save the copper list (specifiaction) in a file, and fire up Deluxe paint, letting you paint in many many more colors than normally possible. You would save the picture when you were done, and to view it you would use a scripting program that would first set up the copper list, and then load the picture. It all worked rather nicely...but an IFF spec would be great! (by the way: It would be a terrible application for raytracing, since you can't change colors on every pixel.) Good luck! -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - Worcester Polytechnic Institute|"It happens sometimes, people just explode, - = Worcester, MA | natural causes." -Repo Man = -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
doug@xdos.UUCP (Doug Merritt) (07/06/89)
In article <206@arnor.UUCP> kevin@arnor.UUCP (Kevin Goroway) writes: >(by the way: It would be a terrible application for raytracing, since you can't > change colors on every pixel.) I doubt that "terrible" is quite the word. Seems like it'd be easier to pick colors for this scheme than it is to use HAM. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
stephan@cup.portal.com (Stephen Derek Schaem) (07/06/89)
All you heard is not true, I hope or I'm totaly crazy and the 0 bitplane 256 colors images in the background is not there, and the 4096 colors in 5 bitplane display earlyer where only dreams. Back to reality:-) the copper need 2 bus cycle for a MOVE, you need 32 move (aprox) before any scanline.The copper get all the even cycle it need.This e equal too humm.. (280x2x32)/140 and you get the distance in pixels (lores) you will need to change all those colors.64... also count the blanking gap. (by the way, 280 is a bus cycle in nanosecond, 140 the lenght in time a lores pixel is displayed). Overscan:-( yeah, that would need more work but still possible. (I didn't mention the bitplane DMA for the even bus cycle.... a 'slight' slow down). All I can say for sure is, you can change register ALOT more than twice. T stand for the video beam position, x could be left to zero for now but could be use. I example that is they find it a bad idea, why in hell do those people think of intuition!!! and the multyscreen... Anyway I just wish I could see example of those people test program showing the limitation they anounced. Just for example I changed 61 time the background colors per scan line (zero bitplane screen) that 200 times to creat an image of Max headroom. The 'pixel' are really width, and I know that If I could not use C and the copper macro and intead use asm I would get better result.(I dont beleive in CWAIT, not asm being faster:-) Stephan.
stephan@cup.portal.com (Stephen Derek Schaem) (07/06/89)
In response of 'where the pictures come from':-) I have alot of 24bitpanes pictures I'm working on.The first idea came years ago when I had a 32 colors hires screen in fron of me (2 hires 16 colors hlaf way scroll). (dont you like 'years ago', 2 years to be exact:-) It's not only great for hires, but you can turn lores into a 12bitplane viewwer with very good result!. The programes WILL generate the file form the copperlist, how would you want to grab it otherwise!.Librayr should be good, but not for now... NewTek suport 21bitplane RGB file... put them down to 12 and there you go... also convert HAM into hires... mix diferent hires screen etc.. I'm using imported pictures but the amiga could really use that 'format'. Interlace is my curent problem!
jms@tardis.Tymnet.COM (Joe Smith) (07/06/89)
In article <20069@cup.portal.com> stephan@cup.portal.com (Stephen Derek Schaem) writes: > After some test I found that displaying 4096 colors in hires is > really easy.The only thing is you can only have 16 different colors per > scanlines (could be doubled) but one can make 6400 colors changes per screen > without a problem. > > My question is how could I make a CCOP chunk for the IFF/ILBM > acceptable to everyone? Should I directly dumped the copperlist in the > junk or give a list of positions and registers to change? Raw copper lists really don't belong in an IFF program. You really want to save just the color registers and let the IFF reader re-create the copper list. On the Atari ST, a picture in "Spectrum 512" format can display all 512 colors on a 640 x 199 screen by doing the same sort of thing; changing the color registers on every scan line. Enclosed are the details, in case you want to add this format to your display program. From: dmb@TIS.COM (David M. Baggett) Newsgroups: comp.sys.atari.st Subject: Monthly Picture Formats Posting Message-ID: <8811091812.AA03351@TIS.COM> Date: 9 Nov 88 18:12:30 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet ST Picture Formats ------------------ Compiled by: Dave Baggett (arpanet: dmb@TIS.COM) (Please report errors or additions) CONTRIBUTORS Phil Blanchfield David Brooks Neil Forsyth Ken MacLeod Jim McCabe Darek Mihocka David Mumper George Seto Joe Smith Greg Wageman Gerry Wheeler Introductory information ------------------------ word = 2 bytes long = 4 bytes palette = Hardware color palette, stored as 16 words. First word is color register zero (background), last word is color register 15. Each word has the form: Bit: (MSB) 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 (LSB) -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 0 0 0 0 0 R2 R1 R0 0 G2 G1 G0 0 B2 B1 B0 R2 = MSB of red intensity R0 = LSB of red intensity G2 = MSB of green intensity G0 = LSB of green intensity B2 = MSB of blue intensity B0 = LSB of blue intensity Intensity ranges from 0 (color not present) to 7 (highest intensity). Example: { red = 7, green = 3, blue = 5 } -> 0735 (hex) The Formats ----------- <NEOChrome> 1 long resolution (0 = low res, 1 = medium res, 2 = high res) 16 words palette 12 bytes filename (" . ") 1 byte Left color animation limit (starting color number) 1 byte Right color animation limit (ending color number) 1 byte color rotation speed 1 byte color rotation direction 1 word color rotation duration (number of iterations) 18 longs reserved for expansion 16000 words picture data (screen memory) ----------- 32128 bytes total <Spectrum 512 (Uncompressed)> 80 words first scan line of picture (unused) -- should be zeroes 15920 words picture data (screen memory) for scan lines 1 through 199 9552 words 3 palettes for each scan line (the top scan line is not included because Spectrum 512 can't display it) ----------- 51104 bytes total <Spectrum 512 (Compressed)> 1 word 5350 (hex) ("SP") 1 word 0 (reserved for future use) 1 long length of data bit map 1 long length of color bit map <= 32092 bytes compressed data bit map <= 17910 bytes compressed color bit map -------------- < 50014 bytes total Data compression: Compression is via a modified run length encoding (RLE) scheme. The data map is stored as a sequence of records. Each record consists of a header byte followed by one or more data bytes. The meaning of the header byte is as follows: For a given header byte, x: 0 <= x < 127 Use the next x + 1 bytes literally (no repetition) -128 <= x < 0 Use the next byte -x + 2 times The data appears in the following order: 1. Picture data, bit plane 0, scan lines 1 - 199 2. Picture data, bit plane 1, scan lines 1 - 199 3. Picture data, bit plane 2, scan lines 1 - 199 4. Picture data, bit plane 3, scan lines 1 - 199 Decompression of data ends when 31840 data bytes have been used. Color map compression: Each 16-word palette is compressed separately. There are three palettes for each scan line (597 total). The color map is stored as a sequence of records. Each record starts with a 1-word bit vector which specifies which of the 16 palette entries are included in the data following the bit vector (1 = included, 0 = not included; i.e., stays the same). The least significant bit of the bit vector refers to palette entry zero, while the most significant bit refers to palette entry 15. Bit 15 must be zero, since Spectrum 512 does not use palette entry 15. Bit 0 should also be zero, since Spectrum 512 always makes the background color black. The words specifying the values for the palette entries indicated in the bit vector follow the bit vector itself, in order (0 - 15). <MacPaint> header { 1 long version number (if zero, entire header is ignored) 38 * 2 longs pattern data (anyone know how to use this?) 51 longs reserved } < 51200 bytes compressed bitmap data ------------- < 51716 bytes total Bitmap compression: The bitmap data is for a 576 pixel by 720 pixel monochrome image. The data is stored as a sequence of records. Each record consists of a control byte followed by one or more data bytes. The meaning of the control byte is as follows: For a given control byte, x: 0 < x < 127 Use the next x + 1 bytes literally (no repetition) -128 <= x <= 0 Use the next byte -x + 1 times There are 72 bytes per scan line. Each bit represents one pixel; 0 = white, 1 = black. Version of Fri Sep 23 18:14:40 EDT 1988 --------------------------------- >8 -------------------------------- -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
doug@xdos.UUCP (Doug Merritt) (07/06/89)
In article <8721@thorin.cs.unc.edu> cullip@unc.cs.unc.edu (Timothy Cullip) writes: >Actually the 4096 color mode in HIRES can be quite useful. I have recently >modified a ray tracer I wrote that used to use 320x400 HAM to now also use >640x400 HIRES with the ability to change the color registers every scanline. >I have found that with 4 bitplanes the bus is too busy during the scanline >to get any color registers changed through copper instruction, but during >horizontal blank I can easily change 13 of the 16 registers. You end up That's interesting. So there's time for a lot more color register loads than I'd (mis-)remembered. There would seem to be some interesting tradeoffs involved here. The implication is that there isn't any bandwidth left for a 14th register change, of course, nor for that matter, left for doing anything else, either. > I even have it >behaving quite well under Intuition (but screen drags are very slow!). Right, the only time the processor can get anything done is during vertical retrace. Perhaps it would be a good idea to leave some more time slots open so that *some* things can still happen during horizontal retrace. For instance, if you restricted it to 8 color register changes per scan line, then presumably system response would be much snappier, and background tasks would be able to run sometimes, yet you'd still have lots of colors to play with (one complete palette switch every two scan lines). >The limit of 16 colors per scan line can be somewhat of a problem in a ray >tracer, but for the most part my pictures turn out much nicer looking than >the old 320x400 HAM pictures I was generating. Yes. And although 8 colors/scanline is still more limited than 13/scanline, I'm sure it'd still look nicer than HAM. And consider how much more effective it would be to show off the Amiga to someone if you could still get reasonable system response even while displaying a really nice image. I don't think that dealers, for instance, would ever show the 13/scanline images, because it'd impact performance so much. And, hmmmmm, what about playing background music? Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
johnm@spudge.UUCP (John Munsch) (07/07/89)
I knew those months when I owned an ST would come in handy for something :-)
Basically, it sounds to me like you are trying to rebuild the system that the
ST uses to display pictures with more than 16 colors. It appeared first in
the program Spectrum 512 and a description of its format and the nature of
graphics on the ST follows this...
Basically what I think we could get out of it are two things:
1) A simple method for compressing the extra information we need for a
graphics screen. For example, if we do things similarly to Spectrum then we
will have a line of data and then a set of colors that refer to that line.
The number of colors will depend on how rapidly we can perform the color
register switching during the course of the line being written to the screen.
We keep down the amount of space devoted to each lines color table by using a
bit map to indicate which colors changed in the table from the previous line
to this line. Due to the locality of color that most pictures exhibit this
should help tremendously to keep the extra color information within reason.
2) The other thing we can get from Spectrum is a sensible way of describing
the new screen format. If you change the color registers in order, first
register one, then two, etc. you will have a set of regions that each color
covers.
For instance, let's say that you can change the color in each register
exactly three times while a scan line is being drawn. Then the number of
colors on a given scan line is 48. Each color also has a certain area of the
scan line it covers, like so...
012345678901234567890123456789012345678901234567
Scan line pixel # 000000000011111111112222222222333333333344444444
Reg 1 = Color 1 xxxxxxxx
Reg 2 = Color 2 xxxxxxxxxxxxxxx
.
.
.
Reg 1 = Color 17 xxxxxxxxxxxxxxx
Reg 2 = Color 18 xxxxxxxxxxxxxxxx
.
.
.
Where the x's represent the pixels where that color is available.
By doing things this way we also don't have to give up using intuition
altogether. If all the colors for a given register are set to the same color
all the way down the screen (i.e. Colors 1, 17, 33 are set to black on every
line) and that is done for the first four registers then you will have
sacrificed some colors on every line but you will still be able to draw
windows, menus, etc. and have them look normal.
/* End of my $.02 */
Note: All of the above assumes that the copper will let you change the
R,G,B of a given register all in one swoop rather than one component at a time
like HAM mode. If that isn't possible and we are stuck with fringing around
the places where colors switch then I have to say, don't waste your time.
The fringing in HAM mode makes it a bitch to use and the few people who seem
to have come up with good algorithms for working around it (like Digi-tek)
don't seem inclined to share them with the rest of us.
John Munsch
=============================ST Graphics/Spectrum=============================
The following is a description that I wrote (a long time ago) of the ST's
graphics and the Spectrum format documentaion that Antic software distributes.
The part with the >'s is mine.
>Color: Color on the ST is handled in the same way as on a lot of micros
>currently. They lack the memory necessary to show all the colors available
>because you would need to store a large number of bits for each pixel in order
>to keep track of its color. For example, the Atari has 512 colors available,
>if these were to all be available simultaneously then you would need
> 320 * 200 * 9 bits (screen resolution * number of bits needed)
> (to store numbers from 0-511)
> = 72K for a graphics screen!
>Instead, the ST (and others) use color registers, 16 of them in the Atari's
>case. Each register is given a color value from the 512 available and then
>each pixel need only store four bits to refer to the color register that
>contains the color for that pixel. Even though this can be a real hinderance
>(16 colors on a screen isn't much) it does allow for tricks like color
>cycling (changing the colors in the registers so that parts of the picture
>change color instantly).
>
>The colors that are available on the ST are stored in the color registers
>(and also in most files) as follows:
> A two byte word: 0000 0 111 0 111 0 111
> ^^^ ^^^ ^^^ Three bits specifying a blue
> | | intensity from 0-7
> | --- Three bits specifying a green intensity
> | from 0-7
> --- Three bits specifying a red intensity from 0-7
> The 0 bits are just wasted bits...
> 8 levels of red * 8 of green * 8 of blue = 512 colors
>
>Resolution: There are 3 resolutions on the Atari ST (not counting European PAL
>mode). They are:
> 320 x 200 (with all 16 palette registers used) <- The most common
> 640 x 200 (with the first 4 palette registers used)
> 640 x 400 (monochrome)
>You'll note that what they have done is cut down the number of bits needed to
>specify colors per pixel as the resolution increased. The effect of this was
>to keep the amount of memory used by the screen buffer constant across all
>resolutions.
>
>Pixel organization: Once you know the above then all you need to know is
>exactly how pixels are stored in the 32K devoted to the screen on a ST.
>I'll tackle the easiest first, monochrome. Because each pixel needs only 1
>bit to store its color, the pixels are just stored in order reading from left
>to right, one line at a time. The first bit in the first byte corresponds to
>the pixel in the upper left corner, the next bit to the pixel just to the
>right of it, etc.
>
>Unfortunately, the storage in the color modes is not so simple. In fact, I
>have seen conflicting information on exactly how pixels ARE stored in the
>color modes. What I'm about to give you is the version that I have seen most
>often and believe to be correct (I have never written directly to video
>memory myself so I can't say for sure). Rather than storing the 4 bits per
>pixel contiguously in the color modes (i.e. 11112222 33334444 = the first four
>pixels color info as on an IBM) the ST stores pixels in separate "planes" for
>high speed access by the video chips. The way this works is like this:
> Two byte words: 12345678 9ABCDEFG 12345678 9ABCDEFG
> 12345678 9ABCDEFG 12345678 9ABCDEFG Low resolution
>
> or 12345678 9ABCDEFG 12345678 9ABCDEFG Med resolution
>The first byte contains the leftmost bit for pixels 1 through 8, the next
>byte the for pixels 9 through 16. Thus, to get the colors for sixteen pixels
>in low resolution mode you would need to read in 4 two byte words, the color
>for the first pixels would be in the marked bit positions:
> 12345678 9ABCDEFG 12345678 9ABCDEFG 12345678 9ABCDEFG 12345678 9ABCDEFG
> ^ ^ ^ ^
> | | | |
> ------------------------------------------------------
> These bits when combined together give the color register to use
> for pixel one. The ones next to them for pixel two, etc.
>
>For medium resolution the setup is identical except that you only need to deal
>with two bits per pixel so you only need to read in 2 two byte words at a time
>in order to get the info for 16 pixels.
SPECTRUM 512 Picture File Format
There're two kinds of Spectrum files: uncompressed (.SPU) and
compressed (.SPC).
The .SPU file is always 51104 bytes long and consists of two parts:
first the bit map (32000 bytes) and then the color map (19104 bytes).
Because SPECTRUM 512 cannot display the topmost raster line, you have
199 lines instead of 200. For that reason, the top line in the bit map
(the first 160 bytes of the file) contains no useful information and
you should simply ignore it (SPECTRUM 512 fills it with zeros).
Otherwise the bit map has the usual meaning -- low res, 4 planes, 160
bytes per raster line, giving each pixel a certain color number from 0
to 15. When you want to determine the color of any particular pixel in
the .SPU file, you should first find it's color number (using Get Pixel
$A002 from A-line, for example; or your own routine).
To find the actual color of the pixel, look at the color map portion
of the file. It consists of 199 blocks, one 96-byte block per raster
line (no dummy top line here!). Each block contains 48 word color
values in the usual ST format (00000rrr0ggg0bbb, r=red, g=green,
b=blue). You will find the block you need for your particular pixel
at the address (Y-1)*96 from the start of the color map, where Y is the
Y coordinate of your pixel, 1<=Y<=199.
Finding which of the 48 colors in the block is the color of your
pixel is a little trickier. To do that you'll need the color number
that you found from the bit map and the X coordinate of your pixel.
First, multiply the color number by 10. If the color number is even,
add 1 to the result; if it's odd, subtract 5. Let's call the resulting
number X1. Now, if X is less then X1, leave the color number as it is;
if X is more or equal X1 but less then X1+160, add 16 to the color
number; and if X is more or equal X1+160, then add 32 to the color
number. This adjusted color number (it could be anything from 0 to 47)
is the solution to our problem! It shows which of the 48 color values
in the block corresponds to your particular pixel.
An example:
X=139 and the color number is 3.
Multiply by 10: 3*10=30.
Subtract 5 (because 3 is odd): X1=30-5=25.
Okay, 139 is more than 25, but less than 185 (25+160). So, we add 16
to the color number and the result is 19. That pixel's color will be
found in the word number 19 of the block (word count starts at 0).
.SPC files consist of 3 parts: 12-byte header, compressed bit
map and compressed color map. Here's the header layout:
word $5350 ("SP")
word 0 for future enhancements
<>0 means there're additional
records in the file, following
the compressed color map
long length of the bit map
long length of the color map
Bit map compression is a slightly modified RLE. Each record
consists of a header byte followed by one or more data bytes. A
positive header ( 0<=n<=127 ) means copy the next n+1 bytes literally,
a negative ( -128<=n<=-1 ) - copy the next byte -n+2 times (minimum 3;
the encoder does not compress if there're just 2 equal bytes in a
row). First goes bit plane #0, all scan lines from 1 (not 0!) to 199,
without breaks at the ends of scan lines (only at the end of the last
line), then bit planes #1,2 and 3. Terminate decompression when the
number of bytes extracted reaches 31840 (4 bit planes x 199 lines x 40
bytes per line). The length of the compressed bit map is always even,
so there might be one filler byte at the end of it. If you convert
an .SPC file to .SPU to display it on the 512-color screen, fill scan
line #0 with zeros (first 160 bytes of the .SPU file) to give it the
same color as the top screen margin.
In the color map each short 16-word block is compressed
separately (there're 3 of them in each scan line, 597 altogether). The
compressed record for each short block starts with the bit vector (1
word) indicating which of the 16 color slots are used, followed by the
color values themselves (each is a word). For instance, $000A,$0707,
$0777 should be expanded into 0,$0707,0,$0777, twelve zeros ($000A =
%0000000000001010, meaning only colors #1 and 3 are used). Unused
color slots should always be filled with zeros. Color #15 is never
used in a finished Spectrum picture, so bit #15 of the bit vector must
always be 0. Color #0 is always used (as a background) and it's always
black. Since it makes no sense to have this extra 0 in every
compressed record, bit #0 of the bit vector is always cleared,
indicating to the decoder to fill slot #0 with 0. The number of color
values following the bit vector in the compressed record is equal
to the number of 1's in the bit vector.
If the above compression rules are observed the length of the
compressed bit map will never be greater than 32092 bytes, and the
length of the compressed color map will never be greater than 17910
bytes. Spectrum rejects SPC files that exceed these size limits.jeh@elmgate.UUCP (Ed J Hanway CUST) (07/07/89)
In article <421@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: (speculating why screen drags with a custom copper list are slow) >Right, the only time the processor can get anything done is during vertical >retrace. Perhaps it would be a good idea to leave some more time slots >open so that *some* things can still happen during horizontal retrace. Actually, I think screen drags are slow because Intuition must rebuild its master copper list whenever a screen is dragged. For normal screens, the copper lists are trivial, and the rebuilding is quick enough that screen dragging is smooth, but a custom list that has a few instructions per scan line can take a while to sort. Sure, the extra copper instructions will steal cycles that would have gone to the CPU, but the real slowdown happens because the computations necessary for screen dragging are much harder. >For instance, if you restricted it to 8 color register changes per scan >line, then presumably system response would be much snappier, and background >tasks would be able to run sometimes, yet you'd still have lots of colors >to play with (one complete palette switch every two scan lines). Why place any restrictions on it at all? I'd much rather see a scheme where I could redefine one color for line 1, then 12 for line 2, then 3 for line 3, and so on. On the average, this would probably result in less copper instructions but would allow more flexibility. >-- >Doug Merritt {pyramid,apple}!xdos!doug >Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary -- Ed Hanway Eastman Kodak Company ...!rochester!kodak!elmgate!jeh #include <std_disclaimer.h>
kevin@arnor.UUCP (Kevin Goroway) (07/07/89)
Doug, I see your point about this technique working for Ray Tracing. I misunderstood the approach that was to be taken. Most of my experimentation was in changing only one of the color registers as fast as possible, and as you know, this is far from every pixel. I can't wait to see this one a reality... "Deluxe Paint IV, the final frontier..." -Kevin -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - Worcester Polytechnic Institute|"It happens sometimes, people just explode, - = Worcester, MA | natural causes." -Repo Man = -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
stephan@cup.portal.com (Stephen Derek Schaem) (07/07/89)
From Kevin: >It all worked rather nicely...but an IFF spec would be great! >(by the way: It would be a terrible application for raytracing, since you can > change colors on every pixel.) Yes, I would try otherwise:-) But for the raytracing is not true at all.The copper can ONLY help and can help alot for HAM.I haven't done any calculation on my ham images but I sure I could break down 30-9% to 3-1% color diference from 12 bitplanes images with the copper. Also it allow a new video mode, where you have a diferrent palette for each scan line.And it's rare that images use sizex of diferent colors on 1 scan line.
stephan@cup.portal.com (Stephen Derek Schaem) (07/07/89)
T. J. Cullip, the open that conference to actually get the format decided and then try to make CBM accept it. So if you have any suggestion you are welcome... For you raytrace, Try not to use the last bitplane untill you have too during that time you have upper half of the color table not on screen that let you change the other register in that upper half.You can extand that and do other checking of the like, so you can actually have alot more color on one scanline than 16 (in hires). I calculated (more experienced:-) that you can change 44 register in lores 5bitplane..Let me try in hires.. Well untill the Bitplane DMA dont take odd cycle it's 44... 22 in hires 3 bitplane etc.. Also you should check color table from scan line to the next, some can be shared.... That give you more time to work on other register on the fly. Best case should be around 32 colors per scna line in HIRES... I wonder if the blitter could help... Anyway, hope those tips could help a bit to creat THE best hires images ever made on the amiga. Well imagine with 32 register changes (drag bar) :-)
portuesi@tweezers.esd.sgi.com (Michael Portuesi) (07/16/89)
In article <412@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: In article <20112@cup.portal.com> stephan@cup.portal.com (Stephen Derek Schaem) writes: >If you change the colors registers (384,000 times a second) you get you 4096 > colors screen As I recall from previous discussions, you can't change that fast due to latency of response from the chip. Someone once said they'd calculated that you could change (I think) two colors in the palette per scan line in the horizontal retrace period, and if you tried to change more, you wouldn't finish in time for the next scan line. I never double checked this myself, but you certainly should check before committing to this approach. Only two colors? The Atari 800 has the capability to interrupt the CPU at a particular raster position (very similar to the Amiga's Copper, but only at the end of a raster scan line). I remember that even with the 1.79 MhZ clock on the Atari you could change three colors reliably if you wrote your interrupt service routine tightly enough. I should think that you could change more colors in the palette with the Copper, though all 32 seems pretty unlikely. Of course, I could simply be spewing rubbish. --M
stephan@cup.portal.com (Stephen Derek Schaem) (07/21/89)
Ok here a actual number, 14 in hires 4 bitplane.alot more if you had only 2 bitplane.Maybe around 24 in lores 5 bitplanes. the fastes I done is 44 register change during the visable scan line. on a one 2 bitplane hires screen. one of my last portal posting, please send ALL mail to stephan@velo.sgi.com I showed demo at BADGE, only 200 time 14 register change in hires. Soon you can double that number (200x14x60 to get the register change in one second...) when interlace come, 400x14x60.Only 336,000 register change in a second:-) Stephan.