f



W98SE MCA Adapters

Hard to believe, two new adapter IDs and one shared ID, from W98SE INF
files!

The list of supported MCA SCSI and network adapters under W98SE follows. I
created the list manually, checked it, but assume a slight error margin in
any case. MCA_NNNN is the adapter ID.

SCSI, ESDI
===========================================

FD16MCA   Future Domain MCS-600/700 SCSI Host Adapter
MCA_004e  NCR C700 MCA SCSI Host Adapter
MCA_7f4c  NCR 53C94 MCA SCSI Host Adapter
MCA_7f4d  NCR 53C94 MCA SCSI Host Adapter
MCA_7f4f  NCR 53C94 MCA SCSI Host Adapter
MCA_01ba  NCR 53C710 MCA SCSI Host Adapter
MCA_01bb  NCR 53C710 MCA SCSI Host Adapter
NCR_C9X   NCR 53C94 MCA SCSI Host Adapter
NCR_710   NCR 53C710 MCA SCSI Host Adapter
MCA_8eff  IBM MCA SCSI Host Adapter
MCA_df9f  Integrierte IBM MCA-Festplatte und -Controller

A few more entries for the Spock family in SCSI.INF will be needed, but that
isn't difficult to do. Below a section from SCSI.INF:

;IBM-manufacturer device list
[IBM]
%mca_8eff.DeviceDesc%=spock,mca_8eff            ;IBM SCSI

[mca_8eff.LogConfig]
ConfigPriority=NORMAL
IOConfig=8@3540-357f%fff8(ffff::)
IRQConfig=14


NETWORK
============================================
MCA_5600   Cabletron E3000 Series DNI
MCA_5601   Cabletron E3000 Series DNI
MCA_5602   Cabletron E3000 Series DNI
MCA_5603   Cabletron E3000 Series DNI
MCA_5604   Cabletron E3000 Series DNI
MCA_5605   Cabletron E3000 Series DNI
MCA_5606   Cabletron E3000 Series DNI
MCA_5607   Cabletron E3000 Series DNI
MCA_5608   Cabletron E3100 Series DNI
MCA_5609   Cabletron E3100 Series DNI
; MCA_0050 Cabletron T3015 4/16 Mbps DNI (Ed. disabled!)

MCA_63CA  HP Ethertwist MCA-Adapter (HP27246)
MCA_0101  Proteon ProNET-4 MCA Token Ring (1840)
MCA_0102  Proteon ProNET-4/16 MCA Token Ring (P1892) (**Ed: new ID)

MCA_5C1D  IRMAtrac Convertible MCA Phase II
MCA_5C1C  IRMAtrac Convertible MCA Phase I

MCA_6042  EtherLink/MC
MCA_627D  3Com 3C529 MC  (Ed: Etherlink III)
MCA_627C  3Com 3C529 MC  (Ed: Etherlink III)

MCA_002D  Madge Smart 16/4 MC Ringnode
MCA_0074  Madge Smart 16/4 MC32 Ringnode

MCA_0100  NCR Token-Ring 16/4 Mbs MCA
MCA_8FA2  IBM Auto LANStreamer MC32 Adapter(NDIS4)

MCA_0051  Thomas-Conrad TC4046 T/R

MCA_7012  UB NIUps or NIUps/EOTP (**Ed: Ungerman-Bass)
MCA_EFF5  UB NIC/ps

MCA_6DEF  DEC (DE210) EtherWorks MC
MCA_628B  Intel EtherExpress 16 (mca)
mca_67b0  Artisoft AE-2 (MCA) or AE-3 (MCA)

mca_6447  Olicom Ethernet MCA 10/100 Adapter
mca_0a86  Olicom Token Ring MCA 16/4 (OC-3129)
mca_0a84  Olicom Token Ring MCA 16/4 (OC-3129)
mca_0a83  Olicom Token Ring MCA 16/4 (OC-3129)  (**Ed: new ID)

mca_6fc0  SMC EtherCard PLUS/A (MCA) (WD 8003E/A or 8003ET/A)de
mca_6fc1  SMC StarCard PLUS/A (MCA) (WD 8003ST/A)
mca_6fc2  SMC EtherCard PLUS 10T/A (MCA) (WD 8003W/A)
mca_61c8  SMC EtherCard PLUS/A (MCA,BNC/AUX) (WD 8013EP/A)
mca_61c9  SMC EtherCard PLUS/A (MCA,TP/AUX) (WD 8013EW/A) (**Ed: duplicate
ID)
mca_6ec6  SMC TokenCard Elite/A (8115T/A)

mca_e000  IBM Token Ring (MCA)
mca_e001  IBM Token Ring 4/16Mbs (MCA)

**********
Created from W98SE INF files.



0
UZnal
3/24/2006 8:08:30 PM
comp.sys.ibm.ps2.hardware 10363 articles. 0 followers. Post Follow

170 Replies
804 Views

Similar Articles

[PageSpeed] 40

> Created from W98SE INF files.

XGA
========================
8FDB  XGA         XGA1_ID  equ 8fdbh
8FDA  XGA-2      XGA2_ID  equ 8fdah
8FD9                 AGX_ID  equ 8fd9h
(Ed: ID reserved for the non-existent 2M XGA-2)

AGX = XGA Clones
=========================
Hercules Graphite Card
Hercules Graphite Power
Hercules Graphite Pro
Boca Vortek (IIT)
Orchid Celsius (IIT)
Paradise Accelerator Pro (IIT)

XGA and AGX use the same XGA driver (xga.drv, xga.vxd). An AGX could have 2M
and has the better VESA support. If we know the internals of XGA-2 well,
adding a 800x600x16 mode could be easily possible (W9x driver code is open
and available).

** TsengW32 ? Has its own driver and denoted as XGA-2 class card.
DetectTsengW32 = display,msdisp.inf,1,BUS_ALL,RISK_LOW,DetectXGA2

TsengW32 family:
----------------
- Diamond Stealth 32 (Tseng)
- DFI WG-5000 (Tseng)
- Genoa Phantom 32I (Tseng)
- Hercules Dynamite (Tseng)
- Hercules Dynamite Pro (Tseng)
- STB Ergo MCX (Tseng)
- STB LightSpeed (Tseng)
- STB MVP-2X (Tseng)
- STB MVP-4X (Tseng)







0
UZnal
3/25/2006 1:06:14 PM
Can we use the AGX, which may support better than XGA? I understand that 
they use XGA.drv / XGA.vxd, but Windblows is not the galactic overmind. 
What modes are supported by AGX?

UZnal wrote:
>> Created from W98SE INF files.
> 
> XGA
> ========================
> 8FDB  XGA         XGA1_ID  equ 8fdbh
> 8FDA  XGA-2      XGA2_ID  equ 8fdah
> 8FD9                 AGX_ID  equ 8fd9h
> (Ed: ID reserved for the non-existent 2M XGA-2)

> XGA and AGX use the same XGA driver (xga.drv, xga.vxd). An AGX could have 2M
> and has the better VESA support. If we know the internals of XGA-2 well,
> adding a 800x600x16 mode could be easily possible (W9x driver code is open
> and available).
0
Louis
3/25/2006 2:23:41 PM
Smoking some Blue Monster. Can we force setup to use the AGX ID? Would a 
simple edit of the XGA adapters allow us to use the AGX modes?


>> XGA
>> ========================
>> 8FDB  XGA         XGA1_ID  equ 8fdbh
>> 8FDA  XGA-2      XGA2_ID  equ 8fdah
>> 8FD9                 AGX_ID  equ 8fdah  <change equ 8fd9h to equ 8fdah>
>> (Ed: ID reserved for the non-existent 2M XGA-2)
0
Louis
3/25/2006 3:53:48 PM
Odd, does the AGX exist in NT4 as well?

Louis Ohland wrote:
> Smoking some Blue Monster. Can we force setup to use the AGX ID? Would a 
> simple edit of the XGA adapters allow us to use the AGX modes?
> 
> 
>>> XGA
>>> ========================
>>> 8FDB  XGA         XGA1_ID  equ 8fdbh
>>> 8FDA  XGA-2      XGA2_ID  equ 8fdah
>>> 8FD9                 AGX_ID  equ 8fdah  <change equ 8fd9h to equ 8fdah>
>>> (Ed: ID reserved for the non-existent 2M XGA-2)
0
Louis
3/25/2006 3:54:38 PM
 >http://groups.google.com/group/comp.sys.ibm.ps2.hardware/browse_thread/thread/a9de97959e646963/4805dc5c28d13af0?lnk=st&q=agx+modes+xga&rnum=4&hl=en#4805dc5c28d13af0<

Bummer, I think.

Louis Ohland wrote:
> Smoking some Blue Monster. Can we force setup to use the AGX ID? Would a 
> simple edit of the XGA adapters allow us to use the AGX modes?
> 
> 
>>> XGA
>>> ========================
>>> 8FDB  XGA         XGA1_ID  equ 8fdbh
>>> 8FDA  XGA-2      XGA2_ID  equ 8fdah
>>> 8FD9                 AGX_ID  equ 8fdah  <change equ 8fd9h to equ 8fdah>
>>> (Ed: ID reserved for the non-existent 2M XGA-2)
0
Louis
3/25/2006 3:59:00 PM
 >http://groups.google.com/group/comp.windows.x.i386unix/browse_thread/thread/1adf8d7e7e8b0314/4549a218462ffac9?lnk=st&q=agx+modes+xga&rnum=65&hl=en#4549a218462ffac9<


>>IIT AGX based on XGA? I know little about XGA, but it's supposed to do
>>bus-mastering which I consider BAD, BAD, BAD. Is it also i/o based
>>like the 8514?
> 
> The AGX is inspiered by the XGA. Mostly seems to be compatible, but in
> a few places it has more restrictions than the original (like the
> possible widths of pixmaps). However, it is memory mapped, althought
> not directly how the IBM XGA spec describes it. 



Louis Ohland wrote:
>  >http://groups.google.com/group/comp.sys.ibm.ps2.hardware/browse_thread/thread/a9de97959e646963/4805dc5c28d13af0?lnk=st&q=agx+modes+xga&rnum=4&hl=en#4805dc5c28d13af0< 
> 
> 
> Bummer, I think.
> 
> Louis Ohland wrote:
>> Smoking some Blue Monster. Can we force setup to use the AGX ID? Would 
>> a simple edit of the XGA adapters allow us to use the AGX modes?
>>
>>
>>>> XGA
>>>> ========================
>>>> 8FDB  XGA         XGA1_ID  equ 8fdbh
>>>> 8FDA  XGA-2      XGA2_ID  equ 8fdah
>>>> 8FD9                 AGX_ID  equ 8fdah  <change equ 8fd9h to equ 8fdah>
>>>> (Ed: ID reserved for the non-existent 2M XGA-2)
0
Louis
3/25/2006 4:10:56 PM
> Can we use the AGX, which may support better than XGA? I understand that
> they use XGA.drv / XGA.vxd, but Windblows is not the galactic overmind.

I extracted & merged the AGX parts from the driver (ASM code). There are
certain differences between XGA and AGX but not that big. AGX has more VESA
mode tables defined, suppors more VESA modes. The XGA lacks in the driver
code the VESA mode 114 table for 800x600x16. The driver itself is careful to
detect XGA and AGX, respects the differences and handles common parts.
Somebody knowing well the XGA hardware could tell better what XGA parts can
be optimized resp. improved.

> What modes are supported by AGX?

XGA modes:
------------
MODES\4\640,480
MODES\4\1024,768
MODES\8\640,480
MODES\8\1024,768
MODES\16\640,480

XGA-2 modes
-------------
MODES\4\640,480
MODES\4\1024,768
MODES\8\640,480
MODES\8\800,600
MODES\8\1024,768
MODES\8\1280,1024
MODES\16\640,480

AGX modes
------------------
MODES\4\640,480
MODES\4\1024,768
MODES\8\640,480
MODES\8\800,600
MODES\8\1024,768
MODES\16\640,480
MODES\16\800,600
MODES\16\1024,768




0
UZnal
3/25/2006 6:33:21 PM
The XGA-2 should top out at the 800x600x16. The ethereal 2MB XGA would 
top out at the 1024x768x16

UZnal wrote:

> AGX modes
> ------------------
> MODES\16\640,480
> MODES\16\800,600
> MODES\16\1024,768
0
Louis
3/25/2006 8:12:40 PM
VGA.ASM:

