Re: [MiNT] Shutdown() discussion

["Konrad Kokoszkiewicz" <draco@obta.uw.edu.pl>]

> I realized it at the end of the previous reply. But the word "blocked"
> is not correct - the output is simply not drawn on the screen because
> the necessary routines are missing.

Ok, if you prefer such wording, the text output is not blocked, it just does
not appear on the screen, while it should.

I would not accept the explanation that "it should not be done", because it
is obvious, that if a program wants to display a text with Cconws(), then
the text SHOULD appear on the screen. I hope that we agree on that. I guess
that Johan Klockars also agrees on that, since the fVDI tries to write its
initial message to the screen as well.

I would not accept the explanation that "it could not be done", because
obviously other VDIs can do it. The VT52 emulator is in ROM, it knows where
to output the text to, so if fVDI is lacking the proper routines, perhaps it
should just pass the stuff down to the BIOS?

Yes, I know that fVDI is free, the author gets completely no responsibility
et cetera, and that you are not the author. But from the symptoms I am not
completely sure that it is really a problem with fVDI, it can as well be a
problem with Aranym and natfeats which (I guess) the native graphics drives
uses. This is why I bother you. Please read on.

> Konrad, you may not know how it works internally. The short answer is
> that fVDI does not implement the VT52 and the LineA emulation.

Good.

And now I'd want you carefully read what I now am gonna write.

1) Please pay attention to the symptom I mentioned: the fVDI initial message
(that with the version number, that is displayed after fvdi.prg gets loaded)
SOMETIMES DOES NOT EVEN APPEAR IN FULL (and sometimes does not appear at
all). It looks as if the printing was aborted in the middle of the string.
Since it is a very strange symptom IMHO, I think it is very important to
take it into account tracing down the reasons for such a behaviour. This
also makes me think that this may be an Aranym's fault, not fVDI's.

2) Also the word "blocking" I used was not used without a reason. Namely
after the fVDI loads, there is 3-4 seconds pause, and then suddenly all the
text appears again (as if a buffer was flushed - and please don't waste your
time to explain me that there are no buffers, as I am describing symptoms).

3) It is too quick to see whether all the text gets printed then that was
previously "blocked", or only a part of it. However, it seems to somehow
shake your theory about missing routines - because there is apparenly enough
routines to display the text at least partly. This also shakes Johan's words
about no way to handle text output before the AES opens the workstation -
because at least part of the text output is handled.

4) All this wouldn't be very important, if it didn't block the access to the
boot menu, for example.

I hope that this is now explained enough. I think you (or anyone) can easily
reproduce the symptoms on your side, if you still don't exactly know, what I
mean. The setup I am observing this is:

aranym 0.8.0 beta 3 for Windows (XP) - all previous versions I tried had the
same thing.

Config 14/64 MB of RAM, TOS 4.04

Auto folder: XBOOT, FASTRAM.PRG, FVDI.PRG (58664 bytes), the rest does not
matter (it is the same without).

The effect does not depend on fVDI configuration.

>> This is quite a long moment and MiNT outputs quite a lot of
>> information
>
> It clearly depends on the order of programs in the AUTO folder. If
> fVDI.PRG is the last one in the AUTO folder the amount of missing
> information is close to zero.

Not true (init.prg, rc scripts, login prompt).

--
CVV
Konrad M.Kokoszkiewicz, http://draco.atari.org

** Ea natura multitudinis est, aut seruit humiliter, aut superbe dominatur.
** Taka to już natura pospólstwa, albo służalczo się płaszczy,
** albo bezczelnie się panoszy. (T. Liuius XXIV, 25).