• 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.

LCIII PDS <-> IIc iCache <-> IIsi PDS in column look see . . .

Trash80toHP_Mini

NIGHT STALKER
.  .  .  taken because I had a couple of days off with nothing in particular planned. That fresh look/blank page approach to the PowerCache Cloning Project seemed a good way to clear some of the cobwebs out. I decided that nice clean columns of text for pinouts of the various slots involved done to the same scale would come in handier than scrambling around looking for them in whatever size I'd done them across a slew of Illustrator files. Didn't turn out exactly as I imagined it, but it's a good start.

RosettaCache-00-003.jpg

RosettaCache-00-003.PDF

I couldn't believe how few control lines were on the IIci Cache Slot, but luckily an error on my part sent me off to find four more. The 1990 PaparDocs were different from the 1989 Macintosh IIci DevNote. Four signals went undocumented as "n.c." for about a year. Dunno if it was done on purpose or what, but leaving CPU Disable undocumented outside the later Printed Volumes might well have been. Some line designations were changed from Vcc to +5V and some not. Why was the distinction between the two in the hard copy docs?

Signal nomenclature in the DevNote was XXXX~ and was changed to /XXXX matching earlier editions of Cards and Drivers and Hardware Guides. No clue what was up with that, but I found it odd.

DCaDftMF2e-vs-IIci_DevNote.jpg

DCaDftMF2e-vs-IIci_DevNote.PDF

I've got the passive LCIII Adapter in hand to translate into IIci Cache as a model for translating IIsi PDS passively into IIci Cache in the same manner. Why? Because I'm guessing my PowerCache Card might work just fine in a passive IIsi adapter, so long as there's nothing on the bus identifying itself as being located at Slot ID $E.

DayStar's drivers might check for the Mac's Identity, but I'm figuring not. We shall see.

edit: oopsie in the title, please fix.  Looks like I failed to gray out A1 and a Vcc connection on the IIci Slot, still looks really bare to me, without those four n.c./undocumented signals grayed out the IIci Cache Slot looked all but naked.

Also: if I still had my IIx from back in the day and could find that blasted (passive) IIcx PowerCache adapter I'd be trying that combo with NuBus Slot $E empty. ;)

 

Attachments

  • RosettaCache-00-003.PDF
    178.3 KB · Views: 59
  • DCaDftMF2e-vs-IIci_DevNote.PDF
    601.4 KB · Views: 67
Last edited by a moderator:

Trash80toHP_Mini

NIGHT STALKER
This fresh look see turned out to have been a very productive exercise. Did some scribbling on the printout at work and all signals between IIsi and IIci Cache connectors are accounted for except:

CACHE - Memory controller for cache access

/CENABLE - Cache enable

/CFLUSH - Cache flush

Since the PowerCache handles such Cache related functions on board, they're not necessary on any adapter. (AFAIK)

/CPUDIS - CPU disable

Apple was apparently looking forward to opportunities such as the PPC601 upgrade card popping up in the future, so they put a pin to disable the CPU into the hardware interface, no drivers necessary, unlike the case of the universal PowerCache.

/RMOE - ROM output enable

Heaven only knows about this one, best guess it that Apple was likely covering all possible bases after the "Dirty ROM" fiasco.

edit: I wonder if this line works the other way, allowing a processor card such as the PPC601 access to the toolbox routines in ROM on the motherboard?

It's a given that all signals are accounted for between the LCIII's oddball 68030 PDS implementation because it requires only a passive adapter.

I had a hunch that a passive adaptation for the IIsi might be available in one possible scenario. Thanks to joethe zombie's much appreciated help in yet another narrowly defined investigation thread I got very quick confirmation that this scenario does indeed exist (maybe) and that all systems are go for experimental development of that passive IIsi PowerCache adapter. If that experiment proves successful, it will confirm my theory that memory conflicts between the PowerCache' internal cache operations and any standard implementation of a device utilizing memory allocated to NuBus Slot $0E is the root of all adaptation evil.

Reverse engineering the wiring and line conditioning on my passive LCIII adapter and then translating that into IIsi SlotSpeak would be the next steps on the agenda. Figuring out where to provide cutouts for transplantation of the GAL from the IIx adapter to the (no longer) experimental passive IIsi adapter sends me right back to shenanigans on the banana ranch.

 
Last edited by a moderator:

Trash80toHP_Mini

NIGHT STALKER
I've been going over the passive LCIII PowerCache adapter with the continuity tester on and off for a few days and have some interesting results:

RosettaCache-LCIII-IIci-25p.jpg

Things match up pretty well, found out the CPU variants are connected to the IIci side as opposed to the PDS variants of the same signals on the LCIII PDS.

Last I checked, /CFLUSH and /CENABLE were tied to +5V and GND respectively, pulling them high and low rather than leaving them hanging in the breeze unconnected. Gotta re-check that.

I think the center alignment presentation may be about as close as I've ever come to doing anything resembling an actual schematic, does it translate well for that?

Haven't checked out the n.c. annotated signals yet, dunno when I marked 'em up like that. Time to double check everything and pencil in the pin numbers on the graphic while I'm at it. Color coding is inexplicable, blue is a good thing, the black stuff need a good going over and the other colors  .  .  .  lets just say it's weird.

Curiouser and curiouser.

RosettaCache-LCIII-IIci-025.PDF

 

Attachments

  • RosettaCache-LCIII-IIci-025.PDF
    178.1 KB · Views: 40
Top