ArcaOS widescreen video not working in virtualbox

[madbrain]

1) do not use Panorama in the VM. There is absolutely no gain in doing so. GENGRADD will either work or not.
In fact, Panorama is based on GENGRADD with some very minor additional feature (saving and restoring screen parts from a memory buffer called "shadow" buffer). This speed issue is not really relevant in a VM (where the host needs to inferfere with the guest screen output anyway)

2) you can use the GENGRADD that comes with the OS/2 additions. in the past I also used the GENGRADD that comes with Panorama (it's located in \OS2\DLL) and it made no difference but I think it is a good idea to use the GENGRADD from the OS/2 additions.

So, my next question is, how to properly reinstall GENGRADD under ArcaOS ?
I tried running s:\CID\SERVER\SNAP\SETUP.CMD GEN  .
That gets me into a state where only a single resolution is shown under the "Screen" GUI tool. If I disable all custom resolutions in the VM in Virtualbox, then it only shows 1600x1200x16M .

Under ECS, reinstalling GENGRADD the same way (from ECS 2.0 CD) allows me to see all kinds of resolutions.

2) have you increased the aperture size of the VM to 32 MB ?

Actually, I increased it to 128MB. But 32MB results in the same behavior.

Of course you have to do that. If you do that you might also need to reduce the VIRTUALADDRESSLIMIT value in the guest. That's because more address space is now needed for kernel addresses (due to the larger aperture size). I recommend not going beyond 2048 for VIRTUALADDRESSLIMIT but you can experiment what works for you.

Looks like my VM has 2048MB in virtualbox, and the ArcaOS installer put VIRTUALADDRESSLIMIT=1536 in config.sys . I left that part alone.

[madbrain]

There is a limit, depending on how much video memory you have, and there is a limit to how much gengradd can handle (might even be 15 MB).

Is this 15 MB limit in GENGRADD documented somewhere ? It would be nice to know if this is a problem in the GENGRADD drivers or in the Virtualbox VBE BIOS .

[madbrain]

1) do not use Panorama in the VM. There is absolutely no gain in doing so. GENGRADD will either work or not.

I agree. Using SNAP, or Panorama, in a VM is unnecessary overhead, and does absolutely NOTHING for you.

That's not really true. The different video drivers change the behavior of the "Screen" dialog, which is where you can select video modes.
All 3 drivers - GENGRADD, Panorama, SNAP - are showing different sets of available video modes under ArcaOS 5.0.3 .

Under ECS 2.0, GENGRADD and Panorama show the same video modes, including all the Virtualbox custom video modes.

I couldn't get SNAP drivers to show any custom video modes, either under ECS or ArcaOS .

[Doug Bissett]

So, my next question is, how to properly reinstall GENGRADD under ArcaOS ?
I tried running s:\CID\SERVER\SNAP\SETUP.CMD GEN

I am not sure what you have done, but that will simply install SNAP, which isn't going to help.

Just copy gengradd.dll from the OS/2 Additions to \OS2\DLL. Whether that will fix your problem(s) will depend on what else you have done. It would probably be easier to simply start over, to avoid missing something.

Looks like my VM has 2048MB in virtualbox, and the ArcaOS installer put VIRTUALADDRESSLIMIT=1536 in config.sys . I left that part alone.

You misunderstand. 2048 is probably the disk size that you specified, or the virtual memory size (not clear from what you said). VIRTUALADDRESSLIMIT has nothing to do with either of them. 1536 was okay, 7 years ago. It is very marginal now (depending on what software you are running). The reason to not use 3072 is that video memory reduces the total memory that is available, and video can overwrite the top of memory, or, the top of memory can be used for something else, and overwrite the video memory. Neither one is good, so I suggest 2560, which is more than safe, yet it gives you more room in the virtual memory space that OS/2 provides, than the default of 1536.

Is this 15 MB limit in GENGRADD documented somewhere ?

Not that I know about (and I could be wrong about 15 MB). I don't think I ever saw video use more than that in OS/2. Higher screen resolutions may need to be balanced, by using a lower color depth to stay within the limits.

That's not really true. The different video drivers change the behavior of the "Screen" dialog, which is where you can select video modes.
All 3 drivers - GENGRADD, Panorama, SNAP - are showing different sets of available video modes under ArcaOS 5.0.3 .

