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 ... 78 79 [80] 81 82
1186
Article Discussions / Re: [Arca Noae] Checked your disk lately?
« on: December 07, 2015, 06:16:25 am »
Interesting. I did not know that the USB repository is now split. I only know the one at Netlabs.

Lars

1187
General Discussion / Re: XEU.com and eComStation
« on: July 21, 2015, 08:12:28 pm »
Hi Joachim,

So it appears that the USB keyboard problem is what I mentioned earlier, a lack of communication between USBKBD.SYS and KEYBOARD.DCP because the Chinese keyboard need a special translate table for which there is no provision.  Sounds as if your team are in for a serious re-write of all that area, just make sure all the changes are tested against non Chinese installs before you release them.

From what I can tell from the USBKBD.SYS code it doesn't do any translation at all. It only creates scan codes.
I guess the translation to characters always happens somewhere else, also for any other keyboard.

1188
What's the point in building drivers from the DDK sources and releasing them as freeware ?

1) the drivers already exist and are part of the OS/2 product. Just rebuilding them and declaring them as freeware adds nothing.
2) the DDK sources might be outdated with regards to the binary drivers that come with OS/2. This is even very likely (I am sure this is the case for OS2CDROM.DMD for example).
In other words: you might run into a whole bunch of bugs and problems using these built drivers that where already solved.

The only reason why print01.sys exists on hobbes is because a functional limitiation was removed that existed in print01.sys and people where "desperate" for a fix.
You still run the risk of the DDK code not being up-to-date.

I have already gone through this nightmare for all the USB drivers. You are just opening a can of worms.

1189
Programming / Re: Presentation Manager - About PM DLL's
« on: March 08, 2015, 09:56:03 pm »
Plain Forwarder DLLs contain no code but just references to other DLLs which actually implement the function. The loader that loads the executable that in turn loads the forwarder DLL will replace the entry points in the executable not by the entry point of the forwarder DLL but rather by the entry point of the DLL the forwarder DLL refers to (after all that is the purpose of a forwarder DLL).

Why ?  Well maybe because the designers of PM decided to stuff everything into a single DLL "PMMERGE.DLL". But at that point in time there where multiple applications around that referred to file "PMWIN.DLL" (and others like "PMDRAG.DLL" for example) instead. In order to ensure that those applications would continue to work, "PMWIN.DLL" was made a forwarder DLL.
By the way: libc also follows this concept, libc*.dll are all forwarder DLLs except for the latest version that you have installed. You can tell by the file size: the latest version of libc*.dll is about 1.3 MBytes in size while the others are only 150 kByte or less in size. At least they started doing this with version libc06.dll.

1190
Applications / Re: AOOo 4111GA does not install libc066
« on: February 28, 2015, 12:45:49 pm »
Oh, thanks a lot. I don't have a clue about this yum/rpm stuff. I did as you suggested. At least that worked and downloaded and installed a bunch of things I don't know about.

I had already found the ftp://ftp.netlabs.org/pub/gcc/libc-0_6_6-csd6.wpi (or rather, the equivalent zip file) and installed that which cured the problem with AOOo 4111GA.

To be honest: I don't like the yum/rpm stuff as I cannot see what it is doing and how to fix problems with it. But I don't want to start a flame war ...

1191
Applications / AOOo 4111GA does not install libc066
« on: February 22, 2015, 08:49:39 pm »
I tried the WPI method (rpm WPI on same directory as the base WPI): it does not work
I then tried to run yum with the command line given in the readme: I get told that Python cannot find urlgrabber and then that's it

libc066.dll is not installed and therefore none of the applications works.

Can someone tell me where to get libc066.dll ?

1192
Hardware / Re: Motherboard woes
« on: January 04, 2015, 01:34:33 pm »

Quote
Currently the USB stack is getting its last bugs taken out and the OS2AHCI driver being worked on.

