On Wed, Mar 27, 2013 at 3:54 PM, Bob Breuer <breu...@mc.net> wrote: > On 3/26/2013 12:24 PM, Artyom Tarasenko wrote: >> On Tue, Mar 26, 2013 at 4:08 PM, Bob Breuer <breu...@mc.net> wrote: >>> 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 >>>> framebuffers. >>>> >>>> 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. Blue? Mark? -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu