SuperIIsiHack™ AKA SE/30's BANE . . .

[Trash80toHP_Mini]

I'd like to be able to snag the interrupt for the on-board vampire video. The IIsi disables the Memory buffering for it if there's no sense pin signals on the the DA-19. As I'll be removing that connector from the MoBo or cutting its traces and patching a subterranean RCPII/IIsi cable to it the SuperIIsi™ will never have a use for the internal video interrupt.

[bbraun]

That won't really help AFAICT. You can get the interrupt, since all slots are ORed into /SLOTIRQ. The point of the VIA2 register is to decode which slot had the interrupt. If your card interrupts and you send it to the RBV video interrupt, that's telling the processor the RBV video interrupted, which isn't what you want. What you need is for the corresponding bit in the emulated VIA2's register A (I think this is RBV register C?) to indicate your desired slot had an interrupt. /IRQ0-3 from the 030 PDS correspond to slots 9, A, B, and E, which correspond to bits 0, 1, 2, and 5 of the second VIA's register A. So you somehow need to get bits 3 and 4 of that register to correspond to slot C and D /IRQ lines. What I'm saying is in the SE/30 these correspond to physical (and available) pins on VIA2, AFAICT. On the IIsi, I'm not sure these pins exist. Without the appropriate bit being set in that register, you don't get proper interrupt routing in software. It is possible to either modify SlotMgr or some other hack to alter the routing to do what you want, but that has changed from a pure hardware mod into needing drivers and/or possibly a ROM modification.

[Trash80toHP_Mini]

Which brings me right back to the PAL on the Megabuck$ Japanese Three Slot SE/30 Adapter.
Does anyone know if that's a pure hardware hack or if there's an init/driver necessary for it to work?

My second thought would be that VIA2's function on the IIsi may be handled, in part, by the NuBus Bridge Chipset. If the NewBus Bridge tells the Mac that there's a DeclROM on a NuBus Card in slot X, then it's using interrupt Y by definition, therefore the Slot Manager ought to handle it as such without the need for inits/drivers.

It may be a stretch, but the NuBus Signal and the NuBus Chipset availability seem to be the defining characteristics that differentiate the two machines and their near-identical '030 PDS implementations.

[Trash80toHP_Mini]

We may be looking at this particular case backwards now that I think of it. We're NOT talking about the IIsi as the CPU in the SuperIIsi™ whatsoever.

The Radous Rocket is the CPU and will only need the Addresses and Interrupts available on the PDS to talk to Cards at those address/interrupt locations on the IIsi's I/O Bus.

The Rocket will have taken over the NuBus, becoming the Master and enslaving any Card it can address through the NuBus Chipset . . . and possibly beyond.

I'll have to chop up one of my extra Gemini Cards for the machine pin hack, so that I can plug straight into the IIsi NuBus Adapter's Slot to test this out. Both Duo NuBus Slot IDs are different than the IIsi's Slot ID and the PDS IDs available, IIRC.

Hrmmmm . . .

[bbraun]

How does the Nubus bridge tell the Mac there's a declrom somewhere? That goes against my understanding of how this all works, so if you've got something specific in mind, I'm all about increasing my understanding...

Here's my understanding of the process from connector to System software:
The /NMRQ pin of the Nubus connector on the Nubus bridge adapter goes to /IRQ1 of the 030 PDS connector, and the ID0-3 pins of the Nubus connector indicate to the card to use slot 9. In the IIx, each slot's /NMRQ line goes to VIA2 register A bits 0-5 (one per, slot 9's /NMRQ goes to bit 0, slot A goes to bit 1, etc.). Bits 0-5 of VIA2's register A are then ORed by VIA2 (or RBV, in the IIsi/IIci case) into /SLOTIRQ, which is the actual processor interrupt. The bridge adapter only supports 1 card at slot 9, so /NMRQ goes to /IRQ1. When /SLOTIRQ indicates an interrupt, the CPU interrupts, the SlotMgr's interrupt handler fires, the SlotMgr then checks VIA2 register A to see which (one or more) slots interrupted, and fires off the appropriate interrupt handlers.
So... A (pseudo)slot can interrupt the CPU by toggling /SLOTIRQ, but unless the appropriate bit gets set in that VIA2 register, no one knows what interrupted, and that slot's interrupt handler (if any) won't get run. There's no way an 030 PDS card can inform SlotMgr to go look at some other bit to determine which slot interrupted.
Now, this is all pretty machine specific, since AFAIK, later models have a different way of checking which slot interrupted. As it stands, the IIsi/IIci are already kind of different from the II/IIx/SE/30 since the RBV emulates this VIA2 register and the II/IIx/SE/30 have an actual 2nd VIA.

