Discussion:
W98SE MCA Adapters
(too old to reply)
UZnal
2006-03-24 20:08:30 UTC
Permalink
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=***@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.
UZnal
2006-03-25 13:06:14 UTC
Permalink
Post by UZnal
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)
Louis Ohland
2006-03-25 14:23:41 UTC
Permalink
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?
Post by UZnal
Post by UZnal
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).
Louis Ohland
2006-03-25 15:53:48 UTC
Permalink
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?
Post by UZnal
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)
Louis Ohland
2006-03-25 15:54:38 UTC
Permalink
Odd, does the AGX exist in NT4 as well?
Post by Louis Ohland
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?
Post by UZnal
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)
Louis Ohland
2006-03-25 15:59:00 UTC
Permalink
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.
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?
Post by UZnal
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)
Louis Ohland
2006-03-25 16:10:56 UTC
Permalink
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.
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.
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?
Post by UZnal
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)
UZnal
2006-03-25 18:33:21 UTC
Permalink
Post by Louis Ohland
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.
Post by Louis Ohland
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
Louis Ohland
2006-03-25 20:12:40 UTC
Permalink
The XGA-2 should top out at the 800x600x16. The ethereal 2MB XGA would
top out at the 1024x768x16
Post by Louis Ohland
AGX modes
------------------
MODES\16\640,480
MODES\16\800,600
MODES\16\1024,768
Louis Ohland
2006-03-25 20:46:58 UTC
Permalink
;
; 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) }
;
;
; 800x600 with 8 BPP
; 1024x768 with 8 BPP (non-interlaced)
; 1280x1024 with 8 BPP
;
;
; 800x600 with 16 BPP
; 1024x768 with 16 BPP
The XGA-2 should top out at the 800x600x16. The ethereal 2MB XGA would
top out at the 1024x768x16
Post by Louis Ohland
AGX modes
------------------
MODES\16\640,480
MODES\16\800,600
MODES\16\1024,768
UZnal
2006-03-25 23:08:32 UTC
Permalink
;
; 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)
Charles Lasitter
2006-03-27 09:23:56 UTC
Permalink
On Sun, 26 Mar 2006 00:08:32 +0100, "UZnal" <unalz-at-mail333-dot-com>
Post by UZnal
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 |
+-----------------------------------------+
UZnal
2006-03-27 13:18:46 UTC
Permalink
Post by Charles Lasitter
Post by UZnal
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.
Post by Charles Lasitter
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.
Post by Charles Lasitter
Too bad about the 60Hz.
More hope with an LCD monitor. How good is the combo XGA-2 + LCD ?
Louis Ohland
2006-03-27 13:33:22 UTC
Permalink
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.
Post by UZnal
Post by Charles Lasitter
Post by UZnal
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.
Post by Charles Lasitter
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)
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
;When the XGA is in HiRes mode (such as we're going to do in a minute), the
;VGA registers are not readable.
;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.
;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.
Post by Charles Lasitter
Too bad about the 60Hz.
More hope with an LCD monitor. How good is the combo XGA-2 + LCD ?
UZnal
2006-03-27 21:09:21 UTC
Permalink
Post by Louis Ohland
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!
Post by Louis Ohland
The original XGA with 1MB was "supposed" to support 64k, perhaps with
some sleight of hand, but it was possible.
UZnal
2006-03-28 23:39:21 UTC
Permalink
Post by UZnal
Post by Louis Ohland
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
Post by UZnal
VESA Bios Extensions (VBE) 2.0 are discussed in Richard Wilton
"Programmer's
Post by UZnal
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.
UZnal
2006-03-29 21:36:31 UTC
Permalink
"Extended Graphics Mode Register Settings
3-218 XGA Function- May 7th 1992"

Do we have the other chapters? Sections on XGA-NI ...?
Post by UZnal
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."
Post by UZnal
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)
UZnal
2006-03-29 22:58:41 UTC
Permalink
Post by UZnal
Do we have the other chapters? Sections on XGA-NI ...?
Today is my lucky day, merci google.
Charles Lasitter
2006-03-30 01:10:00 UTC
Permalink
On Thu, 30 Mar 2006 00:58:41 +0200, "UZnal" <unalz-at-mail333-dot-com>
Post by UZnal
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 |
+-----------------------------------------+
UZnal
2006-03-30 21:36:08 UTC
Permalink
Post by Charles Lasitter
Post by UZnal
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.
UZnal
2006-03-31 14:11:13 UTC
Permalink
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.
UZnal
2006-04-01 11:01:36 UTC
Permalink
Post by UZnal
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).
Post by UZnal
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
Post by UZnal
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.
UZnal
2006-04-02 12:32:30 UTC
Permalink
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.
UZnal
2006-04-02 22:26:15 UTC
Permalink
Post by UZnal
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...??
UZnal
2006-04-03 15:06:24 UTC
Permalink
Post by UZnal
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.
David L. Beem
2006-04-03 19:42:46 UTC
Permalink
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
***@IBMMuseum.com
UZnal
2006-04-03 22:15:53 UTC
Permalink
Hi David,
Post by David L. Beem
...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
Post by David L. Beem
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.
Post by David L. Beem
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.
Post by David L. Beem
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.
UZnal
2006-04-06 22:00:02 UTC
Permalink
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.
Louis Ohland
2006-04-06 23:58:51 UTC
Permalink
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?
Post by UZnal
XGA
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.
UZnal
2006-04-07 12:48:00 UTC
Permalink
Post by Louis Ohland
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.
Louis Ohland
2006-04-07 21:30:13 UTC
Permalink
Please, please, PLEASE include support for XGA 1MB, 640x480, 64k if
possible. All Model 90 owners will be very appreciative.
Post by UZnal
Post by Louis Ohland
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.
UZnal
2006-04-08 10:57:42 UTC
Permalink
Post by Louis Ohland
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?
UZnal
2006-04-08 22:14:02 UTC
Permalink
Post by Louis Ohland
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.
Louis Ohland
2006-04-09 12:51:13 UTC
Permalink
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.
Post by UZnal
Post by Louis Ohland
XGA 1MB, 640x480, 64k
XGA: fixed, 640x480 at 16-bpp at 60 Hz. Max 45 Mhz dot rate.
XGA-2: programmable. Max 90 Mhz dot rate.
XGA: 1, 2, 4 and 8 bits per pixel
XGA-2: 1, 2, 4, 8 and 16 bits per pixel
XGA colors: 256 out of 256K colors (18-bit)
XGA-2 colors: 256 out of 16M (24-bit)
XGA: 16-bpp display mode only, no coprocessor support
XGA-2: 16-bpp packed pixel format, full coprocessor support
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
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.
UZnal
2006-04-09 13:41:06 UTC
Permalink
Post by Louis Ohland
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.
Louis Ohland
2006-04-09 18:08:48 UTC
Permalink
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?
Post by UZnal
Post by Louis Ohland
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.
UZnal
2006-04-09 21:14:02 UTC
Permalink
Post by Louis Ohland
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.
Louis Ohland
2006-04-09 22:01:46 UTC
Permalink
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].
Post by UZnal
Post by Louis Ohland
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.
UZnal
2006-04-10 00:03:41 UTC
Permalink
Post by Louis Ohland
UZ, you didn't respond to my triple secret query on those two books.
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....;)
UZnal
2006-04-11 22:41:00 UTC
Permalink
Post by UZnal
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)
Louis Ohland
2006-04-12 12:15:23 UTC
Permalink
Post by UZnal
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.
UZnal
2006-04-12 14:31:14 UTC
Permalink
Post by Louis Ohland
Post by UZnal
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.
Post by Louis Ohland
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)
Louis Ohland
2006-04-12 14:50:12 UTC
Permalink
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?
Post by UZnal
Post by Louis Ohland
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
- 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)
UZnal
2006-04-12 21:27:48 UTC
Permalink
Post by Louis Ohland
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.
UZnal
2006-04-12 23:21:47 UTC
Permalink
Post by UZnal
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.
Louis Ohland
2006-04-12 23:51:06 UTC
Permalink
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.
Post by UZnal
Post by UZnal
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 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.
UZnal
2006-04-13 12:54:12 UTC
Permalink
Post by Louis Ohland
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.
Post by Louis Ohland
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).
UZnal
2006-04-14 13:57:05 UTC
Permalink
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
UZnal
2006-04-16 14:01:42 UTC
Permalink
Post by UZnal
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)
UZnal
2006-04-19 12:54:33 UTC
Permalink
Post by UZnal
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
Louis Ohland
2006-04-19 13:18:33 UTC
Permalink
What M$ systems does this run on? W9x and or NT?
Post by UZnal
Post by UZnal
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
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)
......
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
Daniel Hamilton
2006-04-19 18:43:08 UTC
Permalink
Post by Louis Ohland
What M$ systems does this run on? W9x and or NT?
Being a VXD, it'd be W9x.

