Project30 - IIsi NuBus Adapter in SE/30 - fifth edition

[Trash80toHP_Mini]

Looks like the 74ALS651 transceivers used in the IIcx are still available, so I don't necessarily need to translate the schematic/layout to substitute the two ICs used in the DuoDock II for the eight on my IIcx board. I can stick with the layout developed by @max1zzz as my baseline.

Have you developed the schematic from your IIcx board layout yet max?

 

[Phipli]

Have you developed the schematic from your IIcx board layout yet max?

Can't you use the Bromarc one?

 

[max1zzz]

Looks like the 74ALS651 transceivers used in the IIcx are still available

ALS651's are a bit of a pain because they are not manufactured new so you either end up spending a crazy price per chip or having to order stupid quantity's. there is the 74ABT651 which is still made (though only in a SOIC package) it tends to be pretty expensive though (about £5 a chip last I looked) here are also FCT651's and ACT651's still being made but I haven't tried either of these on the IIcx

As for that IIcx schematic - it's on my (very long) list of stufff to do still

 

[Trash80toHP_Mini]

Ah well, don't really work from schematics anyway. You sent me a high res pic of the top layer of your IIcx board which will be a great start. Can you send me the same for the other layers, please?

Between those and the BOMARC schematic I should be able to lay out everything but the bridge to PDS on a board that'll fit my as yet to be determined form factor.

Not worried about transceiver cost for this. Everything is thought experiment, pretty pictures and form factor determination at this point. I can't imagine that switching to the avaiable TI active product transceivers will be too much of a problem if and when?

Most curious ATM about where the NuBus slot ID signal originates on the two machines and if the SE/30 board can be modified to support that second slot over a ground line PDS pin? If the signal is pulled low when offline An inverter could be utilized iin the other case. I'd think there'd be no problem? Passthru connector from the NuBus adapter would be sent back to standard ground line status.

Fun times, time to fire up AI again!

 

[Melkhior]

ATM about where the NuBus slot ID signal originates

NuBus slot ID are completely passive. On the motherboard, some signals are left floating (for 0, they're active-low), some are grounded (for 1), that's it.. So to create a slot $9, you ground ID0 and ID3 of the slot on the motherboard, and leave ID1 and ID2 floating.

On the NuBus device, weak pull-ups on all IDs.. They bring the floating signals high to register as 0, grounded signals are still registered as 1. And you know the MSb will be grounded for 1 (the valid range for slots is from 'b1001 to 'b1110, $9 to $E, so the MSb is always 1) so no need to bother reading it - saves one pin on the NuBusFPGA ;-)

The only thing to be careful on the motherboard (or adapter) is to match the IRQ lines used and the slot numbers, as they are implicitly associated by the software.

 

[Trash80toHP_Mini]

I forget if the IIsi NuBus Slot is $C or $D, but that's where the primary slot will reside. I'll pull the SE/30's Video ROM, hijacking the interrupt for SE/30 $E onboard video for the second slot. That leaves one interrupt available if I ever snag a GS card.

If the second slot works at $E it'll have the Futura SX Video/10bT combo there with one big screen and a higher end VidCard in the Primary NuBus Slot for a second big screen. Gotta wedge in the PowerCache adaptation for my P33 in at some point if the experiments are successful.

With the HDD smack up vertically aside the PSU per the Gamba diagrams so that there's enough room for all three cards and vertical Passthru to GS on the postage stamp display or my High Res SE/30 card for a third screen.

 

[Melkhior]

I forget if the IIsi NuBus Slot is $C or $D, but that's where the primary slot will reside.

Actually it's likely $9, as that's the one you use for pseudoslot in PDS and that has a matching IRQ.

I'll pull the SE/30's Video ROM, hijacking the interrupt for SE/30 $E onboard video for the second slot.

I'm not sure what you try to achieve overall. The SE/30 exposes three pseudoslots on the PDS, $9, $A, and $B, all with matching interrupts. There's nothing stopping a NuBus adapter from implementing all 3, although that would prevent using a pseudoslot PDS device at the same time. As long as you're happy with just 3 devices, you can probably implement any combinations of 3 slots - PDS $9, NuBus $A & $B would be the safest option I suppose for PDS devices hardwired to $9.

The SE/30 as a complete VIA2, so in theory you could break out the IRQ signals from $C and $D (assuming internal video uses $E) that aren't on the PDS slot and gain an extra two potential slots, but that would require some modifications on the motherboard. Or revisiting a 'reloaded' SE/30 motherboard to expose the signals 'properly'.

EDIT: by '3 devices' I mean '3 vintage cards following Apple's specs'. There's nothing stopping you from implementing multi-functions cards to avoid the issue altogether (you mention the dual-function Futura SX already). The NuBusFPGA shares the one IRQ line between the FB and the RAM disk (when using DMA bus-mastering), plus the IRQ-less audio-over-HDMI device, and there's no reason why one couldn't implement a similar device with dual-head (or more!) given enough pins for the HDMI connectors & memory bandwidth to support the framebuffers.

 

