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

[Romain Dolbeau]

Le mer. 20 oct. 2021 C  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.  (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.  My experience with
>    the cg14 indicates that this makes a significant difference.  (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