I find that unlikely, since SNAP, and Panorama, both use what gengradd tells them. Plus, all video is interfaced to the host video system, by gengradd, when using the gengradd.dll supplied by VBox additions (I doubt if SNAP or Panorama, ever get used). Gengradd simply shows the available modes, as described by the video BIOS, for VESA mode. Adding resolutions in VBox simply adds the resolution to the available list in BIOS. If gengradd can use it, it is listed in gengradd, SNAP, and Panorama. If it can't use it, for some reason, it isn't shown. Panorama is somewhat smarter about selecting resolutions though, and it should automatically choose the best one to fit the attached monitor (assuming that the monitor has the required smarts - I am not sure what support VBox has for that).

Look in the guest in C:\var\log\vbe2grad.log and that should tell you what is available, if you can make any sense out if it.

[madbrain]

So, my next question is, how to properly reinstall GENGRADD under ArcaOS ?
I tried running s:\CID\SERVER\SNAP\SETUP.CMD GEN

I am not sure what you have done, but that will simply install SNAP, which isn't going to help.

No, that is not correct. SNAP installation is done with :
s:\CID\SERVER\SNAP\SETUP.CMD SNAP

How am I supposed to reinstall GENGRADD ?

I have also tried DSPINSTL, but there are many different GRADD and VGA GRADD options there, and when prompted to locate the files, I am not sure what path to point.

Just copy gengradd.dll from the OS/2 Additions to \OS2\DLL. Whether that will fix your problem(s) will depend on what else you have done. It would probably be easier to simply start over, to avoid missing something.

Start over as in, reinstall the entire VM ? No, thanks. I shouldn't have to do that to switch video drivers.

You misunderstand. 2048 is probably the disk size that you specified, or the virtual memory size (not clear from what you said). VIRTUALADDRESSLIMIT has nothing to do with either of them. 1536 was okay, 7 years ago. It is very marginal now (depending on what software you are running). The reason to not use 3072 is that video memory reduces the total memory that is available, and video can overwrite the top of memory, or, the top of memory can be used for something else, and overwrite the video memory. Neither one is good, so I suggest 2560, which is more than safe, yet it gives you more room in the virtual memory space that OS/2 provides, than the default of 1536.

I don't misunderstand, and I meant exactly what I wrote. 2048 MB is the amount of RAM selected in Virtualbox for my guest. It is not the disk size.
I don't believe VIRTUALADDRESSLIMIT is really impacting my problems here.

Not that I know about (and I could be wrong about 15 MB).

OK, because if it was documented somewhere, that would be helpful, as that would point to a bug in GENGRADD as opposed to a bug in the VBE BIOS for virtualbox. I guess it still needs to be determined where the bug is, then.

I don't think I ever saw video use more than that in OS/2. Higher screen resolutions may need to be balanced, by using a lower color depth to stay within the limits.

Yes, and if you read my post above, you know that I already tried to use 64K color modes, but I did not succeed with any video driver under ArcaOS. All of GENGRADD, SNAP and Panorama only show 16M color modes, even when I add some 64K color modes to the guest. By contrast, in ECS 2.0, GENGRADD and Panorama work with 64K color modes, and I was able to get 3840x2160x16 to work there with GENGRADD and Panorama, without OS/2 additions, but not with SNAP.

I find that unlikely, since SNAP, and Panorama, both use what gengradd tells them.

I'm only reporting the actual behavior I'm seeing on VM here when switching between the 3 video drivers. I have been banging my head on this ther last couple days. Don't call me a liar. And please lose the condescension.

Plus, all video is interfaced to the host video system, by gengradd, when using the gengradd.dll supplied by VBox additions (I doubt if SNAP or Panorama, ever get used). Gengradd simply shows the available modes, as described by the video BIOS, for VESA mode. Adding resolutions in VBox simply adds the resolution to the available list in BIOS. If gengradd can use it, it is listed in gengradd, SNAP, and Panorama. If it can't use it, for some reason, it isn't shown. Panorama is somewhat smarter about selecting resolutions though, and it should automatically choose the best one to fit the attached monitor (assuming that the monitor has the required smarts - I am not sure what support VBox has for that).

