Re: [MiNT] XaAES sources for FreeMiNT 1.16.3

[Johan Klockars <johan@klockars.net>]

> isn't one of the main reasons for direct video access the fact that
> only one physical workstation can be open with VDI, and yet by default
> it abstracts this with a virtual work station. Shouldn't an app be

I'm not sure I understand what you are getting at. There's no
functional difference (as far as a user is concerned) between the
physical workstation and the virtual ones. You just need to open the
physical one before you can create any virtual ones.
Under fVDI at least, v_opnwk() even calls v_opnvwk() internally (after
checking that you are really attempting to open a driver that fVDI
handles, initializing the driver, and setting up some vectors).

> it pleases. And isn't it related to a fundamental flaw in VDI's
> construction, the fact that is has full control over the actual
> hardware screen via a physical workstation (but is limit in some way,

The most fundamental flaw, as I see it, is that the VDI does not have
any notion whatsoever about different applications or windows. If it
did, it could limit access for an application to the parts of the
screen where it is allowed to write.
As it is, any application can write all over everyone elses windows.
Only the AES knows about the windows, and it leaves it to the
applications to clip to their own.

> to one physical workstation), shouldn't it be able to manage the
> actual virtual to physical, even from another app/control point. (like
> a display/desktop manager)

It would indeed have been much preferable if the VDI had been able to
enforce rules about who can access what part of the screen.
This is something I thought about back when I was designing fVDI (I
believe there must be some comments about it in the old docs). One
idea was to make everyone able to open "physical" workstations, which
would then be private to that application. These physical workstations
would not necessarily be visible on screen at all, but would be
handled by some display/desktop manager behind the scenes. Thus, every
application would have its own "screen", protected from everyone else
(whether in a window or full-screen).

> Another way to say this: App says give me a screen, (like console, but
> not just text only), or tries traditional memory write (which VDI
> intercepts). App is "yay I have full access... (doing stuff)". VDI

No "application" should ever require full access (as in getting a
pointer to the frame buffer) to the screen. Game developers might want
it, but they should be made to understand that it is quite
counter-productive on anything besides the standard Atari hardware
(and perhaps SuperVidel, if/when that becomes available).

While it is possible to do the kind of "VDI intercept" of memory
writes that you are talking about (at least on hardware with MMU), it
would be so horribly slow as to be unusable.

Perhaps there is some middle ground here?

I do understand that accessing the screen directly is significantly
faster than any other option for the standard Atari hardware. The copy
speed C2P from FastRAM to STRAM that someone mentioned could easily be
done by the VDI, though (I wrote one of those myself some 15 years
ago, and always planned to write a chunky 256 colour VDI driver for
the Falcon using that), and I am not aware of anything else that
anyone would want to access the STRAM directly for, if they have a
modern CPU accelerator, and assuming the VDI can blit stuff at similar
speed as your own code. Please, let me know what I am missing, if
anything.

Anyway, for those who are running without '040:s etc, it is obviously
faster to access the screen directly. So, what can we do for them?

Obviously, they would require screen base changes to get smooth
animation. This is something that at least some graphics hardware
could provide, but then it would be inside the graphics card memory.
Since writing directly to the graphics card memory is not something
you would want to be doing, normally, they will rather do their work
in normal RAM and blit things over before flipping the screen base.

So, how do we make
- write to STRAM, then flip
- write to FastRAM, blit to back-buffer (on card or in STRAM), then flip
- draw (using the VDI) to back-buffer, then flip
work the same, in some nice VDI:ish way? Shouldn't be very hard, I hope.

We also need to figure out what should happen to all the applications
that can no longer be writing to the screen while this game (or
whatever) controls it. Perhaps they can just continue working as
before, in some off-screen (but preferably on-card) area?

> says "who is screen manager/director?" in response to positive answer
> "this is for you. tell me when you want this onscreen, also let me
> know if it is to be "screen hog" and on which monitor (nothing else,
> dedicated), or else tell me what size and where do you want it.. "

I think you are talking about the kind of thing I mentioned above.

/Johan