> ;The XGA/1 can run in the following configurations:
> ;
> ;	640x480 with 8 BPP
> ;	640x480 with 16 BPP (not on 512K XGA's) [!!!!]
> ;	1024x768 with 4 BPP			}These are interlaced modes
> ;	1024x768 with 8 BPP (not on 512K XGA's) }
> ;
> ;Additionally, the XGA/2 can run the following:
> ;
> ;	800x600 with 8 BPP
> ;	1024x768 with 8 BPP (non-interlaced)
> ;	1280x1024 with 8 BPP
> ;
> ;The IIT AGX can run in the following modes in addition to those above:
> ;
> ;	800x600 with 16 BPP
> ;	1024x768 with 16 BPP


Louis Ohland wrote:
> The XGA-2 should top out at the 800x600x16. The ethereal 2MB XGA would 
> top out at the 1024x768x16
> 
> UZnal wrote:
> 
>> AGX modes
>> ------------------
>> MODES\16\640,480
>> MODES\16\800,600
>> MODES\16\1024,768
0
Louis
3/25/2006 8:46:58 PM
> > ;The IIT AGX can run in the following modes in addition to those above:
> > ;
> > ; 800x600 with 16 BPP
> > ; 1024x768 with 16 BPP

Implanting that portion of the TSR into the driver for mode 114 would give
800x600x64K color packed pixel mode at low 60Hz Vertical Refresh. Not much
motivating those 60Hz but it would be a good experiment.

XGAVESA

This TSR supports the following standard VESA modes for the XGA-2 adapter
(in addition to the modes supported for the XGA/A product), provided the
appropriate DMQS Display Information file indicates that the mode is
available on the installed system:

   VESA mode        Description

   102h             800x600x16 color planar mode
   103h             800x600x256 color packed pixel mode
   114h             800x600x64K color packed pixel mode (60Hz Vertical
Refresh)




0
UZnal
3/25/2006 11:08:32 PM
On Sun, 26 Mar 2006 00:08:32 +0100, "UZnal" <unalz-at-mail333-dot-com>
wrote:

>   114h             800x600x64K color packed pixel mode (60Hz Vertical

Very interesting.  I always thought that high color 800x600 on an XGA2
would be the bees knees.

Too bad about the 60Hz.
+-----------------------------------------+
| Charles Lasitter   | Mailing/Shipping   |
| 401/728-1987       | 14 Cooke St        |
| cl+at+ncdm+dot+com | Pawtucket RI 02860 |
+-----------------------------------------+
0
Charles
3/27/2006 9:23:56 AM
> >   114h             800x600x64K color packed pixel mode (60Hz Vertical

Supplied by SVGAVESA and not XGAVESA.

"SVGAVESA is a TSR that makes your XGA/A or XGA-2 Adapter VESA-compliant
for SVGA.

> Very interesting.  I always thought that high color 800x600 on an XGA2
> would be the bees knees.

Assuming no hidden traps, it is just about defining the VESA Mode 114h Table
and a few more fixes, e.g. (see XGA.ASM, just read the comments if not the
code)

line 1944:
  cmp al,11h         ;running above mode 111H?
  ja VF2Failure      ;yes, can't run these on the XGA!

The driver is in fact a SVGA VESA handler. It sets up the adapter
environment and then handles the VESA requests. The XGA specifics are
handled properly:

line 2029:
;When the XGA is in HiRes mode (such as we're going to do in a minute), the
;VGA registers are not readable.

line 2192:
;When the XGA is in HiRes mode (as we've just done), the standard VGA DAC
;registers 3C6H-3C9H are not used.  Rather, the XGA uses a proprietary DAC
;programming scheme.  We therefore must virtualize the DAC registers
3C6H-3C9H
;since most VESA apps assume that these are the palette registers and
program
;them directly.  We have virtualization code to translate accesses to the
VGA
;DAC into XGA accesses.

line 900:
;We're running on an XGA/2.  Check to see if we have 2 megabytes of memory

Without a prototype 2M XGA-2 board, this portion of the code cannot be
really tested. At board detection time, a 2M XGA-2 is supposed to have the
AGX-ID (8fd9), but if such a board was never available, large portions
remained again untested. The check above for 2M is performed regardless of
the board ID, hence, two cases: (1) a conventional XGA-2 with 2M, or (2) an
AGX-ID XGA-2 with 2M. In case (2), the XGA-2 becomes for the driver a true
AGX.

Clearly, without a 2M XGA-2 to test, the relevant portions of the code are
simply well intended assumptions. It surprises me that someone would code a
driver based on assumptions and without being able to test and verify.


> Too bad about the 60Hz.

More hope with an LCD monitor. How good is the combo XGA-2 + LCD ?






0
UZnal
3/27/2006 1:18:46 PM
Please look at the 5:6:5 references. How can the XGA be accessed to 
allow direct color, which IIRC was also called packed pixel.

The original XGA with 1MB was "supposed" to support 64k, perhaps with 
some sleight of hand, but it was possible.

UZnal wrote:
>>>   114h             800x600x64K color packed pixel mode (60Hz Vertical
> 
> Supplied by SVGAVESA and not XGAVESA.
> 
> "SVGAVESA is a TSR that makes your XGA/A or XGA-2 Adapter VESA-compliant
> for SVGA.
> 
>> Very interesting.  I always thought that high color 800x600 on an XGA2
>> would be the bees knees.
> 
> Assuming no hidden traps, it is just about defining the VESA Mode 114h Table
> and a few more fixes, e.g. (see XGA.ASM, just read the comments if not the
> code)
> 
> line 1944:
>   cmp al,11h         ;running above mode 111H?
>   ja VF2Failure      ;yes, can't run these on the XGA!
> 
> The driver is in fact a SVGA VESA handler. It sets up the adapter
> environment and then handles the VESA requests. The XGA specifics are
> handled properly:
> 
> line 2029:
> ;When the XGA is in HiRes mode (such as we're going to do in a minute), the
> ;VGA registers are not readable.
> 
> line 2192:
> ;When the XGA is in HiRes mode (as we've just done), the standard VGA DAC
> ;registers 3C6H-3C9H are not used.  Rather, the XGA uses a proprietary DAC
> ;programming scheme.  We therefore must virtualize the DAC registers
> 3C6H-3C9H
> ;since most VESA apps assume that these are the palette registers and
> program
> ;them directly.  We have virtualization code to translate accesses to the
> VGA
> ;DAC into XGA accesses.
> 
> line 900:
> ;We're running on an XGA/2.  Check to see if we have 2 megabytes of memory
> 
> Without a prototype 2M XGA-2 board, this portion of the code cannot be
> really tested. At board detection time, a 2M XGA-2 is supposed to have the
> AGX-ID (8fd9), but if such a board was never available, large portions
> remained again untested. The check above for 2M is performed regardless of
> the board ID, hence, two cases: (1) a conventional XGA-2 with 2M, or (2) an
> AGX-ID XGA-2 with 2M. In case (2), the XGA-2 becomes for the driver a true
> AGX.
> 
> Clearly, without a 2M XGA-2 to test, the relevant portions of the code are
> simply well intended assumptions. It surprises me that someone would code a
> driver based on assumptions and without being able to test and verify.
> 
> 
>> Too bad about the 60Hz.
> 
> More hope with an LCD monitor. How good is the combo XGA-2 + LCD ?
> 
> 
> 
> 
> 
> 
0
Louis
3/27/2006 1:33:22 PM
> Please look at the 5:6:5 references. How can the XGA be accessed to
> allow direct color, which IIRC was also called packed pixel.

VESA Bios Extensions (VBE) 2.0 are discussed in Richard Wilton "Programmer's
Guide to PC Video Systems", 2nd Ed., Microsoft Press, 1994. Page 442
describes the structure of the Mode Table (MODEINFOBLOCK). We have now the
format of the tables but that should be verified with a sample table from
the code (decode to get the fields).

Some calculations: 800x600 with 16 bpp wastes 937.5 KB and that fits into
the 1M of the XGA-2. But see the comment below, this mode is "not" supported
according to the code and that is simply false.

VGA.ASM

line 554:
;Additionally, the XGA/2 can run the following:
;
; 800x600 with 8 BPP
; 1024x768 with 8 BPP (non-interlaced)
; 1280x1024 with 8 BPP


Below 2M are requested for 800x600 with 16 bpp:

line 628:
 cmp dx,16   ;do they want 16 BPP on the AGX?
 [....]          ;do they have 2 megs?
 jb FMErrorExit  ;nope, they can't do it!


>
> The original XGA with 1MB was "supposed" to support 64k, perhaps with
> some sleight of hand, but it was possible.




0
UZnal
3/27/2006 9:09:21 PM
> > Please look at the 5:6:5 references. How can the XGA be accessed to
> > allow direct color, which IIRC was also called packed pixel.

We need a timing table as the one below for 800x600x16. These numbers
program the XGA for a desired mode. One possible source could be (1)
SVGAVESA.EXE (XGA2 1.2 driver disk) or (2) Win3.1 XGA2 driver (3) an XGA-2
techref.

Won't move an inch without such a table, will run 64K miles with
it... URGENT URGENT URGENT !!!!!!!!


; We now must setup the XGA's extended CRTC registers.  This is done from a
table

Mode800x600x8x60 label word
 dw 0150h, 0050h, 8310h, 0011h, 6312h, 0013h, 6314h, 0015h
 [..........]
 dw 0032h, 0035h, 0038h, 0039h, 003ah, 0ff3bh, 0ff3ch, 0ff3dh


> VESA Bios Extensions (VBE) 2.0 are discussed in Richard Wilton
"Programmer's
> Guide to PC Video Systems", 2nd Ed., Microsoft Press, 1994. Page 442
> describes the structure of the Mode Table (MODEINFOBLOCK).

Done, no problems. Looks like only above problem left.






0
UZnal
3/28/2006 11:39:21 PM
"Extended Graphics Mode Register Settings
3-218 XGA Function- May 7th 1992"

Do we have the other chapters? Sections on XGA-NI ...?

> We need a timing table as the one below for 800x600x16.

"The original XGA subsystem does not support XGA coprocessor
operations on 16 bit direct color bitmaps. The XGA-NI subsystem
provides full 16 bit direct color support."

> Mode800x600x8x60 label word
>  dw 0150h, 0050h, 8310h, 0011h, 6312h, 0013h, 6314h, 0015h
>  [..........]
>  dw 0032h, 0035h, 0038h, 0039h, 003ah, 0ff3bh, 0ff3ch, 0ff3dh

The second byte is the register index, e.g. 50, 50, 10, 11, 12 etc. 0150h
means "prepare for reset", 0151h means "reset CRT controller" etc.

Spread the mode tables in Lotus 1-2-3, go to page 3-218 in the above ref,
and fill in the blanks by deducing the numbers, just compare and decide.
About 55 entries in total, 45 defined (hopefully correct!), those below
remain to be defined. Though I have some idea and literature, I need the
exact hardware timings, better yet the few pages from the XGA-2 techref
describing XGA-2 Mode Settings.

Todo:
-----------------------
10 - Horiz Total Low
16 - Horiz Blank End Low
18 - Horiz Sync Start Low
1A - Horiz Sync End Low
1C - Horiz Sync Posn
1E - Horiz Sync Posn
20 - Vert Total Low
26 - Vert Blank End Low
28 - Vert Sync Start Low
2A - Vert Sync End (20 No Sync)
58 - ?? (xga-2 only)




0
UZnal
3/29/2006 9:36:31 PM
> Do we have the other chapters? Sections on XGA-NI ...?

Today is my lucky day, merci google.




0
UZnal
3/29/2006 10:58:41 PM
On Thu, 30 Mar 2006 00:58:41 +0200, "UZnal" <unalz-at-mail333-dot-com>
wrote:

>
>Today is my lucky day, merci google.

So give us a TinyURL with the google result you found!
+-----------------------------------------+
| Charles Lasitter   | Mailing/Shipping   |
| 401/728-1987       | 14 Cooke St        |
| cl+at+ncdm+dot+com | Pawtucket RI 02860 |
+-----------------------------------------+
0
Charles
3/30/2006 1:10:00 AM
> >Today is my lucky day, merci google.
>
> So give us a TinyURL with the google result you found!

Sure, offline. Timing parameters for XGA-2 extended modes are in the monitor
DMQS file. There is no bpp-setting setting there (index 43 - Buffer Pitch
Low) but it is in the driver XGA/XGA-2 mode tables. Does that mean the
bpp-setting does not afect the timings? It indeed looks so, I compared
VGA-8-bpp and VGA-16-bpp, 1024x768 4 and 8 bpp, only one difference. Timings
change for resolution and frame rate.

800x600 at 16 bpp (64K colors) at 60Hz:

The dot rate (or pixel rate) for this mode is 40 Mhz, that means 40,000,000
dots per second pass through the Video DAC and leave the card. The maximum
dot rate of the XGA-2 is 90 Mhz (XGA 45 Mhz). An 8-bpp (256 colors) dot
occupies one byte, and a 16-bpp (65,536 or 64K colors) dot occupies two
bytes. But if bytes are counted and not dots, the rate becomes 80 Mhz = 2 x
40 Mhz. That is, 40 Mhz dot rate and 80 Mhz "byte" rate.

The 40 Mhz dot rate are for a line rate of 37.9 Khz, that is, 37,900 lines
per second. 40 Mhz / 37.9 Khz = 1055 dots per line. The 255 dots (= 1055 -
800) are the overhead used for border, horizontal blanking etc. With 600
lines we have 37,900 / 600 = 63 frames per second. The extra frames ( 3 =
63 - 60) go to border, vertical blanking etc.

72 Hz at 800x600: the dot rate with 8 bpp is 50 Mhz. For 16 bpp, the
necessary byte bandwidth would be 100 Mhz, more than 90 Mhz. Can we
overclock the biest by 10% without video side-effects?

Full 90 Mhz at 50 Hz are reached at 1280x1024 with 8 bpp.

BTW,  mono/color LCD display type can be set in the DMQS file.







0
UZnal
3/30/2006 9:36:08 PM
> 800x600 at 16 bpp (64K colors) at 60Hz:

Mode settings table completed: test machine setup, code changes, builds and
tests must follow. Since there is no explicit bits-per-pixel register
setting, one just wonders how the card finds out the effective pixel width.
The solution is very clever, it goes indirectly through certain registers,
far from being obvious. I calculated the values for a 16-bpp for the mode.

There are more mysteries. The basic design has been set up for a 4M card and
a palette color is a 24-bit color, though only 256 palette colors are
defined. When you go to Direct Color Mode, you have to init 128 palette
colors according to a defined scheme, where R=0 G=0 B=1-bit set. Get the
idea? A 16-bit direct color pixel goes possibly through an 8-bit palette
location, a byte at a time and the empty half of the palette buffers one
byte, then joines with the second byte in the other half to produce a
palette color. In this way, a palette entry is redefined each time for each
16-bit pixel. With 256 palette locations, that translates into processing
512 8-bit pixels to simulate 16-bit pixel processing. I suspect, that
doubles the Pixel Rate.

The Pixel Rate is allowed to reach "128.00 MHz in 1.00MHz increments" but
"the maximum PEL Frequency that should be programmed for the XGA-NI
Subsystem is 90MHz."  Note, it says "should be" and not "must be"... Hmm, I
will certainly go beyond that to see if and how an XGA-2 could be toasted.

Video memory can be either 16-bit or 32-bit wide. There is no setting to
read out the amount of memory, you have to probe for it. That could mean,
the card is not hardwired for a certain memory size as long as it is below
4M.

The aperture (a window into video memory) - 64K, 1M or 4M has effect only
when the software exploits it. Real mode software (and W9x) works with a 64K
aperture, 1M or 4M are suitable only for protected mode operations.





0
UZnal
3/31/2006 2:11:13 PM
> Mode settings

Some AGX stuff: http://thorkildsen.no/faqsys/docs/iit.txt
Some XGA stuff: http://thorkildsen.no/faqsys/docs/xga.txt
Some 8514 stuff: http://thorkildsen.no/faqsys/docs/8514.txt
Video Adapters: http://thorkildsen.no/faqsys/cates/video.html

Interesting FAQSYS sections. How to open files: move the cursor before the
bullet of an entry in the list, and move and watch the shape to indicate a
link (an invisible dot).

> The basic design has been set up for a 4M card and
> a palette color is a 24-bit color
> [......]
> The Pixel Rate is allowed to reach "128.00 MHz in 1.00MHz increments"

http://intl.ieeexplore.ieee.org/xpl/abs_free.jsp?arNumber=93358

A 1-micron CMOS 128 MHz video serialiser, palette, and digital-to-analogue
(DAC) chip

Chesters, M.J.
IBM UK Lab. Ltd., Winchester;

This paper appears in: CompEuro '89., 'VLSI and Computer Peripherals. VLSI
and Microelectronic Applications in Intelligent Peripherals and their
Interconnection Networks', Proceedings. Publication Date: 8-12 May 1989

Abstract

The author describes a fully integrated 1-�m CMOS video serializer, color
palette, and digital-to-analog converter (DAC) chip, which is being designed
as a key component for a personal computer graphics system. One application
for this chip is in the IBM Image Adapter/A. The chip drives high-resolution
monitors up to 1600 by 1200 pixels at 128-MHz video frequency with 8
bits/pixel. It offers a palette of 256 colors selectable from a possible 16
million colors. The design represents the state of the art in mixed analog
and digital CMOS design. The design tools and methodology were chosen to
minimize the design time and provide right-first-time hardware. The key
features are a high-performance 256�24 palette RAM, three 8-bit DACs, a
reconfigurable video serializer, and approximately 6 K (equivalent) gates of
standard-cell logic to manage the control and interfacing of the chip

> Video memory can be either 16-bit or 32-bit wide.

Some other reference undocuments these settings, "x" in 21xAh is the XGA
instance  number (Ref. FAQSYS xga.txt):

21xAh index  0  (R/W):  Memory Configuration 0
bit   0-1  VRAM_SERDATA_WID. The width of serial VRAM transfers.
             1 = 16bit, 2 = 32bit.

21xAh index  1  (R/W):  Memory Configuration 1
bit     0  VRAM_RASCAS_EXT. If set extended CAS and RAS cycles are used for
           all cycles except refresh.
        1  VRAM_RAS_PRECH. If set extended RAS precharge time is used
           between consecutive VRAM cycles.
        2  VRAM_REF_EXT. If set extended CAS and RAS cycles are used for
           refresh.

21xAh index  2  (R/W):  Memory Configuration 2
bit     3  VRAM_SER_LEN. If set the VRAM serializer is 512 bits long rather
           than 256 bits.




0
UZnal
4/1/2006 11:01:36 AM
> > Video

Creative individuals.... To install the DDK, you must first install the SDK,
because the resource compiler RC.EXE is not in the DDK. To MASM in the DDK
you need ML.EXE (Macro Assembler Version 6.11c) which is again not in the
DDK. To LINK you need the MSVC 2.0, which is a separate product. You'd
expect a compatibility with the MSCV 6.0 linker but command line invocation
does not support any more "," and ";" in those driver makefiles. You end up
with three batch files setting up environments and then have to take care of
COMMON.VER to define the undefined. Hmm, you consolidate your environment
and put the few binaries so far in a common directory. Sunday juggler...
Stop and go watch the taped F-1.




0
UZnal
4/2/2006 12:32:30 PM
> Creative individuals....

Uuuh, even more... Careful, though not in the destination DDK still in the
source DDK, that is, on the CD, but won't be installed: ML.EXE and
LINK386.EXE, just a VC20 linker patch. Long story short, you end up using
three linkers: an older, true real mode linker for RES, the LINK386 for
xga.drv, and a later, VC6 linker for xga.vxd. At the end the resource
compiler strikes, LINK386 options must be ported to the VC6 linker, because
some ordering is different. Include only from the compiler, not from the
SDK. Much juggling, but it looks promising. Quite promising.

Very nice, there is a display driver certification test suite. Certified
driver, hmmm...??




0
UZnal
4/2/2006 10:26:15 PM
> an older, true real mode linker for RES

To whom it may help:

DDK directories XGA (xga.drv) and RES (VGA display.res): only this version
of the linker (IIRC, MSC 5.1), did the job:

Microsoft (R) Segmented-Executable Linker  Version 5.10
Copyright (C) Microsoft Corp 1984-1990.  All rights reserved.

The reason, I suppose, is the required WIN31 compatibility. Use the RC.EXE
from the MSTOOLS\BINW16 directory of the SDK. Other LINK + RC combinations
did not work for me and I had tested with four other MS linkers.

Above directories are 16-bit code, for the VGA functions. XGA.DRV manages
the VGA of XGA. By constrast, the 32-bit XGA.VXD manages the XGA extended
modes.

Comparing the XGA.DRV files, the one in W98SE shows some minor differences.




0
UZnal
4/3/2006 3:06:24 PM
Hi Unal,
> ...Some other reference undocuments these settings, "x" in
> 21xAh is the XGA instance  number (Ref. FAQSYS xga.txt):...
     How are these functions called?...

>  ...To MASM in the DDK you need ML.EXE (Macro Assembler
> Version 6.11c) which is again not in the DDK. To LINK you need
> the MSVC 2.0, which is a separate product. You'd expect a
> compatibility with the MSVC 6.0 linker but command line
> invocation does not support any more "," and ";" in those driver
> makefiles. You end up with three batch files setting up
> environments and then have to take care of COMMON.VER to
> define the undefined. Hmm, you consolidate your environment and
> put the few binaries so far in a common directory. Sunday juggler...
     MASM 6.x was vastly different from 5.1. I don't think many did the
switch from the 5.1 convention before Microsoft killed the product. 10-packs
of version 6 were dumped on the market while 5.1 held it's value.
     For the MSVC product I got the 1.0 version (something like 20+
compressed diskettes), but qualified for the free 1.5/1.52 upgrade (single
CD). From there I skipped to V4 (think they avoided a 3.0 version, or it was
short lived) & then again to V6. Never had any of the MSQC products.
                            David
                            David@IBMMuseum.com


0
David
4/3/2006 7:42:46 PM
Hi David,

> > ...Some other reference undocuments these settings, "x" in
> > 21xAh is the XGA instance  number (Ref. FAQSYS xga.txt):...
>      How are these functions called?...

According to the quoted document, "Memory Configuration 0", -1, -2. There
are some noticeable holes in the officially documented register indices. See
below how installed memory is probed for. Could this be the backdoor to more
memory?

Replace below "x" in 21xA with the instance number, e.g. 216A for instance
6.

....The Video Memory Base Address field defines a 32MB address range and the
Instance defines a 4MB address range within the 32MB range.

...There are two ways to determine the size of video memory installed. Both
rely on a write-readback-check, in which a particular value is written to a
key location. This value is then read to determine whether the written value
has persisted.

(1) Use the system processor to write a value through an aperture to the
word at offset 768KB into video memory. This technique assumes that the
system video memory real mode aperture is available. See the sample code in
the following figure.

(2) Use the XGA subsystem PxBlt capability to perform a test similar to the
previous example.

;* Assume GS points to start of A0000 Real mode aperture
;* and VGA adapter is in text mode so A0000 Real mode
;* aperture is available for this operation.
;* Where registers are shown as (for instance 21x0h), this should
;* be filled in with the appropriate IO port address after determining
;* the location of the XGA subsystem in IO space
;*
;* First put the adapter PARTIALLY in extended graphics mode
;* to allow use of the system video memory Aperture

mov al,0
mov dx,21x4h ; disable XGA interrupts
out dx,al
;
mov ax,0064h
mov dx,21xAh ; Blank palette
out dx,ax ; indexed XGA register 64h
;
mov ax,04h
mov dx,21x0h ; Set adapter in Extended Graphics Mode
out dx,al
;
mov al,01h
mov dx,21x1h ; Locate video memory Aperture at A0000
out dx,al
;
mov dx,21x8h ; System video memory index reg.
mov al,0ch ; Offset 768K (UZ: = 12 x 64K aperture)
out dx,al ;
;
mov byte ptr gs:[0],0A5h ; Set byte to A5h
mov byte ptr gs:[1],0h ; Avoid shadows on data lines
;
cmp byte ptr gs:[0],0A5h ; Test against value written
jne vram_512k ; 512K video memory only
;
mov byte ptr gs:[0],5Ah ; Set byte to 5Ah
mov byte ptr gs:[1],0h ; Avoid shadows on data lines
;
cmp byte ptr gs:[0],0A5h ; Test against value written
je vram_1Meg ; 1 Meg if still matches
jmp vram_512k


>      MASM 6.x was vastly different from 5.1. I don't think many did the
> switch from the 5.1 convention before Microsoft killed the product.

Here the reason:

....The second step requires the addition of the -coff and -DBLD_COFF
assembler switches to the assembler command line. The -coff switch
instructs the assembler to generate COFF instead of OMF. The -DBLD_COFF
switch defines BLD_COFF which will disable certain sections in VMM.INC
which are incompatible with COFF. The latest version of the assembler
which fully supports COFF is contained in the DDK\MASM611C directory.

> For the MSVC product

MSC 5.1 / 6.00 / 7.0 and MSCV 6.0 and .NET (on a DVD I can't yet read), all
licensed products. The variety of compiler versions resp. tools was this
time very, very helpful. To build an older Windows code, you really need the
tools of those times. There are lots of hick-hacks in the samples and only
properly patched tools manage that. I have now a clean and fully working
production environment.

>  Never had any of the MSQC products.

Wasn't that the one with the Programmer's Workbench? MSC 6.00 ? I can't
really say I liked it at all. You can't just abandon your favorite editor,
not in those days and not now.





0
UZnal
4/3/2006 10:15:53 PM
> >  XGA

Inserting and enabling the mode (800x600 @ 16-bpp) in the driver is the
easiest part, propagating the 16 bpp (64K colors) changes is the most time
consuming part. Now I have a pretty good picture on what is going on, and
that picture gets increasingly brighter. XGA-2 16-bpp operations must be
implemented, many ASM modules will be touched by this. Half-cooked spagetti
code made me spent the evening optimizing large parts.

The coprocessor steams at about 30%, now you know why it sucks.




0
UZnal
4/6/2006 10:00:02 PM
What if any possibility of 32k colors exist? Does the hardware support 
32k, and if so, does it offer better performance than 64k at some 
resolution/refresh?

UZnal wrote:
>>>  XGA
> 
> Inserting and enabling the mode (800x600 @ 16-bpp) in the driver is the
> easiest part, propagating the 16 bpp (64K colors) changes is the most time
> consuming part. Now I have a pretty good picture on what is going on, and
> that picture gets increasingly brighter. XGA-2 16-bpp operations must be
> implemented, many ASM modules will be touched by this. Half-cooked spagetti
> code made me spent the evening optimizing large parts.
> 
> The coprocessor steams at about 30%, now you know why it sucks.
> 
> 
> 
> 
0
Louis
4/6/2006 11:58:51 PM
> What if any possibility of 32k colors exist? Does the hardware support
> 32k, and if so, does it offer better performance than 64k at some
> resolution/refresh?

Everything which is not a nice power of 2 is bad. 32K colors fit in 15 bits,
that is again two bytes. 64K is one bit more. The XGA-2 hardware should do
it just fine and even the XGA hardware could do 64K colors *interlaced* if
you bother to shuffle bits and bytes, but that is too much pixel
arithmetics.

A better solution would be only an XGA-2 support, because there is not much
to do for XGA (512K) and AGX resp. the W9x driver does it already. One thing
I miss is hardware Line Draw (Bresenham), this is done for some (?) reason
in software.

The driver has been written for XGA (512K) and AGX. Obviously, XGA-2 support
has been added later without further exploiting the XGA-2 capabilities. AGX
itself is an XGA hack for more colors but nothing more.




0
UZnal
4/7/2006 12:48:00 PM
Please, please, PLEASE include support for XGA 1MB, 640x480, 64k if 
possible. All Model 90 owners will be very appreciative.

UZnal wrote:
>> What if any possibility of 32k colors exist? Does the hardware support
>> 32k, and if so, does it offer better performance than 64k at some
>> resolution/refresh?
> 
> Everything which is not a nice power of 2 is bad. 32K colors fit in 15 bits,
> that is again two bytes. 64K is one bit more. The XGA-2 hardware should do
> it just fine and even the XGA hardware could do 64K colors *interlaced* if
> you bother to shuffle bits and bytes, but that is too much pixel
> arithmetics.
> 
> A better solution would be only an XGA-2 support, because there is not much
> to do for XGA (512K) and AGX resp. the W9x driver does it already. One thing
> I miss is hardware Line Draw (Bresenham), this is done for some (?) reason
> in software.
> 
> The driver has been written for XGA (512K) and AGX. Obviously, XGA-2 support
> has been added later without further exploiting the XGA-2 capabilities. AGX
> itself is an XGA hack for more colors but nothing more.
> 
> 
> 
> 
0
Louis
4/7/2006 9:30:13 PM
> Please, please, PLEASE include support for XGA 1MB, 640x480, 64k if
> possible. All Model 90 owners will be very appreciative.

This is VESA Mode 111h and is already coded in the driver. Can someone
confirm that this mode is NOT usable/selectable on the 1MB XGA?




0
UZnal
4/8/2006 10:57:42 AM
> > XGA 1MB, 640x480, 64k

Frequencies:
    XGA: fixed, 640x480 at 16-bpp at 60 Hz. Max 45 Mhz dot rate.
    XGA-2: programmable. Max 90 Mhz dot rate.

Coprocessor:
    XGA: 1, 2, 4 and 8 bits per pixel
    XGA-2: 1, 2, 4, 8 and 16 bits per pixel

Palette:
    XGA colors: 256 out of 256K colors (18-bit)
    XGA-2 colors: 256 out of 16M (24-bit)

Direct color:
    XGA: 16-bpp display mode only, no coprocessor support
    XGA-2: 16-bpp packed pixel format, full coprocessor support

W9x driver:
    XGA/XGA-2 - no coprocessor Bit Block transfers at 16-bpp.
    AGX - uses at 16 bpp a similar workaround as described below.
    ** XGA-2 to do: enable coprocessor 16-bpp Bit Block transfers


XGA coprocessor only (PEL = pixel):

The XGA coprocessor does not support the 16 bits-per-PEL (bpp) mode.
This mode is a display mode only, and must be programmed using
the system processor to access the video memory display buffer
directly using one of the system video memory apertures.

The coprocessor is not disabled in this mode. However, the PEL
map formats available for coprocessor operations are restricted to
1, 2, 4, or 8 bpp. The coprocessor can be used in this mode if the
application manages the differences in bits per PEL. Some
ingenuity is required to achieve useful results using the
coprocessor in this way.

Bit Block Transfer Operations

By using the PxBlt operations on an 8-bpp bit map,
doubling the dimension width of the bit maps involved,
and avoiding arithmetic mixes, bit block transfer
operations are possible. Use of the 1-bpp pattern and
mask maps are possible if carefully considered and
calculated.

Text Operations

Text operations using the coprocessor PxBlt function
rely on 1-bpp patterns. By doubling the width of the
individual character bit map patterns (interspersing the
active bits with zero bits) and writing the high and low
order bytes of the required color index separately, text
operations are possible.






0
UZnal
4/8/2006 10:14:02 PM
UZ, do you have a copy of "Power Programming... the IBM XGA", ISBN 
1558281274? It's based on the HITR for the XGA and XGA-NI, and might 
give you some advise.

UZnal wrote:
>>> XGA 1MB, 640x480, 64k
> 
> Frequencies:
>     XGA: fixed, 640x480 at 16-bpp at 60 Hz. Max 45 Mhz dot rate.
>     XGA-2: programmable. Max 90 Mhz dot rate.
> 
> Coprocessor:
>     XGA: 1, 2, 4 and 8 bits per pixel
>     XGA-2: 1, 2, 4, 8 and 16 bits per pixel
> 
> Palette:
>     XGA colors: 256 out of 256K colors (18-bit)
>     XGA-2 colors: 256 out of 16M (24-bit)
> 
> Direct color:
>     XGA: 16-bpp display mode only, no coprocessor support
>     XGA-2: 16-bpp packed pixel format, full coprocessor support
> 
> W9x driver:
>     XGA/XGA-2 - no coprocessor Bit Block transfers at 16-bpp.
>     AGX - uses at 16 bpp a similar workaround as described below.
>     ** XGA-2 to do: enable coprocessor 16-bpp Bit Block transfers
> 
> 
> XGA coprocessor only (PEL = pixel):
> 
> The XGA coprocessor does not support the 16 bits-per-PEL (bpp) mode.
> This mode is a display mode only, and must be programmed using
> the system processor to access the video memory display buffer
> directly using one of the system video memory apertures.
> 
> The coprocessor is not disabled in this mode. However, the PEL
> map formats available for coprocessor operations are restricted to
> 1, 2, 4, or 8 bpp. The coprocessor can be used in this mode if the
> application manages the differences in bits per PEL. Some
> ingenuity is required to achieve useful results using the
> coprocessor in this way.
> 
> Bit Block Transfer Operations
> 
> By using the PxBlt operations on an 8-bpp bit map,
> doubling the dimension width of the bit maps involved,
> and avoiding arithmetic mixes, bit block transfer
> operations are possible. Use of the 1-bpp pattern and
> mask maps are possible if carefully considered and
> calculated.
> 
> Text Operations
> 
> Text operations using the coprocessor PxBlt function
> rely on 1-bpp patterns. By doubling the width of the
> individual character bit map patterns (interspersing the
> active bits with zero bits) and writing the high and low
> order bytes of the required color index separately, text
> operations are possible.
> 
> 
> 
> 
> 
> 
0
Louis
4/9/2006 12:51:13 PM
> UZ, do you have a copy of "Power Programming... the IBM XGA"

No, but 16-bpp XGA coprocessor hacks are a bit too early for this stage. I'd
recommend using an XGA-2 in Mod. 90 (nobody seems to run W9x on it anyway).
Selecting the better XGA-2 is much more easily implemented, that is, it can
be
selected which adapter to use if there are multiple XGAs or XGA-2s.






0
UZnal
4/9/2006 1:41:06 PM
Perhaps the reason nobody runs W9x on it is that the XGA support sucks. 
You have 4 MCA slots to play with, and who wandts to burn one for an add 
in video card?

UZnal wrote:
>> UZ, do you have a copy of "Power Programming... the IBM XGA"
> 
> No, but 16-bpp XGA coprocessor hacks are a bit too early for this stage. I'd
> recommend using an XGA-2 in Mod. 90 (nobody seems to run W9x on it anyway).
> Selecting the better XGA-2 is much more easily implemented, that is, it can
> be
> selected which adapter to use if there are multiple XGAs or XGA-2s.
> 
> 
> 
> 
> 
> 
0
Louis
4/9/2006 6:08:48 PM
On Sun, 9 Apr 2006 15:41:06 +0200, "UZnal" <unalz-at-mail333-dot-com>
wrote:

> I'd recommend using an XGA-2 in Mod. 90

I'll say.  They're a dime a dozen!  Let's get practical.  I can smell
the end zone!
+-----------------------------------------+
| Charles Lasitter   | Mailing/Shipping   |
| 401/728-1987       | 14 Cooke St        |
| cl+at+ncdm+dot+com | Pawtucket RI 02860 |
+-----------------------------------------+
0
Charles
4/9/2006 8:50:25 PM
> Perhaps the reason nobody runs W9x on it is that the XGA support sucks.
> You have 4 MCA slots to play with, and who wandts to burn one for an add
> in video card?

I have only three slots in my Mod. 70 and one is occupied by the XGA-2.
I'll put that aside as a later option, first the high priority tasks and the
assurance that we've been handed out the right piece of code.







0
UZnal
4/9/2006 9:14:02 PM
Charles, I _AM_ practical [or was that reality?].

XGA-2 will be the most flexible option. W9x drivers MIGHT be useable 
under NT4, I hope. Miniport, anyone?

Charles Lasitter wrote:
> On Sun, 9 Apr 2006 15:41:06 +0200, "UZnal" <unalz-at-mail333-dot-com>
> wrote:
> 
>> I'd recommend using an XGA-2 in Mod. 90
> 
> I'll say.  They're a dime a dozen!  Let's get practical.  I can smell
> the end zone!
> +-----------------------------------------+
> | Charles Lasitter   | Mailing/Shipping   |
> | 401/728-1987       | 14 Cooke St        |
> | cl+at+ncdm+dot+com | Pawtucket RI 02860 |
> +-----------------------------------------+
0
Louis
4/9/2006 9:59:15 PM
UZ, you didn't respond to my triple secret query on those two books. 
What do you wandt me to do? [sorry, y'all, "go get %&#@ed" is NOT a 
possible choice].

UZnal wrote:
>> Perhaps the reason nobody runs W9x on it is that the XGA support sucks.
>> You have 4 MCA slots to play with, and who wandts to burn one for an add
>> in video card?
> 
> I have only three slots in my Mod. 70 and one is occupied by the XGA-2.
> I'll put that aside as a later option, first the high priority tasks and the
> assurance that we've been handed out the right piece of code.
0
Louis
4/9/2006 10:01:46 PM
> UZ, you didn't respond to my triple secret query on those two books.
> What do you wandt me to do? [sorry, y'all, "go get %&#@ed" is NOT a
> possible choice].

Entertain me ?? Programming is a lonely job. Thanks, no books right now, the
techref is exciting and comprehensive enough, I saw the divine blue light...

Just say again how to enable CD-ROM under DOS on Mod. 57 and 77,
I have to install W95 and W98SE there. This W95 is a special MSDN
edition, fits on 60M or less.

I must say, CL has a good nose....;)






0
UZnal
4/10/2006 12:03:41 AM
> Entertain me ??

Why don't we do 132 columns text modes?

Extracting mode settings from the DQMS files, manually, through a hex
editor. Why this? Without DMQS we need some more built-in refresh rate
flexibility, 60, 72 and 75 Hz for all modes, 70 Hz and less for some other.
The W9x driver is using the 60 Hz VGA of the XGA also for the XGA-2, not so
good. Below the map:

640x480:
    60, 72 and 75 Hz with 256 / 64K colors

800x600:
    60, 72 and 75 Hz with 256 colors.
    60 Hz with 64K colors
    72 Hz with 64K colors ** Pixel rate beyond the specs, to test.

1024x768:
    60, 70, 72 and 75 Hz with 256 colors.

More modes:

1280x1024:
    Below 50 Hz ?? Interlaced with 16 colors

1280x960:
    Below 50 Hz  ?? Interlaced with 16 colors (pending)

1360x1024:
    Below 50 Hz  ?? Interlaced with 16 colors (pending)





0
UZnal
4/11/2006 10:41:00 PM

UZnal wrote:
> 800x600:
>     72 Hz with 64K colors ** Pixel rate beyond the specs, to test.

What pixel clock? I would assume the heatsink version is not capable, 
but the bare ceramic MIGHT be. And the blue version most likely is...

I noticed that the XGA can be set to use either clock frequency from 
it's oscillators, OR it may use one supplied over the feature connector.

0
Louis
4/12/2006 12:15:23 PM
> > 800x600:
> >     72 Hz with 64K colors ** Pixel rate beyond the specs, to test.
>
> What pixel clock? I would assume the heatsink version is not capable,
> but the bare ceramic MIGHT be. And the blue version most likely is...

We'll see in a while, toast or not... The pixel rate (not clock) is 50 Mhz,
for 75 Hz it is 52 Mhz. I suspect the double of these rates for 16-bpp.

Look at this: IBM 9517 monitor defines for 1360x1024 with 4-bpp 16 colors a
frame rate of 53 Hz interlaced and 106 Mhz pixel rate. Now, if the 106 Mhz
are halved, we have 53 Mhz pixel rate, and this is more than the needed 50
Mhz or 52 Hz for 64K.

I looked at the monitors with the XGA-2 applet of Win3.1 (XGA212.DRV).
Strange, the applet seems to misinform: if there is only one resolution for
a 800x600 mode, it allows you to select 64K colors, regardless of the frame
rate. If there are two resolutions, it allows you to select only the lower
one for the 64K colors. Also the "ViewSonic 7" monitor claims to do 55.8 Hz
NI on 1280x1024 16 colors, while other monitors, e.g. 9517, define it as
interlaced using the same Mhz and kHz.

> I noticed that the XGA can be set to use either clock frequency from
> it's oscillators, OR it may use one supplied over the feature connector.

True, this is done at mode setting time, a combination of register index  54
and 70, omitting the bit values:

- VGA 8-PEL Character Mode and 640x 480 Graphics Mode Clock
- VGA 9-PEL Character Mode Clock
- Clock Sourced from Video Extension Interface
- 1024 x 768 Graphics Mode Clock
- 132-Column Text Mode Clock (8 PEL Characters)
- Programmed PEL Clock (***Ed: XGA-2 only)






0
UZnal
4/12/2006 2:31:14 PM
Erk. I wish I could hang a different osc on a 90 in order to get an 
800x600 resolution... I think the card would be hackable, but why not 
stick in an XGA-2 if you have to use a card?

I wonder if you can attach another osc to a 90 [without removing 
installed osc] and get the 800x600?

UZnal wrote:

>> I noticed that the XGA can be set to use either clock frequency from
>> it's oscillators, OR it may use one supplied over the feature connector.
> 
> True, this is done at mode setting time, a combination of register index  54
> and 70, omitting the bit values:
> 
> - VGA 8-PEL Character Mode and 640x 480 Graphics Mode Clock
> - VGA 9-PEL Character Mode Clock
> - Clock Sourced from Video Extension Interface
> - 1024 x 768 Graphics Mode Clock
> - 132-Column Text Mode Clock (8 PEL Characters)
> - Programmed PEL Clock (***Ed: XGA-2 only)
> 
> 
> 
> 
> 
> 
0
Louis
4/12/2006 2:50:12 PM
> I wonder if you can attach another osc to a 90 [without removing
> installed osc] and get the 800x600?

We'll have to watch the graphics engine, the coprocessor. There are some
more differences, I think the XGA-2 has a reworked coprocessor.

I found 90 Hz 64K 640x480 mode settings, NEC MultiSync 6FG:

640x480: 89.6 Hz, 38 Mhz PEL, 45.2 kHz Line
800x600: 88 Hz, 62 MHz PEL, 58.7 kHz Line

*** Wait, wait, I see something there (looking at my notes):

Sony GDM-2036S / GDM-2038: 800x600, 75 Hz, 45 MHz PEL, 46.9 kHz Line

If that is correct, even with a doubled pixel rate 2 x 45 MHz = 90 MHz we
stay within the techref limit, that means, 800x600 64K at 75 Hz !!! 8-bpp or
16-bpp do not depend on the mode settings given in the DMQS monitor files.

I'll have to extract the Sony mode and manually verify the encoding. If you
have a nice continously multisyncing monitor (Eizo F56 operates in the range
27 - 86 kHz), you'll have no any problems with the line rate.

In the early 1990s most monitors were operating at a few fixed frequencies,
so you couldn't just go, calculate and demand some weird line rate. Today we
can do that, we have the better monitors, and most probably we will disprove
the techref as well.

You can set any mode on the XGA-2 as long as you know the timings. The
techref does not explain how to calculate mode settings, so I am getting the
basic settings from the DMQS files, merge with other common settings, e.g.
sprite registers, and add the registers dealing with the bits-per-pixels.






0
UZnal
4/12/2006 9:27:48 PM
> Sony GDM-2036S / GDM-2038: 800x600, 75 Hz, 45 MHz PEL, 46.9 kHz Line

Sony GDM-2038 does 72 Hz, for the same PEL and Line, with a few different
register settings.

IBM too:
    IBM 6325 (15V) 9525 (15P):  800x600: 72.1, 45 Mhz, 45.4 kHz

You see, I am searching for a 45 Mhz PEL rate with at least a 72 Hz refresh
rate at 800x600. Two nice hits, and it is time to decide which "monitor" to
use.



0
UZnal
4/12/2006 11:21:47 PM
IBM PS/VALUEPOINT COLOR DISPLAYS (6312, 6314, 6319)
800x600  Vert 72Hz / Horiz 48.1Khz NI	64K / 256

6312 -- ENTRY DISPLAY
o   Ideal for text and entry-level windowing:
     -   800 x 600 pixels, 72Hz non-interlaced refresh rate,
         0.28mm dot pitch, 14-inch screen, offering 56% greater data
         content over 640 x 480 pixels without compromising text
         clarity.
     -   1024 x 768 at 60Hz non-interlaced refresh rate for good
         graphics.
6314 -- MAINSTREAM DISPLAY
o   Designed for a wide variety of windowing and graphics:
     -   640 x 480 at 72Hz non-interlaced and 75Hz non-interlaced
         refresh rates
     -   800 x 600 at 72Hz non-interlaced refresh rate
     -   1024 x 768 at 72Hz non-interlaced refresh rate
o   Convenient, flexible image controls:
     -   Internal microprocessor
     -   Controls for user setup of front of screen
     -   Preset display modes
     -   User selectable display modes.
6319 -- HIGH FUNCTION DISPLAY
o   Designed for the professional user:
     -   Multiscanning to 1024 by 768 at 72Hz non-interlaced on
         15-inch FST enables high-performance windowing without
         compromising front-of-screen clarity
o   Convenient, flexible image controls:
     -   Internal microprocessor
     -   Controls for user setup of front of screen
     -   Preset display modes
     -   User selectable display modes.

UZnal wrote:
>> Sony GDM-2036S / GDM-2038: 800x600, 75 Hz, 45 MHz PEL, 46.9 kHz Line
> 
> Sony GDM-2038 does 72 Hz, for the same PEL and Line, with a few different
> register settings.
> 
> IBM too:
>     IBM 6325 (15V) 9525 (15P):  800x600: 72.1, 45 Mhz, 45.4 kHz
> 
> You see, I am searching for a 45 Mhz PEL rate with at least a 72 Hz refresh
> rate at 800x600. Two nice hits, and it is time to decide which "monitor" to
> use.
> 
> 
> 
0
Louis
4/12/2006 11:51:06 PM
> IBM PS/VALUEPOINT COLOR DISPLAYS (6312, 6314, 6319)
> 800x600  Vert 72Hz / Horiz 48.1Khz NI 64K / 256

Could be, but to start with, should not exceed 45 Mhz pixel rate at 800x600.
I'll certainly try the higher rates as well. For 800x600:

> 6312 -- ENTRY DISPLAY: Monitor ID F5FB,  50 Mhz PEL
> 6314 -- MAINSTREAM DISPLAY: Monitor ID F5FC, 52 Mhz PEL
> 6319 -- HIGH FUNCTION DISPLAY: Monitor ID F5FD, 52 Mhz PEL

Quick tip: How to read out XGA-2 mode data from a *.DGS file (e.g.
MONF5FB.DGS):

7E 00
20 03 58 02 03 05 00 00 � 00 00 02 00 18 00 C8 00
E1 01 D2 02 00 00 01 50 � 01 01 50 00 01 10 81 01
................
01 70 00 01 58 63 01 54 � 81 01 50 07 7E 00 20 03

(0) You need a hex view, with a hex search option (e.g. FAR, rarsoft.com)
(1) Search for 7E 00 (= length field of mode data). See sample block above.
(2) The four bytes (= two words) following 7E 00 are the mode resolution.
(3) Read them backwards: 20 03 is 320h = 800, and 52 02 is 258h = 600.
    (4) Next two bytes are XGA implementation level, normally 03 05
    (5) Next four bytes are vendor specific, 00 00 00 00 normally.
    (6) Next two bytes, 02 00, is the mode function, 02 is NI and normal
mode.
    (7) Next two bytes is an offset, 18 00 normally.
(5) The two bytes following 18 00 are four times the PEL rate, that is, C8
00 is
C8h = 200 / 4 = 50 Mhz
(6) Next two bytes are ten times the Line rate, E1 01 is 1E1h = 481 = 48.1
kHz.
(7) Next two bytes are ten times the Frame rate, D2 02 is 2D2h = 722 = 72.2
Hz
(8) Next two bytes are usually 00 00 (= optional extension)
(9) Byte triplets follow giving the register settings. A triplet begins
normally with 01 (= write to indexed access I/O register), 01 is the
operation code (00 ... 05).
The second byte is the register, the third byte is the value. For our
sample:

01 50 01 = 0150h  -- 50 Prepare for reset
01 50 00 = 0050h  -- 50 Reset CRT controller
01 10 81 = 8110h  -- 10 Horizontal total low
01 ......
01 54 81 = 8154h  -- 54  Clock select (0454 = Select VGA Oscillator)
01 50 07 = 0750h  -- 50  Display Mode 1

Don't be surprised there are 34 triplets (that was the number I always got).

(10) Next two bytes should be 7E 00 indicating a new mode settings. In the
sample above, 7E 00 20 03 introduces another 800x600 mode. If you see
instead 0A, you have reached the end of file.

End of Quick Tip.

A complete mode setting is about 55 triplets, where the additional 20+
triplets are non-monitor specific settings. The triplets are first
translated to value-register pairs and OUTed at once: "rep  outs dx, word
ptr [esi]" at the proper time.

I let an editor macro do the value-register pair transformation for me.
Actually, with an Aedit macro it will be possible to decode a complete DGS
file and list the mode data in a better understandable form, run the macro
over all DGS files. This could be a useful doc for the user, showing them
the supported monitor(s).






0
UZnal
4/13/2006 12:54:12 PM
> XGA-2

The Win driver does not strictly follow the order of register writes at
setting an extended mode as outlined in the techref. That works obviously
but may cause spurious data at changing a mode. I'd like to stay clean and
strictly follow the big blue order, so I am separating (1) DMQS file mode
data, (2) bits-per-pixel settings and (3) common sprite regs writes. The
side effect is less individual mode bytes by using common parts, and less
driver bytes. Supporting 60, 72, 75 Hz means a mode table for each refresh
rate and each bpp-setting, you easily end up with six tables for 8- and
16-bpp, and this for each resolution. I want to reuse invariant data and
prepare it for possibly later DMQS-like handling.

For the XGA-2, there are alternatives for the palette init, I'd like to
check them all, XGA-2 blue was too dark on NT, probably because it uses the
XGA way of palette init. If it were a pure XGA-2 driver (not now, perhaps
later), the DMQS BIOS interface could be used (excerpts follow):

The primary [DMQS] data is returned to the software via an INT 10 Video BIOS
code point.

These calls return DMQS primary data for all XGA subsystems present in the
system, both XGA and XGA-NI. XGA-NI subsystems recognise and provide DMQS
services for non DMQS capable XGA subsystems.

Adapter and System Diskettes:

Configuration information for future video subsystems must include a
composite DMQS display file. The composite file is made up of the individual
DMQS display information files for all displays available at that time. It
is made by merging the individual display information files into a composite
file. The individual files can be merged in any order.

The naming convention for the composite display file is the adapter ID
followed by the letter M with an extension of DGS. For an adapter with a POS
ID of hex 8FD9, the filename for the composite file is 8FD9M.DGS. (**Ed:
Ever seen such a file ??)

Future systems with the XGA subsystem integrated on the system board will
provide the composite file on the Reference Diskette. Adapters will provide
the file on the Option Diskette.

==================================================
DMQS BIOS Interface

The Adapter POST 'hooks' the INT 10 Video BIOS to point to two new code
points. One code point returns the total size of the DMQS data array for all
XGA instances. The other code point returns the DMQS data to the caller's
buffer.

The DMQS primary data contains the following information for each XGA
instance:

- XGA implementation level identifier
- Location of XGA I/O registers or ports in I/O space
- Location of memory mapped XGA registers in system address space
- Location of 1 Meg memory mapped XGA aperture
- Location of 4 Meg memory mapped XGA aperture
- System address at which the XGA accesses video memory
- The composite ID of the attached display
- Amount of video memory available (Ed: number of 256K blocks)

The following two Video Int 10h code points are required to pass DMQS data
to the software.

Video BIOS Int 10h Software Interrupt function
 (AH) = 1FH - XGA Display Mode Query and Set (DMQS)
 (AL) = 00H - Read DMQS Data Length
On Return:
 (AL) = 1FH - function supported
 (BX) = Number of bytes of DMQS data

Video BIOS Int 10h Software Interrupt function
 (AL) = 01H - Read DMQS Data
 (ES:DI) - User buffer pointer for return of information
On Return:
 User buffer contains DMQS data
 (AL) = 1FH - function supported

As many as eight instances of XGA are possible. One copy of the following
data structure exists for every instance:

(DI+00H) word - Offset in bytes to DMQS data for next XGA instance

(DI+02H) byte - Slot number

(DI+03H) byte - XGA implementation function level identifier:
        Identifies the level of the DisplayController chip
        = 03h  Base XGA implementation (XGA Display Adapter/A)
        = 05h  XGA-NI implementation level of function

(DI+04H) byte - XGA implementation resolution level identifier
     Identifies the level of the Serializer Palette DAC chip
     = 00h  Base XGA implementation (XGA Display Adapter/A) (Max 45 MHz Pel
rate)
     = 03h  XGA-NI Serializer Palette DAC. (Max 90 MHz Pel rate)

(DI+05H) word - Vendor identifier - identifies card vendor

(DI+07H) word - Vendor defined field

(DI+09H) word - XGA Adapter I/O register base address

(DI+0BH) word - XGA Coprocessor register base address - The
    location of memory mapped XGA coprocessor
    registers in system address space
    Multiply the value of this field by 10h to
    get the physical address

(DI+0DH) word - 1 Megabyte System Video Memory Aperture - The
    location of 1 meg memory mapped XGA aperture
    in physical address space. A value of 0
    indicates that the aperture is not allocated.
    Multiply the value of this field by 100000h
    to get the physical address

(DI+0FH) word - 4 Megabyte System Video Memory Aperture - The
    location of 4 meg memory mapped XGA aperture
    in physical address space. A value of 0
    indicates that the aperture is not allocated.
    Multiply the value of this field by 100000h
    to get the physical address

(DI+11H) word - Video Memory Base Address - The location of video
    memory in XGA system address space. Multiply the
    value of this field by 100000h to get the physical
    address.

(DI+13H) word - Composite ID of the attached display

(DI+15H) byte - Amount of video memory available,
    in multiples of 256K bytes

(DI+16h) dword - Alternate XGA Coprocessor register base address -
    The location of alternative memory mapped XGA
    coprocessor registers in protect mode system
    address space. A value of 0 indicates that the
    alternative register location does not exist. A
    non-zero value is the physical location in system
    address space. *** If present, higher performance is
    available using the registers at this location. ****

(DI+?? ) misc - DMQS Data for further XGA Instances










0
UZnal
4/14/2006 1:57:05 PM
> The primary [DMQS] data

Avoid MON0303.DGS, Sony GDM-2038, 800x600 72 Hz, 46.9 kHz, 45 Mhz is set up
as INTERLACED which is an obvious bug, and a much higher res mode is set as
NI which is not possible at all on the XGA-2.

MON0F00.DGS, IBM 6091-019 is most unusual, it skips the pixel, frame and
line rate values, the mode setting table is however complete (this irritated
the IBM applet, it showed a frame rate of 8 Hz and a pixel rate of 5200 Mhz
or so).


The do-it-yourself solution to mine monitor selection resp. hard coding
monitor settings problem, is to browse all monitor files and enumerate the
mode specs. The 1-2-3 XGA-2 spreadsheeet is getting crowded with too many
numbers, but I must do that, who else. Think and calculate first, code
later.

For the higher res modes, IBM 9517 can be used as a reference, where
1360x1024 and 1280x1024 are interlaced.

Below some common line rates, these should be supported by a wider range of
older monitors (but not by all IBM monitors). The least common denominator
is:

31.5 kHz:
    640x400     70.1 Hz  (VGA standard)
    640x480     59.9 Hz  (VGA standard)
    (Ed: IBM uses 31.6 and 31.5 on 8513, but all VGA monitors do 31.5)

37.9 kHz
    640x400     84.3 Hz
    640x480     72.8 Hz  (VESA Standard)
    800x600     60.3 Hz  (VESA Guideline)

39.4 kHz
    640x400     87.7 Hz
    640x480     75.0 Hz (XGA-2 monitors)

48.1 kHz
    800x600     72.2 Hz (VESA Standard, 50 Mhz pixel rate)

50.0 kHz
    800x600     75.1 Hz (52 Mhz Pixel rate)

16-bpp (non-standard line rate here)
    800x600     71 - 75 Hz with 45 Mhz Pixel rate
                    Options: 44.6    45.4    45.7    46.1    46.9 kHz
    46.9 kHz promises 75 Hz at 16-bpp.

56.5 kHz
    1024x768     70.1 (VESA Standard)

61.1 kHz
    1024x768    75.8 Hz    (XGA-2 monitors)
    1104x828    70.7 Hz    (hack IBM 9515 to do this)












0
UZnal
4/16/2006 2:01:42 PM
> The do-it-yourself solution

XGA.VXD done, now moving to the VGA parts and approaching the grand finale.

As it is, I end up reworking the complete VXD. From the 3000 lines of
assembly code (inc. comments and white space), about 1000 deal with the
initial setup, card detection and card configuration. This part I left
largely untouched.  From the rest 2000 lines, about 2/3 have been completely
revised and 1/3 rewritten.

The VXD became by 1300 bytes smaller than the original driver and contains
at the same time more mode tables and more resolutions. Clean and lean !

Look at the original XGA.ASM code, at line 1294 is a bits-per-pixel bug, I
don't know if that code ever worked, but if it did, it should have been the
bpp-setting in the mode init sequence. The check below takes place however
before the init sequence is OUTed, i.e. the mode init parameters written to
the XGA registers:

     inc dl                               ; EDX --> MemoryAccessMode (21x9)
     mov al,03h                       ;assume 16 BPP ** BUG: must be 04h
     cmp [ebp].Client_BL,11h     ;running 16 BPP? (Ed: 640x480x16)
     je @F                               ;yes, go set it
     ......
     mov al,03h                       ;must be 8 BPP ** Ed: 03h is 8 BPP
@@: out dx,al


XGA.VXD can be now tested on XGA or XGA-2, it replaces the original XGA.VXD
and should provide the same old services but without the new resolutions. I
did not test it yet. So, who wants to burn in or burn out their precious
XGA-2?

www.members.aon.at/mcabase/pub/files/xga.vxd










0
UZnal
4/19/2006 12:54:33 PM
What M$ systems does this run on? W9x and or NT?

UZnal wrote:
>> The do-it-yourself solution
> 
> XGA.VXD done, now moving to the VGA parts and approaching the grand finale.
> 
> As it is, I end up reworking the complete VXD. From the 3000 lines of
> assembly code (inc. comments and white space), about 1000 deal with the
> initial setup, card detection and card configuration. This part I left
> largely untouched.  From the rest 2000 lines, about 2/3 have been completely
> revised and 1/3 rewritten.
> 
> The VXD became by 1300 bytes smaller than the original driver and contains
> at the same time more mode tables and more resolutions. Clean and lean !
> 
> Look at the original XGA.ASM code, at line 1294 is a bits-per-pixel bug, I
> don't know if that code ever worked, but if it did, it should have been the
> bpp-setting in the mode init sequence. The check below takes place however
> before the init sequence is OUTed, i.e. the mode init parameters written to
> the XGA registers:
> 
>      inc dl                               ; EDX --> MemoryAccessMode (21x9)
>      mov al,03h                       ;assume 16 BPP ** BUG: must be 04h
>      cmp [ebp].Client_BL,11h     ;running 16 BPP? (Ed: 640x480x16)
>      je @F                               ;yes, go set it
>      ......
>      mov al,03h                       ;must be 8 BPP ** Ed: 03h is 8 BPP
> @@: out dx,al
> 
> 
> XGA.VXD can be now tested on XGA or XGA-2, it replaces the original XGA.VXD
> and should provide the same old services but without the new resolutions. I
> did not test it yet. So, who wants to burn in or burn out their precious
> XGA-2?
> 
> www.members.aon.at/mcabase/pub/files/xga.vxd
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
0
Louis
4/19/2006 1:18:33 PM
On Wed, 19 Apr 2006 14:54:33 +0200, "UZnal" <unalz-at-mail333-dot-com>
wrote:

> XGA.VXD done, now moving to the VGA parts and approaching the grand 
> finale.

I'm amazed at how quickly you're going thru this.  Are you the last
person on the planet that knows how to code in assembly?  We once had
programs that ran faster because the whole thing was done this way,
which of course became impractical because of portability.

I think the original assembly coders spent a lot more time THINKING
about how to best use the computer's resources -- something that has
also long since gone out the window.

Does anyone still code specific intensely used program loops in
assembly?  That gave folks the benefit of mostly portable code and the
benefit of speed where it was needed most.

And now we have Visual Everything and JAVA -- moving a gazillion
abstraction levels away from the hardware.

It breaks my heart that we couldn't have got onto this project some
years ago. Suffering while Win95 apps fought over a 256 color pallet is
one of the things I think lead to the early demise of many fine
machines.
+-----------------------------------------+
| Charles Lasitter   | Mailing/Shipping   |
| 401/728-1987       | 14 Cooke St        |
| cl+at+ncdm+dot+com | Pawtucket RI 02860 |
+-----------------------------------------+
0
Charles
4/19/2006 1:44:16 PM
Louis Ohland wrote:
> What M$ systems does this run on? W9x and or NT?

Being a VXD, it'd be W9x.

--Daniel

> 
> UZnal wrote:
>>> The do-it-yourself solution
>>
>> XGA.VXD done, now moving to the VGA parts and approaching the grand 
>> finale.
>>
>> As it is, I end up reworking the complete VXD. From the 3000 lines of
>> assembly code (inc. comments and white space), about 1000 deal with the
>> initial setup, card detection and card configuration. This part I left
>> largely untouched.  From the rest 2000 lines, about 2/3 have been 
>> completely
>> revised and 1/3 rewritten.
>>
>> The VXD became by 1300 bytes smaller than the original driver and 
>> contains
>> at the same time more mode tables and more resolutions. Clean and lean !
>>
>> Look at the original XGA.ASM code, at line 1294 is a bits-per-pixel 
>> bug, I
>> don't know if that code ever worked, but if it did, it should have 
>> been the
>> bpp-setting in the mode init sequence. The check below takes place 
>> however
>> before the init sequence is OUTed, i.e. the mode init parameters 
>> written to
>> the XGA registers:
>>
>>      inc dl                               ; EDX --> MemoryAccessMode 
>> (21x9)
>>      mov al,03h                       ;assume 16 BPP ** BUG: must be 04h
>>      cmp [ebp].Client_BL,11h     ;running 16 BPP? (Ed: 640x480x16)
>>      je @F                               ;yes, go set it
>>      ......
>>      mov al,03h                       ;must be 8 BPP ** Ed: 03h is 8 BPP
>> @@: out dx,al
>>
>>
>> XGA.VXD can be now tested on XGA or XGA-2, it replaces the original 
>> XGA.VXD
>> and should provide the same old services but without the new 
>> resolutions. I
>> did not test it yet. So, who wants to burn in or burn out their precious
>> XGA-2?
>>
>> www.members.aon.at/mcabase/pub/files/xga.vxd
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
0
Daniel
4/19/2006 6:43:08 PM
> > XGA.VXD done, now moving to the VGA parts and approaching the grand
> > finale.

XGA.DRV done too, 16-bpp enabled, cut the ribbon. Coding is finished,
testing must start now. I hope it works, but if not, we'll make it work.

www.members.aon.at/mcabase/pub/files/xga206.zip

I must really HALT now, more details and responses tomorrow.


> I'm amazed at how quickly you're going thru this.  Are you the last
> person on the planet that knows how to code in assembly?  We once had
> programs that ran faster because the whole thing was done this way,
> which of course became impractical because of portability.
>
> I think the original assembly coders spent a lot more time THINKING
> about how to best use the computer's resources -- something that has
> also long since gone out the window.
>
> Does anyone still code specific intensely used program loops in
> assembly?  That gave folks the benefit of mostly portable code and the
> benefit of speed where it was needed most.
>
> And now we have Visual Everything and JAVA -- moving a gazillion
> abstraction levels away from the hardware.
>
> It breaks my heart that we couldn't have got onto this project some
> years ago. Suffering while Win95 apps fought over a 256 color pallet is
> one of the things I think lead to the early demise of many fine
> machines.
> +-----------------------------------------+
> | Charles Lasitter   | Mailing/Shipping   |
> | 401/728-1987       | 14 Cooke St        |
> | cl+at+ncdm+dot+com | Pawtucket RI 02860 |
> +-----------------------------------------+


0
UZnal
4/20/2006 12:12:13 AM
Is there any chance to get a look at the source code? Or are you 
following the Micro$oviet model?

UZnal wrote:
>>> XGA.VXD done, now moving to the VGA parts and approaching the grand
>>> finale.
> 
> XGA.DRV done too, 16-bpp enabled, cut the ribbon. Coding is finished,
> testing must start now. I hope it works, but if not, we'll make it work.
> 
> www.members.aon.at/mcabase/pub/files/xga206.zip
> 
> I must really HALT now, more details and responses tomorrow.
> 
> 
>> I'm amazed at how quickly you're going thru this.  Are you the last
>> person on the planet that knows how to code in assembly?  We once had
>> programs that ran faster because the whole thing was done this way,
>> which of course became impractical because of portability.
>>
>> I think the original assembly coders spent a lot more time THINKING
>> about how to best use the computer's resources -- something that has
>> also long since gone out the window.
>>
>> Does anyone still code specific intensely used program loops in
>> assembly?  That gave folks the benefit of mostly portable code and the
>> benefit of speed where it was needed most.
>>
>> And now we have Visual Everything and JAVA -- moving a gazillion
>> abstraction levels away from the hardware.
>>
>> It breaks my heart that we couldn't have got onto this project some
>> years ago. Suffering while Win95 apps fought over a 256 color pallet is
>> one of the things I think lead to the early demise of many fine
>> machines.
>> +-----------------------------------------+
>> | Charles Lasitter   | Mailing/Shipping   |
>> | 401/728-1987       | 14 Cooke St        |
>> | cl+at+ncdm+dot+com | Pawtucket RI 02860 |
>> +-----------------------------------------+
> 
> 
0
Louis
4/20/2006 12:31:50 AM
On Thu, 20 Apr 2006 02:12:13 +0200, "UZnal" <unalz-at-mail333-dot-com>
wrote:

> XGA.DRV done too, 16-bpp enabled, cut the ribbon. Coding is finished, 
> testing must start now. I hope it works, but if not, we'll make it 
> work.

OK!  So where's the best place to unzip the files so that Win95 will
find them?  Does it just replace some existing files?  Is there any .INI
file that needs to be created?  Just a "have disk" and point to a
directory?

Thanks for tips on the install process. 
+-----------------------------------------+
| Charles Lasitter   | Mailing/Shipping   |
| 401/728-1987       | 14 Cooke St        |
| cl+at+ncdm+dot+com | Pawtucket RI 02860 |
+-----------------------------------------+
0
Charles
4/20/2006 11:58:51 AM
Louis Ohland:
> Is there any chance to get a look at the source code? Or are you
> following the Micro$oviet model?

Yes and Yes.


Charles Lasitter:
> OK!  So where's the best place to unzip the files so that Win95 will
> find them?  Does it just replace some existing files?  Is there any .INI
> file that needs to be created?  Just a "have disk" and point to a
> directory?

There is this quick hack:

(0) The default XGA/2 driver is installed

(1) Go to the registry, enter "regedit" in the DOS prompt

(2) Locate the node below, by stepping down through the registry tree:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Display\0000\MODE
S\16

(3) At node 16, right click and select New Key. Enter 800,600 exactly as it
is written here. You will have now two entries below 16, one is 640,480 and
the other is 800,600.

(4) In the right panel, click on the Default (or Standard) value, input form
comes, do nothing, just click OK. Key value must show now as ""

(5)  Close the registry window.

(6) Reboot to DOS

(7) Copy the unzipped files to C:\WINDOWS\SYSTEM

(8) Reboot to Windows. Go to Display and select 800x600 at 16-bpp.

(9) Have some demo images to convince yourself.


A clean install procedure will come, driver update will be done through the
System Manager. Also, the key above can be put in *.REG file so the key is
automatically inserted, I did not try it yet, I was too busy counting
colors.





0
UZnal
4/21/2006 1:23:16 AM
> > XGA.DRV done too, 16-bpp enabled, cut the ribbon.

Oooh, so many colors, so fast changing... I can't count them all.

IT WORKS !!! **

Kindly sponsored by Mr Charles Lasitter, sincere thanks. Charles Lasitter
deserves a big credit for the realization of the driver, I probably wouldn't
have done it in absence of interest. His genuine concern showed up at the
right moment.


** Tested on W95, XGA-2 adapter in Mod. 77.





0
UZnal
4/21/2006 1:32:39 AM
> The VXD became by 1300 bytes smaller than the original driver and contains
> at the same time more mode tables and more resolutions. Clean and lean !

The "original driver" I compared to was the VXD included in the DDK. The
size difference to the VXD included in the W95 distribution is much greater,
about  9000 bytes.

The size reduction is mainly due to the compacted mode tables. The lookup
structure contains entries for 18 VESA modes, but had an unused gap of 11
consecutive entries for XGA and XGA-2 and 9 entries for the AGX. Each entry
was 16 bytes long.

In the rewritten version, each entry became 32 bytes long and the lookups
for XGA and XGA-2 were separated. The gap was eliminated too but this
required additional lookup logic, offset adjusted for the compacted tables.
W95 did the following: given a mode number, it scanned the table and then
checked if the entry was zero, if yes, the mode was not supported. All this
despite the fact that another much smaller "array" contained only the
applicable modes and could be used for this kind of check.

I changed that to lookup the mode array first, and only if found, to go to
the mode data lookup. This structure contains now also pointers to the mode
set data for 3 more refresh rates, altogether 4 refresh rates are defined,
and bit flagged. Refresh rate switching is done easily, test the bit flags
and if supported, use the supplied pointer to the correct mode table.

This kind of handling is typical for object-oriented (OO) programming. By
contrast, procedural programming defines rather dumb data structures and
implements complex logic to manipulate it. In the OO model, you define a
complex data structure and implement simple logic to manipulate it. So to
say...

Whoever has written the W95 driver, is coming from the strictly procedural
world
But also those, who have created the driver code templates, are strongly
rooted there. I compared a number of drivers, they all use the same
structuring, i.e. driver template. You have been handed it in, just fill in
the blanks, the hardware specific parts, and do not a bit more.

Performance comes from design and less from coding.

P.S. My monitor, EIZO F56, suffers increasingly often from brightness
attacks, it pumps really. I fear, it will leave me before this thread ends.




0
UZnal
4/21/2006 1:33:59 PM
On Fri, 21 Apr 2006 03:23:16 +0200, "UZnal" <unalz-at-mail333-dot-com>
wrote:

> A clean install procedure will come, driver update will be done through the
> System Manager. Also, the key above can be put in *.REG file so the key is
> automatically inserted, I did not try it yet, I was too busy counting
> colors.

This is the one I'll be looking for ...
+-----------------------------------------+
| Charles Lasitter   | Mailing/Shipping   |
| 401/728-1987       | 14 Cooke St        |
| cl+at+ncdm+dot+com | Pawtucket RI 02860 |
+-----------------------------------------+
0
Charles
4/21/2006 1:35:32 PM
> > A clean install procedure
> This is the one I'll be looking for ...

W95 is amazingly strange. I reconstruct the steps, outlined earlier as
"quick hack" here, but each time with different results. The reason could be
that the first time I got it working, it was the very first, clean W95
install. Since then I reinstalled a number of times (the registry got messed
up trying different INF files), this did not help either.

The driver worked, it passed even M$'s Display Compatibility Tests at
800x600x8. It was too late in the night to run it for 16-bpp, and the next
day nothing worked any more. During the display tests you see how fast the
XGA-2 is, how good a low-res video runs or how fast bit blocks transfers
are. The card itself is fast enough, I was surpised, I did not expect to see
such a performance.

I created an INF file, installation proceeds through the Display properties,
"Change Adapter / Have Disk", installation itself succeeds. On reboot, I get
mostly blue screens. The default XGA driver is a part of the Setup Base, it
is a PNP (plug and play) device. Certain settings in the INF file are
perhaps not yet correct or but additional settings are needed. If I use the
default XGA PNP hardware ID, I get blue screens, if I use a make up vendor
ID, I get registry errors. Then the driver works, but since the registry has
errors (which errors?), display mode change fails.

I work with the W95 version from the MSDN CD, requires about 50 MB and
installs quickly. I have no idea how buggy or how reliable this version is,
it is from 1995. I cannot even restart it in DOS Mode, with the original XGA
driver installed.

Perhaps I should start again from a clean disk, delete and reformat. CD-ROM
with Spock on Mod. 77 under DOS did not go, I had to boot with the OS/2 Warp
disks, to obtain a drive letter for it.


Has anybody else tried to test the XGA206 or was it only me?




0
UZnal
4/22/2006 10:43:13 AM
On Sat, 22 Apr 2006 12:43:13 +0200, "UZnal" <unalz-at-mail333-dot-com>
wrote:

> Has anybody else tried to test the XGA206 or was it only me?

I hope to try this out in a few days, but I was wondering if the changes
"stuck" when you did it the manual way -- installed with standard XGA
driver and then did the registry changes.

I wonder how Win95B/C would behave.

Perhaps someone in the NG is an .INF semi-expert?

I have faith that in time we'll sort it out.
+-----------------------------------------+
| Charles Lasitter   | Mailing/Shipping   |
| 401/728-1987       | 14 Cooke St        |
| cl+at+ncdm+dot+com | Pawtucket RI 02860 |
+-----------------------------------------+
0
Charles
4/22/2006 1:06:59 PM
UZ,

UZnal wrote:

<SNIP XGA stuff>

> Perhaps I should start again from a clean disk, delete and reformat. CD-ROM
> with Spock on Mod. 77 under DOS did not go, I had to boot with the OS/2 Warp
> disks, to obtain a drive letter for it.

Try the boot diskette on the following page with your 77:

http://lacuna.ccad.uiowa.edu/content/software/mcacdrom/

See the comments in the CONFIG.SYS file about enabling Stubborn CDROM
support.

Good luck!

Brad

0
brad
4/22/2006 1:18:27 PM
> I hope to try this out in a few days, but I was wondering if the changes
> "stuck" when you did it the manual way -- installed with standard XGA
> driver and then did the registry changes.

Installation instructions and workarounds in the updated zip, same URL
new contents:

www.members.aon.at/mcabase/pub/files/xga206.zip

Read carefully the README. Though install is as clean as the standard
procedure now, the registry errors on my machine have not disappeared.
Perhaps it is a build/file resources/file version problem, no idea. Anyway,
you can at least enjoy that great colorful moment now.

* We have 75 Hz refresh at 800x600 with 16-bpp, fantastic.

* 50 Mhz pixel rate at 16-bpp corrupted the display. This special test
version of the driver is NOT included in the zip, so you won't be burning
your XGA-2.

* 16-bpp obviously doubles the XGA-2 pixel rate. My formula is

    Effective-Pixel-Rate = ( bits-per-pixel / 8 ) * Used-Pixel-Rate

where the Effective-Pixel-Rate should be less than or equal to 90 Mhz.

* Anyone out there with Windows 98 DDK ? I'd like to check the build
procedures.

> Perhaps someone in the NG is an .INF semi-expert?

Seems to be registry/file related and less INF. I got the INF, and anyone
can try the alternatives included in the INF. Make sure to uncomment, a
semicolon is a comment sign. If you play with it, make sure you have each
time only two entries uncommented, see the included INF file.

> I have faith that in time we'll sort it out.

Today I ran a part of the Display Compatibility Tests with 16-bpp on
800x600. Looks fine, background colors in some cases are reversed, M$ driver
bug.





0
UZnal
4/22/2006 10:02:11 PM
> Try the boot diskette on the following page with your 77:

Thanks, Brad. I suppose it works for Mod. 57 too.

What was that trick to make W98 install on a 486 machine?



0
UZnal
4/22/2006 10:03:50 PM

UZnal wrote:
> 
> Perhaps I should start again from a clean disk, delete and reformat. CD-ROM
> with Spock on Mod. 77 under DOS did not go, I had to boot with the OS/2 Warp
> disks, to obtain a drive letter for it.


Back up your registry using the ERU utility that is buried on the Win95
CD. It has saved my ass many times. Works with 98 too.

 
> Has anybody else tried to test the XGA206 or was it only me?


Maybe in the next few days. Got a 90 sitting here with Win95 that I can
beat up....

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
4/23/2006 5:39:01 AM

UZnal wrote:
> 
> 
> W95 is amazingly strange.


Amazing isn't the word for it....

 
> Has anybody else tried to test the XGA206 or was it only me?


This is interesting.

I was wrong, the 90 has OS/2 2.1 on it. But the Ultimedia Bermuda
underneath it has Win95B. All ready to roll, with the M$ XGA driver
installed. Backed up the registry with ERU and away we go....

The driver installation proceeded as described with no hitches. Restart
OK, no reg errors. On selecting 16bpp color, things immediatly got
strange. Title bar and icon text background colors are wonked. I have
permanent mouse trails. I changed the desktop background to the "setup"
bitmap (the only one that looked like it had more than 3 colors) and the
permanent mouse trails went away. But now I have windows that stay when
you close them, that is, the window display doesn't get erased when you
close the window. Start button no longer responding, things going from
bad to worse, time to force a reboot...

After a cold reboot, everything looks fine. No more wonked colors,
reluctant windows, etc. Still looking for hi-color pics on that machine,
and it refuses to talk on my LAN for some reason. I just love Windoze
networking. But it looks good now. OK after a warm reboot too. No signs
yet of strangeness or corruption.

The moral of the story, always restart after changing color depth.

For reference, this is a DX2-66 Ultimedia Bermuda, 16 MB RAM, heatsinked
XGA-2, ActionMedia II and ACPA installed but no drivers.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
4/23/2006 4:00:16 PM
> The driver installation proceeded as described with no hitches. Restart
> OK, no reg errors. On selecting 16bpp color, things immediatly got
strange.

The reg error I get indicates something is yet unfixed. I tried today
different INFs, all the same. I'll rebuild and check before strictly the
resource includes (these are the parts which contain specific driver IDs,
version information, driver name and copyrights).

Actually, the VXD in the DDK lacked a resource section, I created one, that
could be the problem. Perhaps there was a reason for this, M$ wants the
drivers to be registered with them.

Installed drivers and files are listed in the registry, in the case of VXDs,
there are internal checks based on the resource section. The reg error you
don't get could mean the VXD checks have been relaxed.

> After a cold reboot, everything looks fine. No more wonked colors,
> reluctant windows, etc. Still looking for hi-color pics on that machine,

You could start Paint and select to change/define the palette colors, then
check the color selector where you mix a color. There you can see the solid
colors.

> The moral of the story, always restart after changing color depth.

This W95 prompts to restart, but I should have included the tip in the
readme.

** Monitors: In case of doubt/unsupported, select a standard VESA DDC
monitor.



0
UZnal
4/23/2006 6:38:25 PM

UZnal wrote:
> 
> Installed drivers and files are listed in the registry, in the case of VXDs,
> there are internal checks based on the resource section. The reg error you
> don't get could mean the VXD checks have been relaxed.


This machine came with Dr Solomon antivirus on it, and their automatic
reg checker doesn't complain about anything either.


> You could start Paint and select to change/define the palette colors, then
> check the color selector where you mix a color. There you can see the solid
> colors.


3D Pipes look real nice. I've seen some very pretty shades show up.
Solid colors look good in Paint as well.

 
> ** Monitors: In case of doubt/unsupported, select a standard VESA DDC
> monitor.


This machine had Gateway Crystal Scan 1572 selected. I didn't even think
to look beforehand. Whatever, it works.

Looks great so far, Unal. Nice work! I'll let the Pipes screen saver
beat it up for a few hours (wow, a transition from Teal to faded
Lavender .. cool!). Kelly green, bright red, shadows and shades, very
nice.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
4/23/2006 9:04:24 PM
> > VXD checks

I located a copy-paste error in the resource description of the VXD and
updated it with the correct file type (VXD) and device type (VDD_DEVICE_ID).
I have overlooked that VXD and DRV have different internal filetypes and
subtypes.

That did not remove the reg error, probably I need a clean reinstall or a
better W9x. But that helped to come up with a simpler cure for 16-bpp
selection in case of troubles. Just boot to safe mode and select it from the
Display applet, no need to manually edit the registry.

Updated VXD and updated installation instructions in the updated zip, same
URL
new contents (Apr 23, 2006):

www.members.aon.at/mcabase/pub/files/xga206.zip

> This machine came with Dr Solomon antivirus on it, and their automatic
> reg checker doesn't complain about anything either.

I'd be very happy if it is this W95 version and this machine. Let us wait
for reports from other enthusiastic testers.

Switching to DOS fails, but so happens with the Windows XGA driver too, at
least here.

> Looks great so far

Somehow funny how much joy 64K colors can bring. I have 32-bit colors with
an 8MB Matrox in PC300GL and not that impressed at all. This is real MAD....

The very first time with 16-bpp, I grabbed a CD lying around, Lexmark Print
Gallery. Mona Lisa came in full colors, or so it seemed to me. But that is
true, the XGA-2 color quality is indeed fine, and I dare say, now even
better than in OS/2.

Why? This driver supplies 16-bpp at 800x600 with 75 Hz unchanged on every
monitor that can support the line frequency of 46.9 kHz. No DMQS dependency
where IBM claimed the highest refresh were 60 Hz at 16-bpp and enforced it
in the DMQS settings, just to stay VESA compliant with the VESA line freqs
(at 75 Hz and 8-bpp, this results in 50 Mhz pixel rate, XGA-2 can't do that
with 16-bpp). The 60Hz deliver inferior display quality.

We will have time to draw more conclusions, keep on counting the colors...





0
UZnal
4/24/2006 12:02:27 AM

UZnal wrote:
> 
> The very first time with 16-bpp, I grabbed a CD lying around, Lexmark Print
> Gallery. Mona Lisa came in full colors, or so it seemed to me. But that is
> true, the XGA-2 color quality is indeed fine, and I dare say, now even
> better than in OS/2.


I'll have to agree, it looks DAMN nice on a Sony 100GS Trinitron
monitor. I've never seen the pipes look better. Since I can't get this
damn Cabletron 3100 DNI to talk to my network anymore, I need to either
scare up another NIC or a CD with some nice pictures on it. Waitaminnit,
Scout camp 2005...

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
4/24/2006 1:20:39 AM

UZnal wrote:
> 
> But that is
> true, the XGA-2 color quality is indeed fine, and I dare say, now even
> better than in OS/2.


I'm looking at a pic of storm clouds in the Colorado sky over (Scout)
Camp Alexander. Shades of light to dark blue to grey to sunlit white,
all intermixed. Beautiful.

XGA-2 is a real sleeper. C'mon you guys, what are you waiting for? Load
Unal's driver! What are ya, CHICKEN????

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
4/24/2006 3:35:18 AM
UZnal wrote:
> > Try the boot diskette on the following page with your 77:
>
> Thanks, Brad. I suppose it works for Mod. 57 too.

Let me know if it doesn't.

> What was that trick to make W98 install on a 486 machine?

The no machine check switch at setup, /NM. See the following textfile:

http://lacuna.ccad.uiowa.edu/content/software/win/w98-setup.txt

Other business - I think you can automagically write an .INF file for
XGA using HZTool. I found it useful when I was working with the 6091-19
back before I got a Cornerstone card. You know what is in the driver so
you should be able to make some standard settings.

IIRC HZTool works by modifying the .INF file.  You will also need
"quickres" from M$ when working with Win 95.

See the text file in the directory below for more info:

http://lacuna.ccad.uiowa.edu/downloads/software/HZTool/


Brad

0
brad
4/24/2006 4:22:15 PM
On Sun, 23 Apr 2006 22:35:18 -0500, Jim Shorney <jshorney@inebraska.com>
wrote:

> XGA-2 is a real sleeper. 

I'm really excited about the development.

UZnal has refused compensation for his efforts, and so I have made an
initial contribution to Doctors Without Borders in his honor.

Salute, UZnal!
+-----------------------------------------+
| Charles Lasitter   | Mailing/Shipping   |
| 401/728-1987       | 14 Cooke St        |
| cl+at+ncdm+dot+com | Pawtucket RI 02860 |
+-----------------------------------------+
0
Charles
4/24/2006 8:07:03 PM
>  Load Unal's driver!

Thanks for the compliment, but read this as
modified/adapted/rewritten/updated, without the DDK code it would have not
been possible at all. In the end, the VXD got however rewritten in the
hardware interface parts.

Jim, you deserve a big, big credit for your tests. They assured me that the
problem is in Windows and not the driver, and indeed I FIXED the registry
errors. Thank you !

If you happen to use the special Win95 version from the MSDN Subscription
1995-96, make sure to set/change the Virtual Memory settings from auto to
manual. I suspect that this Win95 version does not swap at all, so the
registry error was due to insufficient memory (Mod. 77, 32 MB RAM). I booted
to safe mode, gave it some 100 MB disk space to swap, the error disappeared
immediately, but I still suspect it swaps only in special cases, not to let
this version be usable at all.

That means, users and testers can be assured now that the driver installs
correctly and works hopefully correctly on a correctly configured Windows
95. I hope someone comes up with Windows 98 results in the next days.

I updated the installation instructions, same URL, new contents (Apr 24,
2006):

www.members.aon.at/mcabase/pub/files/xga206.zip

I'll be running the Display Compatibility Tests (DCT) from the DDK in the
next days, it takes too much time.





0
UZnal
4/24/2006 9:14:04 PM
> > > Try the boot diskette on the following page with your 77:

With ASPI4B.SYS and IBMCDROM.SYS this 2x Toshiba XM-3401TA did not get
recognized. I did not have yet time to combine more. I was somehow thinking
ASPI4B.SYS were for the Future Domains.

> Other business - I think you can automagically write an .INF file for
> XGA using HZTool.

The INF basics are discussed in the MSDN Library, I did not have troubles
with it at all. The [XGA.PosDup] and [XGA2.PosDup] sections in XGA206.INF
announce the compatibility on driver level to the XGA/XGA-2 hardware device.




0
UZnal
4/24/2006 9:21:01 PM
> UZnal has refused compensation for his efforts, and so I have made an
> initial contribution to Doctors Without Borders in his honor.

This is a contribution I gladly approve, thank you very much indeed.




0
UZnal
4/24/2006 10:20:37 PM
Hi �nal !

> Updated VXD and updated installation instructions in the updated zip, same
> URL
> new contents (Apr 23, 2006):
> 
> www.members.aon.at/mcabase/pub/files/xga206.zip

Want to share some experiences als well.

I'd tried out my trusty old 9556-0BA with the onboard-XGA2 ... and found 
out, that the otherwise reliable 2GB Quantum Fireball got bad. Hrrrm. 
Swapped it for a DORS,installed Ref-Partition,  GHOSTed all the stuff 
over (Win95C with TR-Network and ACPA sounddriver) and connected it to 
the 19" ColorTac LCD. Install went fine so far.
Since a reboot is always recommended after driver install I'd restarted 
the system. No serious initial problems on re-entering W95, but the 
display disliked the refresh and screen control signals. The picture was 
offset about 2.5 cm towards the left and 1cm towards the top. Changing 
refresh "on the fly" ended with a very nasty exception error and a blue 
screen.
Restarted the system, 800 x 600 Hi-Color mode and changed the display to 
"IBM 6314", which is a sort-of multimode screen, which does 60Hz on most 
modes. Voil�: here we are. Stable picture in Hi-Color in between the 
screen borders.

I guess you can put that onboard-XGA2 part aside as "solved".

(I tried to run the very same driver on the 9533 PS/2e before ... 
ISA-XGA2. Well ... of course it crashed and did not work. I think the 
problem is false ressources. The ISA adapter uses different Base-I/O 
adresses and I guess these are not that easy to query.)

-- 
Very friendly greetings from Peter in Germany
http://members.aol.com/mcapage0/mcaindex.htm

*** Reply to: peterwendt@aol.com only ! ***
0
Peter
4/25/2006 2:33:15 PM
Hi Peter,

Thank you for the test report, it gave me good clues. I extended the README
with the list of monitor specs, and the original test reports as posted
here. Also, mode change to 1024x768 with 256 colors has been fixed.

Today's updates as always at (Apr 25, 2006)

www.members.aon.at/mcabase/pub/files/xga206.zip

> Changing
> refresh "on the fly" ended with a very nasty exception error and a blue
> screen.

Lucky you, I can't change any refresh rates on this test Win95, so I could
not test it all. The parts of the code dealing with the registry are from
the Win3.x
times, they must be reworked and I have left that for later. AFAIK, LCD
should work well at 60 Hz, which is supported, i.e. built-in.

> I guess you can put that onboard-XGA2 part aside as "solved".

Glad to hear that. Saves me from setting up a Mod. 57, though it seems to me
to be the faster machine than Mod. 77.

> (I tried to run the very same driver on the 9533 PS/2e before ...
> ISA-XGA2. Well ... of course it crashed and did not work. I think the
> problem is false ressources. The ISA adapter uses different Base-I/O
> adresses and I guess these are not that easy to query.)

Yes, I haven't forgotten the ISA Radius XGA-2, it will be a future
extension. On an EISA system with Phoenix BIOS, POS query should work, the
card responds to it, and it uses the same instance schema as the XGA-2, same
I/O ranges. It will be certainly interesting to explore this more, I am
really curious. I have the card and could not bring years ago the same Win95
version to recognize it. Time for revanche ...;)




0
UZnal
4/25/2006 7:15:20 PM
Hi �nal !

> Hi Peter,
> 
> Thank you for the test report, it gave me good clues. I extended the README
> with the list of monitor specs, and the original test reports as posted
> here. Also, mode change to 1024x768 with 256 colors has been fixed.
> 
> Today's updates as always at (Apr 25, 2006)
> 
> www.members.aon.at/mcabase/pub/files/xga206.zip
> 

Downloaded.
Had to remove the 9556 for a while, since I needed "the shoebox" 
computer usually occupying that place and screen for some other purpose.
But I will check out the revised version with the 56 again later.

> 
>>Changing
>>refresh "on the fly" ended with a very nasty exception error and a blue
>>screen.
> 
> 
> Lucky you, I can't change any refresh rates on this test Win95, so I could
> not test it all. The parts of the code dealing with the registry are from
> the Win3.x
> times, they must be reworked and I have left that for later. AFAIK, LCD
> should work well at 60 Hz, which is supported, i.e. built-in.

The LCDs favour for 60Hz was my initial idea to try it with a setting 
for a monitor included in the database and known for the same behaviour 
as well. That lead me to the 6314. However I could use 60, 72 and 75 Hz 
as well. In the worst case the ColorTac responds with "unsupported mode" 
and a black display ....


> 
> 
>>I guess you can put that onboard-XGA2 part aside as "solved".
> 
> 
> Glad to hear that. Saves me from setting up a Mod. 57, though it seems to me
> to be the faster machine than Mod. 77.

The -0BA is a 50MHz 486SLC with no FPU but with full 16MB RAM - and a 
pretty snappy DORS 2.16GB U-SCSI drive installed. Plua an antique caddy 
loaded Plextor CD-ROM (4x in best case) ... plus Token Ring card and the 
M-ACPA. Wooof. "Where are my sunglasses ?"

>>(I tried to run the very same driver on the 9533 PS/2e before ...
>>ISA-XGA2. Well ... of course it crashed and did not work. I think the
>>problem is false ressources. The ISA adapter uses different Base-I/O
>>adresses and I guess these are not that easy to query.)
> 
> 
> Yes, I haven't forgotten the ISA Radius XGA-2, it will be a future
> extension. On an EISA system with Phoenix BIOS, POS query should work, the
> card responds to it, and it uses the same instance schema as the XGA-2, same
> I/O ranges. It will be certainly interesting to explore this more, I am
> really curious. I have the card and could not bring years ago the same Win95
> version to recognize it. Time for revanche ...;)

Maybe it was a fairly stupid idea to try it out on the PS/2e.
But at least I can now say "I *did* try it". On the other hand: M$ 
drivers coming with W95 *do run* perfectly well with the 9533 onboard 
ISA-XGA2.
So why shouldn't it work ?
Different adresses ? Bus & ressource detection ? How comes that the 
original driverset can handle the PS/2e while the bus architecture 
differs ? And it does 1024 x 768 / 256 colors - that's confirmed.


-- 
Very friendly greetings from Peter in Germany
http://members.aol.com/mcapage0/mcaindex.htm

*** Reply to: peterwendt@aol.com only ! ***
0
Peter
4/25/2006 8:07:34 PM

UZnal wrote:
> 
> Jim, you deserve a big, big credit for your tests. They assured me that the
> problem is in Windows and not the driver, and indeed I FIXED the registry
> errors. Thank you !

Glad to do it. The machine was just sitting here, taking up space
awaiting a purpose. I expect someday I will hack away at the ACPA. It
should get OS/2 if I ever have hope of using the AM-2 though. I mainly
stuck that in there for bragging rights. Anyway, it was fun.

I didn't mention that I had the same effect Peter found, of the image
being somwhat up and to the left at first. Didn't think anything of it,
this is not uncommon when changing video drivers or hardware. I just
adjusted the monitor.

 
Now, if only you could solve my Linux video bug...  

-Jim

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
4/26/2006 3:48:35 AM
Hi Peter,

> drivers coming with W95 *do run* perfectly well with the 9533 onboard
> ISA-XGA2.

I see, I've projected that onto the Radius ISA XGA-2.

> So why shouldn't it work ?
> Different adresses ? Bus & ressource detection ? How comes that the
> original driverset can handle the PS/2e while the bus architecture
> differs ? And it does 1024 x 768 / 256 colors - that's confirmed.

I left the XGA/XGA-2 detection unchanged. Detection and resource settings
are derived through POS bytes, nothing spectacular. The only dependency are
the hard coded XGA and XGA-2 adapter IDs, 8FDB resp. 8FDA. But I have
removed the AGX detection code, where the ID is set to 8FD9. It would be
reassuring if you can run QUMC on the PS/2E and post the POS bytes dump.

There is also the option of claiming the VGA resources through the INF file
with the section [VGA.LogConfig] but this is rather for devices and less for
drivers. The probability is low that it will solve the problem, in any case
the modified INF is here:

www.members.aon.at/mcabase/pub/files/xgaps2e.zip



0
UZnal
4/26/2006 11:09:55 AM
> I didn't mention that I had the same effect Peter found, of the image
> being somwhat up and to the left at first. Didn't think anything of it,
> this is not uncommon when changing video drivers or hardware. I just
> adjusted the monitor.

The used line frequency for 16-bpp 800x600 is not a VESA standard. We had to
stay below the 50 Mhz pixel rate which results at using the VESA standard
rates. I'll have to indicate that in the monitor/resolution table of README.

I had the same effect but had to only push the AUTO button of the monitor
and it correctly adjusted the image and stored the setting.

Since we cannot yet select a refresh rate, we cannot see the effects on
selecting a 72 Hz refresh. I can change the driver to use 72 Hz per default,
a VESA standard, and we can check again the resulting image.

The 75 Hz were actually a 16-bpp 800x600 stress test and the XGA-2 passed
it. Now we can go on using the standard 72 Hz.





0
UZnal
4/26/2006 11:40:18 AM
Hi !

BTW & FWIW: It was a common good and welknown practise to return to 
Standard-VGA modus (640 x 480 / 16 colors) and reboot before installing 
new and advanced video-drivers.
Particularly with so-called "intelligent cards" like the XGA / XGA2 / 
Cirrus Logic and the S3-family for instance.
You'd often fell flat on the face when starting from "somewhere else" 
than plain VGA. Mostly because some VXDs or DLLs are still in use and 
hadn't been updated.

-- 
Very friendly greetings from Peter in Germany
http://members.aol.com/mcapage0/mcaindex.htm

*** Reply to: peterwendt@aol.com only ! ***
0
Peter
4/26/2006 11:56:25 AM
Hi �nal !

> Hi Peter,
> 
> 
>>drivers coming with W95 *do run* perfectly well with the 9533 onboard
>>ISA-XGA2.
> 
> 
> I see, I've projected that onto the Radius ISA XGA-2.
> 
> 
>>So why shouldn't it work ?
>>Different adresses ? Bus & ressource detection ? How comes that the
>>original driverset can handle the PS/2e while the bus architecture
>>differs ? And it does 1024 x 768 / 256 colors - that's confirmed.
> 
> 
> I left the XGA/XGA-2 detection unchanged. Detection and resource settings
> are derived through POS bytes, nothing spectacular. The only dependency are
> the hard coded XGA and XGA-2 adapter IDs, 8FDB resp. 8FDA. But I have
> removed the AGX detection code, where the ID is set to 8FD9. It would be
> reassuring if you can run QUMC on the PS/2E and post the POS bytes dump.

:-)
I put *that* aside to make room for the 9556 ... but I can bring it back 
on stage later today. Will give it a try for QUMC.


> There is also the option of claiming the VGA resources through the INF file
> with the section [VGA.LogConfig] but this is rather for devices and less for
> drivers. The probability is low that it will solve the problem, in any case
> the modified INF is here:
> 
> www.members.aon.at/mcabase/pub/files/xgaps2e.zip

I'll check that out too.


-- 
Very friendly greetings from Peter in Germany
http://members.aol.com/mcapage0/mcaindex.htm

*** Reply to: peterwendt@aol.com only ! ***
0
Peter
4/26/2006 11:59:38 AM
Hi !

By what reason the PS/2e always dumps into a registry error in Hi-Color 
mode. It runs with no problems in 256 colors and either resolution as 
far as I can tell.

I used the "PS/2e"-INF and the drivers from 25.04. (latest).

Something about the machine:
- it has an 850MB / 2.5" drive Toshiba running under EZDrive
- it has no FPU (shouldn't be a problem: the 56 hasn't got one either)
- it has the quad PCMCIA adapter card and a Token Ring Credit Card II 
adapter for networking
- it has 16MB RAM / 15.232KB Useable (with XGA2 Copro copied to RAM - 
15.872KB with using the ROM function only, which is a tad slower)

QUMCDOS comes up with

Planar Video (b_5): IBM XGA-2 Display Adapter/A
AdapterID   8FDA		
-------------------------------------
106-7h  POS Subadress extension: 0000
102h    pos[0] = 7D : 0 1 1 1 1 1 0 1
103h    pos[1] = ED : 1 1 1 0 1 1 0 1
104h    pos[2] = 02 : 0 0 0 0 0 0 1 0
105h    pos[3] = 0F : 0 0 0 0 1 1 1 1

......   Video I/O Address
            Instance 6: 2160h - 216Fh

......   1 MB VRAM Aperture Base Address
            Address at 15 MB (F00000h)

......   Video Arbitration Level
            Arbitration level 13

......   Video Fairness
            Fairness On

All else is - of course - not detected, since it isn't a MCA-machine.
No planar ID given. The Video I/O Adress, Arbitration Level and Fairness 
is identical to the 9556.

The only major difference between the PS/2e and the 9556 XGA-wise is the 
1 MB VRAM Aperture. It is set to "Disable" on both machines in the Setup 
- but it shows up as "15 MB" with QUMC on the PS/2e.

And -maybe- there is a difference in the XGA-2 Coprocessor base 
adresses. On the PS/2e it is listed in the Setup as "C7F0-C7FF" and I 
wonder where it might be on the 9556 ? It is not listed in Setup.
(On my 9595-AMT with XGA-2 it is set to 0xC1F00 ... queried with XGAPOS2 
under Linux.)

Using the "ROM" option for the XGA2 Coprocessor ends in *very* odd 
crashes with a black background, icons visible, but you cannot read 
anything, since the display shows black color on black ground in either 
window. Some icons show up, but no buttons ... Argh.
I must have rebooted the poor PS/2e fifty times or more.

All of that strongly reminds me to the time, when I tried to get XF86 to 
run on the PS/2e ... ;-)


-- 
Very friendly greetings from Peter in Germany
http://members.aol.com/mcapage0/mcaindex.htm

*** Reply to: peterwendt@aol.com only ! ***
0
Peter
4/26/2006 3:38:28 PM
Hi!

> XGA-2 is a real sleeper.

I thought that was pretty well known, at least under M$ control...

However, even IBM's drivers for Win 3.1x/OS/2 Warp 4 don't let you use
72/75Hz refresh on 800x600 at 64K colors.

I tried forcing the issue once by twiddling the INI entries under
Windows for Workgroups on a Model 90. I got a garbage screen as a
result. Never investigated it much beyond that--I posted here and was
told that I'd exceeded what the card would do at high color.

> C'mon you guys, what are you waiting for?
> Load Unal's driver! What are ya,
> CHICKEN????

No, but I'd stepped back from this thread. (And wouldn't you know it,
but it got interesting really fast!)

Tonight, in the middle of the (so-far empty, but the farmers are coming
out to work their fields) quiet cornfields of Central Illinois, there
will be two XGA-2 cards coming up in brilliant high color at 800x600
under Win95. I don't care what else might need to be done--short of
anything falling down, it can happen later.

"Defiant" is going to be the first...I love using the Model 85 and this
will be a real treat.

Watch out, GUP. Your performance is lacking and your days may be
numbered.

Thank you, Unal Z!

William

0
wm_walsh
4/26/2006 5:47:28 PM
Hi!

> W9x drivers MIGHT be useable
> under NT4, I hope. Miniport, anyone?

A miniport driver might work, but there are some differences in Windows
NT that might have to be accounted for.

First and foremost, there is no VXD support in NT.
Also, NT drivers do support being started and stopped without a reboot.
This feature seems to exist in Win95 (PCMCIA cards and similar devices
can be removed/reinserted without rebooting) but is not as fully
implemented.

I am no driver expert...

William

0
wm_walsh
4/26/2006 5:58:04 PM
In article <444f9588$0$13355$9b622d9e@news.freenet.de>,
"Peter H. Wendt" <peterwendt@aol.com> wrote:
|- it has 16MB RAM / 15.232KB Useable (with XGA2 Copro copied to RAM -
|15.872KB with using the ROM function only, which is a tad slower)

Some apps/drivers require the 1 MB aperture, if so you will need to replace
one of the SIMMS with a smaller one (4 MB planar, 1x 8 MB, 1x 2 MB to give
14 MB) so that the 1 MB aperture can be enabled.
I experimented with this with OS/2 on my "e" compared with my 9556. I
discovered that OS/2's Multimedia AVI player worked on the 9556 with the
base 64K window, but on the "e" it needed the 1 MB window.

-- 
Don Hills    (dmhills at attglobaldotnet)     Wellington, New Zealand
"New interface closely resembles Presentation Manager,
 preparing you for the wonders of OS/2!"
    -- Advertisement on the box for Microsoft Windows 2.11 for 286
0
black
4/26/2006 11:23:59 PM
> Tonight, in the middle of the (so-far empty, but the farmers are coming
> out to work their fields) quiet cornfields of Central Illinois, there
> will be two XGA-2 cards coming up in brilliant high color at 800x600
> ....
> Thank you, Unal Z!

Test reports first, cakes later....;)





0
UZnal
4/27/2006 12:22:43 AM
Hi Peter,

> By what reason the PS/2e always dumps into a registry error in Hi-Color
> mode. It runs with no problems in 256 colors and either resolution as
> far as I can tell.
>
> I used the "PS/2e"-INF and the drivers from 25.04. (latest).

If I get it right, the INF changed the situation? The driver works now but
PS/2e fails at 16-bpp? If so, that could mean system problems with setting
the mode.


> Planar Video (b_5): IBM XGA-2 Display Adapter/A
> AdapterID   8FDA
> -------------------------------------
> 106-7h  POS Subadress extension: 0000
> 102h    pos[0] = 7D : 0 1 1 1 1 1 0 1
> 103h    pos[1] = ED : 1 1 1 0 1 1 0 1
> 104h    pos[2] = 02 : 0 0 0 0 0 0 1 0
> 105h    pos[3] = 0F : 0 0 0 0 1 1 1 1
>
> .....   Video I/O Address
>             Instance 6: 2160h - 216Fh
>
> .....   1 MB VRAM Aperture Base Address
>             Address at 15 MB (F00000h)
>
> .....   Video Arbitration Level
>             Arbitration level 13
>
> .....   Video Fairness
>             Fairness On

You have above different fixed resources:

AdapterId 08FDAh
AdapterName "XGA-2 Display Adapter/A"

FixedResources
        pos[1]=0XXXXXX0b     -- differs in bit 0 (is 1)
        pos[3]=110XXXXXb     -- differs in bits 5-7 (is 110)


For comparison, below is QUMC output from the planar XGA-2 of Mod. 57

Planar Video (b_5): IBM XGA-2 Display Adapter/A
AdapterID   8FDA
-------------------------------------
106-7h  POS Subadress extension: 0000
102h    pos[0] = FD : 1 1 1 1 1 1 0 1  pos[ 8] -- Video I/O Address, Video
ROM
103h    pos[1] = 6C : 0 1 1 0 1 1 0 0  pos[ 9] -- Arbitration
104h    pos[2] = 02 : 0 0 0 0 0 0 1 0  pos[10]
105h    pos[3] = C0 : 1 1 0 0 0 0 0 0  pos[11] -- Aperture

......   Video I/O Address
           Instance 6: 2160h - 216Fh

......   1 MB VRAM Aperture Base Address
           Disabled

.......... (same as above)

> The only major difference between the PS/2e and the 9556 XGA-wise is the
> 1 MB VRAM Aperture. It is set to "Disable" on both machines in the Setup
> - but it shows up as "15 MB" with QUMC on the PS/2e.

The aperture on PS/2e, judging by the 8FDA.ADF, is indeed ENABLED, because

choice "Disabled"
        pos[3]=XXXX0000b

But on your PS/2e you have

pos[3] = 0F : 0 0 0 0 1 1 1 1

which is

choice "Address at 15 MB (F00000h)"
        pos[3]=XXXX1111b mem 0F00000h-0Ffffffh

> And -maybe- there is a difference in the XGA-2 Coprocessor base
> adresses.

pos[0] and pos[1] are used to calculate the address of the memory mapped
registers  We get different results for PS/2e and Mod. 57 (different POS
values), but that shouldn't be a problem.

The coprocessor is accessed in 256 colors modes also. If it works there, it
must work everywhere.

Aperture isn't a problem either, if 1M enabled and unused, will only waist
memory.

16-bpp is just 2-3 different register values. However, there are this time
twice more bytes.

Lower the pixel rate? I set the default refresh lower, to 60 Hz, it gives 40
Mhz pixel rate and built a new driver set for PS/2E, it is here (April 26.
2006, PS/2E):

www.members.aon.at/mcabase/pub/files/xgaps2e.zip




0
UZnal
4/27/2006 12:44:16 AM

wm_walsh@hotmail.com wrote:
> 
> "Defiant" is going to be the first...I love using the Model 85 and this
> will be a real treat.


FWIW, "Serenity" has been running since Sunday morning with UZ's driver,
without incident. Sometime I'll update to his latest rev, but so far I'm
just doint a burn-in.

 
> Watch out, GUP. Your performance is lacking and your days may be
> numbered.


Hey, unless UZ can work another miracle for NT, I wouldn't mind having a
non-buggy GUP..

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
4/27/2006 1:51:30 AM
Hi!

> Test reports first, cakes later....;)

Okay. But it's not all good news. :-)

I chickened out a bit and decided to use a "sacrificial" 9595-0LG for the
test. It's just about completely original, save for 32MB RAM and a 3GB hard
disk. Even the L complex is still in place. This machine is running Win95
OSR 2.5.

I started by changing everything back to standard VGA, 640x480. For a
monitor, I picked the IBM G50...it was closest to what I had attached.

Loaded the driver per the instructions provided in the readme...that part
worked great. Rebooted. Windows comes up with the blue "setup"
wallpaper--only it is pink! Once I got past the logon dialog, this corrected
itself and the wallpaper turned the proper color.

No big deal...go into display properties, settings tab...and uh-oh! The
registry is corrupt, or so says Windows.

Okay, follow the instructions for setting the swapfile...I too picked 100MB
as the top limit, and 0 as the bottom. No improvement upon rebooting.
Windows still says the registry is corrupt. Trying to jump directly to
800x600x64K colors results in a "you need to restart your computer" message.
Letting the computer restart brings things up in 640x480x256 colors.

Perhaps a smaller leap might do the trick. Going to 800x600x256 colors
works, no prompt for rebooting. Taking that a little further and going to
64K...monitor goes dark, LED turns yellow and the computer has completely
locked up. Even CTRL-ALT-DEL won't get things started over again.

Well...maybe my monitor selection is overly ambitious. Reboot, go back into
display properties...change out the IBM G50 for a "Super VGA 1024x768"
generic monitor. Long story short, the first jump back to 800x600x256 colors
works. So...change to 800x600x64K...and it makes the switch! The mouse
pointer is leaving semi-permanent trails, and some things are the wrong
color, but going into Windows Paint confirms that I have high-color!

At this point, things might be fine if I could reboot and the registry
wouldn't bail out...as it stands now, each reboot takes me back to
640x480x256.

William


0
William
4/27/2006 3:27:11 AM
William R. Walsh wrote:
> No big deal...go into display properties, settings tab...and uh-oh! The
> registry is corrupt, or so says Windows.

I'm stating the obvious, so please forgive me, but it seems like the 
registry here isn't corrupt, but rather the driver seems to be doing 
some very naughty memory access, and fiddling around with things that's 
making Windows think the registry is corrupt.

--Daniel
0
Daniel
4/27/2006 4:45:00 AM
> worked great. Rebooted. Windows comes up with the blue "setup"
> wallpaper--only it is pink! Once I got past the logon dialog, this
corrected
> itself and the wallpaper turned the proper color.

This is a known problem but so far harmless.

> No big deal...go into display properties, settings tab...and uh-oh! The
> registry is corrupt, or so says Windows.

You did not get before the error message? Only when you clicked the tab in
the Display applet? If so, this is something different, it has to do with
the system.

Check the section [Display] in SYSTEM.INI, it should be empty. If you
installed earlier another card, it might have settings there.

SYSTEM.INI was the registry of Win3.x, calls to it are redirected to the
Win9x registry.


> Okay, follow the instructions for setting the swapfile...I too picked
100MB
> as the top limit, and 0 as the bottom. No improvement upon rebooting.

This is, as the README says, rather for this particular MSDN version of
Windows. In this case, the registry error was coming right after the logon
screen. The registry was locked for any changes.

> Windows still says the registry is corrupt.

Once it starts saying so, you get only troubles. Your essential problem is
the registry error, until it is fixed you won't be able to test correctly.


> Well...maybe my monitor selection is overly ambitious. Reboot, go back
into
> display properties...change out the IBM G50 for a "Super VGA 1024x768"
> generic monitor. Long story short, the first jump back to 800x600x256
colors
> works. So...change to 800x600x64K...and it makes the switch!

What happened to the registry error? Did you have to reboot after each
resolution change? I need to know exactly what steps you performed.


> The mouse
> pointer is leaving semi-permanent trails, and some things are the wrong
> color, but going into Windows Paint confirms that I have high-color!

What happens when you disable the mouse trails?

> At this point, things might be fine if I could reboot and the registry
> wouldn't bail out...as it stands now, each reboot takes me back to
> 640x480x256.

Reinstall the Windows XGA driver, and see if the error persists. If not,
select "VESA DDC" monitor and reinstall XGA206.

Did you see any tabs/options in Display dealing with refresh rates?





0
UZnal
4/27/2006 7:47:36 PM
WDM Audio DDK for Windows 98

There are known issues with WDM audio 1.0, a component of the initial 
release of Microsoft� Windows� 98 that was contained in previous 
versions of the Microsoft Windows 98 DDK. These issues are described 
below. The Microsoft Windows� 2000 DDK contains an updated version of 
the WDM audio development environment, version 1.1. Since a more recent 
version now exists, the Windows 98 DDK no longer contains support for 
WDM audio. Use the Windows 2000 DDK to create audio drivers for Windows 
98 Second Edition, and Windows 2000.


UZnal wrote:
>> worked great. Rebooted. Windows comes up with the blue "setup"
>> wallpaper--only it is pink! Once I got past the logon dialog, this
> corrected
>> itself and the wallpaper turned the proper color.
> 
> This is a known problem but so far harmless.
> 
>> No big deal...go into display properties, settings tab...and uh-oh! The
>> registry is corrupt, or so says Windows.
> 
> You did not get before the error message? Only when you clicked the tab in
> the Display applet? If so, this is something different, it has to do with
> the system.
> 
> Check the section [Display] in SYSTEM.INI, it should be empty. If you
> installed earlier another card, it might have settings there.
> 
> SYSTEM.INI was the registry of Win3.x, calls to it are redirected to the
> Win9x registry.
> 
> 
>> Okay, follow the instructions for setting the swapfile...I too picked
> 100MB
>> as the top limit, and 0 as the bottom. No improvement upon rebooting.
> 
> This is, as the README says, rather for this particular MSDN version of
> Windows. In this case, the registry error was coming right after the logon
> screen. The registry was locked for any changes.
> 
>> Windows still says the registry is corrupt.
> 
> Once it starts saying so, you get only troubles. Your essential problem is
> the registry error, until it is fixed you won't be able to test correctly.
> 
> 
>> Well...maybe my monitor selection is overly ambitious. Reboot, go back
> into
>> display properties...change out the IBM G50 for a "Super VGA 1024x768"
>> generic monitor. Long story short, the first jump back to 800x600x256
> colors
>> works. So...change to 800x600x64K...and it makes the switch!
> 
> What happened to the registry error? Did you have to reboot after each
> resolution change? I need to know exactly what steps you performed.
> 
> 
>> The mouse
>> pointer is leaving semi-permanent trails, and some things are the wrong
>> color, but going into Windows Paint confirms that I have high-color!
> 
> What happens when you disable the mouse trails?
> 
>> At this point, things might be fine if I could reboot and the registry
>> wouldn't bail out...as it stands now, each reboot takes me back to
>> 640x480x256.
> 
> Reinstall the Windows XGA driver, and see if the error persists. If not,
> select "VESA DDC" monitor and reinstall XGA206.
> 
> Did you see any tabs/options in Display dealing with refresh rates?
> 
> 
> 
> 
> 
0
Louis
4/27/2006 8:16:32 PM
Hi!

> Only when you
> clicked the tab in the Display applet?

That's when I first saw it, yes.

> If so, this is something
> different, it has to do with the system.

I have my doubts. This system had been in use at my place of work for
some time. It was used to periodically retrieve an audit trail from an
electronic safe lock.  During all that time, I never saw any registry
error.

> Check the section [Display] in SYSTEM.INI, it should be empty.
> If you installed earlier another card, it might have settings there.

I'll check, but I have had no other video card in this system.

> What happened to the registry error? Did you have to reboot after
> each resolution change? I need to know exactly what steps you
> performed.

Rebooting was, as noted, impossible without being thrown back to
640x480x256. Therefore, I had no choice but to make the changes without
rebooting.

The registry error stayed around at all times. I ignored it, and left
it sitting in the background. "Hot" changes of the resolution more or
less worked, despite some display corruption.

> What happens when you disable the mouse trails?

They are not enabled and never were.

> Reinstall the Windows XGA driver, and see if the error persists.
> If not, select "VESA DDC" monitor and reinstall XGA206.

I'll give that a try to see what happens. I'm not sure that a VESA DDC
monitor is a choice on my particular system...

> Did you see any tabs/options in Display dealing with refresh
> rates? 

No, I never happened to see any such tabs.

William

0
wm_walsh
4/27/2006 10:12:09 PM
Hi!

Okay, I reverted completely back to the Microsoft-supplied IBM XGA-2
driver...upon rebooting, there were no registry errors of any sort
displayed. All supported display modes work. I can enter and leave the
display control panel without incident. I used the system quite
heavily, visiting web pages, running Paint and typing up a quick
document in a word processor. As far as I can tell, it works just fine
when the stock XGA-2 driver is loaded.

I can't prove it beyond all trace of doubt, but I feel very strongly
that the new driver still has a bug.

William

0
wm_walsh
4/27/2006 11:05:48 PM
> > If so, this is something
> > different, it has to do with the system.
>
> I have my doubts. This system had been in use at my place of work for
> some time. It was used to periodically retrieve an audit trail from an
> electronic safe lock.  During all that time, I never saw any registry
> error.

Windows manipulates the registry, not the driver. When a registry error
happens, it comes from the system, read Windows, side, for whatever reasons.
In such  a case, if you continue on testing, you will most probably report
biased results, because you cannot know what registry/display information
Windows passes to the driver.

Basicly, Windows ask a driver if it can support a particular resolution and
refresh rate. Windows calculates the refresh rate based on the properties of
the defined monitor (see MONITORx.INF). The driver sets the resolution and
refresh rate if it can do it, keeps unchanged if not.

We test currently if High Color mode can be enabled on all Windows
variations.
For this test VESA DDC is a good choice, and this is not about supporting
your favorite monitor. Check the monitor table in the README and find out
what modes your monitor can support. Then define the monitor as VESA DDC and
use only the appropriate modes.

The XGA206.INF file tells Windows to look for a DDC monitor each time it
boots.


> I can't prove it beyond all trace of doubt, but I feel very strongly
> that the new driver still has a bug.

There is the Display Compatibility Test (DCT) suite for this kind of
feelings.


> Okay, I reverted completely back to the Microsoft-supplied IBM XGA-2
> driver...upon rebooting, there were no registry errors of any sort
> displayed. All supported display modes work. I can enter and leave the
> display control panel without incident.

Fine, keep on testing it.



I did a new build but could not test the changes. The floppy drive on my
test machine, Mod. 77, suddenly refused to read diskettes.

This is the untested package (April 28, 2006):

www.members.aon.at/mcabase/pub/files/XGA206UN.ZIP




0
UZnal
4/28/2006 12:59:08 AM

"William R. Walsh" wrote:
> 
> No big deal...go into display properties, settings tab...and uh-oh! The
> registry is corrupt, or so says Windows.


And you >DID< back up the registry as I recommended, right?

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
4/28/2006 2:53:50 AM
Hi!

> Windows manipulates the registry, not the driver. When a registry error
> happens, it comes from the system, read Windows, side, for whatever reasons.

The driver may not, but what of the .INF file? It does.

I have no reason to believe a machine that was working flawlessly with
a relatively fresh installation of Windows, and running with only one
other program installed would have a truly corrupt registy.

The display driver is the *only* thing that changed, and when it did,
the errors started up.

> For this test VESA DDC is a good choice, and this is not about supporting
> your favorite monitor. Check the monitor table in the README and find out
> what modes your monitor can support. Then define the monitor as VESA DDC and
> use only the appropriate modes.

There's no such choice on my version of Windows. (Win95 OSR 2.5 or the
so-called "C" release...)

