Should the design work, it would make sense to first redo some of it - the dual output is mostly for testing, in the hope that one of them will work. Should the HDMI works, it would make sense to remove the VGA and reclaim more than a couple dozens FPGA pins. Those could be more productively used to implement e.g. a micro-sd slot, perhaps add an Ethernet PHY, etc., and perhaps drop the extra CPLD. Like for USB, the biggest challenge is not to add features to the board and an associated controller in the FPGA - it's to write the drivers for them :-( With the SBusFPGA I "cheat" by running NetBSD/sparc, so I have a recent UNIX-like OS to work with (and a much cleaner way of declaring the devices with OpenBoot/OpenFirmware). ROM & drivers in System 7/MacOS 8 are a tougher nut to crack.
-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
Development of Nubus graphics card outputting to HDMI?
- Thread starter dlv
- Start date
Well, if you do decide to do a batch, let me know!
Or post when it's finished and open source, I'll definitely try and build one.
Or post when it's finished and open source, I'll definitely try and build one.
Don't worry, if I ever get the HW to work, I'll let *everyone* know 
Also a word of warning - large framebuffers use a lot of memory so are slow to update. On my SPARCstation, unaccelerated 1920x1080/8bpp is painfully slow in X11 (I use a microcoded RISC-V soft-core to emulate a vintage accelerated device, and that's reasonably usable), while unaccelerated 1920x1080/24bpp is effectively useless. And that's with a bus running at 25 MHz, 2.5x faster than a Mac's NuBus (both are 32 bits wide), so it will be worse in the NuBusFPGA. So getting the basic stuff to work might be ok for 1280x1024@8bpp (a resolution common in older 4:3 LCDs), but for larger display/higher depth it's likely a lot of work on SW to get some acceleration working will be needed to make the design usable.
Also a word of warning - large framebuffers use a lot of memory so are slow to update. On my SPARCstation, unaccelerated 1920x1080/8bpp is painfully slow in X11 (I use a microcoded RISC-V soft-core to emulate a vintage accelerated device, and that's reasonably usable), while unaccelerated 1920x1080/24bpp is effectively useless. And that's with a bus running at 25 MHz, 2.5x faster than a Mac's NuBus (both are 32 bits wide), so it will be worse in the NuBusFPGA. So getting the basic stuff to work might be ok for 1280x1024@8bpp (a resolution common in older 4:3 LCDs), but for larger display/higher depth it's likely a lot of work on SW to get some acceleration working will be needed to make the design usable.
As long as partial updates work I think it's fine. More screen real estate just means you can put more windows on the screen, and the most likely use case is that those windows aren't constantly updating (... well unless you are trying to play multiple videos at the same time).
If you would want to play multiple videos at the same time probably also need accelerator hooks for those.
If you would want to play multiple videos at the same time probably also need accelerator hooks for those.
. . . and a better machine than can support NuBus.
Sweet spot for resolution might be "half" of 2K, pixel doubled for current displays. 1080p is so last year's fashion for the desktop.
Might be a good idea to implement DPI scaling too if you want to go that high resolutions.
Or otherwise you could just use low resolutions and set the scaling method on the monitor itself to nearest neighbor.
Or scaling could be implemented on the card itself and you could apply shader effects to the final output, like CRT, scanlines, etc.
Or otherwise you could just use low resolutions and set the scaling method on the monitor itself to nearest neighbor.
Or scaling could be implemented on the card itself and you could apply shader effects to the final output, like CRT, scanlines, etc.
Would it be possible to have a jumper (or maybe do it via software, I don't know) to enforce 1:1 pixel scaling? For example, assume you have a period appropriate 19" LCD at 1280x1024. The video card would always send a 1280x1024 signal. But when you "change" the resolution on your Mac, instead of actually changing the output signal (it'll keep it at 1280x1024 at all times), it'll compare the 1280x1024 output to the requested "resolution change," then produce the maximum 1:1 scaled image it can output. Fill in the remaining pixels with a black border (or perhaps a user selectable color like on the IIgs.)
So assuming you have said 19" LCD at 1280x1024 and you switch the Mac to 640x480, it'll "change" the resolution to a pixel doubled 1280x960, then fill in the remaining 64 pixels on either side with black (or whatever color.)m Or let's say you're playing a really old game that wants the original 512x342. It'll "switch" the resolution to 512x342, but in actuality will pixel double both the vertical and horizontal to 1024x684, then fill in the remainder with the border, all while maintaining the original 1280x1024 output.
That way the image you get is always a perfect 1:1 scale with no interpolation.
Hope that makes sense.
So assuming you have said 19" LCD at 1280x1024 and you switch the Mac to 640x480, it'll "change" the resolution to a pixel doubled 1280x960, then fill in the remaining 64 pixels on either side with black (or whatever color.)m Or let's say you're playing a really old game that wants the original 512x342. It'll "switch" the resolution to 512x342, but in actuality will pixel double both the vertical and horizontal to 1024x684, then fill in the remainder with the border, all while maintaining the original 1280x1024 output.
That way the image you get is always a perfect 1:1 scale with no interpolation.
Hope that makes sense.
Some displays have that kind of 1:1 setting built in. You can use a scaler to do a single resolution that way.
68kmla.org
This Extron scaler stores presets for x number of RGB inputs if not general resolutions. Dunno, it's been a long time since I've played with it.
A scaler development thread would be a good thing to have going on for feasibility study I think. Truly non-trivial from what I understand of comments from threads randomly scattered about the place. That's tangential here, but a very interesting project for discussion.
@Gorgonops you're our resident scaling expert I think. How about heading up that campaign for us? If nothing else, a primer posted would get the discussion going. TIA?
Good & reasonable HDMI scaler: Extron RGB-HDMI 300(A)
At @Trash80toHP_Mini's request, a thread about the HDMI scaler I found myself using to do vintage Mac stuff on a modern screen. It works, at least for me, really well and I'd recommend it to other folks as well. It is also not *that* expensive. The model is Extron RGB-HDMI 300 or 300 A. I...
68kmla.org
A scaler development thread would be a good thing to have going on for feasibility study I think. Truly non-trivial from what I understand of comments from threads randomly scattered about the place. That's tangential here, but a very interesting project for discussion.
@Gorgonops you're our resident scaling expert I think. How about heading up that campaign for us? If nothing else, a primer posted would get the discussion going. TIA?
Last edited:
I had done some fairly extensive research a while back, and I could not find any modern LCDs that did 1:1 scaling that were not "medical grade" and very expensive. There were a few older LCDs that had it, I think, because they were expecting analog inputs with variable resolutions.
Then we're stuck with the available Extron Scaler for the time being it seems. Hoping someone will start development of a daisychain capable input board scaler for video component of a new solid state KVM setup. The only other improvement of Extron I can think of would be wallpaper behind the desktop window.
Again, this should be in a dedicated thread. Why don't you kick one off and we can do spec development without further derailing this thread? My byline tends to be ignored.
Again, this should be in a dedicated thread. Why don't you kick one off and we can do spec development without further derailing this thread? My byline tends to be ignored.
Last bit about scaling related issues for this project:
1280x720 (AKA 720p) would seem to be the sweet spot for a widescreen 68K resolution? 2x scales it directly onto 1440p, the new desktop standard. 1080p Displays interpolating the 480p of DVD input is pretty darn good, but a straight shot would be better.
ISTR 1440p displays having presets for 720p input? What's a glaring omission on consumer panels at that resolution would be scaling columned 1920x1200, which pretty much tops out Mac video under OS9?
1280x720 (AKA 720p) would seem to be the sweet spot for a widescreen 68K resolution? 2x scales it directly onto 1440p, the new desktop standard. 1080p Displays interpolating the 480p of DVD input is pretty darn good, but a straight shot would be better.
ISTR 1440p displays having presets for 720p input? What's a glaring omission on consumer panels at that resolution would be scaling columned 1920x1200, which pretty much tops out Mac video under OS9?
Hello,
Further discussion on NuBusFPGA should go in this new dedicated thread.
Further discussion on NuBusFPGA should go in this new dedicated thread.
