f



W9xNT MCA Adapters - SPOCK

Feasibility report:

- The SCSI port driver provides support and services for SCSI miniport
drivers.

- SCSI miniport drivers are HBA-specific but OS-independent. That is, each
miniport driver links itself against the SCSI port driver and calls only the
port driver's ScsiPortXxx routines to communicate with the system. HBA
miniport drivers can be compiled to run on machines running Windows 95 or
Windows NT. Each platform provides an OS-dependent port driver that exports
the ScsiPortXxx routines.

Below are the SCSI port routines used by the Win SPOCK miniport driver:

ScsiPortInitialize
ScsiPortLogError
ScsiPortStallExecution
ScsiPortWritePortUchar
ScsiPortReadPortUchar
ScsiPortGetPhysicalAddress
ScsiPortGetUncachedExtension
ScsiPortNotification
ScsiPortGetLogicalUnit
ScsiPortGetVirtualAddress
ScsiPortConvertUlongToPhysicalAddress
ScsiPortCompleteRequest
ScsiPortWritePortUlong
ScsiPortMoveMemory
ScsiPortFreeDeviceBase
ScsiPortGetDeviceBase


PORT_CONFIGURATION_INFORMATION is an internal structure describing the
capabilities of the host adapter, it provides port configuration
information. I quote below selected fields, just to show how easy it would
be to downgrade an adapter. This structure is accessible to the miniport
driver:

DmaChannel

Specifies the DMA channel used by the host bus adapter.
The uninitialized value is 0xFFFFFFFF.

DmaPort

Specifies the DMA port used by the host bus adapter.
This is meaningful for MCA-type buses. The uninitialized value is zero.

DmaWidth

Specifies the width of the DMA transfer.
The uninitialized value is zero.
Accepted widths are 8, 16, 32, and maximum DMA widths.

DmaSpeed

Specifies the data transfer speed for EISA system buses.
The default is compatibility timing.
Accepted types are: compatable, type a, type b, type c, and maximum DMA
speed.

NumberOfBuses

Specifies the number of SCSI buses attached to the HBA.
The uninitialized value is zero.

Master

Indicates the HBA is a busmaster.
The uninitialized value is FALSE.

CachesData

Indicates the HBA caches data or maintains cached state on the peripherals,
for example a controller that mirrors two disks would normally set this bit.
When this bit is set, the OS-specific port driver notifies the HBA miniport
driver of events such as a file system flush and system shutdown.
The uninitialized value is FALSE.

Dma32BitAddresses

Indicates that the HBA has 32 address lines and can access memory with
physical
addresses greater than 0x00FFFFFF.

DemandMode

Indicates the system DMA controller should be programmed for demand-mode
rather
than single-cycle operations.

MapBuffers

Indicates data buffers must be mapped into system virtual address ranges.
The value is copied from HW_INITIALIZATION_DATA. The driver may update
the value for each particular HBA.

NeedPhysicalAddresses

Indicates the driver needs to translate virtual addresses to physical ones.
The value is copied from HW_INITIALIZATION_DATA. The driver may update the
value for each particular HBA.

RealModeInitialized

Indicates the real-mode driver has initialized the card. This field is
always
initialized by ScsiPort.

* * *

The specific fields initialized depend on the HBA miniport driver and the
information available to the OS-specific port driver. All uninitialized
fields are set to a default value.

All HBA miniport drivers should have at least one set of defaults to use
for relevant fields if a value is not specified. All relevant fields should
be updated by the HBA miniport driver.

SCSI class drivers, which load later than miniport drivers, depend on the
information supplied by HwFindAdapter to customize their subsequent
requests.
For example, the MaximumTransferLength and NumberOfPhysicalBreaks values
supplied by the miniport driver control whether class driver must split
large transfer requests into a set of partial transfers to suit the limits
of the HBA.




0
UZnal
5/5/2006 12:04:49 AM
comp.sys.ibm.ps2.hardware 10363 articles. 0 followers. Post Follow

321 Replies
911 Views

Similar Articles

[PageSpeed] 21

UZ, I sendt my copy of the SCSI-2 F/W tech ref to Michael Lang so he 
would be better able to write the Linux SCSI driver. Why don't you ask 
him for that copy?

UZnal wrote:

> DmaChannel 
> Specifies the DMA channel used by the host bus adapter.
> The uninitialized value is 0xFFFFFFFF.

Corvette can do IRQ11 and IRQ14. It might be nice if you could set one 
at 11 and one at 14...

> DmaPort
> Specifies the DMA port used by the host bus adapter.
> This is meaningful for MCA-type buses. The uninitialized value is zero.

W98 has NO DMA setting for IBM MCA SCSI. I would consider this to show 
it might not use DMA. If true, it would really cripple Spock and Corvette.

> DmaWidth
> Specifies the width of the DMA transfer.
> The uninitialized value is zero.
> Accepted widths are 8, 16, 32, and maximum DMA widths.

Um, 8 bit might be for the old TMC-850 ISA. It would be nice if the 
driver reported the width, instead of assuming.

> DmaSpeed
> Specifies the data transfer speed for EISA system buses.
> The default is compatibility timing.
> Accepted types are: compatable, type a, type b, type c, and maximum DMA
> speed.

Um, won't bus probing make this nonsequitor?

NumberOfBuses
> Specifies the number of SCSI buses attached to the HBA.
> The uninitialized value is zero.

Um, does this support the separate bus for the corvette? Where the 
internal and external buses are separate?

> Master
> Indicates the HBA is a busmaster.
> The uninitialized value is FALSE.

Better be initialized to TRUE

> CachesData
> Indicates the HBA caches data or maintains cached state on the peripherals,
> for example a controller that mirrors two disks would normally set this bit.
> When this bit is set, the OS-specific port driver notifies the HBA miniport
> driver of events such as a file system flush and system shutdown.
> The uninitialized value is FALSE.

Hm, Spock has a cache that this could use. Corvette has 128K most likely 
for command chaining.

> Dma32BitAddresses
> Indicates that the HBA has 32 address lines and can access memory with
> physical addresses greater than 0x00FFFFFF.

Yay! Get some!

> DemandMode
> Indicates the system DMA controller should be programmed for demand-mode
> rather than single-cycle operations.

Uh, is this SCB?

> MapBuffers
> Indicates data buffers must be mapped into system virtual address ranges.
> The value is copied from HW_INITIALIZATION_DATA. The driver may update
> the value for each particular HBA.

Que pasa?

> NeedPhysicalAddresses
> Indicates the driver needs to translate virtual addresses to physical ones.
> The value is copied from HW_INITIALIZATION_DATA. The driver may update the
> value for each particular HBA.
> 
> RealModeInitialized
> 
> Indicates the real-mode driver has initialized the card. This field is
> always
> initialized by ScsiPort.
> 
> * * *
> 
> The specific fields initialized depend on the HBA miniport driver and the
> information available to the OS-specific port driver. All uninitialized
> fields are set to a default value.
> 
> All HBA miniport drivers should have at least one set of defaults to use
> for relevant fields if a value is not specified. All relevant fields should
> be updated by the HBA miniport driver.
> 
> SCSI class drivers, which load later than miniport drivers, depend on the
> information supplied by HwFindAdapter to customize their subsequent
> requests.
> For example, the MaximumTransferLength and NumberOfPhysicalBreaks values
> supplied by the miniport driver control whether class driver must split
> large transfer requests into a set of partial transfers to suit the limits
> of the HBA.
0
Louis
5/5/2006 12:34:24 AM
I'd like to know how hosed up the M$ driver is, just to confirm my dark 
suspicions about M$. FUD

Louis Ohland wrote:
> UZ, I sendt my copy of the SCSI-2 F/W tech ref to Michael Lang so he 
> would be better able to write the Linux SCSI driver. Why don't you ask 
> him for that copy?
> 
> UZnal wrote:
> 
>> DmaChannel Specifies the DMA channel used by the host bus adapter.
>> The uninitialized value is 0xFFFFFFFF.
> 
> Corvette can do IRQ11 and IRQ14. It might be nice if you could set one 
> at 11 and one at 14...
> 
>> DmaPort
>> Specifies the DMA port used by the host bus adapter.
>> This is meaningful for MCA-type buses. The uninitialized value is zero.
> 
> W98 has NO DMA setting for IBM MCA SCSI. I would consider this to show 
> it might not use DMA. If true, it would really cripple Spock and Corvette.
> 
>> DmaWidth
>> Specifies the width of the DMA transfer.
>> The uninitialized value is zero.
>> Accepted widths are 8, 16, 32, and maximum DMA widths.
> 
> Um, 8 bit might be for the old TMC-850 ISA. It would be nice if the 
> driver reported the width, instead of assuming.
> 
>> DmaSpeed
>> Specifies the data transfer speed for EISA system buses.
>> The default is compatibility timing.
>> Accepted types are: compatable, type a, type b, type c, and maximum DMA
>> speed.
> 
> Um, won't bus probing make this nonsequitor?
> 
> NumberOfBuses
>> Specifies the number of SCSI buses attached to the HBA.
>> The uninitialized value is zero.
> 
> Um, does this support the separate bus for the corvette? Where the 
> internal and external buses are separate?
> 
>> Master
>> Indicates the HBA is a busmaster.
>> The uninitialized value is FALSE.
> 
> Better be initialized to TRUE
> 
>> CachesData
>> Indicates the HBA caches data or maintains cached state on the 
>> peripherals,
>> for example a controller that mirrors two disks would normally set 
>> this bit.
>> When this bit is set, the OS-specific port driver notifies the HBA 
>> miniport
>> driver of events such as a file system flush and system shutdown.
>> The uninitialized value is FALSE.
> 
> Hm, Spock has a cache that this could use. Corvette has 128K most likely 
> for command chaining.
> 
>> Dma32BitAddresses
>> Indicates that the HBA has 32 address lines and can access memory with
>> physical addresses greater than 0x00FFFFFF.
> 
> Yay! Get some!
> 
>> DemandMode
>> Indicates the system DMA controller should be programmed for demand-mode
>> rather than single-cycle operations.
> 
> Uh, is this SCB?
> 
>> MapBuffers
>> Indicates data buffers must be mapped into system virtual address ranges.
>> The value is copied from HW_INITIALIZATION_DATA. The driver may update
>> the value for each particular HBA.
> 
> Que pasa?
> 
>> NeedPhysicalAddresses
>> Indicates the driver needs to translate virtual addresses to physical 
>> ones.
>> The value is copied from HW_INITIALIZATION_DATA. The driver may update 
>> the
>> value for each particular HBA.
>>
>> RealModeInitialized
>>
>> Indicates the real-mode driver has initialized the card. This field is
>> always
>> initialized by ScsiPort.
>>
>> * * *
>>
>> The specific fields initialized depend on the HBA miniport driver and the
>> information available to the OS-specific port driver. All uninitialized
>> fields are set to a default value.
>>
>> All HBA miniport drivers should have at least one set of defaults to use
>> for relevant fields if a value is not specified. All relevant fields 
>> should
>> be updated by the HBA miniport driver.
>>
>> SCSI class drivers, which load later than miniport drivers, depend on the
>> information supplied by HwFindAdapter to customize their subsequent
>> requests.
>> For example, the MaximumTransferLength and NumberOfPhysicalBreaks values
>> supplied by the miniport driver control whether class driver must split
>> large transfer requests into a set of partial transfers to suit the 
>> limits
>> of the HBA.
0
Louis
5/5/2006 12:37:37 AM
> UZ, I sendt my copy of the SCSI-2 F/W tech ref to Michael Lang so he
> would be better able to write the Linux SCSI driver. Why don't you ask
> him for that copy?

At the right time, I have to protect myself from mysef. The miniport story
seems quite simple, the IOMEGA/DDK-95 sample is a good template.


> Corvette can do IRQ11 and IRQ14. It might be nice if you could set one
> at 11 and one at 14...

IRQs have an interpretation, we have to look at it in the model context. May
indicate a completion of an operation.


> W98 has NO DMA setting for IBM MCA SCSI. I would consider this to show
> it might not use DMA. If true, it would really cripple Spock and Corvette.

Not needed for busmasters, only needed for non-busmasters requesting DMA.


> > DmaWidth
> Um, 8 bit might be for the old TMC-850 ISA. It would be nice if the
> driver reported the width, instead of assuming.

It must set it, not report it. Depends on the config.


> > DmaSpeed
> > Specifies the data transfer speed for EISA system buses.
> Um, won't bus probing make this nonsequitor?

EISA is different, you can indeed set DmaSpeed.

> NumberOfBuses
> Um, does this support the separate bus for the corvette? Where the
> internal and external buses are separate?

I think so.

> > Master
> Better be initialized to TRUE

Should be.

> > CachesData
> Hm, Spock has a cache that this could use. Corvette has 128K most likely
> for command chaining.

The host adapter is informed to flush the cache on shutdown, that is the
only use.

> > DemandMode
> > Indicates the system DMA controller should be programmed for demand-mode
> > rather than single-cycle operations.
>
> Uh, is this SCB?

Relates to system DMA controller.

> > MapBuffers
> > Indicates data buffers must be mapped into system virtual address
ranges.
> > The value is copied from HW_INITIALIZATION_DATA. The driver may update
> > the value for each particular HBA.
>
> Que pasa?

Needs a closer look, perhaps buffer-to-host facility.




0
UZnal
5/5/2006 1:21:56 PM
UZnal,

> - SCSI miniport drivers are HBA-specific but OS-independent. That is, each
> miniport driver links itself against the SCSI port driver and calls only the
> port driver's ScsiPortXxx routines to communicate with the system. HBA
> miniport drivers can be compiled to run on machines running Windows 95 or
> Windows NT. Each platform provides an OS-dependent port driver that exports
> the ScsiPortXxx routines.

If this is a hint that you are looking at making improvement to 
spock.sys, let me know how I can help. I am tired of having spock.sys 
not fully enable the corvettes that I use. It appears, and please 
correct me if I am wrong, that Microsoft does not differentiate between 
a spock and a corvette at the miniport level.  

> Below are the SCSI port routines used by the Win SPOCK miniport driver:

Don't forget these from the checked build:

ScsiDebugPrint
ScsiPortLogError

Checked build shows these methods within spock.sys:

DriverEntry
SpockConfiguration
SpockInitialize
SpockStartIo
SpockInterrupt
SpockResetBus
SpockAbortIo
BuildScb
BuildSgl
BuildReadCapacity
McaAdapterPresent
IssueScbCommand
IssueImmediateCommand
MapTsbError
AdapterAddresses

Thanks for the XGA-2 improvements. As soon as I get some more hardware 
for my Model 90, I will put Win95C on it and see how the XGA206 driver 
update fairs.

Have a good day,
exwisdem
0
David
5/5/2006 7:32:35 PM
Ho David.

> > Below are the SCSI port routines used by the Win SPOCK miniport driver:
>
> Don't forget these from the checked build:

That was the list from SPOCK.MPD of W98SE.

> It appears, and please
> correct me if I am wrong, that Microsoft does not differentiate between
> a spock and a corvette at the miniport level.

It isn't surprising, it is? They have barely differentiated between XGA and
XGA-2, and imagine what a blessing the mutual compatibility of the 8EFx
adapters must have been for them m$ofties.

> Thanks for the XGA-2 improvements. As soon as I get some more hardware
> for my Model 90, I will put Win95C on it and see how the XGA206 driver
> update fairs.

Time to give Louis some break from the broken XGA/106....;)







0
UZnal
5/6/2006 12:02:05 AM
UZnal wrote:
> Ho David.
> 
>>> Below are the SCSI port routines used by the Win SPOCK miniport driver:
>> Don't forget these from the checked build:
> 
> That was the list from SPOCK.MPD of W98SE.
> 
>> It appears, and please
>> correct me if I am wrong, that Microsoft does not differentiate between
>> a spock and a corvette at the miniport level.
> 
> It isn't surprising, it is? They have barely differentiated between XGA and
> XGA-2, and imagine what a blessing the mutual compatibility of the 8EFx
> adapters must have been for them m$ofties.
  Is anyone left here familiar with MCA Linux at the source level?  How
does it's support of the Corvette and XGA-2 compare to Win95?
			Kevin
0
Kevin
5/6/2006 8:59:36 PM
>   Is anyone left here familiar with MCA Linux at the source level?  How
> does it's support of the Corvette and XGA-2 compare to Win95?

I know IBMMCA.C of Slackware, the one Tony Ingenoso was squeezing the bytes
out. The Corvette appears there only to get IRQ 11 and that is all about it.

Win9x borrows the SCSI driver model from NT. It is clean, easy to understand
and produce, I like it. Miniport drivers are intended to deal with the
specifics of an adapter, and it is up to you to get every bit of juice out
of it.

I'll have to google for XGA-2 and Linux. The Win9x support for XGA-2 was
until recently miserable, but that has changed now.




0
UZnal
5/6/2006 10:49:49 PM
On Sat, 6 May 2006 22:49:49 UTC, "UZnal" <unalz-at-mail333-dot-com> 
wrote:

> Win9x borrows the SCSI driver model from NT. It is clean, easy to understand
> and produce, I like it

Taken directly from VAX/VMS. I've done a couple of port drivers for 
that.

The model was demonstrably taken directly from VMS. Not a Microsoft idea
at all.
-- 
Bob Eager
rde at tavi.co.uk
PC Server 325; PS/2s 8595*3, 9595*3 (2*P60 + P90), 8535, 8570, 9556*2, 
8580*6,
8557*2, 8550, 9577, 8530, P70, PC/AT..
http://www.tavi.co.uk
http://www.ardent-tool.org.uk

0
Bob
5/7/2006 12:04:49 AM

Kevin Bowling wrote:
> 
>   Is anyone left here familiar with MCA Linux at the source level?  How
> does it's support of the Corvette and XGA-2 compare to Win95?
>                         Kevin


http://www.staff.uni-mainz.de/mlang/linux.html

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
5/7/2006 2:34:05 AM
Bob Eager wrote:
> On Sat, 6 May 2006 22:49:49 UTC, "UZnal" <unalz-at-mail333-dot-com> 
> wrote:
> 
>> Win9x borrows the SCSI driver model from NT. It is clean, easy to understand
>> and produce, I like it
> 
> Taken directly from VAX/VMS. I've done a couple of port drivers for 
> that.
> 
> The model was demonstrably taken directly from VMS. Not a Microsoft idea
> at all.

Well, NT is a VMS clone after all!  Everyone knows that story I think.  :)

--Daniel
0
Daniel
5/7/2006 2:07:35 PM
On Sun, 7 May 2006 14:07:35 UTC, Daniel Hamilton 
<bitslasher_nospam_@gmail.com> wrote:

> Bob Eager wrote:
> > On Sat, 6 May 2006 22:49:49 UTC, "UZnal" <unalz-at-mail333-dot-com> 
> > wrote:
> > 
> >> Win9x borrows the SCSI driver model from NT. It is clean, easy to understand
> >> and produce, I like it
> > 
> > Taken directly from VAX/VMS. I've done a couple of port drivers for 
> > that.
> > 
> > The model was demonstrably taken directly from VMS. Not a Microsoft idea
> > at all.
> 
> Well, NT is a VMS clone after all!  Everyone knows that story I think.  :)

I think I probably posted it first....many years ago! But it's not a 
clone..far from it. Take it from someone who's studied the internals of 
both...!

(and has three VMS systems...as well as the PS2s...)

-- 
Bob Eager
rde at tavi.co.uk
PC Server 325; PS/2s 8595*3, 9595*3 (2*P60 + P90), 8535, 8570, 9556*2, 
8580*6,
8557*2, 8550, 9577, 8530, P70, PC/AT..
http://www.tavi.co.uk
http://www.ardent-tool.org.uk

0
Bob
5/7/2006 2:49:53 PM
> > Well, NT is a VMS clone after all!  Everyone knows that story I think.
>
> I think I probably posted it first....many years ago! But it's not a
> clone..far from it. Take it from someone who's studied the internals of
> both...!

a) The operating requirements have become different.

b) Technology is the people and not the organizations.

c) All is fair in engineering.




0
UZnal
5/7/2006 3:33:50 PM
On Sun, 7 May 2006 15:33:50 UTC, "UZnal" <unalz-at-mail333-dot-com> 
wrote:

> > > Well, NT is a VMS clone after all!  Everyone knows that story I think.
> >
> > I think I probably posted it first....many years ago! But it's not a
> > clone..far from it. Take it from someone who's studied the internals of
> > both...!

Not quite sure what your point is, but:

> a) The operating requirements have become different.

Of course. That's why it's not a clone.

> b) Technology is the people and not the organizations.

Exactly. A lot of the people are the same?

> c) All is fair in engineering.

Que?
-- 
Bob Eager
rde at tavi.co.uk
PC Server 325; PS/2s 8595*3, 9595*3 (2*P60 + P90), 8535, 8570, 9556*2, 
8580*6,
8557*2, 8550, 9577, 8530, P70, PC/AT..
http://www.tavi.co.uk
http://www.ardent-tool.org.uk

0
Bob
5/7/2006 3:47:02 PM
Bob Eager wrote:
> On Sun, 7 May 2006 14:07:35 UTC, Daniel Hamilton 
> <bitslasher_nospam_@gmail.com> wrote:
> 
>> Bob Eager wrote:
>>> On Sat, 6 May 2006 22:49:49 UTC, "UZnal" <unalz-at-mail333-dot-com> 
>>> wrote:
>>>
>>>> Win9x borrows the SCSI driver model from NT. It is clean, easy to understand
>>>> and produce, I like it
>>> Taken directly from VAX/VMS. I've done a couple of port drivers for 
>>> that.
>>>
>>> The model was demonstrably taken directly from VMS. Not a Microsoft idea
>>> at all.
>> Well, NT is a VMS clone after all!  Everyone knows that story I think.  :)
> 
> I think I probably posted it first....many years ago! But it's not a 
> clone..far from it. Take it from someone who's studied the internals of 
> both...!
> 
> (and has three VMS systems...as well as the PS2s...)
> 

Yeah, I agree.  I was stating in a very simplistic way that NT is a 
clone in the sense that architecturally it is *very* similar.  The 
subsystems and their roles are directly taken from the VMS architecture, 
which makes sense since the basically same people designed both systems. 
  Many instances the names were just changed.  Of course the APIs are 
all different, but from what I've read even some of the kernel APIs are 
strikingly similar.  In some instances only the a prefix differentiates 
an NT kernel function from a corresponding one from VMS.

Of course I'm speaking to someone who knows more about this than I, so I 
guess I should ask, do I have the right idea here?  :)

--Daniel
0
Daniel
5/7/2006 6:39:41 PM
On Sun, 7 May 2006 18:39:41 UTC, Daniel Hamilton 
<bitslasher_nospam_@gmail.com> wrote:

> Yeah, I agree.  I was stating in a very simplistic way that NT is a 
> clone in the sense that architecturally it is *very* similar.  The 
> subsystems and their roles are directly taken from the VMS architecture, 
> which makes sense since the basically same people designed both systems. 
>   Many instances the names were just changed.  Of course the APIs are 
> all different, but from what I've read even some of the kernel APIs are 
> strikingly similar.  In some instances only the a prefix differentiates 
> an NT kernel function from a corresponding one from VMS.
>  
> Of course I'm speaking to someone who knows more about this than I, so I 
> guess I should ask, do I have the right idea here?  :)

I wouldn't put it that close. The basic structure is the same, but 
Cutler was doing his long anticipated 'Son of VMS' and he had lots of 
stuff he wanted to change. VMS is very tied to the VAX architecture 
(Itanium notwithstanding), and he wanted to move away from that. VMS is 
much easier to tweak, and has very rigid naming conventions for 
practically everything. Every kernel module (and library, and 
application) has a unique 3 character prefix, and all entry points have 
to conform to that. It seems messier on NT, probably for some historical
reason. The subsystem idea is not really there on VMS. Loadable modules 
are, including loading device drivers at any time, and even unloading 
them again. In many ways VMS has been dumbed down for NT.

Some of the three character prefixes are quite amusing - two of the 
security modules have acronyms that I forget, but the prefixes are CIA$ 
and KGB$...!

Why not have a go at running VMS - it costs nothing! More details if 
wanted...but you'll need a PC a bit faster than a stock PS/2...

-- 
Bob Eager
rde at tavi.co.uk
PC Server 325; PS/2s 8595*3, 9595*3 (2*P60 + P90), 8535, 8570, 9556*2, 
8580*6,
8557*2, 8550, 9577, 8530, P70, PC/AT..
http://www.tavi.co.uk
http://www.ardent-tool.org.uk

0
Bob
5/7/2006 6:52:55 PM
Is it an emulator? What architecture does it run on?

Bob Eager wrote:
> Why not have a go at running VMS - it costs nothing! More details if 
> wanted...but you'll need a PC a bit faster than a stock PS/2...
> 
0
Louis
5/7/2006 7:03:12 PM
Bob Eager wrote:
> Why not have a go at running VMS - it costs nothing! More details if 
> wanted...but you'll need a PC a bit faster than a stock PS/2...
> 

Really?  I have never ran it, didn't know I could.  I thought it 
required special non-PC hardware...

--Daniel
0
Daniel
5/7/2006 7:10:34 PM
On Sun, 7 May 2006 19:03:12 UTC, Louis Ohland <ohland@charter.net> 
wrote:

> Is it an emulator? What architecture does it run on?
> 
> Bob Eager wrote:
> > Why not have a go at running VMS - it costs nothing! More details if 
> > wanted...but you'll need a PC a bit faster than a stock PS/2...

There's a nice VAX emulator. Runs in BSD/Windows/Linux, but I ported it 
to OS/2 since that's the primary system I run.

You need to get the VMS install CD (I have an image of it but it's 
600MB) and image it to the hard disk. Start the emulator and boot VMS 
standalone backup from the CD image (emulating a CD). Transfer the 
initial VMS boot files to an emulated 400MB disk (a file). Boot from 
that and there you are. This is teh normal VMS installation method.

You need a license. These are free but you have to belong to a user 
group. There's a free user group in the U.S. Get your group membership 
number, key it into a website and the license number arrives in email 
five minutes later.

All documentation (14 shelf feet when I last looked) is online in PDF. 
Also compilers for common languages, useful packages and gigabytes of 
programs.

This is a REAL timesharing system, and remarkably capable. Command line 
only, but pretty friendly.

My last real VAX cost me about $60. No disks, hence the use of a 
DCAS-34330. They're all SCSI, at least the ones you can get. I got mine 
on eBay!
-- 
Bob Eager
rde at tavi.co.uk
PC Server 325; PS/2s 8595*3, 9595*3 (2*P60 + P90), 8535, 8570, 9556*2, 
8580*6,
8557*2, 8550, 9577, 8530, P70, PC/AT..
http://www.tavi.co.uk
http://www.ardent-tool.org.uk

0
Bob
5/7/2006 7:36:52 PM
> > c) All is fair in engineering.
>
> Que?

I remember it from a book. I guess, it means "the purpose justifies the
means".





0
UZnal
5/7/2006 7:56:36 PM
A veil of secrecy over the Manual, miss a word and you are in troubles.
Software engineers do not read flowcharts. Before writing to the Command
Interface and Attention registers, system interrupts must be disabled, after
that enabled. NT stays for NoT me, Windows for Why me, Linux for even Less
me.

Accumulate 10 errors, then disable Disconnect and Sync Transfer. Blame
Spock, genial ...!




0
UZnal
5/10/2006 4:22:03 PM
Hello UZ,

> A veil of secrecy over the Manual, miss a word and you are in troubles.
> Software engineers do not read flowcharts. Before writing to the Command
> Interface and Attention registers, system interrupts must be disabled, after
> that enabled. 

Interesting. So you are saying this procedure is not followed in the 
microsoft NT/9x driver?  

> NT stays for NoT me, Windows for Why me, Linux for even Less
> me.

Cute.  Never heard those before.  But, if you are saying the Linux 
driver suffers the same short comings of the microsoft drivers, then did 
some one let loose the microsoft code into the Linux community? I 
generally expect better code from the Linux folks than microsoft.

> Accumulate 10 errors, then disable Disconnect and Sync Transfer. Blame
> Spock, genial ...!

So there is counter, and when it reached 10, it aborts current transfer?  
This would explain the sluggish nature of the driver.

Your posts are mystic at times, but that is ok. You really seem to know 
what you are doing. However, I confess to a bunch of SWAGs in my post, 
;).

exwisdem
0
David
5/11/2006 1:53:21 PM
> Interesting. So you are saying this procedure is not followed in the
> microsoft NT/9x driver?

Yes, not followed.

> Cute.  Never heard those before.  But, if you are saying the Linux
> driver suffers the same short comings of the microsoft drivers, then did
> some one let loose the microsoft code into the Linux community? I
> generally expect better code from the Linux folks than microsoft.

The code in this particular case is not better, however, observe that these
are different driver models, and it must play by the rules of the platform.
The question is then how well the details within the driver code space are
done.


> > Accumulate 10 errors, then disable Disconnect and Sync Transfer. Blame
> > Spock, genial ...!
>
> So there is counter, and when it reached 10, it aborts current transfer?
> This would explain the sluggish nature of the driver.

There is a counter, it then commands the adapter to disable Disconnect and
Sync Transfer. You've described the effect of it.

> Your posts are mystic at times, but that is ok.

Trying to be a brave mcamafioso ...;)




0
UZnal
5/11/2006 3:12:55 PM
Query SPOCK for DOS:

May 21, 2006: www.members.aon.at/mcabase/pub/files/QSPOCK.ZIP

Real mode DOS only. That made more work than I thought. The trick is to
disable the adapter interrupt just before issuing the SCB and then enable
it. Interrupt disable/enable through the adapter Basic Control register.




0
UZnal
5/21/2006 10:20:16 PM
Correct data displayed now.

May 22, 2006: www.members.aon.at/mcabase/pub/files/QSPOCK.ZIP

To whom$ it may concern: Fixed your misordered AdapterInfo fields.




0
UZnal
5/22/2006 8:05:52 PM
Hello UZ,

Do not know if you were looking for verification or not, but here is the 
results of running it on my "checked" 8595 booted to DOS 6.22.

have a great day,
exwisdem

+++++++++++++++++++++ QUOT.TXT +++++++++++++++++++++++++

Port: 3540  Present
Port: 3548  --
Port: 3550  --
Port: 3558  --
Port: 3560  --
Port: 3568  --
Port: 3570  --
Port: 3578  --

( 1 ) IBM SCSI adapters found

Port 3540 : Status Information
-------------------------------
(05h)    Basic Control: 0 0 0 0 0 0 1 1 
0     Interrupt Enable: Yes
1           DMA Enable: Yes
6-2           Reserved: --
7       Hardware Reset: No

(07h)     Basic Status: 0 0 0 0 0 1 0 0 
0                 Busy: No
1    Interrupt Request: No
2  Cmd Interface Empty: Yes : Read by the adapter
3  Cmd Interface  Full: No  : Emptied by the adapter
7-4           Reserved: --

(06h) Interrupt Status: 0 0 0 1 0 0 0 0 
3-0          Device-ID: 0
7-4       Interrupt-ID: ( 0 ) SCB Command completed with success

SCB * Get Adapter Info: ( F ) SCB Command completed with success
            Adapter ID: 8EFC
      POS Register [2]: 1 1 1 1 0 0 0 1 
      POS Register [3]: 1 1 1 0 1 1 0 0 
      POS Register [4]: 0 0 1 1 1 1 0 0 
       Interrupt Level: Eh ( 14 )
Adapter Revision Level: 71h
     Channel Connector: 32-bit
 Num Devices Supported: 30
   Num LUNs per Device: 32
   Num Logical Devices: 16
     DMA Pacing Factor: 100
  EOI to Interrupt Off: 1 msecs
 Max Adapter Busy Time: 30 secs
   Device Cache Status: 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 
   Device Retry Status: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 

------------------------------------------------------
Runstream (R) Query SPOCK / DOS       Beta Rel. 01.02
Copyright (C) UnalZ, 2006         All rights reserved.
------------------------------------------------------

> Correct data displayed now.
> 
> May 22, 2006: www.members.aon.at/mcabase/pub/files/QSPOCK.ZIP
> 
> To whom$ it may concern: Fixed your misordered AdapterInfo fields.
> 
> 
> 
>
0
David
5/23/2006 7:44:48 PM
Hi David,

> Do not know if you were looking for verification or not, but here is the
> results of running it on my "checked" 8595 booted to DOS 6.22.

Thank you for the test results. The more info we have about the different
flavors of IBM SCSI, the better we may know how to improve things. This
little program, and I'll probably add more features to it, is a "toy" to
play with before the real game begins.

I've got so far the most interesting result from the planar SCSI of Mod.
57/486SCL3. It has no adapter ID (or FFFF if you like), its DMA is disabled
and yet it measured about 25% higher transfer rates than the cached planar
Spock of Mod. 77. And it has a different, lower revision level.

Has anybody installed or tried to install Win9x on Mod. 57? Because the
miniport Spock driver assumes that all adapters responding to the ports
queried by QSPOCK, are DMA-enabled busmaster SCSI adapters, regardless of
the adapter ID !

> Do not know if you were looking for verification

Not only, I'd be glad to have more runs from different machines with
different adapter revision levels. I can't say yet if and what we would gain
if we play with the DMA Pacing Factor, the 100% (no pacing) is the power-on
default. This value can be changed at any time later while the adapter is
servicing requests.

So... where have all the other Spock fans gone?




0
UZnal
5/23/2006 10:21:47 PM
On Wed, 24 May 2006 00:21:47 +0200, UZnal wrote:

> I've got so far the most interesting result from the planar
> SCSI of Mod. 57/486SCL3. It has no adapter ID (or FFFF if you
> like), its DMA is disabled and yet it measured about 25%
> higher transfer rates than the cached planar Spock of Mod. 77.

So if no DMA, is it running in some kind of PIO mode?  What
happens to the processor load during transfers?

-- 

CL.

+-----------------------------------------+
| Charles Lasitter   | Mailing / Shipping |
| 401/728-1987       | 14 Cooke St        |
| cl+at+ncdm+dot+com | Pawtucket RI 02860 |
+-----------------------------------------+
0
Charles
5/24/2006 5:57:22 AM
> > I've got so far the most interesting result from the planar
> > SCSI of Mod. 57/486SCL3. It has no adapter ID (or FFFF if you
> > like), its DMA is disabled and yet it measured about 25%
> > higher transfer rates than the cached planar Spock of Mod. 77.
>
> So if no DMA, is it running in some kind of PIO mode?  What
> happens to the processor load during transfers?

QSPOCK applies the same procedure to all Spock-compatible, i.e. IBM SCSI,
adapters. It is not PIO, it is the Subsystem Control Block model, which is,
as I've noticed the about the same on the AHA-154x/1640/174x line of host
adapters.

Therefore, the planar SCSI of Mod. 57 is controlled exactly in the same
manner as the rest SCSIs, no any difference. But it must be somehow able to
access the passed buffer address (this will be always below 16 MB because
the machine is limited to 16 MB RAM).

How this happens is beyond my momentary knowledge of the topic. It could use
system DMA to do so, and the setting "DMA disabled" could mean that the
adapter alone and for itself is not a busmaster.

Below are the interpretations of the QSPOCK POS values according to the
Spock w/Cache techref. Note that the planar SCSI of Mod. 57 is not a
"Spock", so the Mod. 57 interpretations could be as well wrong. Mod. 77
should be correct, since it is IDed as Spock, i.e. 8EFF, unless the techref
is outdated.


First Mod. 57 settings, then Mod. 77:

POS Register [2]: 0 0 0 0 0 1 0 1
----------------------------------
7-4 = ROM Segment Address select:    C000
3-1 = Adapter I/O select:   3550 - 3557 (but presence detected at 3540 !!)
0   = Adapter enable: Yes

For Mod. 77: POS Register [2]: 0 0 0 0 0 0 0 1
------------
7-4 = ROM Segment Address select:    C000
3-1 = Adapter I/O select:   3540 - 3547
0   = Adapter enable: Yes


POS Register [3]: 1 1 1 0 0 0 0 0
-------------------------------
7-5 = SCSI ID:    7
4 = Fairness enable:    Disabled, prioriy selected by Arbitration Level
3-0 = Arbitration level:     0

For Mod. 77: POS Register [3]: 1 1 1 1 1 1 0 0
-----------
7-5 = SCSI ID:    7
4 = Fairness enable:    Enabled (configurable setting)
3-0 = Arbitration level:    Ch


POS Register [4]: 1 1 1 1 1 1 1 1
--------------------------------
7 = ROM BIOS Size:    32 KB ( = 0 is for 16 KB)
6-2 = Reserved
1 = ROM BIOS Enable:    Enabled
0 = ROM BIOS Wait State Disable:   No wait states are generated

For Mod. 77: POS Register [4]: 0 0 1 0 0 0 0 0     (FIXED Resource !)
-----------
7 = ROM BIOS Size:   16 KB
6-2 = Reserved
1 = ROM BIOS Enable:    Enabled
0 = ROM BIOS Wait State Disable:  One wait state is generated for ops to
BIOS


I could try to eliminate the wait state through the planar ADF and see what
effect it has on the performance.





0
UZnal
5/24/2006 1:02:51 PM
UZ, my little DEBbie shows DMA Arbitration Level as Level 8. No option 
to change port address.

Output from my little DEBbie (9556-DEB)

Port: 3540  Present
Port: 3548  --
Port: 3550  --
Port: 3558  --
Port: 3560  --
Port: 3568  --
Port: 3570  --
Port: 3578  --

( 1 ) IBM SCSI adapters found

Port 3540 : Status Information
-------------------------------
(05h)    Basic Control: 0 0 0 0 0 0 0 1
0     Interrupt Enable: Yes
1           DMA Enable: No
6-2           Reserved: --
7       Hardware Reset: No

(07h)     Basic Status: 0 0 0 0 0 1 0 0
0                 Busy: No
1    Interrupt Request: No
2  Cmd Interface Empty: Yes : Read by the adapter
3  Cmd Interface  Full: No  : Emptied by the adapter
7-4           Reserved: --

(06h) Interrupt Status: 0 0 0 1 1 1 1 1
3-0          Device-ID: F
7-4       Interrupt-ID: ( F ) SCB Command completed with success

SCB * Get Adapter Info: ( F ) SCB Command completed with success
             Adapter ID: FFFF
       POS Register [2]: 0 0 0 0 0 1 0 1
       POS Register [3]: 1 1 1 0 0 0 0 0
       POS Register [4]: 1 1 1 1 1 1 1 1
        Interrupt Level: Eh ( 14 )
Adapter Revision Level: 3h
      Channel Connector: 16-bit
  Num Devices Supported: 7
    Num LUNs per Device: 8
    Num Logical Devices: 16
      DMA Pacing Factor: 255
   EOI to Interrupt Off: 1 msecs
  Max Adapter Busy Time: 10 secs
    Device Cache Status: 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1
    Device Retry Status: 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1

------------------------------------------------------
Runstream (R) Query SPOCK / DOS       Beta Rel. 01.02
Copyright (C) UnalZ, 2006         All rights reserved.
------------------------------------------------------
0
Louis
5/24/2006 1:46:50 PM
Hi Unal,
> ...Note that the planar SCSI of Mod. 57 is not a "Spock",
> so the Mod. 57 interpretations could be as well wrong....
     Exactly, the microcontroller is an 8032, making it more like the
Tribble (and P75 planar, SCSI /A, SCSI 16/A, & 3550-002 Dock). If not tested
already (I've only been following the newsgroup with half an ear lately),
virtually all IBM SCSI devices at
http://www.ibmmuseum.com/Projects/SCSILEVL/ should be testable by me at this
point. As long as I can pull away from an otherwise busy schedule...
                               David
                               David@IBMMuseum.com


0
David
5/24/2006 2:29:11 PM
Hi �nal,

"UZnal" <unalz-at-mail333-dot-com> schreef in bericht 
news:44738afa$0$12941$91cee783@newsreader02.highway.telekom.at...
> Hi David,
>
>> Do not know if you were looking for verification or not, but here is the
>> results of running it on my "checked" 8595 booted to DOS 6.22.
>
> Thank you for the test results. The more info we have about the different
> flavors of IBM SCSI, the better we may know how to improve things. This
> little program, and I'll probably add more features to it, is a "toy" to
> play with before the real game begins.
>
> I've got so far the most interesting result from the planar SCSI of Mod.
> 57/486SCL3. It has no adapter ID (or FFFF if you like), its DMA is 
> disabled
> and yet it measured about 25% higher transfer rates than the cached planar
> Spock of Mod. 77. And it has a different, lower revision level.
>
> Has anybody installed or tried to install Win9x on Mod. 57? Because the
> miniport Spock driver assumes that all adapters responding to the ports
> queried by QSPOCK, are DMA-enabled busmaster SCSI adapters, regardless of
> the adapter ID !
>
>> Do not know if you were looking for verification
>
> Not only, I'd be glad to have more runs from different machines with
> different adapter revision levels. I can't say yet if and what we would 
> gain
> if we play with the DMA Pacing Factor, the 100% (no pacing) is the 
> power-on
> default. This value can be changed at any time later while the adapter is
> servicing requests.
>
> So... where have all the other Spock fans gone?

One 57SLC3 with W95 available; if memory serves the 57SLC2 has W95 as well.
Not sure about the 57SLC or the 77i.
And of course the mod 90 with W98SE !
I'll do some testing tomorrow (if the wife lets me....).


>
>
>
>

-- 
Jelte


0
JWR
5/24/2006 8:11:03 PM
Hi Jelte,

> One 57SLC3 with W95 available; if memory serves the 57SLC2 has W95 as
well.

Now that is interesting. The miniport driver does not care if DMA were
disabled or not, it treats the "black box" which responded to the port probe
always as a busmaster. That strategy obviously works, should the "busmaster"
setting have a significant meaning in Windows.

I am now more inclined to believe that "DMA Disabled" is intended to block
the "DMA Pacing Factor", not to let software change it.




0
UZnal
5/24/2006 10:37:42 PM
Hi David,

> > ...Note that the planar SCSI of Mod. 57 is not a "Spock",
> > so the Mod. 57 interpretations could be as well wrong....

>      Exactly, the microcontroller is an 8032, making it more like the
> Tribble (and P75 planar, SCSI /A, SCSI 16/A, & 3550-002 Dock).

I have slight doubts about the bits in the POS fields, but the rest is OK. I
don't think IBM invented a new communications model for the planar SCSI, it
is compatible to that described in the Spock techref. Because, not only
QSPOCK, but also any other Spock driver also wouldn't work if it were
incompatible to the "main" model.










0
UZnal
5/24/2006 10:45:09 PM
> > > ...Note that the planar SCSI of Mod. 57 is not a "Spock",
> > > so the Mod. 57 interpretations could be as well wrong....

> I have slight doubts about the bits in the POS fields, but the rest is OK.


OK, I know now what is happening. The POS fields are tied to the planar POS
bytes resp. to the particular ADF that came with the adapter. You have to
follow the settings scheme there to interpret the POS bytes coming from the
adapter.

The techref describes 8EFF (Spock) and 8EFE (Tribble), both have the same
ADFs. For Corvette, one has to follow the 8EFC.ADF assigments. For the
planar SCSIs, things are more complicated, you have to map the planar POS
indices relating to the SCSI configuration. Luckily, QUMC has done this
already, and QSPOCK has to only reinterpret the data according to the planar
POS choices.

I looked also at the Linux MCA driver, some POS interpretations are there
also not correct, especially those concerning the planar SCSIs. But I saw
there that Corvette delivers more data, I wouldn't be surprised if the
planar SCSIs do the same.

The Spock result buffer should be 18 bytes, but Corvette can deliver 256
bytes. A small part of it are the extended POS bytes, and I wonder what the
larger part would be. Vital Product Data (VPD), perhaps?





0
UZnal
5/25/2006 12:56:44 PM
UZnal schrieb:

> The Spock result buffer should be 18 bytes, but Corvette can deliver 256
> bytes. A small part of it are the extended POS bytes, and I wonder what the
> larger part would be. Vital Product Data (VPD), perhaps?

# lscfg -v -l ascsi0
   DEVICE            LOCATION          DESCRIPTION

   ascsi0            00-01             Wide SCSI I/O Controller Adapter

         Part Number.................006H6159
         EC Level....................001ZD64821
         Serial Number...............007580FY
         FRU Number..................092F0160
         Manufacturer................IBM97N
         Displayable Message.........SCSI-2FWSS
         Diagnostic Level............05
         Loadable Microcode Level....0001
         ROS Level and ID............71
         Device Driver Level.........00
         Device Specific.(ZB)........00

#

and the output of "lsattr"
# lsattr -El ascsi0
dma_bus_mem     0x442000 Address of bus memory used for DMA           False
dbmw            0x202000 DMA bus memory LENGTH                        True
tm_bus_mem      0x644000 Address of bus memory used for target mode   False
tm_dbmw         0x10000  Target mode bus memory length                True
bus_io_addr     0x3540   Bus I/O address                              False
bus_intr_lvl    11       Bus interrupt level                          False
intr_priority   3        Interrupt priority                           False
dma_lvl         5        DMA arbitration level                        False
internal_id     7        Internal bus SCSI ID                         False
external_id     7        External bus SCSI ID                         True
ext_bus_data_rt 10       Maximum synchronous data transfer rate (mHz) True
bb              no       BATTERY backed adapter                       True
ext_wide_enable yes      External bus wide enabled                    True
int_wide_enable yes      Internal bus wide enabled                    True

This is the VPD for a  PS/2 Corvette in a RS/6000.

-- 
Uli
0
Uli
5/25/2006 6:43:30 PM
> and the output of "lsattr"
> # lsattr -El ascsi0

This looks like a driver information...

> This is the VPD for a  PS/2 Corvette in a RS/6000.

Thanks, Uli, that helps. I have the MCA SSA RAID techref and it describes
the VPD fields for the SSA adapters, it is similar to that of Corvette, save
for the FRU.


POS subaddresses 16 through 155 contain Vital Product Data (VPD) for the
adapter
card.

An example of the layout of the adapter card VPD is:

V P D (00) L X X    (XX = CRC Value)
* P N (06) 1 2 3 4 5 6 7 8  (Part Number)
* S N (06) 1 2 3 4 5 6 7 8  (Serial Number)
* E C (07) 1 2 3 4 5 6 7 8 9 A (Engineering Change Level)
* M F (05) I B M 9 0 2   (Manufacturing Location)
* R L (06) 0 0 0 0 0 0 0 1  (ROS Level)
* L L (03) 0 4     (Loadable Microcode Level)
* D D (03) 0 0     (minimum Device Driver Level)
* D S (08) S S A - A D A P T E R (Description)
* Z 0 (06) D R A M = 0 0 8   (DRAM Size)
* Z 1 (06) C A C H E = 1   (Fast-Write Cache Size)
* Z 2 (10) 1 2 3 4 5 6 7 8 9 A B C D E F 0 (8-byte adapter ID as 16 ASCII
chars)


POS Subaddresses 220 through 255

POS subaddresses 220 through 255 contain the adapter error code when a
command had terminated with SS_POST2A_FAIL in the error register. These
error codes report failures that prevent the adapter from being used
normally.


POS Subaddress 257

Boot control

Bit 1 controls execution of the adapter microcode after an adapter reset. It
should normally be 0b. When the boot-control bit is set to 1b during an
adapter reset, the adapter does not branch out of the protected sectors of
the flash EPROM into the changeable sectors. In this state the adapter only
accepts the Download command. Following the Download command, the host
should reset the
boot-control bit to 0b and then perform an adapter reset. This activates the
new microcode and ensures that the adapter resets itself correctly after a
type-1 error.

If the host is not issuing a Download command after an adapter reset, POS
subaddress 257 should be set to zero to allow other commands to be
executed.





0
UZnal
5/25/2006 8:03:10 PM
Hi �nal,

"UZnal" <unalz-at-mail333-dot-com> schreef in bericht 
news:4474e1aa$0$3884$91cee783@newsreader01.highway.telekom.at...
> Hi Jelte,
>
>> One 57SLC3 with W95 available; if memory serves the 57SLC2 has W95 as
> well.
>
> Now that is interesting. The miniport driver does not care if DMA were
> disabled or not, it treats the "black box" which responded to the port 
> probe
> always as a busmaster. That strategy obviously works, should the 
> "busmaster"
> setting have a significant meaning in Windows.
>
> I am now more inclined to believe that "DMA Disabled" is intended to block
> the "DMA Pacing Factor", not to let software change it.
>


I've done some testing (my wife let me ;-)):
model   OS      ID
56SLC2  DOS     6C4T7
56SLC3  W95     1R5M3
57SLC   --      2V99L
77i     --      7P6VG
M77     W95SR2  5Z3L2
90      W95     0C6G5
90      W98SE   0G4H3

The ID's are the link to the QSPOCK-outputfiles on
http://www.depatrijs.demon.nl/Info-files/   (see file +info.txt)

HTTH
-- 
Jelte


0
JWR
5/25/2006 9:06:38 PM
Hi Jelte,

> I've done some testing (my wife let me ;-)):

OK, let me thank her for allowing the test runs ...;)

> The ID's are the link to the QSPOCK-outputfiles on
> http://www.depatrijs.demon.nl/Info-files/   (see file +info.txt)

I got them, thank you. I also found QUMC outputs from machines I did not
have results from, for instance, Mod. 85, 8557 and 9556.




0
UZnal
5/26/2006 6:34:50 PM
Hi �nal,

"UZnal" <unalz-at-mail333-dot-com> schreef in bericht
news:44774a1b$0$12925$91cee783@newsreader02.highway.telekom.at...
> Hi Jelte,
>
>> I've done some testing (my wife let me ;-)):
>
> OK, let me thank her for allowing the test runs ...;)


She says: you're welcome!

>
>> The ID's are the link to the QSPOCK-outputfiles on
>> http://www.depatrijs.demon.nl/Info-files/   (see file +info.txt)
>
> I got them, thank you. I also found QUMC outputs from machines I did not
> have results from, for instance, Mod. 85, 8557 and 9556.

I say you're welcome as well!

I've put some more files up; yesterday the connection was so terribly slow 
(6 files of 2-4kb each took 20-30 minutes!), I put up only the more recent 
files. I've added the rest; most include QUMC-output; QSPOCK didn't exist 
when I made these.

Relation of files to machinetype through machine-ID can be found here (if 
you hadn't found it already):
http://www.depatrijs.demon.nl/PSmain.htm

BTW : the XGA came in today; thanks for the little extra! I'll have a look 
at it tomorrow (if the wife...you know ;-))

-- 
Jelte



0
JWR
5/26/2006 10:23:15 PM
Hi Jelte,

> Relation of files to machinetype through machine-ID can be found here (if
> you hadn't found it already):
> http://www.depatrijs.demon.nl/PSmain.htm

Oooh, you are pretty MAD ...! I think, I understand now ...;)

This one is finishing today on eebay-de:

http://cgi.ebay.at/IBM-PS-2e-9533-silent-PC_W0QQitemZ8815273993QQcategoryZ21
926QQrdZ1QQcmdZViewItem






0
UZnal
5/27/2006 1:27:57 PM
Hi �nal,

"UZnal" <unalz-at-mail333-dot-com> schreef in bericht 
news:447853d5$0$3890$91cee783@newsreader01.highway.telekom.at...
> Hi Jelte,
>
>> Relation of files to machinetype through machine-ID can be found here (if
>> you hadn't found it already):
>> http://www.depatrijs.demon.nl/PSmain.htm
>
> Oooh, you are pretty MAD

 . . . . . . and looking for storagespace!

>
> This one is finishing today on eebay-de:
>
> http://cgi.ebay.at/IBM-PS-2e-9533-silent-PC_W0QQitemZ8815273993QQcategoryZ21
> 926QQrdZ1QQcmdZViewItem
>

Nice, very nice. Price is OK (yet), but shipping  :-/
I guess S&H is reasonable, yet steep compared to the price.

Thinking about it...

-- 
Jelte


0
JWR
5/27/2006 3:34:24 PM
Win9x build procedure produced a very suspicious binary, I did not like it
all. So I moved to NT4 build style, and managed somehow to build it under
W98SE without installing the NT4/DDK.

The games can begin, what a number this 206 ....;)

R u n s t r e a m   /   M C A B a s e
I B M   S P O C K 2 0 6   M i n i p o r t   D r i v e r   ( V e r s i o n
2 0 0 6 / 0 5 )
F i l e V e r s i o n     4 . 0 6 . 9 8
I n t e r n a l N a m e   S P O C K 2 0 6
O r i g i n a l F i l e n a m e   S P O C K 2 . S Y S
P r o d u c t V e r s i o n   4 . 0 6 . 9 8

It remains to be seen if this build would work at all. Next step is the INF
file.






0
UZnal
5/27/2006 8:06:12 PM
    When this built is not inherently dangerous, I will run it on my T3, 
when that pops, then I will slip in a Pentium complex.

UZnal wrote:
> Win9x build procedure produced a very suspicious binary, I did not like it
> all. So I moved to NT4 build style, and managed somehow to build it under
> W98SE without installing the NT4/DDK.
> 
> The games can begin, what a number this 206 ....;)
> 
> R u n s t r e a m   /   M C A B a s e
> I B M   S P O C K 2 0 6   M i n i p o r t   D r i v e r   ( V e r s i o n
> 2 0 0 6 / 0 5 )
> F i l e V e r s i o n     4 . 0 6 . 9 8
> I n t e r n a l N a m e   S P O C K 2 0 6
> O r i g i n a l F i l e n a m e   S P O C K 2 . S Y S
> P r o d u c t V e r s i o n   4 . 0 6 . 9 8
> 
> It remains to be seen if this build would work at all. Next step is the INF
> file.
> 
> 
> 
> 
> 
> 
0
Louis
5/27/2006 8:30:36 PM
UZnal wrote:
> The games can begin, what a number this 206 ....;)

Either due to my limited age, or limited exposure to life in general, 
the meaning of "206" escapes me.  Mayest someone taketh thy torch of 
wisdom and shinith hereunto me a deepening of understanding?

--Daniel

> 
> R u n s t r e a m   /   M C A B a s e
> I B M   S P O C K 2 0 6   M i n i p o r t   D r i v e r   ( V e r s i o n
> 2 0 0 6 / 0 5 )
> F i l e V e r s i o n     4 . 0 6 . 9 8
> I n t e r n a l N a m e   S P O C K 2 0 6
> O r i g i n a l F i l e n a m e   S P O C K 2 . S Y S
> P r o d u c t V e r s i o n   4 . 0 6 . 9 8
> 
> It remains to be seen if this build would work at all. Next step is the INF
> file.
> 
> 
> 
> 
> 
> 
0
Daniel
5/27/2006 8:31:39 PM
>     When this built is not inherently dangerous, I will run it on my T3,
> when that pops, then I will slip in a Pentium complex.

Let me first see the Block Compatibility Test and the performance. IRQ
handling eats too much cycles. What could be the effect of a different DMA
Pacing Factor?

> Pentium complex.

Enable wait states?




0
UZnal
5/27/2006 9:02:12 PM
Hi �nal,

"UZnal" <unalz-at-mail333-dot-com> schreef in bericht 
news:447853d5$0$3890$91cee783@newsreader01.highway.telekom.at...
> Hi Jelte,
>
>
> This one is finishing today on eebay-de:
>
> http://cgi.ebay.at/IBM-PS-2e-9533-silent-PC_W0QQitemZ8815273993QQcategoryZ21
> 926QQrdZ1QQcmdZViewItem
>


I tried, but was outbid (with a margin!!) by cmdr_doyle. It went for 44,94 
euro (excl shipping).

Too much for me.

-- 
Jelte


0
JWR
5/27/2006 9:47:35 PM
   Help me my disbelief. IRQ handling takes too many clock cycles? 
Sounds like bad code [bad code, naughty code, you MUST be punished!]. 
I'd expect PIO to eat cycles. It should be simple, CPU tells card to do 
something, card goes off and gets 'er done, then fires off an IRQ to 
tell the CPU it's done. Or, if this is a DMA thing, the card talks to 
the other device and gets 'er done.

   The XGA had an issue with detection of busy condition, but hopefully 
this is not the same brain dead problem?

> Let me first see the Block Compatibility Test and the performance. IRQ
> handling eats too much cycles. What could be the effect of a different DMA
> Pacing Factor?

DMA Pacing Factor? This should only be a problem if the devices involved 
in the DMA transfer can't speak at the same speeds, or if one device 
starts to bog down during the transfer. But it should identify what it 
can [or can't] do during the initial negotiation.

Each device should use a pin on the MCA bus in order to report their DMA 
capability, shouldn't they?

>> Pentium complex.
> Enable wait states?

Um, the default for SCSI adapters is to enable wait states. Remember the 
absence of DMA use under W98? The device does it during the operation, 
without involving the system.
0
Louis
5/28/2006 2:23:35 PM
>    Help me my disbelief. IRQ handling takes too many clock cycles?
> Sounds like bad code [bad code, naughty code, you MUST be punished!].

The code must do some cleanup and maintenance, this is unavoidable.
Servicing IRQ in protected mode is an expensive operation. As for the code,
you have to follow the OS model.

> I'd expect PIO to eat cycles.

It too uses IRQ for the completion of the operation.

> CPU tells card to do
> something, card goes off and gets 'er done, then fires off an IRQ to
> tell the CPU it's done.

The other mechanism is to disable the IRQ and watch the interrupt-busy bit.
The card will set it regardless of the interrupt status, enabled/disabled.
The best, however, would be a creative mix of both strategies.

> Or, if this is a DMA thing, the card talks to the other device and gets
'er done.

The other device in this case is the miniport driver.

>    The XGA had an issue with detection of busy condition, but hopefully
> this is not the same brain dead problem?

It didn't really have an issue, the XGA-style was applied to XGA-2 which
used a different method but it also could use the XGA-style. XGA206 fixed
and corrected that, it gave the XGA-2 its native method.

> DMA Pacing Factor? This should only be a problem if the devices involved
> in the DMA transfer can't speak at the same speeds, or if one device
> starts to bog down during the transfer. But it should identify what it
> can [or can't] do during the initial negotiation.

DMA transfers are initiated by the adapter. I look for further justification
of this setting.

> Um, the default for SCSI adapters is to enable wait states. Remember the
> absence of DMA use under W98? The device does it during the operation,
> without involving the system.

You can toggle them on Spock and Corvette, but not on Mod. 77/57. I was
thinking of patching the planar-77 ADF to disable them and see how the
planar SCSI reacts to it. Wait states should be controlled by bit-0 of
pos[26], which maps to pos[2] of 8EFF/Spock.

I couldn't map Mod. 57 to the Spock bytes, the POS scheme there is really
weird. I got only the two known settings (SCSI-ID/DMA-Arb) but that is all.




0
UZnal
5/28/2006 3:15:06 PM
Once the device acknowledges the operation, do we care about checking 
the IRQ? I would think the device signaling "done" would be what's 
needed. The error routine might be to set a wait time to czech after a 
reasonable interval.

Would the IRQ-busy be constantly watched [looped], or can the software 
execute when the IB is raised?

UZnal wrote:
> The other mechanism is to disable the IRQ and watch the interrupt-busy bit.
> The card will set it regardless of the interrupt status, enabled/disabled.
> The best, however, would be a creative mix of both strategies.
0
Louis
5/28/2006 6:27:20 PM
> Once the device acknowledges the operation, do we care about checking
> the IRQ? I would think the device signaling "done" would be what's
> needed. The error routine might be to set a wait time to czech after a
> reasonable interval.

The device, i.e. the adapter, since everything goes through the adapter,
ACKs the operation *only on command completion or error*, not before. While
it works it sets the busy bit (cannot accept new commands), and sets the
interrupt bit when it has completed and, if interrupts were enabled on the
adapter, fires the IRQ 14.

You've got in fact two signals: one is the bit and the other is the IRQ. You
must handle the IRQ if interrupts are enabled, but that does not clear the
interrupt bit. You are responsible for clearing the interrupt bit, you issue
EOI (end-of-interrupt) when you are done. This is clever, the adapter allows
you to check the status as many times as you wish.

You can see that in QSPOCK, this one below is the interrupt status on entry,
that of the last operation. Device-ID of F designates the adapter.

(06h) Interrupt Status: 0 0 0 1 1 1 1 1
3-0          Device-ID: F
7-4       Interrupt-ID: ( F ) SCB Command completed with success

The Basic Status register contains the "signals". (07h) is the offset from
the main I/O port, i.e. for 3540h this register would be at 3547h:

(07h)     Basic Status: 0 0 0 0 0 1 0 0
0                 Busy: No
1    Interrupt Request: No
2  Cmd Interface Empty: Yes : Read by the adapter
3  Cmd Interface  Full: No  : Emptied by the adapter
7-4           Reserved: --


> Would the IRQ-busy be constantly watched [looped], or can the software
> execute when the IB is raised?

To catch the IB raised and do something in between would require a separate
timer thread, but again you are constrained by the driver model and
facilities.

Normally, you check it, if busy then stall execution (i.e. wait a few
microsecs) then loop to check again, repeat until not-busy or timeout. But
the Linux MCA SCSI driver loops all the time and has no timeout condition,
that's definitely not so good.

This below is how Linux MCA SCSI waits, edited for clarity. This is an
example of how not to do it, this code eats cycles and may loop forever:

  /*must wait for attention reg not busy, then send EOI to subsystem */

  while (1)
   {
      if ((inb(IM_STAT_REG(host_index)) & 0xf) ==
                            (IM_CMD_REG_EMPTY | IM_INTR_REQUEST))
           break;
   }






0
UZnal
5/28/2006 10:05:33 PM
    Is there a weg to guesstimate on the time needed to run a set of 
commands? Yes, this would be an average, but life is not perfect.

    For X number of commands, we wait Y mS before czeching? Perhaps a 
bit of beta code [a logging app?] to derive some empirical figures? It 
will vary based on speed of transfer, but we can assume a few cases: 
narrow-slow, narrow-fast, wide-slow and wide-fast.

    The beta code would have to drive the adapter, collect transfer 
performance, and record the time to carry out the operations. I think 
that depending on the existing M$ driver will give us bad data.

    Smoking some blue weed, how about a final driver that regularly 
czechs the SCSI performance and changes the wait time to czech for the 
IB? Although I think that fielding a driver with settings for little and 
big commands would be the golden mean. Include the ability to detect the 
actual SCSI operations.

UZnal wrote:
> To catch the IB raised and do something in between would require a separate
> timer thread, but again you are constrained by the driver model and
> facilities.
> 
> Normally, you check it, if busy then stall execution (i.e. wait a few
> microsecs) then loop to check again, repeat until not-busy or timeout. But
> the Linux MCA SCSI driver loops all the time and has no timeout condition,
> that's definitely not so good.
> 
> This below is how Linux MCA SCSI waits, edited for clarity. This is an
> example of how not to do it, this code eats cycles and may loop forever:
> 
>   /*must wait for attention reg not busy, then send EOI to subsystem */
> 
>   while (1)
>    {
>       if ((inb(IM_STAT_REG(host_index)) & 0xf) ==
>                             (IM_CMD_REG_EMPTY | IM_INTR_REQUEST))
>            break;
>    }
> 
> 
> 
> 
> 
> 
0
Louis
5/28/2006 11:28:20 PM
>     Is there a weg to guesstimate on the time needed to run a set of
> commands? Yes, this would be an average, but life is not perfect.

Know your devices and collect empirical data.

>     For X number of commands, we wait Y mS before czeching? Perhaps a
> bit of beta code [a logging app?] to derive some empirical figures? It
> will vary based on speed of transfer, but we can assume a few cases:
> narrow-slow, narrow-fast, wide-slow and wide-fast.

Operations depend on the data length. If you read/write a block or two, that
will be quick, so you can just as well disable the IRQ for that operation,
unless you have a 2x IBM CD-ROM.

>     The beta code would have to drive the adapter, collect transfer
> performance, and record the time to carry out the operations. I think
> that depending on the existing M$ driver will give us bad data.

That is true.

>     Smoking some blue weed, how about a final driver that regularly
> czechs the SCSI performance and changes the wait time to czech for the
> IB? Although I think that fielding a driver with settings for little and
> big commands would be the golden mean. Include the ability to detect the
> actual SCSI operations.

A single-user desktop with fast disks and less multitasking could run faster
with IRQs disabled. But you can't dynamically change the wait time, that is
even not needed. You have to figure out when to use IRQ and when to use only
the interrupt status bit.

There is more to this. To efficiently use the Spock cache, you have to issue
READ_PREFETCH. But since requests are coming from the layer below, the
prefetch logic is too hard for the tiny brain of the miniport. I suspect,
Spock is doing nothing by its own initiative with the cache. It is a mere
decoration unless someone busies it. I didn't see any particular handling of
the cache in the techref, which as a matter of fact could have been much
better written.

> Although I think that fielding a driver with settings for little and
> big commands would be the golden mean. Include the ability to detect the
> actual SCSI operations.

That is what I call a "creative mix" and that could have been done at the
adapter. In a specific operation mode, it just tells you what to expect -
wait a little bit or go away, I will interrupt you. Human intelligence !

I once wrote a very big paper and I had an extra chapter that was analyzing
and recommending to watch humans at work to derive efficient serving models
for certain tasks. Somehow that chapter did not make it into the final
draft.






0
UZnal
5/29/2006 12:18:25 AM
Didn't you play with blocks as a small child? I recommend it.

Is there a weg to get the number of blocks in order to calculate the 
time needed for the operation to complete? Along with a calculated 
transfer rate, then we can say "blocks" divided by "transfer rate" 
equals "don't touch me" in milliseconds. There will be some slop time, 
due to setup and other oorts, but that could also be approximated with 
"blocks", mostly.

> Operations depend on the data length. If you read/write a block or two, that
> will be quick, so you can just as well disable the IRQ for that operation,
> unless you have a 2x IBM CD-ROM.

People tend to work a bit faster when being studied. But that is a 
drawback, because time-motion studies reflect the "idea" world, where 
everybody is pumping it out day in, day out. Look at the soviet 
experience with "norms" for how it worked out. Plus, sometimes the most 
"efficient" weg is not natural, and results in injury or scrap. 
Efficient is not always intuitive.

> I once wrote a very big paper and I had an extra chapter that was analyzing
> and recommending to watch humans at work to derive efficient serving models
> for certain tasks. Somehow that chapter did not make it into the final
> draft.
0
Louis
5/29/2006 12:59:21 PM
I am eliminating cycles. No DISK LIGHTS, don't care ...! It can't be the
task of a mass storage device driver to act as an illuminator.

> Didn't you play with blocks as a small child? I recommend it.

No, we threw stones to each other.

> Is there a weg to get the number of blocks in order to calculate the
> time needed for the operation to complete? Along with a calculated
> transfer rate, then we can say "blocks" divided by "transfer rate"
> equals "don't touch me" in milliseconds.

There is a way, and blocks belongs to a device which has a speed. You could
assume that your primary disk is fast enough and flex the communication with
it.

This should be the second phase, first we need an optimized and correctly
fine tuned miniport. I'd be glad if I can boost it by 10% for now. The
interrupt handler is a mish-mash crying for a clean up

> Look at the soviet  experience with "norms" for how it worked out.

There is always someone behind you who calculates your output and gives you
goals and targets. The Soviet experience failed because they forgot to
reward the individual getting or exceeding the norm, and kept forever the
individuals falling below the norm.

> Efficient is not always intuitive.

Once you have developed an intuition for it, it comes intuitively.








0
UZnal
5/29/2006 9:07:09 PM
Um, lights if error condition exists, otherwise, mums the word. Report 
if exception.

> I am eliminating cycles. No DISK LIGHTS, don't care ...! It can't be the
> task of a mass storage device driver to act as an illuminator.

Empire of the empirical.

> There is a way, and blocks belongs to a device which has a speed. You could
> assume that your primary disk is fast enough and flex the communication with
> it.

So the miniport is generic to the class (ie. "SCSI") and there are card 
specific drivers like "SPOCK", "SPARROW" and "BUSLOGIC".

> This should be the second phase, first we need an optimized and correctly
> fine tuned miniport. I'd be glad if I can boost it by 10% for now. The
> interrupt handler is a mish-mash crying for a clean up
0
Louis
5/29/2006 10:50:18 PM
Perhaps a better error reporting capability instead of that damnable 
[non]Event Viewer. So if there is an error in the SCSI system, you can 
view it from the SCSI adapter's point of view.

Louis Ohland wrote:
> Um, lights if error condition exists, otherwise, mums the word. Report 
> if exception.
> [non]Event Viewer.
>> I am eliminating cycles. No DISK LIGHTS, don't care ...! It can't be the
>> task of a mass storage device driver to act as an illuminator.
> 
> Empire of the empirical.
> 
>> There is a way, and blocks belongs to a device which has a speed. You 
>> could
>> assume that your primary disk is fast enough and flex the 
>> communication with
>> it.
> 
> So the miniport is generic to the class (ie. "SCSI") and there are card 
> specific drivers like "SPOCK", "SPARROW" and "BUSLOGIC".
> 
>> This should be the second phase, first we need an optimized and correctly
>> fine tuned miniport. I'd be glad if I can boost it by 10% for now. The
>> interrupt handler is a mish-mash crying for a clean up
0
Louis
5/29/2006 10:53:12 PM
One reason for the missing DMA settings could have been the misordered
AdapterInfo structure, I fixed it. When you read the techref and look at the
result template, you might be somehow tempted to follow the ordering there,
to read from left to right as you read this text. But this is wrong, very
wrong, because the template is ordered from high to low word. Hence, you
have to read the fields backwards, from right to left, and define your
structure fields accordingly. Thank you QSPOCK...!

Since the structure was misordered, the boy could not get any m$eaningful
results for certain fields, perhaps he just skipped them. Anyway, I am
inserting these, see below.

You have to manually perform reassignment of bad blocks, Spock doesn't do it
by itself. Error handling is tough.

Do we have a Corvette-PDF .... ?


 // check for Corvette

 if ( pAdapter->AdapterInfo.AdapterId == 0x8EFC )
 {
      pAdapter->Scb.BufferLength  = VPD_BUF_SIZE;
      bCorvette = IssueGetPOS( pHwDeviceExtension, uPhysicalAdapterInfo );
 }

 if ( bCorvette )
 {
      // handle Corvette specifics
 }

 // DmaChannel = DMA Arb Level
 //     Specifies the DMA channel used by the host bus adapter.
 //     The uninitialized value is 0xFFFFFFFF.

 // Get DMA arbitration level for Tribble, Spock or Corvette
 // POS[3] (0x103h) / pos[1] :: 3-0 = Arbitration level
 // Mod. 57 not known

 if ( pAdapter->AdapterInfo.AdapterId == 0x8EFE ||
       pAdapter->AdapterInfo.AdapterId == 0x8EFF ||
       pAdapter->AdapterInfo.AdapterId == 0x8EFC )
 {
  pConfigInfo->DmaChannel = pAdapter->AdapterInfo.PosRegister3 & 0x0F;
 }

 // DmaWidth = connector size
 //      Specifies the width of the DMA transfer. The uninitialized
 //      value is zero. Accepted widths are 8, 16, 32, and maximum DMA
widths.
 // Dma32BitAddresses
 //      Indicates that the HBA has 32 address lines and can access memory
 //      with physical addresses greater than 0x00FFFFFF.

 if ( pAdapter->AdapterInfo.ChannelConnector )
 {
      pConfigInfo->DmaWidth = Width16Bits;
      pConfigInfo->AlignmentMask = 1;
 }
 else
 {
      pConfigInfo->DmaWidth = Width32Bits;
      pConfigInfo->Dma32BitAddresses = TRUE;

      // AlignmentMask
      // Is a mask indicating the alignment boundary for buffers required by
      // the HBA for transfer operations. Valid bitsets are 1, 3, 7, and so
on.

      pConfigInfo->AlignmentMask = 3;
 }

 // check bad firmware

 if ( pAdapter->AdapterInfo.RevisionLevel == 0xF )







0
UZnal
5/29/2006 11:32:28 PM
> Um, lights if error condition exists, otherwise, mums the word. Report
> if exception.

Red lights? No lights, forget it.

> So the miniport is generic to the class (ie. "SCSI") and there are card
> specific drivers like "SPOCK", "SPARROW" and "BUSLOGIC".

The card specific drivers are the miniport drivers, the main driver is the
SCSI Port driver. The port driver passes to the miniport a Service Request
Block (SRB) which the miniport translates into the adapter "language" and
manages adapter I/O operations.


Perhaps a better error reporting capability instead of that damnable
[non]Event Viewer. So if there is an error in the SCSI system, you can
view it from the SCSI adapter's point of view.







0
UZnal
5/30/2006 12:02:15 AM
> Perhaps a better error reporting capability instead of that damnable
> [non]Event Viewer. So if there is an error in the SCSI system, you can
> view it from the SCSI adapter's point of view.

The LED display panel of Mod. 95 for "debug" mode.




0
UZnal
5/30/2006 12:04:33 AM

UZnal wrote:
> 
> Red lights? No lights, forget it.


Hey, I like lights. Lights are good, lights can be our friends....

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

UZnal wrote:
> 
> The LED display panel of Mod. 95 for "debug" mode.


Now you're talking. You might even get me to infest a 95 with Win9x for
that.

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

> Hey, I like lights. Lights are good, lights can be our friends....

I'm all for lights, but on our machines it may not be that much of an
issue. Win95 and 98 both turn off the drive access light when you use a
Future Domain MCS 600/700/Patriot card.

Win98 turns off the IDE hard disk light on the Lacuna board. Win95 does
the same with a PS/2 Model 53 with factory installed Reply board. (And
you must use the "no serialization" IDE driver in Win95 with the 53.
Otherwise you get very serious crashes.)

Over this weekend, while trying to hide from the 95 degree heat, I
reloaded Win98SE with an NCR host adapter. I used the same Pentium
60-fired Model 90 and the NCR dual SIOP does not run in protected mode.

That's IBM, Adaptec and NCR so far that fail. I can try the BusTek
BT-640, but it is NCR based.

I wonder if the Cheetah RAID controller has any protected mode support
under Win98SE? Never ran one outside of NT 4.0 Server.

If there's going to be a beta driver offered for testing purposes, I'm
interested in doing whatever I can to help.

William

0
wm_walsh
5/30/2006 2:28:25 PM
No. I tried it earlier.

> I wonder if the Cheetah RAID controller has any protected mode support
> under Win98SE? Never ran one outside of NT 4.0 Server.
0
Louis
5/30/2006 4:38:07 PM
> > Hey, I like lights. Lights are good, lights can be our friends....
>
> I'm all for lights, but on our machines it may not be that much of an
> issue.

Light is on when the adapter is busy, and that is all. Your CD-ROM is busy
but the disk light would be on, that isn't clever either. Port read/write
access is not gratis, you devote cycles to it.

> If there's going to be a beta driver offered for testing purposes

I have to first replay the ceremony, stay tuned.






0
UZnal
5/30/2006 7:39:49 PM
IBM MCA SCSI Miniport Driver SPOCK-206 for Windows 95/98/NT:

May 30, 2006: http://www.members.aon.at/mcabase/pub/files/spock206.zip

Installed and tested on W95 special MSDN version, Mod. 77 planar SCSI/8EFF,
i.e. Spock. Measured immediately 10% performance boost in the dark ....!!!

DMA resource added, but Windows showed the wrong Arb Level, never mind. See
INSTALL.TXT for installation instructions. Corvette support not yet added.
No disk activity light ....;)

As usual, I'll append your test reports to the README which is not yet
created.

I run the Block Compatibility Tests, all PASSED until I stopped them to
write this message and post the news. Optimizations continue, the driver is
not finished.

Gentlemen, start your engines ....!




0
UZnal
5/30/2006 9:58:13 PM
> IBM MCA SCSI Miniport Driver SPOCK-206 for Windows 95/98/NT:
>
> May 30, 2006: http://www.members.aon.at/mcabase/pub/files/spock206.zip


Updated INSTALL.TXT since the last posting, get it again.


> Measured immediately 10% performance boost

IBM DORS disk, average results with CORETEST (DOS program), latest test:

DOS
    2,800 KB/secs - DOS

SPOCK-206
    2,500 KB/secs - Windows DOS prompt, full screen

Windows Spock:
    2,200 KB/secs - Windows DOS prompt, full screen

The improvement is on the average 300 KB/secs. Close to 15% and more than
10%, because Coretest delivers at times slightly different results on each
run.

We need a Windows benchmark, better more benchmarking programs to compare
the results.




0
UZnal
5/30/2006 10:46:22 PM
Its been raining on and off today, so far we're at 1.5", short version 
I'm not lighting it up right now.

OK, like the driver, you install this over the M$ SPOCK.

I see that you have IRQ14 only at this point.

I wonder what this will do with a Pentium complex.

UZ, point us to the benchmark that will be used so we all are speaking 
the same dialect. Also, what test regimen are you using?

UZnal wrote:
>> IBM MCA SCSI Miniport Driver SPOCK-206 for Windows 95/98/NT:
>>
>> May 30, 2006: http://www.members.aon.at/mcabase/pub/files/spock206.zip
> 
> 
> Updated INSTALL.TXT since the last posting, get it again.
> 
> 
>> Measured immediately 10% performance boost
> 
> IBM DORS disk, average results with CORETEST (DOS program), latest test:
> 
> DOS
>     2,800 KB/secs - DOS
> 
> SPOCK-206
>     2,500 KB/secs - Windows DOS prompt, full screen
> 
> Windows Spock:
>     2,200 KB/secs - Windows DOS prompt, full screen
> 
> The improvement is on the average 300 KB/secs. Close to 15% and more than
> 10%, because Coretest delivers at times slightly different results on each
> run.
> 
> We need a Windows benchmark, better more benchmarking programs to compare
> the results.
> 
> 
> 
> 
0
Louis
5/31/2006 1:28:50 AM
Updated package, same driver. README included, links included:

May 31, 2006: http://www.members.aon.at/mcabase/pub/files/spock206.zip


SPOCK-206 is an acronym for SPOCK Miniport Driver 2006. The driver is
based on code samples published by Microsoft Corp. in the Windows 95 DDK.
You can find the code samples in the MSDN Subscription Collection 1995-96.



> UZ, point us to the benchmark that will be used so we all are speaking
> the same dialect.

CORETEST http://www.members.aon.at/mcabase/pub/files/coretest.zip


> Also, what test regimen are you using?

The Block Compatibility Test (BCT) form the Windows 95 DDK CD. It is a big
piece, too big for the dial-up, I have to see the ZIP size of it. But I'd
like to have it out, the tests take too long, I have neither that much time
nor the patience.


> I'm not lighting it up right now.

Lights are at the end of the tunnel. Let me see what % they'd waste.


> OK, like the driver, you install this over the M$ SPOCK.

Sure, I use the Windows SCSI.INF settings, customized of course. Did not
make any problems here. As expected, the first version failed, it copied the
driver to the wrong dir. The second version worked, after I got the INF
directory codings from MSDN Lib.


> I see that you have IRQ14 only at this point.

I want to first have assurance with QSPOCK that I read correctly the
extended Corvette POS bytes. It is a second call to the adapter in this
case, with a larger result buffer (256 bytes vs. 18 bytes). I don't have
Corvette in the test machine,  it is currently in Mod. 95/NT4SP6 which is
deep under the desk.


> I wonder what this will do with a Pentium complex.

IOS (Input Output Supervisor) loads the miniport. IOS has a list of safe
drivers, all look to me as being DOS drivers. PLEXTOR.SYS is marked as
unsafe. IOS mainly deals with IDE drives.

Interesting to note, while there are almost all equivalent functions in IOS,
SCSI drivers are isolated and confined to calls to functions in
SCSIPORT.LIB. That might explain why Windows is talking of "compatibility
mode" drivers, they are sort of invisible to IOS.

IOS.INI ( C:\WINDOWS )
    ...........
    [CDUnsafe]
    plextor.sys     ; Plextor 6plex cd-rom driver.

IOS.VXD ( C:\WINDOWS\SYSTEM\VMM32)
     ...........
     Unsafe CDROM driver, %s, disabling protect mode CDROM

IOSCLASS.DLL ( C:\WINDOWS\SYSTEM )
    .....
    IOSCLASS - IOS Device Class Class Installer


There is a section [SPOCK.hw] in the INF file which is not directly
referenced from another section. I want to have a closer look at the
registry, especially if this setting leaves any traces there. These below
are from SCSI .INF which I duplicated:

[StdIOS]
HKR,,DevLoader,,*IOS            ; standard IOS loads the driver
HKR,,DontLoadIfConflict,,"Y"    ; do not load in case of conflicts

[SPOCK.AddReg]
HKR,,PortDriver,,spock2.mpd    ; add SPPOCK-206 key

[SPOCK.hw]
AddReg=IOSMCA        ; who referendes this section ...???

[IOSMCA]
HKR,,ConfigFlags,1,00,02,00,00        ; must be checked !!!






0
UZnal
5/31/2006 2:25:41 PM
Optimized interrupt handling, though one wouldn't notice it:

May 31, 2006: http://www.members.aon.at/mcabase/pub/files/spock206.zip


WARNING: Do NOT delete/cleanup the SPOCK-206 INF file from the \WINDOWS\INF
directory. If you do, the tab "Driver" in the Device Properties vanishes and
you cannot change/update the driver. The applet also seems to forget which
resources the driver had. That's a magnificient win-design ....;)

If you accidentally do, you have to look at the registry to see which
OEMx.INF file 95 expects to find. In such a case, copying the original
SPOCK206.INF file to OEMx.INF restores the situation.





0
UZnal
5/31/2006 6:44:09 PM
Hi!

> No disk activity light ....;)

I am curious to know (and don't think it's been discussed in a great
deal of detail)...why turn the light off and keep it that way? Is it
really for performance reasons only?

> Gentlemen, start your engines ....!

I will be trying the on-planar SCSI of a 9585-0XF ("Defiant") tonight
to see what happens with Win95 OSR2. This computer has 64MB RAM and a
133MHz AMD CPU.

William

0
wm_walsh
5/31/2006 7:51:42 PM
> > No disk activity light ....;)
>
> I am curious to know (and don't think it's been discussed in a great
> deal of detail)...why turn the light off and keep it that way? Is it
> really for performance reasons only?

Only for performance reasons, nothing else. Each time you fiddle with the
light bulb, you make two port accesses, and that comes at a price in
protected mode and transferring large amount of data from here to there. I
want to make it faster, and besides this, I personally never watch the disk
activity light (how could I, the machines are either below the desk or rest
sideways, so little space here). But let us be user-friendly ....;)

Usually, you turn on the light when you are speaking to the adapter, and
turn it off when you've handled its interrupt. The disk activity light does
not necessarily say it was the disk you accessed ! It only indicates
communication with the adapter. To be strict, I have to look at the target
IDs and find out which one is disk, CD, tape, scanner and so on, to be able
to isolate the disks and manage the lights. That is too much overhead for
too little gain and I am just blindly turning on and off the lights.

Before it becomes a light issue, I have enabled the disk lights. Get the new
build.




0
UZnal
5/31/2006 9:54:06 PM
Let there be light ...

 May 31, 2006: http://www.members.aon.at/mcabase/pub/files/spock206.zip

SPOCK-206 will manage the disk lights on your machine to indicate
communications with the SCSI host adapter. The disk activity light in
such cases does not necessarily imply your fixed disks are being accessed.

The bulb cuts down about 1% - 2% of the total disk transfer rate. Cheap, uh?






0
UZnal
5/31/2006 10:04:32 PM
On Wed, 31 May 2006 22:04:32 UTC, "UZnal" <unalz-at-mail333-dot-com> 
wrote:

> Let there be light ...
> 
>  May 31, 2006: http://www.members.aon.at/mcabase/pub/files/spock206.zip
> 
> SPOCK-206 will manage the disk lights on your machine to indicate
> communications with the SCSI host adapter. The disk activity light in
> such cases does not necessarily imply your fixed disks are being accessed.
> 
> The bulb cuts down about 1% - 2% of the total disk transfer rate. Cheap, uh?

It's better to set a flag in memory, and check that on each clock tick. 
Record the current state of the light in another bit in the same byte, 
and you access the port only when the state changes. In fact, you miss a
lot of state changes but at the clock frequency that is of no 
consequence.

-- 
Bob Eager
rde at tavi.co.uk
PC Server 325; PS/2s 8595*3, 9595*3 (2*P60 + P90), 8535, 8570, 9556*2, 
8580*6,
8557*2, 8550, 9577, 8530, P70, PC/AT..
http://www.tavi.co.uk
http://www.ardent-tool.org.uk

0
Bob
5/31/2006 10:57:36 PM
Hi!

> To be strict, I have to look at the target
> IDs and find out which one is disk, CD, tape, scanner and so on, to be
able
> to isolate the disks and manage the lights. That is too much overhead for
> too little gain and I am just blindly turning on and off the lights.

Ah, yes...it seems that the M$ drive must (or does) do the same thing. I
don't recall offhand if CD-ROM drives trigger the lights, but tape drives
and scanners don't appear to.

> Before it becomes a light issue, I have enabled the disk lights. Get the
new
> build.

Oh, I don't mind one way or the other. In fact, I was thinking of trying the
"light disabled" build first. I seldom look at the disk light either. If
anything, I wonder if systems using on-planar IBM MCA SCSI would use the
light anyway regardless of what your driver says. I also wonder if this is
why M$ turns off the light when you have IBM/Reply on-planar IDE or the
Future Domain MCS-600/700/Patriot running under protected mode control.

Is a user selectable choice for light or none possible? I know there's a
space in device manager to pass parameters to the SCSI adapter and maybe
even the driver.

William


0
William
5/31/2006 11:17:59 PM
On 31 May 2006 22:57:36 GMT, Bob Eager wrote:

> In fact, you miss a lot of state changes but at the clock
> frequency that is of no consequence.

I'd be the LED would qualify as a kind of "long phosphor" such
that you might never see the difference either ...

-- 

CL.

+-----------------------------------------+
| Charles Lasitter   | Mailing / Shipping |
| 401/728-1987       | 14 Cooke St        |
| cl+at+ncdm+dot+com | Pawtucket RI 02860 |
+-----------------------------------------+
0
Charles
6/1/2006 5:32:58 AM
On Thu, 1 Jun 2006 05:32:58 UTC, Charles Lasitter <cl@ncdm.com> wrote:

> On 31 May 2006 22:57:36 GMT, Bob Eager wrote:
> 
> > In fact, you miss a lot of state changes but at the clock
> > frequency that is of no consequence.
> 
> I'd be the LED would qualify as a kind of "long phosphor" such
> that you might never see the difference either ...

You don't...I implemented this approach years ago in a DOS version of 
the same thing, and it worked fine...the OS/2 driver also seems to do it
that way.

-- 
Bob Eager
rde at tavi.co.uk
PC Server 325; PS/2s 8595*3, 9595*3 (2*P60 + P90), 8535, 8570, 9556*2, 
8580*6,
8557*2, 8550, 9577, 8530, P70, PC/AT..
http://www.tavi.co.uk
http://www.ardent-tool.org.uk

0
Bob
6/1/2006 6:34:12 AM
Hi!

Well, I had a brief setback before I got to test the Model 85 "X". The
Kingston Turbochip fan has been making threatening noises for a while now,
but tonight the fan just decided to call it quits. I replaced it with a
comparatively large Pentium I heatsink that I took the fan off of. I had to
break off a few fins to make it fit around the PSU. Interested parties can
see what I did here:

http://greyghost.dyndns.org/another-KTC-heatsink/

All pictures are 640x480 and between 30-56KB in size.

That said, here's the results I got from the two different SCSI drivers
using CORETEST. (Interestingly enough, there sits a Model 80 not 20 feet
away that has a Core International ESDI controller and dual 700MB hard
disks...)

Microsoft Driver (CORETEST windowed): 2187.5KB/s
UZ's Driver (CORETEST windowed): 2257.5KB/s
UZ's Driver: (CORETEST fullscreen): 2540.3KB/s

I totally forgot to do a test with the M$ driver and CORETEST running
fullscreen. Will see about one later, but tomorrow is a busy day.

Attached to the onboard IBM MCA SCSI are an IBM DCAS 32160 (a good
performing, quiet and and cool running drive) and a Toshiba XM-6401TA CD-ROM
drive. For other machine specs, see the sig below.

The performance of the system feels much faster than normal. I don't have
hard numbers for the CD-ROM drive, but copying files from the Office 97 CD
felt noticeably faster.

So far the system is reliable (and the activity LED is working). I think it
can be said that the Model 85 "X" is OK with this driver.

William
--
Brought to you by an IBM PS/2 9585-0XF, "Defiant"
AMD 486-133/64MB/2GB S/N 23HN457


0
William
6/1/2006 7:16:16 AM
> It's better to set a flag in memory, and check that on each clock tick.
> Record the current state of the light in another bit in the same byte,
> and you access the port only when the state changes. In fact, you miss a
> lot of state changes but at the clock frequency that is of no
> consequence.

Wouldn't that result in more overhead? State changes are in my case confined
to the entry and exit points, and these are ON on issuing the Control Block,
and OFF on processing the results from the adapter. These are known
lightbulb-points and firm under control.

When I said "blindly turning on and off the lights" I meant being blind to
the target, i.e. the light is ON regardless of the target except for the few
Immediate Commands which concern only the adapter.

Light ON/OFF is through 0x92 System Control Port A - read first, toggle the
bit and then write back.

I do think, it should have been the task of the adapter/hardware to take
care of the lights. But it doesn't do it and we have to compensate that.






0
UZnal
6/1/2006 11:23:58 AM
> Ah, yes...it seems that the M$ drive must (or does) do the same thing.

Linux MCA does the same thing, more overhead when accessing the LED panel of
Mod. 95.

      /* Read/write on this non-disk devices is also displayworthy,
         so flash-up the LED/display. */

      if (++disk_rw_in_progress == 1)
        PS2_DISK_LED_ON (shpnt->host_no, target);


> don't recall offhand if CD-ROM drives trigger the lights, but tape drives
> and scanners don't appear to.

CD-ROM should do, because it is under Spock control. Tape drives not quite
so, since Spock does not fully support their command set (variable block
lengths). Spock provides the option of sending an "unknown" to it Control
Block to a device, sort of pass through. This allows you to directly manage
the specifics of a device without needing the adapter to understand
everything, it will just relay the request ("long SCB") to the device. It is
for this reason why a tape drive needs a specific backup driver.

However, if you use Spock to relay the long SCB, the light will go on/off,
but that is not the case in SPOCK-206, no long SCBs there since you don't
know what it is.

> Is a user selectable choice for light or none possible? I know there's a
> space in device manager to pass parameters to the SCSI adapter and maybe
> even the driver.

Parameters would mean checking for them all the time. I first did a second
build and edited the INF to allow for the selection and installation of a
driver with lights enabled and another one with lights disabled. I could go
back to this scheme in the final beta release, i.e. you would select which
version to install.





0
UZnal
6/1/2006 11:41:57 AM
> Microsoft Driver (CORETEST windowed): 2187.5KB/s
> UZ's Driver (CORETEST windowed): 2257.5KB/s

Windowed DOS is impaired by display issues, it won't deliver correct timings
to CORETEST. Better avoid it, use only full screen.

> The performance of the system feels much faster than normal. I don't have
> hard numbers for the CD-ROM drive, but copying files from the Office 97 CD
> felt noticeably faster.

I experienced the same effect, the system became more responsive. Execution
stall times are small, and planar SCSIs react fast. The adapter Spock may
not react that fast.

> So far the system is reliable (and the activity LED is working). I think
it
> can be said that the Model 85 "X" is OK with this driver.

What DMA level do you see in the resources? Does it match that of SysConfig?



0
UZnal
6/1/2006 11:47:08 AM
On Thu, 1 Jun 2006 11:23:58 UTC, "UZnal" <unalz-at-mail333-dot-com> 
wrote:

> > It's better to set a flag in memory, and check that on each clock tick.
> > Record the current state of the light in another bit in the same byte,
> > and you access the port only when the state changes. In fact, you miss a
> > lot of state changes but at the clock frequency that is of no
> > consequence.
> 
> Wouldn't that result in more overhead? State changes are in my case confined
> to the entry and exit points, and these are ON on issuing the Control Block,
> and OFF on processing the results from the adapter. These are known
> lightbulb-points and firm under control.

Hardly. It's abiut a 10 instruction additional path on a clock tick.

> Light ON/OFF is through 0x92 System Control Port A - read first, toggle the
> bit and then write back.

I'm perfectly aware of that - I was programming this stuff 14 years ago!

-- 
Bob Eager
rde at tavi.co.uk
PC Server 325; PS/2s 8595*3, 9595*3 (2*P60 + P90), 8535, 8570, 9556*2, 
8580*6,
8557*2, 8550, 9577, 8530, P70, PC/AT..
http://www.tavi.co.uk
http://www.ardent-tool.org.uk

0
Bob
6/1/2006 1:14:36 PM
Hi!

> Windowed DOS is impaired by display issues, it won't deliver correct
> timings to CORETEST. Better avoid it, use only full screen.

I'll rerun the test. It occurred to me only mid-way through the tests
that you'd run them fullscreen.

> I experienced the same effect, the system became more responsive. Execution
> stall times are small, and planar SCSIs react fast. The adapter Spock may
> not react that fast.

I'd be surprised if you didn't have test data from someone with a card
based Spock yet, but I'll be trying it here as soon as I can. I also
plan to try the short and long uncached cards to see what they do.

> What DMA level do you see in the resources?
> Does it match that of SysConfig?

Seven was the level reported on my system in the resources tab. I don't
know if it matches the system configuration or not...didn't think to
check on that.

Something I did notice was that the "driver" tab of the Spock-206
properties page said that "no driver files are required or have been
loaded for this device".

William

0
wm_walsh
6/1/2006 1:37:55 PM
Hi!

> CD-ROM should do, because it is under Spock control.

I tried copying files from CD-ROM (Toshiba XM-6401, Model 9585-0XF)
shortly after my last posting here in the early morning.

To minimize any likelihood of the hard disk doing anything, I copied
the files to the network. The only activity light I saw was that of the
CD-ROM drive.

Interestingly enough, the drive (which I'd forgotten was a nice fast
40X unit) caused the power supply fan to spin up to a higher speed "in
tune" with its seeking around for data. The old MS driver for the Spock
had never exhibited such behavior, and system configuration has been
constant for some time. Perhaps the faster data transfer results in a
little more power draw...

> Parameters would mean checking for them all the time. I first did a second
> build and edited the INF to allow for the selection and installation of a
> driver with lights enabled and another one with lights disabled. I could go
> back to this scheme in the final beta release, i.e. you would select which
> version to install.

I think that would be a good way to implement the choice.

William

0
wm_walsh
6/1/2006 1:49:39 PM
    Having some interesting microchannel maneuvers here. Took out the 
NCR dual channel SCSI adapter [that has no ADF that works], then ran 
into some memory troubles, 90 is having difficulty with SIMMs with 
horizontal chips. Running memory diags now, and if/when I get 'er up, 
I'll run W98SE with narrow Corvette.
0
Louis
6/1/2006 1:59:34 PM
Ctrl-A, test memory, quick test.

Error. Suspect processor board failed FRU 57F1597

Errors in J14/J1 and J14/J2

Testing the complex now.

Louis Ohland wrote:
> 
>    Having some interesting microchannel maneuvers here. Took out the NCR 
> dual channel SCSI adapter [that has no ADF that works], then ran into 
> some memory troubles, 90 is having difficulty with SIMMs with horizontal 
> chips. Running memory diags now, and if/when I get 'er up, I'll run 
> W98SE with narrow Corvette.
0
Louis
6/1/2006 2:06:04 PM
    Seeing CORETEST pop up brings back memories of dial up BBS.

    Installed it over existing SPOCK. Windows said there was a conflict 
and did I want to remove conflicting device? I said yes, and it warm 
rebooted. Settings were wrong, so I reset the I/O address. Rebooted, ran 
System Programs to set DMA to 7 [default is C], disabled DMA on the 
parallel port [never used it anyways], and tried to re-enter W98SE, 
which hung during the green screen, cursor with hour-glass. Shut down, 
power off, back in Safe Mode, it works [ as much as safe mode does], 
rebooted into W98SE, a bit of disk thrash, then I was in.

M$ SPOCK - 4212.4 KB/sec

SPOCK206 - 7588.9 KB/sec

CORETEST bitches about probable caching and humma, humma, humma.

Model 90, 64MB of FPM, Corvette [.77 flash], narrow, 1.08 DPES-31080, 8x 
CD [untested].

I swapped out the memory in J14 / J1 and J2. No more error messages. I 
tested the complex specifically, and it passed. I would guess that the 
memory error triggered a sympathetic hiccup in the complex.

Louis Ohland wrote:
> Ctrl-A, test memory, quick test.
> 
> Error. Suspect processor board failed FRU 57F1597
> 
> Errors in J14/J1 and J14/J2
> 
> Testing the complex now.
> 
> Louis Ohland wrote:
>>
>>    Having some interesting microchannel maneuvers here. Took out the 
>> NCR dual channel SCSI adapter [that has no ADF that works], then ran 
>> into some memory troubles, 90 is having difficulty with SIMMs with 
>> horizontal chips. Running memory diags now, and if/when I get 'er up, 
>> I'll run W98SE with narrow Corvette.
0
Louis
6/1/2006 3:04:39 PM
I popped in a Turbo-Y. After some funny ha-ha diddling with detected 
memory, it worked.

SPOCK206 triggered [UN]protected mode.

 > Model 90, Y-180 complex, 64MB of FPM, Corvette [.77 flash], narrow, 
1.08 DPES-31080, 8x CD [untested].:
 > SPOCK206 - 577.8 KB/sec [8580 w/70MB ESDI drive beats that!]

 > Model 90, M complex, 64MB of FPM, Corvette [.77 flash], narrow, 1.08 
DPES-31080, 8x CD [untested].:
> M$ SPOCK - 4212.4 KB/sec
> SPOCK206 - 7588.9 KB/sec
> 
> CORETEST bitches about probable caching and humma, humma, humma.> 
0
Louis
6/1/2006 3:36:54 PM
> Interestingly enough, the drive (which I'd forgotten was a nice fast
> 40X unit) caused the power supply fan to spin up to a higher speed "in
> tune" with its seeking around for data. The old MS driver for the Spock
> had never exhibited such behavior, and system configuration has been
> constant for some time. Perhaps the faster data transfer results in a
> little more power draw...

You are experiencing the significance of microseconds. The CD-ROM drive can
barely pause and goes into "turbo" mode.




0
UZnal
6/1/2006 7:10:50 PM
> SPOCK206 triggered [UN]protected mode.
>
>  > Model 90, Y-180 complex, 64MB of FPM, Corvette [.77 flash], narrow,
> 1.08 DPES-31080, 8x CD [untested].:
>  > SPOCK206 - 577.8 KB/sec [8580 w/70MB ESDI drive beats that!]

I saw it go down so much the very first time I installed it, but that was a
failure and yellow marked. Whatever the reasons, the driver is
inoperational, not loaded. Lights off could have been useful here to see who
is doing what.

Run QSPOCK over this config to see what happens. How does Win95 react to
this complex?

Wait ........!  There is a setting in the INF file which tells IOS not to
load it in case of conflicts, I got that from SCSI.INF:

[StdIOS]
HKR,,DevLoader,,*IOS
HKR,,DontLoadIfConflict,,"Y"

You could comment out the last line and reinstall SPOCK206, put a semicolon
before the line or leave the line and change "Y" to "N".

[StdIOS]
HKR,,DevLoader,,*IOS
; HKR,,DontLoadIfConflict,,"Y"

or

[StdIOS]
HKR,,DevLoader,,*IOS
HKR,,DontLoadIfConflict,,"N"


> System Programs to set DMA to 7 [default is C]

Same here, this setting does not seem to have any +/- effect. The SCSI port
driver expects to see a DMA channel but we have Arbitration Levels. Or, the
DMA setting could me more appropriate for slave devices, needing the system
DMA. Busmasters do it for themselves, no intervention required.





0
UZnal
6/1/2006 7:38:48 PM
> How does Win95 react to ...

It reacts to settings in SYSTEM.INI section [386enh]. You can set these
below, the first setting requests MCA DMA if the machine is MCA, the second
limits DMA to below 4GB. I wouldn't be surprised if W95 accepts more MCA
Win3.x settings.

MCADMA = 1
MAXDMAPGADDRESS = 100000

Go to Device Manager / System Components / DMA Controller: the changes you
make there to Reserve DMA and DMA Range will be reflected in SYSTEM.INI on
Win95.

I got the settings from the DDK/95/98,  D:\WinDev\DDK\Base\SAMPLES\VDMAD












0
UZnal
6/1/2006 10:10:32 PM
Whacked the SPOCK206.INF, DRVIDX.bin and the other one, reinstalled 206 
(with the IOS second line remmed out), set the I/O and DMA to the 
correct values. Reboot.

W98SE is still having nothing to do with it. Unprotected mode.

Dropped an M back in, reconfigured and W98SE came up with everything in 
protected mode [except the parallel port, the autoconfig must have set 
it to LPT1].

QSPOCK output (Turbo Y and Corvette):

Port: 3540  Present
Port: 3548  --
Port: 3550  --
Port: 3558  --
Port: 3560  --
Port: 3568  --
Port: 3570  --
Port: 3578  --

( 1 ) IBM SCSI adapters found

Port 3540 : Status Information
-------------------------------
(05h)    Basic Control: 0 0 0 0 0 0 1 1
0     Interrupt Enable: Yes
1           DMA Enable: Yes
6-2           Reserved: --
7       Hardware Reset: No

(07h)     Basic Status: 0 0 0 0 0 1 0 0
0                 Busy: No
1    Interrupt Request: No
2  Cmd Interface Empty: Yes : Read by the adapter
3  Cmd Interface  Full: No  : Emptied by the adapter
7-4           Reserved: --

(06h) Interrupt Status: 0 0 0 1 1 1 1 1
3-0          Device-ID: F
7-4       Interrupt-ID: ( F ) SCB Command completed with success

SCB * Get Adapter Info: ( F ) SCB Command completed with success
             Adapter ID: 8EFC
       POS Register [2]: 1 1 1 1 0 0 0 1
       POS Register [3]: 1 1 1 0 0 1 1 1
       POS Register [4]: 0 0 1 1 1 1 0 0
        Interrupt Level: Eh ( 14 )
Adapter Revision Level: 77h
      Channel Connector: 32-bit
  Num Devices Supported: 30
    Num LUNs per Device: 32
    Num Logical Devices: 16
      DMA Pacing Factor: 100
   EOI to Interrupt Off: 1 msecs
  Max Adapter Busy Time: 30 secs
    Device Cache Status: 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1
    Device Retry Status: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

------------------------------------------------------
Runstream (R) Query SPOCK / DOS       Beta Rel. 01.02
Copyright (C) UnalZ, 2006         All rights reserved.
------------------------------------------------------


UZnal wrote:
>> SPOCK206 triggered [UN]protected mode.
>>
>>  > Model 90, Y-180 complex, 64MB of FPM, Corvette [.77 flash], narrow,
>> 1.08 DPES-31080, 8x CD [untested].:
>>  > SPOCK206 - 577.8 KB/sec [8580 w/70MB ESDI drive beats that!]
> 
> I saw it go down so much the very first time I installed it, but that was a
> failure and yellow marked. Whatever the reasons, the driver is
> inoperational, not loaded. Lights off could have been useful here to see who
> is doing what.
> 
> Run QSPOCK over this config to see what happens. How does Win95 react to
> this complex?
> 
> Wait ........!  There is a setting in the INF file which tells IOS not to
> load it in case of conflicts, I got that from SCSI.INF:
> 
> [StdIOS]
> HKR,,DevLoader,,*IOS
> HKR,,DontLoadIfConflict,,"Y"
> 
> You could comment out the last line and reinstall SPOCK206, put a semicolon
> before the line or leave the line and change "Y" to "N".
> 
> [StdIOS]
> HKR,,DevLoader,,*IOS
> ; HKR,,DontLoadIfConflict,,"Y"
> 
> or
> 
> [StdIOS]
> HKR,,DevLoader,,*IOS
> HKR,,DontLoadIfConflict,,"N"
> 
> 
>> System Programs to set DMA to 7 [default is C]
> 
> Same here, this setting does not seem to have any +/- effect. The SCSI port
> driver expects to see a DMA channel but we have Arbitration Levels. Or, the
> DMA setting could me more appropriate for slave devices, needing the system
> DMA. Busmasters do it for themselves, no intervention required.
> 
> 
> 
> 
> 
0
Louis
6/1/2006 10:21:00 PM
Er, what about W98SE? How about requesting MCA DMA under W98SE and where 
would this setting be? It isn't under MCA DMA controller, IIRC. The MCA 
DMA has DMA buffer [1-64KB] 16 and under [jail time!] and under 4GB 
settings.

UZnal wrote:
>> How does Win95 react to ...
> 
> It reacts to settings in SYSTEM.INI section [386enh]. You can set these
> below, the first setting requests MCA DMA if the machine is MCA, the second
> limits DMA to below 4GB. I wouldn't be surprised if W95 accepts more MCA
> Win3.x settings.
> 
> MCADMA = 1
> MAXDMAPGADDRESS = 100000
> 
> Go to Device Manager / System Components / DMA Controller: the changes you
> make there to Reserve DMA and DMA Range will be reflected in SYSTEM.INI on
> Win95.
> 
> I got the settings from the DDK/95/98,  D:\WinDev\DDK\Base\SAMPLES\VDMAD
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
0
Louis
6/1/2006 10:25:37 PM

UZnal wrote:
> 
> Let there be light ...
> 
>  May 31, 2006: http://www.members.aon.at/mcabase/pub/files/spock206.zip


Grabbed it tonight to try out, along with Coretest. Same platform as
used to test the XGA-2 driver, Bermuda 77-Ultimedia with Win95B and
planar SCSI, 24 MB RAM, XGA-2 @800x600 (still counting colors). Hard
disks are 2x IBM 0661-467 400MB each.

Confirmed that the M$ Spock driver was installed and functioning
properly. Ran three passes of Coretest in fullscreen:

DISK 0: 1125.0, 1176.6, 1196.5
DISK 1:  918.4,  926.9,  926.6

Installed Spock-206 per instructions and restarted. No errors,
exclamation points, etc. Confirmed in Device Mangler that Spock-206 is
installed and functioning properly. 3540-3547, IRQ 14, DMA 7. Again,
three passes of Coretest in fullscreen:

DISK 0: 1200.8, 1175.1, 1154.9
DISK 1:  920.4,  921.4,  927.8

Rebooted to check resources in SC, changed DMA Arb. from C to 7. No
difference, as expected.

Interesting. This machine must be bottlenecking somewhere. I suspect it
is the CPU. Looking for a DX4-100ODP. The system does seem a bit
perkier. Shutdown was fast.

I do like my disk light....

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

> You are experiencing the significance of microseconds. The
> CD-ROM drive can barely pause and goes into "turbo" mode.

The significance of microseconds indeed...here are some more results with
various adapters in a Model 90 with a T4-P60 complex, 32MB RAM, Madge Smart
Ringnode 32 and Win95OSR2. The hard disk in use is a 540MB Quantum pulled
from a Power Mac 6100. I think you'll find them striking at the very least.

Old long uncached SCSI/A
M$: 2074.6KB/sec
UZ: 2402.8/KB/sec

New short uncached SCSI/A
M$: 2724.8KB/second
UZ: 2920.4KB/second (!!!)

Old cached SCSI/A (single oscillator)
M$: 1629.3KB/second
UZ: 1786.0KB/second

New cached SCSI/A (triple oscillator):
M$: 2194.9KB/second
UZ: 2390.9KB/second

I have no dual oscillator SCSI with cache cards that I know of. If I find
one, I'll test it.

Model 85-0XF Planar (with DCAS-32160 hard disk):
M$: 2187.5KB/second
UZ: 2540.3KB/second

I tried a Corvette and it must not have liked the Quantum hard drive. I will
try another drive soon as I couldn't even get the system to boot. It threw a
consistent "unidentified SCSI device error" during POST. Maybe the drive is
not fast enough for the Corvette adapter.

I'm surprised at how the uncached cards manage to exceed the performance of
the cached ones with the CORETEST utility. Especially surprising is how the
late model short uncached SCSI/A really seems to be the fastest of anything
I could test so far in the IBM MCA SCSI family...with the on-planar SCSI of
the 9585-0XF coming in a close second.

(For the record, the short uncached SCSI/A won't run reliably on a Model 95
dual LPT planar under Windows NT. I was told this was because the adapter
might be too slow for that planar. Perhaps the NT Spock driver just can't
cope with this adapter. It seems to be adapter revision level sensitive.)

Now, for further results with 2MB cache installed on the cached adapters:

Old cached card, 2MB cache (single oscillator)
M$: 1612.0KB/second
UZ: 1770.9KB/second

New cached card, 2MB cache (triple oscillator)
M$: 2173.6KB/second
UZ: 2432.8KB/second

I find the difference between 512KB cache and 2MB to be interesting. Only
the newest triple-oscillator card seems to get better performance with UZ's
driver. Otherwise performance gets worse across the board with more cache
present.

Earlier in this thread I thought I saw reference to the fact that the cache
on the cached adapters was ignored by the present M$ driver. Is that true
with the new driver? (I'd have to think that a cached adapter using its
cache would easily outrun an uncached adapter.)

I do believe the 9585 "X" planar has a (512K?) cache for its SCSI chipset.
Advanced diagnostics does run a cache test on this system.

I am not sure about the 9577...on the one hand it has a RAM chip in the
vicinity of the SCSI chipset and uses the 80188 CPU instead of an 8032. On
the other, people here have said that it is not cached and I don't recall if
diagnostics runs a cache test on this system's SCSI adapter or not.

Anyway, here are the results...

William
--
Brought to you by an IBM PS/2 9585-0XF, "Defiant"
AMD 486-133/64MB/2GB S/N 23HN457


0
William
6/2/2006 3:14:37 AM
> W98SE is still having nothing to do with it. Unprotected mode.

It is rather an indication that the miniport is excluded, it can't operate.
There must be something specific to this complex. That might be the case if
you have changed the complex after you've installed the OS. But if it were
the complex, W98SE would have other problems with as well, strange that only
the miniport is affected.

> Er, what about W98SE? How about requesting MCA DMA under W98SE and where
> would this setting be? It isn't under MCA DMA controller, IIRC. The MCA
> DMA has DMA buffer [1-64KB] 16 and under [jail time!] and under 4GB
> settings.

Again under [386enh] in SYSTEM.INI. W98 maps the old style to the registry
but I saw no mapped entries for these keys. PS/2 DMA is definitely handled,
but VDMAD has been updated code in W98.

It does not help to manually change the DMA resource. I checked the DDK
code, DMA channels up to 7 are defined there, so it picks up the greatest
defined value.






0
UZnal
6/2/2006 11:19:49 AM
> disks are 2x IBM 0661-467 400MB each.

> M$ Spock driver
> DISK 0: 1125.0, 1176.6, 1196.5
> DISK 1:  918.4,  926.9,  926.6

> Installed Spock-206
> DISK 0: 1200.8, 1175.1, 1154.9
> DISK 1:  920.4,  921.4,  927.8

> Interesting. This machine must be bottlenecking somewhere.

The disks, I would say. There is no difference between the both drivers, but
tests with other, newer, disks show a difference. Yours are interesting
results, thank you!

> I do like my disk light....

I did it for you ...;) The disk light buffers negligibly, I want to try
increased stall times to give other tasks some more time to work, i.e.
spread the load evenly.





0
UZnal
6/2/2006 11:29:12 AM
Turbochip.

Jim Shorney wrote:
> 
> UZnal wrote:
>> Let there be light ...
>>
>>  May 31, 2006: http://www.members.aon.at/mcabase/pub/files/spock206.zip
> 
> 
> Grabbed it tonight to try out, along with Coretest. Same platform as
> used to test the XGA-2 driver, Bermuda 77-Ultimedia with Win95B and
> planar SCSI, 24 MB RAM, XGA-2 @800x600 (still counting colors). Hard
> disks are 2x IBM 0661-467 400MB each.
> 
> Confirmed that the M$ Spock driver was installed and functioning
> properly. Ran three passes of Coretest in fullscreen:
> 
> DISK 0: 1125.0, 1176.6, 1196.5
> DISK 1:  918.4,  926.9,  926.6
> 
> Installed Spock-206 per instructions and restarted. No errors,
> exclamation points, etc. Confirmed in Device Mangler that Spock-206 is
> installed and functioning properly. 3540-3547, IRQ 14, DMA 7. Again,
> three passes of Coretest in fullscreen:
> 
> DISK 0: 1200.8, 1175.1, 1154.9
> DISK 1:  920.4,  921.4,  927.8
> 
> Rebooted to check resources in SC, changed DMA Arb. from C to 7. No
> difference, as expected.
> 
> Interesting. This machine must be bottlenecking somewhere. I suspect it
> is the CPU. Looking for a DX4-100ODP. The system does seem a bit
> perkier. Shutdown was fast.
> 
> I do like my disk light....
> 
> ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
> http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
> ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Louis
6/2/2006 11:58:45 AM
> The significance of microseconds indeed...here are some more results with
> various adapters in a Model 90 with a T4-P60 complex, 32MB RAM, Madge
Smart
> Ringnode 32 and Win95OSR2. The hard disk in use is a 540MB Quantum pulled
> from a Power Mac 6100. I think you'll find them striking at the very
least.

Nice results, William, thank you!

> I'm surprised at how the uncached cards manage to exceed the performance
of
> the cached ones with the CORETEST utility. Especially surprising is how
the
> late model short uncached SCSI/A really seems to be the fastest of
anything
> I could test so far in the IBM MCA SCSI family...with the on-planar SCSI
of
> the 9585-0XF coming in a close second.

The only reference to the cache in the techref is READ PREFETCH, but to use
this efficiently in a multiple device configuration you need the proper
logic. There is no mention of what the adapter actually does with the cache,
the benefits of it would be best seen with slow, uncached disks and small
files. This isn't the case anymore with the disks we have now.

> (For the record, the short uncached SCSI/A won't run reliably on a Model
95
> dual LPT planar under Windows NT. I was told this was because the adapter
> might be too slow for that planar. Perhaps the NT Spock driver just can't
> cope with this adapter. It seems to be adapter revision level sensitive.)

Which revision level does the short uncached SCSI/A have? It would have been
a good idea if you had run QSPOCK on each card to obtain the adapter
revision level (SCSI level).

I need to only link SPOCK206 with the NT libs to build the NT version of it,
no code changes would be required. I'll have to figure out how to install
SPOCK206 on NT. We will test NT as next, but let us first discuss and fix
W9x.

> I find the difference between 512KB cache and 2MB to be interesting. Only
> the newest triple-oscillator card seems to get better performance with
UZ's
> driver. Otherwise performance gets worse across the board with more cache

> present.

The adapter must manage and maintain the cache, but a local disk cache is
much more efficient than a global, adapter cache. Newer disks have probaby
the faster processors than Spock/Corvette have.


> Earlier in this thread I thought I saw reference to the fact that the
cache
> on the cached adapters was ignored by the present M$ driver. Is that true
> with the new driver? (I'd have to think that a cached adapter using its
> cache would easily outrun an uncached adapter.)

You probably mean READ PREFETCH, it is not explicitly used. The miniport
issues the commands coming from the class layer below, and AFAICS, READ
PREFETCH is specific to Spock, it is not designated as a standard SCSI
command in the techref. It is not either in the SCSI OP table of the DDK.

> I do believe the 9585 "X" planar has a (512K?) cache for its SCSI chipset.
> Advanced diagnostics does run a cache test on this system.

See what QUMC detects.

> I am not sure about the 9577...on the one hand it has a RAM chip in the
> vicinity of the SCSI chipset and uses the 80188 CPU instead of an 8032. On
> the other, people here have said that it is not cached and I don't recall
if
> diagnostics runs a cache test on this system's SCSI adapter or not.

The planar SCSI ID is 8EFF, that is, Spock with cache. It should have a
cache, it need not just because of the ID. Cache presence is detected
through a bit in the Cache Information Word in the Command Complete Status.






0
UZnal
6/2/2006 12:12:31 PM
Um, specific to the complex? I think not. W98SE installed on a Pentium 
complex will stay in [in]compatible mode all the live long day. Yet swap 
complexi to an M and it comes up in [un]protected mode. My model 90 
started out that weg.

How do we get the miniport to not be "excluded"?

UZnal wrote:
>> W98SE is still having nothing to do with it. Unprotected mode.
> 
> It is rather an indication that the miniport is excluded, it can't operate.
> There must be something specific to this complex. That might be the case if
> you have changed the complex after you've installed the OS. But if it were
> the complex, W98SE would have other problems with as well, strange that only
> the miniport is affected.
0
Louis
6/2/2006 12:26:30 PM
UZnal wrote:
>> W98SE is still having nothing to do with it. Unprotected mode.
> 
> It is rather an indication that the miniport is excluded, it can't operate.
> There must be something specific to this complex. That might be the case if
> you have changed the complex after you've installed the OS. But if it were
> the complex, W98SE would have other problems with as well, strange that only
> the miniport is affected.

It's not that the complex was changed after install.  It's the speed of 
complex alone, and not that it's a Type 4.  See older posts here, as 
you'll see what works and what doesn't:

Type 3, DX5-0   Works
Type 3, AMDUPG  Doesn't Work
Type 4, DX2-66  Works
Type 4, P-60    Doesn't Work
Type 4, P-66    Doesn't Work
Type 4, P-90    Doesn't Work

Simply swapping out these complexes will change the operational status 
of the SCSI controller.  For example, I installed W98SE with a T4/90. 
SCSI wouldn't work and popped in a T4/486-66 and it works.  Others have 
tried a T3 upgraded with an AMD 133 I think? and the SCSI doesn't work, 
although going back to the stock DX50 will result in the SCSI working 
again.  These "speed" issues aren't present in Win95B, only Win98FE/SE.

--Daniel
0
Daniel
6/2/2006 12:41:28 PM
    Odd, the T3 with a 150MHz clock blows chunks? Must be some base 
clock / multiplier combinations won't go.

    What combinations blow chunks? 486DX with a 133?

> Type 3, AMDUPG  Doesn't Work
0
Louis
6/2/2006 12:49:20 PM
Louis Ohland wrote:
>    Odd, the T3 with a 150MHz clock blows chunks? Must be some base clock 
> / multiplier combinations won't go.
> 
>    What combinations blow chunks? 486DX with a 133?
> 
>> Type 3, AMDUPG  Doesn't Work

Search Google groups for this topic: (March 1999)

ps2 model 5775 and win95

I think the person may have been talking of a Model 77 with spock + the 
upgrade, not a T3.  I could have swore someone recently tried the T3 
with an upgrade and it failed....I might be hallucinating.

--Daniel
0
Daniel
6/2/2006 2:27:04 PM
On Fri, 2 Jun 2006 14:12:31 +0200, UZnal wrote:

> The adapter must manage and maintain the cache, but a local
> disk cache is much more efficient than a global, adapter
> cache. Newer disks have probaby the faster processors than
> Spock/Corvette have.

I would be interested in knowing performance differences with
other test suites involving non-sequential accesses across
multiple disks / devices.  

I would expect that maybe the cache adapters would tend to do
well with the devices that they were designed to be hooked up to.

-- 

CL.

+-----------------------------------------+
| Charles Lasitter   | Mailing / Shipping |
| 401/728-1987       | 14 Cooke St        |
| cl+at+ncdm+dot+com | Pawtucket RI 02860 |
+-----------------------------------------+
0
Charles
6/2/2006 3:03:32 PM
> How do we get the miniport to not be "excluded"?

Run it in debug mode and watch the messages. But I have the debug option
only in the DDK-95, the DDK-98 dld package did not have it. The CD should
have it.

If it the P60 complex, I can try that, I have it.




0
UZnal
6/2/2006 7:06:03 PM
> It's not that the complex was changed after install.  It's the speed of
> complex alone, and not that it's a Type 4.  See older posts here, as
> you'll see what works and what doesn't:

Don't think I have that much time !

> Type 4, P-60    Doesn't Work

I can test that with Mod. 95. But QSPOCK managed to deliver results there.

> Simply swapping out these complexes will change the operational status
> of the SCSI controller.  For example, I installed W98SE with a T4/90.
> SCSI wouldn't work and popped in a T4/486-66 and it works.

The miniport relies on ScsiPortStallExecution(..) and I am letting it wait
up to 20 microsecs on busy. If it is the speed alone, then (a) the function
cannot properly time (b) increasing the stall time should remedy the
situation. There is nothing else in the miniport that is time/speed
dependent.

The question is, if it is the miniport or it is some other related
component. For the curious, the AHA174x.c miniport code in the NT4 DDK is
quite similar to Spock206.

Something different could be done, to link the miniport against the NT
libraries, it is SCSIPORT.LIB. I have been using the lib supplied in the W9x
DDKs.

> These "speed" issues aren't present in Win95B, only Win98FE/SE.

There is not only speed on the complex. I run W98SE on PII 450 Mhz without
problems, and without SCSI. However, I remember that I had problems with the
Sparrow SCSI on MediaVision Pro, I had attributed that to the driver. IIRC,
that was on the P200 MMX machine.




0
UZnal
6/2/2006 7:28:08 PM

UZnal wrote:
> 
> 
> The disks, I would say. There is no difference between the both drivers, but
> tests with other, newer, disks show a difference. Yours are interesting
> results, thank you!


That thought occured to me later, after I had some sleep.....  May do
some playing later this weekend, but things are going to be busy.

 
> > I do like my disk light....
> 
> I did it for you ...;)


Thenk yew. I'm rather fond of lights, as a basic diagnostic and a
reassurance that the computer is actually DOING something (esp. with
Windoze). I prefer external modems for that reason. I've also been known
to pimp up some of my radio gear by swapping out mundane red LEDs for
other interesting colors. It was a happy day when blue became available.

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

Louis Ohland wrote:
> 
> Turbochip.

Fresh out.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
6/2/2006 9:21:42 PM
Run the 95 debug, it should give a close enough idea of what W98SE has a 
problem with. Wouldn't hurt to run against NT, either.

My money is on IOSUBSYS.

UZnal wrote:
> The miniport relies on ScsiPortStallExecution(..) and I am letting it wait
> up to 20 microsecs on busy. If it is the speed alone, then (a) the function
> cannot properly time (b) increasing the stall time should remedy the
> situation. There is nothing else in the miniport that is time/speed
> dependent.
> 
> The question is, if it is the miniport or it is some other related
> component. For the curious, the AHA174x.c miniport code in the NT4 DDK is
> quite similar to Spock206.
> 
> Something different could be done, to link the miniport against the NT
> libraries, it is SCSIPORT.LIB. I have been using the lib supplied in the W9x
> DDKs.
0
Louis
6/3/2006 1:01:38 AM
> Run the 95 debug, it should give a close enough idea of what W98SE has a
> problem with. Wouldn't hurt to run against NT, either.

You must replace a number of binaries/drivers for the debug mode, you would
end up replacing 98 files with 95 files.

> My money is on IOSUBSYS.

- A test case would be to run W98SE with the W95 SCSI port driver, file name
is SCSIPORT.PDR

- Another test case would be to replace all of IOSUBSYS with the 95
IOSUBSYS. This directory is a collection of miniport and port drivers.

W98SE has \WINDOWS\SYSTEM32\DRIVERS which W95 did not have.The SCSI port
mapper SCSIMAP.SYS is located there. Problems could be originating from this
dir.

Press F8 at boot time and let it protocol events in BOOTLOG.TXT. Read the
file and look for the "spock2.mpd" entry. BOOTLOG.TXT is a hidden file on
the boot drive.

[xxxxxxxx] Initing spock2.mpd
[xxxxxxxx] Init Success spock2.mpd

Scan the complete file for eventual error messages.






0
UZnal
6/3/2006 12:53:11 PM
Dual option, with or without disk activity light, tripled busy time
tolerance:

June 3, 2006: http://www.members.aon.at/mcabase/pub/files/spock206.zip

- Dual option

Select "IBM MCA SCSI SPOCK-206 W/LIGHT" at installation time if you wish
the driver to manage the disk activity light.

Select "IBM MCA SCSI SPOCK-206" at installation time if you wish to disable
the disk activity light. This version will NOT manage the disk light on your
machine.

- Tripled busy time tolerance

Waits up to 60 millisecs on busy. Speedy complex overrun?

- Removed error threshold for Disable Disconnect, devices are not forced to
remain connected when too many errors in a multiple device config.

- Test reports included in README

By William Walsh, Louis Ohland, Jim Shorney, Daniel Hamilton (complex note).

Future testers, please include the SPOCK206 option you tested. We lack
Corvette results.



0
UZnal
6/3/2006 6:26:31 PM
Hi!

Okay, I got some time to work with the SCSI adapters again...here are the
QSPOCK results:

Early Uncached SCSI/A (64F4377/76 and 84F8233 ROMs):


Port: 3540  Present
Port: 3548  --
Port: 3550  --
Port: 3558  --
Port: 3560  --
Port: 3568  --
Port: 3570  --
Port: 3578  --

( 1 ) IBM SCSI adapters found

Port 3540 : Status Information
-------------------------------
(05h)    Basic Control: 0 0 0 0 0 0 1 1
0     Interrupt Enable: Yes
1           DMA Enable: Yes
6-2           Reserved: --
7       Hardware Reset: No

(07h)     Basic Status: 0 0 0 0 0 1 0 0
0                 Busy: No
1    Interrupt Request: No
2  Cmd Interface Empty: Yes : Read by the adapter
3  Cmd Interface  Full: No  : Emptied by the adapter
7-4           Reserved: --

(06h) Interrupt Status: 0 0 0 1 0 0 0 0
3-0          Device-ID: 0
7-4       Interrupt-ID: ( 0 ) SCB Command completed with success

SCB * Get Adapter Info: ( F ) SCB Command completed with success
            Adapter ID: 8EFE
      POS Register [2]: 1 1 1 1 0 0 0 1
      POS Register [3]: 1 1 1 1 1 1 0 0
      POS Register [4]: 1 0 1 0 0 0 0 0
       Interrupt Level: Eh ( 14 )
Adapter Revision Level: 12h
     Channel Connector: 32-bit
 Num Devices Supported: 7
   Num LUNs per Device: 8
   Num Logical Devices: 16
     DMA Pacing Factor: 100
  EOI to Interrupt Off: 1 msecs
 Max Adapter Busy Time: 10 secs
   Device Cache Status: 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1
   Device Retry Status: 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1

------------------------------------------------------
Runstream (R) Query SPOCK / DOS       Beta Rel. 01.02
Copyright (C) UnalZ, 2006         All rights reserved.
------------------------------------------------------

Late Uncached SCSI/A (92F2245/44, 54G1800 ROMs, all soldered)


Port: 3540  Present
Port: 3548  --
Port: 3550  --
Port: 3558  --
Port: 3560  --
Port: 3568  --
Port: 3570  --
Port: 3578  --

( 1 ) IBM SCSI adapters found

Port 3540 : Status Information
-------------------------------
(05h)    Basic Control: 0 0 0 0 0 0 1 1
0     Interrupt Enable: Yes
1           DMA Enable: Yes
6-2           Reserved: --
7       Hardware Reset: No

(07h)     Basic Status: 0 0 0 0 0 1 0 0
0                 Busy: No
1    Interrupt Request: No
2  Cmd Interface Empty: Yes : Read by the adapter
3  Cmd Interface  Full: No  : Emptied by the adapter
7-4           Reserved: --

(06h) Interrupt Status: 0 0 0 1 0 0 0 0
3-0          Device-ID: 0
7-4       Interrupt-ID: ( 0 ) SCB Command completed with success

SCB * Get Adapter Info: ( F ) SCB Command completed with success
            Adapter ID: 8EFE
      POS Register [2]: 1 1 1 1 0 0 0 1
      POS Register [3]: 1 1 1 1 1 1 0 0
      POS Register [4]: 1 0 1 0 0 0 0 0
       Interrupt Level: Eh ( 14 )
Adapter Revision Level: 26h
     Channel Connector: 32-bit
 Num Devices Supported: 7
   Num LUNs per Device: 8
   Num Logical Devices: 16
     DMA Pacing Factor: 100
  EOI to Interrupt Off: 1 msecs
 Max Adapter Busy Time: 10 secs
   Device Cache Status: 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1
   Device Retry Status: 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1

------------------------------------------------------
Runstream (R) Query SPOCK / DOS       Beta Rel. 01.02
Copyright (C) UnalZ, 2006         All rights reserved.
------------------------------------------------------

9585 "X" Planar:


Port: 3540  Present
Port: 3548  --
Port: 3550  --
Port: 3558  --
Port: 3560  --
Port: 3568  --
Port: 3570  --
Port: 3578  --

( 1 ) IBM SCSI adapters found

Port 3540 : Status Information
-------------------------------
(05h)    Basic Control: 0 0 0 0 0 0 1 1
0     Interrupt Enable: Yes
1           DMA Enable: Yes
6-2           Reserved: --
7       Hardware Reset: No

(07h)     Basic Status: 0 0 0 0 0 1 0 0
0                 Busy: No
1    Interrupt Request: No
2  Cmd Interface Empty: Yes : Read by the adapter
3  Cmd Interface  Full: No  : Emptied by the adapter
7-4           Reserved: --

(06h) Interrupt Status: 0 0 0 1 0 0 0 0
3-0          Device-ID: 0
7-4       Interrupt-ID: ( 0 ) SCB Command completed with success

SCB * Get Adapter Info: ( F ) SCB Command completed with success
            Adapter ID: 8EFF
      POS Register [2]: 0 0 0 0 0 0 0 1
      POS Register [3]: 1 1 1 1 1 1 0 0
      POS Register [4]: 0 0 1 0 0 0 0 0
       Interrupt Level: Eh ( 14 )
Adapter Revision Level: 25h
     Channel Connector: 32-bit
 Num Devices Supported: 7
   Num LUNs per Device: 8
   Num Logical Devices: 16
     DMA Pacing Factor: 100
  EOI to Interrupt Off: 1 msecs
 Max Adapter Busy Time: 30 secs
   Device Cache Status: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   Device Retry Status: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

------------------------------------------------------
Runstream (R) Query SPOCK / DOS       Beta Rel. 01.02
Copyright (C) UnalZ, 2006         All rights reserved.
------------------------------------------------------


Old (single osc) Cached SCSI (64F4376/77, 64F5984 ROMs):


Port: 3540  Present
Port: 3548  --
Port: 3550  --
Port: 3558  --
Port: 3560  --
Port: 3568  --
Port: 3570  --
Port: 3578  --

( 1 ) IBM SCSI adapters found

Port 3540 : Status Information
-------------------------------
(05h)    Basic Control: 0 0 0 0 0 0 1 1
0     Interrupt Enable: Yes
1           DMA Enable: Yes
6-2           Reserved: --
7       Hardware Reset: No

(07h)     Basic Status: 0 0 0 0 0 1 0 0
0                 Busy: No
1    Interrupt Request: No
2  Cmd Interface Empty: Yes : Read by the adapter
3  Cmd Interface  Full: No  : Emptied by the adapter
7-4           Reserved: --

(06h) Interrupt Status: 0 0 0 1 0 0 0 0
3-0          Device-ID: 0
7-4       Interrupt-ID: ( 0 ) SCB Command completed with success

SCB * Get Adapter Info: ( F ) SCB Command completed with success
            Adapter ID: 8EFF
      POS Register [2]: 1 1 1 1 0 0 0 1
      POS Register [3]: 1 1 1 1 1 1 0 0
      POS Register [4]: 1 0 1 0 0 0 0 0
       Interrupt Level: Eh ( 14 )
Adapter Revision Level: 9h
     Channel Connector: 32-bit
 Num Devices Supported: 7
   Num LUNs per Device: 8
   Num Logical Devices: 16
     DMA Pacing Factor: 100
  EOI to Interrupt Off: 1 msecs
 Max Adapter Busy Time: 30 secs
   Device Cache Status: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   Device Retry Status: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

------------------------------------------------------
Runstream (R) Query SPOCK / DOS       Beta Rel. 01.02
Copyright (C) UnalZ, 2006         All rights reserved.
------------------------------------------------------


Newest (triple OSC) Cached SCSI (94F2244/45, 10G4890 ROMs):


Port: 3540  Present
Port: 3548  --
Port: 3550  --
Port: 3558  --
Port: 3560  --
Port: 3568  --
Port: 3570  --
Port: 3578  --

( 1 ) IBM SCSI adapters found

Port 3540 : Status Information
-------------------------------
(05h)    Basic Control: 0 0 0 0 0 0 1 1
0     Interrupt Enable: Yes
1           DMA Enable: Yes
6-2           Reserved: --
7       Hardware Reset: No

(07h)     Basic Status: 0 0 0 0 0 1 0 0
0                 Busy: No
1    Interrupt Request: No
2  Cmd Interface Empty: Yes : Read by the adapter
3  Cmd Interface  Full: No  : Emptied by the adapter
7-4           Reserved: --

(06h) Interrupt Status: 0 0 0 1 0 0 0 0
3-0          Device-ID: 0
7-4       Interrupt-ID: ( 0 ) SCB Command completed with success

SCB * Get Adapter Info: ( F ) SCB Command completed with success
            Adapter ID: 8EFF
      POS Register [2]: 1 1 1 1 0 0 0 1
      POS Register [3]: 1 1 1 1 1 1 0 0
      POS Register [4]: 1 0 1 0 0 0 0 0
       Interrupt Level: Eh ( 14 )
Adapter Revision Level: 25h
     Channel Connector: 32-bit
 Num Devices Supported: 7
   Num LUNs per Device: 8
   Num Logical Devices: 16
     DMA Pacing Factor: 100
  EOI to Interrupt Off: 1 msecs
 Max Adapter Busy Time: 30 secs
   Device Cache Status: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   Device Retry Status: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

------------------------------------------------------
Runstream (R) Query SPOCK / DOS       Beta Rel. 01.02
Copyright (C) UnalZ, 2006         All rights reserved.
------------------------------------------------------

....and that's everything. If you need the FRU/PN of the adapters, let me
know.

William

--
Brought to you by an IBM PS/2 9585-0XF, "Defiant"
AMD 486-133/64MB/2GB S/N 23HN457


0
William
6/6/2006 5:55:09 PM
Excellent job, William. Have you ever considered a QA-engineer career?


> Early Uncached SCSI/A (64F4377/76 and 84F8233 ROMs):
>             Adapter ID: 8EFE
> Adapter Revision Level: 12h

So, Tribble passes the tests.


> Late Uncached SCSI/A (92F2245/44, 54G1800 ROMs, all soldered)
>             Adapter ID: 8EFE
> Adapter Revision Level: 26h

This is the highest rev-level so far.


> 9585 "X" Planar:
>             Adapter ID: 8EFF
> Adapter Revision Level: 25h

This is the same rev-level as on Mod. 77, 90 and newest (triple OSC) Cached
SCSI.


> Old (single osc) Cached SCSI (64F4376/77, 64F5984 ROMs):
>             Adapter ID: 8EFF
> Adapter Revision Level: 9h

My adapter Spock has the same rev-level.


> Newest (triple OSC) Cached SCSI (94F2244/45, 10G4890 ROMs):
>             Adapter ID: 8EFF
> Adapter Revision Level: 25h

This is the same rev-level as on Mod. 77 and 9585 "X" Planar.


> ...and that's everything. If you need the FRU/PN of the adapters, let me
> know.

Noooo, that would be too much trivia. I wanted to know which adapter
revision levels passed the tests to document the test results.

Many thanks for the test results !!!




0
UZnal
6/6/2006 9:39:17 PM
Hi!

> Have you ever considered a QA-engineer career?

No, I never have considered that line of work. In the grand scheme of
things, hardware fascinates me. (I'd like to learn more about software and
developing it on low and high levels both. However, my mind doesn't seem to
work well with the concepts of software.) At this point in time, I'd like to
actually consider putting some hardware into production, but my skill set is
not yet there.

> This is the highest rev-level so far.

Higher than even the Corvette? (Have you had a report on the "Corvette
Turbo"?)
(see http://www.gilanet.com/ohlandl/IBM_SCSI/SCSI-DFW.html if you haven't
heard of this adapter)

Assuming nobody has tried the Corvette yet, I can always give it a shot and
see. Most of mine are at Rev 58, and not 71 or 77. I haven't seen the need
to update them with newer code for any reason.

> Noooo, that would be too much trivia.

Okay, no FRUs or P/Ns for now...

However, I do have some more test results for your consideration. With
regards to the failure of Spock and other busmastering SCSI adapters to
perform under Win98SE, I have this to add. Today I tried a logged boot to
BOOTLOG.TXT with both spock.mpd and spock2.mpd.

Both show similar entries:

0012EBB1 Initing spock.mpd
0012EBBG Init Failure spock.mpd

00130E40 Initing spock2.mpd
00130E46 Init Failure spock2.mpd

I'm not sure what the leading numbers do. Maybe they are just line numbers
of some type...or I guess they could be descriptive codes. I have not yet
researched them.

Test configuration this time--Model 90, Pentium 60 complex, Win98SE, 32MB
RAM, Madge Smart Ringnode TR (a busmaster-capable card, and it does work!),
Seagate Barracuda 2GB hard disk. The SCSI adapter in use is the latest short
uncached SCSI/A board with over 2GB support. I tried things with both the
Win95 and 98SE SCSIPORT.PDR  There was no obvious difference.

In Device Manager, the property pages for each adapter say "this device is
not present, not functioning properly or does not have all drivers installed
(Code 10 [ed. IIRC])"

I suspect a logged boot with other adapters (NCR, BusLogic, Adaptec, etc...)
will produce the same kind of "Init Failed" results as the IBM ones have. At
the very least, they end the same way in Device Manager's view.

William

--
Brought to you by an IBM PS/2 9585-0XF, "Defiant"
AMD 486-133/64MB/2GB S/N 23HN457


0
William
6/7/2006 12:36:21 AM
Hi!

> Higher than even the Corvette? (Have you had a report on the "Corvette
> Turbo"?)

I just answered my own question.

Corvette reports whatever its current firmware is as the revision level.
From the units I have here, the following are reported:
57, 58, 71 and 77. (I did not know of a Rev 57, but...scsilevl.com on the
Corvette Rev 71 flash diskette agreed with qspock.)

If you want the complete reports, feel free to ask. I have them on disk.

Corvette (in split and combined bus mode) still suffers on Win98SE. However,
it is not impacted as badly per CORETEST. Where transfer rates would fall to
200 or so KB/sec with the new uncached card and the Seagate Barracuda
mentioned below in Windows under "MS-DOS compatability mode, Corvette
transfers data (from a Seagate Barracuda ST12550N) around 7,200KB/sec in
pure DOS. Under Windows98SE with "MS-DOS compatability mode", Corvette
manages to hang on around 6,800KB/sec in a fullscreen window.

I tried the original spock.mpd, spock2.mpd and both versions of
scsiport.pdr. Nothing made any difference here, either.

William

--
Brought to you by an IBM PS/2 9585-0XF, "Defiant"
AMD 486-133/64MB/2GB S/N 23HN457



0
William
6/7/2006 1:22:21 AM
> > Have you ever considered a QA-engineer career?
>
> No, I never have considered that line of work. In the grand scheme of
> things, hardware fascinates me. (I'd like to learn more about software and
> developing it on low and high levels both. However, my mind doesn't seem
to
> work well with the concepts of software.)

Much the better, knowing software too well impaires testing. Not knowing it
too well, you would be free of any bias. There are different QA activities,
some require internal software knowledge, some not.


> > This is the highest rev-level so far.
>
> Higher than even the Corvette? (Have you had a report on the "Corvette
> Turbo"?)

I've been excluding Corvette, it belongs to a different class. I had in mind
Spock/Tribble which are equivalent save for the onboard cache.


> perform under Win98SE, I have this to add. Today I tried a logged boot to
> BOOTLOG.TXT with both spock.mpd and spock2.mpd.
>
> Both show similar entries:
>
> 0012EBB1 Initing spock.mpd
> 0012EBBG Init Failure spock.mpd
>
> 00130E40 Initing spock2.mpd
> 00130E46 Init Failure spock2.mpd

Great, this confirms my suspicions that the driver cannot be loaded at all.
Init failure results from the driver only when the driver cannot find any
adapters at probing the known I/O ports. This could mean, port access fails,
assuming calls are made to the miniport driver. Another option would be to
query the slots for the adapter IDs, however, AHA154x miniport does this and
it fails too, AFAIR.

Above are results from two different runs or did you have spock.mpd and
spock2.mpd at the same time?

> I'm not sure what the leading numbers do.

Not so important.

> In Device Manager, the property pages for each adapter say "this device is
> not present, not functioning properly or does not have all drivers
installed
> (Code 10 [ed. IIRC])"

The exact code could help here but the message is as expected.





0
UZnal
6/7/2006 12:22:08 PM
> Corvette (in split and combined bus mode) still suffers on Win98SE.
However,
> it is not impacted as badly per CORETEST. Where transfer rates would fall
to
> 200 or so KB/sec with the new uncached card and the Seagate Barracuda
> mentioned below in Windows under "MS-DOS compatability mode, Corvette
> transfers data (from a Seagate Barracuda ST12550N) around 7,200KB/sec in
> pure DOS. Under Windows98SE with "MS-DOS compatability mode", Corvette
> manages to hang on around 6,800KB/sec in a fullscreen window.

That means Corvette works on W98SE ...? The negligible drop is OK, we've
seen it on Spock too. If Corvette really works - please confirm - I'll have
look at something else.




0
UZnal
6/7/2006 12:28:37 PM
Hi!

> That means Corvette works on W98SE ...? The negligible drop
> is OK, we've seen it on Spock too. If Corvette really works -
> please confirm - I'll have look at something else.

No, it's in MS-DOS compatability mode. spock.mpd and spock2.mpd still
both fail to load per bootlog.txt.

But for whatever reason, it doesn't appear to suffer as badly in the
performance department as the "Spock" and "Tribble" adapters do when
running in MS-DOS compatability mode.

William

0
wm_walsh
6/7/2006 1:49:29 PM
> > 00130E40 Initing spock2.mpd
> > 00130E46 Init Failure spock2.mpd

I could follow the AHA154x detection procedure, but if AHA-1640 fails to
load, that won't help. IIRC, AHA-1640 exhibits the same symptoms as Spock,
i.e. init failure?


DDK/95, "Layered Block Device Drivers":

Device Driver Loading

The IOS loads and initializes port drivers, miniport drivers, and
value-added drivers. The IOS requires the files for these drivers to be
located in the SYSTEM\IOSUBSYS directory and to have the following filename
extensions:

PDR Port drivers, such as SCSIPORT, ESDI_506, and NEC
MPD SCSI miniport drivers
VXD Value-added drivers, such as the volume tracker and vendor-supplied
drivers

The IOS loads a given port or miniport driver only if the configuration
manager sends a request to load that driver. The configuration manager sends
a request if its hardware detection code locates an adapter. **Currently,
the configuration manager can detect the IDE and AHA154x SCSI adapters
only**. To support other adapters, the configuration manager forces the IOS
to load all remaining miniport drivers. These drivers remain loaded only if
they locate an adapter they can support. In general, any port driver that
fails to locate hardware that it can support will be unloaded.






0
UZnal
6/7/2006 2:19:51 PM
Have you slogged through configuration manager?

Is there a way to force config mangler to load only certain miniport 
drivers? I think that is the cause of the noticeable disk thrash upon 
startup.

UZnal wrote:
> The IOS loads a given port or miniport driver only if the configuration
> manager sends a request to load that driver. The configuration manager sends
> a request if its hardware detection code locates an adapter. **Currently,
> the configuration manager can detect the IDE and AHA154x SCSI adapters
> only**. To support other adapters, the configuration manager forces the IOS
> to load all remaining miniport drivers. These drivers remain loaded only if
> they locate an adapter they can support. In general, any port driver that
> fails to locate hardware that it can support will be unloaded.
0
Louis
6/7/2006 3:42:43 PM
Texas Bill, stop drinking that Taos Lightning.

Though the xfer rates may be acceptable, that still leaves one without 
CD-ROM support under [in]compatible mode. I will not burn more slots in 
a 90 just to prove a point.

wm_walsh@hotmail.com wrote:
> Hi!
> 
>> That means Corvette works on W98SE ...? The negligible drop
>> is OK, we've seen it on Spock too. If Corvette really works -
>> please confirm - I'll have look at something else.
> 
> No, it's in MS-DOS compatability mode. spock.mpd and spock2.mpd still
> both fail to load per bootlog.txt.
> 
> But for whatever reason, it doesn't appear to suffer as badly in the
> performance department as the "Spock" and "Tribble" adapters do when
> running in MS-DOS compatability mode.
> 
> William
> 
0
Louis
6/7/2006 3:45:18 PM
Hi!

> Above are results from two different runs or did you have
> spock.mpd and  spock2.mpd at the same time?

The results are from two different runs.

> The exact code could help here but the message
> is as expected.

Let me see what I can find out this evening. (Central Daylight Time)

I am surprised the Model 90 has not grown tired of all this swapping,
installing and tinkering. :-)

William

0
wm_walsh
6/7/2006 4:48:44 PM
Hi!

> Though the xfer rates may be acceptable, that still leaves
> one without CD-ROM support under [in]compatible mode.
> I will not burn more slots in a 90 just to prove a point.

The data is provided in the interest of being complete and thorough.
Just because you or I didn't think a given something was important does
not mean that someone else would agree.

William

0
wm_walsh
6/7/2006 4:52:23 PM
Hi!

> I could follow the AHA154x detection procedure, but if
> AHA-1640 fails to load, that won't help. IIRC, AHA-1640
> exhibits the same symptoms as Spock,  i.e. init failure?

Yes, it fails to load the same as Spock/Spock2.

So do NCR and BusTek/BusLogic. I tried 53Cxx series NCR adapters of
several different types and the BusTek BT-640A.

> The IOS loads a given port or miniport driver only if the
> configuration manager sends a request to load that driver.

I thought I saw some of this being done in the various bootlog.txt
files I've created across SCSI adapters...

William

0
wm_walsh
6/7/2006 6:54:47 PM
> Though the xfer rates may be acceptable, that still leaves one without
> CD-ROM support under [in]compatible mode. I will not burn more slots in
> a 90 just to prove a point.

That might need the real mode CD-ROM driver in CONFIG.SYS, i.e. the DOS
driver.

> Is there a way to force config mangler to load only certain miniport
> drivers? I think that is the cause of the noticeable disk thrash upon
> startup.

It loads them but driver initialization fails. "Initialization" involves
detecting adapters and setting up specific data structures holding the
configuration info. If all goes well, the driver is ready to process
requests. If not, the error return points are known and I am going to use
the LED panel of Mod. 95 for these checkpoints, including adapter port
access and SCSI port driver calls. Each one will have a code assigned and we
can monitor the progress.

I suspect, a certain system call fails.




0
UZnal
6/7/2006 7:33:21 PM
> > The exact code could help here but the message
> > is as expected.
>
> Let me see what I can find out this evening. (Central Daylight Time)

I am not so sure how reliable this code would be, because there is a bug in
the SCSI error logger. It cannot, under circumstances, log multiple errors
when there is no sufficient time slice between the errors. M$ claims, this
were a feature, err, design, and not a bug. The error sweeping thread had a
lower priority and could not empty the queue in time, or so. What a
perfection of design ...!

> I am surprised the Model 90 has not grown tired of all this swapping,
> installing and tinkering. :-)

You should ask my poor Mod. 77, the PSU and the HD suffer at most. The block
test runs for more than an hour and trashes the disk all the time.


> > I could follow the AHA154x detection procedure, but if
> > AHA-1640 fails to load, that won't help. IIRC, AHA-1640
> > exhibits the same symptoms as Spock,  i.e. init failure?
>
> Yes, it fails to load the same as Spock/Spock2.
>
> So do NCR and BusTek/BusLogic. I tried 53Cxx series NCR adapters of
> several different types and the BusTek BT-640A.

I have the code of the AHA154x (incl. AHA-1640), AHA174x, NCR53C9x and FD8xx
miniport. But I'll move tests to Mod. 95 because of the LED display, and I
need also Corvette there. The goal is to find out what part of the init
sequence fails.





0
UZnal
6/7/2006 7:54:56 PM
UZ, I look at any Windows "OS" as a tottering stack of different sized 
boxes, ready to flop over. Why do you wandt to load unneeded crap that 
may or may not be successfully unloaded?

Wouldn't having fewer drivers loaded help in bug hunting?

I personally do not believe that all code or memory locks are cleared 
when the drivers are unloaded.

UZnal wrote:
>>> 00130E40 Initing spock2.mpd
>>> 00130E46 Init Failure spock2.mpd
> 
> I could follow the AHA154x detection procedure, but if AHA-1640 fails to
> load, that won't help. IIRC, AHA-1640 exhibits the same symptoms as Spock,
> i.e. init failure?
> 
> 
> DDK/95, "Layered Block Device Drivers":
> 
> Device Driver Loading
> 
> The IOS loads and initializes port drivers, miniport drivers, and
> value-added drivers. The IOS requires the files for these drivers to be
> located in the SYSTEM\IOSUBSYS directory and to have the following filename
> extensions:
> 
> PDR Port drivers, such as SCSIPORT, ESDI_506, and NEC
> MPD SCSI miniport drivers
> VXD Value-added drivers, such as the volume tracker and vendor-supplied
> drivers
> 
> The IOS loads a given port or miniport driver only if the configuration
> manager sends a request to load that driver. The configuration manager sends
> a request if its hardware detection code locates an adapter. **Currently,
> the configuration manager can detect the IDE and AHA154x SCSI adapters
> only**. To support other adapters, the configuration manager forces the IOS
> to load all remaining miniport drivers. These drivers remain loaded only if
> they locate an adapter they can support. In general, any port driver that
> fails to locate hardware that it can support will be unloaded.
> 
> 
> 
> 
> 
> 
0
Louis
6/7/2006 8:31:40 PM
> UZ, I look at any Windows "OS" as a tottering stack of different sized
> boxes, ready to flop over. Why do you wandt to load unneeded crap that
> may or may not be successfully unloaded?

The perfection of system design, what else. The whole concept is a cocktail
of DOS, Win3.x, W95, W98 and NT stirred up. Shake that and Winblows will
drown.

> Wouldn't having fewer drivers loaded help in bug hunting?

In some cases, certainly. See, those boys do not have a clear strategy not
do they have a clear state of mind. Perhaps they think they do not need it,
something which sells so good, spoils the weak.

> I personally do not believe that all code or memory locks are cleared
> when the drivers are unloaded.

Reclaiming memory is easy but loading blindly drivers is risky. In fact,
that is ugly.





0
UZnal
6/7/2006 9:11:57 PM
On Wed, 7 Jun 2006 21:33:21 +0200, UZnal wrote:

> If not, the error return points are known and I am going to use
> the LED panel of Mod. 95 for these checkpoints, including
> adapter port access and SCSI port driver calls. Each one will
> have a code assigned and we can monitor the progress.

This is just too slick for words.

-- 

CL.

+-----------------------------------------+
| Charles Lasitter   | Mailing / Shipping |
| 401/728-1987       | 14 Cooke St        |
| cl+at+ncdm+dot+com | Pawtucket RI 02860 |
+-----------------------------------------+
0
Charles
6/7/2006 9:53:46 PM
    Why did M$ intentionally implement a procedure that by design has no 
design?

    How can this hideous technique be controlled? Can we somehow force 
the system to request permission before it starts to blindly load every 
driver? In NT, you can load specific adapters during setup. Perhaps a 
similar approach can be adopted [forced?] under W9x?

UZnal wrote:
>> I personally do not believe that all code or memory locks are cleared
>> when the drivers are unloaded.
> 
> Reclaiming memory is easy but loading blindly drivers is risky. In fact,
> that is ugly.
0
Louis
6/7/2006 10:10:51 PM
On Wed, 07 Jun 2006 17:10:51 -0500, Louis Ohland wrote:

> Can we somehow force the system to request permission before it
> starts to blindly load every driver?

If it's going to try loading all the drivers it knows about under
certain situations, is there any way we could change the universe
of drivers it knows about such that only drivers relevant to MCA
are loaded?

-- 

CL.

+-----------------------------------------+
| Charles Lasitter   | Mailing / Shipping |
| 401/728-1987       | 14 Cooke St        |
| cl+at+ncdm+dot+com | Pawtucket RI 02860 |
+-----------------------------------------+
0
Charles
6/8/2006 6:28:10 AM
> If it's going to try loading all the drivers it knows about under
> certain situations, is there any way we could change the universe
> of drivers it knows about such that only drivers relevant to MCA
> are loaded?

Removing unneeded driver files from the IOSUBSYS directory might work, the
boot log will be useful in this case. I am about to set up Mod. 95 with the
FP-bug P60, we will be soon able to see what is happening.

IIRC, OS/2 is using the same method - snooping for adapters through
drivers - at installation time but not any more after that.



0
UZnal
6/8/2006 12:11:48 PM
Tripple option, with or without disk activity light or with LED display:

June 9, 2006: http://www.members.aon.at/mcabase/pub/files/spock206.zip

Select "IBM MCA SCSI SPOCK-206 LED/95" at installation time if you wish to
monitor the Windows driver loading progress on the LED Display Panel of the
IBM PS/2 Server 95.

SPCK xxxx  = The status code xxxx of SCSI Port Initialize in Driver Entry
SPCK EXIT  = SCSI Port Initialize status code was greater than 9999
INIT SPCK  = Initializing adapter
CORVETTE   = Corvette detected
NOMC SCSI  = No MC SCSI adapters found
BAD FWxF   = Bad Firmware 0xF
INIT OK   = Init success
INIT E*FC  = Feature Control immediate command to adapter failed
UNCX E*00  = FATAL: System call failed, Uncached Extension cannot be
allocated
PHYS E*00  = FATAL: System call failed, Physical Address could not be
obtained
GPOS FAIL  = Get POS SCB command to adapter failed






0
UZnal
6/8/2006 11:40:22 PM
Mod. 9595, P60, 128MB RAM.

The Spock party misbehaved, either the cable or the card, CD reader and
writer were OK. I had to move the CD reader to Corvette, separate bus mode,
no Spock.

Bad news, W98SE shows 65MB RAM on this machine (it has 128MB). Being delayed
by Spock problems (the long cached card), I installed W98SE over PC-DOS 7
which had HIMEM.SYS in CONFIG.SYS. I'll repeat the installation with a blank
HD.

Default Spock was yellow marked. It could be the Corvette or not.

The LED display talks. It says "SPCK 0001" here. 0001 is the status code as
returned from ScsiPortInitialize(...) which must be returned from the
DriverEntry procedure, the main entry point. And that is all. No further
calls, nothing more.

DriverEntry is the entry point. Nothing special there, you just fill in the
blanks with your callbacks, the bus type and then call
ScsiPortInitialize(...) and return its status code. It must be something
someone does not like it and, hence, the driver is marked as failing init.
Sabotage ....???

"DriverEntry calls ScsiPortInitialize... A miniport driver writer can make
no assumptions about the values returned by ScsiPortInitialize....
ScsiPortInitialize calls the HwScsiFindAdapter routine after allocating
storage according to the DeviceExtensionSize that the miniport specified in
the HW_INITIALIZATION_DATA structure." (DDK-NT4).

I hope you have more luck. Test it first on a working complex to be sure
that the messages are issued to the LED panel. Then change the complex and
see what the driver speaks. I could see only the above message.

P.S. Got the new blue XGA-2 (1994) today, courtesy of Charles Lasitter.
There are a few minimal differences to the older XGA-2 (1992). I have to
move it to W95 to exactly tell the difference, but even now, on Mod. 95, the
video quality seems to me clearly better. It is a bit brighter and the
colors are livelier, fleshier ...;)



0
UZnal
6/9/2006 12:08:41 AM
> The driver is marked as failing init.

Forgot to add, BIGMEM.DRV fails too. Search BOOTLOG.TXT for the string
"fail". Would it work with less memory?




0
UZnal
6/9/2006 12:22:48 AM
Hi!

> Forgot to add, BIGMEM.DRV fails too. Search BOOTLOG.TXT for the string
> "fail". Would it work with less memory?

Hmm, I didn't see that one.

My 90 has 32MB. I can try lowering it, but this may not be pretty...

If it shows something to change, I'll very likely be amazed!

William


0
William
6/9/2006 2:48:27 AM
Hi!

> The Spock party misbehaved, either the cable or the card, CD reader and
> writer were OK. I had to move the CD reader to Corvette, separate bus
mode,
> no Spock.

I am not sure if separate bus mode would work on Win9x. Has anyone ever
proven or disproven that separate bus mode would have two of the same thing
sitting on one IRQ?

> Bad news, W98SE shows 65MB RAM on this machine (it has 128MB). Being
delayed
> by Spock problems (the long cached card), I installed W98SE over PC-DOS 7
> which had HIMEM.SYS in CONFIG.SYS. I'll repeat the installation with a
blank
> HD.

You need an updated HIMEM.SYS. The file from M$ was known as HIMEMUPD.EXE.

Not sure if Win98(SE)'s HIMEM.SYS incorporates the fix or not. If you
already had one, it may be loading instead of the Win98 one.

> DriverEntry is the entry point. Nothing special there, you just fill in
the
> blanks with your callbacks, the bus type and then call
> ScsiPortInitialize(...) and return its status code. It must be something
> someone does not like it and, hence, the driver is marked as failing init.
> Sabotage ....???

I suppose the possibility exists. This does beg the question--how did they
get just about every busmastering capable MCA adapter, and yet manage to
miss the pretty common IBM/Future Domain "Patriot"/MCS600-700 adapter?

Also, why do it over a certain speed/CPU point? Shoddy coding?
<sarcastic>Like M$ would put out shoddy code!</sarcasm>

> I hope you have more luck. Test it first on a working complex to be sure
> that the messages are issued to the LED panel. Then change the complex and
> see what the driver speaks. I could see only the above message.

I'll see what I can do...it may be the weekend before I get there. The only
Mod95 I've got free is over in the other house, taken apart and in storage.
At 25MHz base clock (486DX2-50), the CPU ought to be slow enough to let
things work.

No CD-ROM at present...but maybe I could put all the setup stuff and CABs on
a MO disk?

> P.S. Got the new blue XGA-2 (1994) today, courtesy of Charles Lasitter.
> There are a few minimal differences to the older XGA-2 (1992). I have to
> move it to W95 to exactly tell the difference, but even now, on Mod. 95,
the
> video quality seems to me clearly better. It is a bit brighter and the
> colors are livelier, fleshier ...;)

Interesting. I wonder if the "blue glass" RAMDAC is somehow more capable or
faster than the older white ones?

I've never even seen one in person, which I find odd given the number of
XGA-2 cards around.

William


0
William
6/9/2006 2:57:30 AM
> I am not sure if separate bus mode would work on Win9x. Has anyone ever
> proven or disproven that separate bus mode would have two of the same
thing
> sitting on one IRQ?

It works on W95, the MSDN version (Mod. 95, P60). In disk idle times I see
on the LED panel an SCB being sent to the adapter, that is, there is always
a command going to the adapter, and accordingly interrupt handling. Strange.


> You need an updated HIMEM.SYS. The file from M$ was known as HIMEMUPD.EXE.

You mean for W9x ...? I moved to W95 on Mod. 95 and memory size is still 65
MB.


> > DriverEntry is the entry point. Nothing special there, you just fill in
> the
> > blanks with your callbacks, the bus type and then call
> > ScsiPortInitialize(...) and return its status code. It must be something
> > someone does not like it and, hence, the driver is marked as failing
init.
> > Sabotage ....???

I'll have to move back to W98SE again. I needed a successfully operating
driver to define, fix and track the messages. My conclusions from the
yesterday's test are partly wrong, I've been too much trusting my eyes to
detect the display changes.

The messages are coming very fast, and without delay between them you can't
even perceive them. I changed that now, I inserted delays.


> I suppose the possibility exists. This does beg the question--how did they
> get just about every busmastering capable MCA adapter, and yet manage to
> miss the pretty common IBM/Future Domain "Patriot"/MCS600-700 adapter?

I have the FD miniport code, and, provided we can localize the problem, I'll
compare that to FD. But the FD card is not a busmaster.


> I'll see what I can do...it may be the weekend before I get there. The
only
> Mod95 I've got free is over in the other house, taken apart and in
storage.
> At 25MHz base clock (486DX2-50), the CPU ought to be slow enough to let
> things work.

Work with the latest build from today, and take a look at the LED messages.


> Interesting. I wonder if the "blue glass" RAMDAC is somehow more capable
or
> faster than the older white ones?

It feels very lively on P60, very quick and very responsive.




0
UZnal
6/9/2006 12:56:29 PM
Talk show FIXED, the LED display is your friend:

June 9, 2006: http://www.members.aon.at/mcabase/pub/files/spock206.zip


Tested on W95, Mod. 95 P60 Corvette, works OK.

CORETEST on IBM 0664 2GB disk:

Windows Spock = 1750 MB/sec
SPOCK206 LED  = 2450 MB/sec




0
UZnal
6/9/2006 12:58:11 PM
I think separate mode won't make a difference. Remember my efforts with 
the USN 85-NPOD Rapacious and separate bus?

The HIMEM issue with W95 was inability to see >16MB. However, it might 
have had another limit at 64MB.

http://www.gilanet.com/ohlandl/FAQ/FAQ_55a_8.html#8.5b

UZnal wrote:
>> I am not sure if separate bus mode would work on Win9x. Has anyone ever
>> proven or disproven that separate bus mode would have two of the same
> thing
>> sitting on one IRQ?
> 
> It works on W95, the MSDN version (Mod. 95, P60). In disk idle times I see
> on the LED panel an SCB being sent to the adapter, that is, there is always
> a command going to the adapter, and accordingly interrupt handling. Strange.
> 
> 
>> You need an updated HIMEM.SYS. The file from M$ was known as HIMEMUPD.EXE.
> 
> You mean for W9x ...? I moved to W95 on Mod. 95 and memory size is still 65
> MB.
> 
> 
>>> DriverEntry is the entry point. Nothing special there, you just fill in
>> the
>>> blanks with your callbacks, the bus type and then call
>>> ScsiPortInitialize(...) and return its status code. It must be something
>>> someone does not like it and, hence, the driver is marked as failing
> init.
>>> Sabotage ....???
> 
> I'll have to move back to W98SE again. I needed a successfully operating
> driver to define, fix and track the messages. My conclusions from the
> yesterday's test are partly wrong, I've been too much trusting my eyes to
> detect the display changes.
> 
> The messages are coming very fast, and without delay between them you can't
> even perceive them. I changed that now, I inserted delays.
> 
> 
>> I suppose the possibility exists. This does beg the question--how did they
>> get just about every busmastering capable MCA adapter, and yet manage to
>> miss the pretty common IBM/Future Domain "Patriot"/MCS600-700 adapter?
> 
> I have the FD miniport code, and, provided we can localize the problem, I'll
> compare that to FD. But the FD card is not a busmaster.
> 
> 
>> I'll see what I can do...it may be the weekend before I get there. The
> only
>> Mod95 I've got free is over in the other house, taken apart and in
> storage.
>> At 25MHz base clock (486DX2-50), the CPU ought to be slow enough to let
>> things work.
> 
> Work with the latest build from today, and take a look at the LED messages.
> 
> 
>> Interesting. I wonder if the "blue glass" RAMDAC is somehow more capable
> or
>> faster than the older white ones?
> 
> It feels very lively on P60, very quick and very responsive.
> 
> 
> 
> 
0
Louis
6/9/2006 3:02:10 PM
Hi!

> The HIMEM issue with W95 was inability to see >16MB. However, it might
> have had another limit at 64MB.

Dunno...I'd have to do a major RAM reshuffle to test and see. I'm not
doing that right now...the other Model 90 (with the 16MB ECC SIMMs) is
in active use under WinNT.

In any event, the /P switch mentioned in the MS KB article is worth
trying. Perhaps it would alleviate the 64MB limit as well.

William

0
wm_walsh
6/9/2006 4:28:10 PM
> I'll have to move back to W98SE again. I needed a successfully operating
> driver to define, fix and track the messages. My conclusions from the
> yesterday's test are partly wrong, I've been too much trusting my eyes to
> detect the display changes.

An evidence of confusion, the risks of the profession. You get used to think
you did it wrong and then try to prove it. But this time I must disprove it,
it is really as I said the first time. I trust my eyes and my mind:

NO LED DISPLAY ACTIVITY on W98SE !

The system call ScsiPortInitialize(...) definitely FAILS. The driver does
not even get the chance to fail, so how can we accuse it?

When the call to ScsiPortInitialize(...) succeeds, a number of driver
callback are called, you can clearly see the acitivity on the LED display.

SPOCK206 LED/95 version: try it on W95 and see how verbose the driver is.
Look at init/boot time carefully at the LED display, there will be this
message "INIT 0000" flashing for a brief time, this means success. This
happens before the GUI comes.

Move the same driver to W98SE and the LED display freezes at "INIT 0001". It
shows the return code from ScsiPortInitialize(...). Since no further driver
activities take place, these are the final words of SPOCK206.

Both W95 and W98SE show the available system memory as 65 MB (it is 128 MB).
The same W98SE on IBM GL300 with 320 MB shows correctly the full amount of
memory.

There are obviously more things going wrong. In the boot log all fonts fail
to load. Check also IOS.LOG in \WINDOWS\SYSTEM. Saying 65 MB, so it seems to
me, W98SE is running in a some secret Win3.x real/protected mish-mash mode.










0
UZnal
6/9/2006 5:13:21 PM
> > The HIMEM issue with W95 was inability to see >16MB. However, it might
> > have had another limit at 64MB.

The same W98SE shows the full 320 MB on my IBM GL300. The 65 MB is an
indication that W98SE has serious troubles somewhere. Though W95 is again
short sighted and sees only 65 MB, that does not fail driver initialization.
But W98SE uses partly the Windows Driver Model (WDM) and the problem might
be hidden there.

Even with less memory, say 32 MB, W98SE will keep on to have the same
problem. It cannot handle the complex, that is what I'd think. This complex
must have something special. Cache manager, memory manager, DMA
peculiarities ??

We will know it better if the ISA bus AHA-1542 is tested under W98SE with a
faster Pentium. It is the same miniport driver AH154X.MPD that drives
AHA-1640 as well. If the AHA-1542 fails as Spock does, it is not the
complex. I might test that before I trash that Compaq Deskpro 4000, Pentium
200, I have to make room for the 7012.















0
UZnal
6/9/2006 5:26:41 PM
Hi!

> This complex
> must have something special. Cache manager, memory manager, DMA
> peculiarities ??

Well, there's really only the one thing, besides the flashable BIOS
(which at least one non-Type 4 complex also has...) I think that can be
ruled out. The T4-486 "N" also has Flash BIOS and it works properly
with SCSI under 98SE.

But the T4-486 doesn't have...synchrostream! All the other T4 complexes
do, as does the Lacuna planar.

The only thing I'm not sure about is whether or not others have had
trouble with non-SSC (Synchrostream) complexes/planars and fast CPUs.
Something tells me this is too easy of a diagnosis and that other
complexes have failed when the CPU got to be fast enough.

William

0
wm_walsh
6/9/2006 7:28:59 PM
Oh, SHREK killed the M$ONSTER ..... !!! SPOCK206 fixed W98SE on P60.

June 11, 2006: http://www.members.aon.at/mcabase/pub/files/spock206.zip

The LED/95 option tested on W98SE with the P60 complex, Mod. 95. The other
two options (disk light, no disk light) rebuilt, untested, but should work
as well.

The offending word was MICROCHANNEL ( + PENTIUM, I would say). Look at the
line below, it defines the adapter interface type:

hwInitializationData.AdapterInterfaceType = MicroChannel;

The adapter interface type, so I suppose, is of importance for slave DMA
devices but useless to busmaster adapters. Busmasters do not need the OS to
setup a DMA transfer for them, they only need physical addresses:

hwInitializationData.NeedPhysicalAddresses = TRUE;

Go undercover now and pretend Spock to be a busmaster ISA adapter:

hwInitializationData.AdapterInterfaceType = Isa;

Build that and see how Spock talks on the LED display, W98SE + P60. That one
line fixed the things. It was that simple.

CORETEST shows the same performance as it was on W95 with SPOCK206, that is
2750 MB/sec. Before it was 680 MB/s. And, yes, the yellow mark disappeared.

P.S. Earlier today I've been looking at VMM32 and MACHINE.INF and my
conviction grew stronger that you cannot really expect M$ to treat MCA as
MCA, they have equated it everywhere with ISA, except for the system DMA
services. It was then only natural that substituting "Isa" for
"MicroChannel" fixed the driver on P60. I am indeed inclined to think that
Pentium + MicroChannel is a built-in boolean condition.




0
UZnal
6/10/2006 11:46:57 PM
Hi!

> Oh, SHREK killed the M$ONSTER ..... !!!
> SPOCK206 fixed W98SE on P60.

Confirmed! (At least it is working on the Model 90/P60 testbed machine.)

Performance is noticeably better and system response time is much snappier.
Video redraw (on-planar XGA-1, M$ driver, 1MB VRAM, 640x480x16bit color)
also feels faster.

While it is not the focus of discussion, I can confirm that a Corvette
adapter is working with this driver right now. CORETEST said that transfers
were around 6200KB/s from a 50-pin 2.1GB 7200RPM Seagate Barracuda drive.

I would test external goodies along with combined and split bus modes, but
I've got no suitable cable for the Corvette's port. (Would anybody loan one
out?)

> Build that and see how Spock talks on the LED display, W98SE + P60. That
one
> line fixed the things. It was that simple.

Just out of pure curiosity, is there hope for other adapters from NCR and
Adaptec?

> I am indeed inclined to think that
> Pentium + MicroChannel is a built-in boolean condition.

Quite possible. The number of MCA things (Audiovation and now the
Windsurfer) that also don't work and cannot initialize under Win98(se) past
a certain CPU speed/type is rather high. I am not too worried. Sound is the
least of my concerns, and I have a SoundPiper card sitting at the ready if
it becomes something I want to have.

Before I get too much further, there is the matter of a big THANK YOU for
fixing this trouble. It is great to have MCA perform more properly under
Win98(se).

William


0
William
6/11/2006 5:39:59 AM
> > Oh, SHREK killed the M$ONSTER ..... !!!
> > SPOCK206 fixed W98SE on P60.
>
> Confirmed! (At least it is working on the Model 90/P60 testbed machine.)

The CD-ROM is working too. The last build (June 11, 2006) assumes 32-bit DMA
transfers, that may not work on Mod. 56/57. Anyone to test that on Mod. 57?

> While it is not the focus of discussion, I can confirm that a Corvette
> adapter is working with this driver right now. CORETEST said that
transfers
> were around 6200KB/s from a 50-pin 2.1GB 7200RPM Seagate Barracuda drive.

I installed EZ-SCSI 4.0 from the Adaptec CD. On the IBM 0664, 16-bit wide
transfers, Corvette, the highest transfer rate is reached with 8 KB blocks,
it measures 3800 KB/s.

> I would test external goodies along with combined and split bus modes, but
> I've got no suitable cable for the Corvette's port. (Would anybody loan
one
> out?)

I don't think split bus mode will work, only single bus support for now.
That must change, because I have to complement adapter detection with slot
POS query to obtain the adapter ID. The driver must pass the config info
before a certain system call in the init procedure and this call was
enabling to issue Get POS Info to the adapter.  I'll have to also see how
two busses are managed.

I've got an external Corvette cable but the last time I tried it did not
work, the cable is defect.

> Just out of pure curiosity, is there hope for other adapters from NCR and
> Adaptec?

I was going to put forth that, YES, it is possible. These are NCR 53c9x and
Adapter AHA-1640, the miniport code is in the NT DDK. I'll "downgrade" them
to ISA and create the INF file but I cannot test them.


> > I am indeed inclined to think that
> > Pentium + MicroChannel is a built-in boolean condition.
>
> Quite possible. The number of MCA things (Audiovation and now the
> Windsurfer) that also don't work and cannot initialize under Win98(se)
past
> a certain CPU speed/type is rather high.

Technically, if the boys have had problems whatever nature with the speedy
complex, they should have tried to minimize the damage and make best efforts
to remedy the situation. You are a software engineer and not a software
saboteur. But suspicious enough, suddenly they do not have any problems with
that same speedy complex once a driver pretends the adapter were not an MCA.
If I were an IBM lawyer, I would strictly demand an explanation for this
behaviour and bring the issue to the press.

I fixed the following lines of VDMAD.VXD, the System DMA Controller. The VXD
is integrated in the VMM32.VXD, I tried manually, without an INF file, to
point the registry entries to the updated VDMAD206.VXD (again that 206
number...!), the hope showed up, the DMA Controller got the yellow mark. I
think, we can fix that too, but that won't perhaps help the Audiovation and
Windsurfer.


; Set up machine type
;
        push    ebx
        VMMCall Get_Machine_Info

        test    ebx, GMIF_MCA               ; Q: Micro channel?
        jz      SHORT not_PS2DMA            ;   N:
        mov     [VDMAD_Machine_Type], MCA_Machine

; channel 4 is available on PS2's, so assign default handler proc

[...skipped ...]

; ISA and MCA support a max of 16Mb, so make sure we aren't over that limit

        ;; UZ## 200/06/10

        jmp     sci_got_max

        ;;cmp     eax, 1000h
        ;;jbe     sci_check_xt                ; doesn't exceed 16Mb, okay
        ;;mov     eax, 1000h                  ; limit it to 16Mb
............
sci_got_max:
        mov     [DMA_Max_Physical], eax


> Before I get too much further, there is the matter of a big THANK YOU for
> fixing this trouble. It is great to have MCA perform more properly under
> Win98(se).

A small step for a man, a giant leap for the MCA ....;)






0
UZnal
6/11/2006 11:23:38 AM
UZ, WTF is this 16MB stuff? The early MCA systems are limited to 16MB 
for DMA transfers, that much is correct. But any decent system is not 
limited to 16MB, and I dinna ken why you'd have anything to do with it.

Test for planar POSID that matches systems with >16MB DMA support, and 
if found, enable it. If this is an ISA compromise, just do not limit it 
to 16MB and let the system run.

Running in ISA mode will do, since IBM designed it to just that, but I 
think that it's missing the point.

UZnal wrote:
> ; ISA and MCA support a max of 16Mb, so make sure we aren't over that limit
0
Louis
6/11/2006 2:18:56 PM
Perhaps there is a POSID for DMA width / addressing.

Louis Ohland wrote:
> Test for planar POSID that matches systems with >16MB DMA support, and 
> if found, enable it. If this is an ISA compromise, just do not limit it 
> to 16MB and let the system run.
0
Louis
6/11/2006 2:52:52 PM
> UZnal wrote:
> > ; ISA and MCA support a max of 16Mb, so make sure we aren't over that
limit

I did not write that.  I only commented out these lines:

        ;;cmp     eax, 1000h
        ;;jbe     sci_check_xt                ; doesn't exceed 16Mb, okay
        ;;mov     eax, 1000h                  ; limit it to 16Mb

> But any decent system is not
> limited to 16MB, and I dinna ken why you'd have anything to do with it.

Not me, W9x.




0
UZnal
6/11/2006 5:03:32 PM
I didn't catch the ;, my bad.

UZnal wrote:
> I did not write that.  I only commented out these lines:
> 
>         ;;cmp     eax, 1000h
>         ;;jbe     sci_check_xt                ; doesn't exceed 16Mb, okay
>         ;;mov     eax, 1000h                  ; limit it to 16Mb

What, W9x limits to 16MB? That I know. Glory to Micro$loth, let's use 
the least common denominator.

>> But any decent system is not
>> limited to 16MB, and I dinna ken why you'd have anything to do with it.
> 
> Not me, W9x.
0
Louis
6/11/2006 5:10:10 PM
Ran June 11th build. Results:


    Model 90, Turbo-Y 180MHz complex, 64MB of FPM, Corvette [.77 flash], 
narrow, 1.08 DPES-31080, 8x CD [untested]. Existing 1 June SPOCK 206 had 
"!" as expected, no CD Rom.

    Installed it over existing 1 June SPOCK-206. In device manager > 
scsi controllers > IBM MCA SCSI SPOCK 206 > Properties > Driver > Update 
Driver > have disk.

   After restart [warm restart, no power down] system came up into 
protected mode. No "!" on SCSI controller. Both DPES and CDrom visible 
under system manager.

    M$ SPOCK - 4212.4 KB/sec [M complex]

    SPOCK206 - 7588.9 KB/sec [M complex] 1 June 2006 build

    SPOCK206 - 7844.0 KB/sec [turbo-Y] 11 June 2006 build, no LED/lights

      Hmm, 7.8MB/sec, not bad for a narrow device. Wonder how a wide 
drive will do... UZ, I am not satisfied yet. When it hits 8.4MB, then I 
will be.





0
Louis
6/11/2006 6:08:36 PM
DPES has a drive to system xfer of 10MB/sec, media to interface of 
between 35-55 MB/sec (outer to inner tracks).

UZ, System Information now shows a DMA channel for SPOCK, where the 
stock driver didn't.

Louis Ohland wrote:
> Ran June 11th build. Results:
>
>    SPOCK206 - 7844.0 KB/sec [turbo-Y] 11 June 2006 build, no LED/lights
> 
>      Hmm, 7.8MB/sec, not bad for a narrow device. Wonder how a wide 
> drive will do... UZ, I am not satisfied yet. When it hits 8.4MB, then I 
> will be.
0
Louis
6/11/2006 6:26:11 PM

"William R. Walsh" wrote:
> 
> Before I get too much further, there is the matter of a big THANK YOU for
> fixing this trouble. It is great to have MCA perform more properly under
> Win98(se).



All hail UZ, Jedi Master of MCA drivers! Obi-Zed, I have a turbo-Y NT
platform sitting here awaiting your sorcerey. Will play with the latest
build of SPOCK-206 on the Ultimedia 77 as time permits today.

Thank you, so very much, for your efforts.

-Jim (can we schedule my Linux difficulties in sometime?)

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
6/11/2006 6:57:27 PM
> DPES has a drive to system xfer of 10MB/sec, media to interface of
> between 35-55 MB/sec (outer to inner tracks).

Clearly seen on the LED display, Winblows alerts the adapter in idle times
and triggers the interrupt handler. I want to know what kind of command it
sends to it. It looks either like a thread insuring the adapter presence or
so, or a retry attempt. The first SCB command to the adapter fails with
"adapter error, command error or software sequencing error".

> UZ, System Information now shows a DMA channel for SPOCK, where the
> stock driver didn't.

This setting is really useless/unneeded/unused for busmasters, I'll remove
it from the INF file. It has meaning only for slave DMA.





0
UZnal
6/11/2006 9:53:09 PM
> All hail UZ, Jedi Master of MCA drivers! Obi-Zed

Oh, let me remain SHREK, err, their SCHRECK (= fright in German).

You must see the LED panel, it has become indeed "too slick for words" (CL)
and enjoyable too.

> -Jim (can we schedule my Linux difficulties in sometime?)

Sure, if they are sexy ....;)  Fixing drivers is fun, I didn't know it. And
a quite useful activity.




0
UZnal
6/11/2006 9:57:36 PM
UZ, let's take this in a logical fashion.

Let us assume that the adapter is OK, chances are it passes advanced 
diags. That eliminates adapter error. Or is there someway that a bad 
command could result in an adapter error.

How can you test for command error? I >assume< that a command error 
would trigger an error condition.

Software sequencing error? Whazzat? It sounds that the software tries to 
get the adapter to do something that is not in sequence for SCSI 
controllers. How to test that?

Having learned to loathe M$, my money would be on the most inept reason...

UZnal wrote:
> The first SCB command to the adapter fails with
> "adapter error, command error or software sequencing error".
0
Louis
6/11/2006 11:30:51 PM
> > UZ, I am not satisfied yet. When it hits 8.4MB, then I will be.

Few drops of sewing machine oil work wonders.... Try with a different block
transfer size, the default of CORETEST is 64 KB.





0
UZnal
6/12/2006 12:34:24 AM
> > The first SCB command to the adapter fails with
> > "adapter error, command error or software sequencing error".

The error is one of these. It comes from this common part of the code.

> Let us assume that the adapter is OK, chances are it passes advanced
> diags. That eliminates adapter error. Or is there someway that a bad
> command could result in an adapter error.

Correct, no adapter error.

> How can you test for command error? I >assume< that a command error
> would trigger an error condition.

Correct, the adapter acks that in the status code. Most probably the error
is a command error, the port driver sends a command it cannot understand.
But that must be yet verified.

> Software sequencing error? Whazzat? It sounds that the software tries to
> get the adapter to do something that is not in sequence for SCSI
> controllers. How to test that?

"Software Sequencing Error" is the Spock techref terminology, as all of the
said errors. I did not understand what kind of error is that supposed to be,
nor the techref is explicit about it. Adapter overrun? Spock can process one
command per device, IIRC, but can queue up to 16 commands for up to 16
devices.





0
UZnal
6/12/2006 12:48:03 AM
What block sizes does W98SE use? Can we set W98SE to use other than it's 
default?

UZnal wrote:
>>> UZ, I am not satisfied yet. When it hits 8.4MB, then I will be.
> 
> Few drops of sewing machine oil work wonders.... Try with a different block
> transfer size, the default of CORETEST is 64 KB.
> 
> 
> 
> 
> 
0
Louis
6/12/2006 12:57:01 AM

UZnal wrote:
> 
> > -Jim (can we schedule my Linux difficulties in sometime?)
> 
> Sure, if they are sexy ....;)  Fixing drivers is fun, I didn't know it. And
> a quite useful activity.


I don't know about sexy ... maybe if you play some movies. Something in
the MCA code eventually crashes Xwindows when running an application
that is continually moving things around on the screen. Has been
duplicated on two different 95-class machines, two different video cards
and drivers, with two completely different applications.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
6/12/2006 3:45:35 AM
> What block sizes does W98SE use? Can we set W98SE to use other than it's
> default?

It should depend on the file size and some other strategy. No, I don't think
we can or should influence this internally decided block size. That is the
business of the client of the adapter, i.e. the port driver resp. the OS.





0
UZnal
6/12/2006 4:08:06 PM
> the MCA code eventually crashes Xwindows when running an application
> that is continually moving things around on the screen.

Video driver or SCSI driver?




0
UZnal
6/12/2006 4:09:43 PM
AHA-1640 MCB-206 only for Adaptec AHA-1640:

June 12, 2006: http://www.members.aon.at/mcabase/pub/files/aha206.zip

I don't have an AHA-1640 test setup. Absolutely untested, World Cup time
....;)

The miniport has been derived from the AHA154x DDK/NT4 sample. I eliminated,
as far as it was obvious, all non-MCA, i.e. non-AHA-1640 code. The code is
still bloated (70%) with bad firmware checks, special firmware cases etc.
but luckily that happens at init time. Not knowing what might apply to
AHA-1640, I left that portion unchanged but optimized it nevertheless.

Adaptec, in their attempt to support 1542B, 1542C, 1542CF, 1640 and some
more in the same miniport driver had to obviously use timings appropriate
for the slowest ISA device in this family. I eliminated long, too long waits
before write operations, streamlined the code (an ugly example: an
IF-THEN-body going for 300 lines where the ELSE-body is only one line;
negate the condition and get rid of the ELSE-body).

All that should boost up perfomance up to 15%-20%. Please post the CORETEST
numbers. William?

* * * * *

NCR: Only the following - C90 and C94 -  are supported. Is that what we
need? But these are not busmasters:

@7F4C = "NCR 53C94 SCSI Controller"
@7F4D = "NCR 3421 SCSI Controller"
@7F4F = "NCR SCSI Host Adapter Board"

and perhaps

@7F4E = "NCR SCSI Host Adapter Board"


// Adapter configuration Information.

#define ONBOARD_C94_ADAPTER_ID  0x7f4c
#define ONBOARD_C90_ADAPTER_ID  0x7f4d
#define PLUGIN_C90_ADAPTER_ID     0x7f4f




0
UZnal
6/12/2006 4:32:13 PM
> AHA-1640 MCB-206 only for Adaptec AHA-1640:
>
> June 12, 2006: http://www.members.aon.at/mcabase/pub/files/aha206.zip
>

Updated to 16-bit DMA width and word alignment. This is a 16-bit card.



0
UZnal
6/12/2006 6:25:20 PM
Hi!

> All that should boost up perfomance up to 15%-20%. Please
> post the CORETEST numbers. William?

Yes, I'll do that soon. (Within the next three or four hours, you'll
know.)

At this time I can't devote resources to installing Win98(se)
exclusively on this adapter, so it'll have to run secondary to an IBM
adapter. I'll do a standalone test as soon as I can. However, if there
are no resource conflicts, I can't see how it would matter or make any
sort of a difference.

> NCR: Only the following - C90 and C94 -  are supported. Is
> that what we need? But these are not busmasters:
> @7F4C = "NCR 53C94 SCSI Controller"
> @7F4D = "NCR 3421 SCSI Controller"
> @7F4F = "NCR SCSI Host Adapter Board"

The 53C94 adapter is definitely one that's needed. However, Win98(se)
also makes mention of a generic "NCR MCA SCSI adapter", probably much
like the "NCR SCSI Host Adapter Board" you have mentioned above.
There's also a selection for the 53C710, which is used here:
http://www.gilanet.com/ohlandl/SCSI/NCR_Dual_SIOP.html

I've never seen or heard of the "3421".

(Yes, I've got a 53C710 Dual SIOP. I'll try it if you'd like me to do
so. Looks like a nice card...over 2GB capable, busmasters, has a more
common 50 pin external connector...)

Perhaps 53C94 does not handle its own busmastering chores. It seems
like the 53C94 is just a SCSI chipset that can be used with more than
one type of computer bus. With MCA cards it seems to be used with the
86Cxx bus interface. Those parts are busmaster capable.

The NCR 3350 planar pairs a 53C94 with the 86C01 and that is busmaster
capable.

William

0
wm_walsh
6/12/2006 7:45:31 PM
> Yes, I'll do that soon. (Within the next three or four hours, you'll
> know.)

It's really not so urgent, you've got time.

> so it'll have to run secondary to an IBM adapter.

That is OK, we need first to know if it fails or not.

> The 53C94 adapter is definitely one that's needed. However, Win98(se)
> also makes mention of a generic "NCR MCA SCSI adapter"

;NCR-manufacturer device list
[NCR]
%mca_004e.DeviceDesc%=NCRC700,mca_004e
%NCR_C9X.DeviceDesc%=NCR53C94,mca_7f4c,mca_7f4d,mca_7f4f
%NCR_710.DeviceDesc%=NCR53C710,mca_01ba,mca_01bb

Our target is the second line, NCR_C9X. The other two, NCR_710 and mca_004e
have different drivers.

> I've never seen or heard of the "3421".

That was the ADF, I hope it is correct.

> (Yes, I've got a 53C710 Dual SIOP. I'll try it if you'd like me to do
> so. Looks like a nice card...over 2GB capable, busmasters, has a more
> common 50 pin external connector...)

I think, it will fail too.


> Perhaps 53C94 does not handle its own busmastering chores.

Judging by the code, it is definitely not a busmaster, but it uses slave
DMA. The code makes a call to  ScsiPortFlushDma() which "Only miniport
drivers of slave HBAs that use a system DMA controller call this routine"
(DDK/NT4).

The miniport supports the MCA, Internal and MIPS (Emulex?) variants. I am
not so sure if the ISA hack will work on this code, because PS/2 system DMA
is different. In any case, the DMA Level in the adapter settings (ADF,
SysConfig) should be chosen to be at most 3 if other settings fail. It uses
DMA Level  0, 1, 3, 5, 6, 7.


> The NCR 3350 planar pairs a 53C94 with the 86C01 and that is busmaster
> capable.





0
UZnal
6/12/2006 10:20:05 PM

UZnal wrote:
> 
> > the MCA code eventually crashes Xwindows when running an application
> > that is continually moving things around on the screen.
> 
> Video driver or SCSI driver?


My guess would be neither. It doesn't seem to be disk I/O related, and
occurs both with an XGA-2 card driven by the AGX xserver and a
Cirrus-based SVGA with XF86_SVGA xserver. My thinking is it is a bug
somewhere in the underlying Linux code that handles the MCA bus or
memory. It's like something is filling up somewhere and not getting
cleared properly. Also observed on a third MCA system without Xwindows,
but may or may not be related, is console screen corruption after some
days or weeks of continuous operation scrolling text output from a
packet radio relay program across the screen. I have also seen this on
my system while Xwindows is running, which makes me think it is related.

The application I am running is a realtime radio tracking program called
Xastir: http://www.xastir.org/

After some time (my record uptime is about a month, but would typically
run from hours to a week or so) of moving icons around on a map and
painting track lines, Xwindows will crash in a couple of interestng
manners. Users running on more mundane klone boxen report "rock stable".
This behaviour has been duplicated with another application called
LavaPS, which displays memory usage of running tasks in a form
resembling a lava lamp in realtime. LavaPS could crash things in a
matter of minutes.

This is getting complicated, and I don't know if it's making any sense
to you. I'll stop now..... :)

-Jim

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

> That is OK, we need first to know if it fails or not.

The INF file is not accepted by the device driver wizard. Windows 98se says
it is "unable to install" the updated driver and the end of the wizard cites
an "Error Code 192" as the reason.

The one obvious thing I saw was that the adapter name was displayed as
"%AHA1640.DeviceDesc%" after Windows read the INF file. Removing the %
symbols around that string at the end of the file caused the correct name to
display. This was purely cosmetic and still didn't let the INF load the
driver properly.

I tried loading the driver manually by renaming AHA1640.MPD to AHA154x.MPD.
When I did, the adapter's activity LED came on briefly, but there was still
a "!" in Device Manager. Not being overly familiar with INF file layout, I'd
guess that maybe the INF file sets up part of the illusion that this is an
ISA card?

William


0
William
6/13/2006 6:26:59 AM
> The one obvious thing I saw was that the adapter name was displayed as
> "%AHA1640.DeviceDesc%" after Windows read the INF file. Removing the %
> symbols around that string at the end of the file caused the correct name
to
> display. This was purely cosmetic and still didn't let the INF load the
> driver properly.

A typical copy-and-paste bug (editors can be dangerous!). There should be of
course no % signs around the string in the [Strings] section. But I don't
see anything else offending with plain eyes. I'll simulate a fake install
with the INF file.

Perhaps Windows is still referring somehow to the buggy INF file.

> I tried loading the driver manually by renaming AHA1640.MPD to
AHA154x.MPD.

No, that does not work. Windows inserts in the registry some sort of a
checksum.

> guess that maybe the INF file sets up part of the illusion that this is an
> ISA card?

At the INF file level, there is no such distinction. The INF is about
copying files and deleting/adding registry entries.



0
UZnal
6/13/2006 12:25:19 PM
> My guess would be neither. It doesn't seem to be disk I/O related, and
> occurs both with an XGA-2 card driven by the AGX xserver and a
> Cirrus-based SVGA with XF86_SVGA xserver. My thinking is it is a bug
> somewhere in the underlying Linux code that handles the MCA bus or
> memory.

That's what I also would suppose. It looks like a memory leak or some other
kind of resource exhaustion. It could be a small amount of memory that
accumulates drop-by-drop to a leak that causes null pointer exception on
memory allocation request.

A crash that happens after a sufficiently long time of continious operation
is typically a memory allocation problem. It could be in the OS side or but
on the application side, the latter is usually the more probable option (it
depends on how much faith you've put into the OS, but always doubt both
sides). You have to monitor the memory usage, register the amount on start
up and check it after a reasonable manipulation time. Of course, you've got
to get some feeling what exactly is a normal consumption and what is a
waste. Starting and ending an app, should produce no mem changes, i.e. what
was before start must be equal to after the end.

Also, you could check if that is somehow related to the swap size, i.e.
virtual memory. If a bigger swap file prolongues the time to crash, then it
is most probably an uncaught memory leak.


> Users running on more mundane klone boxen report "rock stable"

That could point to the system DMA, since it is handled differently on MCA.

> This is getting complicated, and I don't know if it's making any sense
> to you. I'll stop now..... :)

Go on, that is exciting. This is exactly what I meant by "sexy" .....;)



0
UZnal
6/13/2006 12:41:31 PM
Hi!

> Perhaps Windows is still referring somehow to the buggy INF file.

Which INF file is that? The M$ provided one?

I noticed that when the wizard had failed that it still referred to the
adapter by the M$ name.

> No, that does not work. Windows inserts in the registry some sort of a
> checksum.

I didn't think it would, but I wanted to exhaust all possibilities of
making the driver load.

:-)

> At the INF file level, there is no such distinction. The INF is about
> copying files and deleting/adding registry entries.

I am no expert on INF files...I know just about enough to be dangerous.

William

0
wm_walsh
6/13/2006 3:31:46 PM
Installs but driver init fails:

June 13, 2006: http://www.members.aon.at/mcabase/pub/files/aha206.zip

I'll have to give it the LED display to track the init status.





0
UZnal
6/13/2006 7:16:41 PM
And now for the NCR family, to test:

June 13, 2006: http://www.members.aon.at/mcabase/pub/files/ncr206.zip

Follwing NCR MCA SCSI host adapters are supported by this driver (I hope
so..;)):

ID      Description
------------------------------------
7F4C    NCR 53C94 SCSI Controller
7F4D    NCR 3421 SCSI Controller
7F4F    NCR SCSI Host Adapter Board
        and perhaps
7F4E    NCR SCSI Host Adapter Board





0
UZnal
6/13/2006 10:09:12 PM

UZnal wrote:
> 
> > My thinking is it is a bug
> > somewhere in the underlying Linux code that handles the MCA bus or
> > memory.
> 
> That's what I also would suppose. It looks like a memory leak or some other
> kind of resource exhaustion. It could be a small amount of memory that
> accumulates drop-by-drop to a leak that causes null pointer exception on
> memory allocation request.


Good, I'm not a programmer after all. I'm flying by the seat of my pants
here, and it's good to know that I'm thinking in the right direction.



> Also, you could check if that is somehow related to the swap size, i.e.
> virtual memory. If a bigger swap file prolongues the time to crash, then it
> is most probably an uncaught memory leak.


System has 64M of RAM, with a swapfile of 64M. On first startup, the
system barely touches swap. Subsequent crashes and restarts of X
increase memory usage. Current swap usage is at 20M, the highest I have
ever seen. I don't know how to track memory usage by individual
applications in a way that makes sense to me (TOP doesn't seem terribly
user friendly) and the gurus understandably seem reluctant to hold my
hand through it on such "old" hardware.


 
> Go on, that is exciting. This is exactly what I meant by "sexy" .....;)


OK, here's a teaser for you. Make sure that there are no children in the
room, this could get ugly:

Caught signal 11.

Server aborting...

eip: 08258f1b   eflags: 00013246
eax: 0000003f   ebx: 00000000   ecx: 00000000   edx: 00000000
esi: bffff7c8   edi: 0000003f   ebp: bffff8d8   esp: bffff670
Stack: 401d6008 0845c520 0000003f 00000000 0000016d ffffff91 bffff81c
bffff7e4
       00000000 00000000 bffff740 00000004 bffffa20 bffff9f8 00000000
00240125
       00480129 00490127 00000000 bff00000 00000000 80000000 00000000
fffffe93
       00000001 0000003f 00000000 406fc000 00000000 40830000 00000000
406f8000
Call Trace: 08255d65 08190ded 0818aa8b 08158edb 08255c7d 0813ff44
08190432
       081ebbce 080803e8 0825483d 08186b8e 0818723e 08184b23 08184bab
08269f2e
       08269fca 081a86c7 0819363d 081938a8 08193594 080b2ee2 082700d4
08184a98
       08193462 0819347b 082c90f0 0807ff80 0807ff80 0807ffa1 08192fa8
082c90f0
       0807ff80
Code: 0f b6 41 10 83 e0 03 83 c4 30 83 f8 01 0f 85 65 01 00 00 8a

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
6/14/2006 1:17:58 AM
Oh, SHREK killed another MON$TER and liberated AHA-1640 MCB-206:

June 15, 2006: http://www.members.aon.at/mcabase/pub/files/aha206.zip

Read INSTALL.TXT for the test conditions. I dare think the sample miniport
code is not so unbuggy, I had to fix and displace several elements, and hard
coded finally the interrupt level (15) and adapter SCSI ID (7) because of
garbage on adapter reads. This is an MCA adapter, why send command to
adapter to read these settings? You have to obtain them from the POS bytes,
this comes next.

NCR-206 would probably not work, the code makes a system call to obtain the
POS bytes, but that fails. AHA1640 did the same and failed, I eliminited
that. For both AHA-206 and NCR-206 this must be changed to a manual POS byte
query, then NCR should work as well.




0
UZnal
6/15/2006 2:28:01 PM
> ever seen. I don't know how to track memory usage by individual
> applications in a way that makes sense to me (TOP doesn't seem terribly
> user friendly) and the gurus understandably seem reluctant to hold my
> hand through it on such "old" hardware.

Quick replication of the crash case is rather the problem. Also, without
exactly knowing the internal resource arrangment, it is very difficult. One
has to watch for which process/thread fails and how it is related to the
problem.

> OK, here's a teaser for you. Make sure that there are no children in the
> room, this could get ugly:

You've got be either a fetishist or a genius to see through. You have to
first map the numbers to known entities.

> Call Trace: 08255d65 08190ded 0818aa8b 08158edb 08255c7d 0813ff44

This is a useful info and it is normally the call sequence or the call
stack. The topmost element should be the one wh�ch was called last. All
these numbers are useful in debug mode.




0
UZnal
6/15/2006 2:41:52 PM
UZ, please adopt a naming convention for your builds. I brought up my 90 
with a FW drive (8062KB/s) and it was like playing whack-a-mole looking 
for the latest SPOCK206 build.

   Perhaps a .xx name for beta? SPOCK206.01?
0
Louis
6/15/2006 3:01:07 PM
Buslogic BT-646? Another yellow "!" that's out there...
0
Louis
6/15/2006 3:01:56 PM
Hi!

> Buslogic BT-646? Another yellow "!" that's out
> there...

I don't know about the 646...I haven't got one to try.

As soon as time permits, I'll be trying all my NCR adapters and making
another attempt with the Adaptec.

Who asked NCR about an 0092 ADF? Was that you, Louis? Did you hear
anything?

It's a busy afternoon for me...got to visit the bank, deliver a
recalcitrant Powerbook to have it fixed (for about the 25th time <g>),
and do a few other chores. My dad picked up (probably from Curbside
Discount "broken blue light specials" department) a Sony VAIO computer
that needs to be examined. Hopefully I'll get started later this
evening.

William

0
wm_walsh
6/15/2006 3:38:13 PM
It was for the dual SIOP.

@01BA.ADF  NCR 53C710 SCSI I/O Processor (SIOP)

wm_walsh@hotmail.com wrote:
> Who asked NCR about an 0092 ADF? Was that you, Louis? Did you hear
> anything?
0
Louis
6/15/2006 4:11:23 PM
> Clearly seen on the LED display, Winblows alerts the adapter in idle times
> and triggers the interrupt handler. I want to know what kind of command it
> sends to it. It looks either like a thread insuring the adapter presence
or
> so, or a retry attempt

I updated the LED/95 version to show the bus and the target to which a
command is sent. 0:0 means bus 0 and device 0 (HD), and 0:1 is bus 0 and
target 1 (CD-ROM). That solved the mistery.

Windows constantly probes the CD-ROM, the removable media device. After I
inserted a CD, the probes continued, but you could see that the response
from the CD-ROM drive was much quicker. Without a CD, it took longer.

If you want to save a few CPU cycles, leave a CD in the CD-ROM. If you want
to save more, do not attach a removable media drive to the bus. All this
could be somehow related to the CD-autorun feature of Window, I'll test that
next.

Since obviously I am the only one using the LED display for Spock, I did not
put the updated display on mcabase.





0
UZnal
6/17/2006 7:08:36 PM
You did turn off auto insert notification?

UZnal wrote:
> Windows constantly probes the CD-ROM,
> 
> 
0
Louis
6/17/2006 10:10:58 PM
Hi!

Well, after much devotion to other projects (a good friend of mine came over
and helped me continue to strip the kitchen in my new house down to nothing
but the beams) I am back!

NCR-206 is not working. However, the problem seems to be in the INF file.
When Windows looks at the INF file, it shows an odd name:
%NCR_C9X.DeviceDesc%.

Also, Windows still says it is loading the M$ supplied ncrc710.mpd instead
of your miniport driver.

Will test the Adaptec card again to see if it works here as well.

--
Brought to you by an IBM PS/2 9585-0XF, "Defiant"
AMD 486-133/64MB/2GB S/N 23HN457


0
William
6/18/2006 7:46:48 PM
> NCR-206 is not working. However, the problem seems to be in the INF file.

Indeed, I fixed that. Reload the zip. INF file dated 2006/06/18.

I'd be surprised if it works.

> Also, Windows still says it is loading the M$ supplied ncrc710.mpd instead
> of your miniport driver.

Side effect.

> Will test the Adaptec card again to see if it works here as well.

It should, be sure to use the recommended settings, IRQ 15 and I/O 330-333.




0
UZnal
6/18/2006 10:14:24 PM
Hi!

> Indeed, I fixed that. Reload the zip. INF file dated 2006/06/18.

I reloaded the ZIP file, the inf now seems to work fine.

I started with an NCR 53C710 (Card-ID 7F4C) and it failed with a "!" in
Device Manager.

The next adapter I tried was a BusTek (Buslogic) BT-640. This is based on
the 53C94 and uses the NCR 86C05 MCA bus interface. However, there is also
some "special stuff" in the form of a 80188 CPU. This also failed to work,
and showed the same ! in Device Manager.

The final adapter I tried was a Procom MC SCSI Enabler. This features the
NCR 53CF94 and an SMC bus interface. It too failed with the same ! in Device
Manager.

I put away the last NCR card, removed the entries in Device Manager and
popped the AHA-1640 into place for a little change of pace. I used the
recommended settings. Attached to the adapter at ID4 is a Quantum 528MB SCSI
hard disk from an old Mac and an HP ScanJet 5p at ID0. Windows' Add New
Hardware wizard didn't seem to be able to finish installing the Adaptec card
(with the M$ driver), so I added it manually instead of letting Windows find
things.

I then rebooted, went into Device Manager, found the Adaptec sitting there
with a ! and went to change the driver to your latest release. Windows
dutifully installed the newly specified driver and then something
interesting happened.

Windows sat there for a bit, churned the disk and suddenly popped up a
"Found New Hardware" dialog containing the yellow question mark and "unknown
device".

This came as a surprise--I didn't know what hardware Windows could be
looking for.

Just a moment later, the screen changed..."Hewlett Packard ScanJet 5". Oh,
that! I'd completely forgotten about the built in support that Windows 98SE
came with for some digital cameras and scanners. Most of my hardware didn't
support it, so I never really used it.

The device driver wizard finished and did all that without even needing to
reboot! I went on and ran the HP ScanJet tests found in the Scanners and
Cameras control panel. All of them passed without issue.

After that, I went to make a scan. Windows Imaging locked up (I have never
managed to get that program to scan with any system and many different
versions of Windows.) but Microsoft Photo Editor worked without issue. The
thing scans "like a house afire". :-)

CORETEST says the attached Quantum 528MB SCSI drive is doing about
2871.2KB/sec.

I have been using the system a lot tonight, and it seems stable.

William

--
Brought to you by an IBM PS/2 9585-0XF, "Defiant"
AMD 486-133/64MB/2GB S/N 23HN457



0
William
6/19/2006 2:23:02 AM
> I started with an NCR 53C710 (Card-ID 7F4C) and it failed with a "!" in
> Device Manager.
>
> The next adapter I tried was a BusTek (Buslogic) BT-640. This is based on
> the 53C94 and uses the NCR 86C05 MCA bus interface. However, there is also
> some "special stuff" in the form of a 80188 CPU. This also failed to work,
> and showed the same ! in Device Manager.
>
> The final adapter I tried was a Procom MC SCSI Enabler. This features the
> NCR 53CF94 and an SMC bus interface. It too failed with the same ! in
Device
> Manager.

Well done, William, thank you. NCR behaves as expected, since a particular
system call fails. A possibility could be that the system does not support
this call when the adapter interface type is given as ISA. I am about to
implement this call and then I hope we could see more action from the NCR
team, the real Group of Death ... (= Italy, USA, Ghana, Czech Rep.).


> [AHA-1640] Windows' Add New
> Hardware wizard didn't seem to be able to finish installing the Adaptec
card
> (with the M$ driver), so I added it manually instead of letting Windows
find
> things.

There seems to be a tight connection between Windows and the AHA-154x
adapters, Windows wants the adapter settings to be confirmed. This because
of the ISA AHA-1540/42. The Windows INF option is to shut down the system
and configure the card. I changed that for the AHA-1640.

> Just a moment later, the screen changed..."Hewlett Packard ScanJet 5". Oh,
> that! I'd completely forgotten about the built in support that Windows
98SE
> came with for some digital cameras and scanners.

The SCSISCAN driver code is included in the W98 DDK, we have potentially the
possibility to adapt it.

> The device driver wizard finished and did all that without even needing to
> reboot! I went on and ran the HP ScanJet tests found in the Scanners and
> Cameras control panel. All of them passed without issue.

Running AHA-1640 with Corvette, no reboot is necessary when I update the
AHA-1640 driver. The boot devices, i.e. the disk, are on the Corvette bus.

The LED display of Mod, 95 is a great monitoring facility (can I patent this
unique invention?? ...;)). You can track what is going on when you are
installing a driver, when you say Finish, the driver is loaded and
activated.


> After that, I went to make a scan. Windows Imaging locked up (I have never
> managed to get that program to scan with any system and many different
> versions of Windows.) but Microsoft Photo Editor worked without issue. The
> thing scans "like a house afire". :-)

Scanstation with AHA-1640 sounds good, especially with XGA-2 on 800x600x64K.
The EZ-SCSI package of Adaptec (Win3.x) includes Quick Scan for SCSI
scanners.


> CORETEST says the attached Quantum 528MB SCSI drive is doing about
> 2871.2KB/sec.

Spock should get more from it.


> I have been using the system a lot tonight, and it seems stable.

Good to hear that, AHA-1640 passes the test. I must now implant the POS
query procedure in all SCSI-206 drivers, so that adapter config is
automatically obtained. Then I hope to see true signs of life from the NCR
family.

The NCR sample driver is very well written (Jeff Havens, NCR) and it makes
bets efforts to correctly identify the hardware. The clock on the MCA
variants is set at 14 Mhz. Although you can set the interrupt level in
SysConfig, interrupts are actually disabled per fixed resource, it is in
fact the driver that enables them.

Thank you again for testing, we must quickly finalize the SCSI-206 drivers.







0
UZnal
6/19/2006 11:43:09 AM
Hi!

> Well done, William, thank you.

I hope the results have been useful to you.

> then I hope we could see more action from the NCR
> team, the real Group of Death ... (= Italy, USA, Ghana,
> Czech Rep.).

I'm not sure what you mean here. Can you explain things a little more
clearly?

> The SCSISCAN driver code is included in the W98 DDK, we
> have potentially the possibility to adapt it.

Are there any particularly interesting or practical reasons to do so?
(I ask out of curiosity, and a desire to learn more.)

> Running AHA-1640 with Corvette, no reboot is necessary
> when I update the AHA-1640 driver. The boot devices,
> i.e. the disk, are on the Corvette bus.

That's exactly the setup I have got. Corvette is driving the Seagate
Barracuda boot disk and a Sony CD-ROM. (The Chinon drive gave up a
while back. I think it simply needs a cleaning, but I've had no time.
Looking inside I found something I've never seen before--a little brush
that slides back and forth over the laser diode when a disk is inserted
or ejected. It's not very effective, though, as the laser diode would
have to be in exactly one place to even be touched by the brush.)

> The LED display of Mod, 95 is a great monitoring facility
> (can I patent this unique invention?? ...;)). You can track
> what is going on when you are installing a driver, when
> you say Finish, the driver is loaded and activated.

I haven't actually tried to install any new drivers on a Model 95 yet,
but I'm curious about one thing. If a person is using the LED display
for other purposes, does the SCSI miniport overwrite the contents of
the display?

If it does, can the use of the display be turned off? (I ask primarily
because I frequently use the panel for other tasks--on the Win95
machines, it displays the computer's name and blinks the rightmost
character to indicate disk activity. My NT machines usually display a
running clock, which is very handy since most of my wall clocks aren't
that accurate. The NT machines synchronize their clocks regularly with
NIST.)

> Scanstation with AHA-1640 sounds good, especially with
> XGA-2 on 800x600x64K. The EZ-SCSI package of Adaptec
> (Win3.x) includes Quick Scan for SCSI scanners.

I had plans a few years ago to build a scanning station from a Model
90, Windows NT, a "Corvette" and the ATI GUP. The plans never
materialized because I couldn't get ahold of a working GUP and a cable
for the "Corvette" was nowhere to be found.

Eventually I settled on a ScanJet 3300C that I found refurbished and
drastically reduced in price. Unfortunately, it is USB and that means
using it with a non-PS/2 computer. It is also nowhere near as fast as a
SCSI scanner.

I guess it worked out for the best...in my limited testing so far,
XGA-1 running in high color, the Adaptec board, Windows 98 and the HP
scanner are working very nicely. There's no doubt the XGA-2 is a much
faster (and better designed) card than the GUP.

I am thinking that now I will build that scanning workstation from the
Model 90 that Tim Knight sent me. (So far it's been the machine behind
all the test results.) With Windows 98SE, an XGA-2, a connection to the
TR network, the AHA-1640 and the HP ScanJet, I think it could do quite
nicely.

There's also an Agfa scanner around here that I could try. I'd guess
that it is a pretty high end piece of equipment.

> Spock should get more from it.

Hmmm...I'm not sure I'd agree on that. I remember that even the fastest
board of the ones I tested (the short uncached SCSI/A) wasn't quite
that fast. I think it was about 300KB/sec slower.

> The NCR sample driver is very well written (Jeff Havens, NCR)
> and it makes bets efforts to correctly identify the hardware.

I wouldn't expect poor quality from NCR. While the 3350 I have seems a
bit on the cheap side, other products I've come into are very well
made. What little NCR software I have is also well thought out.

Their customer service has been outstanding, at least with regard to
their refilled printer ink cartridges. (I use them in a DeskJet 560C.)

> Thank you again for testing, we must quickly finalize the
> SCSI-206 drivers.

Certainly. Let me know if there's anything else to be tested. I'm
pretty busy these days, but I'll do my best in squeezing things in.

William

0
wm_walsh
6/19/2006 2:21:26 PM
> I hope the results have been useful to you.

Definitely, you've confirmed that AHA-1640 is working and NCR not working.
The latter fact confirms the findings here, and now the fix can be
attempted.

> > team, the real Group of Death ... (= Italy, USA, Ghana,
> > Czech Rep.).
>
> I'm not sure what you mean here. Can you explain things a little more
> clearly?

World Cup 2006 Germany, William, soccer to you, football for us. The above
is group E, and the term "Group of Death" applies to a group where favorites
are likely to die, that is, not qualify for the next round. Each team plays
three games in the group, the best two go up in the next round, 1/8 final as
they say here. In this group, all four teams have chances to qualify, but
only two teams will qualify.

> > The SCSISCAN driver code is included in the W98 DDK, we
> > have potentially the possibility to adapt it.
>
> Are there any particularly interesting or practical reasons to do so?
> (I ask out of curiosity, and a desire to learn more.)

Only if you want to customize it or modify it to support other scanners with
specific features, or perhaps non-SCSI scanners (but that is another story
then).

> I haven't actually tried to install any new drivers on a Model 95 yet,
> but I'm curious about one thing. If a person is using the LED display
> for other purposes, does the SCSI miniport overwrite the contents of
> the display?

Yes, all the time.

> If it does, can the use of the display be turned off?

You can install the driver version without the LED monitor, because this
facility is primarily for testing purposes. It gives you a good idea what is
going on inside the driver and it helped me a lot. It is quick, easy, better
than real debug mode.

> There's no doubt the XGA-2 is a much
> faster (and better designed) card than the GUP.

Definitely, the XGA-2 is hard to beat. I saw the GUP/Mach32 driver code, no
comparison to the simplicity and beauty of the XGA/XGA-2 handling.

> > Spock should get more from it.
>
> Hmmm...I'm not sure I'd agree on that. I remember that even the fastest
> board of the ones I tested (the short uncached SCSI/A) wasn't quite
> that fast. I think it was about 300KB/sec slower.

Really? AHA-1640 is a 16-bit card, DMA width is set at the driver also to
16-bits. I'd be pleasantly surprised if the AHA-1640 keeps pace with Spock.
Next task would be to find out how OS/2 manages to overcome the 1 GB barrier
with HPFS partitions.

> > Thank you again for testing, we must quickly finalize the
> > SCSI-206 drivers.
>
> Certainly. Let me know if there's anything else to be tested. I'm
> pretty busy these days, but I'll do my best in squeezing things in.

We will have a last round of tests when that routine is implemented and
then, I guess, we are finished with it. That's been a good harvest for MCA.
Like it or not, use it or not, one more supported OS can't be a bad thing.
Left on our own, we have not too many choices.




0
UZnal
6/19/2006 6:57:51 PM
Hi!

> World Cup 2006 Germany, William, soccer to you, football
> for us. The above is group E, and the term "Group of
> Death" applies to a group where favorites are likely to die,
>  that is, not qualify for the next round.

Thank you, that explains it. I don't follow sports of any type that
closely...so that's probably why I didn't know.

> Definitely, the XGA-2 is hard to beat. I saw the GUP/
> Mach32 driver code, no comparison to the simplicity
> and beauty of the XGA/XGA-2 handling.

The driver for the GUP under NT also doesn't fully utilize the
capabilities of the card. One  example is ATI's test utility...which
will happily put the card in 1024x768 at high color with a refresh rate
of 75Hz.

NT will only go up to 72Hz, which some monitors don't really like.

Lately I've taken an interest in the Artist Graphics Winsprint 1000i MC
card. This card tops out at 256 colors (have you seen any DDK code for
it?) but will do 1600x1200 at 75Hz refresh. The speed is on a par with
XGA-2, even at that high resolution. All I need now is a base video
transfer cable.

I think the 256 colors might be a hardware limit, but the card uses a
high color capable DAC.

> Really? AHA-1640 is a 16-bit card, DMA width is set at
> the driver also to 16-bits. I'd be pleasantly surprised if
> the AHA-1640 keeps pace with Spock.

Here are some of my test results for the assorted IBM MCA SCSI
adapters:

Old long uncached SCSI/A
M$: 2074.6KB/sec
UZ: 2402.8/KB/sec

New short uncached SCSI/A
M$: 2724.8KB/second
UZ: 2920.4KB/second (!!!)

Old cached SCSI/A (single oscillator)
M$: 1629.3KB/second
UZ: 1786.0KB/second

New cached SCSI/A (triple oscillator):
M$: 2194.9KB/second
UZ: 2390.9KB/second

Adaptec AHA-1640:
UZ: 2871.2KB/sec.

(no M$ findings as the driver won't load and I didn't try on Win95!)

> Next task would be to find out how OS/2 manages to
> overcome the 1 GB barrier with HPFS partitions.

That's probably a pretty straightforward task. As long as you can boot
from a partition that falls under the hardware limits, there's no
reason why a device driver (or possibly, an ASPI manager in this case)
couldn't take over from the adapter's boot-BIOS and give you access to
the rest of your disk.

Operating systems that take over (or try to take over) control of your
hardware (like WinNT, OS/2 and Linux) usually do things like this.

As an example, I have an HP Vectra VL Pentium II-300 computer that has
a limit of 8GB on its onboard IDE. My boot drive on that system is a
6GB Quantum. I have a 40GB Western Digital drive set up as a slave
drive. While the computer can only see 8GB of that drive, Windows 2000
sees the whole drive without any trouble.

William

0
wm_walsh
6/20/2006 1:44:03 PM
> Thank you, that explains it. I don't follow sports of any type that
> closely...so that's probably why I didn't know.

That is a big event here, very, very big. Especially for the breweries.

> Lately I've taken an interest in the Artist Graphics Winsprint 1000i MC
> card. This card tops out at 256 colors (have you seen any DDK code for
> it?)

No, I haven't.

> Here are some of my test results for the assorted IBM MCA SCSI
> adapters:

Yes, I saved them and will append them to the test reports. I usually run
CORETEST with the option /T:10, it runs 10 seconds for better averaging.

> Adaptec AHA-1640:
> UZ: 2871.2KB/sec.

Adaptec is obviously right in claiming that they use premium DMA controller
on this card, with data rates up to 8 MB/sec. It supports also synchronous
transfers.

The driver, AHA206, has more room for optimizations, I did not really touch
the adapter interface code. I'll have a look at it when we are done with the
POS, I am on it right now. I have integrated the changes and I need to test
them before releasing the next NCR build.


> That's probably a pretty straightforward task. As long as you can boot
> from a partition that falls under the hardware limits, there's no
> reason why a device driver (or possibly, an ASPI manager in this case)
> couldn't take over from the adapter's boot-BIOS and give you access to
> the rest of your disk.

I had something in mind when I wrote this. The driver code contains
references to this case, translation enabled for > 1GB, albeit only for
AHA-154x. I still suspect that could be done on the AHA-1640 as well, it is
only a matter of firmware fixes or but specific adapter commands. You enable
the translation on the AHA-1542 with the onboard SCSISelect utility.

> drive. While the computer can only see 8GB of that drive, Windows 2000
> sees the whole drive without any trouble.

Windows employs a built-in disk manager, it does the job.







0
UZnal
6/20/2006 10:47:36 PM
AHA-1640 MCB-206 completed, full MCA POS support:

June 25, 2006: http://www.members.aon.at/mcabase/pub/files/aha206.zip

Adapter configuration obtained from POS, test case restrictions removed. Use
any adapter configuration you like but do not yet share interrupts.
Eventually disabled adapters will be recognized and ignored.

POS query ported from QUMC with necessary adaptations. Tested OK, awaiting
your confirmations. Moving on to NCR.




0
UZnal
6/25/2006 3:37:15 PM
NCR 53C9x MCB-206 completed, full MCA POS support:

June 25, 2006: http://www.members.aon.at/mcabase/pub/files/ncr206.zip

Adapter configuration obtained from POS. Use any adapter configuration you
like but do not yet share interrupts. Eventually disabled adapters will be
recognized and ignored.

***NOT TESTED, due to the absence of NCR SCSI host adapters. I hope it
works, see INSTALL.TXT for the IDs of the supported NCR adapters. These IDs
are hard coded and validated, we can extend the list once the driver works.

Moving on to Spock to finalize all SCSI 206.







0
UZnal
6/25/2006 9:58:37 PM
Hi!

> ***NOT TESTED, due to the absence of NCR SCSI host
> adapters.

By this afternoon, it should be. I'll try the adapters I've got and
maybe a few extras just for the experience.

William

0
wm_walsh
6/26/2006 1:29:05 PM
If you ever get the dual SIOP to pop, please send me a working ADF for 
it. @0092, I think.

wm_walsh@hotmail.com wrote:
> Hi!
> 
>> ***NOT TESTED, due to the absence of NCR SCSI host
>> adapters.
> 
> By this afternoon, it should be. I'll try the adapters I've got and
> maybe a few extras just for the experience.
> 
> William
> 
0
Louis
6/26/2006 1:33:02 PM
> By this afternoon, it should be. I'll try the adapters I've got and
> maybe a few extras just for the experience.

The extras won't work, adapter ID is strictly checked for. I can relax that
for the experiment once NCR works. Also, I'd like to know what happened to
Spock which was failing. And if you are still not bored, AHA-1640 as well.

Somehow funny, only two people have AHA-1640 and only one NCR....

At the very right moment an external Corvette cable for almost nothing, also
being able to read the extended POS, separate bus option can be tested on
site, provided the cable is OK.




0
UZnal
6/26/2006 5:53:09 PM
UZ, do you have an interest in working on the NT SCSI? Once again, by 
almost doubling the W9x SCSI driver, you added weight to my contention 
that M$ is "Stuck on Stupid".

If I had an ADF that worked with my Dual SIOP, I'd try it. @0092, IIRC. 
The problem is setup claims the file is damaged.

UZnal wrote:
>> By this afternoon, it should be. I'll try the adapters I've got and
>> maybe a few extras just for the experience.
> 
> The extras won't work, adapter ID is strictly checked for. I can relax that
> for the experiment once NCR works. Also, I'd like to know what happened to
> Spock which was failing. And if you are still not bored, AHA-1640 as well.
> 
> Somehow funny, only two people have AHA-1640 and only one NCR....
> 
> At the very right moment an external Corvette cable for almost nothing, also
> being able to read the extended POS, separate bus option can be tested on
> site, provided the cable is OK.
> 
> 
> 
> 
0
Louis
6/26/2006 6:05:08 PM
How about better than 256 colors on XGA-1 under NT?

Louis Ohland wrote:
> UZ, do you have an interest in working on the NT SCSI? Once again, by 
> almost doubling the W9x SCSI driver, you added weight to my contention 
> that M$ is "Stuck on Stupid".
> 
> If I had an ADF that worked with my Dual SIOP, I'd try it. @0092, IIRC. 
> The problem is setup claims the file is damaged.
> 
> UZnal wrote:
>>> By this afternoon, it should be. I'll try the adapters I've got and
>>> maybe a few extras just for the experience.
>>
>> The extras won't work, adapter ID is strictly checked for. I can relax 
>> that
>> for the experiment once NCR works. Also, I'd like to know what 
>> happened to
>> Spock which was failing. And if you are still not bored, AHA-1640 as 
>> well.
>>
>> Somehow funny, only two people have AHA-1640 and only one NCR....
>>
>> At the very right moment an external Corvette cable for almost 
>> nothing, also
>> being able to read the extended POS, separate bus option can be tested on
>> site, provided the cable is OK.
>>
>>
>>
>>
0
Louis
6/26/2006 6:06:24 PM
> UZ, do you have an interest in working on the NT SCSI? Once again, by
> almost doubling the W9x SCSI driver, you added weight to my contention
> that M$ is "Stuck on Stupid".

The drivers will work unchanged on NT, we need only the INF to install them.
The SCSI port/miniport model in W9x comes from NT. Let us finalize the
drivers and then we can move them to NT. Also, my test setup is currently
only W9x.


> If I had an ADF that worked with my Dual SIOP, I'd try it. @0092, IIRC.
> The problem is setup claims the file is damaged.

Only these NCR adapters are supported:

ID      Description
------------------------------------
7F4C    NCR 53C94 SCSI Controller
7F4D    NCR 3421 SCSI Controller
7F4F    NCR SCSI Host Adapter Board


> How about better than 256 colors on XGA-1 under NT?

"With a little help from my friends" many things could be possible....




0
UZnal
6/26/2006 10:39:37 PM
AHA-1640 MCB-206 maintenance. Improved multiple adapters support:

June 27, 2006: http://www.members.aon.at/mcabase/pub/files/aha206.zip

Changed adapter scanning logic. Basicly, the same as of Spock-206 excluding
the planar option. Use this version to test and work with.

Windows driver date on device panel now sync'ed with the build date.




0
UZnal
6/27/2006 2:07:13 PM
SPOCK-206 completed, full MCA POS support:

June 27, 2006: http://www.members.aon.at/mcabase/pub/files/spock206.zip

Adapter configuration obtained from POS. Use any adapter configuration you
like but do not yet share interrupts. Eventually disabled adapters will be
recognized and ignored. TESTED on Mod. 95.

Windows driver date on device panel now sync'ed with the build date, for all
206.

Added William Walsh and Louis Ohland older test reports to README.TXT.

Corvette separate bus option pending.

Observe the following:

- First, known SCSI I/O ports are probed for. If there is a response from a
port, the adapter list with POS bytes for 8 slots and the planar SCSI entry
with POS bytes are built.

- Then the adapter list is scanned for Tribble (8efe), Spock (8eff) or
Corvette (8efc) and the port POS settings checked.

- If no adapters are found, the planar SCSI is checked for Tribble, Spock or
Corvette and again the port POS settings verified.

- If the planar SCSI could not be identified (e.g. Mod 57 delivers FFFF),
the port is assumed to belong to it.

- Unidentified planar SCSI (ID of FFFF): DMA width set to 16 bits and SCSI
ID to 7.

- In all other cases, DMA width set to 32 bits, and the adapter SCSI ID
taken
fom the POS setting.

- In all cases, busmaster DMA is assumed.






0
UZnal
6/27/2006 2:12:44 PM
Hi �nal,

"UZnal" <unalz-at-mail333-dot-com> schreef in bericht 
news:44a01ee1$0$3882$91cee783@newsreader01.highway.telekom.at...
>> By this afternoon, it should be. I'll try the adapters I've got and
>> maybe a few extras just for the experience.
>
> The extras won't work, adapter ID is strictly checked for. I can relax 
> that
> for the experiment once NCR works. Also, I'd like to know what happened to
> Spock which was failing. And if you are still not bored, AHA-1640 as well.
>
> Somehow funny, only two people have AHA-1640 and only one NCR....

Correction: *three* people have AHA-1640 and only one NCR....

Just checked my QUMCDOS-output:

I've got an IBM PS/2 Server 95 (9585-ONG s/n 55-4K2B8) with
  Planar SCSI (b_1): IBM PS/2 SCSI Adapter w/Cache (Spock)
*and*
  SLOT 8 ---  Adaptec AHA-1640 SCSI Host Adapter (rev F)

That one won't go into storage. However, time and space for testing is 
unfortunately not available for at least two weeks.

>
> At the very right moment an external Corvette cable for almost nothing, 
> also
> being able to read the extended POS, separate bus option can be tested on
> site, provided the cable is OK.
>

-- 
Jelte


0
JWR
6/27/2006 7:55:33 PM
Hi Jelte,

> Correction: *three* people have AHA-1640 and only one NCR....
>
> Just checked my QUMCDOS-output:
>
> I've got an IBM PS/2 Server 95 (9585-ONG s/n 55-4K2B8) with
>   Planar SCSI (b_1): IBM PS/2 SCSI Adapter w/Cache (Spock)
> *and*
>   SLOT 8 ---  Adaptec AHA-1640 SCSI Host Adapter (rev F)

Run the LED Display version so you can see the board ID, hardware ID and
firmware revision level of the AHA-1640. Output on mine is "b3 hA fB"
meaning board ID 3, hardware ID A and firmware level B.




0
UZnal
6/27/2006 9:34:55 PM

JWR wrote:
> 
> Hi �nal,
> 
> "UZnal" <unalz-at-mail333-dot-com> schreef in bericht
> news:44a01ee1$0$3882$91cee783@newsreader01.highway.telekom.at...
> >> By this afternoon, it should be. I'll try the adapters I've got and
> >> maybe a few extras just for the experience.
> >
> > The extras won't work, adapter ID is strictly checked for. I can relax
> > that
> > for the experiment once NCR works. Also, I'd like to know what happened to
> > Spock which was failing. And if you are still not bored, AHA-1640 as well.
> >
> > Somehow funny, only two people have AHA-1640 and only one NCR....
> 
> Correction: *three* people have AHA-1640 and only one NCR....


I've got a 1640. Wouldn't work in the Turbo-Y, haven't tried it in other
machines. I have some sort of NCR adapter somewhere. Maybe it was one of
the Procomm things... So little time...

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

"UZnal" <unalz-at-mail333-dot-com> schreef in bericht 
news:44a1a4a8$0$3880$91cee783@newsreader01.highway.telekom.at...
> Hi Jelte,
>
>> Correction: *three* people have AHA-1640 and only one NCR....
>>
>> Just checked my QUMCDOS-output:
>>
>> I've got an IBM PS/2 Server 95 (9585-ONG s/n 55-4K2B8) with
>>   Planar SCSI (b_1): IBM PS/2 SCSI Adapter w/Cache (Spock)
>> *and*
>>   SLOT 8 ---  Adaptec AHA-1640 SCSI Host Adapter (rev F)
>
> Run the LED Display version so you can see the board ID, hardware ID and

Sorry, no display on this 9585. Suppose I'll have to perform an 
AHA-transplant.

> firmware revision level of the AHA-1640. Output on mine is "b3 hA fB"
> meaning board ID 3, hardware ID A and firmware level B.
>


-- 
Jelte


0
JWR
6/28/2006 7:15:48 PM
Hi!

> Run the LED Display version so you can see the board ID, hardware
> ID and firmware revision level of the AHA-1640. Output on mine is
> "b3 hA fB" meaning board ID 3, hardware ID A and firmware level B.

I'll try this as well at some point, just to provide another data point. It
may not be soon.

I tried the NCR-206 driver tonight in the Model 90 with the 7F4C NCR SCSI
board. (I believe it to be the only board on your list that I have.) Windows
98SE really did not like it. The device manager/update driver wizard crashed
(with a blue screen, and after that with an illegal operation message citing
RUNDLL32 as having failed) right after I gave it the new driver information
and clicked "Next".

I thought we might get past that (slim chance, maybe, but I want to try
everything or as much as is reasonable), so I rebooted the system. Windows
halted once with a protection error and told me I needed to restart my
computer.

From that point Windows Device Manager told me the driver had stalled the
computer and that it would never be allowed to load again. (The so-called
"Automatic Skip Driver" function.)

William

--
Brought to you by an IBM PS/2 9585-0XF, "Defiant"
AMD 486-133/64MB/2GB S/N 23HN457
"UZnal" <unalz-at-mail333-dot-com> wrote in message
news:44a1a4a8$0$3880$91cee783@newsreader01.highway.telekom.at...

>
>
>
>


0
William
6/29/2006 12:03:45 AM
> I tried the NCR-206 driver tonight in the Model 90 with the 7F4C NCR SCSI
> board. (I believe it to be the only board on your list that I have.)
Windows
> 98SE really did not like it. The device manager/update driver wizard
crashed
> (with a blue screen, and after that with an illegal operation message
citing
> RUNDLL32 as having failed) right after I gave it the new driver
information
> and clicked "Next".

Strange, the NCR driver experienced the least code changes. I can simulate
an install over the AHA-1640, I'll have to devise a hack.





0
UZnal
6/29/2006 1:01:26 PM
Hi!

> Strange, the NCR driver experienced the least code changes.
> I can simulate an install over the AHA-1640, I'll have to devise
> a hack.

I can send you one or many (probably seven) NCR-based SCSI adapters if
you think it would help. My only request would be that I'd want them
back at some point.

You can contact me off the group here:
wct <atsign> walshcomptech <dot> com
or I'll check for a reply at some point...

William

0
wm_walsh
6/29/2006 4:37:19 PM
NCR 53C9x MCB-206 fixed, driver loads:

June 29, 2006: http://www.members.aon.at/mcabase/pub/files/ncr206.zip


> Strange, the NCR driver experienced the least code changes.

That was the problem, I've been partly using the original structures,
removed them and applied the full SPOCK206 adapter query style to it. That
fixed it.

> I can simulate an install over the AHA-1640, I'll have to devise a hack.

I did, driver loads now. I can't test more than this.




0
UZnal
6/29/2006 10:02:28 PM
> I can send you one or many (probably seven) NCR-based SCSI adapters if
> you think it would help. My only request would be that I'd want them
> back at some point.

Either the DDK sample works or not. An adapter alone does not suffice, you
can't fix certain problems without a techref. The last build (Jun 29, 2006)
loads, I tested it with the LED display, and reaches the point of
identifying installed adapters. From there on, all is left to the rest of
the code, which I do not intend to touch.

NCR MCA SCSI + Pentium is a working combination and that is all I wanted to
do. We slowly reach the point where a driver fix is useful to only one
person. There is no one else to test besides you.




0
UZnal
6/29/2006 10:36:59 PM
Hi!

> I did, driver loads now. I can't test more than this.

Then I will, as soon as I can. Do you have a preferred adapter in mind for
the test run?

William


0
William
6/30/2006 5:46:40 AM
> Then I will, as soon as I can. Do you have a preferred adapter in mind for
> the test run?

Any one of the three adapters supported will do, though there are
confguration differences. The NCR onboard SCSI should respond as an adapter
in a slot.




0
UZnal
6/30/2006 5:02:49 PM
Some of you will be famous again:

www.members.aon.at/mcabase/spock206.htm

And that concludes the SCSI miniport season 206.
Special thanks to all participants and winners.





0
UZnal
7/1/2006 1:31:24 PM
Hi!

> SPOCK-206 completed, full MCA POS support:

Unfortunately, I am here to report that the driver still doesn't get past
INIT 0001 on a Model 9595-0LG with Win95 OSR 2.5 and the "latest" triple
oscillator SCSI/A with cache.

Is there something I'm missing?


0
William
7/1/2006 9:45:00 PM
> > SPOCK-206 completed, full MCA POS support:

I guess you mean the latest Spock build, though I have made a week ago that
special spock206mcled.zip for you to test and report which messages you see
before you get to INIT 0001. I didn't get any response, but spock206mcled
should work. Did it work for you?

> Unfortunately, I am here to report that the driver still doesn't get past
> INIT 0001 on a Model 9595-0LG with Win95 OSR 2.5 and the "latest" triple
> oscillator SCSI/A with cache.

This has rather to do with Windows 95 which is more MCA-aware (surprise!)
and does not like lying about the adapter interface type. I will have to
supply separate driver packages for Win95 and Win98/98SE.

I wonder how Windows 95 is going to behave on a mixed bus MCA/ISA systems,
if it does not allow ISA adapters in a MCA system.


The special build below works fine with the latest SPOCK206 version and
changed adapter interface type. Tested with the planar SCSI (8EFF) on Mod.
77, works OK:

SPOCK206 full MCA POS support on Windows 95, special build:

July 2, 2006 www.members.aon.at/mcabase/pub/files/spock206w95.zip

Test now with this build, all three driver variants are operational. This
package does not include readme/install.




0
UZnal
7/1/2006 11:28:15 PM
Hi!

> I guess you mean the latest Spock build, though I have made a week
> ago that special spock206mcled.zip for you to test and report
> which messages you see before you get to INIT 0001.

Ooops. I must have missed the special build part. I thought I was supposed
to download spock206 during that timeframe.

The regular spock-206 driver seems to generate some messages before INIT
0001, but they go by too fast.

> I wonder how Windows 95 is going to behave on a mixed bus
> MCA/ISA systems, if it does not allow ISA adapters in a MCA system.

I do not think that such a beast existed. There were PCI/EISA boxen and
MCA/PCI boxen, but I don't think anyone ever produced an MCA/ISA machine.

> Test now with this build, all three driver variants are operational. This
> package does not include readme/install.

Stand by...here we go.

William


0
William
7/1/2006 11:59:39 PM
Hi!

> Ooops. I must have missed the special build part. I thought I was supposed
> to download spock206 during that timeframe.

Again the messages go by awfully fast. I'd have to cycle it a few times to
know them all.

> Stand by...here we go.

The Win95 driver file works! The flourescent display lights up, flickers and
changes very rapidly. (Is there a list of code meanings somewhere?)

CORETEST reports as follows:
M$: 2521.8KB/sec
UZ: 2360.3KB/sec

I would guess the slower result is due to the display update process that
your driver is performing right now.

William


0
William
7/2/2006 12:50:34 AM
Hi William,
> ...I do not think that such a beast existed. There were
> PCI/EISA boxen and MCA/PCI boxen, but I don't think
> anyone ever produced an MCA/ISA machine...
     IBM Gearbox 800. The bus is actually proprietary (and has a DASD
adapter that is early Spock-like), having pass-through adapters for
both MCA & ISA. But the ISA cards have to probably be pretty standard
fare (and I think the COM/LPT ports on the main card are locked into
those I/O addresses).
                       David
                       David@IBMMuseum.com

0
IBMMuseum
7/2/2006 3:33:37 AM
I wonder if someone didn't confuse the 7552 adapters (ISA) with the 7568 
adapters (MCA). I don't feel like trying a 7552 adapter in my Gearbox 800.

IBMMuseum wrote:
> Hi William,
>> ...I do not think that such a beast existed. There were
>> PCI/EISA boxen and MCA/PCI boxen, but I don't think
>> anyone ever produced an MCA/ISA machine...
>      IBM Gearbox 800. The bus is actually proprietary (and has a DASD
> adapter that is early Spock-like), having pass-through adapters for
> both MCA & ISA. But the ISA cards have to probably be pretty standard
> fare (and I think the COM/LPT ports on the main card are locked into
> those I/O addresses).
>                        David
>                        David@IBMMuseum.com
> 
0
Louis
7/2/2006 1:13:58 PM
> Again the messages go by awfully fast. I'd have to cycle it a few times to
> know them all.

You get now full one second of time to read each message. The build below
should NOT work on Windows 95 and I want to know which messages you see
before you get to INIT 0001. This is very important to further investigate
the problem.

There is only the LED version in the zip, freshly made:

July 2, 2006 www.members.aon.at/mcabase/pub/files/spock206isled.zip


> The Win95 driver file works! The flourescent display lights up, flickers
and
> changes very rapidly.

No display delays once the driver is past the init. You'll have to watch it
for a while to get used to it.

> (Is there a list of code meanings somewhere?)

See README.TXT in spock206.zip, there is a commented list of all messages.

> CORETEST reports as follows:
> M$: 2521.8KB/sec
> UZ: 2360.3KB/sec
>
> I would guess the slower result is due to the display update process that
> your driver is performing right now.

Forget CORETEST on LED display. The driver adds 16 LED panel port accesses
on the average for each request, that slows it down. This version is useful
mainly for education and debugging purposes.




0
UZnal
7/2/2006 1:32:45 PM
Hi!

> You get now full one second of time to read each message. The build
> below should NOT work on Windows 95 and I want to know which
> messages you see before you get to INIT 0001. This is very important
> to further investigate the problem.

Alrighty, I will check it out.

> No display delays once the driver is past the init. You'll have to watch
> it for a while to get used to it.

It's very, very fast. During disk accesses, the display is updated so
frequently that it appears at a lowered brightness (I'd call it dimming by
modifying the duty cycle...) or when the text changes, it never gets a
chance to fully update the display before being replaced.

In any case, the concept is "cool".

William


0
William
7/2/2006 2:58:08 PM
Hi!

> Any one of the three adapters supported will do, though there are
> confguration differences. The NCR onboard SCSI should respond as
> an adapter in a slot.

I went with 7F4C, it's the only one of the adapters I have.

There are no big crashes this time (though Windows produces a warning that
says this driver is not written for the hardware I have) but the experiment
still ends in the same way...Windows says the device is not installed, not
working properly or may not have all the drivers installed.

William


0
William
7/3/2006 11:05:24 PM
Hi William, UZ,
>> Any one of the three adapters supported will do, though
>> there are confguration differences. The NCR onboard
>> SCSI should respond as an adapter in a slot.
> I went with 7F4C, it's the only one of the adapters I have...
     The NCR System 2210 & System 3220 both have POSID 7F4D planar SCSI
on "slot 5". Trying to figure out what both of the 7F4E & 7F4F "NCR
SCSI Host Adapter Board" are. What is the POSID of the "strange" NCR
SCSI adapter for the 3300?
                        David
                        David@IBMMuseum.com

0
IBMMuseum
7/4/2006 12:41:16 AM
Hi Louis,
>> ...IBM Gearbox 800. The bus is actually proprietary,
>> having pass-through adapters for both MCA & ISA...
> I wonder if someone didn't confuse the 7552 adapters (ISA) with the 7568
> adapters (MCA). I don't feel like trying a 7552 adapter in my Gearbox 800.
     I should say only the connection is different on the Gearbox 800.
For all other things in hardware & software it is a MCA bus. And the
"ninth" slot doesn't have the MCA "card select" signal (all the desktop
MCA seem to be limited to eight slots).
                       David
                       David@IBMMuseum.com

0
IBMMuseum
7/4/2006 4:02:25 AM
Hi William, UZ,
> ...What is the POSID of the "strange" NCR SCSI adapter for the 3300?
     It doesn't seem to have one! Maybe it is just considered an
extension of the system planar since the bus connector is proprietary &
it fits no other systems (like the memory cards). Slots with these kind
of adapters are labelled as "PB" on the back (and the SCSI adapter as
"SCSI").
     My NCR 3300 already has Windows 95B. The NCR display ("640 x 480,
256 colors" Win 3.x drivers!) & SCSI entries ("NCR C700") are in place
in Device Manager ("No driver files are ..." with the SCSI, and many
"in use by an unknown device" for I/O & other resources). With a
Kingston Turbochip & 128Mb of RAM I could even go to Windows 98 if I
wanted.
                        David
                        David@IBMMuseum.com

0
IBMMuseum
7/4/2006 6:03:14 AM
> I went with 7F4C, it's the only one of the adapters I have.
>
> There are no big crashes this time (though Windows produces a warning that
> says this driver is not written for the hardware I have) but the
experiment
> still ends in the same way...Windows says the device is not installed, not
> working properly or may not have all the drivers installed.

Which Windows? It should be tested on W98SE, the driver will possibly not
work on Win95. Once I have the assurance it works on W98SE, I'll provide the
Win95 builds for all miniports.





0
UZnal
7/4/2006 11:15:36 AM
Hi David,
>      The NCR System 2210 & System 3220 both have POSID 7F4D planar SCSI
> on "slot 5". Trying to figure out what both of the 7F4E & 7F4F "NCR
> SCSI Host Adapter Board" are. What is the POSID of the "strange" NCR
> SCSI adapter for the 3300?

Both 7F4C and 7F4D should be the planar SCSI subsystems, 7F4F is the
"plugin" adapter, see the defs below.

#define ONBOARD_C94_ADAPTER_ID  0x7f4c
#define ONBOARD_C90_ADAPTER_ID  0x7f4d
#define PLUGIN_C90_ADAPTER_ID   0x7f4f



0
UZnal
7/4/2006 11:18:34 AM
Dave, between being evil and a barbarian, how did you posit the absence 
of the card select signal? The world wants to know...

IBMMuseum wrote:
> Hi Louis,
>>> ...IBM Gearbox 800. The bus is actually proprietary,
>>> having pass-through adapters for both MCA & ISA...
>> I wonder if someone didn't confuse the 7552 adapters (ISA) with the 7568
>> adapters (MCA). I don't feel like trying a 7552 adapter in my Gearbox 800.
>      I should say only the connection is different on the Gearbox 800.
> For all other things in hardware & software it is a MCA bus. And the
> "ninth" slot doesn't have the MCA "card select" signal (all the desktop
> MCA seem to be limited to eight slots).
>                        David
>                        David@IBMMuseum.com
> 
0
Louis
7/4/2006 11:34:30 AM
Hi David,

>      My NCR 3300 already has Windows 95B. The NCR display ("640 x 480,
> 256 colors" Win 3.x drivers!) & SCSI entries ("NCR C700") are in place
> in Device Manager ("No driver files are ..." with the SCSI,

SCSI.INF lists it as the equivalent of 004E "NCR 53C700 SCSI Host Adapter"
and Win9x installs the ncrc700.mpd miniport driver for it. The knock-knock
detection approach of Windows is to probe the I/O ports and then get
additional config data through port reads.

NCR C700, C710 and C5390/94 have different I/O address ranges, so it is easy
to separate them.





0
UZnal
7/4/2006 12:19:59 PM
Hi!

> Which Windows?

I used Windows 98SE.

William


0
William
7/4/2006 2:59:36 PM
Hi!

>      It doesn't seem to have one!

I don't think my 3350 reports one either, but I'll boot  a QBMCA disk and
find out.

>      My NCR 3300 already has Windows 95B. The NCR display
> ("640 x 480, 256 colors" Win 3.x drivers!) & SCSI entries ("NCR C700")

Do you have the option of picking high color in any mode?

William


0
William
7/4/2006 3:01:34 PM
Hi Louis,
> ...how did you posit the absence of the card select signal?
     The DASD module is normally installed in "slot 8" (to block slot
9). If located in another position, or absent, IBM said not to put any
MCA adapters in slot 9, only ISA if used. For a desktop system, a ninth
slot becomes a little troubling to support in the way MCA is there.
                        David
                        David@IBMMuseum.com

0
IBMMuseum
7/4/2006 3:50:04 PM
Hi William,
>> ...The NCR display [is] "640 x 480, 256 colors" [using "]Win 3.x drivers["]!
> Do you have the option of picking high color in any mode?
     No. 256 is the highest color depth available. I'll have to look at
the chipset & VRAM amount, then determine if I will supplant another
video card.
                       David
                       David@IBMMuseum.com

0
IBMMuseum
7/4/2006 4:10:29 PM
Where did the reference to Slot 9 ISA only come from?

So what does it mean? The Card Select pin is not there, or is it that 
the system programs cannot handle more than 8 slots?

IBMMuseum wrote:
> Hi Louis,
>> ...how did you posit the absence of the card select signal?
>      The DASD module is normally installed in "slot 8" (to block slot
> 9). If located in another position, or absent, IBM said not to put any
> MCA adapters in slot 9, only ISA if used. For a desktop system, a ninth
> slot becomes a little troubling to support in the way MCA is there.
>                         David
>                         David@IBMMuseum.com
> 
0
Louis
7/4/2006 5:02:23 PM
Hi UZnal,
> SCSI.INF lists it as the equivalent of 004E "NCR 53C700 SCSI
> Host Adapter" and Win9x installs the ncrc700.mpd miniport driver
> for it. The knock-knock detection approach of Windows is to probe
> the I/O ports and then get additional config data through port reads.
     As it would have to do with ISA implementations. In the case of
this NCR system & SCSI adapter (which I think would be almost always
paired together) you could get the Planar ID, then separate it from the
Model 70 -Axx & 50Z (all are F9FFh) by the reported number of MCA slots
(50Z & 70 are four slots, NCR 3300 is seven). The question remains if
the NCR 3300 supports more than one of these adapters at a time (it
looks like it would physically fit, at the expense of a RAM card in one
of the five "PB" slots).

> NCR C700, C710 and C5390/94 have different I/O address ranges,
> so it is easy to separate them.
     For the 7F4D planar SCSI on the NCR 2210 & 3220 it will always be
on "slot 5", but the Planar IDs are shared with IBM systems (FDFF for
the 2210 is shared with the Model 80 16MHz, FBFF is shared with the
Model 50-021 & 55SX). The number of supported MCA slots (five for both
the NCR 2210 & 3220) could be used, as above. Apparently the same POSID
isn't on any conventional MCA adapter, so "slot 5" could just be probed
for presence (at possible low 386SX CPU and/or proprietary RAM
capabilities both of these systems would not be able to run Windows 9x
well).
                             David
                             David@IBMMuseum.com

0
IBMMuseum
7/4/2006 5:38:51 PM
Hi Louis,
> Where did the reference to Slot 9 ISA only come from? So
> what does it mean? The Card Select pin is not there, or is it
> that the system programs cannot handle more than 8 slots?
     The nature of microchannel in these systems (not addressing
mainframe MCA) doesn't have the hardware implemented for more than
eight slots. You yourself have the note (twice) on the Gearbox 800
pages "PS/2 adapters should not be installed in the slot #9 position.
This is due to limitations with setup and diagnostic code recognizing
such adapters in that position.". If MCA (and native 7568 cards seem to
be based on MCA too) adapters don't work in slot 9, then it is left to
ISA only if used.
     I have no MCA pass-throughs for my Gearbox. Will the native
Processor or System Resource cards work there? There is a limited
number of these systems we have access to, without all the answers for
now.
     Look over Peter's
http://www.mcamafia.de/mcapage0/hintpage.htm#hint02 to show how all the
adapter POSIDs can be determined for more information. From the code,
the slots yield up their adapter POSID values by OUTputting the
following byte values to I/O port 96h (Line "30"):

Slot 1: 08h (08d)
Slot 2: 09h (09d)
Slot 3: 0Ah (10d)
Slot 4: 0Bh (11d)
Slot 5: 0Ch (12d)
Slot 6: 0Dh (13d)
Slot 7: 0Eh (14d)
Slot 8: 0Fh (15d)

"Slot 9" would be with the value of 11h (16d) OUTput to port 96h, so
plug in an MCA pass-through on your Gearbox & see if you can get a
correct POSID with an adapter installed (Extended CMOS only covers up
to Slot 8).
                         David
                         David@IBMMuseum.com

0
IBMMuseum
7/4/2006 6:27:12 PM
> ..."Slot 9" would be with the value of 11h (16d)...
     Rather 10h (16d)...
                          David
                          David@IBMMuseum.com

0
IBMMuseum
7/4/2006 9:21:43 PM
> (though Windows produces a warning that
> says this driver is not written for the hardware I have)

That shouldn't happen, it means you have device class mismatch. The INF file
declares a SCSI Controller, and that must match the selected class at
installation time.

> still ends in the same way...Windows says the device is not installed, not
> working properly or may not have all the drivers installed.

I have run the driver over the AHA-1640 on W98SE, it passed adapter
detection, from there on it enters the sample code I did not touch. Anyway,
I am going to drop NCR from the 206 list, it makes no sense to go on.




0
UZnal
7/4/2006 10:10:47 PM
Hi David,

>      Look over Peter's
> http://www.mcamafia.de/mcapage0/hintpage.htm#hint02 to show how all the
> adapter POSIDs can be determined for more information. From the code,
> the slots yield up their adapter POSID values by OUTputting the
> following byte values to I/O port 96h (Line "30"):
>
> Slot 1: 08h (08d)
> Slot 2: 09h (09d)
> Slot 3: 0Ah (10d)
> Slot 4: 0Bh (11d)
> Slot 5: 0Ch (12d)
> Slot 6: 0Dh (13d)
> Slot 7: 0Eh (14d)
> Slot 8: 0Fh (15d)

These are the channel select masks, you OUT the value to select the channel,
i.e. slot, where subsequent adapter setup operations take place. The masks
are the bit patterns of the lower 4 bits, bit-0 to bit-3. For some reason,
bit 3 is fixed at 1, so you are left with only three bits (bit-0, bit-1 and
bit-2) to select one of the eight channels. Now, for #9 one would need a
fourth bit, but which bit will be that? To speculate, that could be bit-3
set to 0, then channel masks from 0 to 7 could be used to select the second
8-channel half, i.e. from 9 to 16. But that is only a speculation....!

In my notes I see the following remark: "The status of port hex 0096 can be
read by software. However bits 4, 5 and 6 will be read as 1".

Bit-7 is used for channel reset when set to 1.


> "Slot 9" would be with the value of 11h (16d) OUTput to port 96h, so
> plug in an MCA pass-through on your Gearbox & see if you can get a
> correct POSID with an adapter installed (Extended CMOS only covers up
> to Slot 8).




0
UZnal
7/4/2006 10:49:22 PM
Hi!

> Anyway, I am going to drop NCR from the 206
> list, it makes no sense to go on.

I guess that's it then for NCR...oh well.

On a brighter note, I did try the Spock driver you said should fail on
Win95. Indeed it does, and with the display enabled, the only thing
that is ever displayed is the "INIT 0001".

William

0
wm_walsh
7/5/2006 1:55:10 PM
> > Anyway, I am going to drop NCR from the 206
> > list, it makes no sense to go on.

I did that already and updated the pages.

> I guess that's it then for NCR...oh well.

Suspended but not terminated.







0
UZnal
7/5/2006 6:19:29 PM
Hi UZnal,
> ...In the case of this NCR system & SCSI adapter (which I think would
> be almost always paired together)...
     Let me say what I have discovered about this combination. The
specific NCR system is a 3433 (although there is apparently some
similiar models too). More on the particular SCSI adapter below.

> ...The question remains if the NCR [3433] supports more than one of
> these [SCSI] adapters at a time (it looks like it would physically fit,
> at the expense of a RAM card in one of the five "PB" slots)...
     Through empirical testing tonight I went from the standard single
SCSI adapter up to four installed. Normally the NCR 3433 has four RAM
boards & one of these SCSI adapters. Each additional SCSI adapter is at
a loss of one memory card, so you can only install four SCSI cards to
be left with one base RAM adapter (each is 32Mb).
     "PB" means "Parallel Bus" for NCR (on the 3433 there is also three
32-bit MCA & one 16-bit AVE MCA slots). Did more NCR adapters use it
other than these proprietary RAM & SCSI adapters? Inquiring minds want
to know. The adapters all have a standard MCA back bracket & tabs.
    The bus is configured through a setup program much like what we are
used to. Conflicting resources are marked & a warning message comes up
in at least one instance. I saw it installing the four SCSI adapter,
but I know why.
     The SCSI adapters can have the following selection of resources:

SCSI Controller Enabled (default) or Disabled

Memory Address of:
DE000h - DFFFFh (default)
DC000h - DDFFFh
DA000h - DBFFFh
D8000h - D9FFFh
D6000h - D7FFFh
D4000h - D5FFFh
D2000h - D3FFFh
D0000h - D1FFFh
CE000h - DFFFFh
CC000h - CDFFFh
CA000h - CBFFFh
C8000h - C9FFFh
C6000h - C7FFFh
C4000h - C5FFFh

I/O Range of:
300h - 345h (default)
200h - 245h
400h - 445h
500h - 545h
600h - 645h

IRQ of 5 (default), 9, or 14

Host Adapter ID of 0 through 7 (default)

"Number of Fixed Disks Reported": "Actual" (default) or "Maximum Of 2"


     So I had "Warning 93" upon adding the fourth SCSI adapter:

"Interrupts are being shared in the system. Sharing interrupts is
allowable if supported by software, but system performance may suffer."

It went to sharing IRQ 5 on the fourth adapter, also held as a default
by the first. Nothing really mysterious here.
     The SCSI adapter is called "NCR 53C700 SCSI Controller". We should
say it is for the NCR "Parallel Bus" to avoid any confusion thinking
that it is a standard MCA adapter. No apparent POSID visible to the
end-user, although the system does probably track the "Parallel Bus"
adapters similiar to MCA.
                             David
                             David@IBMMuseum.com

0
IBMMuseum
7/6/2006 6:28:48 AM
IBMMuseum wrote:
> ..."PB" means "Parallel Bus" for NCR (on the 3433 there is also
> three 32-bit MCA & one 16-bit AVE MCA slots)...
     The 16-bit AVE is in a shared slot position with "Parallel Bus
Slot 1", normally occupied with a "PB" RAM adapter. On the "Parallel
Bus" the SCSI adapters lack one small bus extension (the size of going
from 8-bit MCA to 16-bit MCA for those in the know) that the RAM
adapters have, and are also physically shorter. So an additional RAM
adapter won't fit where the SCSI adapter is supposed to go ("PB" Slot
5), probably viewed as limiting the 3433 to 128Mb of RAM at maximum.
                             David
                             David@IBMMuseum.com

0
IBMMuseum
7/6/2006 6:41:24 AM
Hi David,

>      So I had "Warning 93" upon adding the fourth SCSI adapter:

Not unexpected, only three IRQ levels are declared in the ADF.

> "Interrupts are being shared in the system. Sharing interrupts is
> allowable if supported by software, but system performance may suffer."

System performance will be a function of the software handling the shared
interrupts. A race condition will occur when interrupts arrive at the same
time, the interrupt handling routine should be very quick to process the
request. When assisted by the adapter hardware, handling shared interrupts
is pretty simple. Spock, for instance, sets a flag when it issues an
interrupt. AHA-1640 resp. 154x do similarly. The Spock and Adaptec 1640/154x
SCSI interface architectures are conceptually quite similar.

I did experimentally share interrupts in the hardware, between Corvette and
AHA-1640, but left it unhandled in the driver software. The interrupt
surprised the wrong driver, I was watching it on the LED display. One day I
could come back to it and let them happily share the same slice of bread,
but that is rather a case for a heavily loaded system.




0
UZnal
7/6/2006 12:44:39 PM
Hi!

>      "PB" means "Parallel Bus" for NCR (on the 3433 there is also
> three 32-bit MCA & one 16-bit AVE MCA slots). Did more NCR
> adapters use it other than these proprietary RAM & SCSI
> adapters?

Is this the SCSI card that you're talking about?
http://greyghost.dyndns.org/mcastuff/ncrmystery/

The 3350 has some similar slots, although this card is much too tall to
fit the system. The purpose of one is to facilitate the installation of
a Clarity I video card. The other is for the processor card. Both are
slots are completely identical.

(I would love to find or see a Clarity I video card.)

http://www.gilanet.com/ohlandl/ncr/3350.html

> The adapters all have a standard MCA back bracket & tabs.

I think they should...on the 3350 there is no choice but to go into a
standard MCA slot opening in the back of the case.

> No apparent POSID visible to the end-user, although the
> system does probably track the "Parallel Bus" adapters
> similiar to MCA.

Does QBMCA/IDMCA show any IDs?

William

0
wm_walsh
7/6/2006 1:57:11 PM
Hi William,
> Is this the SCSI card that you're talking about?
> http://greyghost.dyndns.org/mcastuff/ncrmystery/
     Yes, I looked a little for your link & couldn't find it earlier. In
addition to these SCSI cards installed in two working 3433s (one reporting a
low Dallas RTC battery, but seems to hold its settings) I have three
spares. I wonder if Jerry purged his 3434 models (which sound like they have
a couple more MCA slots) in his move.

> The 3350 has some similar slots, although this card is much too
> tall to fit the system. The purpose of one is to facilitate the
> installation of a Clarity I video card. The other is for the
> processor card. Both slots are completely identical.
     If the SCSI card won't fit, than neither will the "PB" RAM cards (for
adding memory to at least the 3433). I can diagram them sometime by abusing
what you have for the SCSI adapter. On one of my 3433s it has a black
retention clip towards the front on three of the RAM cards that are
seemingly unused, so they have to be used in other models (large NCR
servers?).
     On the 3433 the CPU (486 chassis, with me having a Kingston Turbochip
in there right now) is on the mainboard. Your 3350 CPU card looks like it 
would go in one of the other NCRs I have, but I am not sure it (or the 
Clarity card) is for the Parallel Bus (with the later details we can start 
to figure that out). As the SCSI card shows, it looks to be very long 
connectors.

> Does QBMCA/IDMCA show any IDs?
     I'm using another comparable method (IBM SIT for DOS), but no it 
doesn't. At some later point I will probe to see where the Parallel Bus data 
might be stored on the system. Were you able to get a POSID from the SCSI on 
the planar of your 3350 (should be MCA slot 5)?
                                      David
                                      David@IBMMuseum.com 


0
David
7/6/2006 6:17:56 PM
Hi William,
> ...Were you able to get a POSID from the SCSI on the planar of your 3350 
> (should be MCA slot 5)?
     An NCR 3350 Planar ID would be nice too, I'll change my page for the 
NCR models tonight...
                                     David
                                     David@IBMMuseum.com 


0
David
7/6/2006 6:22:55 PM
>      An NCR 3350 Planar ID would be nice too, I'll change my page for the
> NCR models tonight...

Here is the QUMC dump posted 8 months ago:

Oct 30, 2005 NCR 3350 with cards
CSIPH William Walsh
==================================
.............
SLOT 5 ---  NCR 53C94 SCSI Controller
AdapterID   7F4C
-------------------------------------
...............
PLANAR ---  PS/2 Model 8570-Axx Systemboard 386DX-25 (or 8550 50Z, 80286-10)
PlanarID    F9FF
-------------------------------------



0
UZnal
7/6/2006 6:38:47 PM
Hi UZnal,
> SLOT 5 ---  NCR 53C94 SCSI Controller
> AdapterID   7F4C
     Thanks for the info. So this would be very similiar to my two different 
NCR systems (data to follow sometime). And for the two 7F4C & 7F4D POSIDs 
they will never show up on adapters?

> [NCR 3350] PLANAR ---  PS/2 Model 8570-Axx
> Systemboard 386DX-25 (or 8550 50Z, 80286-10)
> PlanarID    F9FF
     ...or NCR 3433 planar...
                           David
                           David@IBMMuseum.com 


0
David
7/6/2006 9:44:01 PM
Hi David,

> And for the two 7F4C & 7F4D POSIDs they will never show up on adapters?

Who knows, they are in any case occupied by the onboard SCSI subsystems.

7F4C is the onboard C94 - 16-bit DMA
7F4D is the onboard C90 - 8-bit DMA
7F4F is the adapter C90 - 8-bit DMA

All three at 14 MHz clock speed, of those only C94 (7F4C) is the high
performer. 8-bit DMA is pretty low, the Spock family does 32-bit DMA.






0
UZnal
7/6/2006 10:53:19 PM
> I went with 7F4C, it's the only one of the adapters I have.
>
> There are no big crashes this time (though Windows produces a warning that
> says this driver is not written for the hardware I have) but the
experiment
> still ends in the same way...Windows says the device is not installed, not
> working properly or may not have all the drivers installed.

For the record, this test has been invalidated by the following statement
made in the posting "Re: Anyone get the NCR Dual SCSI to work?" from July 7,
2006:

"I've made a mistake here, and I don't really know how I managed it. (It's
not so much the mistake that surprises me. It's how I missed it for so long
that I find bothersome.) What I thought was a 7F4C is really an 01BA. So in
reality, I cannot yet say the driver doesn't work, as I have not been using
an adapter that it supports!

Ooops. :-(

William"





0
UZnal
7/8/2006 11:32:38 AM
Finalized SPOCK206 and AHA206 for W9x, separate drivers for W95 and W98SE:

June 9, 2006 www.members.aon.at/mcabase/services.htm

Unzip the compressed files by preserving and recreating the original
directory structure. For PKUNZIP on DOS, use the command line option -d.
Install the driver from the WIN95 directory for Windows 95, from WIN98 for
Windows 98SE.

Moving to SPOCK206 for Windows NT.




0
UZnal
7/9/2006 9:35:13 PM
I'm here for you.....

UZnal wrote:
> Moving to SPOCK206 for Windows NT.
0
Louis
7/9/2006 10:19:28 PM
Have you ever gotten the corvette card to run faster than 9mb/s ?
From my benchmarks I ran a long while ago, it seemed like the corvette
in NT or win95, was only using narrow-fast, or wide-normal transfers,
I never could get it to go over 10mb/s, even with ultra160 hard disks.
Maybe your spock206 driver can fix this?

>Finalized SPOCK206 and AHA206 for W9x, separate drivers for W95 and W98SE:
>
>June 9, 2006 www.members.aon.at/mcabase/services.htm
>
>Unzip the compressed files by preserving and recreating the original
>directory structure. For PKUNZIP on DOS, use the command line option -d.
>Install the driver from the WIN95 directory for Windows 95, from WIN98 for
>Windows 98SE.
>
>Moving to SPOCK206 for Windows NT.
>
>
>

0
Casolai
7/15/2006 5:14:42 AM
> Have you ever gotten the corvette card to run faster than 9mb/s ?
> From my benchmarks I ran a long while ago, it seemed like the corvette
> in NT or win95, was only using narrow-fast, or wide-normal transfers,
> I never could get it to go over 10mb/s, even with ultra160 hard disks.
> Maybe your spock206 driver can fix this?

Negotiations between the host adapter and the devices on the bus are a
private matter, and should remain so. The driver receives a configured bus
and communicates with the adapter in terms of services on behalf of the
operating system. If the OS sends a WIDE or SYNC transfer message to a
device, the driver can only validate the request and pass it on. But the OS
normally sees only logical devices.

I have just finished the NT install INF for SPOCK206, and I am expecting
tests to yield a 10% to 15% transfer rate improvement over the NT driver.
Eventually, you will be able to get 12 MB/sec or some more with your setup.

Newer disks are usually backwards compatible to SCSI-2 (or, so I suppose),
but how they exactly do behave during a negotiation with Corvette is an
unknown matter to me. Some may be brave, some less. If they are too fast and
overrun the adapter, Corvette may fall back to a safer speed. I remember
such a CORETEST run on DOS with a wide DDRS, after the first benchmark,
speed dropped dramatically down.








0
UZnal
7/15/2006 12:22:19 PM

UZnal wrote:
> 
> I have just finished the NT install INF for SPOCK206, and I am expecting
> tests to yield a 10% to 15% transfer rate improvement over the NT driver.
> Eventually, you will be able to get 12 MB/sec or some more with your setup.


Have the Turbo-Y with Corvette NT4 box patiently awaiting your Jedi
sorcery. I don't have any outstanding disks connected to the Corvette,
just 0661 series 300 and 400 meg, and an IBM DPES-31080, so the test
results will likely be pretty mundane. The big disks (Imprimis and HP)
are in an extarnal Sun box connected to the BT646S. If I could ever find
a Sun-to-Corvette cable...

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
7/16/2006 8:50:59 PM
> Have the Turbo-Y with Corvette NT4 box patiently awaiting your Jedi
> sorcery. I don't have any outstanding disks connected to the Corvette,
> just 0661 series 300 and 400 meg, and an IBM DPES-31080, so the test
> results will likely be pretty mundane. The big disks (Imprimis and HP)
> are in an extarnal Sun box connected to the BT646S.

I am a bit too busy these days and it seems like there are two different
ways for the INF file. I used the sample from the DDK, which is a script and
each driver version gets one, but I also did a combined INF a la W9x.

I just found out that I've had three more diskbench programs, a higher
version and more precise CORETEST, a Quantum benchmark and another one
called RAIDMark. The last two want to run only on true DOS. I'll make them
available.

> If I could ever find a Sun-to-Corvette cable...

I thought I found one, but no, it will suit the AHA-1640.




0
UZnal
7/17/2006 11:17:37 AM

UZnal wrote:
> 
> 
> I am a bit too busy these days and it seems like there are two different
> ways for the INF file. I used the sample from the DDK, which is a script and
> each driver version gets one, but I also did a combined INF a la W9x.


No hurry, take your time. This computer isn't going anywhere. If you
wait long enough, I may even have some bigger drives in it...


> > If I could ever find a Sun-to-Corvette cable...
> 
> I thought I found one, but no, it will suit the AHA-1640.

Had a HD50 double-female adapter that I used with a Spock cable for a
while, but it's been misplaced. I REALLY like that Sun enclosure. Maybe
someday I will rework if with some more generic connectors.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
7/18/2006 3:27:26 AM
> No hurry, take your time. This computer isn't going anywhere. If you
> wait long enough, I may even have some bigger drives in it...

Indeed, I should have. I twice had to repair my NT installation, also
managed to damage SP6, strange things are happening to Spock206 on NT4. The
driver inits OK as far as adapter and resource detections are concerned.
Then it suddenly freezes with an unintelligible return value 'INIT �496', it
should have been 'INIT 0000'.

It could be the additional DMA settings or not, hard to tell. I suspect some
settings conflict there because the init routines are entered and exited
successfully (I test with the LED display). The return value comes from NT4.

Before I started testing, I copied the hardware profile thinking the old
config will be retained. But no, once Spock206 does not move, both profiles
are affected by it. Testing becomes incredibly difficult, we can't test and
repair the installation each time a test fails ... Any ideas?



0
UZnal
7/18/2006 3:57:10 PM
> Testing becomes incredibly difficult, we can't test and
> repair the installation each time a test fails ... Any ideas?

Test with the NT install diskettes. Copy the driver to disk-3, remove
unneeded drivers from disk-3 to save loading time. Start install with
disk-1, pretend to R-epair, uncheck repair options and a bit later you
insert disk-3 and can see on the LED display what is going on. Warning: this
is an onsite developers test, you will perform the user test.

Spock206 works on NT by the above test. The problem must be then either with
the INF file or with the driver update steps, I must see and test with the
other INF version.

I tested on Mod. 95 with Corvette & wide DDRS, and Spock w/cache & two
CD-ROM drives. Both adapters were detected, init ended successfully.






0
UZnal
7/18/2006 11:21:45 PM
SPOCK206 on NT at speed of light, Buzz Lightyear hardcore fans only:

July 20, 2006 www.members.aon.at/mcabase/pub/files/spock2nt.zip

M$ = 6100 KB/sec
UZ = 9800 KB/sec

Preliminary release, no install instructions in zip, will be added later.
This release is for those of you who can't wait a minute longer, here we go:

- Unzip the zip, you get the directory SPOCK208 (yes, 208, test number)
- Click Control Panel group
- Click SCSI Adapters applet
- Click Drivers tab
- Hit Add button
- Select vendor "Other" (left panel) and then "Disk" (button right)
- Click on one INF:
    spock2 = default , no disk light
    spock2b = disk light
    spock2c = LED monitor
- NT neatly lists all options
- Select again the desired version
- If NT prompts you, enter "A:\SPOCK208" for the full path to driver

- DO NOT DARE SAY YES to "Restart Computer" prompt of NT
- Hit ***NO***
- Stay in the SCSI driver window
- Click on "IBM MCA SCSI Host Adapter"
- Hit REMOVE button
- You must have only SPOCK206 left in the SCSI Adapters of SPOCK.
- Reboot

WARNING: You must remove the previous Spock driver after you have installed
Spock206. That was the only problem with my first tests, I did not remove it
and deadlocked the system with two competing drivers loaded. Remember to hit
NO when asked to restart the computer. Remove the previous Spock as
described above and only then restart.

Remove always the previous Spock, no matter which one it is !!!




0
UZnal
7/20/2006 11:17:44 PM
Spock206 is very fast on NT:

Test setup: NT4/SP3, Mod. 95 on P60, wide DDRS (4 GB) on Corvette, Plextor
12xPlex and Yamaha 4416S on Spock with cache. Timings with EZ SCSI 4.0 which
says "On Windows NT, throughputs showed do not reflect the true performance
of your SCSI adapter. The actual values may be considerably higher ...".

Hmmm, is this Adaptec's excuse or what...? I checked this claim with
12xPlex, it did 1800 KB/sec which corresponds to a 12x CD-ROM speed, the
correct result.

Here my results with a 64K transfer size for the wide IBM DDRS (SEQ =
Sequential Access, RND = Random Access and SEC = Same Sector Access),
average values:

M$ SPOCK
    6100 KB/sec SEQ
    2400 KB/sec RND
    2600 KB/sec SEC

SPOCK-206
    9800 KB/sec SEQ (but at times it hit the 11000 KB/sec marks !!!)
    3100 KB/sec RND
    3900 KB/sec SEC

SPOCK-206 DISK LIGHT
    9600 KB/sec SEQ
    3100 KB/sec RND
    3900 KB/sec SEC

SPOCK-206 LED PANEL
    9300 KB/sec SEQ
    3000 KB/sec RND
    3800 KB/sec SEC


Plextor 12xPlex caddy CD-ROM Drive:
    1800 KB/Sec SEQ

Yamaha 4416S CD-ROM Drive/CD Writer:
    1600 - 1700 KB/sec SEQ

The 16x Yamaha is slower than the 12x Plextor ....!







0
UZnal
7/20/2006 11:18:32 PM
    I want to see what this does on the porch system before exposing my 
main system to it. Looks about a 35% increase.

UZnal wrote:
> SPOCK206 on NT at speed of light, Buzz Lightyear hardcore fans only:
> 
> July 20, 2006 www.members.aon.at/mcabase/pub/files/spock2nt.zip
> 
> M$ = 6100 KB/sec
> UZ = 9800 KB/sec
> 
> Preliminary release, no install instructions in zip, will be added later.
> This release is for those of you who can't wait a minute longer, here we go:
> 
> - Unzip the zip, you get the directory SPOCK208 (yes, 208, test number)
> - Click Control Panel group
> - Click SCSI Adapters applet
> - Click Drivers tab
> - Hit Add button
> - Select vendor "Other" (left panel) and then "Disk" (button right)
> - Click on one INF:
>     spock2 = default , no disk light
>     spock2b = disk light
>     spock2c = LED monitor
> - NT neatly lists all options
> - Select again the desired version
> - If NT prompts you, enter "A:\SPOCK208" for the full path to driver
> 
> - DO NOT DARE SAY YES to "Restart Computer" prompt of NT
> - Hit ***NO***
> - Stay in the SCSI driver window
> - Click on "IBM MCA SCSI Host Adapter"
> - Hit REMOVE button
> - You must have only SPOCK206 left in the SCSI Adapters of SPOCK.
> - Reboot
> 
> WARNING: You must remove the previous Spock driver after you have installed
> Spock206. That was the only problem with my first tests, I did not remove it
> and deadlocked the system with two competing drivers loaded. Remember to hit
> NO when asked to restart the computer. Remove the previous Spock as
> described above and only then restart.
> 
> Remove always the previous Spock, no matter which one it is !!!
> 
> 
> 
> 
0
Louis
7/21/2006 3:46:09 PM
>     I want to see what this does on the porch system before exposing my
> main system to it. Looks about a 35% increase.

This one was a 60% increase. I want to see your numbers.

> > M$ = 6100 KB/sec
> > UZ = 9800 KB/sec




0
UZnal
7/21/2006 10:04:14 PM
UZ, I need the app that you are using to measure the SCSI transfer rates.

My porch 90 is reassembled with the cover back on. P90, 64MB, corvette, 
DDRS, and 20x Plextor CD.

Just need to be able to have the same app in order to measure xfer rates...

UZnal wrote:
>>     I want to see what this does on the porch system before exposing my
>> main system to it. Looks about a 35% increase.
> 
> This one was a 60% increase. I want to see your numbers.
> 
>>> M$ = 6100 KB/sec
>>> UZ = 9800 KB/sec
> 
> 
> 
> 
0
Louis
7/21/2006 10:39:32 PM
> UZ, I need the app that you are using to measure the SCSI transfer rates.

It is the SCSI Bench included in Adaptec's EZ SCSI 4.0 CD-ROM, the package
is too big to put in a bottle. I remember seeing it on Adaptec's support
site, look at the AHA-1640/154x/174x pages, i.e. legacy discontinued
adapters.

Check the EZ SCSI downloads, a slight chance it is there:

http://www.adaptec.com/en-us/support/_eol/




0
UZnal
7/22/2006 8:20:56 AM
Wendt there, they had the updates, AFAIK. I'll give 'er the old college 
try [drink enough and forget it].

UZnal wrote:
>> UZ, I need the app that you are using to measure the SCSI transfer rates.
> 
> It is the SCSI Bench included in Adaptec's EZ SCSI 4.0 CD-ROM, the package
> is too big to put in a bottle. I remember seeing it on Adaptec's support
> site, look at the AHA-1640/154x/174x pages, i.e. legacy discontinued
> adapters.
> 
> Check the EZ SCSI downloads, a slight chance it is there:
> 
> http://www.adaptec.com/en-us/support/_eol/
> 
> 
> 
> 
0
Louis
7/22/2006 11:49:50 AM
No EZ SCSI packages there.

Louis Ohland wrote:
> Wendt there, they had the updates, AFAIK. I'll give 'er the old college 
> try [drink enough and forget it].
> 
> UZnal wrote:
>>> UZ, I need the app that you are using to measure the SCSI transfer 
>>> rates.
>>
>> It is the SCSI Bench included in Adaptec's EZ SCSI 4.0 CD-ROM, the 
>> package
>> is too big to put in a bottle. I remember seeing it on Adaptec's support
>> site, look at the AHA-1640/154x/174x pages, i.e. legacy discontinued
>> adapters.
>>
>> Check the EZ SCSI downloads, a slight chance it is there:
>>
>> http://www.adaptec.com/en-us/support/_eol/
>>
>>
>>
>>
0
Louis
7/22/2006 1:01:15 PM
> UZ, I need the app that you are using to measure the SCSI transfer rates.

Looks like it needs only WINASPI, worked for IDE CD-ROM drives on W98SE:

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






0
UZnal
7/22/2006 8:36:06 PM
> > Wendt there, they had the updates, AFAIK. I'll give 'er the old college
> > try [drink enough and forget it].

Not yet, I've put it in a tiny bottle, get it, same for the test crew. Works
for SCSI disks and cdroms, even for IDE cdroms. It needs only WINASPI, so it
seems to me.

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

Let the games begin ...






0
UZnal
7/22/2006 8:48:26 PM
Hi!

> Not yet, I've put it in a tiny bottle, get it, same for the test crew.
> Works for SCSI disks and cdroms, even for IDE cdroms. It
> needs only WINASPI, so it seems to me.

CTL3D.DLL is also a requirement. Fortunately, it is easily downloaded from a
Google search if you don't have it.

I got that figured out and tried to run some benchmarks. Unfortunately, it
doesn't go...Windows says the NTVDM CPU executed an invalid instruction.
Attempting to close the program from that dialog results in several more of
the same dialogs, until Windows finally says that the Win16 subsystem may
have destabilized. Choosing to shut that down allows me to regain control.

I wonder if there could be some issue with two SCSI host adapters.

Your beta driver seems to be working great, and this system (see signature
for config) does feel a good deal faster. (I chose the disk light version.)
I'll try to get some hard and fast numbers to put up here. In the meantime,
I am curious about your report...what adapter did you use?

William
-- 
Brought to you by an IBM PS/2 9585-0XF "Clarus"
Intel 486DX4/100, 2GB HDD, 64MB RAM S/N 23HD700


0
William
7/23/2006 1:58:35 AM
Hello,
I tried this spock208 on my 9595 and also ran into the missing ASPI
and CTL3D.DLL. I installed adaptec aspi 4.71.2 and added in the
missing CTRL3D.DLL, but I also got the same NTVDM CPU error. 

According to the docs I read, CTL3D.DLL is not meant for NT and is for
win95/98. The NT version of that file is CTL3DV2.DLL. I made a copy of
CTL3DV2.DLL and renamed it to CTL3D.DLL to see if scsi bench could use
it, and it did. But when I click to start the benchmark, scsi bench
just exits with no error messages. I'm going to try SiSoft Sandra
2001te and see if it can benchmark the disks.

Casolai
>
>CTL3D.DLL is also a requirement. Fortunately, it is easily downloaded from a
>Google search if you don't have it.
>
>I got that figured out and tried to run some benchmarks. Unfortunately, it
>doesn't go...Windows says the NTVDM CPU executed an invalid instruction.
>Attempting to close the program from that dialog results in several more of
>the same dialogs, until Windows finally says that the Win16 subsystem may
>have destabilized. Choosing to shut that down allows me to regain control.
>
>I wonder if there could be some issue with two SCSI host adapters.
>
>Your beta driver seems to be working great, and this system (see signature
>for config) does feel a good deal faster. (I chose the disk light version.)
>I'll try to get some hard and fast numbers to put up here. In the meantime,
>I am curious about your report...what adapter did you use?
>
>William

9595-1NT: 256mb ram, P90, 3x 9.1gig DPSS Ultra160
2x IBM 8x CDROM, Corvette, Reply SB-16, Yamaha DB50XG
PCMCIA, Dual Etherstreamer, Cheetah with SideCard, GUP
Digi MC16i, NT4 Server
0
Casolai
7/23/2006 6:45:24 AM
Here are the benchmarks from SiSoft Sandra 2001te Professional:

Buffered Read              12mb/s
Sequential Read          12mb/s
Random Read              5mb/s
Buffered Write               8mb/s
Sequential Write           12mb/s
Random Write               7mb/s
Average Access Time   7ms (estimated)

These are a considerable improvement over the NT default driver, it
never got more than 9mb/s before with these hard disks.

Damn fine effort UZ !!

9595-1NT: 256mb ram, P90, 3x 9.1gig DPSS Ultra160
2x IBM 8x CDROM, Corvette, Reply SB-16, Yamaha DB50XG
PCMCIA, Dual Etherstreamer, Cheetah with SideCard, GUP
Digi MC16i, NT4 Server
0
Casolai
7/23/2006 7:39:19 AM
If any of you want the benchmark program I just used, email me and
I'll send it to you, its only 3.3mb and works in win95/98/NT. Send
request to casANTISPAMolai@hotmail.com

don't forget to remove the antispam..   :)

>Here are the benchmarks from SiSoft Sandra 2001te Professional:
>
>Buffered Read              12mb/s
>Sequential Read          12mb/s
>Random Read              5mb/s
>Buffered Write               8mb/s
>Sequential Write           12mb/s
>Random Write               7mb/s
>Average Access Time   7ms (estimated)
>
>These are a considerable improvement over the NT default driver, it
>never got more than 9mb/s before with these hard disks.
>
>Damn fine effort UZ !!
>
9595-1NT: 256mb ram, P90, 3x 9.1gig DPSS Ultra160
2x IBM 8x CDROM, Corvette, Reply SB-16, Yamaha DB50XG
PCMCIA, Dual Etherstreamer, Cheetah with SideCard, GUP
Digi MC16i, NT4 Server

0
Casolai
7/23/2006 7:45:45 AM
Forgot to mention, the spock208 I used was the disk light one, and the
NT4 Server is SP-6/IE6 with all available updates.

>Here are the benchmarks from SiSoft Sandra 2001te Professional:
>
>Buffered Read              12mb/s
>Sequential Read          12mb/s
>Random Read              5mb/s
>Buffered Write               8mb/s
>Sequential Write           12mb/s
>Random Write               7mb/s
>Average Access Time   7ms (estimated)
>
>These are a considerable improvement over the NT default driver, it
>never got more than 9mb/s before with these hard disks.
>
>Damn fine effort UZ !!
>


9595-1NT: 256mb ram, P90, 3x 9.1gig DPSS Ultra160
2x IBM 8x CDROM, Corvette, Reply SB-16, Yamaha DB50XG
PCMCIA, Dual Etherstreamer, Cheetah with SideCard, GUP
Digi MC16i, NT4 Server
0
Casolai
7/23/2006 7:56:52 AM
Ok folks, here are the same benchmarks using the M$ scsi driver:

Buffered Read                  8mb/s
Sequential Read               8mb/s
Random Read                  4mb/s
Buffered Write                  4mb/s
Sequential Write               4mb/s
Random Write                  4mb/s
Average Access Time      7ms (estimated)

Pretty impressive boost ! 200% to sequential write speed !

>>Here are the benchmarks from SiSoft Sandra 2001te Professional:
>>
>>Buffered Read              12mb/s
>>Sequential Read          12mb/s
>>Random Read              5mb/s
>>Buffered Write               8mb/s
>>Sequential Write           12mb/s
>>Random Write               7mb/s
>>Average Access Time   7ms (estimated)


0
Casolai
7/23/2006 8:21:45 AM
> I tried this spock208 on my 9595 and also ran into the missing ASPI
> and CTL3D.DLL. I installed adaptec aspi 4.71.2 and added in the
> missing CTRL3D.DLL, but I also got the same NTVDM CPU error.

Updated with ctl3d32.dll and wnaspi32.dll, both for NT, try again:

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





0
UZnal
7/23/2006 10:52:27 AM
> CTL3D.DLL is also a requirement.

I updated the package, same link, see the other posting.

> I wonder if there could be some issue with two SCSI host adapters.

Missing files obviously. I can't clearly see in the setup INF which files it
exactly needs.

> I am curious about your report...what adapter did you use?

I got the results from Corvette, Rev. 71h, the disk was a 16-bit-wide IBM
DDRS. There were no other devices on the Corvette bus. The cdrom drives are
on the other, Spock w/cache bus. This on Mod. 95 with P60 and 128 MB RAM,
and SP3 for NT4.




0
UZnal
7/23/2006 10:58:48 AM
> >>Buffered Read              12mb/s
> >>Sequential Read          12mb/s

Nice results, thank you, and I am glad you got the promised 12 MB ...;)

> Pretty impressive boost ! 200% to sequential write speed !

To a great part, courtesy of the enabled 32-bit DMA access. Your numbers
confirm that the performance boost on NT is considerably higher than it was
on W9x, but that is the MCA HAL ....!






0
UZnal
7/23/2006 11:12:46 AM
> I updated the package

If it still resists, I have moved the full 4-pack to the Supersite, see my
incoming. Unzip the subroot zip and start with it. You may probably try to
run the updates available from the main support site, I didn't do it. I had
also crashes querying disk params, not every option may work with 3rd party
adapters.






0
UZnal
7/23/2006 11:54:48 AM
One last thing to say, is that the benchmarks I listed were run with a
68pin cable from the corvette to the hard disks, AND a 50pin cable
also on the same corvette to the two cdrom's. I reran the benchmark
with the 50pin cable removed, but the results were exactly the same,
so I suppose either the benchmark program is wrong, or the cdrom's are
not having any effect on the hard disk speed.
>
>To a great part, courtesy of the enabled 32-bit DMA access. Your numbers
>confirm that the performance boost on NT is considerably higher than it was
>on W9x, but that is the MCA HAL ....!
>

9595-1NT: 256mb ram, P90, 3x 9.1gig DPSS Ultra160
2x IBM 8x CDROM, Corvette, Reply SB-16, Yamaha DB50XG
PCMCIA, Dual Etherstreamer, Cheetah with SideCard, GUP
Digi MC16i, NT4 Server
0
Casolai
7/23/2006 12:41:38 PM
http://www.gilanet.com/ohlandl/utils/utilities.html

Down at the bottom.

aspi_471a2 NT4 and W98 ASPI layer
ASPI32 NT4 and W95 ASPI layer
ASPICHK Utility to show installed ASPI layer files and status

UZnal wrote:
>> UZ, I need the app that you are using to measure the SCSI transfer rates.
> 
> Looks like it needs only WINASPI, worked for IDE CD-ROM drives on W98SE:
> 
> www.members.aon.at/mcabase/pub/files/scsib.zip
> 
> 
> 
> 
> 
> 
0
Louis
7/23/2006 1:50:32 PM
For the record, I did not have to use forceaspi to install the 4.71a2 
ASPI layer on my system. I have two corvettes and a Patriot, so the 
package doesn't check for an Adaptec chipset.

Louis Ohland wrote:
> http://www.gilanet.com/ohlandl/utils/utilities.html
> 
> Down at the bottom.
> 
> aspi_471a2 NT4 and W98 ASPI layer
> ASPI32 NT4 and W95 ASPI layer
> ASPICHK Utility to show installed ASPI layer files and status
> 
> UZnal wrote:
>>> UZ, I need the app that you are using to measure the SCSI transfer 
>>> rates.
>>
>> Looks like it needs only WINASPI, worked for IDE CD-ROM drives on W98SE:
>>
>> www.members.aon.at/mcabase/pub/files/scsib.zip
>>
>>
>>
>>
>>
>>
0
Louis
7/23/2006 2:20:20 PM
http://www.gilanet.com/ohlandl/utils/ctl3d.dll
You need this for NT, maybe W9x as well. Version 2.05

Empirical evidence will be presented!

First, the combination of UZ's NT SPOCK and my 85-N was not successful 
where SCSIBENCH is concerned. SCSIBENCH ran without complaint on the M$ 
Spock, but threw four illegal operation errors on SPOCK208 before 
dumping out. Perhaps the POD and L2 cache are lethal to SCSIBENCH and 
208. System itself runs fine with 208, it just detests SCSIBENCH and 208.

9595A, Turbo-T BIOS 10 at 180MHz, 128MB ECC, two corvette, one Patriot.
DDRS-34560W, rev S97B

M$ Spock
Random   :  2,500
Sequent  :  6,400
Same Sect:  3,800

UZ Spock
Random   :  3,100
Sequent  : 11,000
Same Sect:  7,600

For those that use Adaptec's SCSIBENCH, you know it swings back and 
forth a bit. I guesstimated the happy medium [fortuneteller that does 
tricks?] and these are it.

Louis Ohland wrote:
> For the record, I did not have to use forceaspi to install the 4.71a2 
> ASPI layer on my system. I have two corvettes and a Patriot, so the 
> package doesn't check for an Adaptec chipset.
> 
> Louis Ohland wrote:
>> http://www.gilanet.com/ohlandl/utils/utilities.html
>>
>> Down at the bottom.
>>
>> aspi_471a2 NT4 and W98 ASPI layer
>> ASPI32 NT4 and W95 ASPI layer
>> ASPICHK Utility to show installed ASPI layer files and status
>>
>> UZnal wrote:
>>>> UZ, I need the app that you are using to measure the SCSI transfer 
>>>> rates.
>>>
>>> Looks like it needs only WINASPI, worked for IDE CD-ROM drives on W98SE:
>>>
>>> www.members.aon.at/mcabase/pub/files/scsib.zip
>>>
>>>
>>>
>>>
>>>
>>>
0
Louis
7/23/2006 5:01:11 PM
> First, the combination of UZ's NT SPOCK and my 85-N was not successful
> where SCSIBENCH is concerned. SCSIBENCH ran without complaint on the M$
> Spock, but threw four illegal operation errors on SPOCK208 before
> dumping out. Perhaps the POD and L2 cache are lethal to SCSIBENCH and
> 208. System itself runs fine with 208, it just detests SCSIBENCH and 208.

I've had an illegal SCSI command or so, but just ignored it. Spock supports
a subset of the SCSI-2 command set, but provides for issuing the so-called
'other' commands which it passes to the addressed device. This option is a
subject of a future update and is not yet implemented in the driver.

I think, it will be better to separate the NT and W9x zips, I am going to
slightly change the structures before finalizing the package. The setup
procedure remains unchanged, you have to manually delete the previous
driver - either before setup (risky!) or after setup.

NT test reports will go to the readme.

> 9595A, Turbo-T BIOS 10 at 180MHz, 128MB ECC, two corvette, one Patriot.
> DDRS-34560W, rev S97B
>
> M$ Spock
> Random   :  2,500
> Sequent  :  6,400
> Same Sect:  3,800
>
> UZ Spock
> Random   :  3,100
> Sequent  : 11,000
> Same Sect:  7,600

I've got the same disk, the results are similar, though yours are better.
The sequential access rate is amazing, the read cache of the DDRS is well
exploited.

The picture stabilizes - you get a big improvement with modern, wide and
fast disks having a reasonably sized cache. I don't suppose older disks will
show the same preference for the higher transfer rates.

> For those that use Adaptec's SCSIBENCH, you know it swings back and
> forth a bit. I guesstimated the happy medium [fortuneteller that does
> tricks?] and these are it.

Indeed, let it run for a while and observe where it tends to stay longer.




0
UZnal
7/23/2006 6:06:13 PM
Are you the infamous SCSI Cop? Sort of like Fire Marshall Bill, but for 
computers?

I was unable to continue with SCSIBENCH. After I tried to ignore the 
errors, it still closed.

Error ran pretty much the same - "16 bit subsystem" illegal instruction 
in NTVDM CPU, followed by CS:, IP:, OP: segments.

UZnal wrote:
> I've had an illegal SCSI command or so, but just ignored it. Spock supports
> a subset of the SCSI-2 command set, but provides for issuing the so-called
> 'other' commands which it passes to the addressed device. This option is a
> subject of a future update and is not yet implemented in the driver.
0
Louis
7/23/2006 6:23:12 PM
OK, now this is interesting.

EZ-SCSI 4.01 just happens to be already installed on the Turbo-Y from
previous tinkering.

SCSIBench32 saw the drives on both the Corvette and the BT646S while the
Corvette was under M$ control. Now that the Corvette is under UZ
control, SCSIBench32 only sees the drives on the BT646S. ASPI32 shows as
being started in the device panel.

WTF? SPOCK-206 DISK LIGHT is shown in the SCSI adapters panel as a
bonafide SCSI device with all drives cooking.

Adaptec SCSI Explorer also shows both controllers and all drives.

Even more interesting, the Imprimis 94601-15 and HP D2645 on the BT646S
are showing better numbers now that the M$ driver is gone. 1757 vs. 1725
for the Imprimis and 2204 vs. 1629 (sequential, 64k block) for the HP.
Just goes to show how M$ infests everything....

But wait, after I play with the system a while, the drives on the 646S
show 2108 and 1757 respectively. SCSIBench32 is confused.

Oh well, it works. The system seems more perky. I'll play more later.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
7/23/2006 7:05:56 PM
This is not good.

Updated the ASSPI (sic) layer from 4.6 (1021) to 471a2. Now the only
drive SCSIBench32 sees is the HP D2645. But it's fast. 2204 sequential.

Well lookee, get rid of the older wnaspi32.dll from UZ's bottle, and
that version of SCSI bench runs and sees all drives.

"16 bit Windows Subsystem - The NTVDM CPU has encountered an illegal
instruction. CS:0000 IP:0077 OP:fo 37 05 18 02. Choose 'Close' to
terminate the application".

Hell yes, I'll choose 'Ignore'. After all, ignorance is bliss.

More of the same, then it bombs.
CS:0000 IP:007f OP:f0 72 10 a7 00

I notice aspichk shows that wowpost.exe and winaspi.dll are still at
4.61 (1021), but claims that "ASPI is properly installed and fully
operational". Yeah, right.

Do I need to massively downlevel my ASPI layer?

Does anyone have a benchmarker that doesn't need all the Adaptec ducks
to be in a row?

No benchmarks today. Gotta go grocery shopping.

I hate Windows.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
7/23/2006 9:00:00 PM
> "16 bit Windows Subsystem - The NTVDM CPU has encountered an illegal
> instruction. CS:0000 IP:0077 OP:fo 37 05 18 02. Choose 'Close' to
> terminate the application".

Strange indeed, what has 16-bit Windows to do there? The bottles are of the
1995 vintage, somehow corked?

> Does anyone have a benchmarker that doesn't need all the Adaptec ducks
> to be in a row?

That would be fine, the other ones I have run only on true DOS.





0
UZnal
7/23/2006 9:32:50 PM
> Error ran pretty much the same - "16 bit subsystem" illegal instruction
> in NTVDM CPU, followed by CS:, IP:, OP: segments.

No, nothing of the sort. It was just a plain message window saying unable to
send the command, happening as soon as you start SCSI Bench. But then, this
P60 on the complex is the one with the FPU bug.






0
UZnal
7/23/2006 9:33:49 PM
> > Does anyone have a benchmarker that doesn't need all the Adaptec ducks
> > to be in a row?

Tools listed here, see also the page "Hard Disk Drive 2" at the top menu:

http://www.benchmarkhq.ru/english.html?/be_hdd.html

I am going to try ThreadMark (Adaptec), Iometer (Intel, open source) and
HDTach.

HDTach 2.70 supports Windows NT:

http://www.simplisoftware.com/Public/index.php?request=HdTach2.7




0
UZnal
7/23/2006 10:00:09 PM

UZnal wrote:
> 
> > "16 bit Windows Subsystem - The NTVDM CPU has encountered an illegal
> > instruction. CS:0000 IP:0077 OP:fo 37 05 18 02. Choose 'Close' to
> > terminate the application".
> 
> Strange indeed, what has 16-bit Windows to do there? The bottles are of the
> 1995 vintage, somehow corked?


Looking through the EZ-SCSI 4.01 installation on this machine, the
SCSIBench 16-bit Windows utility is the same as the one you have.
SCSIBench32, in the same directory, is the 32-bit NT version. Looks
slightly different, and has a slider to select block size instead of
clickey buttons. It worked with M$ SPOCK, half-worked with SPOCk208, and
only occasionally works and sees only one drive of the 7 total
(including CD-ROMs) on this system since updating ASPI.

I would download the EZ-SCSI 5.0 update, but they insist that you need
original 4.02 install disks and my version is 4.01....

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

UZnal wrote:
> 
> 
> Tools listed here, see also the page "Hard Disk Drive 2" at the top menu:


Trust an old friend:

http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-4BCPER

But alas, EZ-SCSI 5.0 standard (ez50nt98.exe) contains SCSIBench32 4.01
(978) - the same as I already had. And it still sees only the HP drive
on the BT646S. 

Interesting, I just noticed that SCSI Explorer deosn't see the Imprimis
drive on the BT646S. It's there, Windoze sees it in SCSI devices and I
can access it. Strange.


I'll check out the links you provided later...

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
7/23/2006 10:51:09 PM
> SCSIBench32, in the same directory, is the 32-bit NT version.

I don't see it in EZ-SCSI 4.0, there is only one, scsibnch.exe. Setup in
today's 4-pack should be started from the zipped setup, it determines which
version, 16- or 32-bit, to install.




0
UZnal
7/23/2006 10:53:49 PM
> HDTach 2.70 supports Windows NT:
>
> http://www.simplisoftware.com/Public/index.php?request=HdTach2.7

Easy and simple, but tests only sequential read. Below the results for the
wide DDRS on Corvette, disk access time reported for all about 13 ms. Note
the much lower CPU utilization by Spock206, a factor of about 4. The max
improvement over M$ is 60%, confirming SCSI Bench, the average figure is
40%:


M$ Spock:
----------------------
Read speed:
    max 7.0 MB/sec
    min 4.5 MB/sec
    avg 6.9 MB/sec
Read Burst:
    7.0 MB/sec
CPU Utilization:
    46%

Spock206 No Disk Light
----------------------
Read speed:
    max 11.1 MB/sec
    min 6.4 MB/sec
    avg 9.9 MB/sec
Read Burst:
    11.2 MB/sec
CPU Utilization:
    11.6%

Spock206/NT LED Panel:
-----------------------
Read speed:
    max 10.8 MB/sec
    min  6.8 MB/sec
    avg 9.7 MB/sec
Read Burst:
    11.1 MB/sec
CPU Utilization:
    12.4%


Repeat the test a few times, the figures can be slightly different.







0
UZnal
7/23/2006 11:02:02 PM

Jim Shorney wrote:
> 
> And it still sees only the HP drive
> on the BT646S.


After yet another restart, the SCSIBench32 now sees every drive on the
BT646S. But still, none of the drives on the Corvette.

pthah!

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

UZnal wrote:
> 
> > SCSIBench32, in the same directory, is the 32-bit NT version.
> 
> I don't see it in EZ-SCSI 4.0, there is only one, scsibnch.exe. Setup in
> today's 4-pack should be started from the zipped setup, it determines which
> version, 16- or 32-bit, to install.

This was installed on the NT box some time ago from a bonafide set of
EZ-SCSI install disks. I'm thinking that SCSIBench32 is for Win9x/NT,
and probably only gets installed in a 32-bit environment.

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

> Error ran pretty much the same - "16 bit subsystem" illegal instruction
> in NTVDM CPU, followed by CS:, IP:, OP: segments.

I'm going to postulate on the cause of this error...

First, the Adaptec program seems to be a 16-bit Windows program, and
therefore executes in the Win16/NTVDM/WOW (Win16 on Win32) subsystem.

On the 9585 in question, I have a 32-bit ASPI layer installed, courtesy of
ForceASPI.
On a 9595-0Px, I have no ASPI layer installed (yet).
Both machines are running NT 4.0 SP6a.

With the 9585, I get the NTVDM error already mentioned, and the program soon
crashes.
On the 9595, I get an ASPI error OR the program just quits when I try to run
the benchmark.

With the somewhat rudimentary understanding I have of the issues at hand,
I'd tend to think that this is a thunking issue. I don't think a Win16
program can call a Win32 DLL directly without getting into some kind of
trouble.

I could be totally wrong here...but it seems logical enough so far.

In the meantime, I found another disk benchmark tool that is a native Win32
app and will discuss results soon if I can't get the Adaptec tool running in
any way.

William


0
William
7/24/2006 1:47:26 AM

UZnal wrote:
> 
> > HDTach 2.70 supports Windows NT:
> >
> > http://www.simplisoftware.com/Public/index.php?request=HdTach2.7
> 
> Easy and simple, but tests only sequential read. 


At last, something that works. My M$ Spock numbers are from SCSIBench32
4.01, I didn't feel like going back to M$ Spock and doing it all over
after banging my head all afternoon. I know, I know, don't even say
it....

IBM 0661-467
M$ Spock (SCSIBench32)
----------------------
Read speed:
    1.21 MB/sec

Spock206 Disk Light (HD Tach)
----------------------
Read speed:
    max 1.4 MB/sec
    min 1.3 MB/sec
    avg 1.0 MB/sec
Read Burst:
    3.3 MB/sec
CPU Utilization:
    1.0%
 
IBM 0661-371
M$ Spock (SCSIBench32)
----------------------
Read speed:
    1.24 MB/sec

Spock206 Disk Light (HD Tach)
----------------------
Read speed:
    max 1.7 MB/sec
    min 1.6 MB/sec
    avg 2.0 MB/sec (huh?)
Read Burst:
    2.1 MB/sec
CPU Utilization:
    1.1%

IBM DPES-31080
M$ Spock (SCSIBench32)
----------------------
Read speed:
    1.72 MB/sec

Spock206 Disk Light (HD Tach)
----------------------
Read speed:
    max 4.4 MB/sec
    min 2.7 MB/sec
    avg 3.8 MB/sec
Read Burst:
    6.8 MB/sec
CPU Utilization:
    2.4%

For comparison, here are the numbers on the drives residing on the
BT646S before and after.

Imprimis 94601-15
Living with M$ Spock (SCSIBench32)
----------------------
Read speed:
    1.72 MB/sec

Spock206 Disk Light (HD Tach)
----------------------
Read speed:
    max 2.2 MB/sec
    min 1.6 MB/sec
    avg 2.0 MB/sec
Read Burst:
    2.9 MB/sec
CPU Utilization:
    8.0%

IBM 0661-467
M$ Spock (SCSIBench32)
----------------------
Read speed:
    1.2 MB/sec

Living with Spock206 Disk Light (HD Tach)
----------------------
Read speed:
    max 1.4 MB/sec
    min 1.3 MB/sec
    avg 1.0 MB/sec
Read Burst:
    3.3 MB/sec
CPU Utilization:
    1.0%

HP D2645
Living with M$ Spock (SCSIBench32)
----------------------
Read speed:
    1.63 MB/sec

Living with Spock206 Disk Light (HD Tach)
----------------------
Read speed:
    max 2.3 MB/sec
    min 2.2 MB/sec
    avg 2.0 MB/sec
Read Burst:
    4.9 MB/sec
CPU Utilization:
    9.5%

So getting bad M$ drivers out of the way can improve the performance of
other devices as well.

System details:
9595-0PT Turbo-Y complex @200 MHz
96MB RAM
NTws 4.0 1381 SP6a
ASPI Layer 4.71.2 (was 4.6 (1021) )
IBM SCSI-2 F/W (Corvette), wait states disabled, 100ns streaming
enabled, 
combined bus mode
BusLogic BT646S with streaming and sync negotiation enabled
Cornerstone ImageAccel, SoundPiper 16, USR Courier 2400, 512K SVGA/A, HP
Scanjet
(parallel) adapter, IBM Etherstreamer MC32
Hard disks as listed above, all SCSI-2 narrow except the Imprimis SCSI-1
narrow, according to Adaptec SCSI Explorer.

Man, this could be a real screamer if I stuck some Fast/Wide drives in
it....

If enough people whine, I may go back and run HD Tach numbers with M$
Spock. But not tonight.

THANK YOU, Uz!

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
7/24/2006 2:11:16 AM
(resent due to a copy-and-paste error)

UZnal wrote:
> 
> > HDTach 2.70 supports Windows NT:
> >
> > http://www.simplisoftware.com/Public/index.php?request=HdTach2.7
> 
> Easy and simple, but tests only sequential read. 


At last, something that works. My M$ Spock numbers are from SCSIBench32
4.01, I didn't feel like going back to M$ Spock and doing it all over
after banging my head all afternoon. I know, I know, don't even say
it....

IBM 0661-467
M$ Spock (SCSIBench32)
----------------------
Read speed:
    1.21 MB/sec

Spock206 Disk Light (HD Tach)
----------------------
Read speed:
    max 1.4 MB/sec
    min 1.3 MB/sec
    avg 1.0 MB/sec
Read Burst:
    3.3 MB/sec
CPU Utilization:
    1.0%
 
IBM 0661-371
M$ Spock (SCSIBench32)
----------------------
Read speed:
    1.24 MB/sec

Spock206 Disk Light (HD Tach)
----------------------
Read speed:
    max 1.7 MB/sec
    min 1.6 MB/sec
    avg 2.0 MB/sec (huh?)
Read Burst:
    2.1 MB/sec
CPU Utilization:
    1.1%

IBM DPES-31080
M$ Spock (SCSIBench32)
----------------------
Read speed:
    1.72 MB/sec

Spock206 Disk Light (HD Tach)
----------------------
Read speed:
    max 4.4 MB/sec
    min 2.7 MB/sec
    avg 3.8 MB/sec
Read Burst:
    6.8 MB/sec
CPU Utilization:
    2.4%

For comparison, here are the numbers on the drives residing on the
BT646S before and after.

Imprimis 94601-15
Living with M$ Spock (SCSIBench32)
----------------------
Read speed:
    1.72 MB/sec

Spock206 Disk Light (HD Tach)
----------------------
Read speed:
    max 2.2 MB/sec
    min 1.6 MB/sec
    avg 2.0 MB/sec
Read Burst:
    2.9 MB/sec
CPU Utilization:
    8.0%

HP D2645
Living with M$ Spock (SCSIBench32)
----------------------
Read speed:
    1.63 MB/sec

Living with Spock206 Disk Light (HD Tach)
----------------------
Read speed:
    max 2.3 MB/sec
    min 2.2 MB/sec
    avg 2.0 MB/sec
Read Burst:
    4.9 MB/sec
CPU Utilization:
    9.5%

So getting bad M$ drivers out of the way can improve the performance of
other devices as well.

System details:
9595-0PT Turbo-Y complex @200 MHz
96MB RAM
NTws 4.0 1381 SP6a
ASPI Layer 4.71.2 (was 4.6 (1021) )
IBM SCSI-2 F/W (Corvette), wait states disabled, 100ns streaming
enabled, 
combined bus mode
BusLogic BT646S with streaming and sync negotiation enabled
Cornerstone ImageAccel, SoundPiper 16, USR Courier 2400, 512K SVGA/A, HP
Scanjet
(parallel) adapter, IBM Etherstreamer MC32
Hard disks as listed above, all SCSI-2 narrow except the Imprimis SCSI-1
narrow, according to Adaptec SCSI Explorer.

Man, this could be a real screamer if I stuck some Fast/Wide drives in
it....

If enough people whine, I may go back and run HD Tach numbers with M$
Spock. But not tonight.

THANK YOU, Uz!

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
7/24/2006 2:18:03 AM
> IBM 0661-371
> M$ Spock (SCSIBench32)
> ----------------------
> Read speed:
>     1.24 MB/sec
>
> Spock206 Disk Light (HD Tach)
> ----------------------
> Read speed:
>     max 1.7 MB/sec

Still about a 40% increase. However, the older disks perform better with
smaller block transfers, like 8 KB, possibly due to the smaller cache.
HDTach does not allow to play with the block size, but SCSI Bench did it.


> IBM DPES-31080
> M$ Spock (SCSIBench32)
> ----------------------
> Read speed:
>     1.72 MB/sec
>
> Spock206 Disk Light (HD Tach)
> ----------------------
> Read speed:
>     max 4.4 MB/sec

This looks much better, it hits the 250% mark...?

> 9595-0PT Turbo-Y complex @200 MHz

You can see that in the very low CPU utilization.

> If enough people whine, I may go back and run HD Tach numbers with M$
> Spock. But not tonight.

No, not really needed. I for myself look at the change rate and see a
commonly confirming average pattern of 40% to 60% improvement. This will be
of course less felt with slower disks, but it is dramatic with fast/wide
disks.

> Man, this could be a real screamer if I stuck some Fast/Wide drives in
> it....

One reason is the delay or execution stall time inserted in the
communication with the adapter. Spock206 uses a delay of 2 microsecs before
querying the adapter registers for busy, this becomes 1 microsec on waiting
for interrupt ACK from the adapter. These delays are inside a loop, so the
above numbers are the minimum times.

With fast disks, the adapter will respond quickly and that will increase the
throughput. With slower disk, the driver will loop and wait for a while
until it gets the ACK.

> THANK YOU, Uz!

Let me also experiment with the half wait-on-busy delay, with 1 microsec. I
think, fast/wide disks will like it.

Also, I have this feeling that NT ticks more exactly than W9x, I can see
that in the LED display, I had more time on W9x to read the display, but it
has become quicker on NT. Speak about clock/tick granularity which is finer
on NT.




0
UZnal
7/24/2006 11:20:11 AM

UZnal wrote:
> 
> Still about a 40% increase. However, the older disks perform better with
> smaller block transfers, like 8 KB, possibly due to the smaller cache.
> HDTach does not allow to play with the block size, but SCSI Bench did it.


It still baffles me why SCSIBench32 stopped acknowledging the drives on
the Corvette with your driver. Any ideas on this?


> > 9595-0PT Turbo-Y complex @200 MHz
> 
> You can see that in the very low CPU utilization.


Yes, I like those numbers. Better than the BusLogic adapter.

 
> With fast disks, the adapter will respond quickly and that will increase the
> throughput. With slower disk, the driver will loop and wait for a while
> until it gets the ACK.


I'm eyeing that lot of 19 DCHS on ePay...

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

Power
Requirements 	+5 VDC � 5% *2
Dissipation (typical) 	
      Idle average 	1.068 Amps / 1.085 Amps
      Seek average 	1.094 Amps / 0.010 Amps

7.4 Acoustic Levels
Upper Limit Sound Power Requirements (Bels) for 25mm Models
Octave Band Center Frequency (Hz)     A-weighted
           125 250 500 1K  2K  4K  8K  Bel
Idle      4.5 3.5 3.3 3.5 4.5 4.5 4.7 5.0
Operating 4.5 4.0 3.6 4.5 4.8 5.0 4.7 5.4

Jim Shorney wrote:
> I'm eyeing that lot of 19 DCHS on ePay...
0
Louis
7/25/2006 1:47:17 AM
 >http://www.hitachigst.com/hdd/support/dchs/dchstek.htm<

Louis Ohland wrote:
> Hmm, 5.47 watts.
> 
> Power
> Requirements     +5 VDC � 5% *2
> Dissipation (typical)    
>      Idle average     1.068 Amps / 1.085 Amps
>      Seek average     1.094 Amps / 0.010 Amps
> 
> 7.4 Acoustic Levels
> Upper Limit Sound Power Requirements (Bels) for 25mm Models
> Octave Band Center Frequency (Hz)     A-weighted
>           125 250 500 1K  2K  4K  8K  Bel
> Idle      4.5 3.5 3.3 3.5 4.5 4.5 4.7 5.0
> Operating 4.5 4.0 3.6 4.5 4.8 5.0 4.7 5.4
> 
> Jim Shorney wrote:
>> I'm eyeing that lot of 19 DCHS on ePay...
0
Louis
7/25/2006 1:47:57 AM

Louis Ohland wrote:
> 
>  >http://www.hitachigst.com/hdd/support/dchs/dchstek.htm<

Yep, already been there. The Turbo-Y is screaming for some faster drives
now that we have a real driver. Although if I actually took inventory of
what I already have collected, I could probably turn up something....

Oh well, a man can't have too many obsolete hard drives to keep these
machines running.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
7/25/2006 2:27:12 AM
> It still baffles me why SCSIBench32 stopped acknowledging the drives on
> the Corvette with your driver. Any ideas on this?

Puzzling, since SCSI Bench of 4.0 was able to see all drives on both the
Corvette and Spock busses. I suppose, SCSIBench32 makes a different type of
inquiry and from another level. This needs to be investigated, but I don't
have SCSIBench32.

A remote possibility could be that the Adaptec's package registrates with
the driver it finds at installation time ...?




0
UZnal
7/25/2006 10:22:33 AM
> Puzzling, since SCSI Bench of 4.0

Has anyone tried to update EZ SCSI 4.0 to 5.01, the main support site
mentions updates from 4.0x, and not explicitly 4.0 ? The original disks are
DISK1 ... DISK4.

The update is 5 MB.



0
UZnal
7/25/2006 10:37:38 AM

UZnal wrote:
> 
> > It still baffles me why SCSIBench32 stopped acknowledging the drives on
> > the Corvette with your driver. Any ideas on this?
> 
> Puzzling, since SCSI Bench of 4.0 was able to see all drives on both the
> Corvette and Spock busses. I suppose, SCSIBench32 makes a different type of
> inquiry and from another level. This needs to be investigated, but I don't
> have SCSIBench32.



Look here:

http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-4BCPER

Download ez50nt98.exe, that should give you the basic EZ-SCSI 5.0
package with SCSIBench32 4.01. Presumably, EZ-SCSI installed to a 16 bit
Windoze box wouldn't install SCSIBench32. Looks like I've had it just
about forever in EZ-SCSI 4.xx, dunno where you guys have been...

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
7/25/2006 11:05:58 AM
> http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-4BCPER


The IBM FTP lists several EZ SCSI packages for different machines, with a
number of NT miniport dirvers.

I tried EZ-SCSI 4.02L (see below), it includes SCSIBench32. First, I
uninstalled my well working copy of EZ-SCSI 4.0, and then installed 4.02L.
Setup and later SCSI Explorer correctly showed the all SCSI devices.
SCSIBench32 failed, as you all said.

SCSIBench from 4.0 joined in and immediately produced that infamous NTVDM
illegal instruction error. You can't mix up the DLLs from different
versions.

Also, EZ-SCSI installs the ASPI32.SYS driver and removes it when
deinstalled.

I decided to go back to 4.0 and uninstalled 4.02L. But then 4.0 did not
work, the reason were the ...\SYSTEM\WINASPI.DLL and
....\SYSTEM32\WNASPI32.DLL left over from the previous 4.02L version. The
uninstaller has not removed them, you must remove them manually.

SCSIBench though shows correctly all devices, cannot benchmark anymore. The
reason is a leftover, this time ...\SYSTEM\WOWPOST.EXE, you have to remove
it resp. overwrite it with the common version.

Be careful with the above three files when you downgrade your installation,
do not trust the uninstaller. I wouldn't have expected such a mess from
Adaptec.




PC_SERVERS: .....  /pc/pccbbs/pc_servers

EZ-SCSI 4.02L
--------------

24l8060.exe    1317568 09/26/2005 DDSE-3UES6W EZ SCSI utility diskette 1 of
                                  3 version 4.02L
24l8060.txt      64113 09/26/2005 DDSE-3UES6W README file for the EZ SCSI
                                  utility diskette 1 of 3 version 4.02L
24l8061.exe    1412763 09/26/2005 DDSE-3UES6W EZ SCSI utility diskette 2 of
                                  3 version 4.02L
24l8061.txt      64111 09/26/2005 DDSE-3UES6W README file for the EZ SCSI
                                  utility diskette 2 of 3 version 4.02L
24l8062.exe    1189851 09/26/2005 DDSE-3UES6W EZ SCSI utility diskette 3 of
                                  3 version 4.02L
24l8062.txt      64110 09/26/2005 DDSE-3UES6W README file for the EZ SCSI
                                  utility diskette 3 of 3 version 4.02L

EZ-SCSI Netfinity 3500
----------------------

10l9290.exe    1323634 10/03/2005 DDSE-3RDJLP Netfinity 3500 EZ SCSI Utility
                                  Diskette 1 of 3
10l9290.txt      64114 10/03/2005 DDSE-3RDJLP Readme for Netfinity 3500 EZ
                                  SCSI Utility Diskette 1 of 3
10l9291.exe    1412275 10/03/2005 DDSE-3RDJLP Netfinity 3500 EZ SCSI Utility
                                  Diskette 2 of 3
10l9291.txt      64112 10/03/2005 DDSE-3RDJLP Readme for Netfinity 3500 EZ
                                  SCSI Utility Diskette 2 of 3
10l9292.exe    1181489 10/03/2005 DDSE-3RDJLP Netfinity 3500 EZ SCSI Utility
                                  Diskette 3 of 3
10l9292.txt      64111 10/03/2005 DDSE-3RDJLP Readme for Netfinity 3500 EZ
                                  SCSI Utility Diskette 3 of 3













0
UZnal
7/25/2006 9:10:35 PM

UZnal wrote:
> 
> > http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-4BCPER
> 
> The IBM FTP lists several EZ SCSI packages for different machines, with a
> number of NT miniport dirvers.

The package I used installed happily on the PC300xl (Win98se) and on the
Turbo-Y alongside version 4.01 (did not overwrite). V4.01 obligingly
continued to not work, as before. Apparently, EZ-SCSI will install the
utilities regardless of whether you need one of the included miniports
(or even it you have the listed machine).

I'm starting to think that SPOCK208 is simply alienware to SCSIBench32
and/or the Adaptec ASPI layer.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
0
Jim
7/26/2006 2:30:19 AM
> I'm starting to think that SPOCK208 is simply alienware to SCSIBench32
> and/or the Adaptec ASPI layer.

Not quite, so far only SCSIBench32 fails. SCSI Bench can recover and
continue but SCSIBench32 does not. The program makes inquiries (additional
device info) through the ASPI32 layer which are however not vital to the
proper operation of the driver.

With SCSI Bench, you can see which SCSI command has failed. I'll have to
look at the event log to see if errors have been logged.

Also, it won't make a much difference for a 16-bit or 32-bit SCSI Bench,
because both the ASPI layer and the driver are 32-bit codes. Note also that
calls are routed through the ASPI layer, hence Adaptec's warning that the
true performance should be higher than the reported numbers. The ASPI layer
runs as an NT service, and I was hardly excited as I was reading Adaptec's
AHA154x sample code.







0
UZnal
7/26/2006 10:53:21 AM
Re techref of Spock with cache (8EFE), SCSIOP_XXX below are the NT operation
codes. Corvette has certainly a richer command set.

Once Spock206 supports all of the commands below (work in progress), more
things will become possible.

Commands processed by the adapter:

Supported SCSI Commands: (Start SCB)
------------------------------------
Copy -- SCSIOP_COPY
Format Unit -- SCSIOP_FORMAT_UNIT
Inquiry -- SCSIOP_INQUIRY
Read -- SCSIOP_READ
Read Capacity -- SCSIOP_READ_CAPACITY
Read Extended -- ***  SCSIOP_READ_LONG ???
Reassign Blocks -- SCSIOP_REASSIGN_BLOCKS
Request Sense -- SCSIOP_REQUEST_SENSE
Verify -- SCSIOP_VERIFY
Write -- SCSIOP_WRITE
Write and Verify -- SCSIOP_WRITE_VERIFY
Write Extended -- ***

Ed: Read Capacity returns the IML corrected total read space. A non-IBM
adapter may count the IML occupied disk space to the total read space.

Commands NOT processed by the adapter:

The "other" commands are the commands the adapter indirectly supports,
through a special long SCB (Subsystem Control Block) which is relayed to the
addressed device. Cache contents are cleared of any data relating to this
device when a long SCB for this device is received. To send these commands,
the default SCB is extended with a 6-, 10- or 12-byte field containing the
command code, hence the name long SCB. Long SCBs are particularly suited for
SCSI tape drive control.

Note that the commands below are not processed by the adapter, they are
processed only by the addressed device. Also no eventual cache support for
these commands:

Other SCSI Commands: (Start Long SCB)
-------------------------------------
Mode Select -- SCSIOP_MODE_SELECT
Mode Sense -- SCSIOP_MODE_SENSE
Prevent/Allow Medium Removal -- SCSIOP_MEDIUM_REMOVAL
Read Buffer -- SCSIOP_READ_DATA_BUFF
Read Defect Data -- ****
Receive Diagnostic Results
Release -- SCSIOP_RELEASE_UNIT
Reserve -- SCSIOP_RESERVE_UNIT
Rezero Unit -- SCSIOP_REZERO_UNIT
Seek -- SCSIOP_SEEK
Send Diagnostic -- SCSIOP_SEND_DIAGNOSTIC
Start/Stop Unit -- SCSIOP_START_STOP_UNIT
Test Unit Ready -- SCSIOP_TEST_UNIT_READY
Write Buffer -- SCSIOP_WRITE_DATA_BUFF


SCSI Messages:

Supported SCSI Messages:
-----------------------
Abort
Bus-Device Reset
Command Complete
Disconnect
Identify
Initiator-Detected Error
Linked Command Complete
Linked Command Complete with Flag
Message Parity Error
Message Reject
No Operation
Restore Pointers
Save Data-Pointer


Supported SCSI Status Messages:
------------------------------
Busy
Check Condition
Condition Met/Good
Good
Immediate Good
Intermediate/Condition Met/Good
Reservation Conflict

Note: SCSI Extended Message Synchronous Data Transfer Request is also
supported.



0
UZnal
7/27/2006 11:27:05 AM
Hi!

> Once Spock206 supports all of the commands below (work in
> progress), more things will become possible.

(From an interested and curious point of view...) What sort of things?

Does the M$ supplied Spock miniport supply these functions? (Is it
possible to tell?)

I have noticed something interesting. On most of my NT-based PS/2s, the
event log would report "stop sign" errors with the M$ supplied "Spock"
miniport. Since installing your updated driver, I can't recall having
seen a one of these in the event log. (Most are reports of "controller
error".)

William

0
wm_walsh
7/27/2006 4:43:09 PM
> > Once Spock206 supports all of the commands below (work in
> > progress), more things will become possible.
>
> (From an interested and curious point of view...) What sort of things?

NT has a list of 65 or so SCSI opcodes, including audio commands, removable
media, tape drives etc. I expect more SCSI devices to be natively supported
then, but testing and verifying will be quite difficult. See the list at the
end of this posting.

> Does the M$ supplied Spock miniport supply these functions? (Is it
> possible to tell?)

Without the code of the retail driver, a SCSI check suite might tell what is
in there. I hope there is such a suite, all this must be somehow tested.

BTW, what was the issue with multiple LUNs on Spock/Corvette, there were
discussions in the past? As it is now, and that is going to change, only LUN
= 0 is supported. The table in the techref can be misleading on first
reading.

"While configuring the SCSI bus, POST issues the Inquiry command to all 56
possible combinations of PUN/LUN until 15 logical devices are assigned.
Therefore all devices must respond to each possible LUN for its SCSI ID."
(pp. 7)

Device 16 is the adapter itself:

 Num Devices Supported: 7
   Num LUNs per Device: 8
   Num Logical Devices: 16

Devices X LUNs = 7 x 8 = 56 but only 15 will be assigned by Spock.

Though Corvette is more generous, again only 15 + 1 make it to the logical
device list:

 Num Devices Supported: 30
   Num LUNs per Device: 32
   Num Logical Devices: 16

But then, what is the use of 32 LUNs and 30 devices?

> I have noticed something interesting. On most of my NT-based PS/2s, the
> event log would report "stop sign" errors with the M$ supplied "Spock"
> miniport. Since installing your updated driver, I can't recall having
> seen a one of these in the event log. (Most are reports of "controller
> error".)

The retail Spock works probably with a low error threshold or times out and
logs errors. Spock206 has no defined error threshold and very generous
timings, it will wait for quite long to receive an ACK from the adapter.

SCSI.H

// SCSI CDB operation codes

SCSIOP_TEST_UNIT_READY
SCSIOP_REZERO_UNIT
SCSIOP_REWIND
SCSIOP_REQUEST_BLOCK_ADDR
SCSIOP_REQUEST_SENSE
SCSIOP_FORMAT_UNIT
SCSIOP_READ_BLOCK_LIMITS
SCSIOP_REASSIGN_BLOCKS
SCSIOP_READ6
SCSIOP_RECEIVE
SCSIOP_WRITE6
SCSIOP_PRINT
SCSIOP_SEND
SCSIOP_SEEK6
SCSIOP_TRACK_SELECT
SCSIOP_SLEW_PRINT
SCSIOP_SEEK_BLOCK
SCSIOP_PARTITION
SCSIOP_READ_REVERSE
SCSIOP_WRITE_FILEMARKS
SCSIOP_FLUSH_BUFFER
SCSIOP_SPACE
SCSIOP_INQUIRY
SCSIOP_VERIFY6
SCSIOP_RECOVER_BUF_DATA
SCSIOP_MODE_SELECT
SCSIOP_RESERVE_UNIT
SCSIOP_RELEASE_UNIT
SCSIOP_COPY
SCSIOP_ERASE
SCSIOP_MODE_SENSE
SCSIOP_START_STOP_UNIT
SCSIOP_STOP_PRINT
SCSIOP_LOAD_UNLOAD
SCSIOP_RECEIVE_DIAGNOSTIC
SCSIOP_SEND_DIAGNOSTIC
SCSIOP_MEDIUM_REMOVAL
SCSIOP_READ_CAPACITY
SCSIOP_READ
SCSIOP_WRITE
SCSIOP_SEEK
SCSIOP_LOCATE
SCSIOP_WRITE_VERIFY
SCSIOP_VERIFY
SCSIOP_SEARCH_DATA_HIGH
SCSIOP_SEARCH_DATA_EQUAL
SCSIOP_SEARCH_DATA_LOW
SCSIOP_SET_LIMITS
SCSIOP_READ_POSITION
SCSIOP_COMPARE
SCSIOP_COPY_COMPARE
SCSIOP_WRITE_DATA_BUFF
SCSIOP_READ_DATA_BUFF
SCSIOP_READ_LONG
SCSIOP_CHANGE_DEFINITION
SCSIOP_READ_SUB_CHANNEL
SCSIOP_READ_TOC
SCSIOP_READ_HEADER
SCSIOP_PLAY_AUDIO_10
SCSIOP_PLAY_AUDIO_MSF
SCSIOP_PLAY_TRACK_INDEX
SCSIOP_PLAY_TRACK_RELATIVE
SCSIOP_PAUSE_RESUME
SCSIOP_LOG_SELECT
SCSIOP_LOG_SENSE
SCSIOP_PLAY_AUDIO
SCSIOP_READ_CDDA

// Denon CD ROM operation codes

SCSIOP_DENON_EJECT_DISC
SCSIOP_DENON_STOP_AUDIO
SCSIOP_DENON_PLAY_AUDIO
SCSIOP_DENON_READ_TOC
SCSIOP_DENON_READ_SUBCODE

// SCSI Bus Messages

SCSIMESS_ABORT
SCSIMESS_ABORT_WITH_TAG
SCSIMESS_BUS_DEVICE_RESET
SCSIMESS_CLEAR_QUEUE
SCSIMESS_COMMAND_COMPLETE
SCSIMESS_DISCONNECT
SCSIMESS_EXTENDED_MESSAGE
SCSIMESS_IDENTIFY
SCSIMESS_IDENTIFY_WITH_DISCON
SCSIMESS_IGNORE_WIDE_RESIDUE
SCSIMESS_INITIATE_RECOVERY
SCSIMESS_INIT_DETECTED_ERROR
SCSIMESS_LINK_CMD_COMP
SCSIMESS_LINK_CMD_COMP_W_FLAG
SCSIMESS_MESS_PARITY_ERROR
SCSIMESS_MESSAGE_REJECT
SCSIMESS_NO_OPERATION
SCSIMESS_HEAD_OF_QUEUE_TAG
SCSIMESS_ORDERED_QUEUE_TAG
SCSIMESS_SIMPLE_QUEUE_TAG
SCSIMESS_RELEASE_RECOVERY
SCSIMESS_RESTORE_POINTERS
SCSIMESS_SAVE_DATA_POINTER
SCSIMESS_TERMINATE_IO_PROCESS

// SCSI Extended Message operation codes

SCSIMESS_MODIFY_DATA_POINTER
SCSIMESS_SYNCHRONOUS_DATA_REQ
SCSIMESS_WIDE_DATA_REQUEST

// SCSI Extended Message Lengths

SCSIMESS_MODIFY_DATA_LENGTH
SCSIMESS_SYNCH_DATA_LENGTH
SCSIMESS_WIDE_DATA_LENGTH


// Sense codes

SCSI_SENSE_NO_SENSE
SCSI_SENSE_RECOVERED_ERROR
SCSI_SENSE_NOT_READY
SCSI_SENSE_MEDIUM_ERROR
SCSI_SENSE_HARDWARE_ERROR
SCSI_SENSE_ILLEGAL_REQUEST
SCSI_SENSE_UNIT_ATTENTION
SCSI_SENSE_DATA_PROTECT
SCSI_SENSE_BLANK_CHECK
SCSI_SENSE_UNIQUE
SCSI_SENSE_COPY_ABORTED
SCSI_SENSE_ABORTED_COMMAND
SCSI_SENSE_EQUAL
SCSI_SENSE_VOL_OVERFLOW
SCSI_SENSE_MISCOMPARE
SCSI_SENSE_RESERVED

// Additional tape bit

SCSI_ILLEGAL_LENGTH
SCSI_EOM
SCSI_FILE_MARK


// Additional Sense codes

SCSI_ADSENSE_NO_SENSE
SCSI_ADSENSE_MAN_INTERV
SCSI_ADSENSE_LUN_NOT_READY
SCSI_ADSENSE_ILLEGAL_COMMAND
SCSI_ADSENSE_ILLEGAL_BLOCK
SCSI_ADSENSE_INVALID_LUN
SCSI_ADSENSE_SELECT_TIMEOUT
SCSI_ADSENSE_MUSIC_AREA
SCSI_ADSENSE_DATA_AREA
SCSI_ADSENSE_VOLUME_OVERFLOW

SCSI_ADSENSE_NO_MEDIA_IN_DEVICE
SCSI_ADWRITE_PROTECT
SCSI_ADSENSE_MEDIUM_CHANGED
SCSI_ADSENSE_BUS_RESET
SCSI_ADSENSE_TRACK_ERROR
SCSI_ADSENSE_SEEK_ERROR
SCSI_ADSENSE_REC_DATA_NOECC
SCSI_ADSENSE_REC_DATA_ECC
SCSI_ADSENSE_ILLEGAL_MODE
SCSI_ADSENSE_BAD_CDB
SCSI_ADSENSE_BAD_PARM_LIST
SCSI_ADSENSE_CANNOT_READ_MEDIUM

// Additional sense code qualifier

CSI_SENSEQ_FORMAT_IN_PROGRESS
CSI_SENSEQ_INIT_COMMAND_REQUIRED
CSI_SENSEQ_MANUAL_INTERVENTION_REQUIRED
CSI_SENSEQ_BECOMING_READY
CSI_SENSEQ_INCOMP_FORMAT





0
UZnal
7/27/2006 7:27:31 PM
Hi!

> BTW, what was the issue with multiple LUNs on Spock/Corvette,
> there were discussions in the past? As it is now, and that is going to
> change, only LUN = 0 is supported. The table in the techref can be
> misleading on first reading.

Ah...that. Basically, the problem went like this when I tried this kind of
setup on a PC Server 500. Attached to the Spock (cached, 1993 busmaster
microcode, triple oscillator) were a 2X CD-ROM drive, a DDS-2 tape backup
and a six drive Pioneer DRM-624 CD changer.

The Pioneer changer makes use of multiple LUNs. Each of its drives showed up
properly in system programs--something like 0,1 0,2 0,3 0,4 and so on.

But when I got into NT, I got a big surprise! Depending upon how IDs were
set, either the tape drive or the internal CD would get "pushed off" the
SCSI chain. NT's SCSI control panel also showed each drive in the Pioneer
changer to be using a separate SCSI ID.

I still have the changer, and enough SCSI cables should be here soon to test
this on a wide variety of adapters...planar SCSI and otherwise. The changer
itself got a bit wet in the flood, but I think it will work OK anyway.

> But then, what is the use of 32 LUNs and 30 devices?

"Nobody ever needs more than 640K RAM"?

In all seriousness, Tim Clarke found a very large Pioneer SCSI CD changer. I
suppose it could make use of such a configuration, if it were to be allowed.

> The retail Spock works probably with a low error threshold or times
> out and logs errors. Spock206 has no defined error threshold and very
> generous timings, it will wait for quite long to receive an ACK from the
> adapter.

I think I will make another attempt at using the late short uncached SCSI/A
in a "Server 95" planar (dual serial/LPT) once again. With the M$ driver, it
threw a ton of errors and acted very strangely. I never did figure out
why...some people here on the group suggested it was a speed issue...that
the card was not meant to function in such a fast system.

Given that it seems to be the fastest so far of the narrow IBM MCA SCSI
adapters, I have my doubts about that and think the M$ driver did not
understand the hardware and how to use it properly.

I think this is fast turning into the longest running thread ever on CSIPH.
It's run for well over two months now! :-)

William


0
William
7/27/2006 8:08:00 PM
The driver detected a controller error on \Device\ScsiPort2.

This happens once during boot. There is no specific error reported.

wm_walsh@hotmail.com wrote:
> Hi!
> 
>> Once Spock206 supports all of the commands below (work in
>> progress), more things will become possible.
> 
> (From an interested and curious point of view...) What sort of things?
> 
> Does the M$ supplied Spock miniport supply these functions? (Is it
> possible to tell?)
> 
> I have noticed something interesting. On most of my NT-based PS/2s, the
> event log would report "stop sign" errors with the M$ supplied "Spock"
> miniport. Since installing your updated driver, I can't recall having
> seen a one of these in the event log. (Most are reports of "controller
> error".)
> 
> William
> 
0
Louis
7/27/2006 9:12:44 PM
> The driver detected a controller error on \Device\ScsiPort2.
>
> This happens once during boot. There is no specific error reported.

And it happens only on the Corvette bus, M$ Spock logs this error too. Here
I get it on the \Device\ScsiPort0 bus. Cached Spock is on \Device\ScsiPort1.

It is either a SOFTWARE_SEQUENCING_ERROR as reported by the adapter or a
specific Corvette error status not covered by the Spock techref. I'll
separate the error codes and soon we will know it. The error is logged from
the interrupt handler, and it occurs only once. I have too many wild guesses
for this to list them here.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q182335

Let us look at the error log entry format, it might be useful to you. Click
on an entry in the event log and view hex data as WORDS:

0000: 0010000f 00680001 00000000 c004000b
0010: 0001000e 00000000 00000000 00000000
0020: 00000000 00000000 00000000 00000007
0030: 00000000 00000006

At offset 0000 is the internal logger data, c004000b is the error type
(controller error here).

At offset 0010 we have above 0001000e. Spock miniport error codes are in the
upper two bytes, this is 0001 in this case (forget 000e, it is something
else).

At the end of the offset 0020 line we see 00000007, this is the SCSI ID
which is the adapter.

At the end of offset 0030 line is the miniport logged error type 00000006,
which is the code for the internal controller error.

Since error types are limited in NT, "internal controller error" can mean
many things, it is used where no other type is available. Not so bad at it
sounds...;)





0
UZnal
7/27/2006 11:15:25 PM
> But when I got into NT, I got a big surprise! Depending upon how IDs were
> set, either the tape drive or the internal CD would get "pushed off" the
> SCSI chain.

Fine, that is a nice case to test next, with the updated driver, not the
current.

> NT's SCSI control panel also showed each drive in the Pioneer
> changer to be using a separate SCSI ID.

NT shows the logical device number as delivered by Spock and not the SCSI
ID.

> I think I will make another attempt at using the late short uncached
SCSI/A
> in a "Server 95" planar (dual serial/LPT) once again. With the M$ driver,
it
> threw a ton of errors and acted very strangely.

Please do with Spock206, I am very curious.

> I think this is fast turning into the longest running thread ever on
CSIPH.
> It's run for well over two months now! :-)

And no end in sight !




0
UZnal
7/27/2006 11:28:16 PM
I am curious, Yellow?

UZnal wrote:
> Please do with Spock206, I am very curious.
0
Louis
7/28/2006 12:16:56 AM
Hi!

> I am curious, Yellow?

Red, if you're talking termpacks...

William


0
William
7/28/2006 12:54:16 AM
Hi!

> Please do with Spock206, I am very curious.

Interesting results. The system is usable and it seems stable, but...
http://greyghost.dyndns.org/uncachedscsitest/ (stuff from the event log)

When the system acts up, the light on the 6X Teac CD-ROM often blinks
repeatedly, despite there being no CD present. The disk light usually stays
on steadily as well.

HDTach reports the following from the Server 95 with the P90...the one that
was mentioned earlier with the 0663 and DPES-31080 drives being driven by a
triple-oscillator SCSI/A with cache. Now the SCSI adapter is the short
uncached SCSI/A.

CPU Utilization 4.4%
Read Burst Speed: 2.3MB/sec
Minimum 2.1MB/sec, average 2.0MB/sec

While the numbers for this adapter are faster, I changed benchmark
utilities. I will have to try the cached SCSI/A once again.

William


0
William
7/28/2006 1:44:54 AM
Hi!

> The 16x Yamaha is slower than the 12x Plextor ....!

I would say the Plextor is the far higher quality drive. They have the
reputation for a quality product.

The few of them I have are top-flight products...much heavier and better
made than most similar CD-ROM drives from other makers.

William


0
William
7/28/2006 1:46:56 AM
Reply:

Similar Artilces:

IBM RS/6000 MCA SCSI Adapter vs. IBM PS/2 MCA SCSI Adapter
Hello, I found in my MCA repository a (seems to be) functionnal RS/6000 32bit SCSI Adapter. In my '80, I have a (what seems to be, again) original PS/2 SCSI Adapter, w/o cache. I found also a w/cache, but is faulty. May I get better performance, any improvement of any kind trying this RS/6000 Adapter, or is it not going to run at all...or will it be worse ? I have a 0661 type HDD, 320 MB in the SCSI Chain. Thanks ! Hum, as I see after some searches, it is RS/6000-only adapter, no ADF, not useable in a PS/2...Can someone confirm this ? The Godfather wrote: > Hello,...

Auctions (2): Three IBM PS2 Graphics Adapters 8514/A *AND* IBM MicroChannel 4869 External 5-1/4" Disk Drive (360K)
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=270123874305 Starting bid: US $0.99 End time: May-31-07 16:43:43 PDT (6 days 3 hours) Ships to: United States Item location: Surprise, Arizona, United States IBM PS/2 MicroChannel CAD Workstation Graphics Cards Model 8514/A listing is for a quantity of three shipped for a single price Also by same seller : http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=270123854097 Starting bid: US $0.99 End time: May-31-07 15:51:52 PDT (6 days 3 hours) Includes the drive sled, the MCA adapter card and ribbon cables for inside the box (as shown in the picture). No affiliation PS William, WCT is mentioned in both auctions. -- Jelte, admirer of the letter of IBM with blue Ishiki The information contained in this post is copyright the poster and specifically may not be published in, or used by http://www.jlaforums.com ...

W9xNT MCA Adapters
This opens the new 207 season, or Experiment 626 ...;) Test team, get ready. I cannot test, you will test, I will provide the builds. Should take us at most a week or so, targets are W98SE and NT4. The three adapters below will be supported: MAGPIE 8F6C DAC960M RAID Adapter HUMMINGBIRD 8F82 IBM SCSI-2 Fast/Wide Streaming-RAID Adapter/A (Cheetah) PASSPLAY 8FBB IBM SCSI-2 Raid Adapter (Passplay) Do we have a DAC960 techref? Although we can do without it, it would be helpful to have it. And, I think, we should support only MCA, no EISA/PCI ? > three adapters below will be supported: Including soft disk lights, of course, and absolute minimum execution stall times for improved adapter performance. Some +20% wouldn't surprise me. Supporting EISA/PCI would be an interesting experiment. The DAC960M should be fun, since it can support 64MB of cache. I see this more for burning CDs... UZnal wrote: > This opens the new 207 season, or Experiment 626 ...;) > > Test team, get ready. I cannot test, you will test, I will provide the > builds. Should take us at most a week or so, targets are W98SE and NT4. The > three adapters below will be supported: > > MAGPIE > 8F6C DAC960M RAID Adapter > > HUMMINGBIRD > 8F82 IBM SCSI-2 Fast/Wide Streaming-RAID Adapter/A (Cheetah) > > PASSPLAY > 8FBB IBM SCSI-2 Raid Adapter (Passplay) > > Do we have a...

IBM 3270 MCA Emulation Adapter
Hi there, I have been searching high and low for software supporting the IBM 3270 Emulation Adapter in my 8570. I'm in the process of salvaging an old scrapped 3174-11L Estrablishment Controller from the company I work for and thought this would be the cue for putting the 3270 adapter to some use...just for the fun of it. Anybody got any pointers to the drivers etc. needed? Thanks in advance! Best regards, Mads Kristoffersen Aarhus, Denmark On Apr 30, 3:02 pm, "Mads Ulrik Kristoffersen" <mad...@image.dk> wrote: > I have been searching high and low for software supporting the IBM 3270 > Emulation Adapter in my 8570. I'm in the process of salvaging an old > scrapped 3174-11L Estrablishment Controller from the company I work for and > thought this would be the cue for putting the 3270 adapter to some > use...just for the fun of it. Anybody got any pointers to the drivers etc. > needed? The "driver" is integrated into the software in this case, you do need the ADF file for the adapter in your 8570, but you probably already have that set up. Which software to use is a function of what operating system you have installed and a bit of personal preference. If you like the IBM stuff, you're looking for a copy of Personal Communications/3270, which is generally called PCOMM for short. I'm running version 5.6 on my Windows XP machine, which is not the latest version. If I'm remember...

IBM MCA FWSR Raid adapter/A with cables auction
From Canada, I've bought from him before, first class. If you wandt a Cheetah and cables, get on this... http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3071245734 Jan-18-04 02:47:03 PST -- Reply to me at louis little punctuation mark ohland with the same ISP He's also selling the ever-popular IBM Lan Adapter/A. http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3071241727 I'd been watching the Cheetah, but since you mentioned it I placed a marker bid. No sniping, please? -John the Requester He also has a Server 330 hot-swap tray up. htt...

Dutch IBM MCA PS2-stuf for sale in the Netherlands
Hoi, Ik wil mijn IBM MCA PS2 'verzameling' wel kwijt aan een serieuze verzamelaar. Stuur even een mailtje en ik mail je de lijst van de spullen die ik heb terug. groetjes, Bert ...

REQ: Hardware adapter info: Use C64 Keyboard on IBM
I've got a dead C64 that I wanted to adapt over to a mini-itx IBM mobo and use VICE on it. I'd like to use the original C64 keyboard with the new PC; however that would require a custom hardware adapter. One person on mini-itx.com adapted an old SX-64 in this manner and uses the original keyboard. He supposedly developed just such an adapter, and promised to make the hardware details available. Like so many other "orphaned" Internet projects, he appears to have lost interest and no longer shows that info on his web pages. Won't answer email inquiries, either. Has an...

IBM PS2 P70 problems with scsi and etherlink mca card...
Hello to the group and thanks in advance to all the fans.=20 I recently decided to make some projects with p70 starting from documentati= on found in the network and for which I thank the respective owners.=20 The idea is to install win95 and "sail" with a ibm 8573-061 of 90.=20 Starting from a basic configuration working (386DX 20MHz, 8Mb RAM, 60Mb har= d disk, floppy disk adapter, Win3.1 and dos6.2), I'm trying to install a sc= si card mcs-700 (connected to a hd 1gb ibm dpes31080) and a network card 3c= 529-tp.=20 I can not try the 2 cards mca as recently purchased on the net.=20 To install the scsi card, I disconnected the old hd 60mb, the old data cabl= e, insert the card scsi mcs-700 in the riser card (16 or 32 bit) connect po= wer and data cable 50pin to 'hd ibm (set id of 0 or 1, correct?). Restart t= he computer with the reference disk (with several *. Adf) the screen remain= s black, the only light comes on the power supply. The hd turn, would seem = to look for something for a couple of seconds, but then stops. Then nothing= ram test, do not boot from the floppy or normal startup dos. No bios-error= ..=20 Not being certain that the hd or the scsi card are working, I decided to te= st the network card. When I insert the network card 3c529-tp in the riser c= ard (16 or 32 bit) and reboot the pc with the reference disk (with several = *. Adf) I get the same results as installing the scsi card With both cards get the s...

Auction: IBM 74G0865 MCA Etherstreamer MC 32 Adapter
>http://cgi.ebay.com/IBM-74G0865-MCA-Etherstreamer-MC-32-Adapter_W0QQitemZ9705254870QQcategoryZ11182QQrdZ1QQcmdZViewItem< End time: Mar-31-06 18:24:35 PST ...

FS: IBM 5250 Emulation PCMCIA Twinax Adapter (FRU 92G5361), IBM 5250 Express PCI Adapter and Cable (PN 88H0210)
Hi, For sale on Ebay ( IBM 5250 Emulation PCMCIA Twinax Adapter (FRU 92G5361): http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=5734214062 IBM 5250 Express PCI ADAPTER and Cable (PN 88H0210) Twinax: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=5734387307 also IBM 3450-001 QIC 1000 Tape Drive (PN 74G8630) SCSI: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=5142103666 Thanks for looking ...

Auction: IBM PS2 77 9577 Micro Channel MCA Microchannel
<http://cgi.ebay.com/IBM-PS2-77-9577-Micro-Channel-MCA-Microchannel_W0QQitemZ110070238054QQihZ001QQcategoryZ74946QQssPageNameZWDVWQQrdZ1QQcmdZViewItem> End time: Dec-23-06 19:52:53 PST Something good from Wisconsin. Bermuda board. Hi! > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=110070238054 > Something good from Wisconsin. Bermuda board. It's *so* yellow. I wonder if that's all sun-related? (On another note, I unfolded the paper tray on a Color LaserJet 2500n the other day and found it had yellowed. I consider that odd, since this printer has never seen the sunlight...do fluorescent lights yellow stuff too?) Also worth noting are the missing MCA slot covers. I wonder what was in them, if anything... William the Curious wm_walsh@hotmail.com wrote: > Hi! > >> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=110070238054 > >> Something good from Wisconsin. Bermuda board. > > It's *so* yellow. I wonder if that's all sun-related? (On another note, > I unfolded the paper tray on a Color LaserJet 2500n the other day and > found it had yellowed. I consider that odd, since this printer has > never seen the sunlight...do fluorescent lights yellow stuff too?) As far as I know, no. Most likely heat related from the fuser, less probably chemical from the paper. wm_walsh@hotmail.com wrote: > do fluorescent lights yellow stuff too?) Yes. Or so I...

Auction: IBM Image Adapter/A MCA Microchannel Hi-Resolution Card
>http://cgi.ebay.com/IBM-Image-Adapter-A-MCA-Microchannel-Hi-Resolution-Card_W0QQitemZ8701564998QQcategoryZ74946QQrdZ1QQcmdZViewItem< Ends Oct-07-05 21:32:44 PDT -- Reply to ohland@charter.net ...

Search IBM PS2/80 NIC MCA ethernet 10/100
Hi, I search for an MCA NIC for this computer Live in France Debian User <test@test.org> wrote in message news:<pan.2004.12.02.19.37.26.613291@test.org>... > I search for an MCA NIC for this computer If you are willing to settle for a 10Mbps MCA NIC, you have several to choose from, IBM and non-IBM -- some are AUI only (or 10Base2 only), some support two kinds of connections, some support all three. If your 8580 does not have a processor upgrade (16, 20 or 25MHz 80386), I'd stick with a 10Mbps NIC -- the Olicom NIC is the most common 10/100 MCA NIC, but eve...

Auction: IBM PS2 Internal PCMCIA Card Adapter
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=280118973512 Starting bid: GBP 0.99 (Approximately US $1.96) End time: May-29-07 01:23:01 PDT (2 days 13 hours) Ships to: United Kingdom Item location: Reading, United Kingdom Here we have a genuine IBM PS2 Internal PCMCIA Card adapter as pictured. Card only - sold as seen. Came from an office clearance but I don't have the hardware to use it. No affiliation For the PS/2E -- Jelte, admirer of the letter of IBM with blue Ishiki The information contained in this post is copyright the poster and specifically may not be published in, or used by http://www.jlaforums.com ...

Auction: IBM PS2 Model 70 Luggable -
http://search.ebay.com/200206566833 End time: Mar-16-08 12:23:08 PDT Colorado ...

Auction: IBM PS2 Model 70 Luggable -
P70, with a good starting price: http://search.ebay.com/200206566833 $5.00 starting bid. Ends Mar-16-2008, 12:23:08 PDT (2 days, 3 hours). Didn't see any shipping price. Ships to the US only. Located in Nederland, Colorado USA. No affiliation. William ...

[auction US] Lot of 24 IBM RS/6000 RS6000 MCA adapters
>http://cgi.benl.ebay.be/ws/eBayISAPI.dll?ViewItem&rd=1&item=230090916042&ss PageName=STRK:MEWA:IT&ih=013< Fairly common cards, I think. But a big lot. Regards, Alvin. Alvin Andries wrote: >> http://cgi.benl.ebay.be/ws/eBayISAPI.dll?ViewItem&rd=1&item=230090916042&ss > PageName=STRK:MEWA:IT&ih=013< > > Fairly common cards, I think. But a big lot. > > Regards, > Alvin. > > If anyone jumps on this, I need another 9-K. ...

Auc-tion: IBM PS2 77 9577 Micro Channel MCA Microchannel
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=110051463507 End time: Nov-07-06 19:45:51 PST (4 days 16 hours) Shipping costs: Not specified Ships to: United States Item location: Webster, Wisconsin, United States === This is an older IBM Personal Computer. It is one of IBM's Micro Channel Architecture PC, model: 9577. It has 8mb RAM, XGA Video, SCSI card and hard disk, and a 2.88 disk drive. The unit seems to work very well, and it has Windows 95 installed on it. So if your looking for a vintage piece of computer history, this would fit that catagory. No software comes with this, except for the Windows 95 that is intalled in it, and you will have to reinstall your own licensed operating system. I will ship to the lower 48 states, and no international shipping. If you have any questions, please feel free to contact me. Thanks for looking. === PS/2 77 486DX2 Looks clean; slots 2-5 emptied. No affiliation -- Jelte Hi Jelte, > "...model: 9577. ...XGA Video, SCSI card..." > PS/2 77 486DX2 > Looks clean; slots 2-5 emptied. Bermuda planar, as expected by the badge marking. Although a Lacuna could presumably have an XGA adapter installed to supplant the planar S3 video, this is an XGA-2 adapter typical on the Bermudas. The SCSI is planar, not adapter based (not correcting you, but the seller). David David@IBMMuseum.com ...

Auction: IBM MCA SCSI/A Microchannel SCSI Adapter w/512K Cache
http://search.ebay.com/310005789020 End time: Dec-13-07 19:36:17 PST Three can Spock, includes internal flat cable from a 95. ...

Auction: vintage ibm ps2 microchannel mca computer mod 90 486
>http://cgi.ebay.com/vintage-ibm-ps2-microchannel-mca-computer-mod-90-486_W0QQitemZ8784004885QQcategoryZ51096QQrdZ1QQcmdZViewItem< End time: Mar-26-06 14:57:08 PST ..it has a XGA video .it has a;180 mb ;hard drive.with OS2 3.0 and WINDOWS 3.1 and IBM DOS on it, all three,,it has 16MB RAM,, also a 1.44 MB floppy drive .also it has a 486 33 mhz processor in it. Ed. My guess is a 160MB SCSI drive, a K complex, and a Spock with cache. Not sure what level, one, two, or three can, or SCSI BIOS. I could not bring enough detail out of the image in order to detect the particulars. Both memory risers and the riser guide are installed. The seller has a 77 up as well. The descriptions are similar, so the complex might not be a 486DX-33. Louis Ohland wrote: > >http://cgi.ebay.com/vintage-ibm-ps2-microchannel-mca-computer-mod-90-486_W0QQitemZ8784004885QQcategoryZ51096QQrdZ1QQcmdZViewItem< > > End time: Mar-26-06 14:57:08 PST > > .it has a XGA video .it has a;180 mb ;hard drive.with OS2 3.0 and > WINDOWS 3.1 and IBM DOS on it, all three,,it has 16MB RAM,, also a 1.44 > MB floppy drive .also it has a 486 33 mhz processor in it. > > Ed. My guess is a 160MB SCSI drive, a K complex, and a Spock with cache. > Not sure what level, one, two, or three can, or SCSI BIOS. I could not > bring enough detail out of the image in order to detect the particulars. > > Both memory risers and the riser guide...

Auction: Vintage IBM PS2 PC Hardware Maintenance Manual Models 25
<http://cgi.ebay.com/Vintage-IBM-PS2-PC-Hardware-Maintenance-Manual_W0QQitemZ270078671271QQihZ017QQcategoryZ74946QQrdZ1QQcmdZViewItem> End time: Jan-18-07 17:11:07 PST These are good for quick service to the systems. I am electric, electric eye... ...

Auction: (3)IBM Future Domain Bootable SCSI Adapter for MCA PS/2
http://search.ebay.com/310031211896 End time: Mar-18-08 16:50:18 PDT Description: (3) IBM Future Domain MCA Microchannel SCSI Controllers for PS/2 - IBM P/N 71G3575 - Future Domain 18C50 SCSI controller - includes 3-device SCSI cable (FRU 71G2558) - boot BIOS ver.1.01 - HD50 external connector, 50-pin internal ...

Auction: vintage ibm 1.2 mb external floppy drive mca adapter
Caution! this is a 360K drive AND 360K adapter, along with the Model 70 sled. http://search.ebay.com/110104477767 End time: Mar-22-07 09:52:39 PDT ...

IBM MCA Fast Wide RAID Adapter Passplay auction (Swedish militia alert!)
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2757867715 Oct-11-03 09:56:08 PDT Looks like RAID cables included? -- Reply to me at louis little punctuation mark ohland with the same ISP ...

IBM PS/2 SCSI-2 ADAPTER MCA W/Drive&Cable auction
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2762837686 Nov-06-03 11:50:00 PST Auction is wrongly titled on e baye. It's listed as a F/W, while it's clearly a Patriot. Includes DSAS drive and a braided cable. Possibly from either a 76 or 77 system. ...

Web resources about - W9xNT MCA Adapters - SPOCK - comp.sys.ibm.ps2.hardware

Adapter - Wikipedia, the free encyclopedia
An electrical adapter may enable connection of a socket used in one region to a plug used in another by offering connections for the disparate ...

AC Adapter - Replacement Laptop AC Adapters
Online shopping for laptop ac adapters at the best price.Buy cheap ac adapters for your laptop computer.

M3 Adapter
Update the firmware of the M3i Zero GMP-Z003 card to support running in new 3DS (Ver. 4.1.0-8E, Ver. 4.1.0-8J, Ver. 4.1.0-8U) and DSi (Ver 1.4.4E, ...

Bluetooth RFCOMM / SDP connection to a RS232 adapter in android
The Android API provides examples of using listenUsingRfcommWithServiceRecord() to set up a socket and createRfcommSocketToServiceRecord() to ...

Mac App Store - Power Adapter Alarm
Get Power Adapter Alarm on the Mac App Store. See screenshots and ratings, and read customer reviews.

Apple USB Power Adapters - Flickr - Photo Sharing!
Comparison of various Apple USB power adapters for iPhone and iPod.

Miracast Wireless Display with Windows 8.1 - Stream PC to TV without Adapters! - YouTube
In this video, I demo native Miracast wireless display support on Windows 8.1 with Lenovo X1 Carbon Touch and Samsung Smart TV. You can use Miracast ...

Apple recalls more than a decade of power adapters due to risk of electric shock
Tech giant instigates massive international recall of power point adapters due to risk of electric shock.

Apple's iPhone 5 'Lightning' adapters will retail for $35 and $45, not available until October
Apple's decision to change the iPhone 5's dock connector means you'll need an adapter or two.

Apple slammed over power adapter recall, 'incidents' may be under-reported
Consumer group Choice calls for more information on the 'incidents' exposing consumers to electric shock, as more customers come forward detailing ...

Resources last updated: 3/3/2016 6:22:57 AM