[Bolle]

Nubus cards on the IIsi adapter show up in slot $E but it's wired up to /IRQ1 which should be $9 according to the PDS pinout.
There's something special happening in the emulated VIA2 because PDS cards using IRQ1 will show up in $9 just like you'd suppose them to do.

 

[Melkhior]

That's very weird... From everything I've seen for NuBus devices, they are supposed to register their interrupt function via SIntInstall() specifying their own SlotID, so any NuBus device in that adapter would register for $E... Not very difficult to associate that to the 'real' interrupt for $9 one way or another, but it seems utterly insane to not just ID the NuBus slot as $9 in the first place ?!?

Apple, I guess...

Edit: mmm, are you sure about $E ? DCDMF3 claims the IIsi NuBus slot is at $9 (Table 7-1 page 133) ?!? $E is normally used for the internal video.

 

[Bolle]

Pretty sure but I better check again...

 

[Bolle]

Nevermind, not sure what I was remembering. Just popped an ethernet card into my IIsi and it shows up as $9 just as expected.

 

[Trash80toHP_Mini]

The SE/30 as a complete VIA2, so in theory you could break out the IRQ signals from $C and $D (assuming internal video uses $E) that aren't on the PDS slot and gain an extra two potential slots, but that would require some modifications on the motherboard. Or revisiting a 'reloaded' SE/30 motherboard to expose the signals 'properly'.

Looking at my new reloaded board would be what got me back into this craziness. Cut-n-patch on the exposed traces lends itself to such modification of the motherboard.

As for Interrupt/Slot ID pipe dreams:
Three is not really enough on the PDS as far as I'm concerned. A blank CRT doesn't bother me a all. I hated doing production work on the Compact Periscope of my SE since day one. VidCards of the day sometimes blanked the Compact CRT to achieve the FPD/TPD football field of dreams.

Major inspiration for the hijacking of $E would be the near universal Internal Grayscale obsession. That card does an end run around onboard video, freeing up $E for a second NuBus slot. One interrupt on PDS is traditionally occupied by NIC.

I'm lucky enough to have VidCard/Daughtercard NIC combos on hand for the single NuBus Slot scenario most folks aren't so blessed.

Three PDS interrupts:
#1 - NIC
#2 - GrayScale
#3 - NuBus
$E - Pulling Video ROM from MoBo, patching interrupt and second /NuBus control lines via hijacked PDS ground pins to jumpered connections on the NuBus adapter yields forth Slot on PDS? Hack would be easily reversible by removing jumpers and reinstalling the Video ROM, disengaging the second NuBus Slot.

Hijacked ground lines on PDS are connected back to ground upstream of adaptation on its passthru.

Dunno, that's how it looks to me in muddled state as I start on my second cup of coffee.

 

[zigzagjoe]

Have you tested your theory about making use of $E? Just removing the ROM only means Mac OS doesn't know how to address the hardware, it doesn't prevent the hardware from being addressed. You will run the risk of built in video trying to read or drive the data bus and control lines while addressing the card you've stuck in that same address space.

You might be able to pull some of the PALs to disable that, but that could have other knock-on effects.

If I might offer advice, you are suffering from a bad case of scope creep.... get a functional proof of concept first, then see about iterating to add more functionality rather than try to do everything in one fell swoop. Otherwise, projects tend to never get off the ground.

 

[Phipli]

What is wrong with using the other three slots for NuBus, why do you want $E?

Why not use a eMachines combo card to do 24bit video and ethernet on one card?

 

[Trash80toHP_Mini]

Nubus cards on the IIsi adapter show up in slot $E but it's wired up to /IRQ1 which should be $9 according to the PDS pinout.
There's something special happening in the emulated VIA2 because PDS cards using IRQ1 will show up in $9 just like you'd suppose them to do.

IIRC, IIci/IIsi internal video is implemented as PseudoSlot $E which started the tradition of hanging all kinds of crap at that address via the "additional decoding" method mentioned in the Designing Cards series.

Probably the craziest setup would be in the Duodock II where Video, Network, Modem and Serial Ports are implemented on the Docking Connector. The DuoDock is a multipurpose expansion card at $E with NuBus being an entirely separate subsystem. Cut power to the DuoDock's ROM and only NuBus and ADB remain active.

 

[Trash80toHP_Mini]

Have you tested your theory about making use of $E? Just removing the ROM only means Mac OS doesn't know how to address the hardware, it doesn't prevent the hardware from being addressed. You will run the risk of built in video trying to read or drive the data bus and control lines while addressing the card you've stuck in that same address space.

