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 - Dariusz Piatkowski

Pages: 1 ... 88 89 [90] 91 92 ... 95
1336
Hardware / Re: Anyone successfully using Brother HL-5470dw?
« on: February 07, 2016, 06:10:00 am »
So I took Roberto's Linux/cups based PPD and re-fitted the Brother PPD with the *Resolution section, I preserved the 'setpagedevice' settings from the Brother drivers:

=== START ===
*%%%%% Resolution and Appearance Control %%%%%
*OpenUI *Resolution: PickOne
*OrderDependency: 11 AnySetup *Resolution
*DefaultResolution: 600dpi
*Resolution   300dpi: "<</HWResolution [300 300] >> setpagedevice"
*Resolution   600dpi: "<</HWResolution [600 600] >> setpagedevice"
*Resolution   HQ1200dpi: "<</HWResolution [1200 1200] >> setpagedevice
statusdict/true1200 known{statusdict begin false true1200 end}if
"
*Resolution   1200dpi: "<</HWResolution [1200 1200] >> setpagedevice
statusdict/true1200 known{statusdict begin true true1200 end}if
"
*CloseUI: *Resolution
=== END ===

However....somewhat strangely enough, I am getting the following error out of PIN.EXE:

=== START ===
[G:\TEST\PSCRIPT]pin ppd \test\pscript\5470 \test\pscript\5470
PostScript resource packaging utility version 1.00
Copyright (c) IBM Corp. 2000,2001. All rights reserved.

Producing Printer Device PAK
reading driver extended attributes
  fail
SYS0005: Access is denied.

fail
=== END ===

Almost looks like the PSCRIPT.DRV file is throwing the 'Access is denied' error...is this some kind of OS/2 built in protection mechanism on the PSSCRIPT.DRV file??? I copied a fresh ZIP of the PSCRIPT 30.800 driver to my test directory so as to avoid any issues attempting to update the existing driver in \os2\dll\pscript.

1337
Hardware / Re: Anyone successfully using Brother HL-5470dw?
« on: February 06, 2016, 01:55:10 am »
Guys!!!

Great news...I was a little delayed in getting this through, but I finally managed to pick up the printer locally (Staples Canada matched the on-line sales price, thumbs-up to them).

Anyways, glad to report the printer is chugging along quite nicely. So after I extracted the PPD file from the Win version of the driver package I proceeded with the import using Alex's drivers (PSPRINT 30.905). No errors were encountered, I then setup a new SLPR port and off I went.

All current apps readily print w/o any problems. The printer is a speedy little thing, at least as compared to my HL1650 machine. The Postscript options listed in Windows are all recognized by the OS/2 driver.

OK, so all good news....BUUUUTTTT....there is always a "but" right? LOL

Well, not all that bad of a "but", rather a simple definition of a printer control. So the 5470dw printer driver moves the "Resolution" settings to the "Features" tab of the driver settings. No big deal, I can still access them and as I make the changes I see that the printed output matches. However, my HL1650 shows the resolution controls in the "Output" tab. So at least from my liking perspective I would like to maintain this. Now from the "will it work elsewhere" perspective (and I have no idea if there is some sort of dependency here or not) I am worried that the only option in the 5470dw is 600dpi and therefore if an application is actually looking for the printer resolution capability it may in fact force 600dpi print output.

Looking at the PPD files here is how the HL1650 and 5470dw drivers differ:

1) HL1650

*%%%%% Resolution and Appearance Control %%%%%
*OpenUI *Resolution: PickOne
*OrderDependency: 11 AnySetup *Resolution
*DefaultResolution: 600dpi
*Resolution   300dpi: "<</HWResolution [300 300] >> setpagedevice"
*Resolution   600dpi: "<</HWResolution [600 600] >> setpagedevice"
*Resolution   1200dpi: "<</HWResolution [1200 1200] >> setpagedevice"
*CloseUI: *Resolution

