From fnaumann@mail.cs.uni-magdeburg.de Thu Jan 22 15:51:24 2004 Date: Thu, 22 Jan 2004 15:41:33 +0100 From: Johan Klockars To: mint@fishpool.com Subject: [MiNT] fVDI issues Message-ID: <20040122144133.GC17739@haddock.cd.chalmers.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Delivered-To: mint@fishpool.com Delivered-To: mint@lists.fishpool.fi X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: rand@cd.chalmers.se Precedence: bulk List-help: List-unsubscribe: List-ID: X-List-ID: 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)