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 ... 64
Internet / Re: lost in Hobbes
« on: June 28, 2022, 02:45:57 pm »
Meshell-os2.wpi has been moved to:

automatically, to the requested directory. So where is the problem ?

General Discussion / Re: eCS 2.2 purchase
« on: June 11, 2022, 08:31:14 pm »
No. Either you know somebody that lends you the USB stick that has ArcaOS 5.1 on it or you will have to buy ArcaOS. And we are back to zero.

General Discussion / Re: eCS 2.2 purchase
« on: June 10, 2022, 10:48:04 am »
You will never know how much of system memory (RAM) is mapped below the 4 GB physical address line.

Booting in UEFI mode, you will know how much memory is mapped below 4GB, though there is sometimes problems with fragmentation and not being able to use it all. One problem with the newest systems is starting to be having the video buffer mapped above 4 GB, which makes the system unusable to OS/2.

1) Yeah. Once you have bought your new computer you can then check if it works with OS/2. Unless you find someone beforehand that has the very same computer and also uses OS/2. Great deal.

2) "Video Buffer above 4 GB (physical address line)" is a perfect example of PC manufacturers no longer even considering 32-bit OSes, left alone 16-bit OSes. It would have been a better choice if AN had accepted this fact and would have become more involved with the Virtual Box team to ensure that OS/2 will continue to run virtualized. But they decided differently.

I know one thing for sure: if my fairly old desktop computer dies, I will move away from OS/2 altogether. I already do all current development under an eCS guest running under Virtualbox.

General Discussion / Re: eCS 2.2 purchase
« on: June 09, 2022, 04:42:28 pm »
You will never know how much of system memory (RAM) is mapped below the 4 GB physical address line.

Newer systems tend to reserve a lot of the physical memory space below 4 GB presumably for the PCI(e) bus so that you can use older 32-bit PCI cards/devices, potentially requiring large amounts of physical address space (like, say a 32-bit PCI graphics card with 2 GB of video memory: it needs 2 GB of physical address space below the 4 GB address line). Newer 64-bit PCI cards are of course not suffering from this problem.

It's just a fact that every modern OS is 64-bit by now, which means, it has no problem accessing system memory if it is mapped to physical addresses beyond 4 GB and therefore it is not affected by this limit. And therefore manufacturers no longer care about this limit.

Setup & Installation / Re: OS/4 Problem SVN6139
« on: June 08, 2022, 08:59:51 pm »
... 8 cores. Looks like there is something wrong with the thread scheduling (it blocks for extended periods).

Interesting, I run with 4 cores - newer seen.  Any details?

I am using the VAC compiler from time to time. It comes with an IDE called "Integrated Workframe" (IWF).
The IWF implements a couple of WPS classes, in particular one to display all "parts" of the project in a WPS folder.
You can open different views of that WPS folder much like any other WPS folder: icon, tree, details view.
A "part" is normally a file in an ordinary filesystem, however, the IWF can be extended and generalizes the concept of a "part". That said, I wrote an extension to display the contents of ZIP files within the WPS folder where the "directory" is the ZIP file and the "files" are the archive files within that ZIP file.
Now, I have linked 3 ZIP files into one project and the overall number of archive files is > 9000. Unfortunately, the IWF is not very performant and in addition, it starts a new thread for each view of the WPS folder (you can concurrently open multiple views of the same WPS folder, again, much like an ordinary WPS folder). I used the "unzip" DLL interface to query and list the archive files within the ZIP file and maybe, that also eats up quite some processing power as the "unzip" DLL interface will be called for as many views as there are open (even though, of course, the ZIP content is the very same).

What I now observe is this: the time to display all "parts" of a WPS view is already pretty slow with the OS/2 kernel (takes more than 90 seconds to display all "parts") but it becomes VERY slow with the OS/4 kernel in place where it takes much longer (3 minutes or more). From the way those IWF WPS classes work, I'd think that this has either something to do with threading or with some blocking semaphores waiting for something.
What I can see is that OS/4 activates about all kernels on my 8 core machine when that view refresh happens whereas the OS/2 kernel will typically only use 3 kernels with the rest idling (I guess ACPI.PSD takes care of that but I am of course using OS4APIC.PSD+ACPI4.BPD when I am using the OS/4 kernel).
What I additionally see with the TOP tool is that with the OS/2 kernel, one process will shortly monopolize the processing power and that will then quickly move to the next process monopolizing the processing power and so on and so forth (so, the load is not only concentrated on PMSHELL.EXE under whose context the WPS classes are executing).
With the OS/4 kernel, one process will monopolize the processing power for a much longer time.

Setup & Installation / Re: OS/4 Problem SVN6139
« on: June 07, 2022, 11:44:48 pm »
Specifying VALIMIT=3072 seems to fix the trap that I was experiencing. But I have probs running with 8 cores. Looks like there is something wrong with the thread scheduling (it blocks for extended periods).

Setup & Installation / Re: OS/4 Problem SVN6139
« on: June 07, 2022, 11:09:49 pm »
1) latest OS/4 kernel is 6140. However, I experience a trap on bootup. I don´t know why. I created a trap dump but the dump formatter (that comes with eCS) cannot properly decode the dump. the OS/4 kernel seems to be not equivalent in this respect.

2) are you sure it is "E:\OS2BOOT \pmDDK.SYS" ? Looks like that should be "E:\OS2\BOOT\PMDDK.SYS". Or is that a typo ?

