Re: [MiNT] AES & VDI test tools

[Paul Wratt <paul.wratt@gmail.com>]

I post this here, as it is associated to the reason for this post:

subject	Re: [Aranym-dev] v_opnbm() support in fVDI?

Thanks (again) very informative

On Wed, Dec 9, 2009 at 9:11 AM, Johan Klockars <johan@klockars.net> wrote:
>>> Hmm. I suppose one "easy" solution would be to add a couple of generic
>>> minimal drivers internally. fVDI does not really require much more
>>> than palette and pixel set/get functions, and those would be pretty
>>> simple to provide for just about anything. Of course, they would be
>>> dead slow...
> ...
>> Speed: is it not possible to draw on some demo scene code to get an
>> "ultra fast" routine?
>
> Well, the "ultra fast" stuff would be in the real drivers.
> What I'm talking abot here is something so generic that it would,
> basically, just look at the kind of table returned by vq_scrninfo()
> and just cobble together the pixels according to what's there.
>
> The demo scene is not likely to have much of real use. They seldom do
> things as generic as is needed by the VDI, anyway, and I do have
> "ultra fast" routines in most places where it really matters for the
> general stuff.
> Of course, since I've never really been interested in anything besides
> monochrome and the RageII driver, the normal bitplane stuff did not
> even exist until four years ago or so. The "bitplane" driver should
> now be able to deal with any of the Atari bitplane modes, and is
> reasonably fast (based on stuff from EmuTOS, but significantly
> optimized in places).
>
>> Also the screen drivers, is it not possible to provide "a generic
>> driver", or a "driver skeleton" that others could use to provide a set
>> of drivers.
>
> There already is that. The following is an extract from the headers
> for the 16 bit (Falcon TC) driver:
>  * This file is an example of how to write an
>  * fVDI device driver routine in C.
>  *
>  * You are encouraged to use this file as a starting point
>  * for other accelerated features, or even for supporting
>  * other graphics modes. This file is therefore put in the
>  * public domain. It's not copyrighted or under any sort
>  * of license.
>
>> What are the issues for adding multi-driver support. Can the current
>> driver still be used if that was added. Or is it merely a time issue,
>> with testing and debugging.
>
> Well, the main issue is that I have never actually thought about
> exactly how to do it.  ;-)
>
> I believe very few things in the fVDI engine would need changing,
> since everything is already addressed via the workstation struct that
> a specific virtual workstation "belongs" to. The remaining things are
> the driver loading, selection (via v_opnwk() etc), and perhaps dealing
> with global things like the vex_ vectors.
>
>
> If you have some specific case you would want to try out, let me know
> the details and I'll see if I can find the time to write some test
> code. When last I tried to add things that were needed for some
> specific application, I got bogged down single stepping code trying to
> figure out what was needed...
>
If when I come up with a specific scenario I will let you know, as I
understand the last part of that paragraph totally..

If anyone here has specifics, now appears to be a good time to state
them, and if anyone has invested time in either "custom ASM"  or
"speed based C" routines, I would be interested to know (no matter
what they are used for), I will endeavor to check "GNU/GCC" based
speed routines that may be applicable to AES/VDI (or other areas where
speed would be a plus)

Paul