Ryan, I'll have to dig a bit into the HITR to confirm this, but POS 5
has the channel check bit, which sets the function of POS 6 and 7.

POS 3 and 4 pass address or whatever from 6,7 , damn it Jim, I'm a
doctor, not an engineer. The patent does not seem to fully describe POS
5 bit 6, at least not in detail.

Louis Ohland wrote:
> The subaddress-pointer registers located at input/output ports 106(hex)
> and 107(hex) serve a dual function, storing channel check status
> information in addition to pointing to subaddressing data. A specially
> defined bit, called the channel check status indicator field and located
> at bit six in the register at I/O port 105(hex), shows which of the two
> functions these registers are performing at any given time. When the
> Channel Check Status Indicator Field shows a value of a logical zero, it
> means that registers 106(hex) and 107(hex) provide Channel Check status
> (or point to the location where this status information is stored). When
> this bit indicates a logical one, registers 106(hex) and 107(hex) can be
> used as pointers to subaddressing data.

Bit 7 of POS register 5 is set to 1 unless -CHCK is active from the adapter.
The remaining bits can be implemented as required....

hex 0105
bit 6 **may** be used to indicate that additional status is available
through bytes hex 0106 and 0107.

The indicator is set to 0 on a channel check condition, or when bit
7 of hex 0105 is o. The indicator is set to 1 on a channel reset, or
when bit 7 of hex 0105 is 1. This bit may be reset by any action
that occurs during the channel check service routine.
-------
Will look at this next:

This byte may be read at address hex 0091. Bit 0 of this
byte is set to 1 whenever the 'card selected feedback' signal was
active on a previous cycle or when the system board 1/0 functions
(diskette drive, serial, or parallel interfaces) are accessed by an 1/0
cycle. Bit 0 is reset by the read operation

Ryan, the references barely mention POS 5 bits 6,7 when those two bits
determine the function of POS 6 and POS 7.

I sendt you a link to my latest brainchild page,
http://ps-2.kev009.com/ohland/9-K/9-K_and_XPOS.html

I think they futzed up POS 5 bits 6,7 with POS 6 and POS 7. Then they
say to use POS 4 to access the XPOS. I am kontuzed.

Ryan Alswede wrote:
> Bit 7 of POS register 5 is set to 1 unless -CHCK is active from the adapter.
> The remaining bits can be implemented as required....
>
> hex 0105
> bit 6 **may** be used to indicate that additional status is available
> through bytes hex 0106 and 0107.
>
> The indicator is set to 0 on a channel check condition, or when bit
> 7 of hex 0105 is o. The indicator is set to 1 on a channel reset, or
> when bit 7 of hex 0105 is 1. This bit may be reset by any action
> that occurs during the channel check service routine.
> -------
> Will look at this next:
>
> This byte may be read at address hex 0091. Bit 0 of this
> byte is set to 1 whenever the 'card selected feedback' signal was
> active on a previous cycle or when the system board 1/0 functions
> (diskette drive, serial, or parallel interfaces) are accessed by an 1/0
> cycle. Bit 0 is reset by the read operation
>

https://www.ardent-tool.com/docs/pdf/Personal_System_2_Hardware_Interface_Technical_Reference_May88.pdf

Page 90

Hex 0105, Bit 6: Channel-Check Status Indicator:
When set to 0, this bit indicates channel-check exception status is
available from POS Registers 6 and 7.

When set to 1, this bit indicates no status is available. Registers 6
and 7 may be the status, a pointer to status, or a command port to
present the address elsewhere (for example, in a subaddress area).

Louis Ohland wrote:
> Ryan, the references barely mention POS 5 bits 6,7 when those two bits
> determine the function of POS 6 and POS 7.
>
> I sendt you a link to my latest brainchild page,
> http://ps-2.kev009.com/ohland/9-K/9-K_and_XPOS.html
>
> I think they futzed up POS 5 bits 6,7 with POS 6 and POS 7. Then they
> say to use POS 4 to access the XPOS. I am kontuzed.
>
> Ryan Alswede wrote:
>> Bit 7 of POS register 5 is set to 1 unless -CHCK is active from the
>> adapter.
>> The remaining bits can be implemented as required....
>>
>>   hex 0105
>> bit 6 **may** be used to indicate that additional status is available
>> through bytes hex 0106 and 0107.
>>
>> The indicator is set to 0 on a channel check condition, or when bit
>> 7 of hex 0105 is o. The indicator is set to 1 on a channel reset, or
>> when bit 7 of hex 0105 is 1. This bit may be reset by any action
>> that occurs during the channel check service routine.
>> -------
>> Will look at this next:
>>
>> This byte may be read at address hex 0091. Bit 0 of this
>> byte is set to 1 whenever the 'card selected feedback' signal was
>> active on a previous cycle or when the system board 1/0 functions
>> (diskette drive, serial, or parallel interfaces) are accessed by an 1/0
>> cycle. Bit 0 is reset by the read operation
>>

