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

Back to SPARC

Man proposes, God disposes.

I planned to finish the work on the 40p emulation, but due to some turbulences had absolutely no chance to work on QEMU since last December.  But it looks like I may have some time for QEMU again.

Now, while running AIX under QEMU has been a nice brain and finger exercise, looking at my mail box and the comments of this blog, I think the people are more interested in Solaris than in AIX, so I plan to dig out my Ultra-1 sun4u prototype from 2012, adapt it to the current QEMU object model and make it public (no ETA though).

/ Stay tuned