Any apps that probe Nubus space?

[Addicted]

Hey all. I have a Nubus network card that looks to be in fair shape, but which does not appear at all to MacTest, TattleTech, or MacEnvy.

After searching here, it seems the most optimistic theory is the card's DeclROM is not responding or has bit-rot. Are there any apps that ignore the system's determination of card presence and probe for decl data anyway?

Background:

Probing around, the card seems to be delivering power to all the chips. I replaced worn can caps and resoldered dry joints. I've bathed it (IPA eyedropper/brushed/let sit/compressed air+lab wiped/repeat). There are very slight signs of corrosion that do not appear to extend underneath the big AT&T FPGA and NS ST-NIC chips. I am presuming the FPGA is the Nubus controller, and it was essentially corrosion free. I found no bad traces checked any iffy ones for continuity. I replaced a few SMD resistors that showed some corrosion. It is a four layer board, though, so..

Other theories include the FPGA's config ROM failing, the FPGA itself being fried, or dead Nubus glue chips (latches etc). I might try to lift and replace the eight glue chips next.

 

[joevt]

You can look at https://github.com/joevt/SlotsDump See how it calculates addresses for the slots. Then you can try dumping addresses that are not automatically dumped.

The DeclROM should have the header at the end of the slot address space so I would just dump that part. A slot address space is 256 MB and is on a 256 MB boundary.
0x#S000000 where S is the slot number (usually like 9,A,B,C,D,E) and # depends on the machine memory layout.
The last byte of the header is between 0x#Sfffffc and 0x#Sffffff

 

[Addicted]

Cool, thanks! I'll do that perhaps tomorrow with MACSbug.

Today I scoped the FPGA's config PROM lines and it looks like the FPGA is properly initializing at power-on. There were glitches on the data line, though perhaps just due to my scope (Saleae). The bitfile in there has no checksumming (if I recall its datasheet correctly), so there may still be bitrot, or the glitches might be corrupting the transfer.

I then scoped what I believe to be the DeclROM, and am unsure what I saw. I did not see what I expected, which would have been a sequential burst of increasing addresses covering a range of, oh say, tens of bytes. The PROM (74LS471) has two selects and no old spec I can find says why, and they were not always equal. The address lines were changing regardless of their states, but likely they also address the ST-NIC and/or its buffer RAM.

 

[joevt]

Cool, thanks! I'll do that perhaps tomorrow with MACSbug.

I would look at the code. First, see what output it produces (maybe post the results here so we can suggest further steps). Then add a new slot scanning method if the existing methods don't find what you're looking for.

 

[Addicted]

Oh, sorry if I misspoke. I haven't set up a legacy Macintosh build world, and the Github had no app/pkg/binary download that I saw... so I was OK with doing a few peek/poke style accesses with a debugger, rather than jump-starting my someday developer bench. No slight intended! I do want to have my stable IIcx (or the SE, or the LC III, or the C610.. ) able to compile and run legacy Mac source code.. just.. tomorrow

 

[joevt]

I suppose MacsBug should work if you know the addresses.
I've attached the binaries.

 

[Addicted]

I probably have the wrong zip utility.. I could not unpack the SlotsDump. I'll try other utils (and other downloaders) again soon.

TL;DR -- Seeking more info on an obsolete AT&T FPGA at the heart of this problem. Two big asks.

Details:

I dumped the (socketed) DeclROM by reading it with an Atmel MCU. It looks fine to my unschooled eye. Using the ROM-Fiend template with Hex Fiend, everything looked consistent, with the NIC's network MAC address preceding the declaration data.

