Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Lars

Pages: [1] 2 3 ... 86
1
Programming / Re: Dive: Why does not this work
« on: April 22, 2024, 12:27:08 pm »
The samples seem to indicate that you are forbidden to drive screen updates in between calls WM_VRNDISABLED and WM_VRNENABLED. That is, there is a timespan where you are not allowed to blit anything to the screen, that means, the Classicube draw buffer function should do nothing during that timespan.
That in turn means, the proper point in time to call DiveSetupBlitter are WM_VRNDISABLED and WM_VRNENABLED. The "Remarks" section for DiveSetupBlitter even states that DiveSetupBlitter is "not intended to be called at high frequency".

This would be even more relevant for direct screen updates (that is, if you used DiveAcquireFrameBuffer / DiveDeacquireFrameBuffer / DiveSwitchBank / DiveCalcFrameBufferAddress and direct writes to the video aperture "ppFrameBuffer" as returned by DiveOpen) but for already mentioned reasons you should not do that anyways.

Still, it looks as if DIVE still needs to be notified via DiveSetupBlitter when WM_VRNDISABLED and WM_VRNENABLED are called for a specific window even if you do not do direct screen updates.

2
Programming / Re: Dive: Why does not this work
« on: April 22, 2024, 11:23:35 am »
Look at the OS/2 toolkit, in the "beehive" sample code (in that code you can ignore everything that centers around sprite creation. You can also ignore everything that centers around full screen DIVE unless you really want to do that, that includes loading GAMESVR [deprecated since Warp 4] or PMMERGE  Dive Fullscreen Init procedure).

I think you will need to support the WM_VRNDISABLED and WM_VRNENABLED window messages and use DiveAllocImageBuffer,DiveBlitImage,DivFreeImageBuffer. Note that the sample does the blitting from a secondary thread.
Yes, I do use the Dive functions, but WM_VRNDISABLED AND WM_VRNENABLED are not much use for me, since Classicube gives me the rectangles it wants to paint to, anyway. Moreover, SDL2 works without using the window messages, so it seems optional.

Look at the help for the "DiveSetupBlitter" function. You need to support WM_VRNDISABLED and WM_VRNENABLED in order to notify the Dive Blitter via "DiveSetupBlitter" that changes to the visible regions will start or end to occur.
On a reception of WM_VRNDISABLED you need to disable the blitter, on a reception of WM_VRNENABLED you will need to set up again the blitter with the proper values.

3
Programming / Re: Dive: Why does not this work
« on: April 21, 2024, 11:45:27 am »
I don't think that checking for shadow buffer is worth the effort. Todays systems with the video memory addressable as write combined memory are more than fast enough for your purposes. Just always use DiveBlitImage, following the beehive sample. That sample works perfectly well with the shadow buffer enabled.

4
Programming / Re: Dive: Why does not this work
« on: April 20, 2024, 12:39:55 pm »
Look at the OS/2 toolkit, in the "beehive" sample code (in that code you can ignore everything that centers around sprite creation. You can also ignore everything that centers around full screen DIVE unless you really want to do that, that includes loading GAMESVR [deprecated since Warp 4] or PMMERGE  Dive Fullscreen Init procedure).

I think you will need to support the WM_VRNDISABLED and WM_VRNENABLED window messages and use DiveAllocImageBuffer,DiveBlitImage,DivFreeImageBuffer. Note that the sample does the blitting from a secondary thread.

Also note that you cannot do "direct mode" when you are using Panorama with "Shadow Buffer Enabled". Since that is the setting that about 95% of all remaining OS/2 users will use, you should honour that.


5
The effective volume is the "product" of the master volume and the application volume.The sound driver effectively multiplies these 2 values when it receives a request to change the volume (at least, it should do that...). For a sound played via the WPS, no application volume has been set, so what would that be?
It is the default value set in MMPM2.INI via the "PARMSTRING" value for the Uniaud ampmixer (in the case of Uniaud). In that value string look for VOL and increase that to 100. Reboot and you should be set to a louder volume.

6
Setup & Installation / Re: Ecomstation 1.0
« on: March 28, 2024, 07:48:46 am »
www.xeu.com is also dead, has renamed itself to

https://www.payglobaltechnology.com/

as has changed its business model.

7
Applications / Re: XWP 1.0.17: any availability date ?
« on: March 20, 2024, 05:16:02 pm »
ok, thanks for the answer.

8
Applications / XWP 1.0.17: any availability date ?
« on: March 20, 2024, 06:56:08 am »
Out of interest but also need (I had raised 2 tickets): is there a rough availability date for XWP 1.0.17 ?