This gets me thinking whether the Nubus bridge could support additional Nubus cards if ID0-3 were set appropriately, and the additional slots' /NMRQ line went to the corresponding /IRQ line of the 030 PDS.

But again, that's just my understanding, so if there's something specific I should be looking at, let me know...

As for the Rocket, I don't think anything changes. The above is how the system works, and the Rocket has to work within the confines of the existing system. A master in Nubus terminology simply means whoever is initiating the addressing at the current time. Multiple cards can be masters on Nubus, just not during the same cycle. The CPU is always capable of acting as a master, as are Rockets, some SCSI cards, etc.

[Trash80toHP_Mini]

As I understand it, when the Rocket re-boots in Accelerator mode after enslaving the host CPU as a mere I/O CoPro, it runs the NuBus via AppleTalk over NuBus and does Block Transfer Mode with all Compatible Cards.

As I understood it back in the day, the Rocket acted independently of the host CPU, interpreting and issuing the interrupts for the NuBus Slots over the NuBus.

In this way, the Saturn V used a "lowly" SE/30 to copy its ROM to a multitude of Rockets set up in a huge expansion chassis without any regard for the SE/30 as anything but a simple controller terminal . . .
. . . amd the SE/30's not even NuBus Compatible other than via the Two Slot ExPanse Chassis, AFAIK!

[bbraun]

Looking at how things are routed, I just don't see a way a Nubus card can get any interrupts except its own without the host CPU and and consulting VIA2/RBV. Particularly when the Nubus card is sitting off a Nubus bridge off an 030 PDS. The signals just aren't present.
The Rocket can read VIA2/RBV directly, since it is capable of operating as a Nubus master, but it can't get /SLOTIRQ (or onboard SCSI interrupts, Sound interrupts, Egret-based NMI, etc.) without the host CPU. Once the Rocket has software running on the host CPU, nearly anything is possible, but it still has to work within the constraints of the hardware of the system it is running in while (mostly) preserving software compatibility.
The Rocket does change one thing pretty substantially though: it does complicate any software/ROM-based solutions to this problem since any software would need to be compatible with whatever contortions the Rocket software is doing.

But anyway, that's just my understanding, which is definitely subject to reality checks!

[Trash80toHP_Mini]

I was thinking that since it is the Rocket running the Slot Manager in Acceleration Mode, not the CPU relegated to hosting the non-NuBus I/O, similar to the 6502(?) I/O co-processors on the IIfx MoBo, the Rocket may be able to pull at least a few rabbits out of its hat.

I'll need to crack the books and DevNotes for info on Interrupt Lines/Slot IDs/PseudoSlot assignments for multi-slot implementations in oter Macs of the IIsi Adapter's NuBus ChipSet. IIRC, it's the same chipset found on the DuoDock (Rev 1) and possibly the IIci, IIcx and earlier II series Macs.

A few patch wires between a NuBus Slot Section hacked from another machine and the NuBus Adapter Bridge ASICs might do wonders for a Rocket running rampant over a brain-dead IIsi!

[bbraun]

Using JDW's pictures of the SE/30 twinspark thing, these are my best guesses at pin assignments of that chip on the adapter:

1 - CPU A37 (+5V)
2 - CPU A7 (/STERM)
3 - PDS A10 (/BGACK) & Cache B29 (A20)
4 - NC
5 - NC
6 - NC
7 - NC
8 - NC
9 - NC
10 - NC
11 - NC
12 - CPU A10 (/BGACK)
13 - JP3
14 - NC
15 - NC
16 - Cache C38 (CPUCLK)
17 - PDS C38 (CPUCLK)
18 - Cache A2 (/PDS.MASTER)
19 - NC
20 - NC

There might be connections I can't see, or I might have gotten all the assignments backwards. I followed the numbering on the board, and I don't know if that's accurate. But, it seems to be doing something more complex than just mucking with slotid.