Well, that clearly isn't how it actually works in my ArcaOS VM. The Screen dialogs are showing very different modes available. It seems some modes are being filtered somehow.

Look in the guest in C:\var\log\vbe2grad.log and that should tell you what is available, if you can make any sense out if it.

Thanks, that is actually quite helpful. Yes, I can make sense of that. Will add that info once I edit the post as I'm posting this from my Win10 host and copy/paste doesn't seem to work between guest and host.


Edit:


Panorama v1.11 log for GID=0 started at 12.1.2019 14:46:54
This copy of Panorama is licensed to Julien Pierre #XXXXX
Profile setting for Shadow...Enabled
VESA version is 200
BIOS-supplied information
OemVendorNamePtr  = C0007C7B
OemProductNamePtr = C0007C8E
VideoModePtr      = 8F000022
TotalVramSize     = 2100000
OemVendorName     = Oracle Corporation
OemProductName    = Oracle VM VirtualBox VBE Adapter
Custom resolution is disabled
VBE VRAM Base=E0000000 Size=2000000 (32768Kib) (rounded up)=2000000 (32768KiB)
Mode 0x100: 640x400x8bpp
Mode 0x101: 640x480x8bpp
Mode 0x102: 800x600x4bpp 4 1F
Mode 0x103: 800x600x8bpp
Mode 0x104: 1024x768x4bpp 4 1F
Mode 0x105: 1024x768x8bpp
Mode 0x106: 1280x1024x4bpp 4 1F
Mode 0x107: 1280x1024x8bpp
Mode 0x10D: 320x200x15bpp 1 9B
Mode 0x10E: 320x200x16bpp
Mode 0x10F: 320x200x24bpp 1 9B
Mode 0x110: 640x480x15bpp 1 9B
Mode 0x111: 640x480x16bpp
Mode 0x112: 640x480x24bpp 1 9B
Mode 0x113: 800x600x15bpp 1 9B
Mode 0x114: 800x600x16bpp
Mode 0x115: 800x600x24bpp 1 9B
Mode 0x116: 1024x768x15bpp 1 9B
Mode 0x117: 1024x768x16bpp
Mode 0x118: 1024x768x24bpp 1 9B
Mode 0x119: 1280x1024x15bpp 1 9B
Mode 0x11A: 1280x1024x16bpp
Mode 0x11B: 1280x1024x24bpp 1 9B
Mode 0x140: 320x200x32bpp
Mode 0x141: 640x400x32bpp
Mode 0x142: 640x480x32bpp
Mode 0x143: 800x600x32bpp
Mode 0x144: 1024x768x32bpp
Mode 0x145: 1280x1024x32bpp
Mode 0x146: 320x200x8bpp
Mode 0x147: 1600x1200x32bpp
Mode 0x148: 1152x864x8bpp
Mode 0x149: 1152x864x15bpp 1 9B
Mode 0x14A: 1152x864x16bpp
Mode 0x14B: 1152x864x24bpp 1 9B
Mode 0x14C: 1152x864x32bpp
Mode 0x160: 3840x2160x16bpp
Mode 0x161: 3840x2160x32bpp
Video Aperture: Base=0xE0000000 Size=0x2000000 Rounded=0x2000000
Attempt to allocate shadow buffer...Success
Shadow Buffer locked at 0x5BFE0000, Length 0x2000000 bytes
Failed to enable MTRR Write Combine caching.
PAT Write Combine caching enabled for Vram
PAT Write Combine caching enabled for VramRing0
Requested mode=160

This is with Panorama .
Looks like it sees all 32,768 KB of VRAM.

The Screen GUI is letting me select 3840x2160 resolution .
I now see that the drop-down for colors is dynamic. It depends on the resolution .
For example, at 1600x1200, the color drop-down is disabled.
But at 640x480, the color drop-down is enabled.
This is very subtle and hard to see when greyed out or not.
This is the opposite of what happened with some other OS/2 video drivers in the past, where you could always select the color depth, and then the dialog would update with the list of compatible resolutions.
When I found this, I was able to enable 3840x2160x16 bpp. It seems to work fine now with Panorama.

I still don't know why GENGRADD is messed up.

Will try again at 3840x2160x32bpp now since Panorama claims to see 32MB of VRAM, which should be enough for that mode.