> Fine, keep on testing it.

I certainly do plan to do so. I'll happily try the version you just
released.

Has anyone else yet tried a 9595(-0LG) with any version of this driver?

William

0
wm_walsh
4/28/2006 3:51:53 AM
Hi!

> And you >DID< back up the registry as I recommended, right?

Yes, but I've seen no difference between the registry I've got after
restoring the stock MS drivers or the one that I backed up.

I really do not think that anything is or was ever truly wrong with the
registry on this system.

William

0
wm_walsh
4/28/2006 3:53:42 AM
Hi!

> Fine, keep on testing it.
> I did a new build but could not test the changes. The floppy drive on my
> test machine, Mod. 77, suddenly refused to read diskettes.

Okay...I sat and thought a bit, restored everything back to the original
Microsoft XGA-2 drivers, downloaded your latest revision to a floppy and
tried again at setting things up.

The only difference now being that...everything works. I've got a brilliant
800x600 display at 64K colors. Windows and the display properties window are
perfectly stable--I've been running it for a while now, doing everything I
could think of at the time. Nothing seems to be throwing any problems--even
switching to and from a full screen command line within Windows works,
whereas before it would cause a total lockup.

I have not yet tried twiddling with scan rates or anything like that. My
monitor is working (still can't find a VESA type display in the Windows
display list--is that where I should be looking?) with the IBM G50 model
selected.

