Re: [MiNT] Problem with mint 1.16 installation

[Standa Opichal <opichals@seznam.cz>]

Odd, 

OK, I was a little fuzzy it seems... 

To be clear: I do not get the idea of hacking AES to do workarounds when the 
videodriver is to be fixed. What is the point in making AES to shut caches 
off? It this a thing that the AES should do by design? I truly believe it is 
not. 

So the real solution you ET whatever problem is to fix/wrap the HW driver to 
do what is necessary. If there is no API for the particular thing (a VDI 
card video driver in this case) that the closest documented API level is to 
be fixed IMHO (the VDI, right?). 

That is just like the older NOVA HW driver on my friends TT doesn't have the 
VDI scrninfo() implemented. Would I patch HighWire to not to use this 
function or would I rather go and implement the VDI function for the single 
TT I have problem with? 

Just my point of view... 

STanda 


Odd Skancke writes: 

>  Hello, 
>
> fre, 10,.06.2005 kl. 20.10 +0200, skrev Standa Opichal:
> > Hi!  
> >
> > Exactly, if there is a crappy VDI that is not compatible with a particular 
> > CPU then the VDI is to be patched and not the AES, right? So the hack should 
> > not go into AES implementation IMHO.
>
>  The VDI has just as little to do with this as the AES has. The
> videohardware driver is the issue here. But since there is no defined
> API for drivers to use, we're out of luck. The next best thing then is
> to use a defined API where available to attempt to minimize the problem.
> Any problem with this? 
>
> > STanda  
> >
> >
> > Petr Stehlik writes:  
> >
> > > Odd Skancke pí¹e v Èt 09. 06. 2005 v 17:50 +0200:
> > >> with black screen. I had this problem with the ET6K I had in my Hades.
> > >> However, the latest XaAES (as found in the CVS) turns the caches off
> > >> before calling v_opnwk()/v_clswk(), and this should cure it.
> > > 
> > > I am surprised that an AES must play with CPU caches. Shouldn't XBIOS
> > > (or VDI, at worst) do that instead? 
> > > 
> > > Petr 
>
>  Odd skancke