On 3/26/2013 12:24 PM, Artyom Tarasenko wrote:
On Tue, Mar 26, 2013 at 4:08 PM, Bob Breuer
On 3/26/2013 6:13 AM, Artyom Tarasenko wrote:
It looks like we will have more framebuffers
beside TCX in the near future.
One way to use them would be to make new machines combining a base
machine name with a framebuffer name, like ss5tcx and ss5cg3, but I
guess this would produce too many machines if we have more than 2
Should the "-vga" option be (mis)used for selecting a framebuffer?
They are not called "VGA" in the wild, but maybe the name VGA is
obvious enough for a modern user? After all there is already a "-hda"
option in the SPARCStation-5 emulation command line, although in the
non-emulating world no one calls scsi disk "hda".
Or should an architecture-specific option, like -framebuffer be added?
I would like to see -device used. With a better sbus framework, adding
multiple video devices on sparc32 should be really easy to do.
I just looked at how "-device cirrus-vga" works. To get -device to
override the default video, we need to add minimal support into vl.c to
recognize each video device and handle the default_vga flag. Then
sparc32 could limit itself to handling either VGA_NONE or VGA_STD when
it adds the default video.
Oh, that's even better!
And then how would the OpenBIOS find out what framebuffer to use?
For a single display device, can it do just like OBP? Run all FCode
roms, then find the display device in the device tree.
For multiple devices, how to select the primary? Possibly just use the
first one found. OBP provides some control over this with
sbus-probe-list. As a parallel question, for a PC with 2 PCI video
cards, which one gets used as the BIOS display? Just trying
"qemu-system-i386 -device cirrus-vga -device cirrus-vga" gives an error
about RAMBlock already registered.
Would -device cg3 add the FCode ROM? Or do we
need another -device for that?
The FCode ROM should be integrated with the device, similar to a PCI
device with an expansion rom. The SBUS specification defines a rom to
be at offset 0 of the slot. Probably setup a memory region container
for each sbus slot so that the device addresses are relative to the slot
base and isolated from the system address space.
For the existing TCX, looks like it also has space for a rom at offset
0. See ftp://ftp.rodents-montreal.org/pub/mouse/docs/Sun/S24/memory-map
So as a stepping stone, should we create an FCode ROM for TCX?
Sounds reasonable to me, but
- afaik the current TCX implementation is written in C, no Forth. So
maybe it's easier to keep the current implementation in OpenBIOS and
just add some kind of auto-detection.
- I'm not a graphic guy. :) I run qemu -nographic whenever possible.
So I'd wait till someone from the graphic side comments on it.
linux/sparc and solaris/sparc under qemu blog: