Dove FastNet SE ethernet card - software/info needed!

[cj_reha]

Hello all - 

Recently I purchased a Dove FastNet SE ethernet card for my SE FDHD from eBay as it was listed for a decent price and I have been wanting to mess with networking and compact Macs. It arrived today, and after cleaning up what appears to have been a botched recap job performed by a previous owner, I've installed it without issue. However, it is proving exceedingly difficult to find any drivers or software, much less any information at all about this card. In fact, the majority of search results seem to come from other similarly stumped users on this forum and others, asking the same question with no replies. Even though I am expecting a similar outcome as those other threads, I suppose it couldn't hurt to ask again: does anyone have any drivers, software, or other information on this card? I have tried the "DoveEthernetkaart.sit" archive that is mentioned in a few places on the web as the driver for the SE/30 revision of the card, however it is corrupt and will not open in the multiple different versions of StuffIt Expander I've tried (as also mentioned in the other forum threads about this topic.)

If you have any leads on software or information on this card please feel free to contact me! I would love to get this card working with my SE.

 

[cj_reha]

An interesting update...it seems that my card may actually be physically broken. The power LED on my AUI transceiver does not turn on when plugged in, and when making sure I was getting sufficient power, I discovered there is only around 3.45 volts on pin 13 of the connector, where there should actually be around 12. I've verified the cable connecting the PDS daughterboard and rear panel board is good, and checked continuity in various parts of both boards to no avail. At this point, I may just throw the board in my parts bin and bite the bullet purchasing a more expensive one on eBay.

The SIT archive that's been mirrored on multiple sites supposedly containing the driver for the SE/30 revision of the card, "DoveEthernetkaart.sit", is most likely FUBAR. I enlisted the help of a few software-inclined friends in trying to crack it open, and after a day or so of trying to get it to unpack they've made little progress and think it's unrecoverable. It seems to be a StuffIt 5 archive, but with a missing resource fork and an unusual SIT ID, among other problems.

Even though I'm washing my hands of this project for the time being, I would still like to get drivers or information about this card if someone has it available, so my request still stands.

 

[CC_333]

If you're interested, I may have one that you can use. I don't remember offhand what make/model it is, but it's an ethernet card for an SE/30. EDIT: I think it's a MacCon, and the price of the only one I see on eBay is beyond reason in my opinion.

I'll offer a cheaper-than-eBay price

c

 

[cj_reha]

If you're interested, I may have one that you can use. I don't remember offhand what make/model it is, but it's an ethernet card for an SE/30. EDIT: I think it's a MacCon, and the price of the only one I see on eBay is beyond reason in my opinion.

I'll offer a cheaper-than-eBay price

c

Correct me if I'm wrong, but aren't PDS cards made for the SE and SE/30 incompatible with each other due to the different clock speeds and such? I've seen cards specifically labeled "for SE" and "for SE/30." I'm fiddling with an original model SE.

 

[just.in.time]

This person's Dove card also failed to light up the power light on their AAUI transceiver (http://www.toughdev.com/content/2018/03/dove-fastnet-ethernet-card-for-macintosh-se/).  Unfortunately, they also couldn't locate the driver.  And neither can I.  @CC_333, that is very generous of you!

 

[cj_reha]

This person's Dove card also failed to light up the power light on their AAUI transceiver (http://www.toughdev.com/content/2018/03/dove-fastnet-ethernet-card-for-macintosh-se/).  Unfortunately, they also couldn't locate the driver.  And neither can I.  @CC_333, that is very generous of you!

I believe I have his card.... I purchased mine from Singapore and he seems to be located there as well. (Also, @CC_333 - what he said, thanks a lot for the offer...might take you up on it.)

 

[Dog Cow]

Correct me if I'm wrong, but aren't PDS cards made for the SE and SE/30 incompatible with each other due to the different clock speeds and such?

Yes, you are right, but the main reason is the difference in microprocessor: 68000 vs 68030.

 

[nglevin]

I'm still playing around with that archive. It's interesting to break open in a hex editor because the header looks like a normal StuffIt 5.x file:

53747566 66497420 28632931 3939372D 31393938 20416C61 6464696E 20537973 74656D73 2C20496E 632E2C20 68747470 3A2F2F77 77772E61 6C616464 696E7379 732E636F 6D2F5374 75666649 742F0A0A 1A000510 00068C31 00000072 00010000 00729570 0AB4B452 65736572 766564B4

Which reads roughly as "StuffIt (c)1997-1998 Aladdin Systems, Inc., http://www.aladdinsys.com/StuffIt/ 1rrp ´´Reserved´"

By comparison, here's what a valid StuffIt archive of the same vintage looks like:

53747566 66497420 28632931 3939372D 31393938 20416C61 6464696E 20537973 74656D73 2C20496E 632E2C20 68747470 3A2F2F77 77772E61 6C616464 696E7379 732E636F 6D2F5374 75666649 742F0D0A 1A000510 03A2C55F 00000072 00010000 007239D3 0DA5A552 65736572 766564A5

Which reads roughly as "StuffIt (c)1997-1998 Aladdin Systems, Inc., http://www.aladdinsys.com/StuffIt/ ¢Å_rr9Ó ¥¥Reserved¥"

Now if I transplant that valid StuffIt header for the latter into the former, StuffIt no-ops and closes, but it doesn't bail out and say that it cannot determine the file format.

I don't think this a problem with resource forks. Somebody did something nastier to this file at some point, probably by accident, but it's hard to determine if there's some sledgehammer-like operation that I can apply to shift all the bits into the right place.

 

[AwkwardPotato]

