Again, yes, tired, very clumsily tried to make sure technical objections, suggestions or further discussion not tangent bomb this thread.Yes: I'd suggest not getting sidetracked down the lines of the Portable LCD. It's either going to be trivial or painful, and there's not much in the middle, and either way it won't be of much use to many people because the Portable doesn't have NuBus, so it'll only be for people who want to do hacks...
It might be for HDMI, at least that's the suggestion - data and clock lines are running at more than 1 Gbit/s there when you push the resolution to Full HD (which in fact is technically beyond the capability of the FPGA using regular I/O, lower resolution might be more realistic; it's theoretically possible for an Artix-7 to output 4K HDMI using the GTP pins and some signal translation magic but I've not found a reference design and my FPGA board doesn't have GTP anyway).Looks like you had fun with differential PCB lines. Is it needed at theses frequencies ?
If by 'released' you mean the stuff Apple sent to a museum, then no, that's only for the original QuickDraw, which is much simpler.Nice work ! I wonder if the other traps are documented somewhere in the released QuickDraw source code.
Patching QD through the bottleneck routines means re-implementing them, and they can be very versatile so it's a huge job. The 8*24GC did that, but it seems some other accelerators didn't and merely accelerated some of the most common cases through the internal traps. E.g. the 'QCOD' resources in Radius QuickColor starts with a table of trap numbers/code offset, and there's a lot of internal traps in there if I interpret the resource correctly.Honestly, patching QD not through the bottleneck routines sounds like a recipe for pain and compatibility issues to me.
If by 'released' you mean the stuff Apple sent to a museum, then no, that's only for the original QuickDraw, which is much simpler.
But the published ROM code I linked to contains a full 32-bits QuickDraw, with all the then-current traps.
Indeed ; I have now a working declaration rom for the simple case thanks to QEMU (so fixed resolution, 8-bits only), with embedded drivers supporting 7.1/7.5.3/8.1. I was able to test it with up to 5 extra screen in Qemu - not that it's usable. But with one extra screen of 1600x900 set as the primary, Qemu is the best SimCity 2000 platform I knowAlright thanks. The museum code was the one I was referring to. Interesting that you can test that with QEMU right now. Should be handy to test Declaration ROMs !
Linux - on my test machine running Debian 10. It's much faster than a real '040 even with a remote X11 display on my desktop, using a Xeon core (which tends to have lower frequency than their desktop counterpart) and storage on spinning rust (couple of SAS drives in a ZFS mirror).Very, very cool. Are you running QUEMU under LINUX (what distro) or Windows?
Probably in the $500-$600 range per units between the carrier and daughterboard. But it's a toy project at the moment, I have not definite plan to make some for sales - but it will be (is) open-source.What's unreasonably high? You may be able to get 10-20 units sold at a high price...
The current HW design has connectors for HDMI, VGA, and USB - however getting a USB stack working in MacOS is highly unlikely, it's there because it's small and not very expensive and can help with some testing. All peripherals would live in the FPGA, so you could have additional features in there, including e.g. video acceleration (provided one can get some software support working!).I may have missed it, and I'm sure it's buried in this thread somewhere, but what exactly would this card provide? I know HDMI... But it would be more than a stock Toby card could do I would hope. Would this be a super high end type of video card with lots of memory and capable of doing higher resolutions (1xxx by 7xx+) at millions of colors?
No, thick, as it's two cards in parallel separated by the 2.54mm (.1") headers. So it will likely take over 2 or maybe even 3 NuBus slots when plugged in. In length it's pretty much as short as it can be (ends right after the NuBus connector), and slightly less high than a full-size NuBus card.You also mentioned that it was a "wide" card in a past reply (to myself!). Did you mean long, like a stock Mac II card?
Impressive. Could call it a FatMak video cardProbably in the $500-$600 range per units between the carrier and daughterboard. But it's a toy project at the moment, I have not definite plan to make some for sales - but it will be (is) open-source.
The current HW design has connectors for HDMI, VGA, and USB - however getting a USB stack working in MacOS is highly unlikely, it's there because it's small and not very expensive and can help with some testing. All peripherals would live in the FPGA, so you could have additional features in there, including e.g. video acceleration (provided one can get some software support working!).
As for resolution, it the design works, the FPGA should be able to do 1920x1080 on either output - but probably less if trying to create a dual-head configuration (as the memory bandwidth available will become a bottleneck; with 256 MiB on the daughterboard space is not an issue, in the SBusFPGA the balance of memory is used to create a memory-based disk for e.g. swap or /tmp in NetBSD).
No, thick, as it's two cards in parallel separated by the 2.54mm (.1") headers. So it will likely take over 2 or maybe even 3 NuBus slots when plugged in. In length it's pretty much as short as it can be (ends right after the NuBus connector), and slightly less high than a full-size NuBus card.