• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

Criticisms of Panorama VESA

Started by cytan, 2009.06.14, 16:42:23

Previous topic - Next topic

DougB

The idea sounds great, but it is impossible to implement. If you build your own desktop, you do have the luxury of selecting a specific video card (and other things). Your proposal falls apart, when a user tries to get a laptop. There is no real choice of which video adapter (and other things) that you will get. It is also a little unreasonable to have to add a video card to a motherboard, that already has a video adapter built in, and it seems that places to plug such a thing into the board, are also, slowly, going away, and the ones that are available, may be required for other things. Then, there is the problem, that video adapter XYZ, model 1, is available today, and is designated as being the adapter of choice, but tomorrow, that adapter is obsolete, and no longer available, because model 2 has replaced it, with different specs. Then, you run into the problem that model 1 is only available in North America, and not Europe, or Asia. The logistics of actually accomplishing the goal, makes it impossible to achieve. My greatest concern, at the moment, is not that we don't have 2D acceleration, but that it seems that the chip manufacturers are probably not maintaining the VESA compatibility, which will make even Panorama unusable. The bottom line, at the moment, is that there aren't enough resources to go around, to accomplish what needs to be done. Some sacrifices are needed, to keep the whole thing going, until somebody finds a way to do what is needed.

rwklein

Quote from: DougB on 2009.06.18, 23:52:50
The idea sounds great, but it is impossible to implement. If you build your own desktop, you do have the luxury of selecting a specific video card (and other things). Your proposal falls apart, when a user tries to get a laptop. There is no real choice of which video adapter (and other things) that you will get. It is also a little unreasonable to have to add a video card to a motherboard, that already has a video adapter built in, and it seems that places to plug such a thing into the board, are also, slowly, going away, and the ones that are available, may be required for other things. Then, there is the problem, that video adapter XYZ, model 1, is available today, and is designated as being the adapter of choice, but tomorrow, that adapter is obsolete, and no longer available, because model 2 has replaced it, with different specs. Then, you run into the problem that model 1 is only available in North America, and not Europe, or Asia. The logistics of actually accomplishing the goal, makes it impossible to achieve. My greatest concern, at the moment, is not that we don't have 2D acceleration, but that it seems that the chip manufacturers are probably not maintaining the VESA compatibility, which will make even Panorama unusable. The bottom line, at the moment, is that there aren't enough resources to go around, to accomplish what needs to be done. Some sacrifices are needed, to keep the whole thing going, until somebody finds a way to do what is needed.

To create drivers for 2D acceleration I think I wrote and I can write again. But maybe I will write it differently.
For now there will be no 2D acceleration drivers.  The financial resources are no there. And if you closely look at Scitech, you will see they sometimes had to debug a specific chipset multiple times to get it working correctly.

Basicly some other people already confirmed Panorama does a pretty impressive job.
SNAP in VESA mode is slower then Panorama is. If you have a system with 1 CPU core SNAP might be better.