Edit: looks like 3840x2160x32bpp now works. There is no major corruption like before, but still some, mostly related to the mouse pointer, which sometimes gets lost still. I will try to disable the comet pointer now.

[madbrain]

Edit: looks like 3840x2160x32bpp now works. There is no major corruption like before, but still some, mostly related to the mouse pointer, which sometimes gets lost still. I will try to disable the comet pointer now.

Removing the comet pointer didn't fix it. 3840x2160x32bpp still wasn't usable, even with the GENGRADD.DLL from the VB OS/2 additions, due to the mouse pointer just being "lost" and sometimes leaving a random trail.

3840x2160x16bpp seems to work, though, with Panorama. I don't know if I dare to try again with SNAP or GENGRADD now that I have it working.

SNAP has never shown any custom video modes in the Screen dialog on my VM, and GAMON / GACTRL never allowed those custom modes to work either.

And the last time I tried to revert to GENGRADD, it only showed a single video mode in the Screen dialog - no choice available at all.

[Andreas Schnellbacher]

I don't misunderstand, and I meant exactly what I wrote. 2048 MB is the amount of RAM selected in Virtualbox for my guest. It is not the disk size.

2048 MB is also the amount that Silvan recommended, like Lars. I haven't found the thread, but it might be here. AFAIR, he wrote that setting VAL to > 2048 leads to problems. (I don't remember if that has to do with SMP or DLL unloading.)

[Dave Yeo]

Snap will only give lots of resolution choices if using a supported chipset whereas Panorama can patch some video BIOS's to add more resolutions. In short don't bother with Snap unless you have a supported chipset (see readme in the Snap directory).
You will probably get better performance with 64K colours, only half the amount of memory involved. I see this on real hardware playing videos in the browser.
VirtualAddressLimit really depends on your hardware as IBM never really added the logic to tell where system memory ends and hardware memory starts. I've successfully used 3072 on various systems, this one got funky until I lowered it to 2560. Generally 2048 should be fine but there is a bug in the kernel where if you load DLLs high, the shared memory doesn't get released, easy to see in Theseus, hard to get more then a few days of uptime if you're opening and closing things like the browser if they're set to load DLLs high. We do only have 512MBs minus system use, so about 300MB, of lower memory.

[madbrain]

Snap will only give lots of resolution choices if using a supported chipset whereas Panorama can patch some video BIOS's to add more resolutions. In short don't bother with Snap unless you have a supported chipset (see readme in the Snap directory).
You will probably get better performance with 64K colours, only half the amount of memory involved. I see this on real hardware playing videos in the browser.
VirtualAddressLimit really depends on your hardware as IBM never really added the logic to tell where system memory ends and hardware memory starts. I've successfully used 3072 on various systems, this one got funky until I lowered it to 2560. Generally 2048 should be fine but there is a bug in the kernel where if you load DLLs high, the shared memory doesn't get released, easy to see in Theseus, hard to get more then a few days of uptime if you're opening and closing things like the browser if they're set to load DLLs high. We do only have 512MBs minus system use, so about 300MB, of lower memory.

The hardware is a VM in this case. The 64K colors really does look worse than 16M for photos. Even the default ArcaOS logo looks worse. The gradients don't look good. But there is clearly a problem at 3840x2160x32bpp .

On bare metal, I have only nVidia video cards (many different models) and apparently Panorama cannot patch the BIOS on those either, so it is quite limited unfortunately, much more so than what I'm getting in a VM.

It still seems to me that SNAP should be able to use all the resolutions that the VESA VBE BIOS supports, which includes the custom ones for the Virtualbox VM. Somehow, Panorama can do this, and GENGRADD does this (at least on ECS), but SNAP seems to have a hardcoded set of resolutions, and nothing else works, even with GAMON / GACTRL . Anyway, I don't need 3 video drivers to work - just one is fine.

I don't think the amount of RAM is really in an issue for the OS/2 VM, whether it's 1GB or 3GB. This is a 32-bit OS that used to run just fine with <64MB of RAM. 1GB of RAM really is plenty. Maybe only browsers are pushing the envelope these days. I haven't checked how much Firefox consumes. Is there another lighter weight browser available ?

What I would really like to get to work is SMP in the guest. It seems some people have succeeded with VMWare. I won't be trying that today, though

