Gateway G/Ethertwist MC (16 bit MCA) nic drivers

[ardent-blue]

Do you want it straight?

The edge connectors remind me of a meth addict's teeth, as in missing some. I might have miscounted, but I looked at the "A" side [component], and I >think< -CHRDY is not populated.

A lot of the logic is from the HCTLS family. I'm no EE, so I can't say if those can accept the speed change from a 286-10 system to a 486SX-25 system -WITHOUT- any -CHRDY ability.

If a line is not populated, it is very likely that the adapter does not process that signal. So even if you cobbled together a weg to connect the signal from the MCA slot to a trace or via on the adapter, I'm not confident the adapter will USE it.

Prove me wrong. Please.

 

[Alfh]

Looking at @6018, I see it has a SIMMple hex progression, so diddling the IRQs or I/O should be possumble -BUT- your card [and all GC cards] have non-populated edge connector positions.

I must purify myself in the waters of Lake Minnetonka... Compare your card's connectors to the full slot...

No surprise, DMA support TOTALLY absent.

At least on http://ps-2.kev009.com/ohland/Ethertwist/Gateway_Communications_Products.pdf there is "I/O Address" - "9 software selectable".

Do you want it straight?

The edge connectors remind me of a meth addict's teeth, as in missing some. I might have miscounted, but I looked at the "A" side [component], and I >think< -CHRDY is not populated.

A lot of the logic is from the HCTLS family. I'm no EE, so I can't say if those can accept the speed change from a 286-10 system to a 486SX-25 system -WITHOUT- any -CHRDY ability.

If a line is not populated, it is very likely that the adapter does not process that signal. So even if you cobbled together a weg to connect the signal from the MCA slot to a trace or via on the adapter, I'm not confident the adapter will USE it.

Prove me wrong. Please.

So you think this is a processor speed issue? It's strange that it can do ping and receive some text before it freezes. I don't have much understanding of how these work at the hardware level.
I have Model 35 386 but it's a ISA based so can't try with that..
Edit: Where's a Turbo Button when you need it..

 

[ardent-blue]

At least on http://ps-2.kev009.com/ohland/Ethertwist/Gateway_Communications_Products.pdf there is "I/O Address" - "9 software selectable".
View attachment 1295115


So you think this is a processor speed issue? It's strange that it can do ping and receive some text before it freezes. I don't have much understanding of how these work at the hardware level.
I have Model 35 386 but it's a ISA based so can't try with that..
Edit: Where's a Turbo Button when you need it..

It is not so much the processor speed, as the MCA bus is asynchronous. But I think the GC card was built for the timing windows used by the Model 50. So, my SWAG is the HCTLS logic can't meet the timing window requirements, and without the extended cycle signal, things stop.

There are plenty of successful PIO implementations out there. A 486 class CPU has lots of cycles to drive a PIO...

Now if it is a software issue, I have ZERO clue of what could be the issue. Ask Brutmann, he might have a clue.

"Next i tried to boot Model 95 with clean DOS 6.22 floppy and did the same thing with that, but it froze again after connecting the IRC server. It connected and received some text before it froze after second or two."

This MIGHT be a clue, buffer size?

We still have not ruled out misconfiguration, there is a possibility that the 95's set configuration programs doesn't identify conflicts... Another possibility [remote] is the packet software is having problems >16MB, but you had it running on a Model 50, which uses 1 or 2 MB of RAM...

CD CHRDY : Channel Ready: This signal is normally active (ready) and is driven inactive (not ready) by a slave to allow additional time to complete a channel cycle. The indicates this signal is unique to each channel connector (one independent signal per connector).

During a read cycle, a slave ensures that data is valid within the time specified after releasing the signal to a ready state. The slave also holds thedata long enough for the controlling master to sample the data. A slave canalso use this signal during a write cycle if more time is needed to store the data. This signal is initially driven from a valid unlatched address decode and status active.

 

[ardent-blue]

UPDATE: MC 8-bit section , 16-bit right below it.

Unpopulated connectors:
A side Preempt, Burst, ARB0-4, Arb/Gnt, TC, DS 16 RTN, Refresh, DPAR, SBHE, IRQ14

B side NO IRQ3, no DPAREN, no DPAR(0), CHCK, CHRDYRTN, SD Strobe, SDR(0)

16 address lines, 16 data lines, no streaming, no DMA.

I'm confused, it looks as if there is no A29 ARB/-GNT,

 

[ardent-blue]

Time for Uncle Lou to tell a story about mythical powers and artifacts...
First, take your Dr Denton's flannel pajamas [with the footies! ] out of the warming oven, and put 'em on. Next, whip up a nice, hot mug of mint truffle cocoa, toddle over to the over-stuffed sofa, and snuggle into a corner...

Wa-a-a-y back in the magic time before Fast Ethernet [in the hazy daze of the 80s], people still did sneakernet [I did!]. Networking was over modems or serial cards [shudder]. Mythical beasts with names like "Kermit" and "Xmodem" roamed the land.

Anyways, Gateway Communications made a packaged system with a modified [and licensed] version of Netware, along with purposely modified LAN cards. My SWAG is the "G/Ethertwist" moniker was used with the permission of HP.

After meditating on the G/Ethertwist, it is an I/O Slave. No DMA or other performance enhancing drugs or "ancient bedtime rituals" that seem to be the rage on the interweb. Just PIO. It -MIGHT- be the G/Ethertwist [8220] depends more on the software to do things than other adapters of that period, due to how it was designed. I have NO earthly clue, since my interests have pretty much been in the 486DX class systems, which tend to have adapter's edge connectors fully populated. Not like the G/Ethertwist, where the edge connector's contacts resemble the smile of a long-time crystal meth user...

I see nothing "lethal" in the response to being in a Model 95 since it DOES work to a point. It isn't hogging the bus, or preventing system booting. If I was there, we could try diddling with [or just disabling] the planar serial port. Might be a few other settings to play with, again, I dunno... The G/Ethertwist's ADF is so crude, it is possumble that the 95's set configuration [SC.EXE] is not fully successful in configuring it without a conflict. Again, Michael Brutman is still roaming around. Ask him about the Packet software [not me!]

If you look at the G/Ethernet [8221] adapter, all contacts are populated. But it uses the same [sparse] ADF... Simular chipset...

Good luck! Your titanic struggles have produced actual information [unlike cat videos]. And now, the exhortation from our Moravian "Dear Leader" - "Don't speculate, Probulate!"

 

[ardent-blue]

Added some of ALFH's tribulations up top, but it isn't done, we don't understand...

Gateway Communications page has been updated again...