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 - Roderick Klein

Pages: 1 2 [3] 4 5 ... 33
31
Setup & Installation / Re: OS2DASD hangs after 1st stage installation
« on: January 14, 2022, 08:54:27 pm »
Taje out the ACPI.PSD from yoru config.sys or add /VW switch and see if this fixes hanhg.
The hang is most likely occuring with the witch over from the MINIFSD code to the IFS code.

Roderick

32
Hardware / Re: New ArcaOS USB driver and Floppy drive
« on: January 10, 2022, 10:17:44 pm »
I ran into a problem. USB drive of floppy disks does not reread the floppy disk when accessing the disk. In the 16-bit version, everything works successfully.
What can be done to solve the problem?

Are you using the AN USB drivers or the Lars his USB drivers ?



Roderick

33
Storage / Re: JFS - Trap 0003 - anyone?
« on: January 09, 2022, 12:28:29 am »
Folks!

I figured I would inquire here first before logging a ticket for the AN folks on this JFS issue.

So the other day I had a weird situation: my nightly RSYNC job LOG needed to be "rotated" having grown to some 32M in size over the past couple of years. I decided to manually split it up into calendar year LOGs. I most likely had the file open in my editor while at the same time attempted to execute a CLI copy of that big file.

BAM!!!

JFS died with TRAP 0003...meltdown!

Following a power re-boot JFS did a check disk and uber quickly flashed some messages up on the screen about lost directories. The chkdsk forced an automated re-boot and a 2nd chkdsk run. At the end of what felt like the longest 5 mins ever I got back to my MAINT partition to discover that my 'lost+found' directory now had some 17k files. Clearly chkdsk found some directory problems and moved a boat-load of files into the 'lost+found' directory. Yikes!

Anywyas, I was aware that this is probably the worst JFS situation when directories are mangled. Now luckily for me I had a nightly backup (RSYNC...LOL), so I was able to recover just fine. The mangled directories turned out to be my Firefox and Thunderbird cache, thus the massive listing of files.

Now that I'm up and running again and spending a little time researching this I discovered the following description of a TRAP 0003:

Quote
TRAP 0003 - BREAKPOINT. This is a special instruction (INT 3) used in "debugging" software, which was left in the code either accidentally or by design. Contact software support.

Further on, the following is also available:

Quote
[G:\]help 1933

SYS1933: A program caused a breakpoint error.  The program was ended.

***

EXPLANATION: A program started an INT 3 instruction when it was not
being run by a debugger.

ACTION: Correct the program and retry the command.

I found this extremely interesting given that in this latest version of JFS AN announced a successful quashing of a JFS bug when operations on a file LARGER than the JFS CACHE would potentially trap.

In my case I am running a large 1G cache, so I do not think this to be the issue...however as I experiment with various MIN and MAX buffer settings I may have potentially ran into a problem there. Hard to tell and NO I have not tried to replicate this issue!!! ha....

Take a look at the attached TRAP screen...what do you guys make of it?

Thanks!

Is this under ArcaOS ? I ask this as I am not familiar with older OS/2 versions. But if you are running ArcaOS are you also dealing
the latest ACPI, JFS and OS2KRNL from Arca Noae ? They contain different fixes that can resolve a TRAP 3.
But I am not certain.

ROderick

34
Web applications / Re: The MicroWeb DOS web browser
« on: January 06, 2022, 11:27:31 pm »
Hi

I got this reply from Mike, the mTCP author.

Quote
I wrote mTCP to bring networking to my old computers.  Think about machines like the original IBM PC (1981), the PCjr (1983) and the PC AT.  mTCP works fine in an emulated machine, and possible even in a virtual DOS machine.  But it needs a packet driver which has direct and exclusive access to a network card.  And it provides its own TCP/IP implementation.

If you want to use the networking available in a DOS VDM the programs need to be rewritten to use those networking APIs directly.  I don't think that is a huge problem, but some quick Googling did not give me any information on what that network API even looks like.  Do you have any links on what the network API for DOS VDMs looks like?

Do you know by chance the API that the DOS VDM uses for networking?

Regards

Hmmm I do not know if this is even documented somewhere with some examples how to write code to acess this interface.
VDOSTCP.SYS is most likely the driver providing this interface...

