[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] XaAES sources for FreeMiNT 1.16.3
On Thu, Dec 10, 2009 at 4:46 AM, Peter Persson <pep.fishmoose@gmail.com> wrote:
>
> On 9 dec 2009, at 18.20, Paul Wratt wrote:
>
>> a "must have", but an initial start to the sequence should be the
>> ability to choose a screen rez and color depth, and I think that is
>> what VDI cannot do, which is what a virtual worksataion should be able
>> to do.
>
> The XBIOS video API on the CTPCI is compatible with that of the original Falcon TOS. It's also compatible with the extensions provided by the Milan XBIOS. Personally, I think this works fairly well, apart from being too hardware dependent (different calls to set colour registers on different incarnations of the shifter, for example). There is also a slight problem regarding the allocation of video RAM. There is an undocumented TOS call for this (Srealloc()), but I think it re-allocates VRAM instead of just allocating new space.
>
>> From memory frame buffers can be redirected or re-pointed (on PCI/ISA
>> hardware anyway), which will beat bliting any day.. this may be
>> dependant on video mode and/or card support, I cant remember exactly,
>> but I know VESA VBE can supply this sort of support.. which comes back
>> to choosing a video rez, and how to do that thru VDI (current or
>> new)..
>
> Most graphics cards can specify the framebuffer base address, but it's still limited to the onboard VRAM.
>
> -- PeP
>
so one possibility could be to standardize the XBIOS API for future
hardware, and at the same time allow current systems to take advantage
of it. A generic revision of said XBIOS API, that maintains this
compatibility. Isn't this part of TOS/ROM, and there for appropriate
for EmuTOS. This would depend on wheather or not Milans can be
updgraded (source access?) and how that affects current software. If
an upgrade/revision were in the works (ROM/VDI/AES), then there is
also opertunity to allow for video ram allocation. Maybe what is
needed, because of modern hardware, is direct framebuffer access, or a
specific framebuffer access, and things like that. (I know VBE
functions can be rather slow)
Paul