I've also seen no problems with odd colors at startup.

William the thrilled


0
William
4/28/2006 4:57:56 AM
> > Windows manipulates the registry, not the driver.
>
> The driver may not, but what of the .INF file? It does.

The INF file defines the operational parameters. Conflicts can be easily
caused by an INF file.

> I have no reason to believe a machine that was working flawlessly with
> a relatively fresh installation of Windows, and running with only one
> other program installed would have a truly corrupt registy.

I don't think the machine had a corrupted registry. You got a conflict after
you installed the driver and Windows issued a standard error message. You
reverted back to the original driver and the conflict disappeared.

The same INF file worked on tested installations so far, but it did not work
on yours, that was the good side of your tests. Windows versions had
changing requirements, one probably needs 4-5 test machines running
different W9x versions to validate the install procedure and driver
operation.

> > I did a new build but could not test the changes. The floppy drive on my
> > test machine, Mod. 77, suddenly refused to read diskettes.

A bug in the original sense of the word. Children can be very
imaginative....


> The only difference now being that...everything works. I've got a
brilliant
> 800x600 display at 64K colors. Windows and the display properties window
are
> perfectly stable--I've been running it for a while now, doing everything I
> could think of at the time. Nothing seems to be throwing any
problems--even
> switching to and from a full screen command line within Windows works,
> whereas before it would cause a total lockup.

