youngdahl@gacvx1.gac.edu (01/19/91)
Well, it seems everyone agrees that at least in LIMITED usage, it is possible to display 32 colors on at least a few IIgs scan lines by switching the pallette and pixels on a scan line after the SCB interupt is generated, and before the screen is refreshed. Why do I think this is useful? Well, its obvious that this does nothing practical for the IIgs, as it cannot be done on the whole screen as the "3200" mode. But at least it COULD be used in a title page to a program (or such) for a row of text... maybe you could shade the letters from left to right, going through red-->blue using 32 colors?? You'd flip between: (First half of text in colors 1-16/1st pallette) w/ the second group of letters not "in" the scan line's bytes -and- the first half of the text not in the scan line's bytes and the second group of letters in colors 1-16/2nd pallette) I know... its limited... but I'm just wondering if this could be done with minimal flickering. Also, since I'm just talking about "tweeking" the heck out of the graphics right now, perhaps some of you have could tell me if this is possible: Mixing 640 and 320 on a scan line. By changing the contents of a scanline and changing its scanline control byte from "320" to "640," couldn't one "overlay" 640 mode 80-column text onto a background of 320-mode graphics (i.e. the advantage of 16 colors) on at least a 1/10 of the screen? Any comments? Ben Youngdahl youngdah@nic.gac.edu
seah@ee.rochester.edu (David Seah) (01/20/91)
In article <14908@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >This discussion reminds me to ask that IIGS developers who decide to >use scan-line interrupts PLEASE code to accommodate Apple's Video >Overlay Card as well as the stock IIGS. Failure to do so has made >essentially all available 3200-color demo programs unusable for >people using the VOC. Thanks! Not having a VOC myself, what is it about this board that messes up 3200 color demos? -- Dave Seah ^..^ | Analog Design Automation Research Group - Graphics & GUI | | University of Rochester, Dept. of Electrical Engineering | ////// Internet: seah@ee.rochester.edu ////// America Online: AFC DaveS //////
ifar355@ccwf.cc.utexas.edu (David H. Huang) (01/22/91)
In article <35978@netnews.upenn.edu> tyler@eniac.seas.upenn.edu (Tyler W Phillips) writes: > > Why does the alternating colors only yield 32 total. You (meaning an >uninformed you) would think that you could make any combination of 2 colors >which would yield 15! (In other words, a lot) colors. > >P.S. I think this would look great with a Zip or Transwarp > >tyler@eniac.seas.upenn.edu 15! would be a combination of 15 different colors, not 2. BTW, my trusty HP sez that 15!=1.307674368E12. That would be a lot of colors :-) There would only be 32 different colors since gray 4 and gray 6 will make gray 5, which already exists. The possible intensities from this method are 0, 0.5, 1, 1.5, ..., 14.5, and 15. Hmmm... I guess that only makes 31 grey levels... Also, I don't think a Zip or a Transwarp would make much of a difference in terms of the picture quality... the screen can only be refreshed 60 times a second. -- David Huang | Internet: ifar355@ccwf.cc.utexas.edu | "My ganglion is stuck in UUCP: ...!ut-emx!ccwf.cc.utexas.edu!ifar355 | a piece of chewing gum!" America Online: DrWho29 |
gwyn@smoke.brl.mil (Doug Gwyn) (01/22/91)
In article <1991Jan20.112227.10202@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >Doug, they don't know HOW to do it. The VOC runs asynchronously to the >motherboard (so it can genlock) and all we can get from the VOC itself is >a precious few bytes of hardware registers. Currently I only know how to >poll it for VOC VBL. I could have sworn that the docs (VOC Developer's Kit from APDA) said that there was a separate scan-line interrupt available for the VOC. I'll try to figure this all out and post more info at some point.
gwyn@smoke.brl.mil (Doug Gwyn) (01/22/91)
In article <1991Jan20.123430.7039@ee.rochester.edu> seah@ee.rochester.edu (David Seah) writes: >Not having a VOC myself, what is it about this board that messes up >3200 color demos? Basically, in order to synchronize with an external video source, it provides a duplicate IIGS video subsystem that is not synchronized to the one on the motherboard. Unfortunately the existing 3200-color demos use the motherboard clock-based signals to coordinate their updates of scan-line control bytes during the painting of the image. The effect is that the VOC is using the wrong SCB information since it is updated out of sync with the VOC scanning.
tyler@eniac.seas.upenn.edu (Tyler W Phillips) (01/22/91)
In article <42874@ut-emx.uucp> ifar355@ccwf.cc.utexas.edu (David H. Huang) writes: >In article <35978@netnews.upenn.edu> tyler@eniac.seas.upenn.edu (Tyler W Phillips) writes: >> >> Why does the alternating colors only yield 32 total. You (meaning an >>uninformed you) would think that you could make any combination of 2 colors >>which would yield 15! (In other words, a lot) colors. >> >>P.S. I think this would look great with a Zip or Transwarp >> >>tyler@eniac.seas.upenn.edu > >15! would be a combination of 15 different colors, not 2. BTW, my trusty HP >sez that 15!=1.307674368E12. That would be a lot of colors :-) > >There would only be 32 different colors since gray 4 and gray 6 will make >gray 5, which already exists. The possible intensities from this method are >0, 0.5, 1, 1.5, ..., 14.5, and 15. Hmmm... I guess that only makes 31 grey >levels... > >Also, I don't think a Zip or a Transwarp would make much of a difference >in terms of the picture quality... the screen can only be refreshed 60 times >a second. > > >-- >David Huang | >Internet: ifar355@ccwf.cc.utexas.edu | "My ganglion is stuck in >UUCP: ...!ut-emx!ccwf.cc.utexas.edu!ifar355 | a piece of chewing gum!" >America Online: DrWho29 | Granted, my math was a little off, but what I meant was to mix colors in this fashion, not gray levels. I would think that that would theoretically give you 120 colors per scan line (16 x 15 / 2). I would also think that an accellerator would be very useful in keeping up with all 120 colors (especially if the 120 colors are different on each scan line = 120 x 200 = 24,000 colors (although many would probably be indistinguishable)) although it would probably not be enough anyway. tyler@eniac.seas.upenn.edu P.S. I could be wrong.
youngdahl@gacvx1.gac.edu (01/22/91)
Ok... now I get the idea that everyone agrees that by alternating pallettes and partial scan lines we could achieve a very flickering illusion of 32 colors on a scan line. Now, a few questions: If the screen refesh rate was 1/30th of a second, how much would this flicker? I've seen an Amiga in interlace mode many a time. Would this flicker more than an Amiga flickers in interlace mode on a cheap monitor? How about the number of scanlines that could be completely rewritten before the screen catches up to it on a standard IIgs? Ben Youngdahl youngdah@nic.gac.edu
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (01/23/91)
gwyn@smoke.brl.mil (Doug Gwyn) writes: >I could have sworn that the docs (VOC Developer's Kit from APDA) said >that there was a separate scan-line interrupt available for the VOC. That's my suspicion. I'm pretty sure I know which bit it is, too: when I was playing with the VOC registers to find the interlace controls, I discovered that setting one of the bits would cause a bizarre crash/beep behavior. I believe that this is because no one claimed the interrupt -- but then there should have been a monitor crash (I was doing this without GS/OS loaded), and there wasn't. I'll look into it when I get the bordercolor clock init working. Todd Whitesel toddpw @ tybalt.caltech.edu
keen@ee.ualberta.ca (Jeff '876393' Keen) (01/24/91)
In article <14923@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <1991Jan20.123430.7039@ee.rochester.edu> seah@ee.rochester.edu (David Seah) writes: >>Not having a VOC myself, what is it about this board that messes up >>3200 color demos? > >Basically, in order to synchronize with an external video source, it >provides a duplicate IIGS video subsystem that is not synchronized to >the one on the motherboard. Unfortunately the existing 3200-color >demos use the motherboard clock-based signals to coordinate their >updates of scan-line control bytes during the painting of the image. >The effect is that the VOC is using the wrong SCB information since >it is updated out of sync with the VOC scanning. -- ----------------------------------------------------- Jeff Keen University of Alberta keen@bode@alberta -----------------------------------------------------
keen@ee.ualberta.ca (Jeff '876393' Keen) (01/24/91)
In article <14923@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <1991Jan20.123430.7039@ee.rochester.edu> seah@ee.rochester.edu (David Seah) writes: >>Not having a VOC myself, what is it about this board that messes up >>3200 color demos? > >Basically, in order to synchronize with an external video source, it >provides a duplicate IIGS video subsystem that is not synchronized to >the one on the motherboard. Unfortunately the existing 3200-color >demos use the motherboard clock-based signals to coordinate their >updates of scan-line control bytes during the painting of the image. >The effect is that the VOC is using the wrong SCB information since >it is updated out of sync with the VOC scanning. One thing you may want to try is to plug the composite video output into the VOC so it is synched with the computer. This may correct the problem but I don't have a VOC so I can't tell. If reconectting cables isn't what you desire add a video switching unit so you can switch between video to be overlayed and the computers composite output. This is assuming the VOC synchs to composite video not a single wire synch signal used in production houses. -- ----------------------------------------------------- Jeff Keen University of Alberta keen@bode@alberta -----------------------------------------------------
gwyn@smoke.brl.mil (Doug Gwyn) (01/24/91)
In article <1991Jan21.235524.1@gacvx1.gac.edu> youngdahl@gacvx1.gac.edu writes: >Ok... now I get the idea that everyone agrees that by alternating pallettes and >partial scan lines we could achieve a very flickering illusion of 32 colors on >a scan line. Now, a few questions: >If the screen refesh rate was 1/30th of a second, how much would this flicker? >I've seen an Amiga in interlace mode many a time. Would this flicker more than >an Amiga flickers in interlace mode on a cheap monitor? >How about the number of scanlines that could be completely rewritten before the >screen catches up to it on a standard IIgs? I don't quite understand why you ask this. The 3200-color demos manage to keep the SCBs updated (barely) faster than the scanning rate. "Flicker" as you call it (usually called "tearing") would occur only if you couldn't update the SCBs fast enough. Obviously if you set up a backing array for the SCB data, it could be rolled into the actual SCBs at a sufficient rate to keep up with display scanning.
gwyn@smoke.brl.mil (Doug Gwyn) (01/24/91)
In article <1991Jan23.174647.1393@ee.ualberta.ca> keen@ee.ualberta.ca (Jeff '876393' Keen) writes: >One thing you may want to try is to plug the composite video output into >the VOC so it is synched with the computer. Hey, nice idea, I'll have to try that. Thanks! >assuming the VOC synchs to composite video not a single wire synch signal Yes, that's what it does. In the absence of a good RS-170 signal it reverts to an internal clock.
araftis@polyslo.CalPoly.EDU (Alex Raftis) (01/25/91)
In article <14955@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <1991Jan21.235524.1@gacvx1.gac.edu> youngdahl@gacvx1.gac.edu writes: >>Ok... now I get the idea that ... >> ... >> > >I don't quite understand why you ask this. The 3200-color demos manage to >keep the SCBs updated (barely) faster than the scanning rate. "Flicker" >as you call it (usually called "tearing") would occur only if you couldn't >update the SCBs fast enough. Obviously if you set up a backing array for >the SCB data, it could be rolled into the actual SCBs at a sufficient rate >to keep up with display scanning. Does it actaully take up _so_ much CPU time. I was hacking around with some simple assembly, and I made a program to attempt to change the color of pixel as the scan line went accross the screen. By the looks of things, I could change things fast enough, but I had no way of timming the updates, so the colors scrolled on the screen. Someone better at assembly might be able to rig up some kind of timing to get this to work, though I can't see how considering interrupts make software timers un-reliable. -- -------------------------------------------------- Internet: araftis@polyslo.CalPoly.EDU America Online: xela (Real Life: Alex Raftis)
ifar355@ccwf.cc.utexas.edu (David H. Huang) (01/25/91)
In article <14955@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <1991Jan21.235524.1@gacvx1.gac.edu> youngdahl@gacvx1.gac.edu writes: > >I don't quite understand why you ask this. The 3200-color demos manage to >keep the SCBs updated (barely) faster than the scanning rate. "Flicker" >as you call it (usually called "tearing") would occur only if you couldn't >update the SCBs fast enough. Obviously if you set up a backing array for >the SCB data, it could be rolled into the actual SCBs at a sufficient rate >to keep up with display scanning. But, 3200 color pictures are switching the same palettes in for a certain scan-line. What he was asking was having two different palettes on a scan line so they would blend into an intermediate color. The flicker is slightly worse than an Amiga in interlace mode, but it might not be as noticable if the colors that you are blending are close to each other (in color) -- David Huang | Internet: ifar355@ccwf.cc.utexas.edu | "My ganglion is stuck in UUCP: ...!ut-emx!ccwf.cc.utexas.edu!ifar355 | a piece of chewing gum!" America Online: DrWho29 |
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (01/25/91)
araftis@polyslo.CalPoly.EDU (Alex Raftis) writes: >Does it actaully take up _so_ much CPU time. Yes. SCBs are not the problem, just one byte per line. Palettes are the problem. 32 bytes per line, every line. >assembly might be able to rig up some kind of timing to get this to >work, though I can't see how considering interrupts make software timers >un-reliable. Because an interrupt inserts an unknown time delay in between two instructions whenever one occurs. If you are trying to create a 50 microsecond delay and you allow interrupts to be serviced, your delay will be a heck of a lot longer than 50 microseconds if an interrupt occurs in the middle of it. Example: border color stuff -- suppose I have a program that looks at the position of the video beam and creates a delay so that a given instruction will be executed when the video beam reaches a specific position. If an interrupt comes in and gets control, when it returns the delay subroutine doesn't know it has happened -- there is no way to correct for the effect because most interrupts will take longer than the maximum delay you intended to create -- meaning that you will "miss" your target and the border color picture will be drawn further down on the screen, and at some random position. This effect is similar to what happens if you run BGSound with a song and view something with View3200. Todd Whitesel toddpw @ tybalt.caltech.edu