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

[Mouse]

(One of the very few times when a no-trimming reply is actually *more*
useful to me than a proper reply.  Ironic.)

>>> 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).

Yeah, the cg6 has registers for Z coordinates but they don't seem to do
anything.  I don't know whether 3D was planned but never implemented or
whether it's just that how to get it to do anything but parallel
projection down the Z axis is not publicly known.

>>> - 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.

Largely.  The CPU ends up drawing pretty much everything, so having a
factor of 4 less data to shove over the bus comes close to a factor of
4 speedup.

>> [...], a proper blitter would probably be fast enough even in 24
>> bits.

An onboard blitter, yes, probably would be.

>> 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...

Then don't use 'modern' Xorg.  I still use the MIT sample server, with
my DDX layer that _does_ know how to do 8- and 24-bit on the screen at
the same time.  It wasn't even all that hard.  I don't know whether
Xorg has broken their internal interfaces to the point where that's not
practical, or it's just that nobody's bothered to build such a DDX
layer, or what.  (After all, everybody knows the whole world is peecees
running bleeding-edge Linux.  *grrr*)

>> Doing 8 (x)or 24 could be easy and resource-consuming (duplicate
>> everything but the framebuffer) - or harder and more efficient.

Well, the cg14 does it by having more than 24 bits per pixel (26? 32? I
forget the actual number - they're addressed as if it were 32bpp, but I
forget whether the top 8 bits are fully implemented).  The extra bits
specify whether the other 24 bits are sent straight to the DAC
(TrueColor, in X terms), sent through lookup tables to the DAC
(DirectColor), or whether the green channel is sent to all three lookup
tables and thence to the DAC (PseudoColor).  Enhancing this is
framebuffer address decoding logic that causes the bits making up the
green channel of the 32bpp framebuffer to appear elsewhere in the
memory space, arranged as an 8bpp framebuffer.

>> 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...

The cg14 is easy.  The SX is perhaps less easy, but also less critical
to replicate exactly, unless you are trying for complete software
compatability.  (Which is futile as long as you're making an SBus
board, since the cg14 is not an SBus device.)

But, as long as it's fully documented, that doesn't matter to, at
least, me.  I would cheerfully use serial console if necessary.

>> 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...

Depends on how you define `mature', but actually probably not.  My
SS20s run something that's basically NetBSD 1.4T.  I've evolved it a
bit, but my /usr/src is well over 95% identical to the 1.4T I started
with.  ("10461 files changed, 187951 insertions(+), 115420
deletions(-)", out of (post-changes) 25786 files, 8532315 lines.
Counting the whitespace changes as real changes, and going strictly on
line count, counting inserts and deletes both, that's about 40.6% of
the files, 3.5% of the lines. Skipping the whitespace cleanup commit,
it's "2411 files changed, 97449 insertions(+), 24918 deletions(-)", or
9.35% of the files, 1.4% of the lines.)

Which is more mature?  Most metrics, probably, count 9.0 as more mature
than 1.4T.  It's certainly a couple of decades more recent.  Though 9.0
does have a few things I count as pretty childish....

>>> (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).

But a lot better than _no_ documentation.

>> 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.

I'd be willing to put some effort into improving it to the point where
it can run various programs I've written that talk directly to the
cg6....

>> [...], then the question will be figuring out a version of the board
>> with a HDMI output...

Personally, I would pay a small amount extra to _not_ have HDMI, quite
aside from what other connector(s) it has/have.  (But I probably am an
extreme outlier in that respect.)

>> Still a lot of fun to be had with that project :-)

Sounds like!

> [...], 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.

Emulating a cg14 without the SX is easy.  It's very little more than a
dumb framebuffer.  The only thing that's at all difficult is the
various views of the framebuffer RAM, and the cg14 is hardly the only
framebuffer that does that, so presumably there's machinery in place
that can be used for it.

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

I shall have to look into that.  If it really does emulate the SX
stuff, that will help me, because I've been meaning to get around to
reverse-engineering SX documentation from open-source code so I can add
acceleration to my cg14 DDX layer - and my console code.  I'm told
there's some code in NetBSD for it, which I keep meaning to dig up and
read over, but the more code I have to look at the better.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B