> If you have contrary test-data for different VDI bit-depths from:
> - multiple TOS versions (1.04, 2.06, 3.06 and latest EmuTOS),
Tos 1.04 may not work with screen sizes larger than 32KB. Without patches, at least the mouse drawing routines have problems then IIRC.
But 2.06 and above don't have that restriction.
> Besides, as mentioned in the Hatari manual, in monochrome 300kB is
> enough for resolutions like FullHD (1920×1080), WUXGA (1920x1200)
> and QWXGA (2048x1152), so it's not *that* small...
But only for monochrome. With 16 colors, the largest i can get is 896x672, that is an annoying restriction. 256 colors isn't even supported in TT-mode yet.
BTW. there is definitely something wrong with that routine:
if (bIsEmuTOS || TosVersion >= 0300 || ConfigureParams.Memory.STRamSize_KB < 4*1024)
The 0300 was maybe meant to be 0x300. But it does not work anyway, because TosVersion isn't even set at that point. The code falls into the else, which reads:
if (VDIWidth > 3*128 && (VDIWidth-128) % 256)
VDIWidth -= 128;
I don't get that. Why is 1280 not a valid screen width? It is reduced by 128. Where does that strange formula come from? I also don't understand what the screen size has to do with wether more than 4MB ST memory is available.
When i disable the call to VDI_ByteLimit, and that routine above, i can get larger resolutions without problems:
with 3.06:
with 2.06:
With EmuTOS:
all three are 1280x960, in 16 colors. Didn't test NVDI, but if that does not work, there should be a hint in the manual that this is incompatible, or a newer version of NVDI is needed, rather than disabling it for all others.