0000  00 00 1D 07 33 FB 00 00 01 00 00 0C 80 00 00 68    ....3..........h
0010  FF 00 00 00 01 00 00 14 02 00 00 18 20 00 02 88    ............ ...
0020  24 00 00 24 FF 00 00 00 00 01 00 00 00 00 00 00    $..$............
0030  44 4E 49 20 45 74 68 65 72 6E 65 74 20 43 61 72    DNI Ethernet Car
0040  64 00 00 00 01 00 00 10 03 00 00 20 04 00 00 20    d.......... ...
0050  FF 00 00 00 43 61 62 6C 65 74 72 6F 6E 20 53 79    ....Cabletron Sy
0060  73 74 65 6D 73 00 00 00 32 2E 30 00 45 36 31 30    stems...2.0.E610
0070  30 00 00 00 01 00 00 14 02 00 00 18 0A 00 00 3C    0..............<
0080  80 FF FF 80 FF 00 00 00 00 04 00 01 00 01 01 09    ................
0090  4E 65 74 77 6F 72 6B 5F 45 74 68 65 72 6E 65 74    Network_Ethernet
00A0  5F 41 70 70 6C 65 5F 45 4E 65 74 41 64 61 70 74    _Apple_ENetAdapt
00B0  65 72 4D 61 63 49 49 00 00 00 00 00 00 00 00 00    erMacII.........
00C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
00D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
00E0  00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 1C    ................
00F0  00 00 00 F7 C0 69 B5 DC 01 01 5A 93 2B C7 00 A5    .....i....Z.+...

What is of more concern is the Configuration PROM for the FPGA. I have scant documentation on this. I dumped it as well (attached, 1736A.bin , ~3.5KB). I *think* I have the right bit order (MSB/LSB first etc.) but there may be details I have missed.

Unpacking the bitstream in various ways has produced nothing that agrees 100% with that document. Preamble and dummy bits that should be ones or zeros are not. The length field makes sense if I allow one preamble bit to be zero, when the document implies that it must be a one.

But I do see the FPGA driving the right number of cycles to the PROM and raising its DONE signal right after power-on, so, it's not staying in some error state. Again, I may not have the right interpretation of the bitstream.

If anyone has experience with the AT&T/Lucent 3042 or the ORCA Foundry Development suite from 'way back and can answer a few short questions about the bitstream, I'd be so grateful.

OR..

If anyone else has this card and the means to dump its configuration PROM for comparison, that would be awesome. It's a CableTron Systems, P/N 9000343-03 Rev E1. 10BaseT+Thick Nubus. Four link LEDs on the bulkhead.

With the right bitstream, I could use something like the ATtiny85 to mock up a permanent PROM replacement.

 

[joevt]

I'm using macOS Monterey. I used the zip that is built into macOS (Archive Utility.app). It preserves resource forks and finder info.

 

[joevt]

I think the 256 bytes is ok except the length doesn't seem to include everything. The fhByteLanes is 2 out of 4 bytes, so the start address of the decldata (assuming slot E) would be like this:

printf "%X" $((0xFF000000 - 247 * 2))
FEFFFE12

However, we see there's a sRsrcUnknown at FEFFFE00 which is 256 * 2 bytes from the end. This points to the 8 byte MAC address at the very beginning of the ROM. The reason the slot resource is unknown is because SlotsParse doesn't know what ID 0x80 is supposed to be for this sRsrcType. SlotsParse only shows 4 bytes because it doesn't know how big the slot resource is.

Maybe the length was shortened so the checksum does not include the MAC address which is unique to every device produced? In that case, the size should have been 248 so that the start is at FEFFFE10 but I don't think it matters.

FHeaderRec:
FEFFFFD8
       fhDirOffset: 00 FFFF1C = FEFFFE10
          fhLength: 247 (expected 256) ; Start of ROM: FEFFFE12
             fhCRC: C069B5DC = ok
          fhROMRev: 1 = romRevision
          fhFormat: 1 = appleFormat
          fhTstPat: 5A932BC7 = testPattern
        fhReserved: 00
       fhByteLanes: A5 = byte lanes: 0,2