There is a new setting in the XGA2 section of the INF file and two other
changed settings. I'll have to completely rework a part in XGA2.DRV, it has
been done very poorly and incompletely. It is this part that is causing
troubles and reboots on mode and color depth changes. I saw that the S3 code
handles that much better - but it has been written by S3 and not M$.

800x600 at 64K colors is set to the default of 72 Hz in this release (April
28), it uses the IBM monitor mode settings (75 Hz used Sony settings).

> I have not yet tried twiddling with scan rates or anything like that. My
> monitor is working (still can't find a VESA type display in the Windows
> display list--is that where I should be looking?) with the IBM G50 model
> selected.

No need to change if it works. The VESA type should be behind a Standard
Monitor / Super VGA, select at least 75 Hz and 1280x1204.

> I've also seen no problems with odd colors at startup.

Not yet fully eliminated, in 800x600 and 640x480. It looks rather like a
slight disorder in the XGA mode settings although I've strictly followed the
techref (the orginal driver did not). This does not happen in 1024x768.

There is another known problem, font corruption in 1024x768 with 16 colors,
at least on this installation. Please check that.







0
UZnal
4/28/2006 2:48:23 PM
An intermediate release, separate install instructions INSTALL.TXT and
monitor, history and test reports (incl. the latest of William Walsh) in
README.TXT.

www.members.aon.at/mcabase/pub/files/xga206.zip

I intend to release the next update after planned for parts have been
reworked and the driver possibly tested under W98SE. That will take some
time, I think I deserve now some more sleep...;)

Test reports are as always greatly appreciated. When you test, you become a
part of the production and contribute to the development process. The
problems you encounter are important information. Decide for yourself.




0
UZnal
4/28/2006 11:49:37 PM
Hi!

> That will take some
> time, I think I deserve now some more sleep...;)

Certainly. I was going to try the 1024x768 at 16 color setting to see
if I could find a problem, but instead I went to sleep...and did not
get up again until this morning.

As of this afternoon, I'll be rolling out a few more test
configs...model 77 "Bermuda" Ultimedia and Model 85 are to be tested.

William

0
wm_walsh
4/29/2006 1:25:11 PM
Hi!

> Hey, unless UZ can work another miracle for NT, I wouldn't
> mind having a non-buggy GUP..

If you must have the high color, then the GUP is certainly worth the
premium.

However, with the color, there comes a serious price--performance. Even
in 256 color mode, the GUP is painful to watch. In a Server 95 (dual
serial/LPT planar, 90MHz Pentium Type 4, Windows NT Workstation 4.0
SP6a) that should be able to support it nicely, the card is woefully
slow.

I do wonder about any of this being a problem of the card. In the DOS
based ATI test utility, one can do many things that the NT driver
simply doesn't allow. (A 75Hz refresh rate in 1024x768 at high color
being one of these things. This can be specified in the ATI test
utility, and per my monitor, I am getting it. NT says 72Hz max. Not
much of a difference, but some monitors do not like 72Hz vertical
scan.)

For now, my GUP is providing base video to an Artist Graphics Winsprint
1000i, which is truly a *fast* card...even if it is limited to only 256
colors. 1280x1024 at 75Hz is no problem for it.

William

0
wm_walsh
4/29/2006 1:36:08 PM
I'll miss that psychedelic pink in the opening screen, that blue setup
bitmap in deep pink got you hypnotized the moment it came out of the
mysterious XGA-2 universe. Shine on you crazy pink. Goodbye....!

Gentlemen, we have a new XGA-2 driver. Fully operational. Cut the cake !

April 30, 2006: www.members.aon.at/mcabase/pub/files/xga206.zip

No more pink, no more corrupted 16-color modes. Two new 16-color modes,
800x600 and 1280x1204, both unsupported by the original Windows driver.

1280x1204x4 is interlaced at 53 Hz with 58.1 kHz line rate and 106 Mhz pixel
rate, the settings being those of the "IBM 9517 / IBM 9521 (M-1105)"
monitor. Despite the interlaced mode, it looks pretty fine, I was pleasantly
surprised.  Hitachi and ViewSonic claim 58 Hz non-interlaced settings for
this mode, but still low.

How about 1360x1024, 1280x960 or 1104x828 ?  Do we want some more?

The code for 16-color hi-res XGA modes ignores the coprocessor and lets the
DIB engine of Windows slowly do the work. 4-bbp logic is of course more
complicated and needs more manipulations, the boys have not done it. I'll
have to see, those raster operations and region clipping look terrible in
assembly code.

