CTPCI & Graphic card: theory of operation

[guibrush]

So, now that my CTPCI is installed, I’m trying the softs that I installed and there is something I don’t quite understand: how softwares that aren’t aware of the existence of the graphic card address the display output?
Coming from the Amiga world, I’m familiar with the concept of dual screen output, one for the native video and one for the graphic card. I’m pretty amazed to see that on the Falcon, the external graphic card can be initialised and used directly at boot time, this is not the case on Amiga. One has first to load the OS and launch the RTG (Retargetable Graphic) system first.

What I expected was that all softwares that are « desktop compliant » will run correctly on the desktop, and therefore on the graphic card, and that all softwares that use fullscreen and the Videl will output, well, on the Videl. But it looks that it’s only partially true, as I have some softwares that behave differently: ScummVM and Basilisik II. They trash the display on the graphic card and don’t output anything on the Videl output. I found out 2 demos that try to output on the Videl but give a trashed result, where the work good without the CTPCI / Radeon installed (beams for exemple).

Is there a way to tell those softwares to not try to use the graphic card and continue to display on the Videl as before?


thanks!

[mikro]

You can thank Didier on both accounts: the driver is integrated into CTPCI TOS, so that's why you see accelerated output from the first moment.

However that also means that he directly patched stuff on XBIOS level, not only VDI level, so any application which assumes that calling VsetMode() and Physbase() leads to access to the video ram is going to fail.

VsetMode() sort of does the right thing (however not for 320x240...) but any attempt to write to current video ram wont have the desired effect.

Ironically, the "cleanest" applications are now those which access Videl directly, bypassing XBIOS completely.

IMHO Didier shouldn't have touched XBIOS at all but oh well, it's easy to say it now, after 15 years.

[guibrush]

ok, I understand better. So, basically, because ScummVM and Basilisk II respect the legal system calls for opening the screen, they fail, where a demo that bang directly the Video don't care and will display correctly.
And I suppose that there is no way to trick ScummVM or Basilisk II to bypass the legal system call? Maybe display in a windows for ScummVM?

How is the situation with the Supervidel? We don't need a patched TOS for it, so it should work correctly, right?

[mikro]

SuperVidel's main asset is that it is compatible with the Videl on register level. Its authors really got it right, a perfect balance between new features and backward compatibility. Not that it doesn't have its own bugs. ;)

There's no need to trick ScummVM or Basilisk II, there are both open source. :) It's just matter to support the API. In theory, one could code a TSR which would basically revert VsetMode() & VsetScreen() back to its original behaviour (i.e. touch only the Videl) but on that front it is perhaps easier just to change CTPCI TOS. :)

Although displaying anything in a window instead of fullscreen is surely not a trivial task, a much harder one than the above in fact.

TL;DR: everything is solvable, there's just not enough manpower.

[guibrush]

ok. Thanks for the precisions.
Looks that the only way to run those softwares now is to bypass the radeon by pressing the V key at boot. But this need another xa_video.cnf at boot, because the one with the Radeon screen mode generate garbage on the screen.
But because boot don't work with the Radeon, I will need to try another boot manager to do that.

Damn, I wish that the Supervidel isn't unobtainable, this would solve so many problems.

[guibrush]

I have another 2 stupid questions:

how behave ScummVM on a Atari clone that have a graphic card by default, like a Milan or a Hades, or even on a Vampire V4 ? Does it display correctly? If yes, why?

How the Nova PCI adapter worked on the Falcon? Did we had the display at boot up similar way than the CTPI, or was is more something like on Amiga, only when the graphic card resolution is selected the graphic card display something?

[mikro]

how behave ScummVM on a Atari clone that have a graphic card by default, like a Milan or a Hades, or even on a Vampire V4 ?