--Daniel
Post by Louis Ohland
Post by UZnal
Post by UZnal
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
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)
......
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
Charles Lasitter
2006-04-19 13:44:16 UTC
Permalink
On Wed, 19 Apr 2006 14:54:33 +0200, "UZnal" <unalz-at-mail333-dot-com>
Post by UZnal
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 |
+-----------------------------------------+
UZnal
2006-04-20 00:12:13 UTC
Permalink
Post by Charles Lasitter
Post by UZnal
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.
Post by Charles Lasitter
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 |
+-----------------------------------------+
Louis Ohland
2006-04-20 00:31:50 UTC
Permalink
Is there any chance to get a look at the source code? Or are you
following the Micro$oviet model?
Post by UZnal
Post by Charles Lasitter
Post by UZnal
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.
Post by Charles Lasitter
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 |
+-----------------------------------------+
Charles Lasitter
2006-04-20 11:58:51 UTC
Permalink
On Thu, 20 Apr 2006 02:12:13 +0200, "UZnal" <unalz-at-mail333-dot-com>
Post by UZnal
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 |
+-----------------------------------------+
UZnal
2006-04-21 01:23:16 UTC
Permalink
Post by 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.
Post by Louis Ohland
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.
Charles Lasitter
2006-04-21 13:35:32 UTC
Permalink
On Fri, 21 Apr 2006 03:23:16 +0200, "UZnal" <unalz-at-mail333-dot-com>
Post by UZnal
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 |
+-----------------------------------------+
UZnal
2006-04-22 10:43:13 UTC
Permalink
Post by Charles Lasitter
Post by UZnal
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?
Charles Lasitter
2006-04-22 13:06:59 UTC
Permalink
On Sat, 22 Apr 2006 12:43:13 +0200, "UZnal" <unalz-at-mail333-dot-com>
Post by UZnal
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 |
+-----------------------------------------+
UZnal
2006-04-22 22:02:11 UTC
Permalink
Post by Charles Lasitter
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.
Post by Charles Lasitter
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.
Post by Charles Lasitter
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.
b***@gmail.com
2006-04-22 13:18:27 UTC
Permalink
UZ,