2) 5470dw

*%%%%% Resolution and Appearance Control %%%%%
*DefaultResolution: 600dpi
*OpenUI *CAPT/Print Quality:PickOne
*OrderDependency: 10 AnySetup *CAPT
*DefaultCAPT: Middle
*CAPT   SFine/1200 dpi: "<</HWResolution [1200 1200] >> setpagedevice
statusdict/true1200 known{statusdict begin true true1200 end}if
"
*CAPT   Fine/HQ 1200: "<</HWResolution [1200 1200] >> setpagedevice
statusdict/true1200 known{statusdict begin false true1200 end}if
"
*CAPT   Middle/600 dpi: "<</HWResolution [600 600] >> setpagedevice"
*CAPT Low/300 dpi: "<</HWResolution [300 300] >> setpagedevice"
*CloseUI: *CAPT

I have not looked up any Postscript references yet to see if I can actually move my 5470dw "CAPT" settings over to the "Resolution" definition, but both printers claim to support Postscript 1.3, therefore I have no reason to suspect that the 5470dw PPD could not be successfully re-written to move the options to the "Resolution" definition.

If anyone has some input on this I'd love to see them. I will most likely give this a try over the weekend.

1338
Games / Quake/2 now broken???
« on: January 11, 2016, 03:40:29 pm »
So a while back...yeah, maybe a couple of years ago, or longer...my Quake/2 install was working great...then somehow, somewhere something broke...end result is that none of my Quake2 setups (so Quake local, LAN, QuakeWorld) no longer work.

Was hoping to bring back some of that "back in the early days of gaming" feeling for my son and play a bit of LAN Quake here...so I'm curious if anyone has this working on their machine?

I have ATI X850 XT video card here with SNAP drivers.

Here is what I'm finding in my POPUPLOG.OS2:

01-10-2016  20:13:52  SYS3184  PID 00b9  TID 0001  Slot 00b0
G:\APPS\GAMES\QUAKE\QUAKEFS.EXE
c000009b
0002b619
EAX=ffff63c0  EBX=000000c8  ECX=ffff63c0  EDX=00000000
ESI=0110fd24  EDI=035a0000 
DS=0053  DSACC=f0f3  DSLIM=ffffffff 
ES=0053  ESACC=f0f3  ESLIM=ffffffff 
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:0002b619  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:0110ec40  SSACC=f0f3  SSLIM=ffffffff
EBP=00000000  FLG=00010246

QUAKEFS.EXE 0002:0000b619

=================

01-10-2016  20:26:34  SYS3175  PID 00d7  TID 0003  Slot 00aa
G:\APPS\GAMES\QUAKE2\QUAKE2.EXE
c0000005
148943ca
P1=00000001  P2=00000000  P3=XXXXXXXX  P4=XXXXXXXX 
EAX=148a122e  EBX=00b8f838  ECX=00b8fcb4  EDX=00b8f838
ESI=00b8fcb4  EDI=00000000 
DS=0053  DSACC=f0f3  DSLIM=ffffffff 
ES=0053  ESACC=f0f3  ESLIM=ffffffff 
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:148943ca  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:00b8f7e0  SSACC=f0f3  SSLIM=ffffffff
EBP=00b8f81c  FLG=00010202

EMXLIBCM.DLL 0001:000143ca

=================

My EMXLIBCM.DLL info:

Directory of G:\code\tools\emx\dll

 3-20-01  11:45a    193603           0  emxlibcm.dll
        1 file(s)     193603 bytes used

Any ideas?

1339
Programming / Re: New OS/4 kernel :: SVN4227
« on: January 07, 2016, 02:23:34 am »
Lars,

...
4) the next ACPI.PSD is in the queue. Do you think it is sensible for the OS4 team to offer patches to ACPI.PSD to make it work with their kernel ad infinitum ?
...

So here is a real-world example why alternative approaches may be worth pursuing.

