Welcome to the world of blurry ancient Mac texts! [
] ]'> Thanks for the heads up on the three slot interrupt limit, this is going to take more than just a little bit of crossed eyes time! :
I'm not worried about more than two NuBus Cards being addressed, as only two will fit inside the IIsi Case and there are only two slots available on the Gemini Card (upside down RA Riser from the DuoDock) that'll be mangled in this Multi-Slot Hack attempt. (although the NuBus Slot section of ANY Mac MoBo could be grafted onto any NuBus Adapter or a DuoDock LoBo.
Relevant observations:
I "know" there must be a way to generate additional(?) interrupts for NuBus PseudoSlots from a single(?) address/interrupt, because that's how the Expanse NuBus Breakout Boxes worked, IIRC.
Because there was an SE/30 Expanse NuBus Breakout Box, I "know" that the missing "NuBus" signal on the SE/30's PDS present on the IIsi' PDS "must be" possible to generate.
As I read the Mac II Architecture, the Slot Manager "probably" doesn't poll the NuBus for DeclROM PseudoSlot addresses mapping information directly. This appears more than likely to be done by the CPU first polling for the NuBus Chipset in order to establish the "NuBus Present" state. After that is established, the CPU likely has the NuBus Chipset report the DeclROM Info and the NuBus Slot Address/Interrupt location from what I was assuming to be digital glue identifying each particular NuBus Connector where any particular DeclROM happens to be located. From your report, this identifier may be as simple as the NuBus Chipset "knowing" the physical slot location by the "interrupt line" over which the DeclROM is "reported."
You "probably" won't find anything about such goings-on in the PDS documentation for the /030 PDS from the IIsi/SE/30 specific TechNotes, Dunno, that one's a WAG more than an observation.
Questions:
???????????????????????????????????
< brain blur >
???????????????????????????????????
< returns with first cup of coffee in hand >
Could the IIsi PDS "NuBus" signal be the /NMRQ line?
< makes note that we need an animated, old school/non-Mac, emoticon that crosses its eyes, tilts its head while lowering one eyebrow and then "crashes" >
Back to this specific hack's requirements:
The stock NuBus Adapter's Slot will be taken up by the Radius Rocket acting as the IIsi's CPU in its accelerator mode when the IIsi reboots after loading the RocketWare Driver during startup.
I ASSuME that the Rocket will be in Bus Master Mode as it communicates directly with any other NuBus Cards installed leaving the host's CPU and NuBus ChipSet in the dust as its I/O co-processor.
The NuBus Card I intend to use with the Radius Rocket 33 is the Radius 24X (ROM 2.0) which I ASSuME will be running in slave mode as it communicates with the Radius Rocket NuBus Master via NuBus Block Transfer.
New working theory/hypothesis:
Since the RocketMac Launches after the host Mac performs seppuku upon loading the RocketWare Driver . . . hrmmm . . .
. . . the Host Mac's ROM is Copied into memory on board the the Rocket . . . (yet another SE/30/Accelerator combo bottleneck bites the dust! [] ]'> )
. . . it must re-poll the NuBus for DeclROMs/Addresses for Cards awaiting enslavement . . .
. . . the Rocket MAY not really care which Mac in which it is installed for the purposes of PseudoSlot Addressing . . .
< more interesting images cascade from long term memory, overloading . . . xx( . . . reboot . . . >
It has been a VERY long time since I studied the workings of my original, brand spanking new, PRE-Quadra Radius Rocket 33, so take everything I've tried to communicate above with a very large block of salt.
My brain hurts . . .
] ]'> Thanks for the heads up on the three slot interrupt limit, this is going to take more than just a little bit of crossed eyes time! : I'm not worried about more than two NuBus Cards being addressed, as only two will fit inside the IIsi Case and there are only two slots available on the Gemini Card (upside down RA Riser from the DuoDock) that'll be mangled in this Multi-Slot Hack attempt. (although the NuBus Slot section of ANY Mac MoBo could be grafted onto any NuBus Adapter or a DuoDock LoBo.
Relevant observations:
I "know" there must be a way to generate additional(?) interrupts for NuBus PseudoSlots from a single(?) address/interrupt, because that's how the Expanse NuBus Breakout Boxes worked, IIRC.
Because there was an SE/30 Expanse NuBus Breakout Box, I "know" that the missing "NuBus" signal on the SE/30's PDS present on the IIsi' PDS "must be" possible to generate.
As I read the Mac II Architecture, the Slot Manager "probably" doesn't poll the NuBus for DeclROM PseudoSlot addresses mapping information directly. This appears more than likely to be done by the CPU first polling for the NuBus Chipset in order to establish the "NuBus Present" state. After that is established, the CPU likely has the NuBus Chipset report the DeclROM Info and the NuBus Slot Address/Interrupt location from what I was assuming to be digital glue identifying each particular NuBus Connector where any particular DeclROM happens to be located. From your report, this identifier may be as simple as the NuBus Chipset "knowing" the physical slot location by the "interrupt line" over which the DeclROM is "reported."
You "probably" won't find anything about such goings-on in the PDS documentation for the /030 PDS from the IIsi/SE/30 specific TechNotes, Dunno, that one's a WAG more than an observation.
Questions:
???????????????????????????????????
< brain blur >
???????????????????????????????????
< returns with first cup of coffee in hand >
Could the IIsi PDS "NuBus" signal be the /NMRQ line?
< makes note that we need an animated, old school/non-Mac, emoticon that crosses its eyes, tilts its head while lowering one eyebrow and then "crashes" >
Back to this specific hack's requirements:
The stock NuBus Adapter's Slot will be taken up by the Radius Rocket acting as the IIsi's CPU in its accelerator mode when the IIsi reboots after loading the RocketWare Driver during startup.
I ASSuME that the Rocket will be in Bus Master Mode as it communicates directly with any other NuBus Cards installed leaving the host's CPU and NuBus ChipSet in the dust as its I/O co-processor.
The NuBus Card I intend to use with the Radius Rocket 33 is the Radius 24X (ROM 2.0) which I ASSuME will be running in slave mode as it communicates with the Radius Rocket NuBus Master via NuBus Block Transfer.
New working theory/hypothesis:
Since the RocketMac Launches after the host Mac performs seppuku upon loading the RocketWare Driver . . . hrmmm . . .
. . . the Host Mac's ROM is Copied into memory on board the the Rocket . . . (yet another SE/30/Accelerator combo bottleneck bites the dust! [
] ]'> ). . . it must re-poll the NuBus for DeclROMs/Addresses for Cards awaiting enslavement . . .
. . . the Rocket MAY not really care which Mac in which it is installed for the purposes of PseudoSlot Addressing . . .
< more interesting images cascade from long term memory, overloading . . . xx( . . . reboot . . . >
It has been a VERY long time since I studied the workings of my original, brand spanking new, PRE-Quadra Radius Rocket 33, so take everything I've tried to communicate above with a very large block of salt.
My brain hurts . . .