My nubus pipe dream

sircabulon

Well-known member
I will start by stating - I know this is a stupid request and using any sort of Quadra would be easier, cheaper, or whatever.
My late father had a IIcx that was modified with a CPU riser to have a Mobius Speedster with an LC'040 chip on it. Unfortunately, I have lost that accelerator to time, but I still have the IIcx and the SuperMac Spectrum 8 Series ii. Fortunately, I do have a IIci... and now a Carrera 040. Feeding my nostalgic addiction, getting a Thunder II GX in there woud be the total chef's kiss.
This has me thinking.
I can get a new production logic board.
I can get a new prodcution Carrera 040.
I can get new production ROMs.
I can get new production RAM.
I can get new production Power Supplies.
We have to be able to make new production video cards somehow. I have a few video cards, but I want the best one in a fun color or something.
 

Melkhior

Well-known member
We have to be able to make new production video cards somehow
There's already some, both in the "fast, high-res, expensive, somewhat complex to setup, and purely as prototypes" (my own *FPGA range, complete with switchable resolution and depth up to Full HD in 24 bits), but also much easier to acquire/deploy based on an older chipset but for now only for for the '030 PDS slot (the 30Video, for SE/30 and IIsi).

Incidentally, there's nothing that would prevent adding a PDS slot compatible with the IIsi or SE/30 in a IIcx/IIci reproduction board (maybe the exact slot will be an issue in the IIci if it conflicts with the onboard video, can't remember which pseudo-slot it uses). Just need ot be careful with the new routing to preserve signal integrity.
 

zigzagjoe

Well-known member
Melkhior covered it well. My 30Video cards work well for 030 PDS, and have reasonable capabilities for what those machines can do, however I don't have a huge amount of interest in tackling Nubus as there's already a surfeit of vintage framebuffers (non-accelerated) with similar capabilities for nubus. I flirted with making a CPU socket 30Video card for my personal IIcx board, pretty sure I could do the same with IIci cache slot however there's far better things to put in those slots. I may make a LC version at some point but that's probably the end of the line for the epson chip I'm using.

The particular wrinkle is if you want "the best" nubus video board then you are asking for a fully-accelerated high-resolution card. This is not a trivial ask: it's hairy to implement (to say the least) and essentially requires either bespoke ASICs (or a FPGA ;)) to do so as commodity video chipsets with an acceleration engine don't handle much of what "basic" quickdraw acceleration entails. In many cases, such chipsets also don't offer the indexed 1/2/4 bit modes Mac OS and much vintage software want/require either; those modes had went the way of the dodo by the time highly integrated chipsets became common. There's also the difficulty of sourcing parts and finding documentation then electrically implementing such parts (most want PCI...)