Badly. I guess that answer your follow-up question as well. ;-) If you have been watching my ScummVM dev thread, you might have noticed that adding (at least basic) support for Graphics cards and/or VDI is somewhat on my TODO list but that requires my resuscitated attention to CTPCI again. Before I killed (and re-acquired) my CTPCI, I had a proof of concept for CTPCI done but it had many deficiencies, so it wasn't worth releasing.

Mind you, except maybe the V4 (or the FireBee), the code has to be equally efficient and fast, neither Hades, Milan nor CTPCI are much faster than the CT60. Plus if you want a tearing-less picture, another level of care has to be included. FireBee is highest on the list for me, it has a loyal and graceful community but there are hardware problems (@mfro showed me a code how to enable 320x240@8-bit but man, I'm not gonna do that, I'll wait until it makes into their XBIOS...).

All in all, not a trivial work with a lot of testing involved. But sure, having a TT with somewhat accelerated blitting, or at least rendering to a chunky buffer, that would help. But there's again a catch, Mach32/64 doesn't allow easily setting 320x240, only 640x480 and higher. @agranlund did some magic for his Raven to actually allow the resolutions but again, if it doesn't make into Idek's drivers...

How the Nova PCI adapter worked on the Falcon? Did we had the display at boot up similar way than the CTPI, or was is more something like on Amiga, only when the graphic card resolution is selected the graphic card display something?