It is my opinion that the USB stack will never work properly, until it is completely rewritten. The guys who work on it have done wonderful things, but they seem to be constrained by the original design. USB 3.0 may help to get over that, but it should have been finished about 2 years ago.

I wouldn't say that the stack design is the problem. The problem is that the USB Driver code from the DDK that we have is outdated and is also full of bugs where you never know if these bugs are also in the latest drivers from IBM or not.
I think I fixed around 8 to 10 bugs in USBUHCD.SYS+USBOHCD.SYS+USBEHCD.SYS+USBD.SYS (including bugs that RĂ¼diger Ihle had already found). And I reworked USBEHCD.SYS to make isochronous transfer work (which Wim actually implemented, many thanks to him !) which apparently was never properly implemented and therefore not tested at all.
I am currently doing a major rework on USBMSD.ADD to allow to use USB sticks formatted under Windows and fix problems with existing devices. Again, that driver contained a couple of bugs. And it's the worst/messiest piece of SW I have seen in a tong time.
Nonetheless, rewriting the whole stack will never happen. It's much too much work. Forget it.
 

1193
Programming / Re: New OS/4 kernel :: SVN4222
« on: August 21, 2014, 11:25:21 pm »
I can easily think of a scenario where use of MTRRs become a problem compared to PAT.
MTRR mem. type regions have to be of size "power of 2" and there are restrictions regarding overlapping regions. PAT is fine granular down to the 4 kByte memory page and it can"override" the underlying MTRR memory type to a certain extent.

1194
Programming / Re: New OS/4 kernel :: SVN4222
« on: August 21, 2014, 11:25:29 am »
The latest  versions of Panorama also support PAT where MTRRs cannot be set up properly.
I'd appreciate a less biased information flow.
To be more precise: PAT support is in GRADD.SYS which is used by Panorama.

1195
Hi Lars

I just pushed the files to github: https://github.com/OS2World/UTIL-WPS-HWMan.

My only observation is that the git client didn't recognize any change on "hwman.xh" when I replace it over the original final.  Was it any change on it?

Thanks for sharing.

It's well possible that hwman.xh did not change. In any case, it would be regenerated from file hwman.idl by the SOM compiler.

1196
I just took the chance to rework the HW Manager replacement WPS class (HWMAN) and uploaded to Hobbes.
Who cares about HW manager ? Probably nobody. So what's the real deal ?
It comes with full source code that is extensively commented. It's meant for everybody who is interested in starting WPS programming.
That said, I tried to comment the stuff that is not really documented anywhere ...

Martin (if you are reading), I think it is a good idea if you update GITHUB with this new update ...

Lars

1197
Hardware / Re: ecs on actual desktop PC
« on: May 29, 2014, 08:48:47 pm »
pci.exe reports this for the graphics card:
Vendor 10DEh NVIDIA Corporation
Device 0FC6h GK107 [GeForce GTX 650]

I am using Panorama 1.06 (the latest version, currently).
I have not tried with SNAP but I expect problems on an SMP system. At least that's what is said about SNAP and SMP systems. I don't know if SNAP supports this NVidia chip. Is there a readme for SNAP that could tell me ?

Is there some BETA version of SNAP that has fixed SMP support that I could test ? I'd test even if SNAP only offers VESA support on this chipset.


1198
Hardware / Re: ecs on actual desktop PC
« on: May 29, 2014, 11:29:46 am »
In the meantime I have found out this:

1) I had "AHCI BIOS" enabled in UEFI BIOS. What it does is to enable some AHCI BIOS that shows which hard disks/CD-ROMs are connected to the AHCI ports and if SMART is enabled for them, and obviously some other stuff. Once I disabled that I was able to boot the eCS 2.2 beta DVD even in AHCI mode.
Note: disabling "AHCI BIOS" did NOT mean to disable AHCI ! There was another UEFI BIOS configuration option to select among IDE compatibility/RAID/AHCI. THIS is the option that selects if you use AHCI (or IDE compatibility mode instead).

