From mint-bounce@lists.fishpool.fi Fri Nov 27 12:12:18 2009 Message-ID: <4B1007F3.8090704@atari-source.org> Date: Fri, 27 Nov 2009 12:10:11 -0500 From: Mark Duckworth User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Paul Wratt CC: mint Subject: Re: [MiNT] XaAES sources for FreeMiNT 1.16.3 References: <11a6f2b10911270646s6ceab50i915d71aeb27f6be9@mail.gmail.com> <1259333803.8246.36.camel@petr> <7C3EA975C1884385A601809DA1F657B1@mercatus.local> <11a6f2b10911270833x5fbc85hdba1f96e1e70fcfe@mail.gmail.com> In-Reply-To: <11a6f2b10911270833x5fbc85hdba1f96e1e70fcfe@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: mduckworth@atari-source.org Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: I looked into this myself. For some reason the aranym pixel format signature is different than XaAES is expecting. I would suspect this has something to do with fvdi. My attempts to fix the issue with different fvdi color combinations proved fruitless. But yeah I noticed this problem. What I didn't know is that it ever worked before. Thanks, Mark Paul Wratt wrote: > :) > > 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 > > >