UZnal wrote:

<SNIP XGA stuff>
Post by UZnal
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
UZnal
2006-04-22 22:03:50 UTC
Permalink
Thanks, Brad. I suppose it works for Mod. 57 too.

What was that trick to make W98 install on a 486 machine?
b***@gmail.com
2006-04-24 16:22:15 UTC
Permalink
Post by UZnal
Thanks, Brad. I suppose it works for Mod. 57 too.
Let me know if it doesn't.
Post by UZnal
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
UZnal
2006-04-24 21:21:01 UTC
Permalink
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.
Post by b***@gmail.com
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.
Jim Shorney
2006-04-23 05:39:01 UTC
Permalink
Post by UZnal
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.
Post by UZnal
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 =----
Jim Shorney
2006-04-23 16:00:16 UTC
Permalink
Post by UZnal
W95 is amazingly strange.
Amazing isn't the word for it....
Post by UZnal
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 =----
UZnal
2006-04-23 18:38:25 UTC
Permalink
Post by Jim Shorney
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.
Post by Jim Shorney
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.
Post by Jim Shorney
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.
Jim Shorney
2006-04-23 21:04:24 UTC
Permalink
Post by UZnal
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.
Post by UZnal
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.
Post by UZnal
** 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 =----
UZnal
2006-04-24 00:02:27 UTC
Permalink
Post by Jim Shorney
Post by UZnal
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
Post by Jim Shorney
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.
Post by Jim Shorney
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...
Jim Shorney
2006-04-24 01:20:39 UTC
Permalink
Post by UZnal
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 =----
Jim Shorney
2006-04-24 03:35:18 UTC
Permalink
Post by UZnal
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 =----
Charles Lasitter
2006-04-24 20:07:03 UTC
Permalink
Post by Jim Shorney
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 |
+-----------------------------------------+
UZnal
2006-04-24 22:20:37 UTC
Permalink
Post by Charles Lasitter
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.
UZnal
2006-04-24 21:14:04 UTC
Permalink
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.
Jim Shorney
2006-04-26 03:48:35 UTC
Permalink
Post by UZnal
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 =----
UZnal
2006-04-26 11:40:18 UTC
Permalink
Post by Jim Shorney
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.
w***@hotmail.com
2006-04-26 17:47:28 UTC
Permalink
Hi!
Post by Jim Shorney
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.
Post by Jim Shorney
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
UZnal
2006-04-27 00:22:43 UTC
Permalink
Post by w***@hotmail.com
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....;)
William R. Walsh
2006-04-27 03:27:11 UTC
Permalink
Hi!
Post by UZnal
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
Daniel Hamilton
2006-04-27 04:45:00 UTC
Permalink
Post by William R. Walsh
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
UZnal
2006-04-27 19:47:36 UTC
Permalink
Post by William R. Walsh
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.
Post by William R. Walsh
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.
Post by William R. Walsh
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.
Post by William R. Walsh
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.
Post by William R. Walsh
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.
Post by William R. Walsh
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?
Post by William R. Walsh
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?
Louis Ohland
2006-04-27 20:16:32 UTC
Permalink
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.
Post by William R. Walsh
Post by William R. Walsh
worked great. Rebooted. Windows comes up with the blue "setup"
wallpaper--only it is pink! Once I got past the logon dialog, this
corrected
Post by William R. Walsh
itself and the wallpaper turned the proper color.
This is a known problem but so far harmless.
Post by William R. Walsh
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.
Post by William R. Walsh
Okay, follow the instructions for setting the swapfile...I too picked
100MB
Post by William R. Walsh
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.
Post by William R. Walsh
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.
Post by William R. Walsh
Well...maybe my monitor selection is overly ambitious. Reboot, go back
into
Post by William R. Walsh
display properties...change out the IBM G50 for a "Super VGA 1024x768"
generic monitor. Long story short, the first jump back to 800x600x256
colors
Post by William R. Walsh
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.
Post by William R. Walsh
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?
Post by William R. Walsh
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?
w***@hotmail.com
2006-04-27 22:12:09 UTC
Permalink
Hi!
Post by UZnal
Only when you
clicked the tab in the Display applet?
That's when I first saw it, yes.
Post by UZnal
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.
Post by UZnal
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.
Post by UZnal
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.
Post by UZnal
What happens when you disable the mouse trails?
They are not enabled and never were.
Post by UZnal
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...
Post by UZnal
Did you see any tabs/options in Display dealing with refresh
rates?
No, I never happened to see any such tabs.