https://www.betaarchive.com/forum/viewtopic.php?t=32026
Mentions:
IBM TCP/IP for DOS 2.1.1 Programmer's Toolkit

The very few times I used the WIN/OS2 TCP/IP stack it crashed my system most cases. So I am not 100% certain how stable it this VDM TCP/IP support.


Roderick

35
Web applications / Re: The MicroWeb DOS web browser
« on: January 05, 2022, 01:16:12 am »
Hi.

Today I read about this text web browser for DOS.
- https://github.com/jhhoward/MicroWeb/releases/download/v0.51/MICROWEB.EXE

It works on DOS full screen on my ArcaOS 5.0.7 VM, but I have no network under DOS.

Can someone please give me some tip or pointer on how to set the network on VDM DOS?

Regards

As Ibrahim already explained TCP/IP support is working in the DOS VDM.
I think the issue is that the web browser is expecting a different interface then can be found in the DOS VDM.

https://github.com/jhhoward/MicroWeb

Network setup
MicroWeb uses Michael Brutman's mTCP networking library for the network stack. You will need a DOS packet driver relevant to your network interface. You can read more about configuring DOS networking here.

I do not know how you can get the Brutman mTCP interface to work. https://www.brutman.com/mTCP/
Very quickly reading I think its expects an Ethernet driver under DOS to talk to. But I only read this extremely quickly this link.

Roderick

37
Web applications / Re: QT5 simplebrowser
« on: November 20, 2021, 07:36:56 pm »
Seems I did have one system where it did seem to make a difference, but maybe I'm misremembering. In this case it may well have been a coincidence where the reboot fixed things.
I'm not sure if IBM finished the high memory support and a theory is that too high a VAL value on some hardware might intrude into kernel memory space. This system for example has 3,241 MB's memory accessible to the system, which doesn't leave much room above 3072 VAL value for the JFS cache etc. I'd assume a video card could eat up more memory at the top end.

Few people know that this virtualaddresslimit was already build into Warpserver advanced. It was only later this code was moved into the _W4 kernel. In my book the code is finished. IBM introduced high memory for stuff such as DB2, which could use this high memory.
Now does the code contain bugs, possible. But we need to have proper debug data for that.

Roderick

38
Web applications / Re: QT5 simplebrowser
« on: November 19, 2021, 08:22:44 pm »
Here, after the last big update to netlabs.rel, my system became very unstable.

Try to rollback nss* and nspr. I have installed almost all packs from  netlabs.rel  -  everything quite stable.

It's weird, I updated nss* and nspr4 quite a while back on my netlabs-exp partition. The browser started just vanishing, no trp, no popuplog entries and attempting to trace it down was futile. Now on that partition, after updating libc etc, the browser frequently crashes in various places, usually related to committing memory in various places.
This partition using netlabs-rel became very unstable after the big update, fixed partially by lowering my VIRTUALADDRESSLIMIT from 3072 to 2560 but still so frustrating that I formatted it and restored a backup, back to stability.
Seems that a combination of the libc and NSPR4 and NSS updates led to the extreme instability. Previously I had tried the newer NSPR4 and NSS on this partition and had the vanishing browser thing so rolled back.
I've also tested by rebuilding the browser with the updated NSPR4 and NSS and things were stable.
So now I'm testing rebuilding NSPR4 and NSS and just replaced the NSPR4 DLL's as a test. So far things seem stable.
I continue testing and updating the other files. Anyone who wants to play along, here's my newly built NSPR4 DLL's, they're Pentium 4 with -mtune=generic raw builds, so still have the debugging stuff included, could be lxlited, my build didn't create dbg files for these. Unlock and replace the ones in @unixroot/usr/lib and reboot to use them. Haven't tried marking them for high memory yet. If you want to revert, use ANPM or YUM to reinstall.
Be good if someone testing the Otter beta tests too.

I just have one question has there ever been any hard evidence for fiddeling with the virtual address limit really increases or decreases applications stability ? As in something of debug trace to point that this *actually* trace. To be honest I have a hard time feeling this contributes to making applications stable or more stable.

I can see where increasing the amount of virtual memory you can have an application leak memory longer. But reducing virtual address limit ?

Roderick