I was curious and looked into the XWorkplace/XWPHelpers SVN repos but could not see any checkins from Rich. I therefore suspect that currently, he only has done the changes to his local copy.

9
Programming / Re: Parition alignment
« on: March 18, 2024, 12:23:54 pm »
I remember that that would mean that the number of sectors of a partition has to be a multiple of the NUMBER_OF_HEADS * NUMBER_OF_SECTORS_PER_TRACK (where that product is identical to a cylinder size) and that a partition has to start on a sector number that is a multiple of that product and, as a consequence, also end on a sector number that is a multiple of that product minus 1.

At least that is the formula that I used when implementing "virtual partition support" (wrapping a "large floppy" type of USB MSD into a partition) in USBMSD.ADD so that LVM and MINILVM would accept such a media as partioned media without complaining.
I vaguely remember that if the media contained a number of sectors that was not a multiple of that product, that it was acceptable if the partition at least ended on a sector number being a multiple of that product minus 1 (and could start at an offset to that product) but it is possible that that is only allowed for the very first partition on a media (that said: the "virtual partition support" only requires exactly 1 partition for the whole media).

There are specific rules for the NUMBER_OF_SECTORS_PER_TRACK that apply to OS/2 and this number varies with the size of the media.
Typically it is 63, if that is not sufficient with the max NUMBER_OF_HEADS being 255 then it is increased to 127 and further increased to 255 in case 127 is still too small.

10
Programming / Re: About somFree
« on: March 13, 2024, 09:40:01 am »
"somFree" implements SOM Version 3.0. But the WPS uses SOM Version 2.x. There existed a SOM Version 3.0 for OS/2 but nobody ever installed it (apart from testing it) because it is not backward compatible to Version 2.x. There are additional SOM classes in Version 3.0 and I seem to remember that there are subtle differences in managing dynamically allocated memory compared to SOM Version 2.x.

Technically, all of the WPS could be replaced. That said, PMSHELL.EXE (the second instance of it) does not do much more than loading a huge bunch of DLLs that make up the WPS (plus interfacing to the first instance of PMSHELL.EXE to allow a WPS restart without the need to restart the whole computer).
But I think, most of the work is about interfacing to PM, that's where things become tricky and also partly undocumented as far as the WPS goes.
In the end, you would end up replacing the complete user interface and that is a lot of work.

11
Programming / Re: DosDevIOCtl disabling keyboard in VIO mode
« on: March 08, 2024, 01:49:06 pm »
As to fixups: I would think that if you specify the /BASE: keyword to the IBM OS/2 linker that then, fixups can be avoided.
I would also think that the IBM OS/2 linker has the default behaviour that when it creates an EXE, it will always assume a base of 0x10000 for the first memory object (and a fixed scheme of additional bases for the following memory objects) and will then be able to avoid fixups.

If you create a DLL, you would typically not define a base when linking because that is not desirable in general and in that case, you cannot avoid the fixups (but that is what fixups are for: to allow code/data to be relocated in memory).

When I say "IBM OS/2 linker" I assume that the Watcom linker and also the Borland linker would behave the same.

12
Storage / Re: How to properly setup a working FAT32 USB stick?
« on: March 06, 2024, 07:29:11 pm »
Sorry Andi,

The 2 comers were the result of my new keyboard, it is super sensitive - hold a key down a little bit longer and it repeats, the time is much shorter than the old one was.

You should be able to change the delay as well as the repetition rate via the keyboard object. If that does not work and if you have a USB keyboard, then USBKBD.SYS is broken for you.

13
Programming / Re: DosDevIOCtl disabling keyboard in VIO mode
« on: March 04, 2024, 08:56:24 am »
The "Kbd", "Mou" and "Vio" functions have no 32-bit thunking function, the compiler will need to provide the thunk (as the VAC compiler and Watcom compilers will do if the 16-bit function is properly declared as such).
But I also do not understand why you would be dogmatic about using 32-bit only. OS/2 has a strong 16-bit heritage, that's just the way it is.

14
Comments, Suggestions & Questions / Re: Hobbes (Files) Reoganization
« on: February 25, 2024, 09:27:06 am »
"wpsenh" makes no sense as every WPS class enhances the WPS. That is the nature of every WPS class.

15
Comments, Suggestions & Questions / Re: Hobbes (Files) Reoganization
« on: February 17, 2024, 08:54:37 am »
This would go against Martin's decision to keep all old cruft.
Back at the time, he uploaded to Hobbes all old versions he could find.

Pages: [1] 2 3 ... 86