[rescue] SBusFPGA update: USB Host, 256 MiB DDR3 RAM disk, ... (Was: Re: A SBus card for SPARCstation designed in 2020...)

[Mike Spooner]

In terms of CG14/SX hardware register-level "documentation", there is an
open-source CG14/SX emulator module for qemu-sparc, capable of running a GUI
ie: using the normal O/S drivers, at least for NeXTSTEP.
Whether it emulates just a dumb CG14 framebuffer, or also emulates some SX
acceleration features, I'm not sure.

https://tyom.blogspot.com/2010/05/sx-framebuffer-emulation.html

-- Mike S.

20 Oct 2021 21:34:24 Romain Dolbeau <romain at dolbeau.org>:

> Le mer. 20 oct. 2021 CB  18:50, Mouse <mouse at rodents-montreal.org> a C)crit
:
>> It occurs to me that a 24bpp (or 32bpp) SBus framebuffer
>> would likely be a popular thing, especially if it includes a few
>> rudimentary acceleration capabilities.B  (I'm thinking line-draw,
>> rectangle-draw, and rectangle-copy would cover most of it.)
>
> In this day and age, recent X11 "EXA" acceleration seems limited to
> solid rectangle, blitting, image uploading and stuff for Xrender (the
> last of which the cg6 code doesn't implement, either because it can't
> do it or because the proper documentation wasn't yet available).
>
> My ultimate goal is a 24-bits FB, but it is still a *long* way off.
> And the current SBusFPGA doesn't have a proper video output anyway,
> and the FPGA board I used is not quite suited to the job.
>
>> - An 8bpp view of the framebuffer, a la the cg14.B  My experience with
>> the cg14 indicates that this makes a significant difference.B  (I
>> wrote a DDX layer for the cg14 that supports 8bpp and 24bpp on the
>> screen simultaneously.)
>
> I suspect the difference is down to 3-4x faster blitting. The SDRAM in
> the board has 1.6 GiB of raw bandwidth, a proper blitter would
> probably be fast enough even in 24 bits.
>
> Supporting 8-bits pseudocolor and 24-bits truecolor at the same time
> is theoretically possible, but I'm not sure 'modern' Xorg remembers
> how to do that...
>
> Doing 8 (x)or 24 could be easy and resource-consuming (duplicate
> everything but the framebuffer) - or harder and more efficient.
>
> The true problem is (as usual) software. The CG6 has documentation and
> software, so it's easy to replicate. I don't know that a SX (let alone
> the others like ZX or - madness - CG8 or GT) could be replicated
> easily. And doing something new would require a driver for the OS
> console and for X11...
>
> And even if I were to write such drivers, that would only help those
> with a compatible version of NetBSD - in my case the base version is
> 9.0, so I think somewhat less mature than the one you use...
>
>> - 2D acceleration, eg as sketched above.
>
> Replicating the basic feature of a cg6 should be easy no matter the
> color depth - my current PoC is just a RISC-V core and some microcode
> to manipulate the framebuffer memory.
>
>> - FCode making it usable by the the ROMs.
>
> That's easy in 8 bits (the console only uses aligned blits, everything
> else is host-supplied software). But there's no predefined function
> for a 24 bits console, pushing to the dual 8/24 solution for
> ease-of-implementation.
>
>> (As long as it's documented, of course.)
>
> Hehe, it's open-source so 'the code is the documentation' :-) (which
> is a terrible solution, I know).
>
> First I'll be focusing on sorting out the issue in my cg6 emulation so
> that it supports correctly the small subset of features used by the
> consoles (PROM, NetBSD) and X11/EXA. When that works, I'll probably
> start thinking about how to implement a 24-bits FB - and if that ever
> works, then the question will be figuring out a version of the board
> with a HDMI output...
>
> Still a lot of fun to be had with that project :-)
>
> Cordially,
>
> --
> Romain Dolbeau
> _______________________________________________
> rescue list - http://www.sunhelp.org/mailman/listinfo/rescue