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 OfDaniel 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
-- 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 ---------------------------------------------------------------