[Trash80toHP_Mini]

I'm confused now . . .

After looking at those pics:

It looks like the ArtMix card simply converts the SE/30 PDS to a IIci PDS for using the accelerator . . .
. . . so isn't that PAL doing the same function as the PAL on the "official" SE/30 Adapter card and only providing a PassThru for a single SE/30 68030 PDS Card?
Is there even room to stack TWO Cards on top of that thing?

Now I seriously doubt that the PAL on that card has anything at all to do with the PassThru connector or addressing an additional PDS slot . . .
. . . probably just another ASSuME or memory leak brain boo-boo!

[Trash80toHP_Mini]

I just re-read this thread to refresh the gray matter memory, spell-check, grammar check and clarity check my .TXT output and now my brain really hurts!

The extra batch of Machine Pin Strips have been here for over a week and the solder paste just might arrive today!
I've had the IIsi MoBo and bits transferred to the cherry IIsi case I got on eBay a few months back for a couple of days.
So this morning it's time to chop holes in the bottom of the yellowed original case to lower the floor of the basement for the PDS Cards.

[bbraun]

Ah, yup, a IIci cache connector makes sense! That connection to the cache card's BB29 pin becomes /BGACK, and makes a lot more sense.

[Trash80toHP_Mini]

Excellent! The building blocks are stable in the 'ole noggin' once more!

If you can noodle out ( "clean room" reverse-engineer ) the function of the PAL on the "official" SE/30 adapter card, we can design/fab a production run of lower profile "ArtMix/twinspark/whatever "type" adapter cards that can possibly provide correction for at least one "PDS Drift Unit" for the "Wrong Angle" PDS Card StackHack!

-ness!

edit: Maybe techknight can figure out how to do it with an embedded proc that will also multiplex/convert the PDS address/interrupt gobbledegook to do a three PDS Card Hack . . .
. . . unless a NuBusChipSetGraftHack™ for a vertical internal 7" NuBus Card Slot makes sense . . .

edit: Move the NuBus slot as far forward as possible so a plate-less LittleRedRadiusPixelRocket™ faces the rear of the SE/30 and an internal cable can do a VGA conversion on the way to an HD-15 connector on the EtherNet breakout panel! Choose the original NuBus Chipset and it' becomes available for rework/forwardwork from a lot more donors than the relatively scarce IIsi NuBus Adapter.

[Trash80toHP_Mini]

Let's try this again: YO! bbraun, come on back for some playtime!

I've Updated the TWO SLOT IIsi Nubus Card hack . . . thread with a couple of diagrams, one of which definitely belongs here . . .

I played around with the NuBus Adapter Diagram from the DevNote and wound up doing a major overhaul.

This diagram shows both the NuBus and Basement PDS hacks, both done by soldering Machine Pin strips to the soldertails of the Gemini Card and the IIsi PDS respectively. One of the two cards mentioned will have its Right Angle PDS Male Connector removed and replaced by Machine Pin Strips in their standard configuration as high reliability sockets on a PCB.

Lets see if this clears anything up!

This diagram basically shows the Gemini Card's origins and how it needs to be modified for the TWO SLOT hack.

[Trash80toHP_Mini]

This was last update for this thread, since discussions w/bbraun abut the addressing issues of both of these I/O hacks are here I'm phasing out the TWO SLOT IIsi Nubus Card hack . . . thread



Please let me know if this diagram is self-explanatory.
Do I need to show the NuBus Slot Hack alone for simplicity or is the combo graphic sufficient?
Might it be clearer with both posted individually?

[Trash80toHP_Mini]

I've switched to a more aggressive hack of the IIsi MoBo by substituting the original soldertail PDS socket with a Wire-Wrap Socket that will join the Hacked SuperMac adapter to the Hacked SuperIIsi's Mobo permanently for the Basement PDS Card Hack. I've decided that going half-way using the "Machine Pin Hack" would be reversible, but less robust physically and therefore less reliable electrically.

The same holds true for the marginally less risky, but equally aggressive, removal of the NuBus Connector from my spare NuBus Adapter. The cut down Gemini Card (DuoDock Donation) will have its Male NuBus Connector replaced with a soldertail version as well, after this is fully tested in the unmodified NuBus Adapter's Slot, the NuBus Slot will be removed and the extra length pins on the wire wrap connector will be permanently soldered to the NuBus Adapter slot's pads.