I have directly benefitted by subscribing to the Arca Noae's DRIVER package, thanks to that I now have a pretty stable SMP environment, although (and this is the big enough of a justification in my mind) of the total of 6 CPU cores I can only boot the machine up with 5, otherwise I end up with the dreadful "PMSHELL blue screen". Having logged a ticket with support organization it was prompty written of as a "known PMSHELL issue"...hmm...so really?...no further debug, no additional follow-up, just a plain "...can't be fixed..."? And this is for software that I actually paid money for...

Now, from my point of view, I am literally locked-out of using nearly 20% of my computing power simply b/c the current de-facto SMP solution won't let me do it. I'm not saying that this is the SOLE reason...heck, I am no os2ldr/krnl/PMSHELL guru, but as long as I have apparently reached the end of the road in one approach I will pursue others if they arise so that maybe in the course of testing/researching I will learn something and maybe someone else in our tiny community will benefit from.

Beyond just that very selfish reason above, here is a more precise one: if the /ST=0 parameter in the ACPI.PSD drive does in fact get ignored, and the authors have set some arbitrary value for the size of the stack, then I would consider this to be a defect. So if the OS4 team patches the binary to actually correct this behaviour then I'm actually questioning why the "core" OS2 maintainer team refuses to fix the code itself?

1340
Quote
This 21" CRT was fully capable of displaying 1800 x 1440/76 Hz NI resolution providing a pretty decent 0.26 mm aperture grille pitch.
...1800x1440 was way to much for this tube and you never could see that much pixels. Simply cause there were not that much stripes in the grill. You can't cheat physics...

Completely agree with all you stated...however, you are leaving out the intended use of the hardware. So while I may have been focused on text quality, the person doing CAD work on this display would certainly be able to take advantage of the higher addressable resolution. In other words, the monitor electornics had the ability to physically address (turn on/off) some 1800 locations on the X-axis...this very much translates to having a functionality where the display can choose from 1800 different points, even though not each of these 1800 points was a unique physical screen location, sort of an interpolation solution I suppose.

For me anyways it all boils down to the functionality one indends to utilize. Image/graphics work on displays is very different then text work. Today's hardware, where the RGB gamut is wholly covered (near 100%) will still fetch a good price at the cash register...and if one is willing to spend that money I can only assume it's because he/she is not focused on text only.

If anyone reading the post is looking at a pretty good review of panel capabilities head on over to http://www.tftcentral.co.uk, these guys do a great mix of usability and tech analysis.

1341
Olafur and Andi,

For what it's worth, here is a personal experience of mine when it comes to the CRT style displays.

I have always invested heavily into the displays, primarily because given today's way of "human computer interface" the display is really how we gather much of the information. This is slowly starting to change, tablets and mobile computing in general are a good indicator of this, however, we are not quite there yet.

