BLITing overlaping regions...

... may be tricky. The following screen shot illustrates why the memmove() system call was introduced as a safe replacement for the good old memcopy() back in the days.

Overlapping BLIT

The splash screen is done, next level

After some improvements to the cgsix emulation the boot splash screen is finally looking good:

cgsix under sun4m

On the screen above there is only one thing missing: the cursor. Unlike cgthree, the cgsix graphic adapter has hardware cursor, which I haven't implemented yet.

Well, the hardware cursor is not the only thing which is not yet implemented in general. The next screen is not as good:

The freedom statue is looking at Solaris install process

/stay tuned

Meanwhiile in sun4m

Debugging when a program does something unexpected is easy. You just have to find the place where it starts doing it and find out the reason.

In my case though, the problem is that Solaris doesn't change the color map. But where and when is it supposed to update it? Tricky.

And then I thought: why don't I try it under sun4m? And tell you what. I've got a good and a bad news. The good news is that the RAMDAC emulation does work ok:

cg6 under sun4m

The bad news is that the reason why it doesn't perform somewhere near it when running on a sun4u is still to be found. My current educated guess is that it has to do with the interrupt processing...

Don't know yet what I'm going to attack next: fix the interrupts under sun4u, or improve some missing graphic features under sun4m. The latter has an advantage of producing some nice or ugly screen shots, and everyone likes screen shots. :-)

The colors...

... are still not quite right:

Let's add some colors

The moment you see the endianess is wrong

Think I fixed one bug, but this way I loose the half tones. And the endianness is definitely wrong:

The endianness is wrong

Above I treat the bytes as pixels. The endianness is definitely wrong. Fixing the endianness the picture gets better:

The endianness is correct

Not sure if the bit order in the byte is correct. And no idea why it's so contrast and monochrome. Treating the bits as pixels with the proper endianness the picture looks more interesting:

As if a bit were a pixel

The result must be somewhere in between the two above... But I'm think I'm done for this weekend.

The moment you see you used bits instead of bytes

Trying to find out how the cg6 registers work I get some funny pictures.

When the bytes are treated as bits

Here it interprets bytes as bits. Plus some more bugs indeed...

Fixed the cgsix colormap

Looks like the cgsix DAC is slightly different from the one used in cgthree. Fixed it and now the image doesn’t look so psychedelic anymore:

 

cgsix in the DFB mode

Now, that was the easy part. Making it work under OpenWindows is going to be trickier. There is virtually no documentation on the GPU. I guess this manual is really lost: as Sun tried to open the specs back in 2008, they failed with “Unable to locate (15-July-08)” message.

Does anyone by any chance have the book “TurboGX Reference Card” (p/n 800-5112) or any other document which describes how to program the TEC and FBC units of the TGX chip?

The first experiments with cgsix emulation

Okay, I’ve got the first picture with a virtual cgsix under QEMU. The colors are slightly distorted, but at least the image is there:

cgsix in red

a few more words on cgfourteen

A customer asked me if he’ll ever gets a chance to watch HD movies on an emulated SPARC machine. At first, I was going to say never ever, but then I looked at the specs of some ancient adapters and got surprised.  The SGI machines were commonly known for good graphics, but it never occurred to me that Sun machines were really powerful as well.

The cgfourteen (cg14) adapter could show Full-HD (1920x1080) pictures back in 1993!

Since the manufacturers sometimes claim just the theoretic abilities of the chipset, I wanted to check that the software has been really aware of such graphic modes in early nineties.

So, I gave a spin to the old cgfourteen patch from Bob Breuer. And here we go.

 

SPARCstation 20 OBP supports 1920x1080

Overall the cgfourteen adapter was really powerful. Michael Lorenz who added the hardware acceleration support for cgfourteen to NetBSD, wrote “SX has plenty of registers (128 - eight of them have special functions, the rest is free for all) and every instruction takes a count to operate on several subsequent registers or memory locations (ALU ops can use up to 16, memory accesses up to 32). SX supports some parallelism too - the ALUs can do up to two 16bit multiplications and two other arithmetic or logical ops per clock cycle (32bit multiplications use both ALUs).

The bad news is that Bob’s patch doesn’t implement the SX rendering engine. Also, the Solaris (or rather OpenWindows) driver is very much bound to sun4m SRMMU, so it won’t work on sun4u machines.

Would really like to have the emulation of a graphic card which would be better than cgthree, and ideally would work on both sun4m and sun4u machines, but it’s not easy.

Right now, I’m choosing between cgsix and creator ffb, but none of them has public documentation.

P.S. A funny fact about the Solaris SX driver: there are lots of symbols which have the word “SPAM” in a name. It can spamify and unspamify.  It’s really hard to google what it could mean back in nineties. “M” is probably for “Memory”.