QA-Department / Test Crew: Please validate mode selection (all modes are
selectable) and eventual registry errors on install. Take a look at
1280x1024.

When you keep the color depth unchnanged and change only the resolution, you
won't need to reboot. Reboot perhaps on color depth change, depends on
Windows.

> As of this afternoon, I'll be rolling out a few more test
> configs...model 77 "Bermuda" Ultimedia and Model 85 are to be tested.

I'd be glad to hear more about the planar XGA-2. Peter [Wendt] confirmed it,
but the driver wasn't that stable. 77-Bermuda is main test machine, and we
also need results from different Windows versions, time to look at
Win98/98SE.


* * *

I am duplicating the response here to keep the topic in this thread and for
the easier documentation of the driver and discussion history:

Re: Help needed setting up Mod 90:

Louis Ohland:
 > You will need all 8 ZIPPs in order to try 64K color.

Not on the XGA, I intercept it. The XGA misery with 64K is the
non-programmable pixel clock, it is fixed at 45 Mhz. The techref supplies
mode set tables for the XGA registers only for 640x480 and 1024x768. These
are not identical to the XGA-2 tables. The first job would be to create the
mode table for 800x600, the second, to perform the coprocessor hacks.

What best refresh rate can you get out of 45 Mhz pixel rate? I am not that
optimistic. Instead, it would be wiser to put the efforts to accelerate the
XGA-2 with additional coprocessor operations, because the card itself is
indeed fast enough.










0
UZnal
4/29/2006 11:39:35 PM
On corrupted 16-color modes:

> Not yet fully eliminated, in 800x600 and 640x480. It looks rather like a
> slight disorder in the XGA mode settings although I've strictly followed
the
> techref (the orginal driver did not).

The init order is perfectly OK.

> no more corrupted 16-color modes.

Memory Access Mode Register (21x9) is the key. The pink color was a side
effect of of too ambitious optimization, but the cure for the corrupted
16-color screen would have been a hard guess to come up with. If you have
played with video adapters,
when you see that shifted screen, you'll feel there is a hardware setting
missing there.

XGA-2 can operate in Intel or Motorola byte ordering. The order must be
explicitly set up, and that is done. While it is straightforward to set it
for whole byte quantities, like 8-bpp and 16-bpp, things change in 4-bpp
when you work with the Intel ordering. (Before you read further, stop and
think why).

In the Intel case, for 4-bpp (a nibble), a byte holds two nibbles which are,
considering only the two nibbles in the byte, in fact Motorola-ordered. When
you set the Memory Access Mode Register for 4-bpp, you have to set the PEL
Order bit to Motorola. Otherwise, the coprocessor will be swapping the
nibbles and you will get nicely swapped bitmaps.

The register setting for 4-bpp (bits 0-2) is 010b. The third bit is the
Intel/Motorola bit, and for an Intel machine, it must be set and the final
correct value is 1010b, which is 0x0A or 0ah. That's all.




0
UZnal
4/30/2006 12:33:49 AM
Hi �nal, Louis,

"UZnal" <unalz-at-mail333-dot-com> schreef in bericht 
news:4453f9e9$0$12927$91cee783@newsreader02.highway.telekom.at...
>
> I'll miss that psychedelic pink in the opening screen, that blue setup
> bitmap in deep pink got you hypnotized the moment it came out of the
> mysterious XGA-2 universe. Shine on you crazy pink. Goodbye....!
>
> Gentlemen, we have a new XGA-2 driver. Fully operational. Cut the cake !
>
> April 30, 2006: www.members.aon.at/mcabase/pub/files/xga206.zip

Gratuliere!!

>
> No more pink, no more corrupted 16-color modes. Two new 16-color modes,
> 800x600 and 1280x1204, both unsupported by the original Windows driver.
>
> 1280x1204x4 is interlaced at 53 Hz with 58.1 kHz line rate and 106 Mhz 
> pixel
> rate, the settings being those of the "IBM 9517 / IBM 9521 (M-1105)"
> monitor. Despite the interlaced mode, it looks pretty fine, I was 
> pleasantly
> surprised.  Hitachi and ViewSonic claim 58 Hz non-interlaced settings for
> this mode, but still low.
>
> How about 1360x1024, 1280x960 or 1104x828 ?  Do we want some more?
>
> The code for 16-color hi-res XGA modes ignores the coprocessor and lets 
> the
> DIB engine of Windows slowly do the work. 4-bbp logic is of course more
> complicated and needs more manipulations, the boys have not done it. I'll
> have to see, those raster operations and region clipping look terrible in
> assembly code.
>
> QA-Department / Test Crew: Please validate mode selection (all modes are
> selectable) and eventual registry errors on install. Take a look at
> 1280x1024.
>
> When you keep the color depth unchnanged and change only the resolution, 
> you
> won't need to reboot. Reboot perhaps on color depth change, depends on
> Windows.
>
>> As of this afternoon, I'll be rolling out a few more test
>> configs...model 77 "Bermuda" Ultimedia and Model 85 are to be tested.
>
> I'd be glad to hear more about the planar XGA-2. Peter [Wendt] confirmed 
> it,
> but the driver wasn't that stable. 77-Bermuda is main test machine, and we
> also need results from different Windows versions, time to look at
> Win98/98SE.

I'm working on this Model 90, but could change to the Ultimedia if 
preferable; you choose.

Do you have a specific test-sequence in mind or at hand?

>
>
> * * *
>
> I am duplicating the response here to keep the topic in this thread and 
> for
> the easier documentation of the driver and discussion history:
>
> Re: Help needed setting up Mod 90:
>
> Louis Ohland:
> > You will need all 8 ZIPPs in order to try 64K color.

You mean a full complement of video-RAM?

>
> Not on the XGA, I intercept it. The XGA misery with 64K is the
> non-programmable pixel clock, it is fixed at 45 Mhz. The techref supplies
> mode set tables for the XGA registers only for 640x480 and 1024x768. These
> are not identical to the XGA-2 tables. The first job would be to create 
> the
> mode table for 800x600, the second, to perform the coprocessor hacks.
>
> What best refresh rate can you get out of 45 Mhz pixel rate? I am not that
> optimistic. Instead, it would be wiser to put the efforts to accelerate 
> the
> XGA-2 with additional coprocessor operations, because the card itself is
> indeed fast enough.
>
>


-- 
Jelte


0
JWR
4/30/2006 11:05:29 AM
Yes. Depending on the planar, you may have 4 soldered ZIPPs and four 
sockets, or eight sockets. XGA works with 512K [four ZIPPs] or 1MB 
[eight ZIPPs]. The high color mode is available only with 1MB.

640x480x64k, the unicorn. Though I'd like to see the MXGA driver.

JWR wrote:
>> Re: Help needed setting up Mod 90:
>>> You will need all 8 ZIPPs in order to try 64K color.
> You mean a full complement of video-RAM?
0
Louis
4/30/2006 12:41:10 PM
"Louis Ohland" <ohland@charter.net> schreef in bericht 
news:Hf25g.331$YJ4.13@fe06.lga...
> Yes. Depending on the planar, you may have 4 soldered ZIPPs and four 
> sockets, or eight sockets. XGA works with 512K [four ZIPPs] or 1MB [eight 
> ZIPPs]. The high color mode is available only with 1MB.

Just checked : 8 ZIPPs present (and accounted for in QUMCDOS's output).
>
> 640x480x64k, the unicorn. Though I'd like to see the MXGA driver.
>
> JWR wrote:
>>> Re: Help needed setting up Mod 90:
>>>> You will need all 8 ZIPPs in order to try 64K color.
>> You mean a full complement of video-RAM?


-- 
Jelte


0
JWR
4/30/2006 1:15:25 PM

UZnal wrote:
> 
> 
> Gentlemen, we have a new XGA-2 driver. Fully operational. Cut the cake !
> 
> April 30, 2006: www.members.aon.at/mcabase/pub/files/xga206.zip



Sunday morning playtime again. The Ultimedia has been running
continuously for the last week without a glitch. I beat on it for a
while this morning looking at hi-res pictures on the internet.
Fleshtones are very nice.... :)  Switching in and out of fullscreen DOS
prompt OK, shutdwon/restart OK, anything else I can think of seems to
work. Response is very good, limited by hard disk swapping.

I installed the above driver set a few minutes ago without problems, and
all seems to be working as before. Quickly scrounged up some memory and
bumped the system RAM up to 24 megs, that helps. Will let the AfterDark
slideshow go at it for a while as I attend to other matters.

Well done, UZ! Your efforts are very much appreciated!

-Jim

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
4/30/2006 4:39:29 PM
Hi Jelte,

> I'm working on this Model 90, but could change to the Ultimedia if
> preferable; you choose.
>
> Do you have a specific test-sequence in mind or at hand?

We have no test results for the XGA. Though there are no new features, we
need the assurance that the driver works on it.




0
UZnal
4/30/2006 6:43:39 PM
> 640x480x64k, the unicorn. Though I'd like to see the MXGA driver.

The techref is very reserved about the (fixed) clock settings of the XGA,
only 2-3 settings are mentioned (640x480 and 1024x768), the rest is marked
as reserved.

640x480 at 60 Hz (25.25 Mhz) it too low for a max pixel rate of 45 Mhz,
there is room for improvement there. 800x600 cannot be attacked without mode
settings.

A possibility is to look closer at the AGX, the XGA clone.




0
UZnal
4/30/2006 6:53:38 PM
> Fleshtones are very nice.... :)

Mmmm... You've deciphered XGA-2-0-6...;)

> Well done, UZ! Your efforts are very much appreciated!

Thank you! All test efforts are highly appreciated as well!

A sad affair, actually. Why have we been deprived of it for so long? It took
one Windows-95-driver-untrained person less than 4 weeks of part time to
accomplish it. Without the resources of IBM/M$. An engineer with display
driver experience could have done it in a shorter time.

This driver is coming possibly years too late. Better late then never?




0
UZnal
4/30/2006 7:20:40 PM
   I dug down to my 90 out on the porch and applied power to it for the 
first time in perhaps years. As expected, it powered up and booted.

   I must now install a BT-646 due to W98's inability to handle dual 
SCSI controllers on the same adapter.

    Where is the setup disk image for W98?
0
Louis
4/30/2006 8:00:24 PM
Hi �nal !

> I'll miss that psychedelic pink in the opening screen, that blue setup
> bitmap in deep pink got you hypnotized the moment it came out of the
> mysterious XGA-2 universe. Shine on you crazy pink. Goodbye....!
> 
> Gentlemen, we have a new XGA-2 driver. Fully operational. Cut the cake !
> 
> April 30, 2006: www.members.aon.at/mcabase/pub/files/xga206.zip
> 
> No more pink, no more corrupted 16-color modes. Two new 16-color modes,
> 800x600 and 1280x1204, both unsupported by the original Windows driver.

When I returned from Ankes aunts birthday "party" (or whatever I should 
call that: many meals included) I needed to feed my mind a bit too and 
downloaded the new version.

Tests haven't yet fully finished, but it works as good as the previous 
- 28.04.06 dated ... I left out that from 29th, since I had put the 9556 
aside for a larger scan run on "the shoebox".

> 1280x1204x4 is interlaced at 53 Hz with 58.1 kHz line rate and 106 Mhz pixel
> rate, the settings being those of the "IBM 9517 / IBM 9521 (M-1105)"
> monitor. Despite the interlaced mode, it looks pretty fine, I was pleasantly
> surprised.  Hitachi and ViewSonic claim 58 Hz non-interlaced settings for
> this mode, but still low.
> 
> How about 1360x1024, 1280x960 or 1104x828 ?  Do we want some more?

I cannot use these modes on the LCD in the 6314 setting, since they are 
unsupported with it, but I try a different setting later.

[snip]

> I'd be glad to hear more about the planar XGA-2. Peter [Wendt] confirmed it,
> but the driver wasn't that stable. 77-Bermuda is main test machine, and we
> also need results from different Windows versions, time to look at
> Win98/98SE.

Some remark (again) on my "mode of operation":
- before trying out a new driver I return to "Standard VGA" mode
- do a reboot
- kill off the two files DRVIDX.BIN and DRVDATA.BIN
- delete the MCABaseXGA206.INF (see comment further below)
- I however keep the 6314 screen setting, since it allowes to select 
between 60, 72 and 75 Hz along with "Standard" and "Optimal" settings.

Then I install the new drivers and do a reboot (as asked).

On change from 640x480 / 256 colors to 800x600 / 64K colors the screen 
turns "crying green" with pinkish window background and the mouse 
actions leave a trail of mouse cursor icons, when I select "Change mode 
without restart".
A fullscreen DOS-screen does not fix it - you really need a restart 
(reboot or "Shutdown to DOS" and Exit)

The 1024x768 mode works, the 1280x1024 ends in an "No Supported" display 
on the ColorTac 19" LCD, but that won't surprise me much.
This then requires to start Win95 up in "Safe Mode" and set the screen 
resolution back to 800x600 with appropriate refresh. No way to go back 
otherwise, since the LCD stays totally blank (except you know *exactly* 
all the pushbuttons and the way to reach them via keyboard blindly)

The antique Siemenst 14" CRT however shows a picture - but it is a pain 
for the eyes. As worse as my RS/6000 in 1280x 1024 ... I use the 14" for 
the 7009-C10 to be honest. A purpose it was never intended to do. :-)


A side comment on the README.TXT:

 >INF FILE CLEANUP
 >
 >If you are reinstalling the XGA206 driver and wish to to get rid of
 >previous XGA206 driver traces, you can delete the following two files
 >from the C:\WINDOWS\INF directory:
 >
 >DRVIDX.BIN      -- These will be rebuilt by Windows
 >DRVDATA.BIN        when you install a driver.
 >OEMn.INF        -- See following note.
 >
 >The XGA06 INF files are copied to C:\WINDOWS\INF as OEMn.INF where
 >n denotes a number. You can safely delete these files if you are
 >reinstalling the driver. Make sure you remove XGA206 INF files,
 >check first the contents of each OEMn.INF before you delete it.

On my Win95C (OSR2) there is no OEMn.INF.
Instead there is a subdir called "Other" which contains a file 
MCABaseXGA206.INF


Next I'm going to try out the PS/2e with the new set of drivers.
Most likely tomorrow ...

-- 
Very friendly greetings from Peter in Germany
http://members.aol.com/mcapage0/mcaindex.htm

*** Reply to: peterwendt@aol.com only ! ***
0
Peter
4/30/2006 9:15:05 PM
Hi �nal !

> Hi Jelte,
> 
> 
>>I'm working on this Model 90, but could change to the Ultimedia if
>>preferable; you choose.
>>
>>Do you have a specific test-sequence in mind or at hand?
> 
> 
> We have no test results for the XGA. Though there are no new features, we
> need the assurance that the driver works on it.

I could offer to dig out the working P75 and attach the 19" ColorTac LCD 
to it ... ;-)
(But as I recall that one still has OS/2 on the HD ...)

-- 
Very friendly greetings from Peter in Germany
http://members.aol.com/mcapage0/mcaindex.htm

*** Reply to: peterwendt@aol.com only ! ***
0
Peter
4/30/2006 9:22:53 PM
On Sun, 30 Apr 2006 21:20:40 +0200, "UZnal" <unalz-at-mail333-dot-com>
wrote:

> This driver is coming possibly years too late. Better late then never?

Think of all the thousands of tons of PS/2 computers that hit the
landfills around the world for want of this device driver.  And all
because IBM/M$ couldn't be bothered to spend a few hundred dollars of
effort to keep machines relevant to the dominant OS.

We don't hesitate to require cradle-to-grave responsibility for makers
of such electronics nowadays, but because we couldn't see the value in a
driver to keep the computers relevant ...

How do we simplify this issue so that public policy makers can
understand it?
+-----------------------------------------+
| Charles Lasitter   | Mailing/Shipping   |
| 401/728-1987       | 14 Cooke St        |
| cl+at+ncdm+dot+com | Pawtucket RI 02860 |
+-----------------------------------------+
0
Charles
4/30/2006 9:26:41 PM
Hi �nal !

>>Fleshtones are very nice.... :)
> 
> 
> Mmmm... You've deciphered XGA-2-0-6...;)

Uh-oh.
I'd often wondered about that 206-number ... and to be honest I used the 
new-driver-upgraded XGA2 on the '56 with "nice pictures" as well. Hard 
to beat on the naturality side ... :-)

>>Well done, UZ! Your efforts are very much appreciated!
> 
> 
> Thank you! All test efforts are highly appreciated as well!
> 
> A sad affair, actually. Why have we been deprived of it for so long? It took
> one Windows-95-driver-untrained person less than 4 weeks of part time to
> accomplish it. Without the resources of IBM/M$. An engineer with display
> driver experience could have done it in a shorter time.
> 
> This driver is coming possibly years too late. Better late then never?

Good things need time.

Back then, when PS/2s were discontinued the times were fast-changing and 
  everyone switched into the new worlds of wonders (PCI, big, fast 
chips, lots of memory and big HDs) - no one tried a consolidation of 
what we already had. A new world-record every four weeks instead. CPU 
speeds shot into the GHz-range, memory into the GB's and HDs into 
multi-GBs as well. Little interest in fine-tuning the "old stuff". It 
was yesterdays' stuff. Today "our gear" is the VW Kaefer of the IT-world 
and enthusiasts do, what the engineers back then *could have done* if 
there hadn't been the "all new Golf-Model" out all of a sudden ...

Remember the hardware fault with the false-mounted capacitor I 
discovered on the Cirrus SVGA card ? Why didn't anyone notice and fix 
this pretty obvious fault ? Because it was considered "dead technology" 
already. Deads often live longer. Take it as a sign of the superiority 
of PS/2 that there are still operational machines out and that there are 
people with interest in them.

-- 
Very friendly greetings from Peter in Germany
http://members.aol.com/mcapage0/mcaindex.htm

*** Reply to: peterwendt@aol.com only ! ***
0
Peter
4/30/2006 9:36:02 PM
Getting closer to W98SE. Got my SDC3211F out. ADF on floppy. A bit messy 
with installing another CD (50 pin) but I got W95 edit and the BT ASPI 
and CDROM drivers ready. I suspect that I'll be missing some other files...

Peter H. Wendt wrote:
> Hi �nal !
> 
>> I'll miss that psychedelic pink in the opening screen, that blue setup
>> bitmap in deep pink got you hypnotized the moment it came out of the
>> mysterious XGA-2 universe. Shine on you crazy pink. Goodbye....!
>>
>> Gentlemen, we have a new XGA-2 driver. Fully operational. Cut the cake !
>>
>> April 30, 2006: www.members.aon.at/mcabase/pub/files/xga206.zip
>>
>> No more pink, no more corrupted 16-color modes. Two new 16-color modes,
>> 800x600 and 1280x1204, both unsupported by the original Windows driver.
> 
> When I returned from Ankes aunts birthday "party" (or whatever I should 
> call that: many meals included) I needed to feed my mind a bit too and 
> downloaded the new version.
> 
> Tests haven't yet fully finished, but it works as good as the previous - 
> 28.04.06 dated ... I left out that from 29th, since I had put the 9556 
> aside for a larger scan run on "the shoebox".
> 
>> 1280x1204x4 is interlaced at 53 Hz with 58.1 kHz line rate and 106 Mhz 
>> pixel
>> rate, the settings being those of the "IBM 9517 / IBM 9521 (M-1105)"
>> monitor. Despite the interlaced mode, it looks pretty fine, I was 
>> pleasantly
>> surprised.  Hitachi and ViewSonic claim 58 Hz non-interlaced settings for
>> this mode, but still low.
>>
>> How about 1360x1024, 1280x960 or 1104x828 ?  Do we want some more?
> 
> I cannot use these modes on the LCD in the 6314 setting, since they are 
> unsupported with it, but I try a different setting later.
> 
> [snip]
> 
>> I'd be glad to hear more about the planar XGA-2. Peter [Wendt] 
>> confirmed it,
>> but the driver wasn't that stable. 77-Bermuda is main test machine, 
>> and we
>> also need results from different Windows versions, time to look at
>> Win98/98SE.
> 
> Some remark (again) on my "mode of operation":
> - before trying out a new driver I return to "Standard VGA" mode
> - do a reboot
> - kill off the two files DRVIDX.BIN and DRVDATA.BIN
> - delete the MCABaseXGA206.INF (see comment further below)
> - I however keep the 6314 screen setting, since it allowes to select 
> between 60, 72 and 75 Hz along with "Standard" and "Optimal" settings.
> 
> Then I install the new drivers and do a reboot (as asked).
> 
> On change from 640x480 / 256 colors to 800x600 / 64K colors the screen 
> turns "crying green" with pinkish window background and the mouse 
> actions leave a trail of mouse cursor icons, when I select "Change mode 
> without restart".
> A fullscreen DOS-screen does not fix it - you really need a restart 
> (reboot or "Shutdown to DOS" and Exit)
> 
> The 1024x768 mode works, the 1280x1024 ends in an "No Supported" display 
> on the ColorTac 19" LCD, but that won't surprise me much.
> This then requires to start Win95 up in "Safe Mode" and set the screen 
> resolution back to 800x600 with appropriate refresh. No way to go back 
> otherwise, since the LCD stays totally blank (except you know *exactly* 
> all the pushbuttons and the way to reach them via keyboard blindly)
> 
> The antique Siemenst 14" CRT however shows a picture - but it is a pain 
> for the eyes. As worse as my RS/6000 in 1280x 1024 ... I use the 14" for 
> the 7009-C10 to be honest. A purpose it was never intended to do. :-)
> 
> 
> A side comment on the README.TXT:
> 
>  >INF FILE CLEANUP
>  >
>  >If you are reinstalling the XGA206 driver and wish to to get rid of
>  >previous XGA206 driver traces, you can delete the following two files
>  >from the C:\WINDOWS\INF directory:
>  >
>  >DRVIDX.BIN      -- These will be rebuilt by Windows
>  >DRVDATA.BIN        when you install a driver.
>  >OEMn.INF        -- See following note.
>  >
>  >The XGA06 INF files are copied to C:\WINDOWS\INF as OEMn.INF where
>  >n denotes a number. You can safely delete these files if you are
>  >reinstalling the driver. Make sure you remove XGA206 INF files,
>  >check first the contents of each OEMn.INF before you delete it.
> 
> On my Win95C (OSR2) there is no OEMn.INF.
> Instead there is a subdir called "Other" which contains a file 
> MCABaseXGA206.INF
> 
> 
> Next I'm going to try out the PS/2e with the new set of drivers.
> Most likely tomorrow ...
> 
0
Louis
4/30/2006 9:54:27 PM
SDC3211F installed in slot 3. XGA-2 in slot 1. Found 50 pin cable from 
76 that has IDC header on it. Now to swap out 20x Plextor with 8x IBM. 
Dig up 50 pin drive.

This 90 has the full 1MB of ZIPPs installed. Should make it easier [I 
hope] to test the XGA support.

Louis Ohland wrote:
> Getting closer to W98SE. Got my SDC3211F out. ADF on floppy. A bit messy 
> with installing another CD (50 pin) but I got W95 edit and the BT ASPI 
> and CDROM drivers ready. I suspect that I'll be missing some other files...
> 
> Peter H. Wendt wrote:
>> Hi �nal !
>>
>>> I'll miss that psychedelic pink in the opening screen, that blue setup
>>> bitmap in deep pink got you hypnotized the moment it came out of the
>>> mysterious XGA-2 universe. Shine on you crazy pink. Goodbye....!
>>>
>>> Gentlemen, we have a new XGA-2 driver. Fully operational. Cut the cake !
>>>
>>> April 30, 2006: www.members.aon.at/mcabase/pub/files/xga206.zip
>>>
>>> No more pink, no more corrupted 16-color modes. Two new 16-color modes,
>>> 800x600 and 1280x1204, both unsupported by the original Windows driver.
>>
>> When I returned from Ankes aunts birthday "party" (or whatever I 
>> should call that: many meals included) I needed to feed my mind a bit 
>> too and downloaded the new version.
>>
>> Tests haven't yet fully finished, but it works as good as the previous 
>> - 28.04.06 dated ... I left out that from 29th, since I had put the 
>> 9556 aside for a larger scan run on "the shoebox".
>>
>>> 1280x1204x4 is interlaced at 53 Hz with 58.1 kHz line rate and 106 
>>> Mhz pixel
>>> rate, the settings being those of the "IBM 9517 / IBM 9521 (M-1105)"
>>> monitor. Despite the interlaced mode, it looks pretty fine, I was 
>>> pleasantly
>>> surprised.  Hitachi and ViewSonic claim 58 Hz non-interlaced settings 
>>> for
>>> this mode, but still low.
>>>
>>> How about 1360x1024, 1280x960 or 1104x828 ?  Do we want some more?
>>
>> I cannot use these modes on the LCD in the 6314 setting, since they 
>> are unsupported with it, but I try a different setting later.
>>
>> [snip]
>>
>>> I'd be glad to hear more about the planar XGA-2. Peter [Wendt] 
>>> confirmed it,
>>> but the driver wasn't that stable. 77-Bermuda is main test machine, 
>>> and we
>>> also need results from different Windows versions, time to look at
>>> Win98/98SE.
>>
>> Some remark (again) on my "mode of operation":
>> - before trying out a new driver I return to "Standard VGA" mode
>> - do a reboot
>> - kill off the two files DRVIDX.BIN and DRVDATA.BIN
>> - delete the MCABaseXGA206.INF (see comment further below)
>> - I however keep the 6314 screen setting, since it allowes to select 
>> between 60, 72 and 75 Hz along with "Standard" and "Optimal" settings.
>>
>> Then I install the new drivers and do a reboot (as asked).
>>
>> On change from 640x480 / 256 colors to 800x600 / 64K colors the screen 
>> turns "crying green" with pinkish window background and the mouse 
>> actions leave a trail of mouse cursor icons, when I select "Change 
>> mode without restart".
>> A fullscreen DOS-screen does not fix it - you really need a restart 
>> (reboot or "Shutdown to DOS" and Exit)
>>
>> The 1024x768 mode works, the 1280x1024 ends in an "No Supported" 
>> display on the ColorTac 19" LCD, but that won't surprise me much.
>> This then requires to start Win95 up in "Safe Mode" and set the screen 
>> resolution back to 800x600 with appropriate refresh. No way to go back 
>> otherwise, since the LCD stays totally blank (except you know 
>> *exactly* all the pushbuttons and the way to reach them via keyboard 
>> blindly)
>>
>> The antique Siemenst 14" CRT however shows a picture - but it is a 
>> pain for the eyes. As worse as my RS/6000 in 1280x 1024 ... I use the 
>> 14" for the 7009-C10 to be honest. A purpose it was never intended to 
>> do. :-)
>>
>>
>> A side comment on the README.TXT:
>>
>>  >INF FILE CLEANUP
>>  >
>>  >If you are reinstalling the XGA206 driver and wish to to get rid of
>>  >previous XGA206 driver traces, you can delete the following two files
>>  >from the C:\WINDOWS\INF directory:
>>  >
>>  >DRVIDX.BIN      -- These will be rebuilt by Windows
>>  >DRVDATA.BIN        when you install a driver.
>>  >OEMn.INF        -- See following note.
>>  >
>>  >The XGA06 INF files are copied to C:\WINDOWS\INF as OEMn.INF where
>>  >n denotes a number. You can safely delete these files if you are
>>  >reinstalling the driver. Make sure you remove XGA206 INF files,
>>  >check first the contents of each OEMn.INF before you delete it.
>>
>> On my Win95C (OSR2) there is no OEMn.INF.
>> Instead there is a subdir called "Other" which contains a file 
>> MCABaseXGA206.INF
>>
>>
>> Next I'm going to try out the PS/2e with the new set of drivers.
>> Most likely tomorrow ...
>>
0
Louis
4/30/2006 10:13:54 PM