Slot Resource Directory from Header:
FEFFFE10
  0    01    00000C FEFFFE28                   
	  0    01    000014 FEFFFE50 ; sRsrcType       0001=CatBoard 0000=TypBoard 0000=DrSWBoard 0000=DrHWBoard
	  1    02    000018 FEFFFE60 ; sRsrcName       "DNI Ethernet Card"
	  2    20    000288          ; boardId         0288 ; Unknown Board ID
	  3    24    000024 FEFFFE88 ; vendorInfo      
		  0    01    000010 FEFFFEA8 ; vendorID        "Cabletron Systems"
		  1    03    000020 FEFFFED0 ; revLevel        "2.0"
		  2    04    000020 FEFFFED8 ; partNum         "E6100"
		  3    FF    000000 FEFFFEA0 ; endOfList       
	  4    FF    000000 FEFFFE48 ; endOfList       
  1    80    000068 FEFFFEE8                   
	  0    01    000014 FEFFFF10 ; sRsrcType       0004=CatNetwork 0001=TypEthernet 0001=DrSWApple 0109=DrHWUnknown
	  1    02    000018 FEFFFF20 ; sRsrcName       "Network_Ethernet_Apple_ENetAdapterMacII"
	  2    0A    00003C FEFFFF70 ; minorBaseOS     $Fs00 0000 + 00000000
	  3    80    FFFF80 FEFFFE00 ; sRsrcUnknown    00001D07
	  4    FF    000000 FEFFFF08 ; endOfList       
  2    FF    000000 FEFFFE20 ; endOfList       

minAddr = FEFFFE00   maxAddr = FEFFFF70

FEFFFE84: 0000                                                                             ".."
FEFFFE88: (2 = 00000002 bytes)

FEFFFECC: 0000                                                                             ".."
FEFFFED0: (2 = 00000002 bytes)

FEFFFEE4: 0000                                                                             ".."
FEFFFEE8: (2 = 00000002 bytes)

FEFFFF78: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  "................................"
FEFFFFB8: 0000 0000 0000 0000 0000 0000 0000 0000                                          "................"
FEFFFFD8: (48 = 00000030 bytes)

As for the 1736A.bin file, it seems to be the same 42 bytes repeating. Are you sure you uploaded the correct file?

xxd /Volumes/Storage/Downloads/1736A.bin > /tmp/1736A.xxd.txt

 

[Addicted]

Aha, my Atmel code to read the FPGA's PROM dropped the very first bit. Now the decode of the corrected PROM dump at least shows a coherent header. But then the frames still go on to conflict with the document, which seems to require each frame to end with 0b111 .

So it depends on whether or not the FPGA requires the frames to end on 0b111 or not. If it does, then this bitfile appears to be the problem with this Nubus card. I'm reviewing my decoder program to be sure it's correct.

3853 bytes recovered
Preamble prefix: 1111_1111
Preamble code: 0010
Length: 0000_0111_1000_0110_1100 30828 0x786c
'Dummy' bits: 1111
Frame   0: 0 01101111111111111011111110111111110111111011111111111011111111111111111111011111110111111101111111011111 111
Frame   1: 0 11110111111111011101111110011101111111011110111111001110111101111111101011000011111101101111011111110111 111
Frame   2: 0 11000101011111000100110001101100011111000111110101011110101111100011111000110111111111100100000000001111 000
Frame   3: 0 11011001111001101111111111111011111110111111110111111011111111111011111111111111111111011111110111111101 111
Frame   4: 1 11011111111011110111111111011101111110011101111111011110111111001110111101111111101011000011111101101111 011
Frame   5: 1 11110111111011000101011111000100110001101100011111000111110101011110101111100011111000110111111111100100 000
Frame   6: 0 00001111000011011001111001101111111111111011111110111111110111111011111111111011111111111111111111011111 110
Frame   7: 1 11111101111111011111111011110111111111011101111110011101111111011110111111001110111101111111101011000011 111
Frame   8: 1 01101111011111110111111011000101011111000100110001101100011111000111110101011110101111100011111000110111 111
...

 

