techknight
Well-known member
I figured that transformer was bad. its a VERY very very very VERRRY common failure that succumbs with lightning strikes or surges.
-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
Ethernet MicroDock - any chance of repair?
- Thread starter dougg3
- Start date
Trash80toHP_Mini
NIGHT STALKER
Very interesting, why has there never been a NuBus IDE Card, other than lack of demand back in the day?
I'm guessing that the T-REX ASIC on the bottom of the PCMCIA Card Cage/IRTalk subsystem sitting on the 1400's '030 slow I/O bus (PBX ASIC bridged) on this NuBus architecture PowerBook does this conversion.
What do you think the odds are of successfully integrating the T-REX Card Cage with a generic NuBus Chipset?
Aims of proposed development:
1) IDE interface for HDD per the original question for SCSI HDD replacement by spinning disk A/O silent SD chiplet booting of course
______available drives
______faster(?) than the Mac's rudimentary SCSI-1
2) PCMCIA WiFi card'S antenna sticking out the backplane of the pet IIfx
3) Inverting the function to hang the NuBus Transceiver/Controller ASIC Trio off the 1400's bridged '030 bus.
4) various other fun and games
Dunno . . . been looking at DCaDFTM2aMSE (Designing Cards and Drivers for the Macintosh II and Macintosh SE) which seems to have (all necessary?) the baseline info missing from DCaDftMF2e for building the NuBus Design Examples (SCSI Test & Video Cards) like the schematics, in-depth function definitions and driver/DECLROM development info . . .
. . . gotta stop reading stuff like that. :-/
The problem with any adapter, even NuBus, is that it is limited to a subset of machines. Most of the simple/cheap IDE adapters on the Amiga side of the 68k world plug directly into the CPU socket! This is viable on machines like the slot-less Plus and Classic. Such a design could be adapted to a PDS card, but there are so many variants of them that it gets expensive trying to accommodate a very limited market.
techknight
Well-known member
Not to mention, you need a driver..
Trash80toHP_Mini
NIGHT STALKER
For the NuBus version you'd need drivers, but hack it onto an '030 bus/PDS and it ought to just work so long as you're running an "install for any Macintosh" that supports the PB190/Duo230 and the memory mapping is workable.
The 190 has the same TREX controller for the PCMCIA subsystem as the 1400 and the 230 was supposed to get a PCMCIA MiniDock with it on board as well. (that's why there's that big gaping maw underneath the UltraDock's logic board)
Dunno really, but it sure looks like an interesting set of crevices to try to driving a wedge home. }
The 190 has the same TREX controller for the PCMCIA subsystem as the 1400 and the 230 was supposed to get a PCMCIA MiniDock with it on board as well. (that's why there's that big gaping maw underneath the UltraDock's logic board)
Dunno really, but it sure looks like an interesting set of crevices to try to driving a wedge home. }
68k Powerbooks have twice the ROM as the roughly equivalent 68k desktop Mac, I'm sure the low-level drivers associated with the PCMCIA module are in there. (The 500 series machines can apparently boot from PCMCIA flash devices, that clearly indicates the driver is *not* in the OS.)
Trash80toHP_Mini
NIGHT STALKER
:?: Not quite sure about your logic re the 500s/PCMCIA/ROM sizes.
The PB150 uses IDE with only 1MB of ROM in an era overlapping the Duos, 190 and 5300
The Duos had 1MB until the 2300c upped that to 2MB, they were (all?) supposed to get the announced, but unrealized PCMCIA UltraDock.
PB190 was 2MB and the 5300 needed 4MB
Dunno, makes a lot more sense to me that the early PPC PBs needed extra ROM capacity for a fat binary toolboxen than for hardware specific drivers, especially those in developmental flux.
All those dead plastics liberated 1400 card cages are in dire need of new homes! :lol:
Perhaps I was oversimplifying things a bit; I was primarily thinking of the fact that the 68040 laptops (with the odd exception of the Duo 280) had those 2MB ROMs while Quadras had 1MB. (You could also note that your typical early-ish 68030 desktop had 256k-512k of ROM, but apparently the last ones out the door had 1MB so on that front it is indeed a tie.) In any case, my point was that the fact that the one 68k machine that was actually blessed with the option of a PCMCIA slot can boot from it indicates that they must have some ROM support for it, unless said ROM support is added via an extension ROM on the PCMCIA module itself. (Which is certainly possible since it plugged into a "PDS slot", but doesn't that also suggest it's unlikely that this ROM support would be in a card cage ripped out of a machine like a 1400 which I *think* came with it built-in?)
Re: the ".EDisk driver": A "normal" PCMCIA card drive (or a CompactFlash card jammed in an adapter, which apparently will boot a 500 series PB) doesn't look anything like system RAM. (They offer a "Memory Mapped" mode in which the device can be physically treated as if it were a memory chip occupying 2k of space but addressing is still via 512 byte blocks that are shuffled in and out of that window by writing to a register. The only difference is that the registers are presented as memory space inside that 2k window instead as "I/O Ports" as they are in "True IDE Mode". Granted it might be interesting to know which mode the Mac uses. "Memory Mapped" in combination with the 8 bit mode that's also offered by CF are semi-popular for use in really simplistic DIY interfaces to microcontrollers.) It seems unlikely to me this is the driver a PCMCIA-equipped Powerbook uses to boot off a card unless said driver is also used as an "abstraction layer" for other physical devices? (The question mark really is a question; I have no idea?)
I haven't looked explicitly at the PCMCIA support of the .EDisk driver, I was mainly looking at the RAM and ROM boot capabilities for interoperability and ultimately my own driver. But it's definitely doing some PCMCIA booting of some sort. Presumably using some memory mapped mode.
Huh, okay then.
Strictly speaking there wouldn't be any advantage to using the Memory Mapped mode over "True IDE"; a driver to do either is of roughly the same complexity (again, you still have to page through the card by writing LBA block addresses into a register area to read more than 512 bytes. The card only has 11 physical address lines implemented), the primary advantage of mapped mode is it can be physically easier to implement when you're just cramming the card onto a system bus without a PCMCIA card services controller. So the .EDisk driver in those machines would pretty much have to have most of an IDE driver embedded in it, I'd think?
(The Developer Note for the PB 5300 says in the "Software Features" section that:
In chapter 8,the very long chapter about the ATA driver, it says it's used for PCMCIA devices after configuring the card with the PC Card Services software. So presumably a stub of the PC Card services exists in ROM on those machines and is called at boot?
So... unless the 500 series + PCMCIA Dock does things very much differently my best guess is there's some ROM on the expansion module to add the boot-time rudiments of the card-socket services and an ATA driver, and perhaps the hook used to do the boot happens to be embedded in .EDisk?
In any case, it seems to me that if you were trying to wedge one of these cages into a desktop PDS slot you're going to have to drag a lot of ROM support along with it, unless the hardware itself does some magic to translate an ATA drive into "virtual memory" for .Edisk, which none of the documentation says is happening.)
Trash80toHP_Mini
NIGHT STALKER
I certainly don't know, but there is a lot going on in general and within the TREX ASIC on the bottom of the 1400 Card Cage's PCB, having added BootROM, driver support, etc. would be trivial.
If the 1400's Card Cage hadn't been heading into the Duo PCMCIA UltraDock, it would have made a lot more sense for Apple to have put all the goodies on the MoBo like in the previous incarnations of the 190 and 5300. That sub-assembly adds a significant manufacturing cost increase and a reliability hit the way they tacked it onto empty real estate on the MoBo of the 1400 with headers like that.
If the 1400's Card Cage hadn't been heading into the Duo PCMCIA UltraDock, it would have made a lot more sense for Apple to have put all the goodies on the MoBo like in the previous incarnations of the 190 and 5300. That sub-assembly adds a significant manufacturing cost increase and a reliability hit the way they tacked it onto empty real estate on the MoBo of the 1400 with headers like that.
I've noticed you seem to attribute a lot of magical powers to that T-REX ASIC... maybe I'm missing something, but from the functional description in the various devnotes it looks to me like it's just a PCMCIA socket controller, roughly equivalent to something like the Vadam VG-469. (Which is a register compatible clone of the PCMCIA support included in the 82365SL chipset.) While I'll grant that PCMCIA controllers *are* complex beasts (Look up the datasheet for one to see why; PCMCIA power management is complicated, and the controller is also required to contain a memory mapper that's essentially the same as that used in EMS/LIM 4.0 ISA expanded memory cards; that's why PCMCIA can have a 64 MB address range for SRAM/Linear Flash cards despite ISA being limited to 16MB. There's also some weird magic they can do with DMA, like "Zoomed Video".) it looks like the T-REX is a pretty bog-standard one with the one exception that its "outside" bus is that 68030 PDS subset that Apple used to hang peripherals on internally in all their pre-PCI Powerbooks instead of an ISA bus.
(The internal arrangement of all those "PDX" based Powerbooks is very similar to your typical 386 or 486 PC computer; the CPU's native "fast" bus is used for little more than RAM while every other peripheral sits on the other side of an ISA bridge. Considering the needless complexity of NuBus for internal peripherals it's not surprising that Apple kept cooking up various flavors of "PDS" busses, which of course were no longer "Processor direct busses" when a next generation CPU necessitated the use of a bridge chips like the PDX. Various subsets of the 68030 bus are essentially "Apple ISA", minus the "Standard" part. No wonder Macs were so ridiculously expensive...)
Anyway. Unless it does some *really* magical things (which the guy who wrote the T-REX PCMCIA driver for PPC Nubus-Linux didn't notice as he was reverse-engineering how to drive it from the practically non-existent documentation), it's going to need software to drive it, and I don't see why that software would already be present in a desktop system's (coincidentally or not, usually smaller) ROMs. So it would seem to follow that if you're going to try to cram one of those card cages into something with a possibly-compatible-with-the-PBX-defined-68030-PDS-bus' slot you're going to have to figure out which software pieces have to come along for the ride, and unless the card cage has a ROM on it (in addition to the T-REX chip) it's safe to assume those pieces are in the main ROM on the PCMCIA-equipped Powerbooks. The exception there is of course possibly the removable module that actually shipped for the 500 series, in which case it would be interesting to know the size and contents of the ROM that might be in the expansion module.
Trash80toHP_Mini
NIGHT STALKER
Therein lie the mystic powers of TREX! :approve:
I've been fascinated with T-REX since I did the block diagram comparison graphic to prove to DR. Bob that TREX was the only missing link for turning a Duo 2300c into a 640x480/48MB PB1400 sans expansion bay over on 'fritter in the 2300c/G3 thread, lo these many years ago.
Silent IDE boot and WiFi for the IIfx would be the holy grail of the kingdom of TREX . . . it'll never happen . . .
. . . but the siren song of the HDD replacement PCMCIA card cage in the Duo 2300c hack remains irresistible. }
Trash80toHP_Mini
NIGHT STALKER
But what fun would that be? :lol:
