Re: [Qemu-devel] [RFC v2 23/23] 40p: Add an IBM 8514/A graphics card

[Blue Swirl]

On Sun, Jun 19, 2011 at 1:04 PM, Andreas Färber <address@hidden> wrote:
> Am 18.06.2011 um 22:42 schrieb Blue Swirl:
>
>> On Thu, Jun 16, 2011 at 3:02 AM, Andreas Färber <address@hidden>
>> wrote:
>>>
>>> The IBM E15 is equivalent to an S3 Vision864.
>>>
>>> Lacking S3 SDAC (86C716) support, the DAC indizes are translated
>>> to greyscale colors. This works sufficiently to observe firmware
>>> boot progress.
>>>
>>> Cc: Hervé Poussineau <address@hidden>
>>>
>>> Fixed off-by-one drawing issue.
>>> Replaced hardcoded color for RECT.
>>> Separate I/O debug output for readability.
>>> Start cleaning up the naming s3 vs. ibm8514.
>>> Prepare support for DAC_MASK, DAC_R_INDEX, DAC_W_INDEX, DAC_DATA regs.
>>>
>>> Cc: Roy Tam <address@hidden>
>>> Signed-off-by: Andreas Färber <address@hidden>
>>> ---
>>>  Makefile.objs                   |    1 +
>>>  default-configs/ppc-softmmu.mak |    1 +
>>>  hw/pci_ids.h                    |    3 +
>>>  hw/ppc_prep.c                   |    2 +
>>>  hw/vga-ibm8514.c                |  780
>>> +++++++++++++++++++++++++++++++++++++++
>>>  5 files changed, 787 insertions(+), 0 deletions(-)
>>>  create mode 100644 hw/vga-ibm8514.c
>
>>> diff --git a/hw/vga-ibm8514.c b/hw/vga-ibm8514.c
>>> new file mode 100644
>>> index 0000000..a87afe1
>>> --- /dev/null
>>> +++ b/hw/vga-ibm8514.c
>
>>> +// 40f3 = CMD_CMD_RECT | CMD_INC_Y | CMD_YMAJAXIS | CMD_INC_X | CMD_DRAW
>>> | CMD_PLANAR | CMD_WRTDATA
>>> +// 4331 = CMD_CMD_RECT | CMD_16BIT | CMD_PCDATA | CMD_INC_X | CMD_DRAW |
>>> CMD_WRTDATA
>>> +// c0b3 = CMD_CMD_BITBLT | CMD_INC_Y | CMD_INC_X | CMD_DRAW | CMD_PLANAR
>>> | CMD_WRTDATA
>>
>> C89 comments?
>
> Yeah, and it could use an explanation: It's a decode table for debug output
> from the command register.
>
>>> +static VMStateDescription vmstate_ibm8514 = {
>
> Missing .name - crashes in some pstrcpy() without it. Better error handling
> would be nice.
>
>>> +    .version_id = 1,
>>> +    .minimum_version_id = 1,
>>> +    .fields = (VMStateField []) {
>>> +        VMSTATE_END_OF_LIST()
>>> +    },
>>> +};
>
>>> +static void my_update_display(void *opaque)
>>> +{
>>> +    VGACommonState *s = opaque;
>>> +    int w;
>>> +    uint8_t *vram;
>>> +    uint8_t *data_display, *dd;
>>> +    int x, y;
>>> +    unsigned int (*rgb_to_pixel)(unsigned int r, unsigned int g,
>>> unsigned int b);
>>> +
>>> +    if (ds_get_width(s->ds) != 640 || ds_get_height(s->ds) != 480) {
>>> +        qemu_console_resize(s->ds, 640, 480);
>>> +    }
>>> +
>>> +    switch (ds_get_bits_per_pixel(s->ds)) {
>>> +        case 8:
>>> +            rgb_to_pixel = rgb_to_pixel8;
>>> +            w = 1;
>>> +            break;
>>> +        case 15:
>>> +            rgb_to_pixel = rgb_to_pixel15;
>>> +            w = 2;
>>> +            break;
>>> +        case 16:
>>> +            rgb_to_pixel = rgb_to_pixel16;
>>> +            w = 2;
>>> +            break;
>>> +        case 32:
>>> +            rgb_to_pixel = rgb_to_pixel32;
>>> +            w = 4;
>>> +            break;
>>> +        default:
>>> +            BADF("unknown host depth %d\n",
>>> ds_get_bits_per_pixel(s->ds));
>>> +            return;
>>> +    }
>>> +
>>> +    vram = s->vram_ptr;
>>> +    /* XXX: out of range in vram? */
>>> +    data_display = dd = ds_get_data(s->ds);
>>> +    for (y = 0; y < 480; y++) {
>>> +        for (x = 0; x < 640; x++) {
>>> +            unsigned int color;
>>> +            color = (*rgb_to_pixel)(vram[0], vram[1], vram[2]);
>>> +            memcpy(dd, &color, w);
>>
>> Please take a look at tcx.c for a 8 bit mode frame buffer with palette
>> translation. Also VGA_DIRTY bit handling should be added to this loop
>> to speed it up.
>
> Will look into it.
>
> I doubt this is causing the long delays though.

The difference is that only areas which have been written after last
update are copied to display instead of updating the whole screen
every time. IIRC for TCX it was a major speedup.

> * There's an unhandled write to the PCI card's config address 0x4, for which
> I have no documentation.
> * Generally, there are some unhandled writel to 0x680, which look like IBM
> progress codes (but I didn't find a manual to decode them - Hervé?), and
> * a frequent writeb to 0x690 with value 0x1 or 0x3 (some activity LED
> maybe?).
> I thought it might be trying to access the missing NCR 53C810 SCSI but saw
> no indication of that.
>
> Andreas