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 - Dave Yeo

Pages: 1 ... 11 12 [13] 14 15 ... 196
181
Games / Re: Drilling Billy - Problem running the exe
« on: December 20, 2020, 07:10:24 pm »
Not sure about EMX/GCC but for kLIBC/GCC (basically all GCC versions above 3.3.5), yes it uses HLL debug info and mostly works in the IBM debuggers. I understand that there are slight problems at times with how the stack is handled and dmik had to work around GCC's object format of AOUT not having big enough fields for some of the HLL stuff creating warnings like,
Code: [Select]
20:00.87 emxomf warning: Input file 'K:\var\temp/ccTjZZujasXXXXXX' has more HLL
debug types than we can index in PUBDEF and EXTDEF records.
but it generally works in the debugger. Unluckily I don't really know much about using the debugger.

182
Hardware / Re: Snap Vs Panorama - Refresh rate problem.
« on: December 20, 2020, 06:52:41 pm »
As Roderick said, the biggest problem is that the old Snap wasn't SMP safe as the MTRR registers need to be set for each CPU. Some BIOS's would correctly set them up, others left it to the operating systems drivers. I take it you are using old hardware, so most likely they'll be stable and fast for you.
Really an issue should be opened at Arca Noae as it is clearly a regression to not save the refresh rate. Most of us are using digital monitors where refresh rate doesn't matter.

183
Multimedia / Re: again on Uniaud
« on: December 20, 2020, 09:54:31 am »
Try adding "SET KAI_AUTOMODE=DART" without quotes to config.sys, reboot and test.

184
Hardware / Re: Snap Vs Panorama - Refresh rate problem.
« on: December 20, 2020, 09:49:41 am »
Sounds like a defect or regression. Try installing https://hobbes.nmsu.edu/download/pub/os2/system/drivers/video/snap-os2-3.1.8.zip and testing. Likely lots of complaining about older files and you have to enter the free registration.

185
Web applications / Re: Seamonkey that plays well with firefox 45.9
« on: December 20, 2020, 09:23:39 am »
This will be a reoccurring problem as libraries get updated with API changes. Next is FFmpeg libs. Next version currently in netlabs-exp is not compatible with Mozilla so will need to install ffmpeg-libs-legacy or such. As the FFmpeg libs are used dynamically, the need will be harder to be noticed as some stuff will just stop working.

186
Internet / Re: Curious what the problem is making new firefox versions.
« on: December 20, 2020, 09:15:06 am »
It is currently barely capable of being built, carefully.

Yeah I know it's still under development just curious if it would solve the memory issue if/when it gets functional or that is just something fundamental.

Well browsers are just using more and more memory. I'd assume that it'll keep working for quite a while, especially if the users are careful not to have a hundred tabs open but fundamentally memory usage keeps increasing and we have a limited amount.
It's weird, I started using OS/2 v3 on a 4MB machine and was so happy when I got 8 MB's. Now with 12 GB's of memory, I worry more about memory. Before it was excessive swapping, now it is crashing.

187
Hardware / Re: Snap Vs Panorama - Refresh rate problem.
« on: December 20, 2020, 08:50:32 am »
Try x:\snap\gamode,
Code: [Select]
gamode set <xres> <yres> <bits> <refresh> [head] [device]
   To set the default refresh rate for a specific resolution

Never used it but should work if you get the parameters right.

188
Storage / Re: DISKIO - updated version in need of TEST
« on: December 20, 2020, 05:20:41 am »
Hi, thanks for working on this. About optimization, i686 or Pentium II should be best for the vast majority of current CPU's.
Redirecting output seems to make the divide by zero crash worse here, which doesn't make it to the log. So I started up EPM, created a cmd shell and ran it in that.
Disk 1 is a fast 1TB drive on a SATA3 port, Disk 2 is the SSD on a SATA2 port, Disk 3 a regular HD on a SATA2 port, Disk 4 the ram disk, disk 5 is a USB stick, disk 6 is a 2TB external drive plugged into a USB2 port (like the stick). Note that the size of the 2TB is expressed as a negative. Really need to use 64bit variables I guess.
Code: [Select]
epm: H:\tmp >diskio
DISKIO - Fixed Disk Benchmark, Version 1.18z
(C) 1994-1998 Kai Uwe Rommel
(C) 2004 madded2

Number of fixed disks: 12
Number of CD-ROM drives: 2

Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 2778159 runs/sec

