• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

Development of Nubus graphics card outputting to HDMI?

Melkhior

Well-known member
Darn, I finally realized why my approach cannot work as-is. SBus has a somewhat 'modern' electrical interface, and the driving strength of the FPGA is enough to talk to the bus through the 74CB3T shifters (which are bidirectional pass-through, they don't drive the bus by themselves, they just make sure the FPGA doesn't get more than 3.3V on its pins). I thought I could just re-use the same principle, but I can't. Hence, darn.

NuBus has much, much higher driving requirements - way above what an Artix 7 can do. So now I need level-shifters with proper drivers, and those tend to be either bidirectional with weak drivers (won't work), or directional - meaning extra pins from the FPGA to set the direction; and proper grouping of signals to minimize the number of direction signals (without conflict in group - a nuisance is TM0 which is normally grouped with TM1 but can be used on its own as an intermediate 'ack' signal in block transfer...). And I'm not even sure that would work for the arbitration signals, as basically they are driven and sampled simultaneously - thus perhaps requiring external logic... which will need to talk to the 5V bus, the very problem we're trying to solve.

It still would work 'reasonably' easily by giving up on block transfers (which were only introduced in Quadra and so not universally useful even if I could figure out how to initiate one in software, and 2x mode isn't even supported to talk to main memory in Q700 and Q900 [1], no idea about newer Quadras) and on Master mode (no more need for arbitration!), thus needing just one direction pin for AD as I think everything else would be unidirectional (CLK, RESET and ID are always inputs, and for slave TM* and START are inputs while ACK and NMRQ are outputs). But it's not very satisfactory - and Master mode could be useful...

5V tolerant CPLD might do the trick (as PAL are no longer a thing), but that would add a lot of complexity...

[1] Coincidentally, while the Q700 and Q900 boast 2x mode but only for nubus-to-nubus, the SPARCstation 20 I use for SBus boast of 64-bits extended transfer but it's only for sbus-to-sbus ; apparently Sun and Apple agreed it was easier to upgrade the standard and tell 3rd-party what to do than actually upgrading the system controller itself :)
 

demik

Well-known member
NuBus has much, much higher driving requirements - way above what an Artix 7 can do. So now I need level-shifters with proper drivers, and those tend to be either bidirectional with weak drivers (won't work), or directional - meaning extra pins from the FPGA to set the direction; and proper grouping of signals to minimize the number of direction signals (without conflict in group - a nuisance is TM0 which is normally grouped with TM1 but can be used on its own as an intermediate 'ack' signal in block transfer...). And I'm not even sure that would work for the arbitration signals, as basically they are driven and sampled simultaneously - thus perhaps requiring external logic... which will need to talk to the 5V bus, the very problem we're trying to solve.

5V tolerant CPLD might do the trick (as PAL are no longer a thing), but that would add a lot of complexity...

Ha yeah, using TXS0108 or similar will not help on a NuBus slot indeed. they perform poorly in push-pull situations and have weak drivers.
Only a few cards used block transfer IIRC. That would be a nice feature for sure, but maybe that can be added later.

For what it's worth, if the logic is simple enough, PALs are still around (check for ATF16V8 & ATF22V10). Dunno enough about 5V CPLD to suggest a candidate to regroup a few PALs (ATF1508 maybe ?).

If you look at page 226 of "Designing Cards and Drivers for the Macintosh", It describe how you an build some basic NuBus cards. Schematics are a few pages later. Equations are at the end of the document.
 

Trash80toHP_Mini

NIGHT STALKER
Not up on FPGA as complex ASIC stuff, just general systems connectivity from the day. But I feel the need to mention the Raspberry Pi Compute Module 4 as a possibility for this and many other current tech to retro-Mac I/Oish via Pi kinda projects.

All would be on one 68K carrier board/expansion card with NuBus connector and on top the 030 PDS connector for inverted playtime sans multiplexing. Driving the HDMI connector(s) is there if it can be dumbed down to programmable output VidCard utility. If not wide enough I/O on its pins for neolithic parallel bus interfaces, I'd think it would be fast enough for multiplexing such stone age signals in the 8-40 MHz range, no?

If not this one, rev 5 can't be all that far off?

/tangent?
 
Last edited:

uyjulian

Well-known member
If you are going to put Raspberry Pi on PDS, might as well port PiStorm to it.

But for graphic card probably better to start off with a simple NuBus card using documented examples like the Toby and BUG Pickles cards first.
 

Melkhior

Well-known member
For what it's worth, if the logic is simple enough, PALs are still around (check for ATF16V8 & ATF22V10). Dunno enough about 5V CPLD to suggest a candidate to regroup a few PALs (ATF1508 maybe ?).
Thanks for the pointer to PALs; indeed Mouser still carries those. But it seems you need a special hardware programmer, and the software seems nearly as vintage as the hardware we're playing with (at least the free stuff from Atmel).
I'm looking at a more 'convenient' (for me as I know only Xilinx tools...) CPLD ; Xilinx XC9356XL have 5V tolerant I/Os and have a regular JTAG port to program them. Less convenient that the on-board USB programmer of the Ztex, but I have the JTAG stuff already. And they have enough pins and 'programmability' that they should deal with the annoying arbiter stuff and shifting/direction of the non-AD signals ; for AD signals a set of 74FCT245 should do the trick.
 

demik

Well-known member
Thanks for the pointer to PALs; indeed Mouser still carries those. But it seems you need a special hardware programmer, and the software seems nearly as vintage as the hardware we're playing with (at least the free stuff from Atmel).
I'm looking at a more 'convenient' (for me as I know only Xilinx tools...) CPLD ; Xilinx XC9356XL have 5V tolerant I/Os and have a regular JTAG port to program them. Less convenient that the on-board USB programmer of the Ztex, but I have the JTAG stuff already. And they have enough pins and 'programmability' that they should deal with the annoying arbiter stuff and shifting/direction of the non-AD signals ; for AD signals a set of 74FCT245 should do the trick.

The XC9356XL looks like a good candidate indeed. The ATF can be programmed by a simple TL866 (at least ATF16V8B do), but yeah theses ATF need an old software to put equations in (WinCUPL)
 

Trash80toHP_Mini

NIGHT STALKER
If you are going to put Raspberry Pi on PDS, might as well port PiStorm to it.
Thanks for that info. Everything but the acceleration sounds good. I'm not a fan of stuffing a Pi in the face of our machines like that, better to go emulation if you want that kind of thing I think.

As a general purpose I/O development board such could be very handy indeed. Think of it as a huge, programmable ASIC Apple and developers never had the ability to do.

But for graphic card probably better to start off with a simple NuBus card using documented examples like the Toby and BUG Pickles cards first.
I've been pushing development from the Toby card/design example for a long time and am very excited about the BUG Pickles treasure trove.

However this is exactly what I was thinking about:
The PiStorm can also emulate a retargetable graphics (RTG) card, a common form of add-in card that gives an Amiga high-resolution and high-colour-depth capabilities. Better still, when configured as an RTG – a task that requires adjusting the configuration on both the Raspberry Pi and the Amiga itself – the video is output from the Raspberry Pi’s HDMI port, making it easy to connect your Amiga to modern monitors and TVs.
If this could work with the BUG Pickles drivers we might be onto something.

A general purpose I/O development platform as I've suggested could get the Pi gang involved. Throw an SE PDS connector on the back end of the board for three way development direction support. There has to be a lot of available hardware/software out there in the Pi community. I'd like to drop this now to avoid threadjacking.

/tangent
Love the info surfacing about the hardware availability/design tradeoffs for component requirements.
 

demik

Well-known member
Unfortunately the PiStorm won't work, because 1) NuBus, and 2) it does not support a 32 bit bus, which you need for decent performance.
Using the RPI as a GPU may be possible, but it's more complex than what @Melkhior is trying to do.

You will need a big FPGA to interface all of that, and when you are at that point, it's simpler to do the GPU into that FPGA anyway.
 

Melkhior

Well-known member
and for slave TM* and START are inputs while ACK and NMRQ are outputs)
Nope, only /NMRQ is a pure output ; /ACK has to be unasserted (meaning driven to 1, not left floating) by the master during /START, and there's also "attention cycle" where both /ACK and /START are asserted...

Anyway, some notes:
a) you can actually assemble a NuBus ROM from Linux using a m68k-gcc as proven by jaoswald/ns816-declrom;
b) you can compile C to MacOS binary objects using autc04/Retro68;
c) the BUG Pickles source code shows how to use C as part of a ROM with calls from assembly ; the one I tried (Pickles24V1.4) is a Think C 5 project but unfortunately seems to be missing the 'UserDef.h' header so cannot be rebuilt directly. It's still a super-useful source of information.