3) have you also installed ALL other drivers that come with the OS/4 zip ? OS4APIC.PSD, SCREEN03.SYS, OEMHLP.BPD ?

4) you might also be forced to install ACPI4.BPD in case your system no longer has working MP tables (this is something that predates the ACPI tables and provides a subset of functionality of the ACPI tables to support a multi-core/multi-processor system). However, that driver is hard to find but drop me a private note and I can send that to you.

I doubt that you need to patch something (likely, you mean ACPI.PSD). And the ACPI.PSD that can be patched is an outdated version, that is not recommended anyways.

The trap in PMMERGE happens in a routine called "MoveAndXform".
It happens when copying a string via the "movsd" instruction.
The exception code is C000005 which means "XCPT_ACCESS_VIOLATION".
P1 = 2 which means XCPT_WRITE_ACCESS which means the target buffer is obviously too small to receive the string.
What's more important: "MoveAndXform" calls routines "GetFaceName" and "GetCellTransform" which seems to indicate that this this is all about using fonts and displaying them in a window.

So I think, Roderick is correct and this is a problem with using fonts. The fix might be to set a proper "default font", maybe the font name of the font that is being used is too long or some such.
I seem to remember that there was a OS2SYS.INI setting for this. An alternative might be to drop a new font onto the program window (it it opens at all).

What I would try is to properly install the fonts that come with the program. Open the fonts palette, select "edit" button, then select "Add..." button and browse to the programs dir to select "AHDPHON.AFM" and "AHDPHONI.AFM". This will install the fonts to the \PSFONTS folder.

Unfortunately, I cannot test the prog as I don't have the encyclopedia data as such.
One thing you obviously need to do is to set up env vars DUX_AHD_DATA and DUX_ENC_DATA to point to the directory where you have the encyclopedia data.

I have installed AHD_PATH_2-0 and then copied over the contents of AHD_PATH_2-02 and I don't experience any crashes but the prog will not display anything either (due to the missing encyclopedia data).

Games / Re: DOS VDM - USB and Game port Gamepad support
« on: May 28, 2022, 03:55:17 pm »
Use Panorama, but as a test, disable the screen buffer (it's in the screen settings). If that helps then unfortunately, you will have lousy overall video performance.

Hardware / Re: ArcaOS 5.1 UEFI support - GOP?
« on: May 25, 2022, 02:28:15 pm »
I understand that bhyve is a hypervisor, a "host" so to say, for running a "guest" in a VM (much like Virtualbox ?).

So I understand that the "host" relies on GOP but why would the "guest" (ArcaOS in this case) need GOP for just that ?
Wouldn't you be able to run plain DOS as a "guest" (and surely, DOS knows nothing about UEFI or GOP) ?

Or is this necessary to support screen output during the ArcaOS bootup phase ?

The W4 kernel is the old single core kernel. But it is a 32-bit kernel, just like the SMP kernel. The W4 kernel only supports the old 8259a interrupt controller (predating local and IO APIC).
If I try the SMP kernel, it works ok. As I said, it is only a prob with the W4 kernel.

I have a setup with the W4 kernel (to develop and debug WPS classes). That fails with PMMERGE6111. On system start, the system will trap in PMDD with PMMERGE6111 in place. Reverting back to the original PMMERGE fixes the problem

Where is it listed what USB 12.12 fixes ?

Seriously, we all know that by now, 80% of OS/2 is trial and error. It`s worth giving it a try and note down the results (worked / made things worse / did not make a difference).

Games / Re: DOS VDM - USB and Game port Gamepad support
« on: May 21, 2022, 09:32:43 am »
I'm actually running tests on a tower, with an AMD hexcore processor and 3 Gb of usable memory installed (actually 8 GB in the system, but ArcaOS is not seeing the rest). Occasionally after installing the gamepad package previous to 2022-05-17 and with the current one, I've gotten a black screen trap, attempting to start a game with one of the xevents packages active.

I've attached a photo of the trap screen, if it is of any help - I have not determined a particular reason why it happens at the moment as I've only seen it four times and Best!


It`s a trap 3 which means it is a hard coded int3 breakpoint, put there deliberately by the programmer. The reason it fires is that something is calling/jumping to address 1000:0, that is, a ZERO offset. Since this is not expected and likely is a programmer error in that somebody tries to do an indirect near call/jump with a near NULL pointer, that is caught by this breakpoint.
Note that the trap address is 1000:0001 because for an int3 the trap screen will show the address of the instruction following the int3 and the int3 instruction is 1 byte long.

In order to analyze that, you´d need a trap dump in order to find out what code tried to call/jump to 1000:0 (or rather do an indirect near call/jump with a near NULL pointer).

Thinking about it: selector 1000 points to the DOSCODE segment that contains many low level kernel routines. And the DevHelp Routine is located in that segment (and all the subroutines it calls). The DevHelp Routine in turn is the main entry point for any device driver services and therefore used by about any device driver and a pointer to the DevHelp Routine is passed to each device driver on driver load. If that pointer is not properly saved or subsequently accidentally overwritten then you might see that trap.

So if it`s about a driver, Wim should check that the saved DevHelp pointer was not accidentally overwritten (the offset part of it) by a NULL value.

Programming / Re: getting a single keypress?
« on: May 21, 2022, 07:26:45 am »
And why can't you use the standard RTL function "getchar"? Is that not available?

Pages: [1] 2 3 ... 64