"Peter H. Wendt" wrote:
> 
> I'd often wondered about that 206-number ... and to be honest I used the
> new-driver-upgraded XGA2 on the '56 with "nice pictures" as well. Hard
> to beat on the naturality side ... :-)


Heh ... Peter, domai.com

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
4/30/2006 11:09:07 PM
Amazing how flesh tones help one to adjust color balance...

Jim Shorney wrote:
> 
> "Peter H. Wendt" wrote:
>> I'd often wondered about that 206-number ... and to be honest I used the
>> new-driver-upgraded XGA2 on the '56 with "nice pictures" as well. Hard
>> to beat on the naturality side ... :-)
> 
> 
> Heh ... Peter, domai.com
> 
> ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
> http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
> ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Louis
4/30/2006 11:21:00 PM
Hi Peter,

> >>Fleshtones are very nice.... :)
> > Mmmm... You've deciphered XGA-2-0-6...;)

> I'd often wondered about that 206-number ...

Room number .... :) ?

>  Hard to beat on the naturality side ... :-)

Hey, you all make me realy curious now...


> Remember the hardware fault with the false-mounted capacitor I
> discovered on the Cirrus SVGA card ? Why didn't anyone notice and fix
> this pretty obvious fault ? Because it was considered "dead technology"
> already. Deads often live longer. Take it as a sign of the superiority
> of PS/2 that there are still operational machines out and that there are
> people with interest in them.

Sure, I remember, it was another exciting NG time. It is the company
managers lastly who take such positions. I must say, I  have encountered too
few managers with a sharp technical understanding and appreciation for these
issues. Sometimes I wonder if we probably overvalue and show too much
respect for the established company names.




0
UZnal
4/30/2006 11:32:29 PM
> because IBM/M$ couldn't be bothered to spend a few hundred dollars of
> effort to keep machines relevant to the dominant OS.

I think of the OS/2 IBM EWS (Employe Written Software). An inofficial driver
release could have been possible. M$ did not want to and IBM was not
willing.


> We don't hesitate to require cradle-to-grave responsibility for makers
> of such electronics nowadays, but because we couldn't see the value in a
> driver to keep the computers relevant ...
>
> How do we simplify this issue so that public policy makers can
> understand it?

Local politicians here are mostly seen with the latest gadgets. I haven't
yet found the formula that would explain the interest in "obsolete" (as they
would call it) computers to other people. For some time, I did compare them
to cars, to oldtimers, with less success.

The appreciation will possibly rise with the rise of the computer culture.
Not too late there will be a Hollywood movie where somebody with an
"obsolete" computer will save the world. Then there might be more awareness
and more understanding.





0
UZnal
4/30/2006 11:38:14 PM
Hi Peter,

> On change from 640x480 / 256 colors to 800x600 / 64K colors the screen
> turns "crying green" with pinkish window background and the mouse
> actions leave a trail of mouse cursor icons, when I select "Change mode
> without restart".
> A fullscreen DOS-screen does not fix it - you really need a restart
> (reboot or "Shutdown to DOS" and Exit)

It must be rebooted/restarted because the original code lacks operations for
pre-mode and post-mode change. The original XGA2.DRV code is not fully Win95
(Version 4.0) compliant. I plan to change that and started already. It looks
as if XGA2.DRV would be completely rewritten, the VXD will be also touched
by this.

The Win95 version I am using to test, prompts me to restart in the case
above. But perhaps I should be more explicit in the install instructions.

> A side comment on the README.TXT:

> On my Win95C (OSR2) there is no OEMn.INF.
> Instead there is a subdir called "Other" which contains a file
> MCABaseXGA206.INF

OK, I'll include that in README.TXT.

> Next I'm going to try out the PS/2e with the new set of drivers.
> Most likely tomorrow ...

OK, just for the case it might be needed, I put an updated PS/2e INF file
(incl. the new modes) which claims the VGA resources:

May 1, 2006: www.members.aon.at/mcabase/pub/files/xgaps2e.zip






0
UZnal
4/30/2006 11:39:03 PM
>  XGA-2 in slot 1.
>
> This 90 has the full 1MB of ZIPPs installed. Should make it easier [I
> hope] to test the XGA support.

XGA-2 will take on precedence, the planar XGA will be disabled for the
duration of the session.







0
UZnal
4/30/2006 11:42:05 PM
> >  XGA-2 in slot 1.
> >
> > This 90 has the full 1MB of ZIPPs installed. Should make it easier [I
> > hope] to test the XGA support.
>
> XGA-2 will take on precedence, the planar XGA will be disabled for the
> duration of the session.

And vice versa, XGA in slot takes over. An adapter in a slot means "I want
to use the adapter and not the planar".






0
UZnal
4/30/2006 11:49:33 PM

UZnal wrote:
> 
> I haven't
> yet found the formula that would explain the interest in "obsolete" (as they
> would call it) computers to other people. For some time, I did compare them
> to cars, to oldtimers, with less success.


I think it is similar to the interest in vintage communications radio
equipment among ham and shortwave hobbyists. The older stuff has a
certain charm and warmth (real radios glow in the dark), a sense of
history, is easier to maintain and repair yourself, and a well
maintained specimin of one of the finer examples (Drake, Collins, the
infamous R390-series, Hallicrafters, Hammerlund, etc.) will, more often
than not, perform better than the cheap mass-market equipment available
today.

And, this stuff has been on the other side of the inverse bell curve for
several years now. For many years it was worth next to nothing, and now
the value has gone back up to where, in some cases, people pay more now
for them than when they were new. Will this happen to our PS/2s? Only
time will tell.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
5/1/2006 1:01:21 AM
Hi Jim !

> "Peter H. Wendt" wrote:
> 
>>I'd often wondered about that 206-number ... and to be honest I used the
>>new-driver-upgraded XGA2 on the '56 with "nice pictures" as well. Hard
>>to beat on the naturality side ... :-)
> 
> 
> 
> Heh ... Peter, domai.com

You bet.
They had some nice pictures in the "newsletter" section for 1st of May 
(Springbreak !).

-- 
Very friendly greetings from Peter in Germany
http://members.aol.com/mcapage0/mcaindex.htm

*** Reply to: peterwendt@aol.com only ! ***
0
Peter
5/1/2006 9:17:04 AM
Louis Ohland wrote:
>   I dug down to my 90 out on the porch and applied power to it for the 
> first time in perhaps years. As expected, it powered up and booted.

I've installed XGA206 on my 8590, and works without a hitch, this is the 
configuration:

Machine   : 8590
OS        : Windows 98 SE
Processor : P90 Type 4
Memory    : 64MB
SCSI      : Spock (Slot 1)
Display   : XGA/2 (Slot 2)
Network   : 3COM 3C589 (Slot 3)
Hard Disk : 540 MB SCSI
CD-ROM    : IBM CD-ROM II

Started with a clean disk.  Copied the CABS off the CD onto the HDD. 
Ran setup without any special switches.  After a good wait, it finally 
rebooted into Windows.  Default display driver ran 640x480x256.  I upped 
it to 640x480x64K, success.  Then I downloaded XGA206 driver onto a 
floppy and installed it via the Display Properties dialog.  Selected 
640x480x64K resolution, it asked to restart and so I let it.  Restarted, 
display did a big "Dong" as if it had just been turned on.  It then 
gleefully showed me my network login.  IE shows colorful web pages, 3D 
screen savers work great, no problems.  No display corruption noted so 
far.  I have to say this is by far the coolest thing I've seen.  Perhaps 
this can spur a whole new wave of software development for these PS/2s?

--Daniel
0
Daniel
5/2/2006 1:15:42 PM
Hi!

> A sad affair, actually. Why have we been
> deprived of it for so long?

Hmm...my guess is that Microsoft just didn't care. They didn't have to.

The XGA-2 driver is not the only deficient driver Microsoft has
supplied. I can think of Trident (256 colors max, Trident later issued
drivers that allow full use of the chipset), Cirrus (WinNT/2000/XP only
see 1MB of VRAM on early PCI chipsets) and Compaq Advanced Graphics
(driver doesn't work right, not even in Win98-98SE...). The NCR video
chipset in my NCR 3350 (thanks Louis!) is high color capable, and NT
even installs a 64K color driver, but I can't get there from here (256
colors max)...refresh rates are also quite limited, and I feel that
limit is artificial.

> This driver is coming possibly years too late.
> Better late then never?

For those of us dedicated to running and preserving Microchannel, it's
not too late. I'm sure that many others not frequenting this group will
see it as well. A lot of machines will benefit anyway.

Others have been down down this road. See comments above regarding
Compaq (AVGA) and Trident video adapters. Both companies wrote their
own drivers when the Microsoft-supplied ones failed or underutilized
the chipset.

William

0
wm_walsh
5/2/2006 2:19:59 PM
Daniel Hamilton wrote:
> floppy and installed it via the Display Properties dialog.  Selected 
> 640x480x64K resolution, it asked to restart and so I let it.  Restarted, 
> display did a big "Dong" as if it had just been turned on.  It then 
> gleefully showed me my network login.  IE shows colorful web pages, 3D 

As an addendum, 800x600x64K works great as well!

--Daniel
0
Daniel
5/2/2006 3:11:20 PM
> > floppy and installed it via the Display Properties dialog.  Selected
> > 640x480x64K resolution, it asked to restart and so I let it.  Restarted,
> > display did a big "Dong" as if it had just been turned on.  It then
> > gleefully showed me my network login.  IE shows colorful web pages, 3D
>
> As an addendum, 800x600x64K works great as well!

Good news, looks like we have positive results on almost all Windows
versions. Please play a little bit more with it, I'd be glad if you can
report a problem.

The original Windows driver supports 640x480x64K as a display-only mode, no
coprocessor. I moved the operations to the coprocessor in case of the XGA-2.
Another point to note, 1024x768x8 on the XGA-2 is for the Windows driver the
XGA mode, that is, interlaced. It uses the XGA mode table on the XGA-2, with
60 Hz. XGA206 removed these and other limitations.












0
UZnal
5/2/2006 10:21:50 PM
The status of the XGA side is set to "PARTLY OPERATIONAL" until more XGA
tests are published. We have too little info about the XGA behaviour of the
driver.

The latest XGA206 build is below, work with it:

May 3, 2006: www.members.aon.at/mcabase/pub/files/xga206.zip

Updated INSTALL.TXT with more preliminary info, added section on multiple
adapters.

Updated README.TXT with the latest XGA-2 test reports (Daniel Hamilton,
Peter Wendt, Jim Shorney).








0
UZnal
5/3/2006 7:23:51 PM
On 2 May 2006 07:19:59 -0700, wm_walsh@hotmail.com wrote:

> The XGA-2 driver is not the only deficient driver Microsoft has
> supplied.

If you were going to task someone to write an efficient driver for
something, like an XGA-2, how would you come up with a measure of
efficiency for the resulting effort?
+-----------------------------------------+
| Charles Lasitter   | Mailing/Shipping   |
| 401/728-1987       | 14 Cooke St        |
| cl+at+ncdm+dot+com | Pawtucket RI 02860 |
+-----------------------------------------+
0
Charles
5/3/2006 7:58:20 PM
XGA fixes / XGA-2 unchanged, the latest XGA206 build:

May 4, 2006: www.members.aon.at/mcabase/pub/files/xga206.zip

Updated test reports (Louis Ohland), included XGA-2 refresh tables.

XGA-2 refresh rates selection and changes on W98SE are possible on the fly.
All refresh rates work as expected. The setting Standard/Optimal refers to
the best refresh, 75 Hz,  except for 1280x1024 which is currently only 53 Hz
interlaced.




0
UZnal
5/4/2006 10:13:44 PM
XGA fixes / XGA-2 unchanged, the latest XGA206 build:

May 7, 2006: www.members.aon.at/mcabase/pub/files/xga206.zip







0
UZnal
5/7/2006 12:32:54 AM
The 4 MB aperture setting on the XGA/XGA-2  is controlled by bit 0 of
pos[2]. This setting is not present in the ADF, but it is present in the
planar ADF of Mod. 57 as a fixed resource (pos[10]=00000010b meaning
disabled).

- If this bit is set (= 1) , the 4 MB aperture is enabled. It will be
enabled on 32-bit systems when the XGA/XGA-2 is in a 32-bit slot.

- If this bit is not set (= 0), the 4 MB aperture is disabled. It will be
disabled in SX class 16-bit systems. It will be disabled on 32-bit systems
when the XGA/XGA-2 is in a 16-bit slot.

The 4 MB aperture tells where the video memory is located, the video memory
size on the cards we have and use is max 1 MB. The XGA design has the limit
at 4 MB, and the addressing logic is obviously already on chip.

Below is the dump from Mod. 77, the 4 MB aperture is enabled. As expected,
it is disabled on Mod. 57.

Bits 1-7 of pos[2] ( = 1 1 1 1 1 1 0) are the upper 7 bits of the video base
address, the next three bits are taken from the instance number, e.g.
instance 6 ( = 1 1 0), and the rest 22 bits are all 0. This 32-bit value
gives the physical address of video memory, the start address of the 4 MB
aperture. Since there can be 8 instances, the total range is 32 MB where
each 4 MB portion is assigned to an XGA instance.

Imagine a 32 MB video RAM card extender filling in the holes ....? Or only 3
MB, with instance settings.


SLOT 1 ---  IBM XGA-2 Display Adapter/A
AdapterID   8FDA
-------------------------------------
106-7h  POS Subadress extension: 0000
102h    pos[0] = 0D : 0 0 0 0 1 1 0 1
103h    pos[1] = 5E : 0 1 0 1 1 1 1 0
104h    pos[2] = FD : 1 1 1 1 1 1 0 1    Bit-0: 4MB aperture enabled
105h    pos[3] = D0 : 1 1 0 1 0 0 0 0


If you run NT on XGA-2, make sure the 4 MB aperture is enabled, i.e. use
XGA/XGA-2 in a 32-bit slot on a 32-bit machine.

The aperture allows a system to access the complete video memory without the
need to do anything else, this accelerates operations on video memory.




0
UZnal
5/7/2006 8:38:50 PM
UZ, to enable the 4MB aperture you need to do nothing under setup?

If I understand:

For 386DX and 486DX systems, if an XGA/XGA2 is installed in a 32 bit 
slot, then the 4MB aperture is automagically possible and is used by 
default. There is no setting under system programs needed to enable this.

> If you run NT on XGA-2, make sure the 4 MB aperture is enabled, i.e. use
> XGA/XGA-2 in a 32-bit slot on a 32-bit machine.
> 
> The aperture allows a system to access the complete video memory without the
> need to do anything else, this accelerates operations on video memory.
0
Louis
5/7/2006 9:30:53 PM
> UZ, to enable the 4MB aperture you need to do nothing under setup?

Correct, though the planar ADF for Mod. 57 (see PE0FE.ADF) lists it as a
fixed resource.

> For 386DX and 486DX systems, if an XGA/XGA2 is installed in a 32 bit
> slot, then the 4MB aperture is automagically possible and is used by
> default. There is no setting under system programs needed to enable this.

There is no setting, but the POS resource exists.  I'll have to update QUMC
to report it and provide some more info on XGA/XGA-2.





0
UZnal
5/7/2006 9:52:05 PM
JWR's XGA arrived in best condition. Tests can resume.










0
UZnal
5/10/2006 4:22:17 PM
Hi �nal,

"UZnal" <unalz-at-mail333-dot-com> schreef in bericht 
news:446214ed$0$3882$91cee783@newsreader01.highway.telekom.at...
> JWR's XGA arrived in best condition. Tests can resume.

Great!
>
>


And to continue on this happy note : here are the first testresults from 
Holland!

Testset :
(more info -output of QUMCDOS etc- on
ftp://ps2supersite.homedns.org/incoming/jelte.roelfsema/
files : 0G4H3*.TXT )

------------------------------------------
Mod 90 9590-ALA; Spock in slot1; rest empty;
8 * 8 MB ECC; planar XGA1;
Type 3 -xMx DX-50 256KB L2 cache.
HD1 : Conner CP3540 540 MB SCSI-ID=6
HD2 : IBM DCHS 4.3 GB SCSI-ID=5
CD : IBM CR-503-C 4speed SCSI-ID=0
Display : IBM 6546

OS: W98SE 4.10.2222A

-------------------------------------
Upon installing W98SE recognised and installed XGA1 correctly:
XGA.drv    4.10.00.1998
+XGA.vxd   4.10.00.1998
  +VMM32.vxd (vdd.vxd)
  +VMM32.vxd (vflatd.vxd)

I/O range : 03B0 - 03BB
I/O range : 03C0 - 03DF
Mem range : 000A0000 - 000AFFFF
Mem range : 000B8000 - 000BFFFF

Although "use new settings without restarting the system" was selected, 
sometimes the OS requested it still, see below.

With "Standard Display"
-----------------------------------
Initial setting : 640 x 480 x 16
Display, Settings gives 16, 256 and hi (16 bit) colors; slide has 640x480 
and 1024x768.

At 640 x 480, changing from 16 to 256 or hi color and back to 16, requires a 
restart.
Changing from 256 to hi and back goes without question.
Results are good and stable.

Changing from 640x480 to 1024x768 needs a restart. Only 16 colors available. 
Result good and stable.

With "IBM 6546"
-----------------------------------
Initial setting : 640 x 480 x 16
Display, Settings gives 16, 256 and hi (16 bit) colors; slide has 640x480 
and 1024x768.

At 640 x 480, changing from 16 to 256 or hi color and back to 16, requires a 
restart.
Changing from 256 to hi and back goes without question.
Results are good and stable.

And now for the funny part:
Start from 640x480x16 ; change to 1024x768; only 16 colors available.
Start from 640x480x256 ; change to 1024x768; 16 and 256 colors available!!
Start from 640x480xhi ; change to 1024x768; 16 and 256 colors available.

Changing from 640x480 to 1024x768 needs a restart. Only 16 colors available. 
Result good and stable.

========================
Went back to 640x480x16 and IBM 6546
Installed XGA206; please restart the system; ok; system closes down, tries 
to restart, but "general protection error"!
Powered off; and on again; got the menu (safe mode pre-selected); selected 
normal instead; system came up without a hitch in 640x480x16.
Display, Settings says:
XGA2.drv      4.06.98
+XGA2.vxd   4.06.98
  +VMM32.vxd (vdd.vxd)
  +VMM32.vxd (vflatd.vxd)

I/O range : 03B0 - 03BB
I/O range : 03C0 - 03DF
Mem range : 000A0000 - 000AFFFF
Mem range : 000B8000 - 000BFFFF

Suddenly desktop-icons turn black when double-clicked. System feels 
unstable. I try to go into Systems, but "error in desk.cpl" and exit. Try to 
start Explorer : "Error starting explorer" and exit.
Start, exit, restart : system closes down, tries to restart, but "general 
protection error"!
Powered off; and on again; got the menu (safe mode pre-selected); selected 
normal instead and suddenly a full, slow memcount occurs (I normally have a 
fast check). But system starts up fine otherwise in 640x480x16.

Trying to change into anything other than 640x480x16 triggers a restart , 
followed by a "general protection error" upon restarting.

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

So, not a very great succes.

Deleted the following:
INF/OTHER/MCABaseXGA206.inf
INF/drvdata.bin
INF/drvidx/bin
INF/msdisp.pnf
SYSTEM/XGA2.vxd
SYSTEM/XGA2.drv
Re-installed the stock-XGA driver and all seems fine now.

It's late, more tomorrow.

HTTH
-- 
Jelte


0
JWR
5/10/2006 9:13:29 PM
Hi Jelte,

> > JWR's XGA arrived in best condition. Tests can resume.
>
> Great!

The video quality of the XGA is great, it surprised me. It is even better
than XGA-2 in VGA modes. Back then, monitors were not as good as now, so a
strong and powerful video signal promised a quality. Indeed, we owe
something to this great card, though the interlaced mode and the lowly 60 Hz
are technically hardly justifiable.


> Installed XGA206; please restart the system; ok; system closes down, tries
> to restart, but "general protection error"!

I tested today in the evening with the build from May 7, 2006 and your XGA
in Mod. 77 / Bermuda, however, without any protection errors. So much for
the good news.

No exceptions or protection errors here, but also no expected results.
Display modes can be selected, the colors depth + resolution combinations
work, but a selected mode cannot be set. It falls back to the 640x480 with
16 colors, which is the generic VGA driver. XGA still has some problem there
in 206.

I observed strange things in Windows. I had an XGA-2 in this machine and
W98SE installed initially the Windows XGA driver on the XGA-2 node, it did
not create an XGA node with the *PNP090C designation. After a few trials, I
removed the device, and let Windows detect the graphics card with Hardware
to create the node. It did so, but installed the XGA206 driver, because it
was already indexed and had a newer date. I cleaned up the INF and BIN
stuff, again safe mode, reinstall and so on, until I observed that there
were two "IBM XGA MCA" entries in the device tree. Cleaned up that too.

Certain things happen because the driver cannot set the mode, it rejects it
for some reason. But it does not crash, at least not here, on this machine.
It just shuts down, and this may be the hint - perhaps W98SE cannot
sometimes shutdown on Mod. 90.


> Display, Settings says:
> XGA2.drv      4.06.98
> +XGA2.vxd   4.06.98

4.06.98 are our version numbers (06 for 98).


> I try to go into Systems, but "error in desk.cpl" and exit.

I got that too. Safe mode helps.


> Deleted the following:
> INF/OTHER/MCABaseXGA206.inf
> INF/drvdata.bin
> INF/drvidx/bin
> INF/msdisp.pnf
> SYSTEM/XGA2.vxd
> SYSTEM/XGA2.drv

That's a good cleanup.


> It's late, more tomorrow.

No need to continue, better wait for the fix. In the worst case, I'll have
to run the debugger over the null-modem line.




0
UZnal
5/10/2006 11:06:07 PM
Hi �nal,

<<SNIP>>

> Certain things happen because the driver cannot set the mode, it rejects
> it for some reason. But it does not crash, at least not here, on this
> machine.
> It just shuts down, and this may be the hint - perhaps W98SE cannot
> sometimes shutdown on Mod. 90.

Not just sometimes, never. W98 obviously cannot do a software shutdown on 
the mod 90. It always ends with the screen "You may shut down the system 
now" and waits ad infinitum.

<<SNIP>>

>
> That's a good cleanup.
>

Checked the registry just now and I can't find anything related to XGA206 
anymore. Reinstalling XGA has removed it completely.

> No need to continue, better wait for the fix. In the worst case, I'll have
> to run the debugger over the null-modem line.

Will do, good luck!

-- 
Jelte



0
JWR
5/11/2006 9:33:28 AM
UZ, remember the XGA can accept a clock over the BVE....

Just what frequency would make sense and howinthehell do we create it?

UZnal wrote:
> though the interlaced mode and the lowly 60 Hz are technically hardly justifiable.
0
Louis
5/11/2006 11:03:23 AM
> Not just sometimes, never. W98 obviously cannot do a software shutdown on
> the mod 90. It always ends with the screen "You may shut down the system
> now" and waits ad infinitum.

That's OK, it is the case with the "older" computers. In case of
driver/device XGA/XGA206 conflicts in W98SE, the best is to cleanup the
INF/BIN/PNF part, remove the device from the device tree, and let Windows
detect it automatically. That should restore the system to a consistent
state again.




0
UZnal
5/11/2006 2:50:55 PM
> UZ, remember the XGA can accept a clock over the BVE....

According to the techref, you cannot program the pixel rate. You have to
work with the available fixed rates, but there are no exact specs in the
techref. In this case, you start reading the XGA mode settings and try to
find out the values you need and their relations to a specific mode.

It is hard to believe that such an advanced card for its time, could have
only supported 60 Hz and 43 Hz interlaced. Perhaps it was just hard- or
softwired to do so.

> Just what frequency would make sense and howinthehell do we create it?

Take what we have, perhaps create new mode settings with the 1024x768 clock,
it is supposed to provide 45 Mhz pixel rate.




0
UZnal
5/11/2006 3:02:43 PM
Hum, I wonder about the windows protection error. While you may have up 
to eight XGA in a system, there can be only one in VGA mode. So if you 
switch an XGA into VGA mode, you must ensure that no other VGA is active 
in the system, otherwise the system might crash due to the I/O conflicts.

Is two instances of the driver about the same as XGA and VGA?

UZnal wrote:
>> Not just sometimes, never. W98 obviously cannot do a software shutdown on
>> the mod 90. It always ends with the screen "You may shut down the system
>> now" and waits ad infinitum.
> 
> That's OK, it is the case with the "older" computers. In case of
> driver/device XGA/XGA206 conflicts in W98SE, the best is to cleanup the
> INF/BIN/PNF part, remove the device from the device tree, and let Windows
> detect it automatically. That should restore the system to a consistent
> state again.
> 
> 
> 
> 
0
Louis
5/11/2006 3:47:12 PM
Sprite, obey your thirst! (American soft drink)

UZ, are you using the hardware sprite under Windows?

Louis Ohland wrote:
> Hum, I wonder about the windows protection error. While you may have up 
> to eight XGA in a system, there can be only one in VGA mode. So if you 
> switch an XGA into VGA mode, you must ensure that no other VGA is active 
> in the system, otherwise the system might crash due to the I/O conflicts.
> 
> Is two instances of the driver about the same as XGA and VGA?
> 
> UZnal wrote:
>>> Not just sometimes, never. W98 obviously cannot do a software 
>>> shutdown on
>>> the mod 90. It always ends with the screen "You may shut down the system
>>> now" and waits ad infinitum.
>>
>> That's OK, it is the case with the "older" computers. In case of
>> driver/device XGA/XGA206 conflicts in W98SE, the best is to cleanup the
>> INF/BIN/PNF part, remove the device from the device tree, and let Windows
>> detect it automatically. That should restore the system to a consistent
>> state again.
>>
>>
>>
>>
0
Louis
5/11/2006 3:54:24 PM
XGA registers should not be accessed while in VGA mode
VGA registers should not be accessed wile in XGA mode

Louis Ohland wrote:
> Hum, I wonder about the windows protection error. While you may have up 
> to eight XGA in a system, there can be only one in VGA mode. So if you 
> switch an XGA into VGA mode, you must ensure that no other VGA is active 
> in the system, otherwise the system might crash due to the I/O conflicts.
> 
> Is two instances of the driver about the same as XGA and VGA?
> 
> UZnal wrote:
>>> Not just sometimes, never. W98 obviously cannot do a software 
>>> shutdown on
>>> the mod 90. It always ends with the screen "You may shut down the system
>>> now" and waits ad infinitum.
>>
>> That's OK, it is the case with the "older" computers. In case of
>> driver/device XGA/XGA206 conflicts in W98SE, the best is to cleanup the
>> INF/BIN/PNF part, remove the device from the device tree, and let Windows
>> detect it automatically. That should restore the system to a consistent
>> state again.
>>
>>
>>
>>
0
Louis
5/11/2006 3:56:30 PM
OS/2 DEVICE DRIVER FOR IBM XGA
Build D.036

http://greyghost.dyndns.org/pccbbs/options/xga.exe

SUPPORTED RESOLUTIONS

This video driver supports these resolutions and
color depths:

                         Number of    Video Memory
         Resolutions      Colors        Required

          640 x 480         16            512k
          1024 x 768        16            512k
          1280 x 960        16            1 MB
          1280 x 1024       16            1 MB
          1360 x 1024       16            1 MB

          640 x 480         256           1 MB
          800 x 600         256           XGA-2 only
          1024 x 768        256           1 MB

          640 x 480         65536         XGA-2 only
          800 x 600         65536         XGA-2 only

I wondered about Clock Select 1 and 2, along with the reserved bits...
0
Louis
5/11/2006 4:37:45 PM
Hi Louis,

