68kMLA Classic Interface
This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.
| Click here to select a new forum. | |
| NuTabby: A Modern NuBus Card | |
| Posted by: saybur on 2026-09-09 19:01:48 I've been having a blast playing around with NuBus and wanted to share some of the stuff I've been up to. First, the hardware:  This "NuTabby" board is just a RP2354B microcontroller (the 2MB stacked flash one) with a minimum of circuity to interface it to NuBus, plus a memory card slot and space for a future flash or PSRAM chip. There are no PLD/FPGA parts or other external decoder chips, all work is done on the microcontroller. As usual with Raspberry Pi MCUs the PIO units are the star of the show: two of those (plus one of the CPU cores to handle memory access) are all that's needed to juggle NuBus, leaving the rest of the chip available for user code.  I also built a little NuBus host with a Pico 2, mainly to avoid possible damage to my nice Macs during the (long) process of getting all the timing right. The thing is not remotely compliant with NuBus electrical rules but it was quite useful for testing.  NuTabby has no support for fancy NuBus features like block transfers or bus mastering, only basic single-word reads/writes plus /NMRQ interrupts. That said, I wanted to wring out as much performance as possible within those limits:
I've written some test software on the Mac side to confirm the basics are working. On my IIci using BlockMove calls I'm getting about 5MB/s transfer speeds. Same approach for RAM to RAM transfers was ~7.6 MB/s for reference. Watching on the scope the card is responding to reads on the cycle immediately after addressing, with about 5-7 idle cycles after that, which seems to validate the transfer speed math and the IIci as the bottleneck. PIOs have been delivering deterministic responses that should be in line with the spec; here's an example scope trace during a read operation, with CH3 as /START and CH2 the card's internal /OE for the control signal driver.  Sidenote, fun over/undershooting on the card driver. Slew rate limiting is on and the driver is set at the 2mA minimum, so I guess the next hardware revision could probably use some series resistors? I am not experienced in this area so if anyone has suggestions I'm all ears. I'm very happy with how this has been going so far, it's been a really interesting dive into a part of the Macintosh I don't have much experience with. Next steps are to finish verifying NuBus basics work, then it's on to interfacing with the Slot Manager, writing a system driver, learning DeclROMs, and filling in the many (many) unknown gaps in my understanding. And write a memory card/PSRAM handler for the RP2350. Just a couple more things to do still! 😆 Since it's 2026, I also wanted to note that what you see here is human work done by me. I obviously can't vouch for libraries underpinning the code, but all I personally use LLMs for is getting references to source materials, not problem solving. Not making a judgement about other people's decisions, it's just how I prefer to do my hobbies. Finally, this was my first try at silkscreen art beyond my spouse's doodles. The eponymous tabby:  I think JLCPCB did a pretty good job with that one! I'll try to keep this thread updated as work continues. | |
| Posted by: Trash80toHP_Mini on 2026-09-09 19:29:47 Fabulous! 😉 | |
| Posted by: Froggy814 on 2026-09-09 19:30:49 I like it! Good job on getting it "working"! (working in quotation marks because it is always a work in progress.) | |
| Posted by: uyjulian on 2026-09-09 20:59:15 Nice work! It looks like all the GPIO is used, so there is nothing free, such as DVI/HDMI using HSTX. | |
| Posted by: robin-fo on 2026-09-09 22:53:03 Cool! | |
| Posted by: stepleton on 2026-09-10 00:56:59 👍 | |
| Posted by: robin-fo on 2026-09-10 02:58:25 What bus buffers do you use? ’245? I‘m contemplating for quite some time now about doing something similar with an STM32… | |
| Posted by: Snial on 2026-09-10 03:35:45 Even though I don't have a NuBus Mac (and I have no space for one), this is very impressive! I suppose at a basic level it provides SPI/SD or USB access? Or does the USB port share pins with NuBus or SPI? It's obviously much easier to develop functionality on top of an MCU than an FPGA, so it could mean some really rapid modern product development. Things that spring to mind:
| |
| Posted by: lauland1 on 2026-09-10 07:18:36 A raspberry pi in mac...hmm...pistorm/emu68 port anyone? Graphics acceleration you say...I'm working in that direction. I've got a software only opengl stack (or two) in progress. Am planning on doing something rave (at least api) compatible. This could be used as a "de facto" standard for future m68k (and nubus ppc) graphics acceleration. The low end part would be generic enough to use various hardware like this, or fpga's, etc. I'm keeping the api's compatible with Apple's real ppc OpenGL stack. | |
Posted by: robin-fo on 2026-09-10 07:32:46A raspberry pi in macThis is not a Raspberry Pi SBC, just a Microcontroller… | |
| Posted by: lauland1 on 2026-09-10 09:25:20 "RP2354B". It would take a LOT of work (seriously), but in theory, the software could be adapted. This is Risc-V and the pistorm uses an arm version, so a lot of lot of lot of work. Having any risc cores, with accessible shared memory opens a lot of possibilities. | |
| Posted by: saybur on 2026-09-10 10:10:11 Thanks to everyone for the kind comments! Nice work! It looks like all the GPIO is used, so there is nothing free, such as DVI/HDMI using HSTX.Even with 48 GPIOs they went fast. After accounting for all the NuBus data/control lines and transceiver signals there were 7 left over. One of those went to a PSRAM chip select and 6 to the 4-bit memory interface. If you didn't use NMRQ that'd get you the 8 needed. Annoyingly, the HSTX peripheral is fixed to GPIO 12-19, smack dab in the middle of the range used for address/data. And the PIO on the RP2350 is limited to working with only 32 contiguous pins at a time, either 0-31 or 16-47. Basically means you're guaranteed to not have the full 32-bit bus available, unfortunately. The RP2350 is an amazing MCU for the price but IMHO it will never outclass a dedicated FPGA solution like the excellent NuBusFPGA. What bus buffers do you use? ’245?Exactly, just basic LVTH245s and 125s. I was trying to stick to common, cheap, and easy to source parts as much as possible. By my read of the datasheets these are electrically compatible with NuBus, but if someone more knowledgeable wants to comment on that I'd be interested in hearing. As for other MCUs, I don't know enough about the STM32 family to comment. I will say that at least on this chip I doubt it would have been possible without the PIOs. Modern microcontrollers have all kinds of interesting mechanisms that make cycle-accurate code hard to achieve. The PIOs really excel at that: it's like having a fleet of very small, very predictable PICs/AVRs at your disposal in addition to the big beefy ARM CPU. Even with that I still had to overclock the system to 200MHz to improve the timing margins (a modest overclock by RP standards, people run these things at crazy speeds). That said, I don't want to be discouraging, I'd be super interested in seeing what you come up with! Even though I don't have a NuBus Mac (and I have no space for one), this is very impressive! I suppose at a basic level it provides SPI/SD or USB access? Or does the USB port share pins with NuBus or SPI? It's obviously much easier to develop functionality on top of an MCU than an FPGA, so it could mean some really rapid modern product development.Honestly, going into this my main goal was just getting NuBus transactions working at all. Before laying out the board I wrote a PIO implementation I thought was doable, but this project has lots of elements outside my comfort zone and I wasn't confident that it would result in something more than a pile of PCB coasters! Now that it's functional, next goal is storage. It seems like it should be relatively straightforward to build out and could benefit from any extra throughput. NuBus is no speed demon but its got to be faster than the pokey SCSI implentations on the 68020/30 Macs. Less sure about 68040s or the first gen Power Macs, but one thing at a time I guess. As for the other stuff you listed, I imagine anything that could be done faster on a 200MHz Cortex-M33 is potentially on the table, with the (big) caveat that everything would obviously require software support written up successfully on both sides. The RP2350 doesn't have a ton of peripherals, but the SHA-256 accelerator might be useful for some purposes. USB on the board is set up just as a device at the moment, mainly to give me a UART during development. The USB controller on the RP2350 isn't anything special or particularly fast. | |
Posted by: uyjulian on 2026-09-10 11:06:13Even with 48 GPIOs they went fast. After accounting for all the NuBus data/control lines and transceiver signals there were 7 left over. One of those went to a PSRAM chip select and 6 to the 4-bit memory interface. If you didn't use NMRQ that'd get you the 8 needed. A couple of ideas I had for a different project potentially using RP2350: * Use 2x RP2350 communicating with each other, use 2x PSRAM chips, one receiving data from one RP2350 while another sending data to another RP2350, and a control channel e.g. UART for swapping between the two. This method can work around the missing QSPI device support. * Use one PIO using the first 0-31 I/O as the selection when hooking up the first 16 AD lines, and use another PIO using the second 16-47 I/O as the selection when hooking up the last 16 AD lines. The overlapping section at 16-31 will be the control lines both PIOs can access, allowing interleaved 32 bit burst transfers. | |
| Posted by: saybur on 2026-09-10 11:26:54 Two devices is probably the only answer with this type of MCU. Assuming you have a similar system architecture, you'd have a free PIO unit and could probably get a pretty good QSPI PIO implementation going, especially for a video card where all you'd care about is pushing data into the card as fast as possible. Use one PIO using the first 0-31 I/O as the selection when hooking up the first 16 AD lines, and use another PIO using the second 16-47 I/O as the selection when hooking up the last 16 AD lines. The overlapping section at 16-31 will be the control lines both PIOs can access, allowing interleaved 32 bit burst transfersWhat I did was set it up so /AD0-31 sits on 0-31 and /AD16-31 and control sits on 16-47, then synced units via interrupts. From a simplicity standpoint that might be easier than trying to keep two MCUs in lockstep, then keep video on the second chip exclusively. If you try out your approach definitely post something, I'd be very interested in taking a look! | |
Posted by: zigzagjoe on 2026-09-10 12:52:44.... I did some investigation of this with a nubus development card with a pico, and later, my NuCF cards. I found that most of the performance gain with a programmed IO approach was more due to cutting out the SCSI Manager stack so random/small sector IO improved significantly. Kind of like going from a SATA SSD to a NVMe drive. Not a lot of CPU time to go around so these results made sense. I am sure there is some additional benefit due to cutting out the SCSI emulator itself, but I never measured how much it contributed. Sequential performance was, of course, much faster, but that's of rather little real-world use; that random IO improvement is what makes Mac OS more responsive. On 030 class systems, programmed IO was reasonable to use if you can do 32 bit transfers, especially given DMA would just pole-axe the 030 anyways. On the 16mhz bus systems the nubus transfer rate is abymsal due to poor alignment between 16mhz system bus/10mhz nubus during the neccisary double synchronization. Quadra 650 was *much* better and more or less maxed out the potential of 10mhz Nubus, real world performance agreeing with that 5-6mb/s number you mentioned. I hadn't looked at the Nuchip30 systems (IIci, etc) but I would hope they fall somewhere in the middle. On 040 (presumably first generation power macs too), there wasn't a huge benefit in random IO as compared to the built-in SCSI. Larger CPU caches side-step the issue with SCSI Manager being phat and the 53C96 SCSI controllers (even without DMA) are much more capable. For these systems, in my opinion, there is little point in nubus storage if the goal is to improve speed, unless you can manage DMA since it does not completely halt the 040. I started to prototype a more advanced NuBus storage card (that was always the goal with NuCF, anyways) but ended up drifting to other projects as those results made me less interested. The nubus attached Pico wasn't my cup of tea either so it also fell by the wayside. My thinking was the RP2xxx would be best applied for new and interesting interfaces (audio!) and as a specialized coprocessor (TLS?) since video and storage weren't really killer applications for it. Don't let me stop you though, here's my example DeclROM / Driver for storage, may it be helpful 🙂 Edit: I appreciate that you dithered your cat picture, I had no great success with that and a black cat 😛 | |
| Posted by: olePigeon on 2026-09-10 13:07:56 I heard a rumor that @saybur originally created a Ginger Cat card, but it didn't have enough memory to do anything. | |
| Posted by: lauland1 on 2026-09-10 14:26:40 Yes, love the cat! I've got two little voids. It would be funny to have a black card with a blank space and say there was a black cat there... | |
Posted by: saybur on 2026-09-10 18:51:38I did some investigation of this with a nubus development card with a pico, and later, my NuCF cards...That information is helpful, thanks! I recall from SCSI work the OS just loves sending out storms of short READ commands, makes sense that would still happen on disk usage even without SCSI in the picture. As for 32-bit, that I really wanted from the get-go. I had originally tinkered with doing this all on a Pico 2 but everything I read at the time backs up what you said: NuBus access is precious, make every access count and don't skimp on data width. If I can get this going I'll do some testing and report back numbers, it'd be interesting to see how this behaves on various bus speeds. And with the MCU it'd be easy to intentionally narrow the bus, might be fun to see how badly performance goes kaput. And your driver looks great! I really appreciate you documenting the work you've been up to in this space as well as you have. Both you and Melkhior have left great information for people to follow. Thank you! On 040 (presumably first generation power macs too), there wasn't a huge benefit in random IO as compared to the built-in SCSI. Larger CPU caches side-step the issue with SCSI Manager being phat and the 53C96 SCSI controllers (even without DMA) are much more capable. For these systems, in my opinion, there is little point in nubus storage if the goal is to improve speed, unless you can manage DMA since it does not completely halt the 040.Candidly I've been confused about the different features on offer in the '040s when it comes to block transfers/DMA and how useful they might practically be. From what I found reading around there is:
...My thinking was the RP2xxx would be best applied for new and interesting interfaces (audio!) and as a specialized coprocessor (TLS?) since video and storage weren't really killer applications for it.Heh, that may be where this ends up too. The surface mount 0.1" header near the card socket is there for futzing about with features like that later; I've done enough audio that adding a I2S DAC wouldn't be out of the question. And it might be nice to have native MP3/OGG playback available through some future application 😎 Edit: I appreciate that you dithered your cat picture, I had no great success with that and a black cat 😛Thanks! I got lucky with my guy, the dithering effect worked nicely with his coat, because... I heard a rumor that @saybur originally created a Ginger Cat card, but it didn't have enough memory to do anything.🤣 You hit close to home! He's a (very) orange tabby. And I mean orange in EVERY sense of the word. This is a mischief maker!  Yes, love the cat! I've got two little voids. It would be funny to have a black card with a blank space and say there was a black cat there...Haha nice, and appropriate too, this guy's brother is also a void. Maybe he belongs on a future revision? I got a kick out of seeing Mr. Cat on NuCF and I would be thrilled if more people started putting their pets on PCBs! 😀 | |
Posted by: zigzagjoe on 2026-09-10 20:40:27That information is helpful, thanks! I recall from SCSI work the OS just loves sending out storms of short READ commands, makes sense that would still happen on disk usage even without SCSI in the picture. I mostly did my testing with a 16 bit device so that's part of why I keenly felt the pain on the earlier Nubus controllers when synchronization was so expensive. Most NuBus NICs only have 2x8bit SRAMs onboard but perform expansion to 32 bits at least on reads to avoid doubling up on the costs of each NuBus cycle. Going for 32 bit right away is definitely the right approach. That example driver is very basic but hopefully it helps. Happy to supply more detail too, where possible. 68040 line transfers; The 040 always tries to perform transfers of an entire cache line (16 bytes). Instruction reads and data reads will always be lines under typical conditions. Data writes will do the same, unless the region is marked non-cachable or write through. When a line transfer occurs to a device that does not support the 040 burst transfer mechanism, transfer acknowledge /TA should be asserted with /TBI (burst inhibit) and 32 bits of data provided. The 040 will issue 3 more transfers with SIZ[0...1] = long (32 bits) to transfer the remaining bytes. MOVE16 is a special case that performs line transfers but also does not allocate cache misses so you don't blow away cache contents when doing bulk copies. Not always the absolute fastest method to move data but generally the right choice if the alignment works out. Dunno what happens if you hit a device that is burst inhibited or cache inhibited regions. Nubus pseudo block transfer: If the 040 issues a line transfer for Nubus space, the NuBus controller accepts the 040 line transfer and issues 4x long transfers over nubus. Not quite sure why since in theory Nubus bursts could accomidate an 040 line. Perhaps it was too difficult to deal with the case where the slave device couldn't accept a burst, or was confusing older cards? Also, nubus space is cache inhibited by default and probably serialized (in-order access enforced) too. @Melkhior probably can detail this better than I can. NuBus DMA: This works as you describe, per my understanding. Arbitrate for the NuBus and emit an appropriate address residing in main memory, and the controller will arbitrate for the system bus then issue appropriate bus cycle(s). Not all logic board resources (IO, ROM) may be accessible by the NuBus master, and the relative-to-NuBus-master address space is mapped differently from what the CPU/logic board uses. I never did end up implementing this myself so I might not have that 100% correct. DMA: On the 030/020, unless the current code is executing fully out of the (small) caches, doesn't read data outside data cache (030), and doesn't write anything but registers, alternate bus masters can starve the CPU while they have bus tenure. Extended DMA transfers - for example, transferring an entire disk sector - will prevent the CPU from performing any access unless the bus is regularly released, the timing of which is up to the alternate master. I would expect the NuBus controller would release the bus after each NuBus master transfer, so the 030 will get a cycle or two in between each NuBus transfer. On the other hand, a PDS device like the NuCF could entirely stop the CPU. DMA on these system is mostly useful for trickling in small bits of data to/from slow IO devices (like a serial port) rather than big fast transfers. DMA is more interesting on the 040 as the 040 cache is write-back; unless cache behavior is modified by MMU flags (ie. a write to cache inhibited IO space is needed), the 040 will defer data writes until either forced by a cache magement instruction (CPUSH) or the cache line needs to be evicted. Combined with prefetches, the 040 can execute entirely out of its caches for extended periods of time (compared to 030/020 and 000) so alternate bus masters can utilize the bus without impeding the '040 nearly as badly as an 030. Additionally, arbitration of the 040 bus is handled by the logic board chipset with a prioritization/fairness mechanism so the CPU can not be starved out. Block move transfers between NuBus masters and main memory: Typical DRAM timing might be 5-2-2-2 as measured in system clock cycles; this mean any initial memory access to DRAM from 040 requires 5 clocks, but subsequent accesses in a line transfer require only 2 clocks per long transfered. So: 5 clocks for 4 bytes, but 11 clocks for moving 16 bytes. If your Nubus master implements bursts, the relative throughput increase ought to be similar. Not sure if this applies to writes/reads or both. There's a lot of moving parts there, but hopefully it helps. | |
| Posted by: lauland1 on 2026-09-11 07:35:05 Yes, I've been looking recently into putting something into the 040 cpu slot, ala an accelerator, or a pi ala pistorm, and the 040 is very complex compared to the 030 where it's "relatively" easy to do something like that. The 040 does many things which make it much harder to emulate in hardware. I'm not a hardware engineer, so this is all just theory, or looking for what other people are doing. I'm a software guy, so am looking for some sort of accelerator (any sort) for 040 macs, and turning up either nothing, connectors (like pds) that are almost impossible to source/purchase, or people just putting in faster 040's or 060's, which seems counter productive in 2026, at least to me. (The cost alone of a newer faster 040 or 060, compared to a rasp pi is just...not going to happen for me). I'm very interested in this project, as it looks like what I'm searching for. Until I have some sort of better hardware, I've been working on graphics acceleration, and will just need to use what hardware I actually have. Right now, that is a dos compatible card, so I have a really crazy idea to make use of it. I apologize for a huge aside for this thread...as you're not talking about graphics. ---- The idea, which I wanted to avoid, as it will be a lot of work, although I'm pretty sure I can do it, would be to create a mac video driver for the dos card's svga. I'd base it on Melkhior's for a start. This would be a lot of work, and the benefit may or may not be worth it, due to the overhead of passing messages in shared memory to the 486, which could, in theory, handle at least some of the rendering. (So you can see why I'm interested in the risc cores on your card). This would all be to set up some sort of environment to work on graphics acceleration, so not a means to an end. I'm looking heavily into 3d, obviously, but quickdraw acceleration of some sort would be in there too. ---- What I want to do is maybe try and establish a "de factor" standard for people working on mac graphics acceleration. It would be as compatible with Apple's ppc OpenGL as possible, at least at the api level. This driver I'd write would work as much as possible as Melkhior's for 2d The hope being, if I write it, we could merge it into a more generic driver, that could be used, in my fantasy world, for any sort of hardware. (The mac part, each hardware would need a different "plugin" depending on the core or fpga or whatever was used). ---- So I'd do 2d first, and once I get that going, am not sure if the 3d part would be part of that driver or separate...eventually...the "final form" could be a cfm-68k shared library that looks like Apple's OpenGL as much as possible (including RAVE). If I have this driver doing 2d, I'd do 3d just as a static link library for proof of concept. Since the dos card also works in my 6100, I'd do it for both m68k and ppc. I find moving my code from arch to arch or compiler to compiler, almost always flushes out hard to find bugs. ---- I've got mesa 2 as a software renderer working very well, but slow. Am working on Mesa 3 and beyond. I also have TinyGL looking very promising. I'm working on a RAVE which uses OpenGL (upside down compared to apple's), which could use any of these stacks, or even Apple's. I'm adding to these stacks so they can build and run Apple's OpenGL SDK demos and other demos. (Which I have almost all working with well Mesa 2). This includes an AGL that is compatible with Apple's, at least at the api level. ---- Your orange cat is very orange, you can tell by the look in those eyes. | |
| 1 > |