The only reason for the System to address the SE/30's Video Subsytem at all is the Video ROM/DeclROM being detected by the Slot Manager at startup. Folks have made your same point about the SE/30 somehow loading registers in the onboard video subsystem causing a problem, but very doubtful that can be the case.

Cannot imagine how such could happen as the Slot Manager only addresses slots detected via DeclROM. PseudoSlot at $E only becomes problematic with onboard video's introduction in the IIci/IIsi generation in the Mac II series.

Back to the DuoDock as a $E expansion card. Onboard Video/LCD display at $E is disabled in the DuoDocked state, replaced by Video Substem in the full size docks. MiniDock expands $E function to include support for its auxiliary video subsystem. One Hail Mary pass post-retirement will be replacing original DuoDock's ROM with MiniDock ROM.

The way I'm seeing it, pulling Video ROM will equate with a Docked State, leaving $E available for use via DeclROM on a Card, NuBus or PDS. The SE/30 has no idea that there is anything to load at that Slot Address/mapped memory without Video ROM detection.

 

[zigzagjoe]

The only reason for the System to address the SE/30's Video Subsytem at all is the Video ROM/DeclROM being detected by the Slot Manager at startup. Folks have made your same point about the SE/30 somehow loading registers in the onboard video subsystem causing a problem, but very doubtful that can be the case.

Cannot imagine how such could happen as the Slot Manager only addresses slots detected via DeclROM. PseudoSlot at $E only becomes problematic with onboard video's introduction in the IIci/IIsi generation in the Mac II series.

Back to the DuoDock as a $E expansion card. Onboard Video/LCD display at $E is disabled in the DuoDocked/MiniDocked, replaced by Video Substems in those docks.

The way I'm seeing it, pulling Video ROM will equate with a Docked State, leaving $E available for use via DeclROM on a NuBus Card. The SE/30 has no idea that there is anything to load at that Slot Address.

You are confusing the world as Mac OS knows it (software), and the reality of hardware on the LB. Now, without the DeclROM, as we both pointed out, Mac OS has no reason to read/write that address space. As you say, it doesn't know anything is there.

The point I'm making is removing the ROM does not prevent the video hardware from being addressed. You read/write to any address beginning with 0xFE or 0xFF, the video hardware thinks you are talking to it and it will try to handle it. This will happen regardless of any code because again, this behavior is implemented in hardware. So when you put a hypothetical nubus card in this address space, both the video hardware and nubus card think you are talking to them as they have no ability to co-exist, and things don't work.

Again: re-iterating the recommendation to start small and scale from there. There's no need to hijack $E. @Melkhior and @Phipli have established a good case for basic interface compatibility with minimal glue logic, so try to get your chipset working and a single slot before you worry about more.

 

[Trash80toHP_Mini]

Again: re-iterating the recommendation to start small and scale from there. There's no need to hijack $E. @Melkhior and @Phipli have established a good case for basic interface compatibility with minimal glue logic, so try to get your chipset working and a single slot before you worry about more.

Absolutely, positively!

The point I'm making is removing the ROM does not prevent the video hardware from being addressed. You read/write to any address beginning with 0xFE or 0xFF, the video hardware thinks you are talking to it and it will try to handle it.

If the Video ROM is pulled, there is no video hardware in that machine state for system software to try to handle as it no longer exists in mapped memory at startup, no?

 

[cheesestraws]

If you pull the video ROM, you're doing the equivalent of pulling the declrom on a PDS card. If you write to the address space that the card occupies, it still gets the reads and writes regardless of whether the ROM is there or not.

You could, in theory, pull the video ROM then load the contents of the video ROM off disc, and the machine would work fine.

 

[zigzagjoe]

Absolutely, positively!


If the Video ROM is pulled, there is no video hardware in that machine state for system software to try to handle as it no longer exists in mapped memory at startup, no?

DeclROM is a mechanism to tell Mac OS hardware is present, how it is addressed, (typically) initialize the hardware, and provide code/resources/etc for Mac OS to facilitate it interacting with the installed hardware in an intelligent manner.

So without the DeclROM, yes, Mac OS won't try to do anything productive with that address space - it doesn't know how nor does it have a reason to - but nobody told the video subsystem to go sit in the corner and not talk to anyone. You could write a bit of assembly to initialize it post-boot if you really wanted to and push bytes into video RAM and have them appear on screen. This is effectively what FreeBSD and linux do, though they borrow the fact the ROM/Mac OS has already run the video initialization sequence.

Your issues lies in that - skipping a few steps for legibility - when a new DeclROM is present in that space belonging to a nubus card, when SlotManager tries to read from the DeclROM, the video hardware is going to try to service the CPU's read request from the (nonexistant) Video ROM while your Nubus card presumably tries to fulfill the same read request from its declrom. This is a Bad Thing.