Panorama has a modified GRADD.SYS, the frame buffer to speed things up. What realy even makes it run faster is when ACPI has SMP enabled. It goes even faster (some additional CPU tricks are utilized, don't know what).

Doug Bisset what do you mean the VESA standard will not remain around ? Silly question but the OS needs some base firmware todo output before its device drivers are loaded  ? And heck is the VESA standard goes away, some new generic interface will be around.

That Panorama is not the same as SNAP, granted. But its not as bad. And SDL already has a fixed version.
I used virtual PC with as well on my T60 and don't see any problems realy. In windows mode sometimes some slight redraw problems.

Other then that I have been using it for over a year now on my T60.

Roderick Klein
Mensys

DougB

QuoteBasicly some other people already confirmed Panorama does a pretty impressive job.
SNAP in VESA mode is slower then Panorama is. If you have a system with 1 CPU core SNAP might be better.

Yes, Panorama is quite good. As I noted earlier, I don't use it, for one reason, and only one reason: It doesn't allow Doodle's screen saver to power off the screen. If that was fixed, I would use Panorama, on my newer systems. SNAP is still the best choice for a lot of older systems.

QuotePanorama has a modified GRADD.SYS, the frame buffer to speed things up. What realy even makes it run faster is when ACPI has SMP enabled. It goes even faster (some additional CPU tricks are utilized, don't know what).

I also quit using ACPI, simply because my system hangs after about 4 hours, when I do, and it goes for about 8 days, when I use OS2APIC.PSD to run in SMP mode. Unfortunately, that is the only thing I can say about it, I have no idea what is going wrong, and I haven't found any indication of anything that will help to fix (or even describe) the problem, other than it simply stops responding, at irregular intervals, for no apparent reason.

QuoteDoug Bisset what do you mean the VESA standard will not remain around ? Silly question but the OS needs some base firmware todo output before its device drivers are loaded  ? And heck is the VESA standard goes away, some new generic interface will be around.

I didn't say it was "going away". I said that it appears that the manufacturers seem to be ignoring it. After all, windows doesn't use it any more, so who cares if it works, or not?

QuoteThat Panorama is not the same as SNAP, granted. But its not as bad. And SDL already has a fixed version.
I used virtual PC with as well on my T60 and don't see any problems realy. In windows mode sometimes some slight redraw problems.

I see redraw problems with both SNAP, and Panorama (slightly worse with Panorama, for some reason). The problem seems to have something to do with multiple processor support. I suspect that it may be related to some specific compiler (specifically, whatever was used to build BackAgain/2000 v4.10), but I have nothing to prove that. Virtual PC, and Virtual Box, both show redraw problems, with either driver, but that also happens in single processor mode.

Sigurd

Hello Mr. Klein,


Quote from: rwklein on 2009.06.19, 00:53:27
Quote from: DougB on 2009.06.18, 23:52:50
The idea sounds great, but it is impossible to implement. If you build your own desktop, you do have the luxury of selecting a specific video card (and other things). Your proposal falls apart, when a user tries to get a laptop. There is no real choice of which video adapter (and other things) that you will get. It is also a little unreasonable to have to add a video card to a motherboard, that already has a video adapter built in, and it seems that places to plug such a thing into the board, are also, slowly, going away, and the ones that are available, may be required for other things. Then, there is the problem, that video adapter XYZ, model 1, is available today, and is designated as being the adapter of choice, but tomorrow, that adapter is obsolete, and no longer available, because model 2 has replaced it, with different specs. Then, you run into the problem that model 1 is only available in North America, and not Europe, or Asia. The logistics of actually accomplishing the goal, makes it impossible to achieve. My greatest concern, at the moment, is not that we don't have 2D acceleration, but that it seems that the chip manufacturers are probably not maintaining the VESA compatibility, which will make even Panorama unusable. The bottom line, at the moment, is that there aren't enough resources to go around, to accomplish what needs to be done. Some sacrifices are needed, to keep the whole thing going, until somebody finds a way to do what is needed.

To create drivers for 2D acceleration I think I wrote and I can write again. But maybe I will write it differently.
For now there will be no 2D acceleration drivers.  The financial resources are no there. And if you closely look at Scitech, you will see they sometimes had to debug a specific chipset multiple times to get it working correctly.

Basicly some other people already confirmed Panorama does a pretty impressive job.
SNAP in VESA mode is slower then Panorama is. If you have a system with 1 CPU core SNAP might be better.

I just tried to load SDDHELP.SYS in Addition to Panorama Vesa - and there has been

1.: a real enhancement in starting application (as mentioned in the Panorama Bug Tracker)
2.: I discover no more desgin faults or missing parts in the windows
3.: everything seems to be a little sharper

So I could be happy but there is still one thing that (for me) makes it not working: SDL application now crash.

But for people who do not use SDL applications this seems to be a good choice

Sorry, forgot the Hardware Info: I am using Lenovo SL 300 Thinkpad mit Intel 4500 Grafic and an Intel T5870 Dualcore Chip at 2 Mhz. It is used in APIC and SMP mode. ACPI is 3.14 (eCS 2.0 RC 6a)


[/quote]
Panorama has a modified GRADD.SYS, the frame buffer to speed things up. What realy even makes it run faster is when ACPI has SMP enabled. It goes even faster (some additional CPU tricks are utilized, don't know what).

Doug Bisset what do you mean the VESA standard will not remain around ? Silly question but the OS needs some base firmware todo output before its device drivers are loaded  ? And heck is the VESA standard goes away, some new generic interface will be around.

That Panorama is not the same as SNAP, granted. But its not as bad. And SDL already has a fixed version.
[/quote]

Where do you get this fixed version? I downloaded the latest from Paul Smedley but the error still occurs. Is there a different version around? Thansk for an Advice!

[/quote]
I used virtual PC with as well on my T60 and don't see any problems realy. In windows mode sometimes some slight redraw problems.



Other then that I have been using it for over a year now on my T60.

Roderick Klein
Mensys
[/quote]

Sigurd

Criguada

Sigurd, I have been running Panorama with  SDDHELP.SYS for a long time now. It really is a good tradeoff, and it allows Doodle Screen Saver to power off my monitor, so Doug's concern should be solved.
I have SDL apps running here.. please read the docs in the SDL package, it needs a setting in config.sys IIRC.

Bye
Cris

Sigurd

Cris,

thank you very much! Even though I read the SDL documentation included in the latest release, it seems I am to stupid to find the extra line in config.sys I should add.

Could you please be so kind to tell me the line you add at your config.sys, or where exactly to find the information?

Thanks again,

Sigurd

The Blue Warper

Quote from: Sigurd on 2009.06.19, 13:28:23
Cris,

thank you very much! Even though I read the SDL documentation included in the latest release, it seems I am to stupid to find the extra line in config.sys I should add.

Could you please be so kind to tell me the line you add at your config.sys, or where exactly to find the information?

Thanks again,

Sigurd

Hi, Sigurd!
Well, I'm not Cris, but you'll hopefully find this info useful.

From the Panorama download page (http://en.ecomstation.ru/projects/panorama/?action=down), under the section "Libraries, runtimes", two SDL 1.2.10 packages are listed, claimed to be "ready for Panorama VESA":

ftp://ftp.netlabs.org/pub/sdl/sdl-1.2.10-bin-20070618.zip
http://ecomstation.ru/temp/200804/sdl-20080121.zip

In the readmes, Doodle does indeed mention some Panorama tuning activity.

1) ftp://ftp.netlabs.org/pub/sdl/sdl-1.2.10-bin-20070618.zip:
From the readme (section: "10. Changelog of the OS/2 port"):

Version 1.2.10 - 2007-06-18  - Doodle
- Added support for DIVE. This is being used if SNAP is not found or cannot
   be used for some reason. Please note that SDL in DIVE mode does not support
   fullscreen mode. Also note that DIVE is a bit slower than SNAP.
- New environment variable: SDL_DISABLE_FSLIB. Set it to something if you
   want to use the DIVE mode even if you have SNAP installed.
   e.g: set SDL_DISABLE_FSLIB=1


2) http://ecomstation.ru/temp/200804/sdl-20080121.zip
From the "info" file:

20080121
Doodle

it now has VMAN support instead of DIVE for systems where SNAP is not found.
I'd like to know if it works for others, both in windowed and fullscreen mode.

I only tested JumpNBump and Wesnoth, and worked for me, but I have SNAP
installed.


The sdl12.dll included in the eComStation.ru site has a different size than the one found on netlabs (303303 bytes vs. 188391 bytes).  I don't know if there are any real differences between the two.  Either the bigger one is a debug version or it's a 'merged' DLL that contains fslib.dll and sdl12.dll.  Anyway the readme in the netlabs version says:

Version 1.2.10 - 2008-01-21  - Doodle
- Replaced DIVE backend with VMAN backend, for better performance for Panorama users.
   It also has the advantage of having fullscreen support.


Latest version is ftp://ftp.netlabs.org/pub/sdl/sdl-1.2.10-bin-20080804.zip
but it shouldn't contain any Panorama-related enhancements, as far as I can see.

So, in summary, it seems that Doodle did make some enhancements to his SDL port in order to provide better compatibility with Panorama (and with non-SNAP drivers, too).  As to the config.sys setting Cris was referring to, perhaps it is that
SET SDL_DISABLE_FSLIB=1
which is mentioned by Doodle in his readmes starting from the 20080121 version.

Hope this helps a bit.

Regards

MrJinx

Based on the info provided, I was hopeful for a moment. I too experience the same problems Sigurd refers to with certain SDL apps.
None of these suggestions help.
1. adding sddhelp.sys to my config.sys and starting a full screen dosbox session worked,  once you try and exit the session or Alt-Esc out, It's game over, no desktop, hard reboot! Is there other switches for the driver I'm missing?
2. The problem is not that Panorama will not run SDL apps in full screen, The problem is when some SDL apps are running in full screen, the color tables are messed up. In my casee, Dosbox and ScummVM in FS mode have inverted red and blue color palettes.
Many of the SDL apps for OS/2 ship with SDL.DLL,SDL12.DLL,FSLIB.DLL, I have removed those and only leave the 804 2008 release set in my dll directory. that helped some of the windowed sdl apps. didn't affect the FS apps.

Some SDL apps that do work ok in FS for me are VirtualBox, SDLMAME<latest release.
Can you concur? Sigurd

I'm quite fine with Panorama for now if the SDL FS thing could get resolved... I have Windows for workgroups 3.11 and WIndows Millennium working in dosbox but looks horrible in inverted color mode!
Scitech VESA mode on my Acer Aspire One netbook was so slow it was unusable!


DougB

QuoteSigurd, I have been running Panorama with  SDDHELP.SYS for a long time now. It really is a good tradeoff, and it allows Doodle Screen Saver to power off my monitor, so Doug's concern should be solved.

Well, no. It still won't power off the screen. I have an Acer AL1715 screen, attached, by the DVI interface, to a video adapter described by PCI.EXE as:
Vendor 1002h ATI Technologies Inc
Device 9610h Radeon HD 3200 Graphics

I have DSS set up to start the Cairo clock, after 3 minutes of inactivity, and it is supposed to turn off the screen after 2 minutes of screen saving. The clock comes on as expected, runs for 2 minutes, then sits there not moving, until I wake it up. The screen never goes off, when I use Panorama. It does when I use SNAP.

I also tried various SDL versions, with no apparent changes, and I added:
SET SDL_DISABLE_FSLIB=1
to my config.sys. Still no changes.

I do agree, that performance is better, when I use Panorama, but that isn't as important as having the screen turn itself off IMO. I know that I can just turn the screen off, with the power switch, but I often forget to do that, so I prefer that it is done automatically.

Sigurd

Quote from: MrJinx on 2009.06.19, 18:46:09
Based on the info provided, I was hopeful for a moment. I too experience the same problems Sigurd refers to with certain SDL apps.
None of these suggestions help.
1. adding sddhelp.sys to my config.sys and starting a full screen dosbox session worked,  once you try and exit the session or Alt-Esc out, It's game over, no desktop, hard reboot! Is there other switches for the driver I'm missing?
2. The problem is not that Panorama will not run SDL apps in full screen, The problem is when some SDL apps are running in full screen, the color tables are messed up. In my casee, Dosbox and ScummVM in FS mode have inverted red and blue color palettes.
Many of the SDL apps for OS/2 ship with SDL.DLL,SDL12.DLL,FSLIB.DLL, I have removed those and only leave the 804 2008 release set in my dll directory. that helped some of the windowed sdl apps. didn't affect the FS apps.

Some SDL apps that do work ok in FS for me are VirtualBox, SDLMAME<latest release.
Can you concur? Sigurd

I'm quite fine with Panorama for now if the SDL FS thing could get resolved... I have Windows for workgroups 3.11 and WIndows Millennium working in dosbox but looks horrible in inverted color mode!
Scitech VESA mode on my Acer Aspire One netbook was so slow it was unusable!



Hi,

yes, I can concur. For me only the two applications: SCUMMVM and DOSBOX do have this inverted colorsheme. Others like Virtualbox do show the right colours.

I remebered together with Shai we discussed this here:

http://www.os2world.com/component/option,com_smf/Itemid,63/topic,1093.msg7452/#msg7452

as well.


Wonder, why I seem to forgot this - think I am getting older  :o

He solved the problem by telling the SDL program to use the full desktop screen resolution. I will try this again in the evening.

What I was able to figure out: If you reset desktop colour from 16M to 64K the Dosbox Window and the ScummVm window both started with the right colour sheme....

I will giv it more tries this evening.

Just to inform  ;) :

Yesterday I bought a ASUS EEE 1008HA PC, and try to do my best with eCS there. Already installed it, but LAN and WLAN not running, to early to say more, will inform about progress in a different thread.

Sigurd

David McKenna

  You guys might want to try the libs found here:

http://ebisa.hp.infoseek.co.jp/os2/index.htm#others

and see if there is any improvement. I haven't tried DOSBox or SCUMMVM myself...

Dave McKenna

warpcafe

Hi,

regarding video drivers and OS/2|eCS, well, I could keep talking about a trunkload of things for an entire day, but let me keep it short ;) :
- I used to have a registered version of SNAP for years (even back to when it was called "DisplayDoctor" ;) )
- Panorama is slow, yes, (not to mention when compared to Snap...)