So...in my previous high-res setups I have used Mitsubishi displays (yeah, the price tag was somewhat astronomical, even by today's standards)...specifically, the last model prior to switching to the LCD panel (Samsung 214T) was the DiamondPro 1010. This 21" CRT was fully capable of displaying 1800 x 1440/76 Hz NI resolution providing a pretty decent 0.26 mm aperture grille pitch. While my Matrox cards had no problem driving the monitor, especially since I was using heavily shielded BNC cabling (each cable carrying separate RBG signals), the attempts to use 1800x1440 resolution on a 21" CRT panel (remember the darn CRT geometry problems??? even with a high-end aperture grille displays like the 1010 you always fought the converegence issue - separate beams not quite aligning on the surface of the display thus causing a drift and fuzziness). The end result was that the 21" CRT (which really was a 19.7" diagonal display size) was far too small of a format for this high of a resolution unless you were doing pure CAD/graphics work. The text, especially smaller fonts was simply hard to deal with. I ended up running 1600x1200 on that display and was extremely happy with it for quite a number of years.

I've attached the monitor spec file if you are interested in the details.

Now, once I upgraded to my Samsung 214T LCD, boy, all geometry issues went away...yeah, the colour was never the same, but how could it when compared to an extremely high end CRT display like the 1010? I accepted that because for me geometry rendering was far more important. Moving on to the 245T display simply carried on with the display resolution progression, that gave me 1920x1200 but required me to move to a DVI connector video adapter, which was the ATI X850, top-of-the-line in SNAP supported video chipsets at that time.

1342
Dave and Martin,

Probably Lewis would be best, lgrosenthal at 2rosenthals dot com

Exchanged a couple of emails with Lewis, he is going to follow-up with Steve. For those of you who reviewed the SNAP 2015 video there is some on-going work, I just hope we can narrow the scope down to a workable range of hardware and optimize that. Anyways, my input in that project can only be limitted to the driver <=> monitor interface as I have no video driver development skills.

Appreciate the right pointer to the correct contact point!

1343
Ivan,

Hi Dariusz,

Experience with monitor power supplies says that you not only replace the obvious dead capacitors but also any other electrolytic ones as well.  It might also be a good idea to have a good look at any on the panel driver board and replace any that have the slightest bulge at the top.

Excellent point sir...I did actually closely eye-ball all the capacitors on the power board...luckily only these 2 appeared damaged. There was at least 1 other 1000 uF/35V piece that actually looked "brand-new" (visually that is...LOL). I also pulled the logic board to take a peek at it...this is mostly IC though and contained none of the aluminum case capacitors.

1344
Programming / Re: New OS/4 kernel :: SVN4502
« on: January 02, 2016, 03:14:00 pm »
1) booting with OS4krnl produces a hard trap right after PMSHELL (I can not tell at all what is going on, so this looks like a candidate for a COM port debug, I need to get this organized though)

Similar stuff sometimes happens on  my computer as well. In the comport log it looks like this:

Code: [Select]
DelayHardError SYS3171: 4 string(s):
 Pid 0020  Tid 0001  Slot 0045  HobMte 053A
 C:\OS2\PMSHELL.EXE
c0000005
1f93b94a
P1=00000002  P2=0003ff14  P3=XXXXXXXX  P4=XXXXXXXX 
EAX=00000000  EBX=1f93b93c  ECX=00040028  EDX=0004f564
ESI=00000000  EDI=0004f3f4 
DS=0053  DSACC=d0f3  DSLIM=ffffffff 
ES=0053  ESACC=d0f3  ESLIM=ffffffff 
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:1f93b94a  CSACC=d0df  CSLIM=ffffffff
SS:ESP=0053:0003ff18  SSACC=d0f3  SSLIM=ffffffff
EBP=00040054  FLG=00010206

PMWP.DLL 0001:0000b94a
This happens once every 100 boots approx. I don't know the reason and it happens much later after the init of the kernel has finished.

It's possible that it's some old bug that has no relation to OS/4. I remember on the original kernel there sometimes happened situations when there appeared PMshell background and nothing more. Somebody offered a solution with organizing a kind of delay  before PMshell start, but I cannot find that post.

What you describe is precisely what I see with my standard 3.22.08 setup upon nearly every re-boot. Meaning, the PMSHELL window displays (the blue background) and halts...CTL-ALT-DEL still reboots the PC though. I find that if I hit the CTL-ESC key combination repeatedly as the PMSHELL window is coming up I can sucessfully boot though. This procedure works pretty well when I run my 6-core CPU in 5-core mode, as soon as I enable all the cores the PMSHELL nearly always hangs regardless of what I do during bootup. So this certainly appers to be some type of timing issue...

...Yes, ACPI.PSD has to be patched and used with /ST=0. Indeed,  the patch does very simple thing:
in ACPI.PSD there is something like this:
Code: [Select]
if (ST==0)
{
    ST=4096
}

patch makes this code out of it:
Code: [Select]
if (ST==0)
{
    ST=0
}

