Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ico!ism780c!wilbur!scott From: scott@wilbur.uucp (Scott Beckstead) Newsgroups: comp.sys.amiga.hardware Subject: Re: (Non) Square Pixels? Message-ID: <1990Feb14.205629.16840@wilbur.uucp> Date: 14 Feb 90 20:56:29 GMT References: <4687@lmrc.uucp> <3119@cello.UUCP> <4736@lmrc.uucp> <3053@d75.UUCP> <7217@netcom.UUCP> Reply-To: scott@wilbur.UUCP (Scott Beckstead) Organization: Wilbur's Bike Shop, Westlake Village, Ca Lines: 386 In article <7217@netcom.UUCP> hue@netcom.UUCP (Jonathan Hue) writes: >>>In article <3119@cello.UUCP>, robin@sabre.uucp (Robin D. Wilson/1000000) writes: >>>> Most monitors (and TV's do not have "square" pixels. Most have round or oval >>>> shaped pixels. In fact, the only monitors that I know to have square pixels > >CRTs don't have pixels, frame buffers do. If I have a three tube camera >displaying its picture on a television, there aren't any pixels. Pixel stands >for picture element. In this case the picture has neither been quantized >nor sampled, so how can there be picture elements? > >The useful parameters about a monitor are bandwidth, pitch, horizontal scan >rate, and vertical retrace rate. The number of pixels in either dimension >is not meaningful as it depends on the device driving it, although recently >monitor vendors have been adding an x by y resolution spec in their literature, >mainly to help non-technical customers figure out whether or not a monitor will >work with their frame buffer. > >For example, when I worked at JVC (the inventors of the multiple scan rate >monitor, by the way) we had a monitor with 125MHz bandwidth, which could sync >to horizontal scan rates from 31.5KHz to 75KHz. The typical frame buffer >that drove it with a 31.5KHz horizontal scan rate was 640x480, at 75KHz >it was 1280x1024. I guarantee you that we did not make the phosphor dots >("pixels", by your definition) shrink to half their size when we did this. > > >>>> are the high-end Sony's similar to the one Apple uses for the MacII. (The >>>> Apple color monitor for the MacII is a modified Sony.) > >The Sony Trinitron CRT uses vertical metal strips for the mask, stabilized by >two (faintly visible) horizontal wires, and a vertical stripe phosphor. If >you are going to call these "pixels" (which nobody does), then the pixels are >rectangles as they are the entire height of the screen. > >When the phosphor is illuminated by the electron beam, it does not expose a >single stripe or single phosphor dot. The spot size of the beam is usually >larger than the pitch of the tube, meaning the beam shines through multiple >openings in the mask, so multiple stripes or spots are exposed. BTW, the >profile of the electron beam strength across its diameter approximates a >Gaussian distribution. > > >>Also, on my NEC 3D there is an adjustment to increase the distance between the >>pixels from right to left (thus making the screen wider, and changing the >>aspect ratio from that perspective) and another adjustment that changes the >>ratio from top to bottom. It sure helps me to get a 1 to 1 aspect ratio on my >>stuff. (I'm not sure how NEC does this, but I think it may have something to >>do with changing the shape of the tension masks.) > >This is plainly ridiculous. The phosphor on the screen is carefully aligned >with the electron guns through the mask, usually by applying the phosphor to >the tube with a photoresist, and exposing the tube through the mask from a >light source located where the guns normally are. If the geometry of the mask >was somehow changed, this alignment would be lost and it would be impossible to >display a color picture. > >The only think the mask does is expand slightly due to heating caused by the >electron beam. On some monitors the mask frame is held in place by bimetallic >clamps, which moves the mask toward the tube face as it heats up. This keeps >the mask and phosphor aligned during changes in temperature. > >All that the knobs on the NEC do is decrease the current through the >deflection coils, which reduces strength of the magnetic field applied across >the yoke of the tube. This slows the beam deflection rate across the face of >tube and causes a smaller area of the CRT to be exposed. A Commodore 1084S >can do this. > >Followups to alt.stupidity. > >-Jonathan FLAME ON!!!!!!!!!!!!!!!!!!!!!!!!!!! Look, I don't mind being told that I am ignorant of the facts. I do mind being called stupid because I'm ignorant of the facts. In line with my previous article about this subject I'll keep this short. I suppose you would call any one who doesn't speak english stupid? Well I hope you like being called stupid by any one in a country who's language you don't happen to speak. This kind of attitude speaks of a far more dangerous prejudice (read Intellectual bigot). FLAME OFF!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Thank you for the explanation from those of us who never happened to work for a CRT or TV manufacturer. It does clear up some of the questions that have been raised here. In the future could you please provide the info with a little less rightous indignation. Scott Beckstead Followup-To: Distribution: Organization: Wilbur's Bike Shop, Westlake Village, Ca Keywords: Newsgroups: comp.sys.amiga,comp.sys.amiga.tech Subject: Re: CSA Accelerator Summary: Expires: References: <4098@rayssdb.ray.com> <1285@marlin.NOSC.MIL> Sender: Reply-To: scott@wilbur.UUCP (Scott Beckstead) Followup-To: Distribution: Organization: Wilbur's Bike Shop, Westlake Village, Ca Keywords: Accelerator, custom chip I happen to be the proud owner of the original CSA 68020 accelerator card serial number 2. However I happen to also be the not so proud owner of a Starboard II 2meg/multifunction card. The problem is that the Starboard II refuses to work correctly with the CSA board. I have contacted both companies and what I get from CSA is that they have tried to get Microbotics to work with them to fix the problem and have given up after several years of trying the story I get from Microbotics is that once you install the '020 in the AMIGA it is no longer an AMIGA and they will not be responsible for the consequences of my actions. No help is forthcoming from Microbotics and the fixes recomended by CSA don't quite work (minor improvement but not full function) Since I use my A1000 for video (3d rendering etc.) I need the speed increase provided by the 68020 and I need the ram afforded by the Starboard. I think that Microbotics attitude is deplorable and have resolved not to buy any more products made by this comapny (please feel free to join the boycott) however much satisfaction that this gives me it does not solve my problem. If anybody out there can help me I would appreciate it greatly. Scott Beckstead scott@wilbur.uucp (sorry all the address I have on the net) Or Scott Beckstead @ 206/2814 (Fidonet) From: scott@wilbur.uucp (Scott Beckstead) Path: wilbur!scott Newsgroups: comp.sys.amiga,comp.sys.amiga.tech Subject: Re: CSA Accelerator References: <4098@rayssdb.ray.com> <1285@marlin.NOSC.MIL> Reply-To: scott@wilbur.UUCP (Scott Beckstead) Organization: Wilbur's Bike Shop, Westlake Village, Ca Keywords: Accelerator, custom chip I happen to be the proud owner of the original CSA 68020 accelerator card serial number 2. However I happen to also be the not so proud owner of a Starboard II 2meg/multifunction card. The problem is that the Starboard II refuses to work correctly with the CSA board. I have contacted both companies and what I get from CSA is that they have tried to get Microbotics to work with them to fix the problem and have given up after several years of trying the story I get from Microbotics is that once you install the '020 in the AMIGA it is no longer an AMIGA and they will not be responsible for the consequences of my actions. No help is forthcoming from Microbotics and the fixes recomended by CSA don't quite work (minor improvement but not full function) Since I use my A1000 for video (3d rendering etc.) I need the speed increase provided by the 68020 and I need the ram afforded by the Starboard. I think that Microbotics attitude is deplorable and have resolved not to buy any more products made by this comapny (please feel free to join the boycott) however much satisfaction that this gives me it does not solve my problem. If anybody out there can help me I would appreciate it greatly. Scott Beckstead scott@wilbur.uucp (sorry all the address I have on the net) Or Scott Beckstead @ 206/2814 (Fidonet) Newsgroups: comp.sys.amiga Subject: Re: PAL grounding? Summary: Expires: References: <1990Jan13.033100.14807@wam.umd.edu> Sender: Reply-To: scott@wilbur.UUCP (Scott Beckstead) Followup-To: Distribution: comp.sys.amiga Organization: Wilbur's Bike Shop, Westlake Village, Ca Keywords: PAL In article <1990Jan13.033100.14807@wam.umd.edu> walrus@cscwam.umd.edu (Udo Karl Schuermann) writes: > >Hi net! > >I've heard so much about grounding the PALs but have never quite >understood what the deal is. Things I would really like to know: > > 1. WHY? Do ungrounded PALs cause problems? dangers? > The only problem I've ever had was with this Missile Command > game: the bonus ship was a full-screen height random-bits > mess. Worked fine with my roommates' A1000 and they didn't > make any mods (theirs are vintage '85 while mine is about a > year older). > 2. How easy is it to do? Can a non-EE person recognize the > chip(s) and do the job without blowing the A1000's brains > out? > 3. Where can I get the necessary information to do the job? > >I've got an unmodified A1000, no extrahalfbright. So far, the only >expansion on my bus is a 2.5M Starboard II. I'm thinking of getting >the SCSI module and putting a decent sized HD on it. Will THAT cause >problems without grounding? > >Thanks for any help!! > >Please respond via email. If there is interest, I'll summarize to >the net. > >Udo Schuermann >walrus@cscwam.umd.edu >.signature coming real soon now >-- >Udo Schuermann "There is hopeful symbolism in the fact >walrus@cscwam.umd.edu that flags do not wave in a vacuum." >x2215 -- Arthur C. Clarke Newsgroups: comp.sys.amiga,rec.games.video Subject: Re: The Lynx CPU (???) (Was:Re: Developing for the Lynx) Summary: Expires: References: <8581@cbnewsm.ATT.COM> <759@cs.wmich.edu> <7243@lindy.Stanford.EDU> <4952@sugar.hackercorp.com> <19142@bellcore.bellcore.com> <4960@sugar.hackercorp.com> Sender: Reply-To: scott@wilbur.UUCP (Scott Beckstead) Followup-To: Distribution: usa Organization: Wilbur's Bike Shop, Westlake Village, Ca Keywords: ========================================================================== | In Vino Veritas--- In wine there is truth. | | Is somehwat disappointing compared to: | Scott Beckstead | In Veritas VINO-- In truth there IS WINE | CIS 76106,3720 | Made it up this morning I did. | FIDO 1:206/2814 | Not responsible for miss-spellings | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Newsgroups: comp.sys.amiga,rec.games.video Subject: Re: The Lynx CPU (???) (Was:Re: Developing for the Lynx) Summary: Expires: References: <8581@cbnewsm.ATT.COM> <759@cs.wmich.edu> <7243@lindy.Stanford.EDU> <4952@sugar.hackercorp.com> <19142@bellcore.bellcore.com> <4960@sugar.hackercorp.com> Sender: Reply-To: scott@wilbur.UUCP (Scott Beckstead) Followup-To: Distribution: usa Organization: Wilbur's Bike Shop, Westlake Village, Ca Keywords: In article <4960@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes: >In article <19142@bellcore.bellcore.com> sdh@flash.UUCP (Stephen D Hawley) writes: >>You have recognized this, but went swinging out into >>space in your fury. > >Hardly fury. > >Hey, I could program an 1802 with toggle switches and get it to do something >more or less useful. That doesn't mean I want to. > >I acheived a near maximum guhuri level on the 6502, IIMSSM. At one point on >the Apple ][+ I had hacked up a two-user Forth environment with a tree- >structured filesystem and multiple assembly tasks running under a realtime >exec, and the code in that exec was damn near optimal. Oh yeah, I wrote >some massively hacked bit-blit routines, too. (Yuck, this all keeps coming >back) a-and my own loop-while-speaker-toggling sound-playing routines that I >tuned up with a strobotuner. > >My point is that *I've been there.* > >And I'm not going back. > >I finally learned the futility of trying to reinvent the wheel without >massive resources. On the Apple that was more like "invent the wheel," >'cuz most of that stuff wasn't available. But on the Amiga, I have all >these guys at Commodore (and elsewhere) writing that stuff for me. > >Tree-structured filesystem. Realtime exec. Bit-blit routines. > >Yep, it's all there, plus groovy stuff like C compilers, sample-playing >hardware, audio.device, serial.device, BitBltMapRastPort or whatever it is, >the blitter, windows, screens, fonts, fish disks, IFF (!) &c &c &c > >If you choose to develop for the Lynx, you are choosing to assume some >major burdens, to wit: small developer community, little "garage" >development (high entry price); you'll be insular (little free code) and poorly >supported. > >Good luck, and this is *not* a flame. It's just that *I* want more of an >environment and ever-higher performance, not less, so I see moving towards >(Indeed I am already there) protected-mode 32-bit systems adhering to >open systems standards (Unix) on the one hand, and realtime multitasking on >an affordable machine, hopefully on the same hand, but if not, as for now, >on the other hand, i.e. the Amiga. > >-- >-- uunet!sugar!karl "It takes a smart man to know when he's stupid." >-- -- Barney Rubble >-- Usenet access: (713) 438-5018 Newsgroups: Comp.sys.amiga Subject: Re: (Non) Square Pixels? Summary: Expires: References: <4687@lmrc.uucp> <3119@cello.UUCP> <4736@lmrc.uucp> <3053@d75.UUCP> <7217@netcom.UUCP> Sender: Reply-To: scott@wilbur.UUCP (Scott Beckstead) Followup-To: Distribution: Organization: Wilbur's Bike Shop, Westlake Village, Ca Keywords: In article <7217@netcom.UUCP> hue@netcom.UUCP (Jonathan Hue) writes: >>>In article <3119@cello.UUCP>, robin@sabre.uucp (Robin D. Wilson/1000000) writes: >>>> Most monitors (and TV's do not have "square" pixels. Most have round or oval >>>> shaped pixels. In fact, the only monitors that I know to have square pixels > >CRTs don't have pixels, frame buffers do. If I have a three tube camera >displaying its picture on a television, there aren't any pixels. Pixel stands >for picture element. In this case the picture has neither been quantized >nor sampled, so how can there be picture elements? > >The useful parameters about a monitor are bandwidth, pitch, horizontal scan >rate, and vertical retrace rate. The number of pixels in either dimension >is not meaningful as it depends on the device driving it, although recently >monitor vendors have been adding an x by y resolution spec in their literature, >mainly to help non-technical customers figure out whether or not a monitor will >work with their frame buffer. > >For example, when I worked at JVC (the inventors of the multiple scan rate >monitor, by the way) we had a monitor with 125MHz bandwidth, which could sync >to horizontal scan rates from 31.5KHz to 75KHz. The typical frame buffer >that drove it with a 31.5KHz horizontal scan rate was 640x480, at 75KHz >it was 1280x1024. I guarantee you that we did not make the phosphor dots >("pixels", by your definition) shrink to half their size when we did this. > > >>>> are the high-end Sony's similar to the one Apple uses for the MacII. (The >>>> Apple color monitor for the MacII is a modified Sony.) > >The Sony Trinitron CRT uses vertical metal strips for the mask, stabilized by >two (faintly visible) horizontal wires, and a vertical stripe phosphor. If >you are going to call these "pixels" (which nobody does), then the pixels are >rectangles as they are the entire height of the screen. > >When the phosphor is illuminated by the electron beam, it does not expose a >single stripe or single phosphor dot. The spot size of the beam is usually >larger than the pitch of the tube, meaning the beam shines through multiple >openings in the mask, so multiple stripes or spots are exposed. BTW, the >profile of the electron beam strength across its diameter approximates a >Gaussian distribution. > > >>Also, on my NEC 3D there is an adjustment to increase the distance between the >>pixels from right to left (thus making the screen wider, and changing the >>aspect ratio from that perspective) and another adjustment that changes the >>ratio from top to bottom. It sure helps me to get a 1 to 1 aspect ratio on my >>stuff. (I'm not sure how NEC does this, but I think it may have something to >>do with changing the shape of the tension masks.) > >This is plainly ridiculous. The phosphor on the screen is carefully aligned >with the electron guns through the mask, usually by applying the phosphor to >the tube with a photoresist, and exposing the tube through the mask from a >light source located where the guns normally are. If the geometry of the mask >was somehow changed, this alignment would be lost and it would be impossible to >display a color picture. > >The only think the mask does is expand slightly due to heating caused by the >electron beam. On some monitors the mask frame is held in place by bimetallic >clamps, which moves the mask toward the tube face as it heats up. This keeps >the mask and phosphor aligned during changes in temperature. > >All that the knobs on the NEC do is decrease the current through the >deflection coils, which reduces strength of the magnetic field applied across >the yoke of the tube. This slows the beam deflection rate across the face of >tube and causes a smaller area of the CRT to be exposed. A Commodore 1084S >can do this. > >Followups to alt.stupidity. > >-Jonathan FLAME ON!!!!!!!!!!!!!!!!!!!!!!!!!!! Look, I don't mind being told that I am ignorant of the facts. I do mind being called stupid because I'm ignorant of the facts. In line with my previous article about this subject I'll keep this short. I suppose you would call any one who doesn't speak english stupid? Well I hope you like being called stupid by any one in a country who's language you don't happen to speak. This kind of attitude speaks of a far more dangerous prejudice (read Intellectual bigot). FLAME OFF!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Thank you for the explanation from those of us who never happened to work for a CRT or TV manufacturer. It does clear up some of the questions that have been raised here. In the future could you please provide the info with a little less rightous indignation. Scott Beckstead -- Scott Beckstead | Sew Crates was a grate greek. CIS 76106,3720 | Dang that one got right by the spelling checker FIDO 1:206/2814 | don't look at me YOU wrote it!