Hard disk 1: 255 sides, 60321 cylinders, 127 sectors per track = 953855 MB
Drive cache/bus transfer rate: -96336 k/sec
Data transfer rate on cylinder 0   : 178456 k/sec
Data transfer rate on cylinder 60319: 86168 k/sec
CPU usage by full speed disk transfers: 4%
Average latency time: 0.0 ms
Average data access time: 15.6 ms
Multithreaded disk I/O (4 threads): 45709 k/sec, 1% CPU usage

Hard disk 2: 255 sides, 29185 cylinders, 63 sectors per track = 228934 MB
Drive cache/bus transfer rate: 93543 k/sec
Data transfer rate on cylinder 0   : 123821 k/sec
Data transfer rate on cylinder 29183: 181134 k/sec
CPU usage by full speed disk transfers: 4%
Average latency time: 0.1 ms
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads): 52275 k/sec, 2% CPU usage

Hard disk 3: 255 sides, 30394 cylinders, 63 sectors per track = 238417 MB
Drive cache/bus transfer rate: 145126 k/sec
Data transfer rate on cylinder 0   : 91842 k/sec
Data transfer rate on cylinder 30392: 49640 k/sec
CPU usage by full speed disk transfers: 4%
Average latency time: 0.1 ms
Average data access time: 17.9 ms
Multithreaded disk I/O (4 threads): 20850 k/sec, 3% CPU usage

Hard disk 4: 255 sides, 1138 cylinders, 63 sectors per track = 8926 MB
Drive cache/bus transfer rate: 40175 k/sec
Data transfer rate on cylinder 0   : 20746 k/sec
Data transfer rate on cylinder 1136: 20531 k/sec
CPU usage by full speed disk transfers: 9%
Average latency time: 0.0 ms
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads): 20092 k/sec, 10% CPU usage

Hard disk 5: 255 sides, 985 cylinders, 63 sectors per track = 7726 MB
Drive cache/bus transfer rate: 18272 k/sec
Data transfer rate on cylinder 0   : 15544 k/sec
Data transfer rate on cylinder 983 : 16830 k/sec
CPU usage by full speed disk transfers: 1%
Average latency time: 1.9 ms
Average data access time: 1.8 ms
Multithreaded disk I/O (4 threads): 15958 k/sec, 1% CPU usage

Hard disk 6: 255 sides, 60085 cylinders, 255 sectors per track = -189423 MB
Drive cache/bus transfer rate: 21755 k/sec
Data transfer rate on cylinder 0   : 21658 k/sec
Data transfer rate on cylinder 60083: 21590 k/sec
CPU usage by full speed disk transfers: 1%
Average latency time: 1.8 ms
Average data access time: 20.3 ms
Multithreaded disk I/O (4 threads): 21787 k/sec, 2% CPU usage

Hard disk 7: 12 sides, 512 cylinders, 9 sectors per track = 27 MB
Drive cache/bus transfer rate: Disk read error.
Data transfer rate on cylinder 0   : Disk read error.
Data transfer rate on cylinder 510 : Disk read error.
CPU usage by full speed disk transfers: Disk read error.
Average latency time: Disk read error.
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads):
SYS1808:
The process has stopped.  The software diagnostic
code (exception code) is  009B.

epm: H:\tmp >diskio-debug
DISKIO - Fixed Disk Benchmark, Version 1.18z
(C) 1994-1998 Kai Uwe Rommel
(C) 2004 madded2

Number of fixed disks: 12
Number of CD-ROM drives: 2

Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 2299450 runs/sec

Hard disk 1: 255 sides, 60321 cylinders, 127 sectors per track = 953855 MB
Drive cache/bus transfer rate:
 DEBUG => nData is: 3407777792
 DEBUG => nTime is: 10246
-86588 k/sec
Data transfer rate on cylinder 0   :
 DEBUG => nData is: 1761370112
 DEBUG => nTime is: 10259
171690 k/sec
Data transfer rate on cylinder 60319:
 DEBUG => nData is: 889398272
 DEBUG => nTime is: 10268
86618 k/sec
CPU usage by full speed disk transfers: 4%
Average latency time:
 DEBUG => nTime is: 10019.599360
 DEBUG => nCnt is: 135755.196980
0.0 ms
Average data access time:
 DEBUG => nTime is: 10045.599344
 DEBUG => nCnt is: 644.196980
15.5 ms
Multithreaded disk I/O (4 threads): 45620 k/sec, 1% CPU usage

Hard disk 2: 255 sides, 29185 cylinders, 63 sectors per track = 228934 MB
Drive cache/bus transfer rate:
 DEBUG => nData is: 946132992
 DEBUG => nTime is: 10242
