On Thu, Jan 8, 2026 at 5:12 AM Andrew Randrianasulu <randrianasulu%gmail.com@localhost> wrote: > > > > чт, 8 янв. 2026 г., 04:33 Michael <macallan1888%gmail.com@localhost>: >> >> Hello, >> >> On Wed, 7 Jan 2026 20:00:23 +0300 >> Andrew Randrianasulu <randrianasulu%gmail.com@localhost> 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 >> >>