[Addicted]

@joevt Thanks for the DeclROM detail! And also for noticing the repetition in the FPGA bitfile data. I've been looking at it in binary (e.g. previous reply) and focusing mostly on the header, so I had not noticed that.

I'll review my dumping code once more before I blame the chip. 42 is a strange length for a chip to repeat.

 

[zigzagjoe]

Yeah, that looks highly questionable. Attached is a PROM from a Carrera (contains a XC3x42 and XC3x20 bitstream) for comparison. Here is a tool I wrote to program PROMs: https://github.com/ZigZagJoe/AT17C65-Arduino-Programmer
Along with a reader program (attached) and a validation tool I made some time ago. Hopefully some of this is useful.

You might consider looking at @Arisotura's work here: https://68kmla.org/bb/index.php?threads/bitstream-viewer-for-xilinx-xc3-family-fpgas.47031/

XC3000 display

 

[Addicted]

I slowed the clock down (considerably..) and now have a bitstream with correct header and trailers on all frames.

The 42-byte pattern may have been the PROM's internal counter being overdriven by my original clock, and hence not properly updating all eight counter bits.

3853 bytes recovered
Preamble prefix: 1111_1111
Preamble code: 0010
Length: 0000_0111_1000_0110_1100 30828 0x786c
'Dummy' bits: 1111
Frame   0: 0 01101111111111111011111110111111110111111011111111111011111111111111111111011111110111111101111111011111 111
Frame   1: 0 11110111111111011101111110011101111111011110111111001110111101111111101011000011111101101111011111110111 111
Frame   2: 0 11000101011111000100110001101100011111000111110101011110101111100011111000110110001111100011101000110111 111
Frame   3: 0 01110111111111111110111111111111011111111010111111011111111101111111111111111111111111111111111111110111 111
Frame   4: 0 00110111110110111110101111111111111101111111101111110101111101011111110111101111111011011110000111111111 111
( ... )
Frame  282: 0 11111101111111111111110111111101111111111111111111110111111111101111111111111111111010101111111111110111 111
Frame  283: 0 10111100011111011111110011111100111111000111110111111110111111100011111000111110111111100111111010111111 111
Frame  284: 0 11110111111101111111111111111111111111111111111111111111111110111111111111111011111110111111111111111111 111
Dummy bits: 1111

Which is good in that I haven't lost my ability to write a simple utility, and bad in that I have no more leads to follow on resurrecting this Nubus card. Perhaps the FPGA itself has failed, but it's no longer available in 84-PLCC format.

@zigzagjoe - I will look at your links today. Anything that might shine some light on the 3042 (xc3 series FPGA) might give me a new clue.

For posterity, the slow-clock data is attached.

Thanks all for the responses! I hope I am sharing interesting things in the field of 68K Mac maintenance...

 

[Addicted]

@zigzagjoe .. that bitfile visualizer is neat. Thanks!

I am not well-versed in FPGA internals. But from what it shows, many CLBs are using inputs that are unassigned. Assuming such inputs serve as constant 0s (or 1s), in many cases they render the function into a constant. Which seems like a waste of a CLB, but possibly just something that was not optimized away. Continuing my little self-ed crash-course in FPGA internals to figure this out.

I should also glance at the Nubus spec and see just how complex the protocol is. B/c I am curious what this FPGA 'does', partly to guide me to any remaining low-hanging fruit experiments to try.

.. And then I should choose my next goal in Mac repair, as I think this card may be a dead end. All I can imagine now is lifting the ST-NIC in search of damaged traces, or replacing all six bus glue logic chips. And some of those do not want to come off of the board, I've tested a few. The ST-NIC would be a difficult lift, too.

 

[zigzagjoe]