William
w***@hotmail.com
2006-04-27 23:05:48 UTC
Permalink
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

Jim Shorney
2006-04-27 01:51:30 UTC
Permalink
Post by w***@hotmail.com
"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.
Post by w***@hotmail.com
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 =----
Peter H. Wendt
2006-04-25 14:33:15 UTC
Permalink
Hi Ünal !
Post by UZnal
Updated VXD and updated installation instructions in the updated zip, same
URL
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: ***@aol.com only ! ***
UZnal
2006-04-25 19:15:20 UTC
Permalink
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
Post by Peter H. Wendt
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.
Post by Peter H. Wendt
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.
Post by Peter H. Wendt
(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 ...;)
Peter H. Wendt
2006-04-25 20:07:34 UTC
Permalink
Hi Ünal !
Post by UZnal
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.
Post by UZnal
Post by Peter H. Wendt
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 ....
Post by UZnal
Post by Peter H. Wendt
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 ?"
Post by UZnal
Post by Peter H. Wendt
(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: ***@aol.com only ! ***
UZnal
2006-04-26 11:09:55 UTC
Permalink
Hi Peter,
Post by Peter H. Wendt
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.
Post by Peter H. Wendt
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
Peter H. Wendt
2006-04-26 11:59:38 UTC
Permalink
Hi Ünal !
Post by UZnal
Hi Peter,
Post by Peter H. Wendt
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.
Post by Peter H. Wendt
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.
Post by UZnal
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
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: ***@aol.com only ! ***
Peter H. Wendt
2006-04-26 15:38:28 UTC
Permalink
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: ***@aol.com only ! ***
Don Hills
2006-04-26 23:23:59 UTC
Permalink
In article <444f9588$0$13355$***@news.freenet.de>,
"Peter H. Wendt" <***@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
UZnal
2006-04-27 00:44:16 UTC
Permalink
Hi Peter,
Post by Peter H. Wendt
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.
Post by Peter H. Wendt
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)
Post by Peter H. Wendt
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
Post by Peter H. Wendt
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
Peter H. Wendt
2006-04-26 11:56:25 UTC
Permalink
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: ***@aol.com only ! ***
UZnal
2006-04-21 01:32:39 UTC
Permalink
Post by UZnal
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.
UZnal
2006-04-21 13:33:59 UTC
Permalink
Post by UZnal
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.
Charles Lasitter
2006-04-09 20:50:25 UTC
Permalink
On Sun, 9 Apr 2006 15:41:06 +0200, "UZnal" <unalz-at-mail333-dot-com>
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 |
+-----------------------------------------+
Louis Ohland
2006-04-09 21:59:15 UTC
Permalink
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?
Post by Charles Lasitter
On Sun, 9 Apr 2006 15:41:06 +0200, "UZnal" <unalz-at-mail333-dot-com>
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 |
+-----------------------------------------+
w***@hotmail.com
2006-04-26 17:58:04 UTC
Permalink
Hi!
Post by Louis Ohland
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
Loading...