[rescue] Sun ASIC Manuals

Thu Apr 28 16:15:58 EDT 2022

Sorry guys, this apparently didn't make it through to the list
yesterday, probably because the "eedjit team" consisting of my mail
client and me sent it to rescue-request. So here goes again:

On 27.04.22, 22:28, Malte Dehling <mdehling at gmail.com> wrote:

> Hi, I would also be interested in these docs!
>
> Arno, do you have any pointers to arbitrary resolutions on cg3? From the
> firmware side it looks like it shoulnd?t be hard to do, but the cg3 I?ve
> seen use fixed frequency oscillators rather than programmable clock
> generators like some later cards (tgx/tgx+ for example.)  Did you make
> any
> hardware modifications?  My cg3 cards and classic have extra space for
> additional oscillators and that is something I?ve been meaning to try
> out.
>
> Cheers,
> Malte
Nope, I did not do any hardware mods to that box, the only custom
component in the setup was a 13w3 cable that I had already obtained with
one connector missing and to which a SCART plug was fitted All this
stuff was nearly 15 years ago, as I graduated from University in 2010
and I remember taking the SPARCclassic to a HF lab with some
sophisticated GHz-range counter there as the Genrad nixie tube counter I
owned only went up to 50 MHz and some (most?) of the settings of the
pixel clock PLL(?) chip exceeded that, and stepping through the settings
by means of OBP FORTH commands to take the measurements:
SPARCclassic cg3 Dot Clock frequencies at Pin 6 of U0902 (KS82C671)

rom    measured
entry    freqency

00    13,503808
01    39,960347
02    49,964232
03    54,015360
04    60,017056
05    62,455249
06    64,143230
07    64,987222
08    68,676656
09    70,568441
0a    72,920728
0b    74,271082
0c    74,924518
0d    77,422004
0e    79,920675
0f    81,023015
10    82,659876
11    84,399012
12    88,618968
13    90,025668
14    92,838980
15    94,526885
16    95,621874
17    97,576223
18    99,928508
19    105,395926
1a    108,031000
1b    114,032477
1c    117,033350
1d    135,038500
1e    189,054100
1f    - 0 -

The final process was somewhat similar to that described in the Sun
Framebuffer FAQ for the TGX/TGX+ but the details of the fcode
implementation (order of parameters on the mode line etc.) are of course
different. Basically the cg3 fcode defines some FORTH words for the
standard resolutions and if you define your own for a custom resolution
in the nvramrc startup code going by that template, it can be called in
identical fashion.
(...) OK, you got me far enough to dig out the notes I compiled back
then and the deed was actually done in August 2008. I basically dumped
the whole cgthree fcode by cd'ing to
/iommu at 0,10000000/sbus at 0,10001000/cgthree at 3,0, doing"words" and then
"see" on each word defined there - recursively. I also consulted some
linux and, IIRC, NetBSD driver sources floating around on the 'net which
shed further light on the data format of the mode lines. And now,
straight from the horse's mouth (i.e. my old notes):
"An examination of the FCode of the cg3 revealed that a resolution
set-up word looks like this:

     : r1152x900x76
        " 10,02,43,175,03,179,12,04,43,187,0,26,76,1152,900"
        " 1152x900-76" xdrstring " params" attribute
     ;

A routine that is called during the initialisation of the framebuffer
determines which resolution is to be selected (from the state of the
sense code pins in the monitor connector, if not overridden by user
input); it then invokes the corresponding resolution word that returns a
string with the parameters inside (and sets a single attribute string to
give an indication of the video mode invoked). The parameter string is
then chopped up to extract the parameters, which are translated to
hexadecimal values (the default representation for numbers in OBP FORTH)
and stored into the registers of the framebuffer controller as well as
made accessible for other routines that need to know - so that e.g. the
console emulator can break a line exactly at the right margin of the
screen.

But what exactly do these numbers inside the parameter string mean now?
The Video Controller basically works by keeping track of the pixels and
lines written in two counters. The pixel counter is reset after writing
the visible part of the line, the line counter is reset after the
visible part of the frame, and the transitions between the different
states take place when the counter value reaches the number stored in a
register.
The parameters are (from left to right, example value given in
parentheses):

End of vertical sync/Start of vertical back porch in lines after
top-of-frame (10)
End of vertical front porch/Start of vertical sync pulse in lines after
top-of-frame (02)
End of vertical back porch/Start of visible display in lines after
top-of-frame (43)
End of visible display in pixels after beginning of line, low byte (175)
End of visible display in pixels after beginning of line, high byte (3)
     (That means that the transition takes place at a count of 3*256 +
175 = 943 lines)
End of horizontal sync pulse during vertical sync (179)
End of horizontal sync/Start of horizontal back porch in pixels*8 after
start-of-line (12)
End of horizontal front porch/Start of horizontal sync in pixels*8 after
start-of-line (04)
End of horizontal back porch/Start of visible display in pixels*8 after
start-of-line (43)
End of visible display in pixels*8 after start-of-line (187)
     (meaning the actual transitions take place at count 32, 96, 344, 1496)
Video Clock divider select (0)
Video Clock frequency select (26)
Vertical Frequency in Hz (76)
Horizontal resolution in pixels (1152)
Vertical resolution in pixels (900)."

For some reason I no longer remember it was necessary to do some changes
to the "banner" word as well to make stuff work, so the nvramrc I
finally came up with was as follows:
probe-all
" /iommu/sbus/cgthree" select-dev
: rPAL
" 04,02,32,56,01,254,11,03,20,100,03,02,50,640,280"
" PAL-RGB" xdrstring " params" attribute ;
unselect-dev
: banner
    " banner-" do-drop-in suppress-banner ffd38f98 execute #line @
ffd38f64 execute
    ! oem-banner? if
       cr ffd38f4c execute oem-banner type cr cr
    else
       ffd38f4c execute ffd38fd4 execute type ." , " ffd379b4 execute cr
       ffd38f4c execute ffd38e90 execute ffd2ec10 execute ." , "
ffd38eb8 execute cr
       ffd38f4c execute ffd38edc execute cr
       ffd38efc execute ." , " ffd38f18 execute cr
    then  cr cr ffd2bdb8 execute 0= if
       ." The IDPROM contents are invalid" cr
    then  ffd36378 execute if
       ." Force Keyboard Mode: Using input device keyboard anyway."
       cr
    then  ffd38f68 execute " banner+" do-drop-in ;
install-console
banner

In order to use that resolution, you would then also set the nvram
parameter accordingly, in this case:
setenv output-device screen:rPAL

So long,
Arno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sunhelp.org/pipermail/rescue_sunhelp.org/attachments/20220428/627cc4a1/attachment.html>