39
Games / Re: DOS VDM - USB and Game port Gamepad support
« on: November 17, 2021, 09:04:36 pm »
Seems to me that adding joystick support to SDL would be relatively easy, at least compared to writing device drivers. I'd assume that it would also give joystick support to DosBox. I'm not really a programmer so haven't looked into it.

Hi Dave!

It shows that I'm a Luudite when it comes to software technobabble.
(The reason I'm a hardware geek)

Of course SDL = Simple DirectMedia Layer - and from reading the Wikipedia Wiki, it seems DosBox is running the SDL libraries and is essentially an SDL program. Duh!

I reached out to Jochen Schäfer, whose porting DosBox to ask two questions:

1) In his ports, is the OS/2 DosBox code related to Input Devices still present? I noted in the .conf file for the ArcaOs inplementation a section exists under "Joysticks", but I'm sure would not work if we have no frontend USB Input driver under ArcaOS. Addressing your comment, if it is already there, NFAR, which is why I suggested this may be a solution to the problem presented, related to DOS.

2) I also wanted to know if he had some idea of how well Input Devices worked when captured by DosBox (timing, response, implementation), under other OS's, if he had some knowledge in the matter? I agree with Roderick, that would be a key factor as to whether DosBox or a native VBM would be an option.

2Roderick: I also had a follow-up question - for the frontend native USB driver, would there be any different programming required in the ArcaOS input driver to address either a VDM or DosBox? If not, the worst that could happen, if code exists in the current ArcaOS DosBox, is that it works poorly on capture of the Input device, and then a VDM could be developed, as a follow-on.
<SNIP done by Roderick>

I can not speak for the USB driver itself in ArcaOS. What I can say is that using a library for DOSbox (a DLL) to talk to the USB joystick or gamepad VIA USBRESMGR might work.

However what is a key issue is if you want to get the DOS VDM to work. That is slightly more complicated!

You see a DLL running in OS/2 will not work. Since the VDM can not talk to that DLL.

First you have the DOS game.

That would "listen" to hex port 301 (I think was the Joystick hex I/O address under DOS).

A VDD (Virtual Device driver) would provide this port 301. This would also emulate the old joy stick.
What you need then is the next layer, a PDD (physicall device driver). This would know how to "talk" to the USB device's you want to communicate with.

A VDD loaded in OS/2 CAN NOT communicate with a DLL running in OS/2. At least not that I am aware off.
And even if it could I do not know how timing sensitive this would become.

DOSbox might be a whole different story perfomance wise. I have experience with this.

To put it differently. A driver such as USBRESMGR.SYS is NOT realy a device DRIVER. Its purely a ring 3 interface (application level) to have a DLL talk to a USB device. That is why a scanner app such as TAME can do this. But for more timing sensitive applications such a Joystick I  have some doubts if such a DLL can work. But I understand somebody want to see how well this works on Windows.

Roderick

Roderick

40
Games / Re: DOS VDM - USB and Game port Gamepad support
« on: November 16, 2021, 04:26:52 pm »
Seems to me that adding joystick support to SDL would be relatively easy, at least compared to writing device drivers. I'd assume that it would also give joystick support to DosBox. I'm not really a programmer so haven't looked into it.

HI Dave!

Probably wouldn't do much good in SDL, as I've seen few games with complex input requireemnts (maybe gamepad support?)

Interestingly I did some further reading in the DosBox Wiki on Wikipedia and found some interesting facts:

https://en.wikipedia.org/wiki/DOSBox#Hardware_emulation

DOSBox uses the Simple DirectMedia Layer external library to not only build new versions of DOSBox from source, but also handle graphics, audio, and input devices.

It can simulate the PC joystick port, with limited options being to emulate one joystick with four axes and four buttons; one gamepad with two axes and six buttons; two joysticks each with two axes and two buttons; a Thrustmaster Flight Control System joystick that has three axes, four buttons, and a hat switch; and a CH Flightstick with four axes, six buttons that can be pressed only one at a time, and a hat switch. Newer joysticks and gamepads will need to use one of these configurations to function.


So actually a very sophisticated piece of software, building on the original Simple DirectMedia layer external library.

As we have an ArcaOS version of DosBox which works well already (I have over 60 games running under DosBox). it seems the problem may be simplified to how to get USB input devices to address ArcaOS, and how to get the OS to address DosBox, as the architecture already exists within the emulator, as DosBox is really the standard go to now for all platforms, for people who want to run most DOS games at least. Don't know about any other legacy DOS programs.