I know programmable logic (GALs, CPLDs), but not FPGAs. So no idea on the internals... but it is a neat tool for sure. Nubus (slave) doesn't require a lot of logic as long as you can get away with putting the burden on your driver to avoid misaligned or incomplete accesses (hardware is only 16 bits wide instead of 32, for example). So, a FPGA is pretty overkill for a basic network board unless it supports bus mastering (unlikely). A 3042 is not a small FPGA either as the standards of the time went.

Do you have a picture of the card?

 

[cheesestraws]

I have nothing to add but I'm fascinated by the idea of a 10BaseT card needing that juicy an FPGA, so am following with interest.

 

[Addicted]

The FPGA tool's map for this card does paint a picture of an under-utilized FPGA.. a lot of it is unused, which is what sparked my curiosity in what the card side of Nubus needs to do. I presume just address decode to select the network chip or the buffer RAMs, you mentioned lane management, and do wait states?

Here are pictures of this card.

• The piggybacked decoupling capacitor is my doing, added just this morning in hopes that maybe the config PROM underneath it just needed a little more backing due to old age. No change in behavior.
• The paper label is on the DeclROM and echoes the MAC ID data that is found in @joevt 's analysis, which was a good sign.

 

[Addicted]

@KGLlewellyn has one of these too, see thread Cabletron NuBus Ethernet Card Drivers - E6110-X . That card is working.

Edit: ah, it's not identical, but appears to be a very close relative. Different oscillator for the NIC chip; one of the 555s is unpopulated; different delay line chip beside the config PROM socket; minor differences below the DeclROM (unpopulated transistors); and the FPGA has been replaced with a CableTron branded one (possibly pin-for-pin compatible ASIC) that leaves the config ROM unpopulated on that card.

 

[zigzagjoe]

At a glance... probably a 4 layer board.

U5-U8 ALS640 Inverting data transcievers, 32 bits of data bus (Nubus<->Card local)
U9-U10 ALS533 Inverting latches, 16 bits of address bus (Nubus->Card local)
U1-U2 ALS373 latches, to expand 16 bit SRAM/ST-NIC data bus into 32 bit accesses on nubus
U11-U12 Data SRAM for ST-NIC

It's not a bus mastering card, no way to do that with the hardware on the card. It does expand all accesses to 32 bit to make the most of relatively expensive nubus cycles. A pretty common design pattern for a nubus or PDS ethernet board. Not immediately obvious what they're using to decode the upper address bits and check ID bits but the FPGA could be doing that as only 8 bits are needed.

Otherwise, the FPGA needs to handle nubus interfacing, sequencing the buffers & latches, and coordinating the access to the ST NIC and ST-NIC's SRAM. Not a tall ask; it doesn't require terribly complicated logic. It's 3-4 GALs worth of code. Given the relative scarcity of traces and vias in the region of the FPGA it doesn't appear to be doing anything with busses.... if it looks like it's largely unconnected inside the FPGA I'd say that's because it is, but they had to program the cells to a fixed state to reduce noise.

Looks to me like it just is the way it is, there's no real reason I can see that they needed to use the FPGA but they did anyways. That would have been a state of the art chip in 1991 and probably $$$$.

Would recommend probing to see if you get a bus error or not when you hit the card's address space. Try DM FxxFFFF0 or DM FxFFFFF0 in macsbug, where the x corresponds to the slot ID. You can figure that out by looking at the developer note for that system, or placing another card in the slot and seeing what it's reported as. If you get a bus error when trying to do that read, something's badly insane so the card doesn't think it's being accessed or is unable to acknowledge. Could be a few reasons but most of them involve the FPGA being bad/damaged.

 

[Addicted]

I can't replace the 74ALS640's without buying $250 of them, so.. I'll just hope the bus interface is OK.

@joevt also encouraged me to inspect memory directly, and indeed that was this thread's original direction.. I got bad accesses but did not trust my use of the memory map. Today I double checked $A and also tested the spaces for the two other cards ($9, $B) in that system. Woe is me: either it's the FPGA, or those hard-to-find bus interface logic chips...