dca@edison.UUCP (David C. Albrecht) (07/25/86)
I have had my Amiga since May and in general I am pretty happy with it. I do find the flicker in high-res annoying about and I would have been much happier if they had based the OS on UNIX (a mini version of course) instead of yet another half-assed dos. I'm also not too impressed that every piece of software I have bought so far (except Lattice C) is copy protected so installing them in a RAM disk or putting them on a hard disk is not an option. Well, all of this is pretty much water over the bridge. The flicker problem is annoying because most software I have seen ignores the high-res mode. The ones that don't ignore it ala. dpaint don't use it to any great degree (they don't supply and I have yet to see a high-res painting). I'm interested in doing a feasability study on circuitry to suppress the flicker. I am not an electronics expert by any means but I have enough knowledge to at least not be too intimidated. I realise one solution to the problem is a high persistence phosphor monitor but as they are quite expensive a circuit approach might be just as cost effective and possibly have other benefits such as a possibility of reducing the load on the processor. Also, prices on monitors have been dropping relatively slowly compared to prices on semi-conductors thus a circuit solution can't help but look even better as time goes by. As I understand it the flicker is caused by the interlaced display which updates alternate scan lines at a 1/60 sec rate with a total update at a 1/30 sec rate. With high contrast material this causes noticable flicker. As the memory is running flat out during the display period just doing screen updates processor cycles have to slip through the cracks. Therefore, a 1/60 non-interlaced display rate would require not only a faster graphics chip but also faster memory. It seems that one solution is a scan converter which will change the interlaced mode to a non-interlaced mode that updates at the required 1/60 of sec. As I still have some warranty left on my machine, I am not prepared to open it up so have been left to reading the Hardware reference manual which doesn't get down to the nuts and bolts level. From my reading, however, I noticed that one of the custom chips has 3 4-bit (R-G-B) outputs. My surmise at this point is that these outputs are the results of the video sweep. I would expect that these outputs then travel to the monitor drive circuitry. It should be possible to capture this output in video DRAMs ala. the TI dual port chip and save an entire screen (both scans). Mind you, we are not talking a small amount of memory, I figure in the 200K bytes neighborhood (Horz res * Lines on screen * 12 bits plus some for overscan). As I understand it the NTSC can't accept a 1/60 sec full screen sweep so the capture (of the interlaced) and re-insertion point (of the non-interlaced) signal would have to be in the RGB circuitry. The $64,000 question is if I break the link in the RGB circuitry and somehow arrange that it re-injects a non-interlaced 1/60sec update sweep from the serial port on the Video rams; does the output network have the capability to accept what is effectively a doubling in output bandwidth (especially the RGB D/As)? If we get a 1/60sec full screen update does the Amiga monitor have the bandwidth to accept it? Rather than completely wasting the redundancy of this double buffering for only flicker filtering it would be very desirable if it could serve duty to offload the Amiga somewhat. Given that I could suppress the Amiga's video sweep somehow from add on circuitry (a feat I don't know is possible or desirable given that it might upset timing based on the screen sweep), best would be if I could suppress the Amiga video sweep until a change was affected in the screen contents. It is highly unlikely, however, that I can capture this information. More likely to be feasible is to suppress the Amiga's sweep for some time period. A convenient time period measure is the number of screen cycles. A counter on the add on circuitry could suppress the video update for a variable number of screen cycles. In other words, I would delay a display update from actually reaching the screen by some multiple of 1/60 of a sec and in return would get less load on the Amiga's memory. If possible I would want the number of cycles to suppress the video sweep to be a register just like the ones in the custom VLSI and accessable as such. Hopefully, setting the register would be ignored on a 'stock' Amiga. In this way an application could vary the amount of cycles available to the processor versa how fast a feedback response is needed from the screen. To maintain compatibility with an NTSC output an externally accessable switch keeping the board from disabling the video sweep despite the counter register setting would also be handy. All this is just speculation but I am interested in the input of those more knowledgeable on electronics, video drivers, and amiga software/hardware in adding their two cents as to feasability, implementation, and possible alternate approaches. David Albrecht
mitsu@well.UUCP (Mitsuharu Hadeishi) (07/28/86)
High persistence RGB monitors should be coming down in price in about a year. The only real difference between the two is demand; since the Amiga came out, there is a much bigger market now for HP RGB, so the price should drop. The ONLY difference between HP RGB and LP RGB is the phosphor; that amounts to only a few dollars in materials. All RGB monitors were hugely expensive until this year; now it's only LP RGBs that are hugely expensive; I have it on good rumor that LP RGBs will be down around $500 sometime next year. -Mitsu (mitsu@well.UUCP)
rick@mips.UUCP (Rick Frazier) (07/28/86)
> I'm interested in doing a feasability study on circuitry > to suppress the flicker. I am not an electronics > expert by any means but I have enough knowledge to at least > not be too intimidated. > > I realise one solution to the problem is a high persistence > phosphor monitor but as they are quite expensive a circuit > approach might be just as cost effective and possibly have > other benefits such as a possibility of reducing the load > on the processor. Also, prices on monitors have been > dropping relatively slowly compared to prices on semi-conductors > thus a circuit solution can't help but look even better > as time goes by. > > It seems that one solution is a scan converter which > will change the interlaced mode to a non-interlaced mode that > updates at the required 1/60 of sec. As I still have some > warranty left on my machine, I am not prepared to open it up > so have been left to reading the Hardware reference manual > which doesn't get down to the nuts and bolts level. > > From my reading, however, I noticed that one of the custom > chips has 3 4-bit (R-G-B) outputs. My surmise at this point > is that these outputs are the results of the video sweep. > I would expect that these outputs then travel to the > monitor drive circuitry. It should be possible > to capture this output in video DRAMs ala. the TI dual > port chip and save an entire screen (both scans). > have to be in the RGB circuitry. The $64,000 question is if > I break the link in the RGB circuitry and somehow arrange that > it re-injects a non-interlaced 1/60sec update sweep from the > serial port on the Video rams; does the output network have the > capability to accept what is effectively a doubling in output bandwidth > (especially the RGB D/As)? If we get a 1/60sec full screen > update does the Amiga monitor have the bandwidth to accept it? > > All this is just speculation but I am interested in the input of > those more knowledgeable on electronics, video drivers, and amiga > software/hardware in adding their two cents as to feasability, implementation, > and possible alternate approaches. > I have been working with graphics systems for some time, and though the things you propose are "possible" they may not be desirable. In the "old days" we used to get rid of the flicker on high-res (1024x1024) displays in a manner not too different than you describe (but monochrome). There are, however, a few limitations: 1) the monitor (in it's present state) would not have the ability to go that fast! You would need a monitor with TWICE the scan rate, and proportionately higher video bandwidth. 2) the Amiga monitor is and ANALOG input device, so you would need to have a D-to-A in your circuitry as well, if you COULD get the monitor to go faster. (I know this is no big deal as you could use a couple of HC244's and some resistors to sum the signals into a transistor like the folks at Amiga did). If you had a sufficiently high bandwidth monitor around, you could do an external frame buffer to save the alternating fields at the "each half per 1/60th second" they come out and send them on to a 60 frame per second monitor, but the cost of the external ram and state machine to make it all work would end up costing you more than the high persistence monitor, unless you were really into high volume production. If you don't already have the high speed monitor, you'd have to spend far more for the fast unit than a long persistence one. (The Amiga monitor, like most alternate field monitors or tv-similar timed devices, gets it's "doubled" resolution by starting the second field 1/2 of a line thickness down from the "normal" first line. Television was the first commercially produced consumer device to do this, Any beginning tv service or tv fundamentals book at your local library can give you the details. It's assumption is that the adjacent pixels are not of wide contrast levels like we so often see in high-res text applications, etc.) Don't give up on getting something to work for you, It's the people that wouldn't accept what they had that made products like the Amiga a reality. Keep thinking.....Maybe you'll find something that others have either overlooked or just had to discard in the fight to make a product as cost effective as possible. -- --Rick Frazier-- DISCLAIMER: The above is individual opinion (the result of my imperfect recall of facts, real or imagined) in no way representing anyone else. UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!rick DDD: 408-720-1700 x278
stever@videovax.UUCP (Steven E. Rice) (07/31/86)
In article <829@edison.UUCP>, David C. Albrecht (dca@edison.UUCP) writes: > . . . > Well, all of this is pretty much water over the bridge. The > flicker problem is annoying . . . > I realise one solution to the problem is a high persistence > phosphor monitor but as they are quite expensive a circuit > approach might be just as cost effective and possibly have > other benefits such as a possibility of reducing the load > on the processor. Also, prices on monitors have been > dropping relatively slowly compared to prices on semi-conductors > thus a circuit solution can't help but look even better > as time goes by. > > As I understand it the flicker is caused by the interlaced > display which updates alternate scan lines at a 1/60 sec rate > with a total update at a 1/30 sec rate. With high contrast > material this causes noticable flicker. As the memory is > running flat out during the display period just doing screen > updates processor cycles have to slip through the cracks. > Therefore, a 1/60 non-interlaced display rate would require not > only a faster graphics chip but also faster memory. It would also require a significantly higher-priced monitor!! Scanning the CRT at twice the rate of a standard monitor requires quite a bit more power for the deflection circuits, and beefier electronics for the drive. In addition, the bandwidth of the video amplifier has to double. All this will come in time (and money. . .). Steve Rice ---------------------------------------------------------------------------- {decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever
gnu@hoptoad.uucp (John Gilmore) (08/04/86)
In article <829@edison.UUCP>, dca@edison.UUCP (David C. Albrecht) writes: > I have had my Amiga since May... > I'm interested in doing a feasability study on circuitry > to suppress the flicker... ...As the memory is > running flat out during the display period just doing screen > updates processor cycles have to slip through the cracks. > Therefore, a 1/60 non-interlaced display rate would require not > only a faster graphics chip but also faster memory... > It should be possible > to capture this [video] output in video DRAMs... David, you are absolutely right. Video RAMs are the obvious technical solution -- they give the CPU all your memory bandwidth and let you run the monitor at damn near any scan rate it can handle. Unfortunately, Amiga did not built in the video RAMs, nor did they provide you with a monitor that can handle a fast scan rate. Retrofitting them is more trouble than it's worth. Get a long persistence monitor and wait for the Amiga ][. PS: If it's any consolation, I tried to talk Atari into using video rams for their next products and I don't think *they* will either. (Something about them costing a few cents more than regular rams.) -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa May the Source be with you!
mfo@rayssd.UUCP (Miguel F. Oyarzun) (08/10/86)
*** REPLACE THIS LINE WITH YOUR MESSAGE ***
mfo@rayssd.UUCP (Miguel F. Oyarzun) (08/10/86)
Many people have (and will continue to) offer the Long Persitence Monitor option as a solution to the hi-res flicker problem. One potential problem with this approach is that animation applications might require faster phosphor response to prevent blurring. In this context, I suspect many users (myself included) would welcome alternate hardware solutions. In the meantime, I have found that by reducing the brightness and contrast on the 1080 Amiga Monitor, hi-res flicker can be reduced considerably. I have successfully used this approach to generatee BW slides using DeuxePaint in hi-res mode with 1 bit plane. Miguel Oyarzun
mfo@rayssd.UUCP (Miguel F. Oyarzun) (08/10/86)
Many people have (and will continue to) offer the Long Persistence Monitor option as a solution to the hi-res flicker problem. One potential problem with this approach is that animation applications may require faster phosphor response to prevent image blurring. Thus I suspect many users (myself included) would welcome alternate solutions (I don't really want tohave to carry tow monitors). In the meantime I have found that reducing the brightness and contrast on the 1080 Amiga Monitor goes a long ways towards reducing hi-res flicker in certain applications. I have successfully used this approach to generate BW slides using DeluxePaint in hi-res mode with a single bit plane. Miguel Oyarzun Raytheon Submarine Signal Division Portsmouth, RI PS: Dave (Albrecht), I'm pulling for yyou.
mfo@rayssd.UUCP (Miguel F. Oyarzun) (08/11/86)
Perhaps the quickest (and also dirtiest) solution (as many have already suggested) to the interlaced-flicker problem is to shell out the extra cash for the long-persistence monitor. One potential problem with this approach is that animation applications might require faster phosphor response to prevent image blurring. Thus many users (myself included) would welcome alternate solutions (I don't really want to have to carry two monitors). I think that this is an area where someone with a unique perspective on the problem could jump in and make a significant contribution (and a few bucks too). In the meantime, reducing the brightness and contrast on the 1080 Amiga Monitor can go a long way towards reducing hi-res flicker in certain applications. I have successfully used this approach to generate BW slides using DeluxePaing in the hi-res mode with a single bit plane. Miguel Oyarzun PS: May the force be with you Dave (Albrecht).