I wonder if it's an encoding error. This chart shows the Mac OS Roman and Unicode hexes for every character. The Unicode hex for the acute accent is the same as the Mac OS Roman hex for the yen sign, which would explain part of the difference between the valid header and the invalid one.

 

[nglevin]

I think you're on to something.

Though if it is an encoding error, it's hard to say if the data is recoverable. Especially for things like strict 7-bit ASCII where certain byte ranges that can't be interpreted are thrown out.

I tried using Mac OS X's iconv command line tool, as in:

iconv -f MACROMAN -t ISO-8859-1 DoveEthernetkaart-corrupt.sit > DoveEthernetkaart-whatisgoingonahhh.sit

Which is using the Stuffit file as its argument, translating from MacRoman to a western ISO encoding, and piping that to another file. But it doesn't go far beyond the header before it finds invalid characters and bails early.

 

[CC_333]

Maybe try doing it in the opposite direction? I.e., convert from some western ISO to MacRoman?

That probably won't work, but maybe??

c

 

[nglevin]

Nah.

I mean I suspect that there are other combinations worth trying, but on a lark I did try a more lenient encoding like UTF-8. With that, the file size bloats and it's still corrupted.

Although thinking about how this could have been corrupted, and the archive was created around 1998? UTF-8 wasn't a popular option, UTF-16 is a candidate but it's definitely not right when I try to read it as such in a hex editor. Windows-1252 aka what you get if you save binary in Notepad.exe (at least up until Windows 10, maybe) refuses to work as it quickly runs into invalid characters.

Not sure what else it might be. Chances of recovery are low unless the encoding used to corrupt it happened to be a comprehensive one that covers a large number of character sets, like UTF-8.

 

[CC_333]

Hmm, does Linux/Unix have any unique character sets worth trying?

c

 

[ravuya]

I did a little bit of work on this one when it first came up, and we discussed in private what I had looked into. I was going to comment earlier but then the forums were down.

After noticing that the Unarchiver puked on the DoveEthernetkaart.sit file, I wrote my own quickie implementation of a Stuffit5 file decoder to see where the first problems were.

The first problem I encountered was that the string at the top of the file ended in \n\n instead of \r\n like the Unarchiver was looking for. This meant that the Unarchiver (and "official" Stuffit Expander) didn't think it was really a Stuffit archive, and it would throw an unidentified file error. I'm not sure what caused this problem - it is tantalizingly close to the common "binary file uploaded as text through FTP" corruption, but not quite.

I've fixed ZIPs that have been uploaded that way before, but it wouldn't work in this specific case because all fixgz does is replace CRLF with LF; in this case it needed to replace CRCR with CRLF. I tried search-and-replacing CRCR -> CRLF but didn't fix any of the other problems (and it wouldn't have fixed the Arsenic sentinel problem; read on).

The next problem, which happened immediately, is that SIT5 format expects each entry to be flagged with a SIT_ID sentinel, equal to 0xA5A5A5A5 (0xA5 = 10100101). In this file's case, it's 0xB4B4B4B4, which is wrong (10110100). This means that the Unarchiver and regular Stuffit would throw a data-format exception.

I don't think the whole file had the "last bit of every nibble" flipped because then the ASCII strings in the file would also be mangled, and they aren't. So that's two kinds of weird corruption. I manually search-and-replaced all the B4B4B4B4 to A5A5A5A5 and kept going.

After I fixed that, both the Unarchiver and my own Stuffit decoder could pull most of a valid header out of the archive, including directory and file structure. The file type and creator codes looked valid to me, and the resource blob seemed to be about the right length.

The blob corresponding to the Disk Copy blob is Arsenic-encoded, which I guess is some kind of proprietary Stuffit compression format. The decoder is fairly well known, which is good news for me; I figured I could rip out the blob, make a fake stuffit file around it and then feed that through Unarchiver so I wouldn't have to implement my own decompressor.

Unfortunately, when I actually got down to the compressed data blob for the Disk Copy image contained within, I ran into two problems:

1. The declared length of the compressed blob is 22,784 bytes too short (the next file header doesn't start until that far after the declared length);
   
2. Even if I do force it to decompress what I think is the "entire" blob, the compressed blob does not contain the sentinel "As" (0x4173) anywhere inside it, much less at the head of the blob, where the Stuffit decoder expects it;
   

At this point, I got the Unarchiver source code, got it building under Xcode on my Mac, and stuffed it full of printf debugging stuff. Its Arsenic decoder also crashed, so I hardcoded it to try different decoders and see if any of those worked (maybe it was misidentified as Arsenic when it was actually a different compression method). No dice.

I'm sort of stumped, since the corruption on this file is kinda weird.

My super ugly code for reading the Stuffit file header is here: https://github.com/barbeque/reallyunstuff

I have probably made all kinds of mistakes implementing it, but it seems to match the Unarchiver's behaviour.

 

[VintageAppleMac.com]

Hello. I was pointed this way by someone on Twitter. I have a file in my archive that may help: http://www.vintageapplemac.com/files/misc/DoveFastnet.sea

See attached screengrab for contents.

HTH.

 

[ravuya]

Awesome! Thank you for providing that.

 

[Paralel]

I love when people have copies of stuff sitting around people thought was lost.

 

[CC_333]

I tend to think that, unless we can confirm that something's genuinely lost (for example, there was a fire in an Atlantic Records warehouse in the 80s, and what was permanently lost there was profound for the music industry), it still exists somewhere, and all one has to do is search for it.

In other words, if it's not confirmed-lost, it's just floating around on some disk somewhere, waiting to be found!

c

 

[just.in.time]

I downloaded a copy just in case. It should really be mirrored to the garden. I don’t have an account there.