From mint-bounce@lists.fishpool.fi Fri Nov 27 11:37:14 2009 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=uCLeK8LoDt4tV6JbT8+POFDFltxRgir8qtSSUbiKea0=; b=oXo4oaJC/FoGy8Zp5GrBnynMzmO2VHS1/dIR4Vg2AUVKZY+aH8vKa8lSUYReRfgW/6 UlgpHQNyX//318tmBQ+RFB57oG0S1Abf4XgFCJKL8eow8Jn4kVRMr0Nivs5VxEkGbV3z XbdzWZme9+aFvgGAHlyqNeNyWzNkr76j1aRJs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=phULrNW5netdYnScpPEP8draqESUyRJ2ATSAJIDetgZmijT+3O6BJFNk3Wd+h6cKNL kpBblsMX2lCQW0FPG299Ee6PWaH7bEVeAiH7YQg5IhiWk12kcGhac73i+0byJeAOpJuA 4VfYiwzPlRiu/ZTiTueJR+MV3psQV0dfRooRk= MIME-Version: 1.0 In-Reply-To: <7C3EA975C1884385A601809DA1F657B1@mercatus.local> References: <11a6f2b10911270646s6ceab50i915d71aeb27f6be9@mail.gmail.com> <1259333803.8246.36.camel@petr> <7C3EA975C1884385A601809DA1F657B1@mercatus.local> Date: Sat, 28 Nov 2009 03:33:43 +1100 Message-ID: <11a6f2b10911270833x5fbc85hdba1f96e1e70fcfe@mail.gmail.com> Subject: Re: [MiNT] XaAES sources for FreeMiNT 1.16.3 From: Paul Wratt To: mint Content-Type: text/plain; charset=ISO-8859-1 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: paul.wratt@gmail.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: :) OK, I am presuming it is ARAnyM related (in some way), because it would be unthinkable for what I see (and dont see) to have not been fixed let alone reported, if it were the same for other platforms (CT6x, Milan, Hades, etc) It is not ARAnyM related, or fVDI, or EmuTOS, as these can be swapped and the results are the same. The only difference I can find is that anything after 1.16.3 (ie 1-17-cur) causes XaAES to have "invalid pixel format" in >256 color video modes under ARAnyM. Like I said, it is not ARAnyM, fVDI, or EmuTOS, as changing versions does not affect the results of either 1.16, or 1.17. It however might be the ARAnyM MiNT loader, the XaAES loader or kernel module, or it may even be the way ARAnyM runs the BOOTSTRAP, or uses the BOOTSTRAPARGS. I only know this, because I "accidently" saw gradients and texturing when I put 1.16.3 from Pack 3D on the AFROS 8.12 LiveCD. The results are reproducible on a standard ARAnyM using AFROS style boot. I am not 100% sure what the difference in an EasyMint setup might be, except that it looks to use the AUTO folder as its primary boot, NOT the ARAnyM MiNT image, ie MiNT gets loaded after SET_MMU and CLOCKY, unlike AFROS which load the MiNT.PRG first, then uses the .CNF to autoload certain file "before MiNT" This is also the only difference I can see the "may" affect the CAT issue already mentioned elsewhere, but then it would be a quirk, which may or may not be related to ARAnyM (use of BOOTSTRAP). This is only a guess atm.. I have yet to test any 1.17 on EasyMiNT ARAnyM installation (from the EasyMiNT download page) OK, so why 1.16.3 source? Fork, definitely no need for that, yet... To me its simple. I dont know what has changed since 1.16.3, according to XaAES's about dialog, its exactly the same version 0.9.9.8 alpha, but I know that something in how the pixel format is recognised HAS changed, and since it was OK in 1.16.3, I can then do a simple compare of code to see what has changed. This makes "fixing" XaAES to an unbroken level, a simple thing. It may also show why the latest kernel builds are absolutely unusable on ARAnyM. To see what I mean, grab the latest kernel cvs builds from freemint.org, and replace the respective files in a AFROS booting ARAynM, and you will see the system is totally unusable. My understanding of code is that its (probably) a small "thing" that has caused this problem, or it maybe a couple of "small things". But I have noticed only a lack of comment about its results, except for a few comments by "one off" AFROS users on the ARAnyM mail-list, "it has ugly shadows around the icons". Thats it, nothing else.. what the user didn't know, was that gradients AND texturing were also missing.. Unfortunately I neither know enough C, C algorithms, or TOS programming to be able to just jump into the code (or a debugger) and "iron it out by hand", like say Vincent can. But I do know enough to read C, understand what its trying to do, compare it to some other code, and make adjustments, or "cut and paste" some new code which does achieve "the right results". (this is a legacy of web development, but it does mean I can read ANY code, and get working results, based on working examples). As for the rest of the XaAES issues, and for that matter the current load of 68000 FreeMiNT ones, if I can get this sorted, then I can start looking at using a debugger to help fix other problems that are not so simple, especially since the only ST I have are emu's, they are recommended for hardware compatibility, so they will do fine. One last thing, I'm guessing here, but I think that the redraw problem on the Milan, is the same "redraw quirks" that happen on EasyMiNT. These "quirks" are NOT present on an AFROS setup running 1.16.3 (from PACK3D), or 1.17 (from AFROS 8.12). (now that seems to make perfect sense???) If peeps need screen shots to better understand what is and isn't happening, I can provide a catalog. If someone else wants to "fix" XaAES, I would be happy for them to do so.. but I need things sorted asap, which is why I'm willing to do it. Its taken me 12 months to put what I have together, and I was hoping to have a "good" point release of both 1.17 (XaAES) and HighWire out by Christmas, for an initial AFROS 9.12.. but hey, one thing at a time.. Hope that clears up any possibilities.. BTW Alan, cheers on the CVS info, do you know the command off the top of your head? Also, I have already logged the main issue under the XaAES bugtracker on Mantis.. As I side note, while I'm doing all these version tests, I thought I might as well go through and confirm some of the other issues logged, like the "rpm tetex-fonts" issue, to give them up-to-date status Cheers peeps Paul