On Wed, Mar 27, 2013 at 3:54 PM, Bob Breuer breuerr@mc.net wrote:
On 3/26/2013 12:24 PM, Artyom Tarasenko wrote:
On Tue, Mar 26, 2013 at 4:08 PM, Bob Breuer breuerr@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?