From mint-bounce@lists.fishpool.fi Fri Dec 26 20:28:06 2008 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=aaW7/uiAuzKnx+9aJurFmPRsWCXwdWz1CfXn+zku9YY=; b=KMDnRAiqn4NbcLvKvkczeztMtBvYSM9aVc3szUVtYS52Vkj0uFuUeYuLDvWtPCBR8h Krt+Pim3zQp4iit1J5K0eBRNf/r/DyihPLPcYW+YUBWIt5NVVG7SEswkdJwee2Zq6TYY hH67SsKtYxPyQRPitN9Dz+OsNE2BhKPARpRwM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=sPjHgAF9k1mLKdIA93TF/sCmhG2/XyshDszOuOB/08WSzkE8WF+CvgIOEvv5gWcRMo 50cvV798B0GQ7RBBOBe2Kx3SttLzNpKaIjnaUViXDgXCjzO96Fno79FUauERpEzpT9UL yPR7Bq5YLkhEcgvsNcwRQN7PlSbiGZjV5AZy4= Message-ID: Date: Sat, 27 Dec 2008 02:26:10 +0100 From: "Johan Klockars" To: "[MiNT] Mailing-List" Subject: Re: [MiNT] VDI? (was Re: an urgent GEM question :-) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: 0b40f28a7aa921d0 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: johan@klockars.net Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: >>>>>> I am not sure. Can only give my perspective. If fvdi won't drive the >>>>>> display on my Hades then it's a show stopper. I think ozk managed to do >>>>>> that, maybe even for the Milan. I forget just how far he got with it. >> >> It's not up to fVDI itself to drive your display. That's a driver matter. ... > Yes, I realize that, it's somewhat modular. I was generalizing, I don't The fVDI module system has really only been used for display drivers so far, but you could do other things that way if you wanted. Mouse drivers should be possible now, for example, and the whole FreeType machinery is not far away from being "modularizable". > expect you to do it, just whoever. But who will port it? That's always the > problem, it's easy to just say that to someone. I can't do it. So I'm back It will likely have to be someone who has the actual hardware. I've tried before to debug display drivers via email, but it is a _major_ pain. > to square one. It's unusable to me. Both my machines have video cards that > currently have no associated driver for fvdi. See below. > But the thing if is someone is going to suggest it be the 'default vdi' then > to me it should at minimum drive all the current crop of cards already in > use. I know you didn't suggest this. ;-)) That would indeed be preferable. But more important would probably be to be able to guarantee the same functionality for all hardware currently in use. If that in some cases means that you must have another VDI below, so be it. > That's fine. More heads are better than one. Having it on the CVS might > help it get some drivers down the road. Not CVS in itself, since it's already been on that for years (with interruptions), but possibly the FreeMiNT CVS. > driver so I'm stuck and I can't even do as you suggest. The Mach64 in the > Hades requires the nova driver, NVDI alone can't drive my setup. Actually, the RageII used in the Eclipse graphics card uses the mach64 drawing engine (the driver was working on a Falcon+Nova before there ever was an Eclipse), so it shouldn't be very hard to support your Hades. I don't remember if it was a Hades or a Milan that I tried to get the driver working on via email years back (there was some confusion regarding exactly how the PCI BIOS should work, as I recall it), but for someone with actual hardware access it shouldn't be too difficult to do. The main problem (once the PCI BIOS problem is sorted out) is likely to be the mode setup, which we "cheated" on with the Eclipse (by dumping numbers from the same card being properly set up on a PC). The proper way to do that would be to run the actual PC BIOS code on the card, which I believe is what the Milan and Hades (and "prototype" CT60 graphics card tests) do. Not exactly difficult to do, I suppose, but not done in an afternoon either. > The special version of nvdi for the Rage Pro was flakey, so I ditched it. As > in sold it. Ozk has it and the card actually, I sent it to him. I bought a whole bunch of PCI graphics cards way back then, to work on drivers, but the only one I ever did anything with was the Voodoo Banshee (quite nice 2D hardware, with good documentation available). I'm not sure I ever got hold of a PCI Rage Pro. IIRC, ATI hasn't changed the 2D hardware much from the Rage Pro days, so it's possible that the work recently being done to prepare for the CTPCI could be reused for that. >> Does anyone know what oVDI has that fVDI doesn't? >> Well, except more things implemented in plain C code. > > He did get the et6000 working. Pretty sure he asked me to test it on > et4000, but I never got around to testing that. There also looks to be some But that was only pixel by pixel drawing, wasn't it? That is, no acceleration? I don't think I've seen documentation for those cards around, but there should be X11 sources etc that could be used. > work done or started on the standard Atari modes as well. fVDI has drivers for the standard Atari modes. Only the monochrome one is really fast (but that one is blazing), but the rest of the bitplane drivers should be reasonable as well, I think (even though they are 100% C, based on the code in EmuTOS). The FalconTC driver is really only meant as an example (100% C as well), but I seem to recall it working fine. /Johan