POS 5 bit 6 is not implemented on this card. All the mca docs say **may**. They are not using POS 6 or 7 for error status.

POS 6 is the address value mapping to sub register.
POS 7 turns on the piping from POS 4 to the registered addressed by POS 6.

This is just a patent doc so who knows what they revised when going to the real AIC-906R chip

Well, is B32 present? That is the -CHCK line.

The wimpy announcements make no mention of Channel Czech.

Ryan Alswede wrote:
> POS 5 bit 6 is not implemented on this card. All the mca docs say **may**. They are not using POS 6 or 7 for error status.
>
> POS 6 is the address value mapping to sub register.
> POS 7 turns on the piping from POS 4 to the registered addressed by POS 6.
>
> This is just a patent doc so who knows what they revised when going to the real AIC-906R chip
>

This is getting intersting (again).
Beginning of this year I was already in touch with Ryan, and wrote an AIX userspace tool to read/write the 9-K's POS/XPOS and I/O space. The tool worked, but did not come up with anything useful.
XPOS subaddressing did not seem to do anything, but I have to refresh my memory on the convo.

These are dumps of the POS and IO space:
http://www.holzapfel.biz/8F62/POS_8F62.txt
http://www.holzapfel.biz/8F62/IO_8F62.txt

I started looking for a proper 100 MHz capable, multi-channel logic analyzer like the HP 16700 series to capture the initialization sequence directly on the bus, but those machines all look either dead or incomplete and still very expensive, if available at all in my old world.
Any suggestions for an alternative?

Will also fire up my RS/6000 -42T that made the 9-K testbench last time.

Louis Ohland schrieb am Samstag, 14. Oktober 2023 um 21:05:06 UTC+2:
> Well, is B32 present? That is the -CHCK line.
>
> The wimpy announcements make no mention of Channel Czech.

I was confronted with "Channel Check" when trying to repair my MIAMI based Ultimedia Video Adapter.
CHCK# was active on very basic disturbance of important MCA control lines, like when I had a dead 74xx logic chip in the CMD# line.
The Adaptec chip may be different, but I don't think this is the right bit to look at.

On Monday, October 16, 2023 at 4:58:24 AM UTC-4, Christian Holzapfel wrote:

> I started looking for a proper 100 MHz capable, multi-channel logic analyzer like the HP 16700 series to capture the initialization sequence directly on the bus, but those machines all look either dead or incomplete and still very expensive, if available at all in my old world.
> Any suggestions for an alternative?

