c164-1bj@cordelia.berkeley.edu (Jonathan Dubman) (10/25/87)
*** Remarks and Questions on the Future of Amiga Video Output ***
I suspect before Christmas we will see the enhanced graphics chipset for the
A500 and A2000 - in fact, they are probably up and running now at Commodore,
but employees are not allowed to discuss them. (In fact, maybe several
versions are running, and Commodore hasn't decided which one to release -
more advanced ones may alienate A1000 owners, etc...) Pure speculation, mind
you.
In any case, it is inevitable that sooner or later we will see the following:
1. Increased number of bitplanes. The graphics library is completely
flexible in this regard - so flexible that one suspects they had
eight bitplanes in mind back in 1984. This could include
a. Anywhere from six to eight bitplanes in lo-res.
(I KNOW getting six bits out of memory is possible -
all we then need is twice as many color registers, which
is easily done with probably minor modifications to the
original chips. I don't know the specifics of the timing,
but I'll bet eight bit planes is not out of the question)
(Anyone know a theoretical limit with the current hardware?)
b. Increased number of bitplanes in hi-res. Maybe five.
We've got a taste of this with HAM mode and IT LOOKS GREAT!
Compares favorably to Mac II's 256 colors out of a bigger palette.
2. Increased number of colors in the palette - instead of four bits
per red, green, or blue
a. maybe five, giving 819,200 colors
b. or six, giving 262,144 colors
c. or even eight, giving 16,277,216 like the Mac II
I am not a hardware expert, but I believe ALL IT TAKES IS:
a. increased number of bits in each color register - circuit
complexity goes up pretty linearly, I think, with the number
of bits per color register, and those chips are nowhere
near maximum density available with current technology
b. fancy 8-bit digital-to-analog converters for the video
output - a nice one maybe costs $20 (haven't checked the
back of BYTE recently.)
Oh yeah, we'll have to spiff up the copper throughput a little,
but the whole system is running at under 8 MhZ, so we have
oodles of time. Two things make it tough: processor speed
(fast processor wants more out of chip memory) and horizontal
resolution.
3. Increased resolution.
First of all, if you want this, start placing the ad for the
1080 monitor, and open that big window it is going to go
out of.
a. 768x512 - minimum increased resolution, for power-of-two
freaks. This is really not enough of an increase to merit
the trouble - unless, of course, it were FLICKER FREE, as it
would be (I believe) on a multiscan monitor.
Long persistence monitors with interlace are for the
extinct birds.
b. 1024x800 - workstation market starts visiting Amiga
dealers. Blitter is getting really taxed moving those
windows around. (Why not have a whole bunch of them
running in parallel - hee hee) With the great text output
we start getting here, desktop publishing on the Amiga
might really take off - ESPECIALLY if Amiga beats Apple to
the color printing market! (They had better hurry up
now that the Mac II is out.) (Amiga has a big lead with
video, but will increased resolution help? Increased
palette will. Maybe with high-density TV...)
c. 1024x1024 - workstation market - CAD/CAM, etc., starts
buying Amigas - especially if they run UN*X. Amiga is not
really a serious competitor with Sun and Apollo and Mac II
in this regard, because 640x200 is too small and 640x400 is
borderline but there are display problems.
d. 2048x2048... let's not get carried away.
So we have three categories (at least) where graphics can grow:
1. Bits per pixel
2. Colors in palette
3. Resolution
and maybe
4. Amount of chip memory
(Should really be software selectable - yes - that's tough)
KEY QUESTIONS:
0. What would be the effect on sprites with all this?
1. How much can we get away with using the existing motherboards of
the A500 and A2000?
2. How much can we get away with using the video slot of the A2000?
3. What should be standard video on the A3000? What we have will not
do - it's amazing technology for 1985 but competitors are improving
and we are not. (yet.)
4. How general is the current OS, really?
5. How general do we want the operating system to be? Mac OS has
pretty generalized graphics output - a really cute trick is that -
since they have only one "screen" - you can ask for whatever color
you want and the OS will give the CLOSEST color in the palette.
6. How much can we fiddle with AmigaDOS for version 2.0 and remain
reasonably compatible with the current crop of software?
(Stuff like Marble Madness that takes over the machine doesn't
count. Don't buy the Amiga 5000 and expect to play Marble Madness.)
7. What is the optimum getup - increase the resolution, decrease the
speed... How many colors and what resolution do we need to
look lifelike? (Let's not stop with TV quality!)
8. What about multiple output devices running simultaneously?
9. What is the future of display technology?
What the heck goes in that VIDEO SLOT anway, is what *I* want to know...
Also: What's the deal with these frame buffers that third-party companies are
working on?
Also: What ever happened to the 1024x800 monochrome graphics chip that Dale
Luck showed at a meeting a while back?
Also: Anybody know what Adobe (The PostScript people) have brewing for their
generalized screen-description language? Are they working with Apple? How
general is ScreenScript?
One of the reasons I enjoy doing this is that I know the Commodore employees
read the net - and they listen! Remember the 1.2 discussion a little over a
year ago - all the bug reports, suggestions, etc.? Just try posting some
suggestions to comp.sys.ibm...
*&Jonathan Dubman
Overworked Berkeley CS student with Semantic Analyzer AND
Real Analysis midterm on Wednesday.
/
\/ ONE MORE VOTE FOR ANIMATED ICONS IN 1.3
As part of the legal accepted future "enhanced workbench"
environment...
Has anyone else had this idea? It would be real cute... Little
mini-versions of the program - Leo would have a great time - just have
a HyperGadget with a pointer to an animation function... Optional
of co MUZZU!!schein@cbmvax.UUCP (Dan Schein CATS) (10/26/87)
In article <4579@zen.berkeley.edu> c164-1bj@cordelia.berkeley.edu (Jonathan Dubman) writes: > > *** Remarks and Questions on the Future of Amiga Video Output *** > (Gotta keep those net GODS happy by placing text on the alter.) (IE: I deleated alot!) > > >KEY QUESTIONS: > >What the heck goes in that VIDEO SLOT anway, is what *I* want to know... ^^^^^ anyway? Hmmm 2 things that Commodore has shown using the video slot included, a GenLock card, and a combo GenLock - FrameGrabber card. Both of these were shown in public and at several shows (like NCGA, & COMDEX). -- Dan Schein uucp: {ihnp4|rutgers}!cbmvax!schein Commodore Business Machines or: {allegra|burdvax}!cbmvax!schein 1200 Wilson Drive Bix: dschein Plink: cbmtelecom West Chester PA 19380 phone: (215) 431-9100 ext. 9542 +----------------------------------------------------------------------------+ All spelling mistakes are a result of my efforts to avoid education :-) +----------------------------------------------------------------------------+ Those who worked the hardest are the last to surrender -- Gary Ward
kent@xanth.UUCP (Kent Paul Dolan) (10/27/87)
[see reference for context - surely you read it!] Please, please, PLEASE, not EIGHT bits per pixel, OK? Six is good, nine is great(!), but eight means that all my software to divide up the color palatte nicely is a mess. Can't we give each gun the same number of bits of resolution? Since we give each bit plane its own portion of memory anyway, there is no reason to aim at fitting the bits in a pixel per byte. In 1978, the last time I bought a high end workstation (a few RAMTEKs, if you're curious) the state of the art in color look-up tables was 11 bits in, and they were straining really hard to get to twelve. Nine doesn't seem like it should be much of a challenge 9 years later. It may require interleaved memory access from the video side; I don't know enough about the hardware to do the calculations. On the output side, the only limitation seems to be what you want to support in the way of D/A video-speed converters. Eight bit ones have obviously been around for a long time, or 24 bit frame buffers would be a joke. Are they very expensive? Peace. Kent, the man from xanth. Strange netperson. Multiple parent. Divorcing. Retiree. Sailor, diver. Curmudgeon extraordinary. Madman relinquished by the state. Half-hearted presidential candidate, fulminating for a human presence in space. Sometime graphics programmer, mostly unemployable. Most dangerous counter-flamer in the entire known universe. Just generally a nice guy, overflowing with human kindness and lust.
dlleigh@mit-amt.MEDIA.MIT.EDU (Darren L. Leigh) (10/28/87)
In article <2987@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes: >Please, please, PLEASE, not EIGHT bits per pixel, OK? Six is good, >nine is great(!), but eight means that all my software to divide up >the color palatte nicely is a mess. Can't we give each gun the same >number of bits of resolution? Well, Kent, if six bits per pixel will satisfy you, then there should be no problem with eight. You can use the six for graphics and the two left-overs for overlay planes. You just need a little self-control to keep from using all those extra colors. :-) Personally, my dream machine would be 32 bits/pixel. That's 24 bits mapped directly to the guns for super-realistic pictures and eight bits worth of overlay attached to a 24 bit wide color table. Then all I want is a super-computer to do the calculations and a single-frame video recorder . . . ============================================================================= Darren Leigh Have you hugged your id today? 362 Memorial Dr. Cambridge, MA 02139 dlleigh@media-lab.mit.edu
brianop@well.UUCP (10/28/87)
I suspect Commodore should wait until the next-generation tv standard dust settles before latching onto a higher res screen. Whatever they do for the next generation computer should be displayable on the next generation TV. -- ------------------------------------------------------------------- What the eye beholds CI$ MCI: 72406.1363 And the heart covets, BIX PLINK: Brianop Let the hand boldly seize!. USENET: well!brianop
grr@cbmvax.UUCP (10/28/87)
In article <2987@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes: > > [see reference for context - surely you read it!] > > Please, please, PLEASE, not EIGHT bits per pixel, OK? Six is good, > nine is great(!), but eight means that all my software to divide up > the color palatte nicely is a mess. Can't we give each gun the same > number of bits of resolution? Since we give each bit plane its own > portion of memory anyway, there is no reason to aim at fitting the > bits in a pixel per byte. In 1978, the last time I bought a high end > workstation (a few RAMTEKs, if you're curious) the state of the art in > color look-up tables was 11 bits in, and they were straining really > hard to get to twelve. Nine doesn't seem like it should be much of a > challenge 9 years later. It may require interleaved memory access > from the video side; I don't know enough about the hardware to do the > calculations. Hmmm, you seem to trying to ignore the color lookup table for a direct relationship of bitplanes to color guns. The current Amiga bus would let you fetch 8 bit planes, adding that 9'th would require doubling the bandwidth. If at sometime we give you 8, we'll let you use 6 if you want 8-). Sure, when cost is no object as in a high-end graphics terminal you can have all the bit planes you want, however the essense of the affordable* Amiga was compromising features with what could be reasonably integrated into the basic chipset. * affordable - the A1000 was an end-product of the Amiga development effort, not neccessarily the cost target the chipset was designed for. > On the output side, the only limitation seems to be what you want to > support in the way of D/A video-speed converters. Eight bit ones have > obviously been around for a long time, or 24 bit frame buffers would > be a joke. Are they very expensive? Well, at least several times more expensive than the implementation in the A1000 or A500. All that nice Brooktree stuff is rather expensive, the Inmos parts begin somewhat more reasonable. -- George Robbins - now working for, uucp: {ihnp4|rutgers|allegra}!cbmvax!grr but no way officially representing arpa: out to lunch... Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
miner@dino.cpe.ulowell.edu (Rich Miner) (10/28/87)
In article <2987@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes: >>Please, please, PLEASE, not EIGHT bits per pixel, OK? Six is good, >nine is great(!) >Nine doesn't seem like it should be much of a challenge 9 years later. The main problem is things like: struct BitMap {... UBYTE depth...} also in RastPort definitions etc. This is no reason not to go higher then eight, but it will be a lot more work to do so. If someone gives you eight, just use 6 of them if you want, use the other two for overlays. -- Rich miner@ulowell.edu 617/452-5000x2693 ULowell CPE Imaging Research Lab
peter@dalcsug.UUCP (10/28/87)
In article <2607@cbmvax.UUCP> schein@cbmvax.UUCP (Dan Schein CATS) writes: >In article <4579@zen.berkeley.edu> c164-1bj@cordelia.berkeley.edu (Jonathan Dubman) writes: >>What the heck goes in that VIDEO SLOT anway, is what *I* want to know... > ^^^^^ anyway? > > Hmmm 2 things that Commodore has shown using the video slot included, > a GenLock card, and a combo GenLock - FrameGrabber card. Both of these > were shown in public and at several shows (like NCGA, & COMDEX). I thought that the composite video adapter went in this slot. (??) If this is true, how does one get composite video if you also want to use a genlock, etc... My dealer also told me that the composite adapter was not available yet. Is this just a CBM Canada condition? So much for buying an A2000 for video production! > Dan Schein uucp: {ihnp4|rutgers}!cbmvax!schein Peter Philip
keithd@cadovax.UUCP (10/28/87)
In article <2987@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes: >Please, please, PLEASE, not EIGHT bits per pixel, OK? Six is good, >nine is great(!), but eight means that all my software to divide up >the color palatte nicely is a mess. Can't we give each gun the same >number of bits of resolution? Since we give each bit plane its own >portion of memory anyway, there is no reason to aim at fitting the >bits in a pixel per byte. Now wait a minute. By this logic, right now we have 4 bits per 'gun' totalling 12 bits. The number of bit planes has no correspondence to the resolution per gun, when you have a lookup table in between. A lookup table allows you to re-arrange the colors so bits out of bytes or words don't correspond to n-bits of red, n-bits of blue etc. Even if you had 9 bits per pixel, you can't count on your palette being organized in any useful way if it's totally programmable and your software is at all flexible. Look what they did with VideoScape-3D, they fixed the palette! Is that what you are proposing that programs do? Bah! Flexible programs will work with WHATEVER palette you choose to configure. That's what I want to see, not ones that impose a fixed palette when I have hardware lookup on the machine. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
page@ulowell.UUCP (10/28/87)
brianop@well.UUCP (Brian McBee) wrote: >Commodore should wait [for] next-generation tv ... the next >generation computer should be displayable on the next generation TV. Foo. Shouldn't they also wait for the 50MHz 68030? You can't engineer for the future and get the thing to market. People need solutions *now*, so they should provide them *rsn*. Besides, it looks very likely that no HDTV will be OK'd by the FCC unless it's backwards compatible with existing NTSC ... that is of course unless they pull another VCR or 4-channel hifi audio scam (what about stereo AM?) and "let the market decide." ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.{uucp,edu,csnet}
banzai@pixar.UUCP (Eric Herrmann) (10/29/87)
In article <1692@mit-amt.MEDIA.MIT.EDU> dlleigh@media-lab.MEDIA.MIT.EDU (Darren L. Leigh) writes: >Personally, my dream machine would be 32 bits/pixel. That's 24 bits >mapped directly to the guns for super-realistic pictures and eight >bits worth of overlay attached to a 24 bit wide color table. > >Then all I want is a super-computer to do the calculations and a >single-frame video recorder . . . (-: (-: (-: (-: (-: (-: (-: (-: (-: (-: (-: (-: (-: (-: (-: (-: (-: (-: (-: (-: Of course, there's the Pixar, which has 12 bits per channel plus alpha, for a grand total of 48 bits per pixel. (Realistically, it can only display 10 bits of the 12 of RGB, so you get 2^30 possible colors.) A mere 40 MIPS per processor, max of 4 processors, so 160 MIPS total possible. And you can change the output video format to NTSC, for your video transfers... And so cheap, too, only $49,000! :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) > Darren Leigh Have you hugged your id today? -- ------------------------------------------------------------------------------- Night flights on a music ship, leaving on a never-ending trip Just say YES! Eric Herrmann {ucbvax,sun}!pixar!banzai
schein@cbmvax.UUCP (Dan Schein CATS) (10/29/87)
In article <171@dalcsug.UUCP> peter@dalcsug.UUCP (Peter Philip) writes: >In article <2607@cbmvax.UUCP> schein@cbmvax.UUCP (Dan Schein CATS) writes: >>In article <4579@zen.berkeley.edu> c164-1bj@cordelia.berkeley.edu (Jonathan Dubman) writes: >>>What the heck goes in that VIDEO SLOT anway, is what *I* want to know... >> ^^^^^ anyway? >> >> Hmmm 2 things that Commodore has shown using the video slot included, >> a GenLock card, and a combo GenLock - FrameGrabber card. Both of these >> were shown in public and at several shows (like NCGA, & COMDEX). > >I thought that the composite video adapter went in this slot. (??) >If this is true, how does one get composite video if you also want to >use a genlock, etc... > The genlock has composite video output (& input) built in. After all this is how most folks get the genlocked video to their vcr's :-) >My dealer also told me that the composite adapter was not available yet. >Is this just a CBM Canada condition? >So much for buying an A2000 for video production! > Not having any information on Amiga products and Canada (excet Bob & Doug McKinsey (sp?)), I can't say if it a Canadian condition or not - eh! But if you are refering to the A520 video adapter - then it *is* an American condition also - eh! (I have to stop watching STRANGE BREW - eh! :-) >> Dan Schein uucp: {ihnp4|rutgers}!cbmvax!schein > >Peter Philip -- Dan Schein uucp: {ihnp4|rutgers}!cbmvax!schein Commodore Business Machines or: {allegra|burdvax}!cbmvax!schein 1200 Wilson Drive Bix: dschein Plink: cbmtelecom West Chester PA 19380 phone: (215) 431-9100 ext. 9542 +----------------------------------------------------------------------------+ All spelling mistakes are a result of my efforts to avoid education :-) +----------------------------------------------------------------------------+ Those who worked the hardest are the last to surrender -- Gary Ward
daveh@cbmvax.UUCP (Dave Haynie) (10/30/87)
in article <171@dalcsug.UUCP>, peter@dalcsug.UUCP (Peter Philip) says: > > In article <2607@cbmvax.UUCP> schein@cbmvax.UUCP (Dan Schein CATS) writes: >> Hmmm 2 things that Commodore has shown using the video slot included, >> a GenLock card, and a combo GenLock - FrameGrabber card. Both of these >> were shown in public and at several shows (like NCGA, & COMDEX). > > I thought that the composite video adapter went in this slot. (??) > If this is true, how does one get composite video if you also want to > use a genlock, etc... EVERY GenLock I've seen so far also generates color composite video. If you think about it, it really has to. Since what the Genlock is really doing is taking external composite video, syncing and mixing the Amiga's video with that external source, and then pumping that video out. But where is out? It certainly can't go back into the Amiga's video outputs, so it must have outputs of its own. The Amiga 2000 GenLock device (fits inside the box in the video slot) and the Mimetics GenLock device both generate composite video. The Amiga 2000 device isn't out just yet; I don't know the schedule. I think the Mimetics device is already shipping. > > Peter Philip -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The B2000 Guy" PLINK : D-DAVE H BIX : hazy "Computers are what happen when you give up sleeping" - I LW staty ph
stever@videovax.UUCP (10/31/87)
In article <1908@ulowell.cs.ulowell.edu>, Bob Page (page@swan.ulowell.edu) writes: > . . . > Besides, it looks very likely that no HDTV will be OK'd by the > FCC unless it's backwards compatible with existing NTSC ... This won't be much of a problem. When television was developed, all receiver functions had to be performed by 25 to 50 active devices (which at that time came in glass bottles). Now a memory chip with over a million active devices is in the neighborhood of $20 and takes up 0.5 square inches. Manufacturers will invest the few hundred thousand active devices (and the extra $10) needed to ensure that all HDTV sets (at least the ones sold in this country) will be NTSC compatible. Steve Rice ----------------------------------------------------------------------------- new: stever@videovax.tv.Tek.com old: {decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever
peter@sugar.UUCP (10/31/87)
In article <1779@dino.cpe.ulowell.edu>, miner@dino.cpe.ulowell.edu (Rich Miner) writes: > >Nine doesn't seem like it should be much of a challenge 9 years later. > The main problem is things like: struct BitMap {... UBYTE depth...} also > in RastPort definitions etc. Why is this a problem? Depth is the number of planes, not the number of colors... you can fit up to 255 planes in a UBYTE. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (11/01/87)
> >Nine doesn't seem like it should be much of a challenge 9 years later. > The main problem is things like: struct BitMap {... UBYTE depth...} also > in RastPort definitions etc. The only real problem is that the array used to hold pointers to each plane of the bitmap is static.... only 8 entries. Most of the other structures can handle up to 16 bit planes. -Matt