VDI questions

[mikro]

If you really like the idea, I wouldn't give up so early. Software can be always fixed but developing hardware is far more harder. :)

[stormy]

Isn't that just normal behavior on anything that isn't 16bit/24bit true colour? Like, if I open Papyrus in Mint using my ATI graphics card in 256 colours, it totally messes up the desktop palette behind the app, until I close Papyrus (same for other apps too) And this is using NVDI. So I wouldn't say you're discovering something unique? Unless there are two completely different palette problems with different reasons behind them, I don't know.

[pixelpusher]

Isn't that just normal behavior on anything that isn't 16bit/24bit true colour? Like, if I open Papyrus in Mint using my ATI graphics card in 256 colours, it totally messes up the desktop palette behind the app, until I close Papyrus (same for other apps too) And this is using NVDI. So I wouldn't say you're discovering something unique? Unless there are two completely different palette problems with different reasons behind them, I don't know.

If I understood it right, then there's no hardware palette in Badwolf's 8 bit format (it's 256 colors, but with a 3-3-2 bit rgb format - resulting a "coarse" resolution for the blue component).

A software palette (if already up and running now) should avoid any interference - assuming it is per virtual workstation and not global for the device - and if that's case, then there could be indeed a problem in the transformation code of the driver (looking at the screenshot).

[Badwolf]

If you really like the idea, I wouldn't give up so early. Software can be always fixed but developing hardware is far more harder.

Thanks, Mikro. I'll carry on playing with it for now, but like Jean says, if the application software makes assumptions there isn't much I can do about that.

Isn't that just normal behavior on anything that isn't 16bit/24bit true colour? Like, if I open Papyrus in Mint using my ATI graphics card in 256 colours, it totally messes up the desktop palette behind the app

That's exactly what I want to avoid by doing 8 bit true colour. You've described palette-based (colour look up table/CLUT) modes. Mine doesn't have that.

Mine's the 'sub-optimal' 332 format describe at the top of https://en.wikipedia.org/wiki/8-bit_color

A software palette (if already up and running now) should avoid any interference - assuming it is per virtual workstation and not global for the device - and if that's case, then there could be indeed a problem in the transformation code of the driver (looking at the screenshot).

Annoyingly there seem to be some software that uses multiple Virtual Workstations, but sets the palette for only one. Or at least that's what seems to be going on in a couple of places, but I could be wrong. Changing to a global palette (so the last request wins) didn't seem to affect anything, so it may be that actually it's a bit pattern assumption (à la Jean) kicking in.

Still need to fix some other problems before worrying about that, though. My Expand function is all wrong (hence the white icons in my screenshot) and blitting overlapping windows in the desktop is off by a number of pixels.

But thank you everyone for the help and encouragement.

BW

[Badwolf]

Actually, one other question whilst I'm thinking about it.

A related, but not quite the same project comes from my work on PiStorm.

Here you can have a virtual graphics card in the Raspberry Pi, displayed on the HDMI port with very quick memory access.

So obviously I've set up a 16-bit VGA mode on my STE:-

Screenshot_2022-11-02_20-22-38.png

BUT!

The system font is wrong -- it's still the small system font picked up, I presume, from the low resolution the system booted in and all the icons in Vision (and some dialogue boxes) are half height.

Can anyone point me at the bit of the OS I need to fondle in FVDI to correct this?

Cheers,

BW

[stormy]

Hope crap BW you did it!!! Hdmi 16bit output from pi storm!!! Wouldn't the font be chosen in assign.sys ?

[Eero Tamminen]

The system font is wrong -- it's still the small system font picked up, I presume, from the low resolution the system booted in and all the icons in Vision (and some dialogue boxes) are half height.

Can anyone point me at the bit of the OS I need to fondle in FVDI to correct this?

Check what Hatari VDI mode does: https://git.tuxfamily.org/hatari/hatari ... vdi.c#n970

(EmuTOS sources could also be of interest, but I cannot point where the calculations are done.)

[ThorstenOtto]

The only place in fVDI i found for this, is here: https://github.com/freemint/fvdi/blob/m ... stn.c#L350 It does not seem to modify the default font in the linea variables though, so this might still be set by the ROM VDI from the boot resolution.

In EmuTOS, it is done here: https://github.com/emutos/emutos/blob/m ... ext.c#L604 (the default font is shortly after set by comparing this value)

So both use the same heuristic: if vertical resolution is >= 400, use 8x16 font, else use 8x8 font

[Badwolf]

Check what Hatari VDI mode does: https://git.tuxfamily.org/hatari/hatari ... vdi.c#n970

The only place in fVDI i found for this, is here: https://github.com/freemint/fvdi/blob/m ... stn.c#L350 It does not seem to modify the default font in the linea variables though, so this might still be set by the ROM VDI from the boot resolution.

In EmuTOS, it is done here: https://github.com/emutos/emutos/blob/m ... ext.c#L604 (the default font is shortly after set by comparing this value)

Thank you both! I hadn't considered Line-A variables for that one.

I always forget Line-A as, in my mind, it's only for ST Modes. But I think that's actually only true of the functions, the variables are still a starting point for some things, aren't they?

Thanks again, I'll have a play with that.

BW

[ThorstenOtto]

The point is, that the AES uses the current font to obtain the character sizes for the normal and small font ("small" here is the one that is used for icon texts). In Emutos, this is done here:

https://github.com/emutos/emutos/blob/m ... raf.c#L405

TOS essentially does the same.

[mfro]

This might be caused by two recent commits (that appeared unrelated, but apparently aren't). At least I've seen wrong (too small) font sizes with the bitplane driver as well. Not sure if it's the same issue, but worth a try.

Can you recompile with these commits reverted:

Code: Select all

git revert 7689c70 60934b6

to see if you have the same issue??

(https://github.com/freemint/fvdi/pull/3 ... 1126942949)

[Badwolf]

Can you recompile with these commits reverted:

Code: Select all

git revert 7689c70 60934b6

to see if you have the same issue??

Mfro!

Sorry, I made a mistake previously -- I was using the new driver, but not the engine I compiled.

Sure enough, these reverts solve the problem for me!

Apologies for the errant message previously (included below).

BW


WRONG MESSAGE:

Hi Mfro,

Many thanks for that, but I've given that a try and it makes no difference at my end, I'm afraid.

Interestingly starting FVDI from high res doesn't fix the issue either. It must default to the 9 point font.

Trying to figure out how to hack the Line-A variables ATM.

Cheers,

BW

[Badwolf]

!!!

Hey Steve,

I wouldn't call it a complete solution, but how's it look now?

Screenshot_2022-11-03_21-38-43.png

BW

[m0n0]

Sorry for such a noob question, but I tried to understand this thread, and so I analysed the color count of the image posted above. Imagemagick says:

69945 colors.

Command used: identify -format "%k" Screenshot_2022-11-03_21-38-43.png

So, even with some transformation and conversion applied - is 69945 an realistic value for an 8 bit true color image? This is much more than 8 bit can hold, at least from my understanding.

Probably I'm getting something totally wrong... but I would like to understand this, anyway.

My definition of true color: If there is any palette involved at any time (in this piece of art), it can not be called true color.

BTW: nice looking result

[m0n0]

Interesting! But looks only monochrome and 16bit color modes are supported:

Code: Select all

                  subq.w   #1,d0          ;nur eine Ebene, monochrom?
                  beq      vr_trnfm_mono
                  sub.w    #16-1,d0       ;16 Ebenen?
                  bne.s    vr_trnfm_exit

Cheers,
Jean

Nope, "16 Ebenen?" translates to "16 color planes?" which results in 4 bit (not 16).

[ThorstenOtto]

16 planes means 16 bits, not 16 colors.

[mfro]

...
Probably I'm getting something totally wrong... but I would like to understand this, anyway.
...

You probably missed Badwolf's switch from the 3x2x2 (8 bit - 256 colour) hardware originally discussed to the PiStorm-based 16-bit HDMI graphics halfway down the page? That last screenshot is indeed 16-bit true colour on the latter hardware.

And yes, it's a pretty one

[JeanMars]

Hi Badwolf,

I wouldn't call it a complete solution, but how's it look now?

Nice! What did you do? At some point, I was even about to put the blame on VISION itself about bad icon rendering

Cheers,
Jean

[dml]

This looks fun. There's something I'd like to try if I had one of these attached to my MegaST...

[Badwolf]

Probably I'm getting something totally wrong... but I would like to understand this, anyway.

You probably missed Badwolf's switch from the 3x2x2 (8 bit - 256 colour) hardware originally discussed to the PiStorm-based 16-bit HDMI graphics halfway down the page? That last screenshot is indeed 16-bit true colour on the latter hardware.

Sorry, yes -- it's two projects in one thread (as I'm using fVDI for both -- the learning curve's less steep than NVDI for now).

The first few screenshots were of Hatari simulating a Mega ST with another program simulating my cartridge port graphics card. I'm aiming at 8-bit VGA on that and am trying to do a paletteless 3-3-2 bits 'true colour' driver.

The last couple of screenshots are from my PiStormST work where I'm using a similar technique to have a virtual 'graphics card' rendered on the Raspberry Pi and output via HDMI. This is a much more normal 16-bit display. 5-6-5bit RGB.

Since I'm really bad with TOS and the techniques I'm using so similar, I've kept my questions on the same thread.

Cheers,

BW

[Badwolf]

I wouldn't call it a complete solution, but how's it look now?

Nice! What did you do? At some point, I was even about to put the blame on VISION itself about bad icon rendering
Cheers,
Jean

Thanks Jean, but it's actually a different project -- that's a proper 16-bit screen and Vision is quite happy with that.

The only problem I was having with Vision there was that it seems to calcualte its icon height and its window height differently, so icons were not fitting in the window. this is probably technically a bug, but i would have thought one unlikely to occur very often in real life.

This was made visible because of an fVDI issue causing the system font to remain at 8x8 instead of 8x16 after my resolution change.

BW

[Badwolf]

This looks fun. There's something I'd like to try if I had one of these attached to my MegaST...

Thanks.

It's not really viable yet (because of that bloody ST-RAM read performance issue!), but it's a fun demo.

Screenshot_2022-11-03_22-05-51.png

...shall I do a 1920x1080 one..?

BW

[mfro]

...
Sure enough, these reverts solve the problem for me!
...

I have now reverted both offending commits in the upstream repository until somebody comes up with a solution.

If the choice is between having correct font sizes in the desktop and fix31 font height calculation, I opt for the former.

[JeanMars]

Hi badwolf,
Thanks for the update, there should à b un in vision when it comes to low/unsual resolutions. Could you please post vision.log ?

[Badwolf]

Hi badwolf,
Thanks for the update, there should à b un in vision when it comes to low/unsual resolutions. Could you please post vision.log ?

Hi there. Unfortunately as it's working now, I don't see the issue any more -- if I can precipitate it again, I will do.

BW