Re: [hatari-devel] VDI 2-planes mode |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On keskiviikko 06 maaliskuu 2013, Vincent Rivière wrote:
> On 02/03/2013 22:24, Eero Tamminen wrote:
> IMHO, the best possible thing is to keep the current behaviour for boot
> video mode: ST_LOW for 16 and 4 color modes, ST_HIGH for 2 color mode.
>
> Then *avoid* hacking VDICharHeight to keep the right value determined by
> the OS at startup, depending on the boot video mode. As I told
> previously, only the screen dimensions should be hacked by the extended
> mode patch, not other characteristics such as as VDICharHeight.
>
> In src/vdi.c, function VDI_LineA(), I propose to do:
>
> //STMemory_WriteWord(linea-46, VDICharHeight); /* v_cel_ht */
> VDICharHeight = STMemory_ReadWord(linea-46);
> STMemory_WriteWord(linea-44, (VDIWidth/8)-1); /* v_cel_mx
> (cols-1) ...
>
> Instead of forcing VDICharHeight, we read it from the OS and we determine
> the other values accordingly, using the new screen dimensions.
>
> As a result, the small font is used even in high resolutions, but that's
> the best we can get. Anyway, extended 4 color modes will be rarely used
> in practice.
This works fine for normal TOS and for EmuTOS in ST-mode.
However, in TT & Falcon mode EmuTOS for some reason selects 16-pix font
for >=400 high 4- & 16-color modes, although it doesn't do that in ST/e
mode. Do you know the reason for this inconsistency?
The problem with this inconsistency in EmuTOS is that to avoid
crashes when BIOS console writes text at screen bottom, either
I need to:
1. constrain resolution height to be aligned to 16-pixels
(currently it's 8-aligned for other than mono modes), or
2. hardcode extra rules for EmuTOS.
I guess I can live with 1)... :-)
- Eero