le 13/06/04 22:21, Jeff Walther � [EMAIL PROTECTED] a �crit�: >> From: "J Mood" <[EMAIL PROTECTED]> >> Date: Sun, 13 Jun 2004 14:05:24 -0400 > > At 14:51 -0500 06/13/2004, Jeff Walther wrote: >> From: Compact Macs [mailto:[EMAIL PROTECTED] Behalf Of >>> Daniel Daplincourt >>> Sent: Sunday, June 13, 2004 11:35 AM > >>> On the site of Gamba is described the manner of giving 256 levels of gray to >>> a SE30. There, I see the photo of the necessary piece in order to make it. >>> This piece is very difficult to find. Is this possible of her to manufacture >>> oneself? Does someone possess the schema in order to achieve the >>> installation? Could someone draw this schematic drawing? Thank you >>> beforehand. >>> Daniel :-) > >> The device your talking about involves a few dozen IC's. I strongly doubt >> that all of these parts are still available, some of them are likely >> proprietary ICs and programmable logic manufactured exclusively by Micron. > > I suspect that Daniel lacks a crucial piece of information. It took > me a little while to figure this out upon viewing Gamba's site. > > The card which Gamba built is not sufficient to achieve 256 levels of gray. > > His card is an accessory to the Micron Exceed video card which can be > installed in the SE/30. So, in order to achieve 256 levels of gray > one would need both a Micron Exceed video card which is very > expensive and rare, and one of the cards which Gamba built which is > moderately expensive but available, assuming anyone ever hears from > Gamba again. Both cards are necessary. > >> The schematic for this setup is not publicly available, you would need a >> reverse-engineered schematic and knowledge of PC board layout tools to re-do >> the board layout and have it manufactured. > > There were/are schematics of the Micron card kicking around. > Someone was selling them on Ebay. A couple of the list members were > kind enough to send me the copies which they obtained because I have > some experience at designing and having built printed circuit boards. > However, the schematics are not sufficient. > > As James surmises, one of the chips is a custom integrated circuit > designed by Micron and never available to the general public, > although one of the list members seems to have obtained a handful of > the left over chips. > > Unfortunately, there are also a few other chips on board which are > Programmable Logic Arrays (actually PALs) and these contain custom > programming which can not be read out directly. It might be > possible to determine the contents by analyzing the behaviour. But > that would require obtaining a working copy of the card, removing the > chips in question, without damaging them and then analyzing them. > >> None of these tasks are impossible, but it may almost be easier to redesign >> the unit from the ground up. The SE/30 hardware is pretty simple if you >> have a strong background in computer design and hardware. The device driver >> software would be the difficult part, unless you are intimately familiar >> with programming device drivers for Mac OS. > > It probably would be easier or at least cheaper to redesign from the > ground up, especially considering that modern CPLDs/FPGAs, memory > chips and video timing chips are so much cheaper and superior to what > was used/available on the older Micron card. > > I have made a very minor beginning by reading "Designing Cards and > Drivers for the Macintosh" 3rd Edition and by having a lot of good > intentions which are interfered with by life. However, while this > book covers what is needed to interface one's card to the SE/30 (and > NuBus machines in general) it assumes that one is already an expert > on the type of card one wishes to build. > > I'm a fairly fresh EE. I have never designed a video card. I have > looked around for references on the art and there don't seem to be > any resources that cover the topic from a hardware designer's point > of view. > > The specific question that gives me the most headache is how to > handle the refresh of the screen data. I believe that updates to > the screen image (changes to the contents of the video RAM) may be > coming from the host CPU at any time. But if the video card is only > halfway through drawing a screen image (the CRT has scanned half-way > down the screen), one would not want to then implement an update on > the second half of the screen which hasn't been drawn yet. This > could result in the top half of the screen showing one image and the > bottom half showing a completely different image, though only for one > screen refresh cycle. In less extreme cases it just results in > flickers and little starbursts here and there as on ancient CGA video > systems. > > There are various schemes for dealing with this. One is to have two > screen buffers--two sets of video RAM. But this requires twice the > memory on the card (not a big problem now days), and it seems to > require moving a lot more data back and forth, though I'm not > certain. Another method is to only update the video RAM during the > flyback period of the attached CRT. This requires some kind of > buffering of incoming data or lowers performance, as the video card > tells the CPU to hold video updates until that short period. > > Another method is to track where in the video RAM the screen scan is, > and only update portions of the video RAM which are behind the > current scan cycle, but this also requires some kind of buffering for > updates to video RAM in front of the scan point. > > I'm sure these methods have been worked out in detail better than I > can reinvent them, and there is probably a comprehensive comparison > of their relative merits discussed somewhere, but I have not been > able to find such a reference. Somehow the NuBus video cards we > used to buy managed this without using twice the video RAM. > > Another question that interests me, but is not critical, is how to > implement QuickDraw accelleration. If one is going to build a video > card from scratch, one might as well consider providing some > acceleration. There's plenty of logic capacity available in modern > FPGAs at a low price and the things run at clock speeds that > designers of ten years ago could only dream about. Was all the > information on this topic proprietary to folks like Radius and Raster > Ops, or did Apple ever publish guidelines or articles on building > QuickDraw accelerators? > > I'd appreciate any pointers or help. For the optimistic, please > don't expect any results--well anytime. I'm puttering on this > project, but there's a two-year-old in the house and similar things > that distract me, so while I hope to produce something, I can't > guarantee any results in any reasonable time frame. It probably > would go faster with collaboration though. > > Jeff Walther
Thank you Jeff (and others) for your scientists information. It is very precious of having of good and rich information. Unfortunately, I am not capable of you help in order to continue your project. I can only benefit of your work, of your acquaintances. I thought too merely that the card was easy to reproduce, I had not imagined that on this map resides a specific chips of MicronExeed. I hope that some other greatly more qualified people that me, will construct your project with you. and that I will be able to again benefit some fruits of this constructive collaboration. Daniel -- Compact Macs is sponsored by <http://lowendmac.com/>. Support Low End Mac <http://lowendmac.com/lists/support.html> Compact Macs list info: <http://lowendmac.com/lists/compact.shtml> --> AOL users, remove "mailto:" Send list messages to: <mailto:[EMAIL PROTECTED]> To unsubscribe, email: <mailto:[EMAIL PROTECTED]> For digest mode, email: <mailto:[EMAIL PROTECTED]> Subscription questions: <mailto:[EMAIL PROTECTED]> Archive:<http://www.mail-archive.com/compact.macs%40mail.maclaunch.com/> --------------------------------------------------------------- >The Think Different Store http://www.ThinkDifferentStore.com ---------------------------------------------------------------