thus, if one asks for ST=0 he does get ST=0. I would like to stress that this patch does not "spoil"  ACPI.PSD and it still can be used with original kernel.

ACPI4.BPD - it is an optional acpi driver. It is not obligatory for booting the system.

It is true that there are patches only for 3.22.06 and 3.22.03, that's because nobody had asked for something else. If you insist,  patch for 08 will also be produced. At the same time you may try OS/4 with 06 (ACPI.PSD only  the rest may remain 08)

Well, I will try 3.22.06, but if at all possible (not sure how much work this is) I'd prefer to run the matching 3.22.08 instead.

I will a couple more combinations here, like RETAIL vs DEBUG kernels and /APIC vs none for OS4APIC.PSD driver.

waiting for result  (better with comport log ;) )

...nah, no go here...all other combinations produced the same result...a hang at PMSHELL, so I will focus on teh comport log and will attempt to re-test with the patched 3.22.06 first.

Co-incidentally, what is the reason for the different version of DOSCALL1.DLL? I repeated all my tests with both versions (14.106 SMP and the one included in the 4502 drop) but the results were the same.

Thanks for the quick response!!!

1345
Programming / Re: New OS/4 kernel :: SVN4502
« on: January 02, 2016, 02:04:02 am »
OS/4 kernel svn4502 is released. The changes have occurred mostly in clock$.
If HPET is available in the computer, clock$ will use it for providing DosTmrQueryTime/Freq with 64bit time stamp.

Re-tried this latest release...I am currently successfully running SMP in 5-core mode with ACPI 3.22.08, so that is my starting point.

Here are some brief results:

1) booting with OS4krnl produces a hard trap right after PMSHELL (I can not tell at all what is going on, so this looks like a candidate for a COM port debug, I need to get this organized though)