Also, apparently there is a shared clipboard feature for Virtualbox.

It is referenced here :
https://www.os2world.com/wiki/index.php/EComStation_2.x_as_a_VirtualBox_5.x_Guest#Shared_Clipboard

Are they talking about the Virtualbox OS/2 guest additions ? If so, which driver ? I believe I have all the additions installed in my ArcaOS VM, but shared clipboard doesn't work.

Edit: yes, it's the guest additions, which I already have. But there is a checkbox in the VM setting also, which I wasn't aware of. It works now.

Or are they referencing something else that's for ECS only ? Either way, I have an ECS 2.0 license and key, and an ECS 2.0 VM too. I haven't tried the additions in that VM yet.

[Doug Bissett]

I don't misunderstand, and I meant exactly what I wrote. 2048 MB is the amount of RAM selected in Virtualbox for my guest. It is not the disk size.
I don't believe VIRTUALADDRESSLIMIT is really impacting my problems here.

You may want to think again. VIRTUALADDRESSLIMIT=2560 makes my systems usable. Without that, and without loading as much as possible in high shared memory, I get anywhere from 1 to 36 hours of uptime (usually less than 8 hours). With it, I have got as much a 7 days, and that was terminated because I had to reboot to do some updates to RPM/YUM.

3840x2160x16bpp seems to work, though, with Panorama. I don't know if I dare to try again with SNAP or GENGRADD now that I have it working.

I have no idea why you would want a resolution like that, but if it works, use it.

On bare metal, I have only nVidia video cards

NVIDIA is well known to be a very bad choice for OS/2 users, but that has nothing to do with VBox, which emulates it's own video.

I don't think the amount of RAM is really in an issue for the OS/2 VM, whether it's 1GB or 3GB.

The amount of RAM is mostly irrelevant. OS/2 will actually run with 256 MB (possibly less), but it will crawl if you try to run anything that makes it start paging. As I stated earlier, VIRTUALADDRESSLIMIT has nothing to do with the amount of RAM (or disk space). Most of my OS/2 guests run with about 800 MB of memory (and VIRTUALADDRESSLIMIT=2560), but I don't try to run memory hogs like Firefox in them.

But there is clearly a problem at 3840x2160x32bpp .

Does it work with a reasonable resolution (you say that it does)? Why do you want to use something like that?  It is obviously exceeding the capabilities of the OS/2 drivers. OS/2 was designed to use screen resolutions of 1280x1024x32, and the drivers have probably never been used with very large resolutions (do screens of that resolution even exist?). I use 1920x1080x32 on real hardware, with no problems, but I never tried it in a VBox. It would be larger than the host screen, forcing me to scroll it, and that becomes very old, very fast. Most of my VBox systems use 1024x768x32, but I do use 1280x1024x32 on the 1920x1080x32 monitor. I did get wide screen to work, a few years ago, but it was more trouble than it was worth, so I stopped bothering with it.

What I would really like to get to work is SMP in the guest.

I tried that a few years ago, with an eCS guest. It sort of worked, for a few minutes, then froze. I should try it again, they may have fixed something (but I doubt it). I suspect that they are using logic that mimics Hyper Threading, and that is not, at all, compatible with the OS/2 threading model. FWIW, I have tried SMP with a windows guest. The difference in performance is not that great, so I usually use single processor mode in VBox, for all guests.

[Dave Yeo]

Snap will only give lots of resolution choices if using a supported chipset whereas Panorama can patch some video BIOS's to add more resolutions. In short don't bother with Snap unless you have a supported chipset (see readme in the Snap directory).
You will probably get better performance with 64K colours, only half the amount of memory involved. I see this on real hardware playing videos in the browser.
VirtualAddressLimit really depends on your hardware as IBM never really added the logic to tell where system memory ends and hardware memory starts. I've successfully used 3072 on various systems, this one got funky until I lowered it to 2560. Generally 2048 should be fine but there is a bug in the kernel where if you load DLLs high, the shared memory doesn't get released, easy to see in Theseus, hard to get more then a few days of uptime if you're opening and closing things like the browser if they're set to load DLLs high. We do only have 512MBs minus system use, so about 300MB, of lower memory.

