| Re: [hatari-devel] Extended VDI screen in Falcon mode |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On lauantai 02 helmikuu 2013, Vincent Rivière wrote:
> I noticed that Hatari's "Extended VDI screen" feature did not work in
> Falcon mode.
EmuTOS v0.8.7 boots up and its desktop looks fine for 1 & 4 -plane modes
under Falcon emulation, same as with ST mode.
> This is particularly visible in the latest EmuTOS snapshot which has been
> bugfixed regarding to Hatari's Line A hacks to extend the resolution.
I think this fixed the TOS console font size.
> It works find in ST mode,
And 2-plane mode for ST mode.
> but clearly something is wrong with the VIDEL in Falcon mode.
If so, I think that was EmuTOS regression as v0.8.7 seemed to work
fine in 1 & 4-plane modes.
> You can get the latest EmuTOS snapshot there:
> http://sourceforge.net/projects/emutos/files/snapshots/CVS-20130201/
>
> I made a few tests, and fortunately it seems easy to fix those issues.
1 & 4-plane modes seem to work fine for me with Hatari also with this
EmuTOS version.
(Except for the mouse issue with latest Hatari when using VDI mode.)
> Some initializations occur very early in the TOS/EmuTOS startup process:
> determine the boot video mode, use the appropriate font, etc.
>
> Hatari can extend the resolution (I mean screen dimensions, in pixels) by
> changing the Line A variables when appropriate. But it can't change the
> font sizes, etc. So when Hatari wants to extend the resolution, it has
> to boot in a similar standard video mode, then it can increase the
> screen dimensions afterwards (but not bit depth, etc.). This works fine
> in TOS mode.
>
> To support extended modes on Falcon hardware, I propose that Hatari
> overrides the NVRAM boot video mode. It can be found at offset 0x0e in
> the NVRAM.
Actually, at offset 28, at least if counting in bytes (like Hatari)
and not words (like EmuTOS?). :-)
> Of course the checksum has to be recomputed accordingly.
>
> So: When the "Use extended VDI screen" option is checked and the Machine
> is set to Falcon, patch the NVRAM according to the number of colors
> selected in the dialog box:
>
> 2 colors -> mode 0x0188 (ST High)
> 4 colors -> mode 0x0089 (ST Medium)
> 16 colors -> mode 0x0082 (ST Low)
>
> I made preliminary tests by hacking EmuTOS, this should just work fine.
> I got 1024x768 in 2 and 4 color mode without trouble.
>
> In 16 color mode, I had to decrease the resolution to 800x600.
2 & 16-color modes seem to work fine with EmuTOS without NVRAM hacks.
Only 4-color mode seems to need it.
Attached is a test patch for it.
> There is
> probably another issue related to the size of the video RAM in very high
> resolutions.
1024x600 and 800x768 sizes also worked in 16-colors.
Those take 300kB, 1024x608 didn't anymore work, and that just
takes 4kB more.
304kB is a bit weird limit, so I tried narrower resolutions.
There I got upto 600x1064 (312kB) after which EmuTOS started to panic.
This is IMHO suspicious.
> Feel free to implement that in Hatari, if you like.
> This may also work with TOS 4.04, too.
In 2-plane mode colors are wrong. TOS 4.x seems to crash [1]
if one uses larger than 32kB screen modes, i.e. it's totally useless.
I could try whether setting some larger VIDEL resolution helps,
if somebody gives me a number to use for NVRAM setting...?
[1] Easiest way to test this is moving mouse to the bottom of
the screen -> BOOM.
- Eero
--- a/src/falcon/nvram.c Sun Feb 03 22:24:15 2013 +0200
+++ b/src/falcon/nvram.c Mon Feb 04 00:00:28 2013 +0200
@@ -176,6 +170,27 @@
NvRam_SetChecksum();
}
+ if (bUseVDIRes)
+ {
+ /* Needed for TOS to get correct bit-depth without desktop.inf hacks */
+ switch(VDIPlanes)
+ {
+ case 4: /* set ST-low */
+ nvram[NVRAM_VMODE1] = 0x00;
+ nvram[NVRAM_VMODE2] = 0x82;
+ break;
+ case 2: /* set ST-med */
+ nvram[NVRAM_VMODE1] = 0x00;
+ nvram[NVRAM_VMODE2] = 0x89;
+ break;
+ case 1: /* set ST-high */
+ default:
+ nvram[NVRAM_VMODE1] = 0x01;
+ nvram[NVRAM_VMODE2] = 0x88;
+ }
+ NvRam_SetChecksum();
+ }
+
NvRam_Reset();
}