So you probably don't need to go 'full vintage' and write the ROM in MacOS - it's likely doable in Linux.

First attempt says, the XC9536XL-VQ44 has enough pins to handle all the non-/AD, non-/NMRQ signals (plus the FPGA side) and deal with /ARB* and directionality. Four 74FCT245 can do the job for /AD (using whichever packaging isn't entirely out-of-stock everywhere!), while a 74LVC1G07 can handle /NMRQ. And looks like this:nubus-to-ztex-3d-view.jpg
Simulation of slave mode through the CPLD and FCT's seems OK:
N2F_sim.jpg
The 'nub_*' signals (green waves) are meant to be NuBus, while the '*_3v3' signals (blue) are the connections between the CPLD/74FCTs and the Artix-7; at the start on the left for a short while everything is high-impedance before talking to the bus (as directed by the nubus_oe signal at the bottom). The 3 vertical blue lines delineate a write cycle then a read cycle at the same address, to a Wishbone SRAM - the wishbone signals in yellow are from the master side of a clock-domain-crossing Wishbone element (the Wishbone domain itself runs at 100 MHz). Subsequent write/read cycles use narrower request (half-words or bytes) to new addresses; the memory is uninitialized so some bytes come back undefined, causing the red stuff in the waves and the XXXX on some data lines. Out of sight is a read-only sequence to a Wishbone ROM initialized with a 'declaration ROM' (which is just a placeholder for testing).

Now, I need to convince myself this is likely enough to work to be worth the 400€ or so it will take Seeed to build me a couple of boards...
 

demik

Well-known member
Wow that's impressive. I didn't notice the VGA ctrl chip before. Is it some sort of CPLD of yours or an off the shelf part ?
I know the Basys 3 (Artix 7) board is doing this with simple resistor ladders. What's the gain from an external chip ?
 

Melkhior

Well-known member
Wow that's impressive. I didn't notice the VGA ctrl chip before. Is it some sort of CPLD of yours or an off the shelf part ?
Thanks. It's an off-the-shelf chip, an ADV7125 DAC.
I know the Basys 3 (Artix 7) board is doing this with simple resistor ladders. What's the gain from an external chip ?
No idea for the moment :) My testing Pmod for SBusFPGA uses a resistor ladder, but it only has 2 bits per color channel. Resistor ladders are common for up to 6 bits per channels, but I've not seen 8. I figured out I could use a proper DAC instead, but I actually don't know that it will work... one of the many, many unknown of that board (it's only my 2nd PCB design after the SBusFPGA...)
The HDMI chip is a TPD12S016PWR, for which I have a schematic for a cheap Artix-7 board I know work with Litex so it should be fine... if the much higher speed signals are OK.
 

Melkhior

Well-known member
Yet Another Iteration, turns out there isn't that much space to place connectors. USB is back to be micro-B instead of A, as on the SBusFPGA. And now there's some 3D view of the connectors.
nubus-to-ztex-3d-view.jpg
 

Trash80toHP_Mini

NIGHT STALKER
Wow, that looks sweet! Is your component library now complete? Did you get here with or without custom construction of unavailable parts? How many layers will be required for routing the PCB?
 

Melkhior

Well-known member
Wow, that looks sweet! Is your component library now complete? Did you get here with or without custom construction of unavailable parts?
It is complete, some stuff weren't in my local version of Kicad (old Debian, so not exactly up-to-date) but a lot could be found in more up-to-dates version or GitHub. Then I just double-check the symbols and footprints. Kicad's default footprints often have small pads, Seeed's DFA had me rework some stuff in the V1.0 of SBusFPGA because of that. Now I just always use the largest pads between Kicad and the manufacturer's documentation if I can find it.
The 3D symbols for the JTAG headers are not accurate, it's actually this one.
How many layers will be required for routing the PCB?
Unfortunately, back to four layers; the original design could make do with two, but the CPLD is a bit dense for that (and of course you can't have a clean unbroken ground plane, which I'm told is important).
 

demik

Well-known member
Redneck trick to put a CPLD that dense into a 2 layers is to use a adapter to make it a DIP-44.

Otherwise that's nice ! Just out of curiosity, are you starting with a XC7A35 or something bigger ? I see the FAN connector and AFAIK the 35 isn't hot enough to warrant a fan.
 

Melkhior

Well-known member
Redneck trick to put a CPLD that dense into a 2 layers is to use a adapter to make it a DIP-44.
Easier to just go for 4 layers :) Also the cost of the PCB is sort of dwarfed by the cost of assembly and parts. One of the argument in favor of a resistor ladder for VGA is the 12.50€ list price (quantity of 1) at Mouser for the DAC chip... I didn't realize until I added it how expensive analog chips are. The CPLD is only 2.70€ if you get the fastest one (probably not needed, but not much more expensive than the slowest).
Otherwise that's nice ! Just out of curiosity, are you starting with a XC7A35 or something bigger ? I see the FAN connector and AFAIK the 35 isn't hot enough to warrant a fan.
XC7A35 on the FPGA board I have, though they are available with the 50/75/100 as well. But a 35 is more than enough unless adding an heavy-duty crypto engine and/or a lot of acceleration to the framebuffer (even a 35 fit my custom VexRiscv core for the SBusFPGA's cg6 easily, if the crypto core is not present).

The 'fan' header is sort of just-in-case; some SPARCstation have borderline cooling (the 10 is famous for its overheating issue when fully kitted, the quad-CPU version was announced but never delivered because of that), and the stacked design of the SBusFPGA blocks airflow so I added a 5V fan header ; I figure it could be useful in a Mac as well. It could also be used if some NuBus signals needs a missing pull-up/down. The 3.3V/GND header is also there for emergency pull-up/down. I should also add some testing points to make using a logic analyzer easier, but I'm not sure where / how - and the 2.54" header to the FPGA board does give some reasonable level of accesses to its signals; ditto the large NuBus DIN connector.

... now that you've mentioned the fan, makes me think I should check how much power the 12V line offers, a 12V fan header could be useful as well (the 12V line on SBus is very limited in power). There's room on that board, might as well take advantage of it :)
 
Top