The hardware is a VM in this case. The 64K colors really does look worse than 16M for photos. Even the default ArcaOS logo looks worse. The gradients don't look good. But there is clearly a problem at 3840x2160x32bpp .

OK, I agree that 16M colours look better. This is my main system and I need to be able to play videos so I compromise.

On bare metal, I have only nVidia video cards (many different models) and apparently Panorama cannot patch the BIOS on those either, so it is quite limited unfortunately, much more so than what I'm getting in a VM.

It still seems to me that SNAP should be able to use all the resolutions that the VESA VBE BIOS supports, which includes the custom ones for the Virtualbox VM. Somehow, Panorama can do this, and GENGRADD does this (at least on ECS), but SNAP seems to have a hardcoded set of resolutions, and nothing else works, even with GAMON / GACTRL . Anyway, I don't need 3 video drivers to work - just one is fine.

Testing on my T42 (ATI Mobility Radeon 7500), the stock SNAP doesn't give too many choices, but the Arca Noae Snap allows up to 2048x1536x16M with 32 MBs of video ram. Kind of irritating using it with a 1024x768 monitor but it works well. I believe you need a supported chipset to use wide resolutions.

I don't think the amount of RAM is really in an issue for the OS/2 VM, whether it's 1GB or 3GB. This is a 32-bit OS that used to run just fine with <64MB of RAM. 1GB of RAM really is plenty. Maybe only browsers are pushing the envelope these days. I haven't checked how much Firefox consumes. Is there another lighter weight browser available ?

This is about address space, not amount of ram. At one point I needed the whole 3GBs of address space to link a debug xul.dll and with only 1.5GB of real ram, even found the swapper limit of 2GB. Gave me a swap file full error and crash with lots of room, they should have used a larger type or at least unsigned:)
Firefox can use a lot of ram. It tries to allocate in high memory first. There's also the shared memory issue where loading the DLLs, especially xul.dll, into high memory helps. As mentioned, the kernel has a bug and doesn't release this memory so after a few restarts, the system will go down. I resurrected the old mozturbo for this issue, keeps the DLLs loaded and helps a lot.
There are a couple of QT4 based browsers available, they're old. Look on Netlabs, Qt4 apps.

What I would really like to get to work is SMP in the guest. It seems some people have succeeded with VMWare. I won't be trying that today, though

Also, apparently there is a shared clipboard feature for Virtualbox.

It is referenced here :
https://www.os2world.com/wiki/index.php/EComStation_2.x_as_a_VirtualBox_5.x_Guest#Shared_Clipboard

Are they talking about the Virtualbox OS/2 guest additions ? If so, which driver ? I believe I have all the additions installed in my ArcaOS VM, but shared clipboard doesn't work.

Edit: yes, it's the guest additions, which I already have. But there is a checkbox in the VM setting also, which I wasn't aware of. It works now.

Or are they referencing something else that's for ECS only ? Either way, I have an ECS 2.0 license and key, and an ECS 2.0 VM too. I haven't tried the additions in that VM yet.

Weirdly, there was 2 guest additions updates at about the same time. the official which I assume you have, were done by Bird (Knut St. Osmunson) who did the OS/2 libc for Mozilla 1.5 and is the vbox build system maintainer at Oracle, and Valery. There's a recent thread (the one you referenced?) here on Valery's additions. They've both got positives and negatives.

[Lars]

"Reinstallating" GENGRADD: in fact, you don't reinstall anything but you use what is there already:

1) make sure that a file \OS2\DLL\GENGRADD.DLL exists in your guest. There should be, no matter what.
2) in the VM, load the guest extensions. You do that via the Virtualbox GUI from the VM already running. Once you do that, the CD-ROM will show the contents of the guest extensions virtual CD-ROM drive in the guest. Drill down to the OS/2 directory and copy the GENGRADD.DLL to \OS2\DLL (backup the existing one first). It is likely that you will need to unlock \OS2\DLL\GENGRADD.DLL if you want to overwrite it. You can do a "unlock \os2\dll\gengradd.dll" before you copy.
3) make sure your config.sys contains this:
SET GRADD_CHAINS=C1
SET C1=GENGRADD
if there is, delete a line starting with:
SET GREEXT
4) shutdown the guest
5) in the VM config, make sure you have set at least 32 MB of video aperture (for the screen resolution you plan to use)
6) use "vboxmanage" in your host to create the custom screen resolution, how to do this has been described multiple times
7) start the guest
8.) in the screen object in the guest, select your new resolution
9) restart the guest