"Louis Ohland" <ohland@charter.net> schreef in bericht 
news:vLJ8g.99$My4.82@fe04.lga...
> OS/2 DEVICE DRIVER FOR IBM XGA
> Build D.036
>
> http://greyghost.dyndns.org/pccbbs/options/xga.exe
>
> SUPPORTED RESOLUTIONS
>
> This video driver supports these resolutions and
> color depths:
>
>                         Number of    Video Memory
>         Resolutions      Colors        Required
>
>          640 x 480         16            512k
>          1024 x 768        16            512k
>          1280 x 960        16            1 MB
>          1280 x 1024       16            1 MB
>          1360 x 1024       16            1 MB
>
>          640 x 480         256           1 MB
>          800 x 600         256           XGA-2 only
>          1024 x 768        256           1 MB
>
>          640 x 480         65536         XGA-2 only
>          800 x 600         65536         XGA-2 only
>
> I wondered about Clock Select 1 and 2, along with the reserved bits...

Talk about setting a target for �nal!
I guess it would be *very* helpful if you/we could dig up the sourcecode for 
this driver.

-- 
Jelte


0
JWR
5/11/2006 7:15:13 PM
Hi UZnal,

Didn't you ask sometime ago for 2 XGA-'s?
If so, I can send you another one; I don't use it and you can have it, if
you want it.
BIOS date is 27/05/91

George


"UZnal" <unalz-at-mail333-dot-com> schreef in bericht
news:446214ed$0$3882$91cee783@newsreader01.highway.telekom.at...
> JWR's XGA arrived in best condition. Tests can resume.
>
>
>
>
>
>
>
>
>
>


0
George
5/11/2006 8:40:31 PM
> Hum, I wonder about the windows protection error. While you may have up
> to eight XGA in a system, there can be only one in VGA mode. So if you
> switch an XGA into VGA mode, you must ensure that no other VGA is active
> in the system, otherwise the system might crash due to the I/O conflicts.

Well observed. To avoid conflicts, you have this faciltiy called aperture
which is well suited for a protected mode application. Windows must stay
compatible with real mode, and for this reason, the driver is using a 64 KB
window into the memory, and disabling all other XGA/XGA-2 cards.

It is a loose screw somewhere in the driver. I get no protection errors, no
crashes but also no XGA. I have to try it on Win95.

> Is two instances of the driver about the same as XGA and VGA?

The driver manages only the XGA modes, switching to VGA modes is through Int
10h. It provides the VESA interface also.


> UZ, are you using the hardware sprite under Windows?

The sprite is the hardware cursor and it is used.


> XGA registers should not be accessed while in VGA mode

To enter a hi-res XGA mode from VGA, you must access these registers.


> VGA registers should not be accessed wile in XGA mode

You cannot because the VGA ports are not available. See topmost note.




0
UZnal
5/11/2006 10:16:40 PM
> > OS/2 DEVICE DRIVER FOR IBM XGA
> > Build D.036

> >          1280 x 960        16            1 MB
> >          1280 x 1024       16            1 MB
> >          1360 x 1024       16            1 MB

Aren't these "XGA-2 only" modes?

> > I wondered about Clock Select 1 and 2, along with the reserved bits...

We will need a simple DOS program to play with. That will require time and
patience.

> Talk about setting a target for �nal!
> I guess it would be *very* helpful if you/we could dig up the sourcecode
for
> this driver.

We must repair the engine of Mr. Spock before. OS/2 would be certainly fun
to play with.






0
UZnal
5/11/2006 10:27:06 PM
UZ, the race must be made stronger. Is there a way to force the system 
to use XGA only? How can we side step the teeny 64KB window for 
something a lot bigger?

UZnal wrote:
> Well observed. To avoid conflicts, you have this faciltiy called aperture
> which is well suited for a protected mode application. Windows must stay
> compatible with real mode, and for this reason, the driver is using a 64 KB
> window into the memory, and disabling all other XGA/XGA-2 cards.
0
Louis
5/11/2006 10:55:15 PM
UZ, this is a cut n paste from an IBM file. I wondered about the trans 
1024x768 modes.

UZnal wrote:
>>> OS/2 DEVICE DRIVER FOR IBM XGA
>>> Build D.036
> 
>>>          1280 x 960        16            1 MB
>>>          1280 x 1024       16            1 MB
>>>          1360 x 1024       16            1 MB
> 
> Aren't these "XGA-2 only" modes?
0
Louis
5/11/2006 10:58:00 PM
UZ, what is the secret formula to determine pixel rate?

Must be horizontal size by vertical size by color depth by frequency or 
something like that...

UZnal wrote:
> According to the techref, you cannot program the pixel rate.
> 45 Mhz pixel rate.
0
Louis
5/12/2006 1:12:44 AM
Hi George,

> Didn't you ask sometime ago for 2 XGA-'s?
> If so, I can send you another one; I don't use it and you can have it, if
> you want it.
> BIOS date is 27/05/91

I'd be certainly glad to have one, that would make more sense.
Postcard address comes to you offline. Thank you !!!




0
UZnal
5/12/2006 3:56:40 PM
> UZ, the race must be made stronger. Is there a way to force the system
> to use XGA only?

Sure, when the driver works. I am optimistic....;)

> How can we side step the teeny 64KB window for  something a lot bigger?

No way, it must stay compatible with real mode apps. This is Windows.


> UZ, what is the secret formula to determine pixel rate?
>
> Must be horizontal size by vertical size by color depth by frequency or
> something like that...

Later, I must go out now. There is a relation between line rate and pixel
rate.









0
UZnal
5/12/2006 4:39:28 PM
Waiting... for the final solution to strengthen the strain...

As the immortal Pink Floyd has sung, you must be strong, or the 
untermensch O/S will pollute the purity of protected mode.

Let me guess, are all MS-Doze apps real mode, or god forbid, did M$ 
virtualize the MS-DOS apps? What happens when a real mode app is loaded 
in protected mode?

I wandt performance, not compatibility...

UZnal wrote:
> No way, it must stay compatible with real mode apps. This is Windows.
0
Louis
5/12/2006 5:04:02 PM
Hi �nal,

> I'd be certainly glad to have one, that would make more sense.

It is always good to try out different hardware of the same sort. That way 
you can (hope to) eliminate item-specific quirks.

So, I'm not offended, but truly interested : in what way does my XGA _not_ 
make sense?
It wasn't a pull from a working set and I never got around to testing it 
before I sent it to you : I wasn't even aware that I had this card until I 
looked through my stuff when the question for an XGA-card came up.

-- 
Jelte


0
JWR
5/12/2006 6:43:54 PM
Hi!

> What happens when a real mode app is loaded
> in protected mode?

Probably something involving the CPU's V86 mode.

> I wandt performance, not compatibility...

You may get neither, given Microsoft's seeming attitude about MCA...

William

0
wm_walsh
5/12/2006 7:44:44 PM
Hi Jelte,

> So, I'm not offended, but truly interested : in what way does my XGA _not_
> make sense?

Actually, your XGA makes currently the most sense. It helped isolate the
problem and localize the trouble spot in the code. I am indeed grateful for
your support.

Another XGA would also make sense in the long term, but that is all about
"making sense".

> It wasn't a pull from a working set and I never got around to testing it
> before I sent it to you : I wasn't even aware that I had this card until I
> looked through my stuff when the question for an XGA-card came up.

It is in perfect shape and has a very good VGA video quality. I can't really
complain.





0
UZnal
5/13/2006 12:11:46 AM
> > UZ, what is the secret formula to determine pixel rate?
> >
> > Must be horizontal size by vertical size by color depth by frequency or
> > something like that...

The pixel rate - or PEL rate, dot rate, video bandwidth - defines the number
of dots per second the video system can generate. The line rate - or
horizontal frequency, or horizontal scan rate - defines how many lines per
second the monitor can display. Note, that it is lines, and not yet dots per
line.

Take the VGA: the pixel rate is 25.175 MHz, that is 25,175,000 dots per
second. A typical VGA monitor has a horiz scan rate of 31.5 kHz, that is
31,500 lines per second. Dividing the dot rate by the horiz freq results in
800 dots per line.

The CRT Controller values are defined in terms of characters, where a
character is 8 dots. For the VGA in 640x480, we have then 100 characters per
line (800/8), this is Horizontal Total. 100 chars are amount of time to
complete one horiz scan. Only 80 of them are displayed, the rest are used
for retrace and overscan.

If the line rate has been given, you can calculate the necessary pixel rate
for the needed modes. If the pixel rate has been given, you can adapt the
register timings to the line rate. The formula is to calculate the CRTC
register timings.






0
UZnal
5/13/2006 12:12:24 AM
> Let me guess, are all MS-Doze apps real mode, or god forbid, did M$
> virtualize the MS-DOS apps? What happens when a real mode app is loaded
> in protected mode?

We talk about this in the video (buffer) and XGA context. You can run real
mode, i.e. DOS apps, in Windows, and the assumptions those apps make must be
fullfilled. Many DOS apps use this 64K window, and very few perhaps expect
the 1M aperture. Working with 64K aperture inside and outside simplifies the
drivers. There are some other rules, a driver must reserve a 64K, or at
least 32K, offscreen memory, to be used when a DOS app runs in a window.
This range is then just another bank.

> I wandt performance, not compatibility...

I would trade a bit of the performance for the compatibility.






0
UZnal
5/13/2006 12:12:35 AM
Reply:

Similar Artilces:

IBM RS/6000 MCA SCSI Adapter vs. IBM PS/2 MCA SCSI Adapter
Hello, I found in my MCA repository a (seems to be) functionnal RS/6000 32bit SCSI Adapter. In my '80, I have a (what seems to be, again) original PS/2 SCSI Adapter, w/o cache. I found also a w/cache, but is faulty. May I get better performance, any improvement of any kind trying this RS/6000 Adapter, or is it not going to run at all...or will it be worse ? I have a 0661 type HDD, 320 MB in the SCSI Chain. Thanks ! Hum, as I see after some searches, it is RS/6000-only adapter, no ADF, not useable in a PS/2...Can someone confirm this ? The Godfather wrote: > Hello,...

Auctions (2): Three IBM PS2 Graphics Adapters 8514/A *AND* IBM MicroChannel 4869 External 5-1/4" Disk Drive (360K)
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=270123874305 Starting bid: US $0.99 End time: May-31-07 16:43:43 PDT (6 days 3 hours) Ships to: United States Item location: Surprise, Arizona, United States IBM PS/2 MicroChannel CAD Workstation Graphics Cards Model 8514/A listing is for a quantity of three shipped for a single price Also by same seller : http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=270123854097 Starting bid: US $0.99 End time: May-31-07 15:51:52 PDT (6 days 3 hours) Includes the drive sled, the MCA adapter card and ribbon cables for inside the box (as shown in the picture). No affiliation PS William, WCT is mentioned in both auctions. -- Jelte, admirer of the letter of IBM with blue Ishiki The information contained in this post is copyright the poster and specifically may not be published in, or used by http://www.jlaforums.com ...

IBM 3270 MCA Emulation Adapter
Hi there, I have been searching high and low for software supporting the IBM 3270 Emulation Adapter in my 8570. I'm in the process of salvaging an old scrapped 3174-11L Estrablishment Controller from the company I work for and thought this would be the cue for putting the 3270 adapter to some use...just for the fun of it. Anybody got any pointers to the drivers etc. needed? Thanks in advance! Best regards, Mads Kristoffersen Aarhus, Denmark On Apr 30, 3:02 pm, "Mads Ulrik Kristoffersen" <mad...@image.dk> wrote: > I have been searching high and low for software supporting the IBM 3270 > Emulation Adapter in my 8570. I'm in the process of salvaging an old > scrapped 3174-11L Estrablishment Controller from the company I work for and > thought this would be the cue for putting the 3270 adapter to some > use...just for the fun of it. Anybody got any pointers to the drivers etc. > needed? The "driver" is integrated into the software in this case, you do need the ADF file for the adapter in your 8570, but you probably already have that set up. Which software to use is a function of what operating system you have installed and a bit of personal preference. If you like the IBM stuff, you're looking for a copy of Personal Communications/3270, which is generally called PCOMM for short. I'm running version 5.6 on my Windows XP machine, which is not the latest version. If I'm remember...

IBM MCA FWSR Raid adapter/A with cables auction
From Canada, I've bought from him before, first class. If you wandt a Cheetah and cables, get on this... http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3071245734 Jan-18-04 02:47:03 PST -- Reply to me at louis little punctuation mark ohland with the same ISP He's also selling the ever-popular IBM Lan Adapter/A. http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3071241727 I'd been watching the Cheetah, but since you mentioned it I placed a marker bid. No sniping, please? -John the Requester He also has a Server 330 hot-swap tray up. htt...

W98SE hates two IBM F/W adapters
I was wondering why98se was hanging in restarting. Time for a Passplay. -- Reply to ohland@charter.net Louis Ohland wrote: > Time for a Passplay. Time for a operating system. SCNR *g* Saskia -- Remove ".KEIN.ROASTBEEF" from my address to send mail "Louis Ohland" <nullnvoid@charter.net> wrote in message news:433047D2.200D3B15@charter.net... > I was wondering why98se was hanging in restarting. > > Time for a Passplay. The old mis-understanding of the Win9x developers that MCA is the predecessor of PCI and handles multiple adapters using the same IRQ.The drivers do not understand this, or were you musing aloud again? -- Regards, Tim Clarke (a.k.a. WBST) Er, you are speaking of ONE fast wide in seperate mode. I had planar corvette plus a corvette in a slot. System properly identified them and got the resources right, but it hangs after that. "Safe" mode. wm_walsh@hotmail.com wrote: > > Hi! > > > I was wondering why98se was hanging in restarting. > > That's odd. When I ran my F/W in separate bus mode, Win98 stayed in > MS-DOS compatbility mode and put a "!" next to the adapter entry in > Device Manager. > > William -- Reply to ohland@charter.net Oh, are you referring to it hanging if one of the adapters is set to seperate? I am not positive that running both in combined will automagically fix the saf...

Dutch IBM MCA PS2-stuf for sale in the Netherlands
Hoi, Ik wil mijn IBM MCA PS2 'verzameling' wel kwijt aan een serieuze verzamelaar. Stuur even een mailtje en ik mail je de lijst van de spullen die ik heb terug. groetjes, Bert ...

IBM PS2 P70 problems with scsi and etherlink mca card...
Hello to the group and thanks in advance to all the fans.=20 I recently decided to make some projects with p70 starting from documentati= on found in the network and for which I thank the respective owners.=20 The idea is to install win95 and "sail" with a ibm 8573-061 of 90.=20 Starting from a basic configuration working (386DX 20MHz, 8Mb RAM, 60Mb har= d disk, floppy disk adapter, Win3.1 and dos6.2), I'm trying to install a sc= si card mcs-700 (connected to a hd 1gb ibm dpes31080) and a network card 3c= 529-tp.=20 I can not try the 2 cards mca as recently purchased on the net.=20 To install the scsi card, I disconnected the old hd 60mb, the old data cabl= e, insert the card scsi mcs-700 in the riser card (16 or 32 bit) connect po= wer and data cable 50pin to 'hd ibm (set id of 0 or 1, correct?). Restart t= he computer with the reference disk (with several *. Adf) the screen remain= s black, the only light comes on the power supply. The hd turn, would seem = to look for something for a couple of seconds, but then stops. Then nothing= ram test, do not boot from the floppy or normal startup dos. No bios-error= ..=20 Not being certain that the hd or the scsi card are working, I decided to te= st the network card. When I insert the network card 3c529-tp in the riser c= ard (16 or 32 bit) and reboot the pc with the reference disk (with several = *. Adf) I get the same results as installing the scsi card With both cards get the s...

Auction: IBM 74G0865 MCA Etherstreamer MC 32 Adapter
>http://cgi.ebay.com/IBM-74G0865-MCA-Etherstreamer-MC-32-Adapter_W0QQitemZ9705254870QQcategoryZ11182QQrdZ1QQcmdZViewItem< End time: Mar-31-06 18:24:35 PST ...

REQ: Hardware adapter info: Use C64 Keyboard on IBM
I've got a dead C64 that I wanted to adapt over to a mini-itx IBM mobo and use VICE on it. I'd like to use the original C64 keyboard with the new PC; however that would require a custom hardware adapter. One person on mini-itx.com adapted an old SX-64 in this manner and uses the original keyboard. He supposedly developed just such an adapter, and promised to make the hardware details available. Like so many other "orphaned" Internet projects, he appears to have lost interest and no longer shows that info on his web pages. Won't answer email inquiries, either. Has an...

FS: IBM 5250 Emulation PCMCIA Twinax Adapter (FRU 92G5361), IBM 5250 Express PCI Adapter and Cable (PN 88H0210)
Hi, For sale on Ebay ( IBM 5250 Emulation PCMCIA Twinax Adapter (FRU 92G5361): http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=5734214062 IBM 5250 Express PCI ADAPTER and Cable (PN 88H0210) Twinax: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=5734387307 also IBM 3450-001 QIC 1000 Tape Drive (PN 74G8630) SCSI: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=5142103666 Thanks for looking ...

Search IBM PS2/80 NIC MCA ethernet 10/100
Hi, I search for an MCA NIC for this computer Live in France Debian User <test@test.org> wrote in message news:<pan.2004.12.02.19.37.26.613291@test.org>... > I search for an MCA NIC for this computer If you are willing to settle for a 10Mbps MCA NIC, you have several to choose from, IBM and non-IBM -- some are AUI only (or 10Base2 only), some support two kinds of connections, some support all three. If your 8580 does not have a processor upgrade (16, 20 or 25MHz 80386), I'd stick with a 10Mbps NIC -- the Olicom NIC is the most common 10/100 MCA NIC, but eve...

Auction: IBM Image Adapter/A MCA Microchannel Hi-Resolution Card
>http://cgi.ebay.com/IBM-Image-Adapter-A-MCA-Microchannel-Hi-Resolution-Card_W0QQitemZ8701564998QQcategoryZ74946QQrdZ1QQcmdZViewItem< Ends Oct-07-05 21:32:44 PDT -- Reply to ohland@charter.net ...

Auction: IBM PS2 77 9577 Micro Channel MCA Microchannel
<http://cgi.ebay.com/IBM-PS2-77-9577-Micro-Channel-MCA-Microchannel_W0QQitemZ110070238054QQihZ001QQcategoryZ74946QQssPageNameZWDVWQQrdZ1QQcmdZViewItem> End time: Dec-23-06 19:52:53 PST Something good from Wisconsin. Bermuda board. Hi! > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=110070238054 > Something good from Wisconsin. Bermuda board. It's *so* yellow. I wonder if that's all sun-related? (On another note, I unfolded the paper tray on a Color LaserJet 2500n the other day and found it had yellowed. I consider that odd, since this printer has never seen the sunlight...do fluorescent lights yellow stuff too?) Also worth noting are the missing MCA slot covers. I wonder what was in them, if anything... William the Curious wm_walsh@hotmail.com wrote: > Hi! > >> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=110070238054 > >> Something good from Wisconsin. Bermuda board. > > It's *so* yellow. I wonder if that's all sun-related? (On another note, > I unfolded the paper tray on a Color LaserJet 2500n the other day and > found it had yellowed. I consider that odd, since this printer has > never seen the sunlight...do fluorescent lights yellow stuff too?) As far as I know, no. Most likely heat related from the fuser, less probably chemical from the paper. wm_walsh@hotmail.com wrote: > do fluorescent lights yellow stuff too?) Yes. Or so I...

Auction: IBM PS2 Internal PCMCIA Card Adapter
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=280118973512 Starting bid: GBP 0.99 (Approximately US $1.96) End time: May-29-07 01:23:01 PDT (2 days 13 hours) Ships to: United Kingdom Item location: Reading, United Kingdom Here we have a genuine IBM PS2 Internal PCMCIA Card adapter as pictured. Card only - sold as seen. Came from an office clearance but I don't have the hardware to use it. No affiliation For the PS/2E -- Jelte, admirer of the letter of IBM with blue Ishiki The information contained in this post is copyright the poster and specifically may not be published in, or used by http://www.jlaforums.com ...

Auction: IBM PS2 Model 70 Luggable -
http://search.ebay.com/200206566833 End time: Mar-16-08 12:23:08 PDT Colorado ...

[auction US] Lot of 24 IBM RS/6000 RS6000 MCA adapters
>http://cgi.benl.ebay.be/ws/eBayISAPI.dll?ViewItem&rd=1&item=230090916042&ss PageName=STRK:MEWA:IT&ih=013< Fairly common cards, I think. But a big lot. Regards, Alvin. Alvin Andries wrote: >> http://cgi.benl.ebay.be/ws/eBayISAPI.dll?ViewItem&rd=1&item=230090916042&ss > PageName=STRK:MEWA:IT&ih=013< > > Fairly common cards, I think. But a big lot. > > Regards, > Alvin. > > If anyone jumps on this, I need another 9-K. ...

Auction: vintage ibm ps2 microchannel mca computer mod 90 486
>http://cgi.ebay.com/vintage-ibm-ps2-microchannel-mca-computer-mod-90-486_W0QQitemZ8784004885QQcategoryZ51096QQrdZ1QQcmdZViewItem< End time: Mar-26-06 14:57:08 PST ..it has a XGA video .it has a;180 mb ;hard drive.with OS2 3.0 and WINDOWS 3.1 and IBM DOS on it, all three,,it has 16MB RAM,, also a 1.44 MB floppy drive .also it has a 486 33 mhz processor in it. Ed. My guess is a 160MB SCSI drive, a K complex, and a Spock with cache. Not sure what level, one, two, or three can, or SCSI BIOS. I could not bring enough detail out of the image in order to detect the particulars. Both memory risers and the riser guide are installed. The seller has a 77 up as well. The descriptions are similar, so the complex might not be a 486DX-33. Louis Ohland wrote: > >http://cgi.ebay.com/vintage-ibm-ps2-microchannel-mca-computer-mod-90-486_W0QQitemZ8784004885QQcategoryZ51096QQrdZ1QQcmdZViewItem< > > End time: Mar-26-06 14:57:08 PST > > .it has a XGA video .it has a;180 mb ;hard drive.with OS2 3.0 and > WINDOWS 3.1 and IBM DOS on it, all three,,it has 16MB RAM,, also a 1.44 > MB floppy drive .also it has a 486 33 mhz processor in it. > > Ed. My guess is a 160MB SCSI drive, a K complex, and a Spock with cache. > Not sure what level, one, two, or three can, or SCSI BIOS. I could not > bring enough detail out of the image in order to detect the particulars. > > Both memory risers and the riser guide...

Auction: IBM PS2 Model 70 Luggable -
P70, with a good starting price: http://search.ebay.com/200206566833 $5.00 starting bid. Ends Mar-16-2008, 12:23:08 PDT (2 days, 3 hours). Didn't see any shipping price. Ships to the US only. Located in Nederland, Colorado USA. No affiliation. William ...

Auc-tion: IBM PS2 77 9577 Micro Channel MCA Microchannel
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=110051463507 End time: Nov-07-06 19:45:51 PST (4 days 16 hours) Shipping costs: Not specified Ships to: United States Item location: Webster, Wisconsin, United States === This is an older IBM Personal Computer. It is one of IBM's Micro Channel Architecture PC, model: 9577. It has 8mb RAM, XGA Video, SCSI card and hard disk, and a 2.88 disk drive. The unit seems to work very well, and it has Windows 95 installed on it. So if your looking for a vintage piece of computer history, this would fit that catagory. No software comes with this, except for the Windows 95 that is intalled in it, and you will have to reinstall your own licensed operating system. I will ship to the lower 48 states, and no international shipping. If you have any questions, please feel free to contact me. Thanks for looking. === PS/2 77 486DX2 Looks clean; slots 2-5 emptied. No affiliation -- Jelte Hi Jelte, > "...model: 9577. ...XGA Video, SCSI card..." > PS/2 77 486DX2 > Looks clean; slots 2-5 emptied. Bermuda planar, as expected by the badge marking. Although a Lacuna could presumably have an XGA adapter installed to supplant the planar S3 video, this is an XGA-2 adapter typical on the Bermudas. The SCSI is planar, not adapter based (not correcting you, but the seller). David David@IBMMuseum.com ...

Auction: IBM MCA SCSI/A Microchannel SCSI Adapter w/512K Cache
http://search.ebay.com/310005789020 End time: Dec-13-07 19:36:17 PST Three can Spock, includes internal flat cable from a 95. ...

Auction: vintage ibm 1.2 mb external floppy drive mca adapter
Caution! this is a 360K drive AND 360K adapter, along with the Model 70 sled. http://search.ebay.com/110104477767 End time: Mar-22-07 09:52:39 PDT ...

Auction: Vintage IBM PS2 PC Hardware Maintenance Manual Models 25
<http://cgi.ebay.com/Vintage-IBM-PS2-PC-Hardware-Maintenance-Manual_W0QQitemZ270078671271QQihZ017QQcategoryZ74946QQrdZ1QQcmdZViewItem> End time: Jan-18-07 17:11:07 PST These are good for quick service to the systems. I am electric, electric eye... ...

Auction: (3)IBM Future Domain Bootable SCSI Adapter for MCA PS/2
http://search.ebay.com/310031211896 End time: Mar-18-08 16:50:18 PDT Description: (3) IBM Future Domain MCA Microchannel SCSI Controllers for PS/2 - IBM P/N 71G3575 - Future Domain 18C50 SCSI controller - includes 3-device SCSI cable (FRU 71G2558) - boot BIOS ver.1.01 - HD50 external connector, 50-pin internal ...

IBM MCA Fast Wide RAID Adapter Passplay auction (Swedish militia alert!)
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2757867715 Oct-11-03 09:56:08 PDT Looks like RAID cables included? -- Reply to me at louis little punctuation mark ohland with the same ISP ...

Web resources about - W98SE MCA Adapters - comp.sys.ibm.ps2.hardware

Adapter - Wikipedia, the free encyclopedia
An electrical adapter may enable connection of a socket used in one region to a plug used in another by offering connections for the disparate ...

AC Adapter - Replacement Laptop AC Adapters
Online shopping for laptop ac adapters at the best price.Buy cheap ac adapters for your laptop computer.

M3 Adapter
Update the firmware of the M3i Zero GMP-Z003 card to support running in new 3DS (Ver. 4.1.0-8E, Ver. 4.1.0-8J, Ver. 4.1.0-8U) and DSi (Ver 1.4.4E, ...

Bluetooth RFCOMM / SDP connection to a RS232 adapter in android
The Android API provides examples of using listenUsingRfcommWithServiceRecord() to set up a socket and createRfcommSocketToServiceRecord() to ...

Mac App Store - Power Adapter Alarm
Get Power Adapter Alarm on the Mac App Store. See screenshots and ratings, and read customer reviews.

Apple USB Power Adapters - Flickr - Photo Sharing!
Comparison of various Apple USB power adapters for iPhone and iPod.

Miracast Wireless Display with Windows 8.1 - Stream PC to TV without Adapters! - YouTube
In this video, I demo native Miracast wireless display support on Windows 8.1 with Lenovo X1 Carbon Touch and Samsung Smart TV. You can use Miracast ...

Apple recalls more than a decade of power adapters due to risk of electric shock
Tech giant instigates massive international recall of power point adapters due to risk of electric shock.

Apple's iPhone 5 'Lightning' adapters will retail for $35 and $45, not available until October
Apple's decision to change the iPhone 5's dock connector means you'll need an adapter or two.

Apple slammed over power adapter recall, 'incidents' may be under-reported
Consumer group Choice calls for more information on the 'incidents' exposing consumers to electric shock, as more customers come forward detailing ...

Resources last updated: 3/3/2016 6:42:32 AM