2) booting with OS4krnl but ACPI.PSD produces a trap with a complaint regarding missing ACPI4.BPD file...did some researching here but best I could do was to find an earlier forum post (http://www.os2world.com/forum/index.php?topic=785.0) and having re-read the on-line docs multiple times I still can not tell whether I should be attempting to patch the ACPI.PSD driver with the patch files supplied at the OS4 site (I am guessing the answer is a NO because those patches are meant for 3.22.06 release whereas I'm running 3.22.08 here)

I will a couple more combinations here, like RETAIL vs DEBUG kernels and /APIC vs none for OS4APIC.PSD driver.

1346
Well you guys...some good news...I took apart my dead 245T panel, as it turns out the power board shows 2 capacitors looking pretty dead...as in you know, all buldging and the icing on the cake is the leak of the internal chemicals right through the top of the capacitor, this shows there is a crack in the aluminum casing, etc, etc...so I'm thinking I will replace the two 1000 uF 35V capacitors first, will give it another try...now good lucking finding capacitors locally...yikes!

Now, here is an OS/2 thought: there was an announcement out a few weeks back about ArcaNoae picking up and re-starting the development of the SNAP drivers. With my previous EDID decoding experience and somewhat of a decent of an understanding of the monitor EDID structures I wouldn't mind getting involved in that aspect of the SNAP drivers development. So in other words, while the core of the heavy lifting is in the core drivers development (I think) it certainly would be a blessing to smarten up the anciliary logic so that modern monitor INF files are recognized, or the EDID information handling is more robust.

Therefore the question I have is: who is the person to contact regarding this?

1347
Hi Andi,

Quote
but that is still driven by the EDID monitor information being correctly recognized by the driver and thus telling it what the screen capability it.
TTBOMK you can bypass all this DDC stuff in SNAP when choosing 'Unknown monitor'...

Interesting..tell me more about this option because as best as I can remember I was never actually able to make this work, and we're talking here about shutting off the GAOPTION DDC mode, etc, etc. In other words, to make my 245T 1920x1200 capability known to the SNAP driver I had to literally re-program the monitor EDID...a bit of a crazy effort when you manually assemble the EDID record based on VESA standards, etc, etc...did it once, I would prefer not to have to do that again....and I say "again" because I have 3 other 245Ts currently at home, 2 linked on my professional/work PC and the 3rd one on kids's PC.

I had actually pulled the kids' 245T and plugged it in, but the SNAP driver would NOT recognize the monitor successfully (using the "Detect Monitor" option failed, importing the Windows INF file failed as well, although I suspect that is b/c SNAP only supports Win95 versions of monitor INF files). When I querried up the DDC/EDID info the SNAP utility came back with "...invalid EDID record..." error message, which I believe is very similar to what I had experienced way back when with my original 245T display that just died.

So...long story short...LOL...if there is a way to force the SNAP driver to 1920x1200 resolution regardless of what capability the monitor reports or SNAP driver is able to establish I'd love to give this a shot.

Thanks again!

1348
Hi Everyone,

Well, my trusty Samsung 245T 24" monitor (1920x1200) finally gave up the ghost...literally nothing happens upon power-up, not even the "blue glow" of ON/OFF button. Per the Service Manual I have that implies either an internally blown fuse or as per the suggestions provided by previous post responses (I had an issue with my LCD coming out of DPMS save, screen was showing flickering for a few minutes each time) it may have been showing some issues with capacitors.

Anyways...as much as I'd love to keep it, the US and Canadian locations are having some pretty crazy Holiday sales still and I might as well take advantage of it.

So...I understand that with SNAP drivers I can define various resolution modes, but that is still driven by the EDID monitor information being correctly recognized by the driver and thus telling it what the screen capability it. Assuming that all that works correctly, what is the highest screen resolution you have been able to use?

My video card is an old ATI X850 XT PE, info as reported by SNAP drivers is:
=== START ===
Graphics device configuration:
  Manufacturer......... ATI
  Chipset.............. Radeon X850 Series
  Bus Type............. PCI Express
  Memory............... 262144 KB
  DAC.................. ATI Internal 24 bit DAC
  Clock................ ATI Internal Clock
  Memory Clock......... 400 MHz
  Default Memory Clock. 400 MHz
  Maximum Memory Clock. 400 MHz
  Driver Revision...... 3.2, Build 29
  Driver Build......... Sep 25 2006
  Certified Version.... 1.60
  Certified Date....... Sep 25 2006
=== END ===

As best as I can tell the single-link DVI connector can display a maximum resolution of 1920×1200, while the dual-link’s maximum for that same screen is 2560×1600.

My ATI X850 User Guide indicates I have a DVI-I connector, which means I'm maxed out at 1920x1200...so I'm curious if anyone else has done better with different hardware?

1349
Applications / Re: AVxCAT 1.4 alpha
« on: December 30, 2015, 04:31:27 pm »
Hi Remy,

Wow...great news...thank you so much for continuing the work on this.

I was never able to overcome the "system freeze" with the latest previous version so I'm happy to give this a try.

-Dariusz

1350
Hardware / Anyone successfully using Brother HL-5470dw?
« on: December 04, 2015, 05:17:04 am »
I've got my good 'ol trusty Brother HL-1650 (with NIC card, so really the same config as HL-1670) Postscript printer here, working very well with my OS/2 setup. Both the standard IBM as well as Alex's PSPRINT drivers support all the feature. However...the printer is aged and while I love it, the reality is that it's starting to show it's age.

With some of the sales around these past couple of weeks I spied the HL-5470dw unit...as the Brother (http://www.brother-usa.com/Printer/ModelDetail/1/HL5470DW/Overview) product page shows this is basically a modern day (updated) version of the HL-1670...still a Postscript printer, duplexed, fast not to mention it support Wi-Fi and the various types of Cloud/Google/Air printing (great for kids to run stuff off of their tablets).

So here is the big question: has anyone tried this unit in OS/2?

Pages: 1 ... 88 89 [90] 91 92 ... 95