But it is really Games and Input devices were talking here, so it may be very applicable.

I'm not a programmer as well, so I don't know how much it would simplify or complicate matters. I know Joystick drivers were written in the past to address gameport devices under OS/2. Perhaps they could be a framework to start the process.

Best as always!

M

I really wonder how good a DLL is going to work timing wise and then the commands from the USB gamepad or joystick have to end up with the game.
This is extremely timing sensitive. I doubt Dosbox with a ring 3 DLL and usbresmgr.sys can be responsive enough and that the communication becomes to slow.
When you hit the firebutton the game should receive and process this command ASAP.

The DOS VDM I think has better performance then DOSbox.

Roderick

41
Games / Re: DOS VDM - USB and Game port Gamepad support
« on: November 16, 2021, 04:14:43 pm »
Thanks.

I guess the idea will be something like this graphic, to have some gamepad/joystick support for ArcaOS with an USB gamepad.
The red squares are the things that do not exist.

Regards

If you want the DOS VDM and the VDD communicate with the USB joystick you will need to have the knowlegde of the SDL library in a driver. That can be a PDD or a VDD. That is tricky part of supporting the VDM. And the VDD has to have code to "trap" I/O instructions so they are routed to the USB device.

Roderick

42
Web applications / Re: QT5 simplebrowser
« on: November 15, 2021, 10:24:14 am »
Roderick stated the beta is advancing, so let's hope for the best.

About setting a new goal: I could image that it is difficult to port this application in a stepped approach, for example with reduced functionality as an initial drop and then adding things. That is possibly more work than porting it all at once.

Effectively the Otter Browser has been ported. One optional things BWW was thinking of adding (when the USB stack of AN has all support needed) was to look at adding webcam support to the browser. (The browser needs to know how to talk to which device driver).

The goal of currently limited beta test is to improve stability, it still crashes the browser and the stability needs to be improvement from my perspective.

Roderick

43
Web applications / Re: QT5 simplebrowser
« on: November 14, 2021, 08:58:15 pm »
The 49.000 Euro was an estimate, in the mean time loads of other DLL's where updated and added to make the new browser.
As for the beta program I am picking up on that again...

Things have slowed down mainly because of me... I have been having some things happen in my personal live that took away my attention from the browser.  Silvan and Herwig have both had to deal with a private issue.

And while funding has flowed into the webshop of BWW donations via OS2VOICE have mostly dried up. Also duo to my private situation but in genereal the level of donations has been dropping. This has resulted in Dmitry also seeking other work. I can only we say, we warned of this impending issue...

Anyway the browser beta is moving forward again!

Roderick Klein

44
Applications / Re: VIDEO_MODE_RESTRICTION
« on: November 11, 2021, 04:01:37 pm »
It has been a long time but it used to work to give DOS sessions more memory. Now I can't even remember how to measure memory in a DOS session.

mem.exe ? :-)

45
Storage / Re: JFS cache sizing, and system "speed-up"
« on: October 29, 2021, 01:06:28 pm »
Hi Doug,

...
Quote
The apps are loading consistently faster, on multiple attempts.

A lot of that "improvement" depends on timing. If the program parts have not been flushed from the cache, the load time is faster (even when using a small cache). Using a larger cache does increase the probability that most of it will still be there, but it depends on what you do between starts...

So this point here is actually the crux of what I was trying to improve upon.

Consider a set of applications that you normally run, in my case that normally is a mix of:

1) FF
2) Thunderbird
3) Lotus 1-2-3
4) AOO
5) VSE & IBMCPP & GCC (compilation)
6) PMView

Therefore, by increasing the size of the cache (if the upper memory is rarely used otherwise) allows me to try to pull in more of that working set into the cache, and hopefully convert that into a quicker responding system.

In my case, that appears to have been the result of tripling the size of the cache, with the matching increase in the buffer settings.

Of course that that not mean ALL of these apps and their data (heck, FF has a 512M disk cache) are always there, the cache will of course always continue to be shuffled around as needed.

Why is standard Sysbench not sufficient ? Its much more consistant. It tests small file I/O large file I/O.  Also it measures the timing very accurate!

Pages: 1 2 [3] 4 5 ... 33