SAMcinty@exua.exeter.ac.uk (Scott McIntyre) (04/02/91)
I've posted a few bits and pieces lately about the graphics capabilities of the ST series, but I don't seem to have learned much, so, here are all my questions....if you can help me, I would greatly appreciate it... 1) I have a 520 STE (w 4/meg add on)...and the SM 124. I asked a few weeks ago about graphics on this kind of system, and a number of people all suggested that I look into GIF stuff...I have been doing so, downloading dozens at a time from wuarchive, and viewing them on the PC that does the downloading - they all look brilliant. But when I get them home they look crap. Is the usual method of de-giffing a colour (heck, even mono) picture onto an ST merely the clumping of black and white dots, at a horrendous resolution? I know that a lot of effort went into writing these programmes out there, but it seems amazing to me that on the VGA system (yes, I know it has better graphics) it can look so amazing, and on my ST it looks like someone sneezed! Am I doing something wrong? I've been using ViewPic which is very nice for loading gif images, and works in mono or coulour (but looks bad either way...the colours are all off), but the gray images still look like nothing more than clever optical illusions... So...: 2) Does the STE have gray scales, you know, proper shades of gray, not just the nearness of black and white pixels? How can I use these scales? When I look in magazines I see some AMAZING pictures on SM124s that are gray, but look as sharp as a photograph! They ought to! 600 x 400 should yield fantastic quality...so, where is it? 3) Is there any source ftpable that has a collection, or even just a few, of these images? What might they be called? What kind of suffixes will they have? GR8? GR9? 4) Is it possible to get Gif images to look remotely nice on a STE? Thanks in advance for any help that can be given...I just sorta jumped into the world of the ST without really looking at what it can and cannot do.. Thanks, Scott .
larserio@IFI.UIO.NO (LarsErikOsterud) (04/03/91)
I have a monochrome GIF viewer that uses a kind of dot pattern (not the usual GEM-fill patterns - much better) and that look very good on SM124 You can buy some upgrade kit in Germany that makes it possible to use MEDIUM and LOW res on SM124 as grey-scale.... Lars-Erik / ABK-BBS +47 2132659 / ____ ______ ________________________ Osterud / larserio@ifi.uio.no / /___ / The norwegian ST __________/ ______________________/ ____/ / Klubben, user association
hyc@hanauma.jpl.nasa.gov (Howard Chu) (04/03/91)
In article <1245@exua.exeter.ac.uk> SAMcinty@exua.exeter.ac.uk (Scott McIntyre) writes: > I've posted a few bits and pieces lately about the graphics capabilities >of the ST series, but I don't seem to have learned much, so, here are >all my questions....if you can help me, I would greatly appreciate it... > > Is the usual method of de-giffing a colour (heck, even mono) picture >onto an ST merely the clumping of black and white dots, at a horrendous >resolution? I know that a lot of effort went into writing these programmes There is no usual method, GIF is not an ST standard picture format. It is a (*gag*) PC oriented format designed by the Software Geniuses at Compu$erve. (double-*gag*...) >2) Does the STE have gray scales, you know, proper shades of gray, not >just the nearness of black and white pixels? How can I use these scales? >When I look in magazines I see some AMAZING pictures on SM124s that are >gray, but look as sharp as a photograph! They ought to! 600 x 400 should >yield fantastic quality...so, where is it? "Gray-scales" on the STe typically refers to using a color monitor on the STe and just filling the palette (16 entries) with gray. On the STe since there are 4 bits per color (R,G,B) and "gray" is just equal values of each color, you can get 16 distinct intensities of gray *on a color monitor* and only in low-rez. In medium rez you can only get 4 levels. There's nothing special going on here, you're just using your color system with a pretty unimaginative selection of colors. >3) Is there any source ftpable that has a collection, or even just >a few, of these images? What might they be called? What kind of suffixes >will they have? GR8? GR9? Try .SPC, .SPU, or .SPS for Spectrum 512 pictures. Spectrum 512 only uses low-rez as well. >4) Is it possible to get Gif images to look remotely nice on a STE? Well, it's fairly simple to display a full 256-color GIF image, if that's what you mean. I have code doing this in my port of Fractint 12. Using frame-swapping to (almost) double the number of bits per pixel just about squares the number of colors to choose from, and also squares the number of colors displayable at once. (Fractint lets you use 16 colors in med-rez and 256 in low-rez.) This is pretty reasonable, given that regular VGA rez only allows 16 colors onscreen in 640x480 mode. I wonder why other folks haven't tried these tricks with their GIF decoders. I am taking the GIF decoding routine from Fractint and using it with my frame-swapping code, and getting pretty tolerable results. For you with your monochrome system, well... Frame-swapping can work there too, but I'm not sure how many colors you can reasonably expect to get. I just received some code from someone else that is supposed to render 256 grayscales on a monochrome monitor, I haven't gotten to try it yet. (Looking thru, it seems to really only give 4 or 16, but that's still better than black&white, eh?) -- -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA Disclaimer: How would I know, I just got here!
ekrimen@ecst.csuchico.edu (Ed Krimen) (04/03/91)
In article <1245@exua.exeter.ac.uk> SAMcinty@exua.exeter.ac.uk (Scott McIntyre) writes: > > Is the usual method of de-giffing a colour (heck, even mono) picture >onto an ST merely the clumping of black and white dots, at a horrendous >resolution? I know that a lot of effort went into writing these programmes >out there, but it seems amazing to me that on the VGA system (yes, I know >it has better graphics) it can look so amazing, and on my ST it looks like >someone sneezed! Am I doing something wrong? I've been using ViewPic which >is very nice for loading gif images, and works in mono or coulour (but looks >bad either way...the colours are all off), but the gray images still look >like nothing more than clever optical illusions... Get a copy of GIFFER for the ST for converting GIF files to the ST with a monochrome monitor. It has 4 levels of dithering. GIFFER won't let you save the files into a PI3 pic, so you'll need a screen capture program, SNAP30 works well (I think it's SNAP30). Both programs are on atari.archive. -- Ed Krimen ............................................... ||| Video Production Major, California State University, Chico ||| INTERNET: ekrimen@ecst.csuchico.edu FREENET: al661 / | \ SysOp, Fuji BBS: 916-894-1261 FIDONET: 1:119/4.0
logajan@ns.network.com (John Logajan) (04/03/91)
SAMcinty@exua.exeter.ac.uk (Scott McIntyre) writes: >1) I have a 520 STE (w 4/meg add on)...and the SM 124. >GIF stuff... and viewing them on the PC that does the >downloading - they all look brilliant. But when I get them home they look >crap. The secret to photo quality pictures is (for black and white) the number of brightness levels (greys) or (for colour) the number of RGB combinations available per pixel. Consider that USA broadcast television can only send about 250 equivalent color "pixels" per scan line, and you can see that the issue is not one of the number of pixels per line (of course, more don't hurt) but of the "shades" those pixels can assume. A GIF on a 640 VGA is BETTER quality than anything I've seen on my broadcast television set. An Atari ST or STe is much worse. Not because of the number of pixels in a scan line (which exceeds broadcast TV) but simply because the Atari has only a few shades to pick from in color mode (4 or 16) and only black and white for high-res mode. You see, VGA has 256 colors (or 64 shades of grey, I believe) per pixel. There in lies the secret, and there in lies the disappointment of Atari's stone age graphics modes. >4) Is it possible to get Gif images to look remotely nice on a STE? No. Even ST's in color mode have only 8 shades of grey, and the STe's have only 16. In high-res mode you just got on or off. -- - John Logajan @ Network Systems; 7600 Boone Ave; Brooklyn Park, MN 55428 - logajan@ns.network.com, 612-424-4888, Fax 612-424-2853
logajan@ns.network.com (John Logajan) (04/03/91)
hyc@hanauma.jpl.nasa.gov (Howard Chu) writes: >>4) Is it possible to get Gif images to look remotely nice on a STE? > >Well, it's fairly simple to display a full 256-color GIF image, if that's >what you mean. I have code doing this in my port of Fractint 12. Using >frame-swapping to (almost) double the number of bits per pixel just about >squares the number of colors to choose from, and also squares the number >of colors displayable at once. I take it by frame swapping that you build two (or more) logical screens and alternate between them every vertical retrace -- so as to layer intensities on top of one another. Thus your eye and the persistence of the phosphors become the brightness integrators. A duty cycle kind of thing. Let's see per color you have one frame-pixel full on and one frame-pixel in one of 8 possible levels. Or one at level 6 and the other in 7 possible levels, etc .. 8+7+6+5+4+3+2+1=36 levels per color, or 46,656 possible colors to choose from. Hmm, but you still only have 16 pallette cells to choose from per scan line, and you can only add them and not multiply them. Giving you 32 colors per scan line (or scan zone in Spectrum 512 mode) max. My guess would be that flicker and pseudo-shadow movements would be quite severe. So how does it really look? -- - John Logajan @ Network Systems; 7600 Boone Ave; Brooklyn Park, MN 55428 - logajan@ns.network.com, 612-424-4888, Fax 612-424-2853
logajan@ns.network.com (John Logajan) (04/03/91)
>one frame-pixel in one of 8 possible levels. Or one at level 6 and >the other in 7 possible levels, etc .. 8+7+6+5+4+3+2+1=36 levels per >color, or 46,656 possible colors to choose from. Oops, many of those combinations are redundant upon averaging. So you really have less. -- - John Logajan @ Network Systems; 7600 Boone Ave; Brooklyn Park, MN 55428 - logajan@ns.network.com, 612-424-4888, Fax 612-424-2853
ekrimen@ecst.csuchico.edu (Ed Krimen) (04/03/91)
logajan@ns.network.com (John Logajan) writes: - >4) Is it possible to get Gif images to look remotely nice on a STE? - - No. Even ST's in color mode have only 8 shades of grey, and the - STe's have only 16. In high-res mode you just got on or off. I must disagree -- assuming by 'remotely nice' we mean as good as VGA. One may convert GIFs to Spectrum 512 format. Perhaps the best utility for converting them is DIGISPEC, a commercial desk accessory. There are other GIF conversion programs for the ST, but some will not do Spectrum 512 format, and others won't convert to Spectrum 512 as well as Digispec. I think a good comparison is the CLOWN pic: it looks good in VGA, and as good or better in Spec512 format on an ST, IMHO. I agree with John though, in that, if you want a GIF converted to the standard low-res's 16 colors (DEGAS or NEOchrome pic), then it's usually not worth the effort. -- Ed Krimen ............................................... ||| Video Production Major, California State University, Chico ||| INTERNET: ekrimen@ecst.csuchico.edu FREENET: al661 / | \ SysOp, Fuji BBS: 916-894-1261 FIDONET: 1:119/4.0
saj@chinet.chi.il.us (Stephen Jacobs) (04/03/91)
It seemed reasonable to point out here that VGA uses a minimum of (I hope I
have this right) 256 K of screen memory. I'm rather nearer to certain that
most super VGA uses a Meg. This isn't the sort of thing that would have been
considered reasonable when the ST was designed.
Making the display system independent (ala PC) has the advantage of allowing
you to make improvements when technology changes. It has the disadvantage
of causing proliferation of semi-compatible 'standards'. (Look at the
distribution kit of any high-end PC application. There are many screen
drivers.)
Stevelogajan@ns.network.com (John Logajan) (04/04/91)
>>one frame-pixel in one of 8 possible levels. Or one at level 6 and >>the other in 7 possible levels, etc .. 8+7+6+5+4+3+2+1=36 levels per >>color, or 46,656 possible colors to choose from. > >Oops, many of those combinations are redundant upon averaging. >So you really have less. Far less! You get 15 non-redundant intensity levels by swapping two frames. Thus giving you 3375 colors (a subset of which is the 15 shades of grey) to choose from, but you still can only pick from 32 pallette cells per scan line (or zone.) -- - John Logajan @ Network Systems; 7600 Boone Ave; Brooklyn Park, MN 55428 - logajan@ns.network.com, 612-424-4888, Fax 612-424-2853
hyc@hanauma.jpl.nasa.gov (Howard Chu) (04/04/91)
In article <1991Apr3.055519.2322@ns.network.com> logajan@ns.network.com (John Logajan) writes: >hyc@hanauma.jpl.nasa.gov (Howard Chu) writes: >>Well, it's fairly simple to display a full 256-color GIF image, if that's >>what you mean. I have code doing this in my port of Fractint 12. Using >>frame-swapping to (almost) double the number of bits per pixel just about >>squares the number of colors to choose from, and also squares the number >>of colors displayable at once. >I take it by frame swapping that you build two (or more) logical screens >and alternate between them every vertical retrace -- so as to layer >intensities on top of one another. Thus your eye and the persistence >of the phosphors become the brightness integrators. A duty cycle kind >of thing. Let's see per color you have one frame-pixel full on and >one frame-pixel in one of 8 possible levels. Or one at level 6 and >the other in 7 possible levels, etc .. 8+7+6+5+4+3+2+1=36 levels per >color, or 46,656 possible colors to choose from. Hm. I don't quite follow this description. Ok, assume one frame-pixel full-on or full-off, =[0,7] (or [0,15] on the STe). Given equal display time per frame (two frames) this extends the ST palette to an effective 12 bits, or 4096 colors. (Or extends the STe from 4096 to 32768.) Pretty effective, and also surprisingly tolerable. I think this is what the Colorburst 3000 program did. But, this is somewhat wasteful, because this only uses 8 of the 16 available palette registers in the alternate frame. (3 colors, full on or full off, 2**3=8.) > >Hmm, but you still only have 16 pallette cells to choose from per >scan line, and you can only add them and not multiply them. Giving you >32 colors per scan line (or scan zone in Spectrum 512 mode) max. Well, as I mentioned above, you're not realizing the full potential with the scheme you just outlined. Anyway, there are two alternatives, and I've used both in Fractint. First, and most obvious - unbalance the duty cycle. Use two alternating frames, but display one twice as often as the other. This immediately makes all your pixel bits in one frame "more significant" than the other frame. This gives you color levels of 0-7 on one frame, and 0-2-4-6-8-10-12-14 on the other. You now have 22 effective levels per color, or 10648 colors on an ST. (STe - 46 levels, 97336 total colors.) But I think that's a little extreme, it's also really just adding least-significant-bits, so all you're really doing is gaining finer steps between color levels. Oh, for the original poster, this means 22 and 46 gray-levels on ST and STe, respectively, on a color monitor. Now, as to adding and not multiplying colors... Consider these two palette definitions... (Let's use octal, for readability, eh?) Palette 0: {000, 001, 002, 003, 004, 005, 006, 007, 020, 021, 022, 023, 024, 025, 026, 027} Palette 1: {000, 100, 200, 300, 400, 500, 600, 700, 050, 150, 250, 350, 450, 550, 650, 750} By inspection you should be able to satisfy yourself that using these two palettes on two evenly alternating frames, you will be able to use 8 bits per pixel and get 256 unique colors. Your maximum intensity is reduced to half of what it used to be, but the brightness control will fix that. }-) I crippled the green driver arbitrarily, you could decrease the red or blue resolution to suit your taste. This is what you get on a PC with VGA, 3 bits for one color, 3 bits for another, and 2 bits for the last. I don't recall what the 2-bit color on VGA is. At any rate, it covers the full spectrum; there are no color gaps or missing or overemphasized colors in this scheme. [For med-rez, 16 colors, I used {000, 007, 020, 027}, {000, 700, 050, 750}. Note that now two colors are 1-bit each, and one color is 2-bits.] I posted a small archive several months ago (cbox.arc) that demonstrated this setup when I first got Fractint running. It draws 16 horizontal bands on one screen and 16 vertical on another, then just toggles in the two palettes on vertical blank. If you don't have this demo, you can write it yourself based on the description I gave. It will take me at least a week to get to my stuff if I have to repost it, as I no longer have an accessible online copy and I still haven't settled into a place yet, so my STuff is still in storage. > >My guess would be that flicker and pseudo-shadow movements would be >quite severe. So how does it really look? Try it and see, eh? }-) The color scheme I chose above gives the entire 256 color palette of the PC w/VGA. Try other setups.... > >-- >- John Logajan @ Network Systems; 7600 Boone Ave; Brooklyn Park, MN 55428 >- logajan@ns.network.com, 612-424-4888, Fax 612-424-2853 -- -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA Disclaimer: How would I know, I just got here!
Bob_BobR_Retelle@cup.portal.com (04/04/91)
----- Ed Krimen writes: >logajan@ns.network.com (John Logajan) writes: >- >4) Is it possible to get Gif images to look remotely nice on a STE? >- >- No. Even ST's in color mode have only 8 shades of grey, and the >- STe's have only 16. In high-res mode you just got on or off. >I must disagree -- assuming by 'remotely nice' we mean as good as >VGA. One may convert GIFs to Spectrum 512 format. ... Unfortunately, number of colors is only part of the story.. Spectrum 512, while allowing up to 512 colors on the screen, is still limited to low resolution... converting a VGA picture to 320 x 200 resolution usually results in severe loss of detail, and distortion of the aspect ratio of the original. (i.e., pictures come out fuzzy and squashed) DigiSpec does a fairly good job of conversion, but allows no control over aspec ratio... picture of people come out short and fat usually.. the GIF converters that DO allow control over aspect ratio usually end up reducing the picture so much that an extreme amount of detail is lost.. The only GIFs that convert reasonably well to the ST are ones which were 320 x 200 to begin with... and there aren't very many of those any more.. BobR
korpela@stew.ssl.berkeley.edu (Eric J. Korpela) (04/04/91)
In article <1991Apr3.223921.16258@jato.jpl.nasa.gov> hyc@hanauma.jpl.nasa.gov (Howard Chu) writes: > This is what >you get on a PC with VGA, 3 bits for one color, 3 bits for another, >and 2 bits for the last. I don't recall what the 2-bit color on VGA is. >At any rate, it covers the full spectrum; there are no color gaps or >missing or overemphasized colors in this scheme. Are you sure this is how things are done on the VGA? I though that VGA has a palette of 256 colors out of 32K total. In that case the number of bits assigned to each color is really up to the programmer. 32K total colors is 15 bits which turns into 5 bits each of R, G, and B. By appropriate palette choices a programmer could choose to have 5 bits of R and 3 bits of B represented in the byte allocated to each pixel (if he/she so desires.) Because each palette lookup table entry is independent I would think that it would be possible to use 2.67 bits per color rather than the 3,3,2 method you describe. (I, of course, don't mean that literally, but it should be possible to obtain a more even distribution across the spectrum than is possible with the 3,3,2 method). Then again, I don't know all that much about VGA graphics, so I may be wrong about this. /\ korpela@ssl.berkeley.edu Internet /__\ rioch BKYAST::KORPELA 42215::KORPELA DecNet / \ of Chaos korpela%bkyast@ucbjade Bitnet (_____________________ <aka Eric Korpela>
logajan@ns.network.com (John Logajan) (04/04/91)
In article <40852@cup.portal.com> Bob_BobR_Retelle@cup.portal.com writes: >Spectrum 512, while allowing up to 512 colors on the screen, The Spectrum 512 color claim is exceedingly misleading, by the way. Each scan line is broken up into three parts, and each section can use only 16 colors. Or 48 color changes across the screen. A true random 256 color machine can have 256 different colors across one line. A further problem is intensity quantumization. Suppose I have a color with R=5, G=5 and B=1. If I take it down one level, I have R=4, G=4 and B=0!!!! I can't get a lighter shade of the same color!! -- - John Logajan @ Network Systems; 7600 Boone Ave; Brooklyn Park, MN 55428 - logajan@ns.network.com, 612-424-4888, Fax 612-424-2853
kentd@FtCollins.NCR.com (Kent.Dalton) (04/04/91)
>>>>> On 2 Apr 91 08:15:13 GMT, SAMcinty@exua.exeter.ac.uk (Scott McIntyre) said: > > 1) I have a 520 STE (w 4/meg add on)...and the SM 124. I asked a few > weeks ago about graphics on this kind of system, and a number of people > all suggested that I look into GIF stuff...I have been doing so, downloading > dozens at a time from wuarchive, and viewing them on the PC that does the > downloading - they all look brilliant. But when I get them home they look > crap. The SM124 is *true monochrome*, it supports no gray scaling whatsoever. A pixel in a hi-res ST picture is either black or white there is no in between. To some degree this is a feature. Combined with the 70Hz refresh rate and 640x400 resolution the SM124 provides and incredibly solid display for doing serious work. It would be surprising if, say a 320x200 256 color GIF pic, was even recognizable on it, though. There simply are not enough pixels there to dither it properly. I have seen mono GIF viewers that get around this by displaying in a window which can be scrolled, thus allowing better dithering. You might want to look around for such a viewer. > Am I doing something wrong? Not really... but a color display is much much better for viewing GIF pics, even mono GIF pics (see below). > 2) Does the STE have gray scales, you know, proper shades of gray, not > just the nearness of black and white pixels? Yes, 16 in 320x200 mode 4 in 640x200 1 in 640x400 > How can I use these scales? View the picture on a color monitor. > 4) Is it possible to get Gif images to look remotely nice on a STE? Someone else answered your question 'no'. IMHO, this is complete BS. Below is how I typically view GIF pics, usually 320x200 256color images. Many times you can view these with no loss in resolution or clarity: 1. Get GIF pic. 2. Convert to Spectrum 512 format using GIFSPC (<-- available at an archive near you) 3. View the Spectrum pic. (<-- viewers also available at archives) Since you're new to the ST series, I'll tell you what Spectrum 512 format is in case you haven't heard of it: Spectrum 512 picture format uses some software trickery to display more than the maximum 16 colors in 320x200 color mode. It changes the color palette on a per scan line basis with a maximum of three changes per line thus, you can have up to 48 different colors per scan line. This allows creation of pictures which display the entire 512 color palette of the ST on screen simultaneously. I don't know if the extended 4096 colors of the STe are supported but you still shouldn't have any problems using 512 colors. If you try to to view incredibly hi-res pics (ie. 1024x1024 at 16Million colors) they still won't look all that great. GIFSPC can scale the resolution down, however... I have some 640x400 many color pics which look very nice on my ST when converted to Spectrum. -- /**************************************************************************/ /* Kent Dalton * EMail: Kent.Dalton@FtCollins.NCR.COM */ /* NCR Microelectronics * CIS: 72320,3306 */ /* 2001 Danfield Ct. MS470A * */ /* Fort Collins, Colorado 80525 * (303) 223-5100 X-319 */ /**************************************************************************/ Fortune: "Kirk to Enterprise -- beam down yeoman Rand and a six-pack."
Bob_BobR_Retelle@cup.portal.com (04/05/91)
>It seemed reasonable to point out here that VGA uses a minimum of (I hope I >have this right) 256 K of screen memory. I'm rather nearer to certain that >most super VGA uses a Meg. This isn't the sort of thing that would have bee >considered reasonable when the ST was designed. That's very true..! Of course, the ST was designed over *FIVE YEARS* ago, and has never really changed since then.. ( WHY???) An Atari 8-bit screen only took up 8k of RAM... if you want to take it to extremes, an AstroCade only needed 2K to display a full screen.. Why not change with the times..? Why not provide competitive graphics modes..? Why...? BobR
seb3@gte.com (d2eve Belczyk) (04/05/91)
In article <KENTD.91Apr4102750@zappa.FtCollins.NCR.com> kentd@FtCollins.NCR.com (Kent.Dalton) writes: >2. Convert to Spectrum 512 format using GIFSPC (<-- available at an > archive near you) Just a reminder: I'm more than happy to email GIFSPC (and IFFSPC) to anyone without ready FTP access. Steve Belczyk seb3@gte.com
hyc@hanauma.jpl.nasa.gov (Howard Chu) (04/06/91)
In article <40922@cup.portal.com> Bob_BobR_Retelle@cup.portal.com writes: >>It seemed reasonable to point out here that VGA uses a minimum of (I hope I >>have this right) 256 K of screen memory. I'm rather nearer to certain that >>most super VGA uses a Meg. This isn't the sort of thing that would have bee >>considered reasonable when the ST was designed. > >That's very true..! > >Of course, the ST was designed over *FIVE YEARS* ago, and has never really >changed since then.. > > ( WHY???) > > >An Atari 8-bit screen only took up 8k of RAM... if you want to take it to >extremes, an AstroCade only needed 2K to display a full screen.. > >Why not change with the times..? Why not provide competitive graphics >modes..? I think that's a good question... Lessee... Lots of systems out there have 1280x1024 monochrome displays now. There have been 2048x2048 and larger for the military and other applications for a while too. I just wonder - if you can draw 1280x1024 = 1.25Mpixels/frame, 60+ times a second, why can't you do it in color? Doesn't increase the speed requirements, just the width of the bus... I would like to build a true-color board that uses, say, 16 bits per pixel and 8-bit style display lists. Then hardware scrolling in either direction only becomes a matter of updating display list pointers, instead of copying huge amounts of pixel memory. I guess there's not much point to having multiple graphics modes though. (is there?) Lessee, 1.25Mpixels @ 16bits gives 2.5MBytes/screen. Big deal, memory is cheap. We'll say the board has 16MBytes of memory, enough space for 6 screens plus 1MB for display lists and palettes/CLUTs. (Ok, 16MBytes *minimum*.) The display list entries will have to include the address to begin drawing a scanline from. Let's have an optional flag to include palette and address changes at arbitrary pixel counts into the scanline - that gives us the ability to move windows around the screen very rapidly, and allow windows to have their own independent palettes. All of this can be achieved with a simple state-machine, so it should be simple to do quickly in hardware. I was also considering one or two separate bitplanes for text-only, which would be overlayed simultaneously. (Who needs multicolor text anyway, eh?) Haven't given much thought to the text-management though, maybe a separate buffer would be harder to manage than it'd be worth. (But geeze, who wants to waste cycles scrolling 24-bitplanes worth of *text*??) Hm... Is there a practical use for 64K colors out of a larger palette? Mebbe 8 bits per pixel is sufficient, especially given that palettes can be switched on the fly. Mebbe there *is* a reason for multiple modes... Oh well. It seems to me that most of today's workstation vendors spend so much time on how to draw things into their frame buffers, (Oooo, we can do 6 trillion shaded polygons per second!) but no time at all thinking about what they can do with the frame after it's been drawn - no thought spent on panning, zooming, rotation, what-have-you... The display-list idea is incredibly powerful. Have another option for memory-increment to next pixel - this gives you the ability to do instantaneous reductions (zoom-out), as well as 90-degree rotations (corner-turns) just by choosing the appropriate increment. Use another option for pixel-replication, with a count, and you get instant expansion (zoom-in). All of this can be implemented with just an adder/counter circuit and maybe a couple more address registers. Oops. Keyboard run-on again... Well anyway, if I ever get this thing built, I'm sure y'all will find out about it. }-) -- -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA Disclaimer: How would I know, I just got here!
jerry@polygen.uucp (Jerry Shekhel) (04/10/91)
korpela@stew.ssl.berkeley.edu (Eric J. Korpela) writes: > >hyc@hanauma.jpl.nasa.gov (Howard Chu) writes: >> >>This is what >>you get on a PC with VGA, 3 bits for one color, 3 bits for another, >>and 2 bits for the last. I don't recall what the 2-bit color on VGA is. >>At any rate, it covers the full spectrum; there are no color gaps or >>missing or overemphasized colors in this scheme. >> > >Are you sure this is how things are done on the VGA? I though that >VGA has a palette of 256 colors out of 32K total... > You are (wrong about this). VGA simply has 6 bits per primary color, for a total of (2^6)^3 = 262,144 colors, with 256 palette entries. No tricks, no horizontal-sync interrupts, none of that crazy stuff. On a monochrome monitor, you get 64 levels of gray. -- +-------------------+----------------------+---------------------------------+ | JERRY J. SHEKHEL | POLYGEN CORPORATION | When I was young, I had to walk | | Drummers do it... | Waltham, MA USA | to school and back every day -- | | ... In rhythm! | (617) 890-2175 | 20 miles, uphill both ways. | +-------------------+----------------------+---------------------------------+ | ...! [ princeton mit-eddie bu sunne ] !polygen!jerry | | jerry@polygen.com | +----------------------------------------------------------------------------+
logajan@ns.network.com (John Logajan) (04/12/91)
In article <1039@stewart.UUCP> jerry@stewart.UUCP (Jerry Shekhel) writes: >VGA simply has 6 bits per primary color, for >a total of (2^6)^3 = 262,144 colors, with 256 palette entries. No tricks, >no horizontal-sync interrupts, none of that crazy stuff. On a monochrome >monitor, you get 64 levels of gray. Perhaps there is more than one way to VGA. I do know that there are palette chips for sale that include a 256 entry table and three built in DAC's (digital to analog converters). I forget if they had 5 or 6 bits per color though. 5 per would fit in two bytes while 6 per would need three bytes. Oh, and the palette chips claim to be VGA compatible. -- - John Logajan @ Network Systems; 7600 Boone Ave; Brooklyn Park, MN 55428 - logajan@ns.network.com, 612-424-4888, Fax 612-424-2853
wallmann@ipsi.UUCP (Georg Wallmann) (04/15/91)
This comes a little late but...
[In resonse to H.CHus Color graphics board]
I've been thinking about the same thing too, but my calculations
always came up with "too expensive". Of course if you think 16 MB isn't
expensive ... as you do in your post. While thinking about it I
had this great idea for a new RAM technology, which unfortunately
(then unbeknownst to me) already existed as dual-port RAM. Even then the
bus width needed and the cycle speed is just about too ridicolous for
a home computer. Personally I'd be happy with 640*400*16bit colors at
70Hz and some hires in mono. That would be monetarily feasible, I only
want color for the games <slobber> anyway, and some hires for programming.
I as a lowly long-time Atari customer, would indeed be already happy
over some _small_ improvements.
How about Player/Missile Graphics for at least the *&^% mouse cursor,
I can not believe that in the nineties we still got to erase the cursor,
draw something, turn it on again, erase the cursor draw something , turn
it on again (*)
Not neccessarily Atari specific:
Floating point is done in hardware (What %age of the user crowd
actually uses floating points (me NEVER!!) ?), but the stuff you'd
really need is done in software (probably in compiled Alcyon C to boot)
Programs like EZ-draw would definetely profit from a hardwired
draw routine for example. How about a microprogrammable stupid CPU,
that you'd just give instructions like
FOR(;;) ;; this is some mix between
IF IRQ pending ;; english, basic, lisp C and ML
GRAB BYTE from PORT0 ;; lisp for the comments that is
STUFF it into BUFFER at $XXXX ;; har har
IF BUFFERP == full signal IRQ LEVEL 2
CLRIRQ
END
That's basically perfect for sound processing, non DMA I/O processing
and maybe even so stupid tasks as memory initializing. And the 'real'
CPU with it's overkill of registers and cache and what have you
needn't worry about those bothersome context switches for every
*%^$ little interrupt.
Why is everyone so hung up about processor speed ? Sure it's nice that
the compiler does it in 5 minute, if it used to grind for 15 minutes
but chances are that a faster harddisk might be just as profitable
in terms of speed. How often do you compile, aren't you 90% of the time
just typing stuff into an editor ?? Personally I am quite happy even with
a lowly 68000 @ 8Mhz. Yes you speed demons it's allrite for me, IF the
rest of the hardware would do the job, I think a CPU shouldn't do like
graphics, I/O and sound!! My guess it that there just aren't enough
competant people in hardware R&D (anywhere for that matter) to do the
job. So they put in a faster CPU and delegate the rest to a cheesy
graphics card, which virtually does nothing except converting RAM
to colored dots.(the one Intel or TI chip I heard about maybe an exception,
but probably not). Ok this does not neccessarily apply to machines in
scientific environments, where one shittily written application is layered on
top of another (probably in some local LISP dialect) until the processor
croaks.
About every two years it gets to me and I write an article like that,
that's maybe because I would like to buy a computer and don't see
anything I'd like to buy. (Well that ST Notebook sounds tempting,
got yet to see one though...) thanks to the readers of comp.sys.atari.st
for taking it with some humor and letting the old man ramble on
a bit.
bye y'all
Nat!
(*)Probably the Amiga does that rightwarwick@cs.uq.oz.au (Warwick Allison) (04/16/91)
>How about Player/Missile Graphics for at least the *&^% mouse cursor, >I can not believe that in the nineties we still got to erase the cursor, >draw something, turn it on again, erase the cursor draw something , turn >it on again (*) : >(*)Probably the Amiga does that right I can not believe that in the nineties there are STILL people who want hardware to provide anything but the bare essentials. Hardware sprites are just crap. How many do you want? 16 enough? 256? and how shall you allocate them to processes? They would be just another pain-in-the-neck limited resource. But faster you say? Maybe in the old days of 8-bit computers they were worthwhile: when the processors were slow and the graphics was poor quality anyway. "at least [for] the [fucking] mouse cursor" you say? Yeah, sure, then EVERY game every made would use the mouse pointer as a sprite, sending mouse motion packets to the OS to make it mouse. Hey, great! :-) Ciao, Warwick. ps. Why do we whinge so much about our machines? From the crap PD stuff I've seen around, and the crap commercial stuff, Atari users need to learn a bit of computer science before they cry to the designers about missing features. Personally, I think the ST is a fine machine. -- _--_|\ warwick@cs.uq.oz.au / * <-- Computer Science Department, \_.--._/ University of Queensland, v AUSTRALIA.
bgr@uncle-bens.rice.edu (Robert G. Rhode) (04/17/91)
In article <1991Apr16.192259.4357@rice.edu>, bgr@uncle-bens.rice.edu (Robert G. Rhode) writes: > In article <1563@ipsi.UUCP>, wallmann@ipsi.UUCP (Georg Wallmann) writes: > > > always came up with "too expensive". Of course if you think 16 MB isn't > > expensive ... as you do in your post. While thinking about it I > > had this great idea for a new RAM technology, which unfortunately > > (then unbeknownst to me) already existed as dual-port RAM. Even then the > > bus width needed and the cycle speed is just about too ridicolous for > > a home computer. Personally I'd be happy with 640*400*16bit colors at > > 70Hz and some hires in mono. That would be monetarily feasible, I only > > want color for the games <slobber> anyway, and some hires for programming. > > I think I can (theoretically) offer you a better deal: > > How about 1024x1024x24-bit color for <$350 parts cost (if you are an OEM)... > > Ingredients: > 24 1-Megabit Video Rams @ ~$12 each => 3 MB > 1 Brooktree triple 8-bit RAMDAC @ ~@50 > glue logic > > 1024x1024x70 Hz = 110 MHz pixel clock. > Each VRAM is 256Kx4, so each VRAM needs to output at 27.5 MHz. > A 100-ns VRAM is rated to shift out serial information at the rate of 33 MHz. > 1 VRAM chip per bitplane. > > A VRAM is a dual-ported RAM with a DRAM half and a serial shift register half. > The two halves are completely independent of one another except when passing data > between them. 512 bits (1 DRAM row) is transferred at a time. > > Anyway, I am currently doing a theoretical video board design for a senior EE class, > and I assure you that the performance you require is not at all unreasonable in cost. > > - Bob > Silly me, I forgot to tell it the right distribution. By the way, that should say Brooktree VideoDAC, not RAMDAC. A RAMDAC is what you use when you want to have a 256-color lookup table for 8-bit graphics. The Bt459 RAMDAC has a 256x24 lookup table for color information, 16x24 overlay color lookup table for easy text-over-graphics or windowing applications, and even a 64x64x3-color cursor in hardware (For those of you who want a sprite). I hope this reaches more than just me this time...
wallmann@ipsi.UUCP (Georg Wallmann) (04/22/91)
In article <1991Apr16.211304.6829@rice.edu> bgr@uncle-bens.rice.edu (Robert G. Rhode) writes: >In article <1991Apr16.192259.4357@rice.edu>, bgr@uncle-bens.rice.edu (Robert G. Rhode) writes: >> In article <1563@ipsi.UUCP>, wallmann@ipsi.UUCP (Georg Wallmann) writes: >> >> > always came up with "too expensive". Of course if you think 16 MB isn't >> > expensive ... as you do in your post. While thinking about it I >> > had this great idea for a new RAM technology, which unfortunately >> > (then unbeknownst to me) already existed as dual-port RAM. Even then the >> > bus width needed and the cycle speed is just about too ridicolous for >> > [deleted] >> I think I can (theoretically) offer you a better deal: >> >> How about 1024x1024x24-bit color for <$350 parts cost (if you are an OEM)... >> >> Ingredients: >> 24 1-Megabit Video Rams @ ~$12 each => 3 MB >> 1 Brooktree triple 8-bit RAMDAC @ ~@50 >> glue logic >> > >I hope this reaches more than just me this time... Sure did... Your graphics board sounds quite good, even for twice the price, but what H.Chu and I were talking about was some sort of graphip coprocessor like the old 8-Bit ANTIC. ANTIC provided control over the vertical arrangement of the screen (where to get the memory from and to display in what resolution). I figured that a coprocessor that also tried to control the horizontal arrangement (as great as that would be) would be much to costly in terms of bus speed. Otherwise you'd need to restrict the number of windows displayable pretty severely. As to the guy, who responded saying that hardware cursors were bullshit in the nineties. We 'discussed' this offline and I just want to state that a) I am not convinced that hardware cursors are useless b) questioning my CS knowledge was maybe a bit hasty Anyway. I have seen a couple of adds now in various journals about note book computers. I thought that the Atari notebook was doing handwriting recognition, or am I wrong on that ? Most of the other notebooks don't seem to be able to do that. Nat! Email: XBR1DE7B@DDATHD21.BITNET (only this address)