There is no such thing as Nova PCI, only ISA. And the display is similar to CTPCI: separate VGA output on the card, ignoring any hardware accesses however nobody has made a TOS with drivers included (well, except's EmuTOS support for 640x480@1bpp for Mach32 and ET4000 cards). So yes, the latter.

[shoggoth]

There’s sort of a Nova PCI, but it’s called Hades (it uses the Nova VDI)

[shoggoth]

The V4 doesn’t have Atari-style 8BPP planar yet. It’s chunky atm. It may change (likely).

[guibrush]

how behave ScummVM on a Atari clone that have a graphic card by default, like a Milan or a Hades, or even on a Vampire V4 ?

Badly. I guess that answer your follow-up question as well. If you have been watching my ScummVM dev thread, you might have noticed that adding (at least basic) support for Graphics cards and/or VDI is somewhat on my TODO list but that requires my resuscitated attention to CTPCI again. Before I killed (and re-acquired) my CTPCI, I had a proof of concept for CTPCI done but it had many deficiencies, so it wasn't worth releasing.

Yes, I saw that, and because I had no idea about how the CTPI really work I at this time didn't undertstood why a specific version was needed.

Mind you, except maybe the V4 (or the FireBee), the code has to be equally efficient and fast, neither Hades, Milan nor CTPCI are much faster than the CT60. Plus if you want a tearing-less picture, another level of care has to be included. FireBee is highest on the list for me, it has a loyal and graceful community but there are hardware problems (@mfro showed me a code how to enable 320x240@8-bit but man, I'm not gonna do that, I'll wait until it makes into their XBIOS...).

All in all, not a trivial work with a lot of testing involved. But sure, having a TT with somewhat accelerated blitting, or at least rendering to a chunky buffer, that would help. But there's again a catch, Mach32/64 doesn't allow easily setting 320x240, only 640x480 and higher. @agranlund did some magic for his Raven to actually allow the resolutions but again, if it doesn't make into Idek's drivers...
Mind you, except maybe the V4 (or the FireBee), the code has to be equally efficient and fast, neither Hades, Milan nor CTPCI are much faster than the CT60. Plus if you want a tearing-less picture, another level of care has to be included. FireBee is highest on the list for me, it has a loyal and graceful community but there are hardware problems (@mfro showed me a code how to enable 320x240@8-bit but man, I'm not gonna do that, I'll wait until it makes into their XBIOS...).

All in all, not a trivial work with a lot of testing involved. But sure, having a TT with somewhat accelerated blitting, or at least rendering to a chunky buffer, that would help. But there's again a catch, Mach32/64 doesn't allow easily setting 320x240, only 640x480 and higher. @agranlund did some magic for his Raven to actually allow the resolutions but again, if it doesn't make into Idek's drivers...

ok, all of this make totally sense. So, it won't be anytime soon.

There is no such thing as Nova PCI, only ISA. And the display is similar to CTPCI: separate VGA output on the card, ignoring any hardware accesses however nobody has made a TOS with drivers included (well, except's EmuTOS support for 640x480@1bpp for Mach32 and ET4000 cards). So yes, the latter.

Yes, I wanted to say the Nova ISA adapter, sorry. So, if the Nova ISA isn't using a patched TOS, this would mean that ironically, it's easiest to use in a multi configuration system as the CTPCI. One would simply have to not load the driver from, let's say, Xboot III, and the demos won't try to access a wrong memory address. Subsidiary question: I assume it isn't possible to use the CTPCI Radon in the same way than the Nova, without using the patching TOS ?

I have right now another stupid question in my head: does the Supervidel display something if the CT60 is put in 030 mode or not at all?


@ shoggoth:
thanks for the precision.

[mikro]

Yes, I plan to create a bare bone version of CTPCI TOS without the drivers built-in so one can use the latest USB/network/graphics drivers without any collision. But of course, you can use another driver for graphics even on top of current CTPCI TOS but it's not that convenient (long booting time, have to hold V during boot...)

And no, in 030 mode SV does nothing.

[guibrush]

this is a good new! Using "V" at startup don't solve everything, as the driver still need to be de-activated at boot, and because Xboot III don't work with the CTPCI drivers, it's like a chicken and egg problem. Maybe another boot selector is compatible with the CTPCI, this I don't know.

But to me, having the behaviour "Amiga style", meaning always boot on the Video and only activate the graphic. card with the driver is the best solution.

And for the Supervidel, that mean that the Video still need to be hooked on the monitor then for the 030 mode, ok. Thanks for the info.

[agranlund]

Yes, I plan to create a bare bone version of CTPCI TOS without the drivers built-in so one can use the latest USB/network/graphics drivers without any collision. But of course, you can use another driver for graphics even on top of current CTPCI TOS but it's not that convenient (long booting time, have to hold V during boot...)

Sorry if slightly off-topic but since you mentioned CTPCI, graphics cards, and long boot time;
I saw this in CT60 TOS sources:

Code: Select all

	/* try to not init the board with the X86 VGA BIOS, too long on CT60 (more than 20 seconds, 2 seconds on Coldfire) */

Is it perhaps running the vgabios startup code with caches disabled?

I'm doing something similar here for the purpose of making it (much) easier to support more ISA graphics cards in my own clone and yep, vgabios init took some 20 seconds here too.

Then I realised I had 060 caches disabled at that stage of the boot process, enabled them and that made it run in ~1 second.

[guibrush]

well, if this could be implemented, it would be for sure a nice improvement.

[guibrush]

Yes, I plan to create a bare bone version of CTPCI TOS without the drivers built-in so one can use the latest USB/network/graphics drivers without any collision.

There are newer drivers that those available with the flash 2.01?

[mikro]

Then I realised I had 060 caches disabled at that stage of the boot process, enabled them and that made it run in ~1 second.

It's possible. If I were to guess, the lowlevel init code for the 060 is done just before TOS init (basically mimicking CT60 TOS) so when the ATI drivers needed to be executed (even before CT60TOS init), it stayed with the cache off.

So it remains to be seen whether it's only about one innocent cache on before ATI init and then cache off again after.

There are newer drivers that those available with the flash 2.01?

I meant fVDI, USB and ethernet drivers for all of which are newer / bugfixed builds available.

[PeterS]

The Milan takes about 20s to start the screen as well.
I will time it to be sure.

PS.
At 22s the monitor wakes up and at 35s the colour Milan logo appears and the RAM check starts.

[foft]

I do wonder how much is timing critical. For example could run the bios and record the writes and later replay them. There are probably a few stages where it reads a register in a loop to wait for something.