[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Improved memory detection for cgsix
On Sun, 27 Feb 2022 11:12:00 -0800
Malte Dehling <mdehling%gmail.com@localhost> wrote:
> for the TGX+ I can say for certain that it does support single buffered
> mode. The firmware/fcode checks if (width * height *2) <= vmsize (4mb) and
> if so enables double buffering and sets the dblbuf property accordingly.
> This is interesting since no resolution requiring more than 2mb was
> officially supported. The chipset does support acceleration for
> resolutions with widths of 2048 at least, maybe higher (if anyone has a
> copy of the TurboGX Reference Card 800-5112 I would love to check.)
Looking at the 'Sun GX FBC Reference Manual 3.0' right now. It's from
It claims that coordinates for drawing commands must be within the
visible screen, which is obviously bogus. Elsewhere it says coordinates
must be between '-2**14 and 2**14 - 1' or the chip will error out. So
that's probably the actual hw limit.
Otherwise it doesn't say much at all about memory organization.
> I run my tgx+ at 1920x1200 which requires more than 2mb (and a little
> bit if work.) If anyone wants to do the same, you can do this by
> editing nvramrc.
Does the blitter actually work with that? According to the manual
mentioned above the framebuffer's stride is selected by two bits in a
config register, and can only be 1024, 1152, 1280 or 1600. Then again,
the manual is from 1988 so probably doesn't describe the newest chip
> Romain has some code to make that easier here:
> https://github.com/rdolbeau/SunTurboGX . If you don’t mind making
> hardware changes, you can also replace the eeprom and use a modified
> firmware which you can find here:
> https://github.com/1k5/tgx-plus-vesa-mod (sorry, not well documented.)
Alright, I'll definitely dig up a 4MB board and do some experiments. It
would be great if we could use all the memory.
Main Index |
Thread Index |