Re: cg14 vesa (modes) project on github

On Thu, Jan 8, 2026 at 5:12 AM Andrew Randrianasulu
<[email protected]> wrote:
>
>
>
> чт, 8 янв. 2026 г., 04:33 Michael <[email protected]>:
>>
>> Hello,
>>
>> On Wed, 7 Jan 2026 20:00:23 +0300
>> Andrew Randrianasulu <[email protected]> wrote:
>>
>> > found this project;
>> >
>> > https://github.com/mdehling/cg14-vesa-mod
>>
>> "NetBSD 9.2 boots fine. The Xorg 'xf86-video-suncg14' driver implements
>> only 24-bit support. I have patched it to add 8-bit support and Xorg
>> works fine at 1920x1200x60 in 8-bit mode with a 4MB VSIMM. No hardware
>> acceleration for now!"
>>
>> ... I added 8bit support a while ago, mostly because people wanted to
>> run higher resolutions with 4MB VSIMMs. I also added ( still somewhat
>> wonky ) 16bit colour support, for the same reason.
>>
>> That being said, my drivers *should* run with whatever the firmware
>> hands them,
>
>
> hm, I think I should test this patched qemu against latest netbsd/sparc install cd .... I am not sure NetBSD'S kernel driver can deal with _partial_ cg14 emulation, without real SX coprocessor backing it.


https://mastodon.online/@Andrew_R/115857128949389175

just moment before it panics (but in less verbose way compared to 10.1)

 taskset -c 1 build/qemu-system-sparc -M SS-20 -cpu "TI SuperSparc 40"
 -cdrom NetBSD-11.99.4-sparc.iso -g 1152x900x24 -accel tcg,tb-size=256
 -bios ~/Desktop/SunOBP2-19_525-1377-06.ROM
cg14_realizefn 1152, 900
CG14: control register (0x5a) has unimplemented bits set
CG14: readb from reg 1000
CG14: writeb 0x00 to reg 1000
CG14: writeb 0x01 to reg 1000
CG14: readb from reg 1000
CG14: readb from reg 1001
CG14: writeb 0x01 to reg d
CG14: readl 00000000 from reg 20c
CG14: writeb 0x02 to reg 100
CG14: readl 00000000 from reg 20c
CG14: readb from reg 200b
CG14: readb from reg c
CG14: writeb 0x00 to reg c
CG14: writeb 0x02 to reg 100
CG14: readl 00000000 from reg 20c
CG14: readb from reg 200b
CG14: readb from reg c
CG14: writeb 0x00 to reg c

https://youtu.be/S3bdPIYJRPg - short video




>
> Is there simple way to turn off framebuffer accel for testing? Without recompiling ...
>
>
>
>> they don't touch the pixel clock or any other video mode
>> related registers. There may be some hidden assumptions about
>> scanlines being 32bit aligned though, and that would mess with 1366x768
>> for example ( I remember fixing a bug like that when jdc@ added mode
>> setting support to our ffb drivers )
>>
>> have fun
>> Michael
>>
>>