<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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:<br>
</p>
<p>On 27.04.22, 22:28, Malte Dehling <a
class="moz-txt-link-rfc2396E" href="mailto:mdehling@gmail.com"><mdehling@gmail.com></a>
wrote:
</p>
<blockquote type="cite" style="color: #007cff;">Hi, I would also be
interested in these docs!
<br>
<br>
Arno, do you have any pointers to arbitrary resolutions on cg3?
From the
<br>
firmware side it looks like it shoulnd?t be hard to do, but the
cg3 I?ve
<br>
seen use fixed frequency oscillators rather than programmable
clock
<br>
generators like some later cards (tgx/tgx+ for example.) Did you
make any
<br>
hardware modifications? My cg3 cards and classic have extra space
for
<br>
additional oscillators and that is something I?ve been meaning to
try out.
<br>
<br>
Cheers,
<br>
Malte
<br>
</blockquote>
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 <span
class="moz-smiley-s1" title=":-)"></span> 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:
<br>
SPARCclassic cg3 Dot Clock frequencies at Pin 6 of U0902 (KS82C671)
<br>
<br>
rom measured
<br>
entry freqency
<br>
<br>
00 13,503808
<br>
01 39,960347
<br>
02 49,964232
<br>
03 54,015360
<br>
04 60,017056
<br>
05 62,455249
<br>
06 64,143230
<br>
07 64,987222
<br>
08 68,676656
<br>
09 70,568441
<br>
0a 72,920728
<br>
0b 74,271082
<br>
0c 74,924518
<br>
0d 77,422004
<br>
0e 79,920675
<br>
0f 81,023015
<br>
10 82,659876
<br>
11 84,399012
<br>
12 88,618968
<br>
13 90,025668
<br>
14 92,838980
<br>
15 94,526885
<br>
16 95,621874
<br>
17 97,576223
<br>
18 99,928508
<br>
19 105,395926
<br>
1a 108,031000
<br>
1b 114,032477
<br>
1c 117,033350
<br>
1d 135,038500
<br>
1e 189,054100
<br>
1f - 0 -
<br>
<br>
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.
<br>
(...) 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@0,10000000/sbus@0,10001000/cgthree@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):
<br>
"An examination of the FCode of the cg3 revealed that a resolution
set-up word looks like this:
<br>
<br>
: r1152x900x76
<br>
" 10,02,43,175,03,179,12,04,43,187,0,26,76,1152,900"
<br>
" 1152x900-76" xdrstring " params" attribute
<br>
;
<br>
<br>
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.
<br>
<br>
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.
<br>
The parameters are (from left to right, example value given in
parentheses):
<br>
<br>
End of vertical sync/Start of vertical back porch in lines after
top-of-frame (10)
<br>
End of vertical front porch/Start of vertical sync pulse in lines
after top-of-frame (02)
<br>
End of vertical back porch/Start of visible display in lines after
top-of-frame (43)
<br>
End of visible display in pixels after beginning of line, low byte
(175)
<br>
End of visible display in pixels after beginning of line, high byte
(3)
<br>
(That means that the transition takes place at a count of 3*256
+ 175 = 943 lines)
<br>
End of horizontal sync pulse during vertical sync (179)
<br>
End of horizontal sync/Start of horizontal back porch in pixels*8
after start-of-line (12)
<br>
End of horizontal front porch/Start of horizontal sync in pixels*8
after start-of-line (04)
<br>
End of horizontal back porch/Start of visible display in pixels*8
after start-of-line (43)
<br>
End of visible display in pixels*8 after start-of-line (187)
<br>
(meaning the actual transitions take place at count 32, 96, 344,
1496)
<br>
Video Clock divider select (0)
<br>
Video Clock frequency select (26)
<br>
Vertical Frequency in Hz (76)
<br>
Horizontal resolution in pixels (1152)
<br>
Vertical resolution in pixels (900)."
<br>
<br>
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:
<br>
probe-all
<br>
" /iommu/sbus/cgthree" select-dev
<br>
: rPAL
<br>
" 04,02,32,56,01,254,11,03,20,100,03,02,50,640,280"
<br>
" PAL-RGB" xdrstring " params" attribute ;
<br>
unselect-dev
<br>
: banner
<br>
" banner-" do-drop-in suppress-banner ffd38f98 execute #line @
ffd38f64 execute
<br>
! oem-banner? if
<br>
cr ffd38f4c execute oem-banner type cr cr
<br>
else
<br>
ffd38f4c execute ffd38fd4 execute type ." , " ffd379b4 execute
cr
<br>
ffd38f4c execute ffd38e90 execute ffd2ec10 execute ." , "
ffd38eb8 execute cr
<br>
ffd38f4c execute ffd38edc execute cr
<br>
ffd38efc execute ." , " ffd38f18 execute cr
<br>
then cr cr ffd2bdb8 execute 0= if
<br>
." The IDPROM contents are invalid" cr
<br>
then ffd36378 execute if
<br>
." Force Keyboard Mode: Using input device keyboard anyway."
<br>
cr
<br>
then ffd38f68 execute " banner+" do-drop-in ;
<br>
install-console
<br>
banner
<br>
<br>
In order to use that resolution, you would then also set the nvram
parameter accordingly, in this case:
<br>
setenv output-device screen:rPAL
<br>
<br>
So long,
<br>
Arno
<br>
</body>
</html>