Sadly, no. About 25 years ago, it was possible to pick up a Biomation logic analyzer for a relatively good price (around USD1000), those days are long gone, and finding a Biomation AT ALL these days requires arduous searching. One might get lucky with a herd of 4-channel digital scopes that have external triggers that actually work properly (many don't), but you would need a lot of luck. Your best bet is likely to find/make a friend with someone in the technical services department of a well-equipped university, you might be able to come into a lab and use one of their logic analyzers with some kind words and a bit of handwaving. I don't know of any makerspaces with logic analyzers, but maybe they exist -- or maybe one of the makers in the community knows of a way to get access to a logic analyzer at their day job.

Got to be a simpler tool out there to just watch bits 0-3 on an address line and bits 0-7 on the data lines on a break out board when CDSETUP goes high and stop recording when CDSETUP goes low on the slot. The POS registers are only 1 byte and the bus on an RS/6000 runs at a max of 20Mhz but if your machine is older then it's only 10mhz.

Just for fun I fired up my -42T and stuffed 3 San Remo cards in it.
Check out the dump:

http://www.holzapfel.biz/8F62/IO_POS_3x_8F62.txt

I also added the current ressource configuration for comparison.
Looks like POS[3] upper nibble is clearly DMA arbitration level.

Still unsure about interrupt level and if the I/O dump is useful at all.

Are we sure the missing configuration is done through the XPOS rather than through the I/O window or DMA memory space?

POS[4] register = 0x03 Interrupt priority 3

Christian Holzapfel wrote:
> Just for fun I fired up my -42T and stuffed 3 San Remo cards in it.
> Check out the dump:
>
> http://www.holzapfel.biz/8F62/IO_POS_3x_8F62.txt
>
> I also added the current ressource configuration for comparison.
> Looks like POS[3] upper nibble is clearly DMA arbitration level.
>
> Still unsure about interrupt level and if the I/O dump is useful at all.
>
> Are we sure the missing configuration is done through the XPOS rather than through the I/O window or DMA memory space?
>

> POS[4] register = 0x03 Interrupt priority 3

Interrupt priority is CPU based, not set by POS.

On Monday, October 16, 2023 at 9:38:37 AM UTC-4, Ryan Alswede wrote:
> Got to be a simpler tool out there to just watch bits 0-3 on an address line and bits 0-7 on the data lines on a break out board when CDSETUP goes high and stop recording when CDSETUP goes low on the slot. The POS registers are only 1 byte and the bus on an RS/6000 runs at a max of 20Mhz but if your machine is older then it's only 10mhz.

Certainly, if someone had the inclination (I do not), perhaps they could use an Arduino Uno (14 digital I/Os), write some software for trigger and capture, then dump and analyze. Other microcontrollers could also be used, the Uno is inexpensive and readily available. I'm not sure if it would be fast enough to reliably pick up the data. One phrase I used to hate when I was working was "it's just a simple matter of software". If it's so simple, friend, YOU write the software. That response always shut them up.

I got myself a cheap rip-off of the Saleae Logic 16 analyzer from e*ay. The original costs way over a thousand bucks, and is capable of doing up to 100 MSPS on 16 channels , 16 MSPS when all 16 channels are used. Juuust enough. The software is excellent and extensible through their C++ SDK.

It's enough signal inputs to monitor the POS addressing:
CDSETUP#, CMD#, S0#, S1#, M/IO#, A[0-2], Data[0-7].

The original Snark Barker has debug pin headers to access all those signals, plus I grabbed the card-exclusive CDSETUP# signal from the 9-K San Remo card in question.
Stuffed this unusual setup in my RS/6000 -42T and took a 60 s long capture of the whole AIX bootup process.

Then used the Saleae software to manually analyze all POS accesses to the 9-K card from the BIOS, BOS and driver.
It's 36 accesses in total, and all very plausible.
The BIOS only reads out the Card ID in POS[0-1] and sometimes enables-disables the adapter through bit 0 in POS[2].
The driver additionally sets the values to POS[2-5] for IRQ, DMA and IO window as they could be read out later during AIX run time.

There's no access to POS[6-7], no signs of XPOS subaddressing at all. No mysterious, unexpected reads or writes. All very simple and basic.

I'm afraid, we're on the wrong track here, and said patent does not have anything to do with our 9-K adapter.
It must be using a completely different way of configuration, maybe through the IO window.

What if... AIX does the XPOS thing, and not setup?

Christian Holzapfel wrote:
> There's no access to POS[6-7], no signs of XPOS subaddressing at all. No mysterious, unexpected reads or writes. All very simple and basic.
>
> I'm afraid, we're on the wrong track here, and said patent does not have anything to do with our 9-K adapter.
> It must be using a completely different way of configuration, maybe through the IO window.

There's no action on POS 6 or POS 7 and POS 4 stays 0x03 the whole time CDSETUP is high.

The card is still a mystery on how to access the PCI registers. The command register being the most important.

I do have an ADF put together based on Christian's work that we can upload to the website for others to play with this card.

Hope dies last...

How can you monitor accesses to the I/O window on the MCA side and the
PCI side? If it is a SIMMple use of an I/O window, maybe we can
turbo-diddle the conversion?

Dammit Jim, I'm a doctor, not an engineer...

Christian Holzapfel wrote:
> I'm afraid, we're on the wrong track here, and said patent does not have anything to do with our 9-K adapter.
> It must be using a completely different way of configuration, maybe through the IO window.

Louis Ohland schrieb am Dienstag, 24. Oktober 2023 um 14:28:33 UTC+2:
> How can you monitor accesses to the I/O window on the MCA side and the
> PCI side? If it is a SIMMple use of an I/O window, maybe we can
> turbo-diddle the conversion?

It's certainly doable.
One could probably build an address decoder for the 0x1CXX IO range out of A[8-15] and M/IO# with some fast discrete 74xx logic or an FPGA to retrieve a trigger signal whenever the card's IO range is addressed. I've never done that so far.
Then one would need to monitor A[0-5] to capture the address inside the window that is actually written to, plus the D[0-31] lines. Way too many channels for my cheap analyzer.
Maybe we're lucky and the driver does 8-bit wide access only, then my tools would be sufficient. But for an 32-bit OS driving a 32-bit card on a 32-bit bus, I doubt it for now.
Maybe there's a smarter way.

Since all this "probably" happens during AIX driver initialization, I'm not sure the kernel debugger would be of great help, if I understand it at all.

Christian Holzapfel through his work has discovered the io window addressing that the ASIC uses to talked to the Pcnet chipset. We now know how the the PCI config registers are set on the PCI bus, how VPN data is read from the base card and some readings on card init / IRQ reset.

The patent pdf on the 9-K page is not related to this card and should be removed from the 9-K page.

I've emailed Tomáš Slavotínek the official ADF file. Driver development is underway and more info will be released in time.

One yard and a cloud of dust.

> The patent pdf on the 9-K page is not related to this card

We use what we got until someone proves it otherwise. I'm happy to be
proven wrong, since the Magic Christian has penetrated the inner sanctum
of IBM secrecy....

https://www.youtube.com/watch?v=EYOaNOLVMb0

Any SWAG on which card? Which type of card? Components which would be
significant to that style of Sub POS implementation?

Ryan Alswede wrote:
> Christian Holzapfel through his work has discovered the io window addressing that the ASIC uses to talked to the Pcnet chipset. We now know how the the PCI config registers are set on the PCI bus, how VPN data is read from the base card and some readings on card init / IRQ reset.
>
> The patent pdf on the 9-K page is not related to this card and should be removed from the 9-K page.
>
> I've emailed Tomáš Slavotínek the official ADF file. Driver development is underway and more info will be released in time.
>

My dark suspicion is since the 9-K was only used under AIX, the O/S
handled the hardware WITHOUT needing to go the Sub POS route.

Louis Ohland wrote:
> Ryan Alswede wrote:
>> Christian Holzapfel through his work has discovered the io window
>> addressing that the ASIC uses to talked to the Pcnet chipset.  We now
>> know how the the PCI config registers are set on the PCI bus, how VPN
>> data is read from the base card and some readings on card init / IRQ
>> reset.

>> WITHOUT needing to go the Sub POS route.

Louis it's very very good news. I/O can be done easily from a device driver since that's what a device driver does all day long.

AIX OS isn't needed to use this card. And we don't have to try to figure out assembly for an init POS program.

I'll let Christian share his Linux driver progress when he is ready.

My thought was NOT that we needed AIX, but perhaps the adapter didn't
use Sub POS because AIX spoke directly to the card registers or
whatever. I _think_ adapters can be initialized both via ADF / IADF -or-
Sub POS.

I'm not broke up over not needing AIX...

Ryan Alswede wrote:
> AIX OS isn't needed to use this card.

Yes, it's true!

Finally there is a Linux driver for the card that you can try on your dusted 2.2 kernel:

https://github.com/holzachr/sanremo-linux

Getting there was quite a ride.

Using cheap clones of usually expensive 8- and 16-channel USB logic analyzers, I initially sniffed on the CDSETUP# line of the card, plus A0-2 and D0-7, to see all accesses to the POS registers during card initialization on my RS/6000 7006-42T with AIX 4.3.3.
That did not show up anything significant, but experimenting with multiple card and seeing the POS values set according to the assigned ressources led us to conclusions that Ryan welded his ADF from.

Now knowing that the card is not *mainly* set up through the POS registers, we concluded it must go through the regular I/O port window at 0x1C00 to 0x1FFF.
From some discrete 74xx logic I built a simple address decoder that gave me a single trigger once the 0x1Cxx range is addressed.

Check out the nifty setup:

http://www.holzapfel.biz/8F62/LogicAnalyzers.jpg

Further, I used a Snark Barker as a bus break-out board (yes, in an RS/6000!), since it has unpopulated pin headers for many important bus signals.
Being an 8-bit card only, I had to tap in on the San Remo card to get the upper Data and -BE lines.

Having that compact many-in-one trigger signal, I was able to capture the initalization sequences on the Micro Channel bus when the card is initialized.
Trigger + CMD# + S0WRITE# + S1READ# + A0-7 + Data0-31 + BE0-3.
Although the initialization sequence is always the same, this led to countless hours of digital signal analysis and writing down what I/O addresses are accessed, read or written, and which data is exchanged.
Living the dream.

With everything written down in endless lists, Ryan and I were able to see patterns in those accesses and data, bit by bit, concluding what those ASIC I/O registers do, how data is tunneled through the ASIC to the PCnet chip and how interrupts are handled.

Finally, I was able to modify the existing PCnet32 Linux driver to work with the card in my PC 750.

Let's see if someone is able to form a Windows 9X/NT driver from that...