92377 k/sec
Data transfer rate on cylinder 0   :
 DEBUG => nData is: 1221276672
 DEBUG => nTime is: 10240
119265 k/sec
Data transfer rate on cylinder 29183:
 DEBUG => nData is: 1857397248
 DEBUG => nTime is: 10253
181156 k/sec
CPU usage by full speed disk transfers: 5%
Average latency time:
 DEBUG => nTime is: 10027.599360
 DEBUG => nCnt is: 61825.196980
0.1 ms
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads):
SYS1808:
The process has stopped.  The software diagnostic
code (exception code) is  009B.

189
Internet / Re: Curious what the problem is making new firefox versions.
« on: December 20, 2020, 01:06:32 am »
Are there any compile-time optimizations that could help further reduce the size of the binaries ?  Or compile options to target multi-core chips with instructions that
can further reduce the execution path ??

-Os for a smaller optimized binary. Experimenting with Firefox (I believe there is a copy at Bitbucket) it wasn't that much smaller and slightly slower.
The thing with building on a multicore machine is that make can do more jobs by forking. I usually use -j5 (-j3 seems the most that works for TB) so that at times there are 5 make.exe's compiling different subdirectories on my 4 core machine, the extra one is for when one is blocked waiting for the HD. Nice to have all 4 cores running at 100% much of the time. Of course there are bottlenecks where one or more make's has to wait for a dependency to finish.
Bitwise was running into the situation where some object files were using 2GB to compile so had to revert to -j2 or -j1 to avoid the system hanging, leading to long compile times.

The compiler doesn't really seem to have options for multi-core. I did try tuning my latest for Core2 but whether it made a difference is hard to tell. I believe there are libraries that help for multi-core but basically just using more threads is key. While Mozilla uses threads, most of it runs on thread 1.
There's also having each tab as its own process, an option with QT and Firefox. Firefox is broken for doing it in our port and there are memory problems again with having a process per tab besides harder to make work (they have to communicate). Advantage is having a single tab crash instead of the whole browser. I expect that the QT browser will have that disabled, especially at first.

190
Games / Re: Drilling Billy - Problem running the exe
« on: December 19, 2020, 07:36:27 pm »
Might want to reboot with 256 colours and test.

191
Games / Re: Drilling Billy - Problem running the exe
« on: December 19, 2020, 05:15:10 pm »
Well, it never trapped here, just not initializing the correct video mode. My Bios supports some pretty high resolutions in VESA mode which usually aren't supported.
The gdb debugger worked pretty well with EMX, if rebuilding with current GCC, and the right flags (-Zomf -g) gcc builds can be debugged in the IBM debuggers. Whether the source will build with current GCC hasn't been tested but most EMX stuff with minor makefile editing does build.

192
Games / Re: Tux Football not running
« on: December 19, 2020, 05:07:07 pm »
SDL2_mixer is missing mod support, which when I compiled Rocks'nDiamonds recently resulted in no sound. Might be the same with Tux Football.

193
Web applications / Re: Seamonkey that plays well with firefox 45.9
« on: December 19, 2020, 05:00:01 pm »
You need to install libvpx-legacy-4 with ANPM or YUM. Libvpx got updated at some point so newer builds link against newer libvpx. To be safe you could also install libvpx-legacy-2.

194
Internet / Re: Curious what the problem is making new firefox versions.
« on: December 19, 2020, 04:56:47 pm »
How does the QT browser solve that problem though?
[/quote]

It is currently barely capable of being built, carefully.

195
Internet / Re: Curious what the problem is making new firefox versions.
« on: December 19, 2020, 08:03:57 am »
I'm not a programmer either but learning :) I do have the source for 52ESR here that almost compiles. After 52ESR, Mozilla switched to using the programming language Rust to build various modules. We have no Rust port, a very big job and it seems that linking with Rust modules needs much more memory then a 32 bit platform has. Even by 45ESR (actually it was worse for a while), linking xul.dll basically requires the full possible address range. Back when I only had 1.5 GBs of ram for a while, I actually crashed the machine due to the swap file filling up. Seems it has a 2GB limit, which I'm sure seemed like a lot in the early 90's.
It's a problem with the new browser as well, along with compiling some of the object files eating tons of memory. Dmik had to cut down the number of jobs for make to stop from running out of memory.
Theoretically, it should be possible to cross compile OS/2 binaries on Linux or even Windows, but once again it would be a big job by a knowledgeable person setting things up.
Eventually this will kill OS/2 as developers use 64bit machines full of memory, less and less will run on 32 bit machines.

Pages: 1 ... 11 12 [13] 14 15 ... 196