OS stack

[peterlane]

I realised recently I don't have a clear idea of what is doing what on my Firebee. I was hoping more knowledgeable people might give me some pointers, or correct my misunderstandings.

I am typically running the following:

1. I boot into FireTOS
2. This loads FreeMINT and NVDI
3. When FreeMINT starts, it launches XaAES
(4. TeraDesk then starts, but this doesn't impact the OS)

My understanding is that FireTOS is "based on Falcon-TOS 4.04". I thought of this as, essentially, TOS 4.04 (as from the Falcon) with USB and other support added. So this should contain, on its own, a complete implementation of VDI and AES essentially from Atari.

My mental picture was that steps (2) and (3) replaced parts of FireTOS to support new functionality. FreeMINT provides a multi-tasking kernel, replacing the application-handling code in FireTOS. NVDI replaces the VDI component, supporting vector fonts and giving fast screen output. Finally, XaAES replaces the AES component.

(I imagine these replacements as redirecting the trap calls to their own code??)

In this thread though (http://atari-forum.com/viewtopic.php?f=16&t=29859) I was told FireTOS uses fVDI, and this was the likely source of the redraw errors I was noticing there. Also, pmarkers do not work on the Firebee, because they are not implemented in fVDI.

Has fVDI then replaced the Falcon's original VDI code in FireTOS? Or is it part of FreeMINT?

This explanation breaks my mental model of NVDI replacing the VDI. So, which parts of VDI does NVDI actually replace? Is it just the text output? And, if so, how then is general screen output supposed to be improved, as is shown in various tests? (Without NVDI I found that italic text displayed illegibly in programs like Atari Works, which is perhaps another problem for fVDI?)

FireTOS and NVDI are closed source. But fVDI seems to have some sources available, at least here: http://vincent.riviere.free.fr/soft/m68k-atari-mint/archives/mint/fvdi/ Is this what's running most of the VDI commands I use on the Firebee?

[Faucon2001]

NVDI is piggybacked on FVDI.
NVDI is used only for the printing side ; all the screen drivers are deactivated. The screen is managed directly by FVDI.

[lp]

Has fVDI then replaced the Falcon's original VDI code in FireTOS?

Correct. Rather than fix the Atari VDI to handle video modes with more than 16 bits per pixel, he decided to completely replace it. So fVDI is part of FireTOS.

[jfl]

NVDI is used only for the printing side

This doesn't seem correct to me. Sure, the GDOS portion of NVDI is active, but VDI functions too. For example, offscreen bitmaps are not supported by fVDI. Programs making use of them don't work properly if NVDI isn't running.

It seems to me that with NVDI running, fVDI only provides the screen driver. NVDI provides both VDI and GDOS functions.

[Mathias]

I read an older internal developer discussion again. It was between m0n0, PeP and Jo Even. They were also not 100% sure but had similar theories like jfl. The only person who could enlighten us is Didier. Perhaps somebody should drop him a mail.

[shoggoth]

I don't think NVDI provides offscreen bitmaps if you're using fVDI as an underlaying screen driver.

[jfl]

I don't think NVDI provides offscreen bitmaps if you're using fVDI as an underlaying screen driver.

Simple, when NVDI is running offscreen bitmpas work, when it doesn’t they don't. Go figure.

[shoggoth]

I don't think NVDI provides offscreen bitmaps if you're using fVDI as an underlaying screen driver.

Simple, when NVDI is running offscreen bitmpas work, when it doesn’t they don't. Go figure.

Hmm... all depends on the definition of "NVDI is running". On a system where fVDI is responsible for screen drivers, and you run NVDI on top to extend the VDI, NVDI is by definition "running", but you won't get offscreen bitmaps. The situation is different on the Milan or Hades, where MVDI/NovaVDI provides offscreen bitmaps (the normal thing to do is to run NVDI on top to provide vector fonts etc, but NVDI doesn't provide offscreen bitmaps in this case - MVDI/NovaVDI does).

fVDI wrongfully hints the availability of offscreen bitmaps, but as far as I'm concerned, they're not really implemented (functions fail).

[jfl]

On a system where fVDI is responsible for screen drivers, and you run NVDI on top to extend the VDI, NVDI is by definition "running", but you won't get offscreen bitmaps.

Shoggoth, I'm telling that on my FIreBee, with NVDI I have offscreen bitmaps, without it I don't. And I can't deactivate fVDI since it's inside FIreTOS. Why don't you believe me? I'm not making this up. If you have another explanation, I would be interested. But please stop correcting me on something I know to be true by experience.

[shoggoth]

On a system where fVDI is responsible for screen drivers, and you run NVDI on top to extend the VDI, NVDI is by definition "running", but you won't get offscreen bitmaps.

Shoggoth, I'm telling that on my FIreBee, with NVDI I have offscreen bitmaps, without it I don't. And I can't deactivate fVDI since it's inside FIreTOS. Why don't you believe me? I'm not making this up. If you have another explanation, I would be interested. But please stop correcting me on something I know to be true by experience.

Our test results differ, our experience differ! It's not that I don't believe you, don't worry. Explanation below.

I tested it by attempting to open and use offscreen bitmaps in my own code on multiple VDIs, but the best outcome would be that I'm wrong (i.e. my test code was wrong) and you're right. Perhaps the situation has changed (i.e. Didier has put offscreen bitmap support in FireTOS after I made my tests).

How did you test it?

[jfl]

I tested it by attempting to open and use offscreen bitmaps in my own code on multiple VDIs, but the best outcome would be that I'm wrong (i.e. my test code was wrong) and you're right. Perhaps the situation has changed (i.e. Didier has put offscreen bitmap support in FireTOS after I made my tests).

How did you test it?

By running GEMDict (see signature) which uses offscreen bitmaps for it's text display. If I disable NVDI during boot the display is garbled. Exactly like it is with ARAnyM+fVDI. I'm pretty sure Didier hasn't done anything with this.

[shoggoth]

How did you test it?

By running GEMDict (see signature) which uses offscreen bitmaps for it's text display. If I disable NVDI during boot the display is garbled. Exactly like it is with ARAnyM+fVDI. I'm pretty sure Didier hasn't done anything with this.

This is potentially great news. What functions did you use? IIRC I tested the return values of v_opnbm()

[peterlane]

Thanks everyone for your responses. It seems the situation is not very clear for the VDI part!

From the discussion, the picture I get is as follows:

1. FireTOS uses fVDI, as this supports the Firebee video modes.

2. When we install NVDI on top, the situation becomes complex. fVDI retains control over (most?) aspects to do with output to the screen. NVDI provides some additional/improved functionality. This additional functionality includes fonts and (pace shoggoth!) offscreen bitmaps.

The only person who could enlighten us is Didier. Perhaps somebody should drop him a mail.

I'll do that.

[mfro]

Thanks everyone for your responses. It seems the situation is not very clear for the VDI part!

From the discussion, the picture I get is as follows:

1. FireTOS uses fVDI, as this supports the Firebee video modes.

this is one reason, the other one being TOS 4.04 VDI (which is still in the ROMs but inactive) requires the Falcon blitter (that's the reason you can't really disable the blitter on a real Falcon). As there is none (yet) in the Firebee's FPGA, another VDI must be used.

2. When we install NVDI on top, the situation becomes complex. fVDI retains control over (most?) aspects to do with output to the screen. NVDI provides some additional/improved functionality. This additional functionality includes fonts and (pace shoggoth!) offscreen bitmaps.

This is not different or more complex than on any other Atari. NVDI is essentially a GDOS. GDOS is a VDI extension that allows to enhance and/or replace the existing VDI with additional functionality (like loadable video and other graphics device drivers, loadable fonts, normalised device coordinates and what else). It can (like any other GDOS) make use of ROM resident drivers (which just happens to be fVDI in the FireTOS case) or replace them with specific ones that know the video device in question.

For the offscreen bitmaps to work (this is a NVDI extension and - at least to my knowledge - not in the original DRI VDI specs), NVDI must know the physical bit depth and bit arrangement of the video driver.

[jfl]

How did you test it?

By running GEMDict (see signature) which uses offscreen bitmaps for it's text display. If I disable NVDI during boot the display is garbled. Exactly like it is with ARAnyM+fVDI. I'm pretty sure Didier hasn't done anything with this.

This is potentially great news. What functions did you use? IIRC I tested the return values of v_opnbm()

Same here. v_opnbm() and v_clsbm(). Be careful that with fVDI you won't get any errors using these functions. So checking return values is not a valid indication. You need to actually have stuff correctly displayed on screen. Which doesn't happen with fVDI alone. Basically, the offscreen bitmaps implementation in fVDI is completely bogus. Rather than returning a valid error so the program knows it should stop there (for example a zero in the third parameter) it craps all over the screen. Not nice.

[lp]

Same here. v_opnbm() and v_clsbm(). Be careful that with fVDI you won't get any errors using these functions. So checking return values is not a valid indication. You need to actually have stuff correctly displayed on screen. Which doesn't happen with fVDI alone. Basically, the offscreen bitmaps implementation in fVDI is completely bogus. Rather than returning a valid error so the program knows it should stop there (for example a zero in the third parameter) it craps all over the screen. Not nice.

I wrote a small off screen test. I can confirm with aranym standard install off screen stuff does not work and it returns 0 as it should. Maybe that has something to do with the combination of work_in parameters? Hard to say. If I load NVDI over top fVDI then my little test works fine. I did this testing with a fresh install of aranym on my guest account.

[Rajah Lone]

I may be mistaken, the problem was discussed here : viewtopic.php?f=25&t=28983&start=25

[lp]

Is there an official fVDI repository?

I found this http://vincent.riviere.free.fr/soft/m68 ... mint/fvdi/
The links to the original site is broken.

I downloaded the archive and had a look at the sources code. There is some code that tries to deal with v_opnbm(). In the \engine folder, file workstn.c, this bit of code keeps it from doing anything:

Code: Select all

/* Doesn't allow the EdDI v1.1 variant yet */
if (!intin[15] || !intin[16] || !intin[17] || !intin[18] || !intin[19])
  return;


This test is completely backwards. These should all be null for EdDI v1.0. Not sure if it's a bug or intentionally done to disable v_opnbm(). I had the idea to trick fVDI and set work_in() 15 to 19 to non-zero. Now I get back a handle and it appears to allocate the ram and fill in the MFDB. However, anything I draw to the off screen buffer ends up drawing over top the desktop. So it almost worked.