However:
I am able to write this in eCS because Panorama exists. SNAP does not work at all with my newer machines and I'm fed up with having to buy outdated, slow, hard-to-find hardware just because my drivers won't support new stuff.

So Panorama for me is a "necessary evil" you might want to say. I am not excited about it like I was with SNAP, however I WAS excited when I noticed that it makes eCS work on my machines and SNAP didn't. That's it basically.

On a side-note:
Panorama could be improved, yes. But this is nothing impossible. We have to understand that Scitech had a lot more resources and a long-term codebase that was constantly evolving over years, while Panorama has few lesser personnell working on it (how much? 1? 2 people? part-time?) and they basically have started it from scratch. If you look at it from this angle - not bad at all, right?

Finally one comment: Panorama might be dead-slow, but SNAP is only *dead*.
(Except perhaps for "close-to-death" hardware.)
And believe me, it hurts to say this as a long-time fanatical lover of SNAP... but at the end of the day...

Cheers,
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

RobertM

While I agree with what Thomas said, there are other factors as well - for me, SNAP (any release) was downright painful for any "recent" nVidia chipset (2000 to date), while I understand (have not tried) that Panorama is at least better in that respect.

Mostly, when possible, I try to find an ATI card that is supported by SNAP. Sad choice.


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


Saijin_Naib

I never had issues with my Nvidia FX5500OC nor my friends 6600? What issues did they give you?

Also, didn't SNAP release the source as OpenSNAP? Could Panorama not merge the two projects?

abwillis

Quote from: Saijin_Naib on 2009.06.23, 01:57:37
I never had issues with my Nvidia FX5500OC nor my friends 6600? What issues did they give you?

Also, didn't SNAP release the source as OpenSNAP? Could Panorama not merge the two projects?

SNAP was not open sourced.  I contacted the new owners and they are willing to release the OS/2 code but we would have to come up with the money to pay for the code to be split out.  I don't know have any idea how many hours that would require (which would have to then be calculated to a dollar figure). 
Andy