The fact that the screen object looks different is due to the fact that SNAP and Panorama add additional functionality via the SET GREEXT keyword in config.sys. But this is completely irrelevant to what you are trying to achieve (to add and use your own resolution). That can be achieved with naked GENGRADD (which does not require the SET GREEXT config.sys setting).

i am using Virtualbox 6.0 under Windows, I am using GENGRADD in the guest with the guest extensions' supplied GENGRADD.DLL and I can successfully define and use a 1920x1080x32bit video mode.

If you insist on using PANORAMA, then make sure that you disable "shadow buffer" in the screen object. It is possible that this negatively interferes with what the host system needs to do.

[madbrain]

8.) in the screen object in the guest, select your new resolution

Thanks. I followed your instructions. My problem is that at step 8, the only resolution shown is now 3840x2160x65536 . This is the last video mode I had chosen under Panorama. There is no "choice" of resolution that I can make. Something is messed up with the Screen object with ArcaOS with GENGRADD once Panorama has been installed previously. This bug only happens on ArcaOS. On ECS, I get a whole list of video modes to choose from, from 320x200x256 all the way to 3840x2160x16877216 .

The fact that the screen object looks different is due to the fact that SNAP and Panorama add additional functionality via the SET GREEXT keyword in config.sys. But this is completely irrelevant to what you are trying to achieve (to add and use your own resolution). That can be achieved with naked GENGRADD (which does not require the SET GREEXT config.sys setting).

I have removed SET GREEXT from my CONFIG.SYS as you instructed, yet I still have this problem.

If you insist on using PANORAMA, then make sure that you disable "shadow buffer" in the screen object. It is possible that this negatively interferes with what the host system needs to do.

Thanks, will keep that in mind.

[madbrain]

3840x2160x16bpp seems to work, though, with Panorama. I don't know if I dare to try again with SNAP or GENGRADD now that I have it working.

I have no idea why you would want a resolution like that, but if it works, use it.

Simple - I have a triple monitor setup. The left and center monitors are 32" and Ultra HD 4K, which means 3840x2160 is the native resolution. The third one on the right is 23" and HD, but I have it setup in portrait mode, at 1080x1920 . I want the guest to have 1:1 pixel mapping, to avoid scaling, which creates artifacts.

On bare metal, I have only nVidia video cards

NVIDIA is well known to be a very bad choice for OS/2 users, but that has nothing to do with VBox, which emulates it's own video.

Well, it is related for me, since the lack of nVidia driver for OS/2 prevents me from running on bare metal. Virtualbox is the only way for me to get a decent resolution.

Does it work with a reasonable resolution (you say that it does)? Why do you want to use something like that?  It is obviously exceeding the capabilities of the OS/2 drivers. OS/2 was designed to use screen resolutions of 1280x1024x32, and the drivers have probably never been used with very large resolutions (do screens of that resolution even exist?).

It is 2019, not 1992 . Many monitors have higher resolution. My two 4K monitors are LG 32UD59-B, which were only about $400 each last year. Some monitors exist that are even higher resolution. There are 5K displays at 5120x2800, and 8K displays at 7680x4320. Those are currently out of my price range, but I have no doubt I will move on to higher resolution at some point when they become affordable.

What I would really like to get to work is SMP in the guest.

I tried that a few years ago, with an eCS guest. It sort of worked, for a few minutes, then froze. I should try it again, they may have fixed something (but I doubt it). I suspect that they are using logic that mimics Hyper Threading, and that is not, at all, compatible with the OS/2 threading model. FWIW, I have tried SMP with a windows guest. The difference in performance is not that great, so I usually use single processor mode in VBox, for all guests.
[/quote]

I am curious how you got eCS to see more than one processor. I have not succeeded so far. Probably should be its own thread.

[Lars]

I tried to use more than one CPU in Virtualbox 6.0 just a few days ago (the system has an Intel CPU).
When doing a long build process the system would not freeze but the processes (compiler,linker) would not finish and I had to do a Ctrl-C.

In short: it still does not work and I would not bother.