Here is the simplified (I hope) diagram, showing how the Wire Wrap connector moves the Gemini Board & slots closer to the NuBus Adapter:

[Trash80toHP_Mini]

Extra, extra, read all about it!

Rocket lifts off, puts IIsi into orbit!

The RocketShare 1.0 install I did under 7.5.5 on the HDD in the DuoDock II just took a couple of screenshots of itself running on IIsi#2 and I'm ecstatic!

Now maybe I won't have to hack the 230/Dock_II/Rocket/VidCard into a IIsi to get a Rocket to work as an ersatz SuperIIsi™ after all.

Gotta go back to work . . . I'm afraid to shut it down . . .

edit ; Restarted it w/32bit addressing on, still unborken!

[Trash80toHP_Mini]

I played with the Rocket in the IIsi some more after work and booted it again just now. Good news and Meh news to report.

There are still a couple of gotchas that may need a workaround, the worst of which is the grayed out "Take Over Screen" command in the menus. That's a PITA that'll have to be addressed, but I found a reference to fixing that in the manual. One good thing is that the blueprint for the SuperIIsi™ calls for breaking its PDS out the bottom of the MoBo to make use of the other two interrupts/PseudoSlot_IDs. The Radius_Color_Pivot_II/IIsi supports Mac 16" and Portrait resolutions so that'd almost fix the screen issue acceptably. Running the Rocket at 640x480 within the larger window would be OK. It doesn't work so well set at 640x480 at 13"/14" RGB's matching res. but even just 12" RGB within the 640x480 Desktop still matches the SE/30 pixel for pixel . . .
. . . with the GS/Color Ace of Trump up its sleeve.

Getting the Asante NIC to run alongside/on top of Classic networking in the RocketWare install will be a challenge, we'll see!

Be that as it may, the installation seems to be stable, which is pretty good on a machine that is supposed to be incompatible with the Rocket in any way shape or form.

Gotta try installing 7.1 and RocketWare on another HDD. Since RocketShare 1.0 doesn't appear to know it's not supposed to be compatible with the IIsi, maybe the first rev. of RocketWare won't know it shouldn't work with a Mac that was released after it was either.

Gotta try.

Anyone got a suggestion for a benchmarking app I can run to test this monstrosity against someone's tricked out SE/30?

[uniserver]

i think i'm interested in what you have here, but i cannot understand what in the hell you are saying.

[Trash80toHP_Mini]

's OK, i cannot understand what in the hell I am doing.

[olePigeon]

I think he's setting up a IIsi with a dual slot adapter running an Ethernet card & a Radius Rocket on a machine that's technically not even supposed to be able to run just a Radius Rocket.

[Trash80toHP_Mini]

I guess I haven't posted a pic of the baseline SuperIIsi™ spec. as yet. The pics above were my attempt at explaining a more radical approach, involving installation of the more Capable Futura_II_SX/10baseT_Daughtercard, leaving me one remaining address . . .

No Dual-Slot NuBus adapter hack involved unless I get overly ambitious, not great odds of success, really ugly patch wire address line hack required.

Now that the Rocket is up and running where it's not supposed to be, I can get to work on the basement PDS hack. Along with the NuBus Adapter, this will use up all three available address lines on the IIsi.

Meanwhile, back at the launch pad . . . the next step will be to configure the U160 boot drive for the Rocket on its SCSI II DaughterCard . . .
. . . then I can install a benchmarking app to see if the SuperIIsi™ is the SE/30's BANE that I originally set out to build as development stands ATM!

[Trash80toHP_Mini]

I'm having a grand old time with this. I haven't heard a Rocket's WHOOSH!!!!!!!!!!in almost 15 years, IIRC. It's back to a 512x384 window within the 640x480 desktop, looks much more civilized.

The top is on the IIsi and I'm letting it get up to idle temperature to see if I need to install a fan pointing at the two procs before moving on to benchmarking.

This is some kinda sleeper!

[MinerAl]

Semi-off topic: could you use your subbasement principal to stack LCPDS cards? Solder a female connector to the top of an LCPDS Ethernet card and stack a video card onto it?

[Bunsen]

Now that is an interesting thought.