[MiNT] fVDI issues

[Johan Klockars <rand@cd.chalmers.se>]

I heard from Petr that there had been some discussion on the MiNT list
relating to fVDI.
Unfortunately, I currently don't have access to my usual email account
where the discussion has (hopefully) been archived, so I have to start
a new subject (probably a good idea, anyway, since it was a nightmare
to try to locate the relevant postings on the MiNT list archive page ;-).
If I forgot to address something important below, please let me know.

So, a couple of clippings from the archives:

> >  I just want to ask what are peoples experiences with N.AES and N.ChRes.
> > Does it work reliably for anyone here? Changing resolutions does work
> > stable? With Memory Protection enabled?.
> 
> No problems on my Milan, works fine with both the S3-driver as well as
> the ATI-driver. Doesn't work too good on my Falcon with the Eclipse
> installed though.

The main reason why fVDI (independent of what driver is used) can't yet
respond to a resolution change request is that it is still unable to
close a physical workstation and open a new one.
This is related to the way it can still also only deal with a single
configured device driver.

The design should be able to deal with all these things, but the code
is simply not in there. Most of that part hasn't seen much development
since '98 or so, I'm afraid.
The main reasons are simply lack of more device drivers and the fact that,
until recently, only the RageII driver was really seen as important, and
for that there should seldom, if ever, be a need to switch resolutions.
If I'd had requests for making it work, I would probably have done
something about it, but I can't recall getting any.
Obviously it will be fixed sooner or later.


I agree with Odd that the VDI should be a kernel module under MiNT
and that it should keep track of which processes own which handles.
For now, fVDI tries to be MiNT and MP friendly as far as memory
allocation is concerned, but has no other MiNT awareness. This will
change, though.

Speaking of that, I've not looked into if MiNT supports something like
the 'process local storage' that can be found in some operating systems.
It might be nice if it was possible to make the VDI handles really local,
in the sense that they were indices into tables that were allocated
per process (well, it would be even better if they were simply pointers,
but unfortunately they are defined as 16 bit integers).
Of course, it is possible to have the VDI keep track of such tables by
itself, but since they would need to be indexed by the process id, it
is sort of painful. With 'process local storage', the VDI could simply
have the OS take care of the pointer in some way, and just ask for it
when needed (this would obviously need to be a very quick operation,
but that should not be a problem for a kernel module).


Another thing that was mentioned somewhere was the possiblity of
calling the BIOS from inside a VDI trap handler.
In principle, this is not really a problem, since the only difference
to a normal call is that there is some extra stuff on the system stack.
TOS does some extremely funny things with the stack sometimes, though
(in apparent attempt to be 'somewhat' reentrant), which could cause
trouble if the VDI itself was called from inside those parts of TOS, and
the stack is not very large to begin with.
Is there any documentation anywhere on how much space is guaranteed to
be available on the system stack, by the way? Assuming a call from
usermode, that is.


Also, gcc compilation of fVDI is still 'on the way'.
The only real problem is the assembly source files. Mainly their use
of macros and local lables, which is incompatible with gas.
There have been two separate attempts so far to write a DevPac->gas
conversion package to deal with this, but neither was completed.

I'm very much a gcc person myself, so this is a definite priority.
These days, when most fVDI work is done in C, it is a pain not to be
able to use gcc. In the beginning, when most of the code was in
assembly, I liked being able to make use of the features of the DevPac
assembler. Since then I've ported most of the assembly to the Lattice C
and TurboC/PureC assemblers, anyway, though, so gas is 'just' another
target (but unfortunately one that has some important differences).


>>> BTW. I'd be very happy if someone could finally fix the problem with
>>> FVDI blocking Cconws() output, because without fixing this I cannot
>>> even see messages MiNT produces during boot (which could probably
>>> reveal more EmuTOS issues), not to speak about opening the boot menu.
>>
>> It is not blocking anything.
>
>Petr, please, accept one thing: it is. Otherwise I wouldn't waste the time

Well, it depends on what you mean by 'fVDI blocking Cconws()'.  ;-)

Since fVDI does not have a GEMDOS (Trap #1) handler, it obviously can't do
anything about Cconws() itself.
Of course, Cconws() gets turned into BIOS (Trap #13) Bconout() inside
GEMDOS, but fVDI does not have a handler for that trap either...

I've heard about this apparent blocking under ARAnyM before, though, and
have some vague memory of even seeing it for myself (not sure about that).

fVDI does have an XBIOS (Trap #14) handler. But that is only used if the
'xbiosfix' option is set. And even then it only deals with Physbase(),
Logbase() and Getrez() (and the two former only after the physical
workstation has been opened).
It also has a LineA handler. Once that is activated, when the physical
workstation has been opened, no LineA drawing will take place any longer.
Function 0 (font address request) is still passed on to the original
LineA handler, though. All the other functions simply return the address
to the LineA variables in register a0.

So, as far as I can see, fVDI really should not be able to stop Cconws()
in any way. I also can not remember seeing that behaviour on my
Falcon/Eclipse, which I usually run with normal TOS text output going to
my old SM124.
Still, I do not dispute that this is happening. Only that fVDI itself
has anything to do with it. Perhaps the ARAnyM driver does something
that somehow interferes with Cconws()? I do seem to recall it doing
things in a somewhat 'non-orthodox' way at initialization.

>> You probably need a VT52 emulator
>
>I must point out that I have a VT52 emulator. It is inside the ROM and works
>great until the time the fVDI is loaded. Then the screen output stops. The

Well, you should not expect it to work after the physical workstation is
opened, since the time of non-VDI output is then past.
Just loading fVDI should not cause this behaviour, though.

>last message that appears is fVDI's message with version number (sometimes
>it is not even fully displayed, which makes the thing more interesting).

And more likely to somehow be the fault of the ARAnyM driver.

You might want to turn on some debug information in fVDI.
It can print lots and lots of information about what is going on, as
well as single- or multi-step VDI calls.

>Despite that, this is not a matter of the VT52 emulator, or a BCONOUT.PRG,
>because f.e. NVDI is somehow able to load and initialize without making
>GEMDOS troubles displaying text stuff.

Well, NVDI does things very differently from fVDI.
For example, fVDI does not use the lineA variables for anything whatsoever,
or implement any of the lineA functions, or intercept BIOS text output.

>> I didn't know you would need VT52 in the short moment
>> between starting MiNT and opening desktop.
>
>This is quite a long moment and MiNT outputs quite a lot of information
>then. And it can be even longer moment, when I don't load AES at all (as
>Ingo pointed out).

Before the VDI physical workstation is opened, fVDI is not supposed to
touch anything that can affect TOS screen output.
Once that workstation has been opened, fVDI disallows lineA output
functions (since they know nothing about whatever screen the current fVDI
device driver is writing to). It also modifies (if told to) a couple of
lineA variables to describe the new screen (since some software relies
on that) and changes the screenbase returned by XBIOS SetScreen().

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |
                        | so hard to do |  WWW:      http://www.klockars.net
   Gothenburg, Sweden   |     well?     |            (fVDI, MGIFv5, QLem)