I have an SS20 with a cgfourteen in it (ie, with a VSIMM), as some of
you may recall.

Everything seems to work fine as it is.  But, the framebuffer supports
multiple resolutions.  Specifically, I see

ok cd /obio/cgfourteen
ok words
selftest      disp-test     close         remove        restore
draw-logo     write         open          install
send-byte     hdtv          vsync         do-mode-switch
set-logo      random-logo   toggle-colors?
r1920x1080x72 r1024x768x70  r1280x1024x66 r1600x1280x66
r1024x768x66  r1152x900x76  r1152x900x66  r1280x1024x76m
r1600x1280x76m              r1024x768x60
ok

which includes, as you can see, five different resolutions at a variety
of different vertical retrace rates.

It would be nice to be able to get 1600x1200, as there is then a decent
chance it will Just Work with a stock peecee (= cheap) flastcreen
display; losing 80 pixels vertically to save a good deal on the
flatscreen price is a tradeoff worth at least investigating.  (It works
fine at 1280x1024, but I'd *like* higher resolution.)  So, I started to
look at the structure of those resolution-specifying words.  Turns out
each one just pushes ten values on the stack.  For example,

ok see r1920x1080x72
: r1920x1080x72
   780 438 48 cdfe600 d8 3 178 56 30 3
;
ok

I assembled a table of the values, and some of them make sense, but
others don't, at least not to me.  Here are the values, converted to
decimal, reformatted to save lines:

r1024x768x60   1024  768 60  64125000 128  6 160 29 16 2
r1024x768x66   1024  768 66  70400000 124  5 160 39  4 1
r1024x768x70   1024  768 70  74250000 136  6 136 32 16 2
r1152x900x66   1152  900 66  94500000  64  8 272 27 40 2
r1152x900x76   1152  900 76 108000000  64  8 260 33 28 2
r1280x1024x66  1280 1024 66 118125000  64  8 280 41 24 2
r1280x1024x76m 1280 1024 76 135000000  64  8 288 32 32 2
r1600x1280x66  1600 1280 66 200000000 256 10 384 44  0 0
r1600x1280x76m 1600 1280 76 216000000  72  8 440 50  8 2
r1920x1080x72  1920 1080 72 216000000 216  3 376 86 48 3

The first three are pretty bonehead-simple. :)  The fourth is less
clear; I speculate that it's some kind of pixel clock frequency -
certainly the ratio between it and the product of the first three is
both notably close to constant and frustratingly non-constant.  The
rest of them look pretty mysterious to me.

Anyone have any ideas, or is this a case where I'll have to dump and
uncompile the card's fcode to have any chance of understanding it?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B