-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
NuBusFPGA: HDMI on NuBus Macs
- Thread starter Melkhior
- Start date
It is a bit of feature creep yes, the SBusFPGA already has half a dozen different peripherals you can bake into the gateware, including 4 variants of the framebuffers... and it doesn't even have proper video output
NuBus is intended more as a prototyping platform than as a 'product' or something directly usable. The cost is quite high.
Also just to nitpick - being the only NuBus device with digital output that I know of (DVI was introduced in 1999, long after NuBus), it was the fastest since day one ;-) More seriously, what's really missing on that side of things would likely be GWorld support, but that's way too much software to figure out... QuickDraw was fast for the day, but wasn't particularly modular in design.
In my current draft, to avoid too much 'components creep', the Ethernet part would be on an external plugin (a PMod extended to 12 signals) that could have multiple potential functions.
Thanks for the offer - but @olePigeon beat you to it at least for 10BaseTI've got one each 10bT and ThinNet daughter card NICs to match. IIRC, there's a thread on bbraun's site where he explained to me how the VidCard/NIC function was decoded from a single NuBus address. When I get back in town I can dig 'em out to post pics of the two NICs if you're curious, M? Glad to see you're back and at it again!
Those are rather neat devices. I'm not sure they were ever sold over here.Thanks! Lots of engineering has gone into those, for a market that probably wasn't that big. I like the cutouts in the main PCB and brackets to accommodate the upside-down RJ45 without breaking the width limit, and the associated plastic plug is a nice touch. I wonder how many they actually sold for such efforts!
pl212
Active member
I owned a IIsi back in the day and yes, I think this card would have been really compelling if it was in the office and not at home (still had LocalTalk there!). But agree the cost could have been an issue. I only became aware of this kind of card very recently, as part of a project to scan and categorize old ads. It’s the only thing that is in both the “networking” and ”video card” categories!The IIsi could also use one of those, but its intended market segment probably didn't want to spend big bucks on a combo expansion device at the time - and a PDS version would be faster anyway. Nice solution in search of a problem? And yet they have just become the NuBus device I most want
Early prototype pushed, I can hear the system beeps & SimCity 2000 audio coming from the HDMI monitor
(for now, only 44.1 KHz stereo signed 16 bits is supported, so the mac has a lot of conversion to do, I should add HW support for vintage Apple audio like 8-bits unsigned ).Apple's documentation isn't great, but they must have known; there's an article of 'develop issue 20' dedicated to the subject. It's nowhere near complete enough (the interrupt stuff is rather critical yet barely explained...), but while the MacTech website doesn't have the source code anymore, it was put on the "Apple Develop Bookmark CD 21". That's the bit that's really needed, as it gives you a full component that just call back into the standard component. So you just need to replace that by the real HW stuff (and figure out the HW interrupt... fortunately been there, done that for the RAM disk) to get something that works.
Also, you need the old 'Sound' control panel in 8.x (which Apple does provide in the Extra folder!) to change audio source - "Monitor & Sound" can't do it, apparently. Or maybe you need to add something else to the component to make that work? Couldn't find a clear answer in the documentation...
Latest update; audio also works with 8-bits signed/unsigned. It probably doesn't save much CPU work, as the bulk is likely in the frequency conversion from Apple's 22.254 KHz to the 44.1 KHz (could be 48 KHz) used by HDMI. I'm sure it's something that can be done well in a FPGA, but I have no idea how to do it in my design. Haven't figured out the 'proper' way (if any!) for MacOS 8 to change audio output without installing the old 'Sound' control panel...
On a different subject, I got the SBusFPGA to use an external Flash NOR chip using QSPI (in a custom PMod) as an external PROM storage. Should be possible to do the same with an hypothetical revised NuBusFPGA (the pin count is the issue! so many interesting I/O devices, so few pins...) for an easier-to-update ROM. Or, as Flash NOR are fairly cheap in the 16-64 MiB range, it could be used as a bootable ROM disk, using the RAM disk as temporary storage.
On a different subject, I got the SBusFPGA to use an external Flash NOR chip using QSPI (in a custom PMod) as an external PROM storage. Should be possible to do the same with an hypothetical revised NuBusFPGA (the pin count is the issue! so many interesting I/O devices, so few pins...) for an easier-to-update ROM. Or, as Flash NOR are fairly cheap in the 16-64 MiB range, it could be used as a bootable ROM disk, using the RAM disk as temporary storage.
Phipli
Well-known member
Have you considered adding I2C for "toy" peripherals? Many addresses on a small number of I/O pins. You could implement stackable add-on cards
You could literally add hundreds of devices as long as they weren't transferring huge amounts of data. Storage, serial, ethernet, WiFi, port expanders... other stuff.
I have; in fact there's an an optional I2C bus on the SBusFPGA with a NetBSD/sparc driver. I tested it with a couple of LM75-compatible temperature sensors, and everything seems to work fine. I2C is easy in hardware indeedHave you considered adding I2C for "toy" peripherals? Many addresses on a small number of I/O pins. You could implement stackable add-on cards
You could literally add hundreds of devices as long as they weren't transferring huge amounts of data. Storage, serial, ethernet, WiFi, port expanders... other stuff.
The real trick is the software side. NetBSD has a full I2C infrastructure, and the betrusted-io I2C core I use is a wrapper around an OpenCores implementation, which has an OpenBSD driver already. So creating a working driver for the controller wasn't too hard, and the device drivers (like for the LM75) are standard from NetBSD (just do 'envstat -d lmtemp0' and you know at which temperature your SPARCstation 20 is running! 30 years late for those super-hot SM52, but still...).
There's nothing on the System 7/MacOS 8 side of things that I know of. So one would have to create the entire I2C support, or a subset to target some specific devices... it would probably as much work, if not more, than directly supporting a new memory-mapped device (NetBSD/mac68k should be much easier as a straight port, still haven't got around to it).
The 'proper' solution would be to replace the daughter-board/carrier combo by a full-custom PCB that would include a high-pin-count FPGA, but (a) it would likely be even more stupidly expensive and (b) I still don't have the skills to design such a board (mostly properly handling one or two DDR3 devices and a proper power circuit, everything else should be much easier).
Phipli
Well-known member
If I remember correctly, some of the onboard peripherals on the logic board are I2C, but I think it was run from a microchip PIC that was bit banged from a via... but I have a terrible memory sorry.
My Acorn has a 1-Wire bus just asking to be used for fun projects. They used a 1-wire serial number component, it's even socketed I think.
Hello,
A year after the original V1.0 prototype, NuBusFPGA V1.2 is here (and on GitHub, of course):
The expensive and complex-to-program CPLD is gone, the expensive-and-pin-consuming VGA port is gone as well.
Instead, the board gains a micro-sd card slot, an expansion port (PMod but expanded to include 12 signals), and an extra 54 MHz clock so the HDMI can run Full HD at the precise 148.5 MHz and not approximated at 148.8 MHz
It's also a lot cheaper to build at JLCPCB than the previous generation had been at SeeedStudio.
So far...
A year after the original V1.0 prototype, NuBusFPGA V1.2 is here (and on GitHub, of course):
The expensive and complex-to-program CPLD is gone, the expensive-and-pin-consuming VGA port is gone as well.
Instead, the board gains a micro-sd card slot, an expansion port (PMod but expanded to include 12 signals), and an extra 54 MHz clock so the HDMI can run Full HD at the precise 148.5 MHz and not approximated at 148.8 MHz
It's also a lot cheaper to build at JLCPCB than the previous generation had been at SeeedStudio.
So far...
- NuBus is working (non-burst slave and burst bus-master for the RAM disk)
- HDMI with audio is working, including the new clock (with the 1/2/4/8/16/32 bit depth support, windowboxed lower resolution, and optional acceleration)
- RAM Disk is working
- A SPI NOR Flash can be connected to the expansion slot, to be used as the declaration ROM (instead of embedding the declaration ROM in the FPGA bitstream).
- The micro-sd card is proving harder to exploit than expected, so it's not working yet (it works in the SBusFPGA in NetBSD/sparc, and the RAM Disk driver works, and yet I can't combine the two into a working solution...)
- I haven't tried anything else in the expansion slot, although I do have a design for a RMII Ethernet - the hard part is likely to be the driver (SMII is another possibility requiring fewer signals). Another option would be to use the NOR Flash as a ROM disk, haven't tried that either.
cheesestraws
Well-known member
Whoa. Very nice.
nickpunt
Well-known member
Wow this is great @Melkhior ! I looked up prices for the USB-FPGA Module and there are several versions. Wondering which one is the right one to use? The cheapest is 2.13a (XC7A35T, $185), but there's other 2.13 versions (b through d) go up to about $360.
Other curiosity: 1920x1080 must feel small in MacOS 7-9, wondering if there's *anything* like a HiDPI mode or something that could be hacked with an extension so its effectively 960x540 but rendering everything at 2x.
Other curiosity: 1920x1080 must feel small in MacOS 7-9, wondering if there's *anything* like a HiDPI mode or something that could be hacked with an extension so its effectively 960x540 but rendering everything at 2x.
Last edited:
Phipli
Well-known member
There are things, like big menubar font patches, but the UI looks fine at those kind of resolutions.
Trash80toHP_Mini
NIGHT STALKER
So glad to see you're still at it! Way to go!
Thanks for the kind words
I though about integrating the FGPA, but it's above my skills levels. In addition to requiring a somewhat complex power subsystem and the Flash storage for configuration (plus a way to program it, JTAG is easy to have but hard to use), it also needs fast memory to support high resolution/high-depth framebuffer, so properly integrating the DDR3 module - the single 16-bits DDR3 at 400 MHz is OK, but doubling the bandwidth by using two modules for a 32-bits bus would be even better. So for now, I stick with a daughter-board for that part. HDMI signals are also high-speed (the differential pairs run at 742.5 MHz double data rate!), but there's only four pairs so that's reasonably easy.
For programming, ZTex has a simple java-based programmer over USB that's very easy to use. Alternatively, Vivado can also program the board through JTAG but it's much more complex. The Java programmer is convenient enough I didn't even populate the JTAG header on the V1.2 carrier (it's a 7-pins through-hole connector so fairly easy to solder if needed).
The 2.13a is enough, that's what I use. Larger ones would fit larger designs, but are probably not that useful for the price. They would fit a much larger acceleration engine or extra features, but so far the 35T hasn't been a limiting factor - adding the software support is...
I could let go 2 or 3 of them.
First sorry non-EU resident, I won't be able to ship outside the continental EU (Switzerland is probably OK as well).
However, please everyone be aware this is a prototype development board, not a product. You definitely need a ZTex 2.13 board to make anything out of it - without the daughter-board, it's useless (and currently this daughter-board is over 200€ including VAT! as @nickpunt mentioned). You probably need some experience with FPGA in general, and perhaps the Litex infrastructure in particular, to make anything out of it (at the very least you need to be able to program the FPGA in the daughter-board). Also, it has only been tested in my Quadra 650, where it is the only NuBus device - it may have/cause issue(s) in other machines and/or if other NuBus device(s) are present (capacitance, ...). Burst mode is not supported in Macintosh II computers, so some features (RAM Disk DMA mode) won't work or will need rework in them (all Quadra should support burst mode). It may also not respect all electrical requirements from Apple, which may have unexpected short-, mid- and long-term consequences for the board and its host. I highly recommend not considering such a board unless you really know what you're doing, and accepting the risks (the entire design is on GitHub for anyone to double-check the design). Caveat emptor and all that. And this is a toy/hobby thing, moving forward on a 'available free time' basis, and comes as-is with no dedicated support. If I didn't discourage you and you still want to try one, PM me.
Alternatively, as I said the entire design is on GitHub including the production file i sent JLCPCB, so one option is to order the PCB or assembled PCB directly. It's not the easiest of design to bring up, so I recommend against it unless in addition to the above, you're really comfortable playing with PCB. Again, I can't offer proper support.
I though about integrating the FGPA, but it's above my skills levels. In addition to requiring a somewhat complex power subsystem and the Flash storage for configuration (plus a way to program it, JTAG is easy to have but hard to use), it also needs fast memory to support high resolution/high-depth framebuffer, so properly integrating the DDR3 module - the single 16-bits DDR3 at 400 MHz is OK, but doubling the bandwidth by using two modules for a 32-bits bus would be even better. So for now, I stick with a daughter-board for that part. HDMI signals are also high-speed (the differential pairs run at 742.5 MHz double data rate!), but there's only four pairs so that's reasonably easy.
For programming, ZTex has a simple java-based programmer over USB that's very easy to use. Alternatively, Vivado can also program the board through JTAG but it's much more complex. The Java programmer is convenient enough I didn't even populate the JTAG header on the V1.2 carrier (it's a 7-pins through-hole connector so fairly easy to solder if needed).
Hehe, last line of my post
The 2.13a is enough, that's what I use. Larger ones would fit larger designs, but are probably not that useful for the price. They would fit a much larger acceleration engine or extra features, but so far the 35T hasn't been a limiting factor - adding the software support is...There was a discussion about pixel doubling previously in the thread, and in hardware it's theoretically possible but would require some major redesign of the framebuffer. In practice, the MacOS 8 interface is quite crisp and quite readable on a 22" LCD. I did speed up the mouse a bit
This time round, I took the chance of having all 5 boards populated, and I don't really need all 5
I could let go 2 or 3 of them.First sorry non-EU resident, I won't be able to ship outside the continental EU (Switzerland is probably OK as well).
However, please everyone be aware this is a prototype development board, not a product. You definitely need a ZTex 2.13 board to make anything out of it - without the daughter-board, it's useless (and currently this daughter-board is over 200€ including VAT! as @nickpunt mentioned). You probably need some experience with FPGA in general, and perhaps the Litex infrastructure in particular, to make anything out of it (at the very least you need to be able to program the FPGA in the daughter-board). Also, it has only been tested in my Quadra 650, where it is the only NuBus device - it may have/cause issue(s) in other machines and/or if other NuBus device(s) are present (capacitance, ...). Burst mode is not supported in Macintosh II computers, so some features (RAM Disk DMA mode) won't work or will need rework in them (all Quadra should support burst mode). It may also not respect all electrical requirements from Apple, which may have unexpected short-, mid- and long-term consequences for the board and its host. I highly recommend not considering such a board unless you really know what you're doing, and accepting the risks (the entire design is on GitHub for anyone to double-check the design). Caveat emptor and all that. And this is a toy/hobby thing, moving forward on a 'available free time' basis, and comes as-is with no dedicated support. If I didn't discourage you and you still want to try one, PM me.
Alternatively, as I said the entire design is on GitHub including the production file i sent JLCPCB, so one option is to order the PCB or assembled PCB directly. It's not the easiest of design to bring up, so I recommend against it unless in addition to the above, you're really comfortable playing with PCB. Again, I can't offer proper support.
cheesestraws
Well-known member
Ahhh, damn brexit. Oh well.
I checked La Poste, and it turns out the UK is now 3 euros more expensive than continental Europe (as long as it's not one of the islands with 'interesting' custom status like Jersey & co), but there doesn't seem to be any other issue... so I guess if that's a cost/risk a UK resident is willing to take (might be some issues at customs for a weird PCB...), that's a possibility too. I was thinking more of the U.S. members (sorry...) and various oversea territories (France has a bunch of those!).
BTW, I highly recommend to install & test the software side of things (installing Vivado & Litex and generating a bitstream for the FPGA, installing Retro68 and generating the Declaration Rom, installing the ZTex programming software) to make sure you can actually use the board, and then check that you can buy the ZTex FGPA board (the company could run out, what with the component shortage and other issues), and only then buy (or make!) the NuBusFPGA carrier.
Again - a development platform, not a product :-/