So the FPGA route is likely the best path forward, but the majority of FPGAs with the requisite capabilities (as I understand them. I'm sure @Melkhior can expand) are not cheap, so even if you manage to satisfy all of the above requirements you still end up in the unenviable position of a new production product costing more that vintage video boards, making it hard to justify the effort outside of a pure passion project.
 

Melkhior

Well-known member
So the FPGA route is likely the best path forward, but the majority of FPGAs with the requisite capabilities (as I understand them. I'm sure @Melkhior can expand) are not cheap
Pedantically, the actual FPGA itself isn't super expensive, even going for Full HD as in the *FPGA. But you're absolutely right the cost is high anyway, because you also need the PCB to carry the FPGA and all the extra required stuff :-(

To support high resolution and high depth, you need a lot of bandwidth from the framebuffer memory to the FPGA. In my case, there's a 16-bit DDR3 chip running at 400 MHz DDR (so 800 GT/s, or 1.6 GB/s of bandwidth). You also need the complex power supply for the FPGA (including sequencing and a ton of capacitors), some flash for programming, some clock(s), i.e. all the stuff you need for a FPGA board. For Full HD, a very experienced PCB designer might make it work in 6 layers, but Xilinx suggests at least 8 layers for the 7-series, and that will be *expensive* for small orders, and makes for expensive board to buy off-the-shelf. And you're likely to need components on both sides, also driving the cost (though some have managed to do everything one sided). If you want HDMI, a 7-series Xilinx which support the required TMDS signaling is a massive plus... Xilinx ain't cheap. DisplayPort might also be doable, but it's a lot harder to implement than HDMI.

If you don't need Full HD @ 24 bits, a Spartan-7 would likey be enough, and a slower DDR2 interface could do - 16 bits wide at 200+ MHz is probably quite enough for a reasonable framebuffer that would have high-resolution or high-depth but not both at once.

Unfortunately, you also need a ton of pins to interface to the bus (NuBus, '030 PDS, '040 PDS). And for now, I haven't found a board that would carry an adequate Spartan-7, memory, and enough I/O to make a cheaper "sandwiched" version of the NuBusFPGA. I ended up with the ZTex because it had all that, wasn't super expensive at the time (it's become a lot more expensive since), and could be powered from only 5V directly (a lot of board will need a good 3.3V supply at least).

The ultimate option would be to integrate all the components on the NuBus (or '030, ...) itself. However, my PCB design skills are not at the required level - I have tried (more than once!), but the DDR and power are beyond my level.

Also not matter what, my design requires some fairly expensive CB3T level shifters.

Ultimately, I think the best option for a full PCB redesign would be to add a '030 PDS to a IIc*-class recreation. It would likely enable a bunch of vintage devices, plus the 30Video, the SEthernet/30, the IIsIFPGA, and is going to be a lot faster for video than NuBus (the IIci cache slot doesn't count, as it doesn't have the interupt line so isn't easily usable for most devices including video).
 

sircabulon

Well-known member
I think I am understanding this correct - We could re-design a reproduction board for a IIci to have the cache slot and a 030 PDS that could then use the 30Video as referenced and that may be easiest?

What would making a clone of the Thunder card look like?

On a complete tangent, my other thought was to see if a single board computer for Macintosh would be attainable. I have seen them for Amiga's but figured there is some Apple ROM magic that keeps it from being viable.
 

uyjulian

Well-known member
In terms of hardware, I think the hard part is interfacing with the PDS, NuBus, or PCI interface.

Pretty much many modern SoCs and even the RP2040 can output HDMI. Interfacing is the hard part, since nowadays communication has transitioned from low clock speeds, many pins (e.g. 32+ for NuBus or PDS), high (5v or 12v) voltage to high clock speeds, few pins (e.g. 18 pins for PCIe x1) and low (1.8v or 3.3v) voltage.

In terms of software, if not implementing QuickDraw3D or OpenGL, it would require invasive hooking and would take a while to iron out the compatibility issues. One idea I was thinking about for offload is running the existing e.g. QuickDraw functions but running them in a faster (emulated) environment, instead of reimplementing them. This would get around the slow PDS/NuBus speeds in case where the textures and code are smaller than the rendered output, or textures/code were already transferred and can be reused.
For an unaccelerated card, you don't need to do the above.
 
Last edited:

zigzagjoe

Well-known member
I think I am understanding this correct - We could re-design a reproduction board for a IIci to have the cache slot and a 030 PDS that could then use the 30Video as referenced and that may be easiest?

What would making a clone of the Thunder card look like?

On a complete tangent, my other thought was to see if a single board computer for Macintosh would be attainable. I have seen them for Amiga's but figured there is some Apple ROM magic that keeps it from being viable.

Yes, Melkhior was suggesting creating a IICi-class board with an 030 PDS due to the lower barrier of entry for PDS cards. That said the video issue remains, the epson chip I use on the 30video cards is quite adequate, but it is at its limit with the boards I've made. To get something more capable you're back to square 1.

Thunder: Functionally impossible to clone due to lack of the ASICs (application-specific IC). Same goes for the majority of nubus cards - they use ASICs designed by the company that built them, they usually cannot be found unless a tray of chips found its way into the wild somehow. Even so, it's a dead-end once those chips run out. A scratch implementation is really the only sustainable way forward.

SBC wouldn't be impossible, and I believe efforts to that end targetting the Plus are nearing completion. The problem is not that the ROMs are protected, you need to pretend to be apple hardware well enough that the ROM doesn't freak out. For example, a major hurdle that plus group just cleared was figuring out how to fake a response from the SWIM chip enough to say "I'm here, nothing to report, leave me alone" so the ROM could continue booting past that. Same thing applies except worse to the later machines even if you're willing to entertain modified ROMs (essentially what Basilisk does).

In terms of hardware, I think the hard part is interfacing with the PDS, NuBus, or PCI interface.

Pretty much many modern SoCs and even the RP2040 can output HDMI. Interfacing is the hard part, since nowadays communication has transitioned from low clock speeds, many pins (e.g. 32+ for NuBus or PDS), high (5v or 12v) voltage to high clock speeds, few pins (e.g. 18 pins for PCIe x1) and low (1.8v or 3.3v) voltage.

In terms of software, if not implementing QuickDraw3D or OpenGL, it would require invasive hooking and would take a while to iron out the compatibility issues. One idea I was thinking about for offload is running the existing e.g. QuickDraw functions but running them in a faster (emulated) environment, instead of reimplementing them. This would get around the slow PDS/NuBus speeds in case where the textures and code are smaller than the rendered output, or textures/code were already transferred and can be reused.

You're right that low voltage signalling and lack of IOs for parallel buses are a major problem. But that's only the tip of the iceberg; below is a quick list of considerations for a basic framebuffer. If you managed to get a Pico on the bus, you're still going to need to implement everything (including the pico's side of the bus interface) to have a viable framebuffer, never mind acceleration.
  • Bus interface to host
  • Framebuffer memory
    • Framebuffer arbitration if using DRAM
    • DRAM controller / refresh
  • Display readout (to RAMDAC/digital)
    • CLUT for indexed modes
    • FIFO if using DRAM
  • Registers to control all of the above
  • Acceleration engine (*optional)
Funny thing is that Quickdraw acceleration *is* invasive hooking, that's part of the reason it's such a pain. @Melkhior implemented blits, you can check the NubusFPGA sources for an example of what that looks like. In general, each category of function to accelerate (lines, circles, rects, for example) requires essentially the same level of effort per each category to even begin implementing. You essentially hook the main draw function for that "category" and have to understand the stack frame passed to it (along with other fun pieces of quickdraw context) to even understand what the caller was asking Mac OS to do, and then you still need to figure out how you're going to accelerate it with your hardware.

QuickDraw3D I can't speak to, I would say it is probably even worse as there will be not any existing implementations' source to consult for pointers.
 

olePigeon

Well-known member
Would it be possible to make the NuBus slots 40 MHz? They could slow down 1/4 speed to 10 MHz or 1/2 speed to 20 MHz for NuBus 90. This would give it PCI speed & bandwidth for any new cards designed to take advantage of it.
 

Melkhior

Well-known member
I think I am understanding this correct - We could re-design a reproduction board for a IIci to have the cache slot and a 030 PDS that could then use the 30Video as referenced and that may be easiest?
That's one option, yes. If you go that way, might as well go all the way to 6 slots plus the cache slot :)

Basically, in the II, Apple defined 6 "slot area" (from $9 to $E, the 65k version of hexadecimal 0x9 to 0xE) and 6 associated interrupt lines for expansion devices, with one slot needed for the video. All subsequent '030 and '040-based Mac behave the same way, though the interrupt lines might not be present on some models.

NuBus slots all hardwire a few pins to tell the device which slot to use in the $9 to $E range, and connect to the appropriate interrupt line.
PDS slot don't have hardwired pins, instead Apple tell you which "slot area" to use (which will be hardwired inside the device itself) and connect the appropriate interrupt line. On some hardware (namely the SE/30 and IIsi), there's actually another 2 interrupt lines connected, so you can choose between three slots - that's why some PDS devices have a way to select the slot and you can stack them provided they use different slots.

There's nothing stopping you from having multiple devices on a card sharing the address space and the interrupt line, but the card has to be designed that way. It's a lot more difficult (and somewhat pointless) so try and get more than one card to share a single slot.

Most of the issue of doing something differently will be software rather than hardware (hence the expansion boxes that existed back then for some special use cases).

So when all is said and done, most '030 and '040 based Mac can have up to 6 such slots, minus the one used by the onboard video if it uses a pseudoslot design. So on a IIcx with 3 NuBus ($9 to $B) and no video, you can add back another 3 NuBus ($C, $D, $E, basically to get a IIx with easier-to-find memory), or replace up to three of the original ones by IIsi/SE/30 PDS while remainging software-compatible! The three PDS slot would need cards that can handle alternate slot area for at least two of them. Please note this is a *logical* view, signal integrity issue on the '030 bus might prevent three cards in parallel to work reliably at the *physical* level.

IIci cache slots are different as they don't include a interrupt line, and are not supposed to include device using slot area. So you can keep the cache slot with a cache card in it (or an accelerator). Again, signal integrity issues may appear with too many devices. AFAICT, there's no eason why you couldn't have a cache slot in a IIcx, other than potential software compatibility issue of the extra cache.
 

Melkhior

Well-known member
Would it be possible to make the NuBus slots 40 MHz? They could slow down 1/4 speed to 10 MHz or 1/2 speed to 20 MHz for NuBus 90. This would give it PCI speed & bandwidth for any new cards designed to take advantage of it.
Not easily. NuBus90 isn't actually "true" 20 MHz, it uses the 10 MHz NuBus clock (10 MHz 25%/75% duty cycle) for a lot of stuff, and only does data transfer using the 20 MHz (50%/50% duty cycle, so every other 20 MHz pulse matches a 10 MHz pulse). So it only improves performance for transfer of more than one 32-bits word... which are never initiated by the 68030 (they could be initiated by the move16 of the 68040, but that doesn't actually happen, as Apple didn't implement it).

So a faster clock using a scheme similar to NuBus90 would be as useless as NuBus90 on '030 and '040 Mac.Using a different checme would be much harder to make backward-compatible.

If you want a faster "standard" bus, the "easy" option is to use a Quadra, as there's a PCI bridge chip still available for the '040 bus! Huwever, they cost like 80€ each and would require a *lot* of software support, so that ain't happening anytime soon.

IMHO the best option is PDS, it's not too complex to deal with and it's as fast as it can get (anything else will eventually be limited by the CPU bus anyway).
 

olePigeon

Well-known member
@Melkhior Could you also mix in an LC PDS slot? You could use that slot for ethernet. LC PDS ethernet cards can still be had for just $15. Although I guess you could just integrate ethernet onto the motherboard. However, having a //e Card inside a II-style machine would be cool.
 

Melkhior

Well-known member
On a complete tangent, my other thought was to see if a single board computer for Macintosh would be attainable. I have seen them for Amiga's but figured there is some Apple ROM magic that keeps it from being viable.
The absolute bare minimum for a viable '030-or-later Mac is:
(a) a CPU - a purely a money issue, as MC68030 and MC68040 are available for Rochester, plus all the usual sources of vintage chips
(b) a memory controller and associated RAM - many alternate solutions available from SRAM to vintage async DRAM to SDRAM
(c) an ADB controller - there's recreated version to replace dead chips) for mouse/keyboard
(d) some form of storage connected to the SWIM (floppy) or SCSI controller - the 53C80 SCSI controller is still available
(e) some form of video - the IIsiFPGA or 30Video (or QuadraPPGA) are available
(f) the VIA chips for the various required support functions - some 65C22 are still being made
(g) address decoder for everything
Then you also want the serial ports (but the chip have recently been discontinued) and audio, but you can probably live without them at first. You may also want the SWIM, but if you have SCSI and a modern SCSI emulator device, floppies aren't needed (and floppies suck anyway).

In many Apple systems, a custom ASIC handle at least (b) and (g), and later ones accumulated extra functions.

Every component above could be either done with a "real" chip, or "emulated"/"simulated" somehow. But it's a lot of work. And for the CPU, there's no open source '030 with MMU support (mandatory) and I don't know of any working FPU (optional). The decoder is fairly complex but well documented globally.

One thing I've considered is to drop *every* chip other than the CPU, and just connect the '030 or '040 to a FPGA (the IIsiFPGA can already do the memory for instance), and emulate everything else in the FPGA. But one still needs to implement fully-compatible FPGA emulation of some of the chips (VIA, SCSI, ADB) and the decoder...
 

Melkhior

Well-known member
@Melkhior Could you also mix in an LC PDS slot? You could use that slot for ethernet. LC PDS ethernet cards can still be had for just $15. Although I guess you could just integrate ethernet onto the motherboard. However, having a //e Card inside a II-style machine would be cool.
For Ethernet, the SEthernet/30 would do (either the original or my more compact variant), or any NuBus Ethernet, or indeed just remove a slot and hardwire a SEthernet/30 on the motherboard (slot might be easier for routing the mobo PCB though).

The first issue with the LC slot is the 16 MHz clock needed for backward compatibility. If the main CPU is 16 MHz, it should be easy: logically it's just a different pinouts/form factor. However, if the main CPU is faster, then you need to add some magic to enable 16 MHz bus operation... The second issue is addressing. The LC slot is missing some address lines, and some device may misbehave in a multi-slots environment (answering to every possible slot for instance, as they didn't need to check in a real LC*).
And if the main use case is the IIe card, IIRC it only works in 24-bits mode? (never seen one, the II wasn't big in France so the LC card didn't have much success).
So overall, I'd say avoid the LC slot, "proper" PDS is better in every way.
 

sircabulon

Well-known member
I don't know how to say this - you all are incredibly talented and I am impressed. I was hoping to hear this would be a relatively easy task, and I am happy to know why it hasn't been done yet. Thank you all for the information and contributing to this community!
 

Jockelill

Well-known member
I’ve been building and tested most of @Melkhiors cards and I must say this is essentially the “best” performance you can get out of the Nubus, it is basically on par with the onboard graphics, but keep in mind this card does Full HD and 32bit color.

I recently made a somewhat simplified and in some senses improved version of @Melkhior’s Nubus card. Basically I have removed the USB and the sd slot and made a different mounting of the HDMI connector. This brings down the cost a little bit also, but you are still looking at somewhere around 400$ for a card.

There are some limitations with this card, it only works in 32bit mode and it mechanically interferes with its neighbor. Of course if you use the first slot this is a non issue. Also I can say for sure that you should have a 68040 CPU to be able to fully utilize this card (ok, the IIfx or any 50Mhz 68030 accelerator being exception). But if you do it’s definitely one of the fastest Nubus cards ever made.

As for speed, the PDSfpga cards are actually faster, but this Nubus card is of course still extremely useful in many machines. I use mine mainly in an accelerated IIci (Carrera), but also in my IIfx. It’s tested also in the 7100 and here you definitely see the true limitations of the Nubus. It’s actually a little bit slower than in the pictured Quadra.
 

Attachments

  • IMG_1298.jpeg
    IMG_1298.jpeg
    3.2 MB · Views: 43
  • IMG_1299.jpeg
    IMG_1299.jpeg
    1.7 MB · Views: 43
  • IMG_1297.jpeg
    IMG_1297.jpeg
    2.7 MB · Views: 43

Melkhior

Well-known member
does these support 1280x1024 also or only hdmi spec?
Depends :) There's two HDMI output variants (part of the FPGA bitstream, so you need to reconfigure the FPGA to switch between the two):
- one is 'true' hdmi (supports packets), so has an audio output going through to the display, but it can only do Full HD - lower resolutions are windowboxed
- one is really dvi-in-hdmi, something that looks like a digital version of VGA over a HDMI connector. There isn't any audio support, but in the latest version, the resolution can be changed 'for real' to output a true lower-resolution signal (windowboxed is also available at the same time).

Unfortunately, the resolution change isn't super stable for now, so sometimes you need to do a back-and-forth at a different depth to reset the signal as otherwise the image is shifted horizontally :-( I haven't found the root cause of the issue yet.
 

Trash80toHP_Mini

NIGHT STALKER
Ultimately, I think the best option for a full PCB redesign would be to add a '030 PDS to a IIc*-class recreation. It would likely enable a bunch of vintage devices, plus the 30Video, the SEthernet/30, the IIsIFPGA, and is going to be a lot faster for video than NuBus (the IIci cache slot doesn't count, as it doesn't have the interupt line so isn't easily usable for most devices including video).
Tangential maybe? Can't help but think of using such a beast in the Luggable! Driving it's LCD interface would be the major stumbling block.

Redesigning the existing SE/30 reload board to fit the Portable form factor is something I've discussed in PM, possibly in a topic?
 

Joopmac

Well-known member
Yes SE/30 board, or maybe even a lc475/630 in a Portable 5126 would be one of my dreams
Well a replacement LCD would also be Nice if 170 panel can be used

Yes keep Dreaming;)
 
Top