Recent Posts

Pages: [1] 2 3 ... 10
1
Applications / Re: XWP v1.0.16
« Last post by Martin Iturbide on Today at 01:41:56 am »
But I have no idea how to have the same information for DLLs files.
I was able to also have the "Module" tab on the DLLs by using Rich's improved OO and the procedure from this forum thread.
I changed all the DLLs on C:\OS2\DLL to XWPProgramFile

Regards
2
Applications / Re: XWP v1.0.16
« Last post by Martin Iturbide on Today at 01:16:53 am »
Hello Dariusz

I think that XWPProgramFile Class (or is it some other WPS Class?) has already something implemented (See picture) on the "Module" tab. But I have no idea how to have the same information for DLLs files.
What it would be great too, it to have a way to Ctrl+C that information.

Regards
3
Applications / Re: XWP v1.0.16
« Last post by Dariusz Piatkowski on Today at 12:52:50 am »
Rich,

New feature request: would you consider implementing BLDLEVEL file object pop-up functionality?

What I'm envisioning is the ability to right click on a DLL, or any object that does contain the BLDLEVEL information, and have this stuff either pop-up directly under some sort of 'Version' or 'BldLevel' menu entry, or perhaps another place such as under 'Properties'???
4
Multimedia / Re: mplayer - just stopped working...sort of...
« Last post by Dariusz Piatkowski on April 28, 2024, 08:01:50 pm »
Hello KO!

...
3. What's the value of '2D Acceleration' ?


"YES" on my machine


Then, your system should play a movie with 2D acceleration, that is, SNAP mode. Nevertheless, if it fails, your system or SNAP driver seem not to support 1080p with 2D acceleration. In order to verify this, how about other smaller clips than 1080p, such as 720p ?

Great pointer!!!

Sure enough, finding a few other videos I was able to play them through SNAP config, although that's not to say all 720s played, some would, some would not.

Then I remembered: the SNAP vidmem size is something I had tweaked in the past in order to free up max ram for my JFS cache (1G)...sure enough, I had it set to 18M, which for regular use was perfectly sufficient (1920x1200 x 2 heads). However, in this case, whether its the double-buffering or something else, perhaps this was causing me a problem?

I doubled up to 36M, and YUP...all of my 1080 vides play back just fine!!!

Eventually settled on 24M, which also happens to be the previous setting I had in place for a very long time...not sure why I had moved away from that, was probably experimenting with a larger JFS cache and just never remembered to bump that back up.

Anyways...sir: thank you for that spot-on remark!!!
5
Applications / Re: LarsenCommander - new test version
« Last post by Andi B. on April 28, 2024, 07:44:28 pm »
Speed tests with SSDs vary on my system. I've tested with -
Samsung SSD 850 PRO 256GB
Samsung SSD 870 EVO 2TB
Samsung SSD 860 QVO 1TB
Crucial CT500MX500SSD1

It's sometimes not clear why copying from one SSD to another is faster with some setting while it's a bit slower with another target or source. I ever thought the maximum throughput you can get with an OS/2 system is copy from CLI cause a GUI program with progress indicator will always lower performance (the progress indicator needs to be update while CLI copy only waits for disk to accept new data, CLI does not even check CTRL-C). To my findings this is still true with disks although now LCMD comes very close to CLI. But in the last months I've even found scenarios where copying with LCMD is much faster than CLI copy (which TTBOMK uses 4k fixed buffer).

You may think copying with LCMD should be faster when not much else is running at the same time. But I've even scenarios where copying is actually a bit faster when LCMD lost the focus and some other heavy task are running. Once I even need a reboot to get the copy speed from/to a specific source/target to the level I'm used to. It was about 20% slower for unknown reason before.

Bottom line is it needs a lot of tests to get reproducible results. In most scenarios you can't get the same full speed with LCMD than with CLI but we are very close to that. Facts based on my tests for single big files are -
- Samba is way slower than ftp (more than 1,5 times slower here), both via netdrive *)
- for SSDs and harddisks LCMD is not exactly as fast als CLI copy but very close to it
- Ramdisk is way slower than SSD or harddisks (JFS is faster than HPFS but still 3 times slower)
- Peak values may be very high cause of SSD (and JFS) cache

*) Samba is way faster than FTP with a lot of small files I think because of it's directory caching which FTP is missing
6
Applications / Re: LarsenCommander - new test version
« Last post by Dariusz Piatkowski on April 28, 2024, 06:05:07 pm »
Hi Andi,
...
File xfer performance wise, here are the results for movement of a test 800M AVI file:

1) from SAMBA share to ramdisk
OLD:  Peak=58,270K, Avg=43,550K
NEW: Peak=56,220K, Avg=46,516K

...so I'm thinking this is more about being network bound (1G LAN, but of course the Samba share box - NAS is the limitation here)

2) from ramdisk to SSD drive (Samsung 860 Evo, SATA)
OLD:  Peak= 82,788K, Avg=  45,545K
NEW: Peak=310,118K, Avg=220,910K
...

Repeat of the same performance tests for the newest version:

1) from SAMBA share to ramdisk
OLD: Peak=56,220K, Avg=46,516K
NEW: Peak=51,367K, Avg=45,832K