2) eCS 2.2 beta uses the 14.106 kernel. It looks like this kernel fixes a couple of things compared to the 14.105 kernel that came with eCS 2.1. I'd say it's the best kernel (and also the last kernel ever distributed). I am using all 8 cores and that works fine too.

3) On this MOBO, ACPI is a necessity. If I don't use ACPI.PSD on this MOBO, the kernel will trap right away already on system start.
The eCS 2.1 install CD does not enforce the use of ACPI.PSD and even if it did, the version of ACPI.PSD that was delivered with eCS 2.1 was still heavily broken. eCS 2.2 on the other hand selects ACPI.PSD as a default and it's also the 3.22.03 version which is the latest at present date. It works considerably better than early versions of ACPI.PSD.

4) if you have AHCI enabled you can and should set up the installation process to ONLY use the OS2AHCI.ADD driver. That is you neither need DANIS506.ADD nor DANIATAPI.FLT nor the IBM pendants and you can deselect these drivers already in the custom installation menu. However you might need to specify the /!r parameter on the OS2AHCI.ADD command line. This will prevent the AHCI ports from being reset. Resetting the AHCI ports results in a boot hang on my system.

In the meantime I have enabled "native command queueing" (NCQ) by specifying the /f /n parameters for OS2AHCI.ADD. Works like a charm. I am using OS2AHCI.ADD version 1.32 which is the latest one at current date. I seem to remember that eCS 2.2 beta DVD also has this version.

Lars

1199
Utilities / Re: Flash 0.4.2 - 24.02.2014.
« on: March 05, 2014, 08:26:56 pm »
I know.  There is no trap screen. If it is possible to log something that would be helpful via the com port I can do that.

Do you have a sound driver installed ? If yes, I suggest to REM it out in config.sys and see if the trap/reboot goes away.

1200
Hardware / Re: Two Sound Cards on OS/2-eCS
« on: March 05, 2014, 08:18:25 pm »
Thanks for the replies.

Sorry, I didn't actually mean two "cards" , I actually mean two "chipsets", I just noticed I was not clear. But I understand more about it now. But I think we are missing some tool to administrate the sound cards a Windows has.... but I think we need first to have more audio drivers :)

I also want to test the test USBAudio drivers, that's why I try to figure it out how to mnage two chipsets on OS/2-eCS. But I still can not make the USB audio devices that I have to work yet.

1) There IS a tool to administer sound cards in OS/2. You will find it as "Multimedia Configuration" in the "System Configuration" folder.

2) Multiple sound cards: this is a bit involved. When you install a sound driver, apart from other things, the MMPM2.INI file in the \MMOS2 folder will be updated. That file creates sound devices with names as Waveaudio01and associates these devices with the real device driver name like say USBAUD1$ and therefore with a real device driver.
If you had more than 1 of the very same sound card there is a logic to assign device driver names, the first one would be USBAUD1$, the next one would be USBAUD2$. Again, each device driver name is associated with a distinct device name: USBAUD1$ -> Waveaudio01, USBAUD2$-> Waveaudio02 etc.
The device names are subsequently used by applications and even the REXX MMPM API to say play a sound file on a specific sound device. For applications there exist API calls to query what devices (device names) exist in a system, an application can therefore build up a choice list to allow the user to pick a specific device.

Just to mention it: USBAUDIO.SYS has a fixed device driver device name of USBAUD1$. In short: you will only be able to load one instance of USBAUDIO.SYS.
However that is no limitation as USBAUDIO.SYS itself can handle multiple USB audio devices. However it will only ever pick the "first" (where "first" would be the one that was found first on the USB bus) USB device to play etc. as there is no selection logic in USBAUDIO.SYS to pick a specific USB audio device. If you unplug a device, USBAUDIO.SYS will pick the next available USB audio device remaining.

Lars

Pages: 1 ... 78 79 [80] 81 82