Re: CG14 in 8-bit color

[Romain Dolbeau <romain%dolbeau.org@localhost>]

Le ven. 3 déc. 2021 à 19:24, Michael <macallan%netbsd.org@localhost> a écrit :
> IIRC the tgx+ topped out at 1600x1200, according to its firmware.

You can coerce a true TGX[+] into many alternatives resolutions to
Sun's if you reprogram the clock generator & the control registers
(you really want a + to get the extra memory).
The problem is modern LCDs that are very restrictive on what they
accept on their analog input, so finding a working match is not always
easy.
(some years ago I had done some experiments:
<https://github.com/rdolbeau/SunTurboGX>).

> No clue about the X11 issue, does it happen during framebuffer or
> register access?

Neither, it doesn't crash while accessing hardware in X11, that's part
of why it's been a pain to diagnose. When using my own
re-implementation of a cg6 or a cg3 (and the cg3 is a very passive and
simple device), X11 works apparently fine (visually speaking), but
after I exit X11 the kernel will crash sooner or later (this does not
happen with a real cg6 of course, so it concerns literally just me! I
don't have a real cg3 handy to triple-check). It happens even when my
device is set to a lower resolution like 1024x768 or 1152x900. If I
deliberately use swap while running X11, it apparently gets corrupted;
if I use swap after leaving X11, a crash is guaranteed, and it's
always in 'pv_syncflags4m' IIRC.

As far as I can tell (but my knowledge of the NetBSD internals is very
limited), it seems the kernel page table gets corrupted somehow when
X11 is using my device instead of the 'real McCoy', and it doesn't
make sense to me.
I tried to faithfully replicate the ROM behavior in terms of what is
left mapped when the kernel boots, the ROM is the only bit of SW that
is not the same as when running a Sun cg6.

The re-implemented cg3 is really puzzling, as cg3 reuses the console
driver in X11. I can have 2k+ page-ins/page-outs per second to swap on
my sdram-disk all day long with no issue when using only the
console... It's only X11 that causes the issue.

(the good news is that because of that bug I went back to working on
the micro-sdcard support; it is now bootable, even if my NetBSD driver
is still fairly slow and rough :-) )

Cordially,

-- 
Romain Dolbeau