2) from ramdisk to SSD drive (Samsung 860 Evo, SATA)
OLD: Peak=310,118K, Avg=220,910K
NEW: Peak=503,901K, Avg=311,825K

...which naturally made my eyeballs nearly pop out b/c let's be honest, my SSD isn't that fast!!!

So a re-do produced the following NEW:
NEW: Peak=430,674K, Avg=183,007K

...which while still pretty high for a Peak, I suspect this has everything to do with my crazy ass JFS cache, which is 1G in size.

Couple more tests later though the higher Peak appears to be sustained, so perhaps there is a little bit more improvement here Andi!!!?

Thank you again!
7
General Discussion / Re: PMfax
« Last post by Neil Waldhauer on April 28, 2024, 03:21:41 pm »
The serial device drivers, USB, IBMCOM and COM all work fine in any position. All the position in Config.Sys does is determine which com port COM1, COM2, etc. is assigned to which device.

RMVIEW is voluntary, so if a device driver doesn't participate, RMVIEW will not show it.

BASEDEV statements are processed in an earlier pass. We've presented the process at Warpstock several times. They have to be correct, but their order compared to DEVICE= statements is not relevant.
8
General Discussion / Re: PMfax
« Last post by Andi B. on April 28, 2024, 10:40:55 am »
I've it in that order and it works. I've used serial devices on this system since ages. Both the original ones (COM1: COM2: on the standard addresses with PSCOM) and USB converter devices. Mind the PL2303 device lines which are now remed out. I needed to load it 4 times to use the up to 4 attached USB converters. Since about a year the usbcom.sys (v12.13?) from Davids package work with my devices. And usbcom.sys is now loaded only once in contrast to the PL2303 driver.

Code: [Select]
DEVICE=M:\OS2\BOOT\PSCOM.SYS /F

.....
BASEDEV=USBD.SYS
BASEDEV=USBXHCD.SYS
BASEDEV=USBXHCD.SYS
BASEDEV=USBXHCD.SYS
BASEDEV=USBXHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBUHCD.SYS
BASEDEV=USBUHCD.SYS
BASEDEV=USBUHCD.SYS
BASEDEV=USBUHCD.SYS
BASEDEV=USBEHCD.SYS
BASEDEV=USBEHCD.SYS
BASEDEV=USBEHCD.SYS
BASEDEV=USBEHCD.SYS

BASEDEV=USBHID.SYS
BASEDEV=USBKBD.SYS
REM ! DEVICE=P:\util\USBCOM_PL2303\usbcom.sys /V /M:1 /N:COM5 /Z
REM ! DEVICE=P:\util\USBCOM_PL2303\usbcom.sys /V /M:1 /N:COM6 /Z
REM ! DEVICE=P:\util\USBCOM_PL2303\usbcom.sys /V /M:1 /N:COM7 /Z
REM ! DEVICE=P:\util\USBCOM_PL2303\usbcom.sys /V /M:1 /N:COM8 /Z
REM ! DEVICE=M:\OS2\BOOT\USBCOM.SYS
DEVICE=M:\OS2\BOOT\USBCOM.SYS /M:4 /N:COM6 /Z

When I attach one or more usb converters 'mode com6:' 'mode com7:' shows me the attached working devices. I need the /Z option cause I don't use CTS/RTS/DTR/DSR (?) handshake I guess. But with a real modem attached I think you should enable hardware handshake. Anyway as long as 'mode comx:' does not show the device working you don't need to play with any higher level program. Maybe it's necessary to attach a working modem to recognize the handshake lines for that. So maybe testing with /Z first.

Btw. when I played the last time with modems probably more then a decade ago I can't get my US Robotics 56k to work again after it was laying around for 10 years or so. The even older ELSA 33k on the other hand did work with PMFAX.
9
General Discussion / Re: PMfax
« Last post by Dave Yeo on April 28, 2024, 04:05:28 am »
Ideally those basedev lines should precede the regular dev lines but the config.sys is parsed multiple times with the basedev lines parsed early, by  the mini-file system, so the result is a slightly slower boot.
I always had usbcom.sys towards the end of config.sys and it worked. Remming out the com.sys lines (and vcom.sys) for testing purposes seems the important step.
10
General Discussion / Re: PMfax
« Last post by Wayne A. Smith on April 28, 2024, 02:05:59 am »
OK, Neil, I've made those changes but haven't tested PMFax yet.

The one curious think I note is that these DEVICE lines separate the initial BASEDEV lines and the
BASEDEV=USBD.SYS
BASEDEV=USBEHCD.SYS
BASEDEV=USBEHCD.SYS
BASEDEV=USBXHCD.SYS
BASEDEV=USBHID.SYS
BASEDEV=USBKBD.SYS
BASEDEV=USBCDROM.ADD /CDS:1
BASEDEV=USBMSD.ADD /REMOVABLES:3 /FLOPPIES:1
lines. 

Is this a problem?  It would seem the the above lines ought to precede
DEVICE=C:\OS2\BOOT\USBCOM.SYS /M:3
DEVICE=C:\OS2\BOOT\USBRESMG.SYS
DEVICE=C:\OS2\BOOT\USBPRT.SYS
Pages: [1] 2 3 ... 10