68030 accelerator for the Macintosh Portable, redux.

[Trash80toHP_Mini]

It likely just remapped them to different addresses. Though it didn't seem to me that it had any DMA capability so I don't think accelerators would have worked in it.

That I figured, was wondering about available interrupts?

On the SE version, you actually got four slots.

SE/30 version?

 

[SuperSVGA]

That I figured, was wondering about available interrupts?

I'll have to check, maybe I'm remembering wrong about DMA/bus mastering but I do remember it only had 3x 74HCT245s on it, I'll have to double check what those were connected to though.

SE/30 version?

No, the SE version which had SE PDS slots. The SE/30 version had 4 or 8 NuBus slots.

 

[Froggy814]

That one never got much coverage in the day. I wonder how Second Wave managed to address two SE Cards? Then again they were Masters of Black Macintosh Magic, capable of transmuting a single NuBus Slot into three or six!

The Second Wave ExpanSE SE/30 version is a Blue-Eyed Ginger Unicorn, seen once on eBay, but never touched. Auction pics are floating somewhere around these parts.

Expanse setup for the Portable is a friggin' ALBINO UNICORN! Its close relative may have once been spotted in a Squatty Potty commercial, but the Portable version has never been seen available for sale anywhere at any time to my knowledge.

Tangent alert! - Interesting DuckDuckGo/AI tidbit:

The “Second Wave ExpanSE NuBus adapter” is the key detail: a NuBus adapter for the SE/30 has to speak the SE/30’s memory/bus timing correctly (and physically fit), and many adapters designed for other models won’t. In practice, the compatibility problem is usually the NuBus controller (“NuChip”) generation and which bus-cycle type it expects—the SE/30 uses a different CPU/bus/memory-controller behavior than the machines those NuBus adapters were originally built for. 68kmla.org

What this means for your “Second Wave ExpanSE … for SE/30” question:

• If the adapter was specifically made for the SE/30 (correct NuBus controller + firmware/signaling + correct PDS mechanical interface), it should work as a normal “get a NuBus slot” solution.
• If it’s an adapter intended for an IIsi/IIcx-era NuBus environment (or otherwise not explicitly documented for SE/30), it’s at risk of failing to bus-master or reliably operate due to the NuBus controller / bus-cycle mismatch discussed above. 68kmla.org
• Also, the SE/30 doesn’t natively have NuBus—so you’re always depending on a compatible PDS-based (or otherwise adapted) solution.

If you paste (or photograph) the exact model/part number printed on the adapter (and any “NuChip” markings you can see), I can tell you whether it matches the SE/30-compatible style or whether it’s likely to be one of the “won’t talk correctly” variants.

Interesting, more and more searches are being traced to some lunatics posts hereabouts?

Didn't know it was that rare!!!!!

 

[Builder68]

Saw it, didn't think the Vandal setup was necessarily pertinent to Performer hacking?

I initially thought the Vandal setup would be crucial for the host bus driver control logic, especially to handle higher clock frequencies. However, it turns out that logic is much less complex than I first imagined (though it would be nice to see the implementation applied to the Vandal, just as a sanity check).

If I stick with a phase locked clock strategy, rewriting the U4 PLD state machine should just be a matter of increasing the stage counter from 2 to 3 or 4, depending on whether I set the clock ratio to 3:1 (21.5 MHz) or 4:1 (31.33 MHz).

By keeping the original phase locked strategy, achieving an enhanced version of the Performer seems quite attainable.

The hardware impact would involve removing the 74245s (if the fast RAM expansion board from the TS Mercury 030 is integrated) adding a PLL multiplier, three 74574s, two 74646s, an additional G16V8 PLD, and upgrading the U4 PLD to a G22V10, plus a bunch of termination resistors for the RAM control signals and the RA lines coming out of the 74257s.

The additional G16V8 has enough room to also accommodate the logic for a SCSI interface and even the OE signal for the ROMinator.

There is also a fair chance that it could handle extended RAM. However, this largely depends on whether Virtual is able to recognize a 4MB bank starting at $0100 0000 without patching.

It would be the perfect accelerator match for the 512Ke, an all-in-one, one-time upgrade.

The PCB layout for the 16 MHz version could be something like this:

 

[Trash80toHP_Mini]

Now we're talking! Nice work figuring a possibility for grafting a new front end onto Performer. Is that SRAM cache or DRAM stretched across the bottom of your Mercury modeling?

 

[Builder68]

Now we're talking! Nice work figuring a possibility for grafting a new front end onto Performer. Is that SRAM cache or DRAM stretched across the bottom of your Mercury modeling?

Thanks!

Its dimensions fully comply with the constraints stated in the 'Physical Design Guide for Macintosh SE Cards' chapter of Designing Cards and Drivers (Inside Macintosh Library). It should fit nicely on any of the early Macs. It's not just a front-end; it's a full project that is almost ready for generating Gerber files.

As for the board, those are EDO RAM ICs (16-bit x 1024 bits), though I could eventually swap them for a single 72-pin SIMM socket to support a 16MB SIMM of the same chip. Although SRAM would reduce the PLD chip count, I haven't found anything suitable in 16-bit with the right density.

There are some big questions I need to answer regarding the extended RAM and Virtual before making a PCB run.

For instance, I haven’t been able to find anything about the accelerator profile parameters stored within the software.

It clearly uses some sort of memory layout table based on the 68030 brand/model.

It seems very logical that boards like the Gemini Ultra and the Vandal locate all the fast RAM space contiguously in a single block starting at a predefined address above the first 16MB block; this starting point might vary depending on the model chosen during installation.

Also, do some accelerator models enable the system RAM and the fast RAM at the same time?

If so, the application must have a profile table where this mapping is reflected. This would confirm that it could effectively configure the MMU while handling physically discontiguous RAM regions.

I’ve been monkeying around with ResEdit and AI assistance to locate those configuration tables inside the code, but with no luck so far. (It's not my forté)

I just want some assurance that the utility is smart enough to discover this 4MB extended RAM block and merge it with the 4MB of fast RAM located in the early Mac memory map (i.e., by writing the MMU parameters accordingly).

Even after 30 years, I still get the impression that this program is some sort of dark magic.

Does any one of the software guys here have gone down that rabbit hole and have something to share about the inner workings of this software?