Re: [hatari-devel] VDI resolution limits

[ Thread Index | Date Index | More Archives ]


I've been bisecting this, and it's actually a *very* old regression.

I had to go from current Hatari down to Hatari v0.40 from 2003, until
I started to get versions where this works.  During which time Hatari
build system (make -> autotools -> cmake), dependencies and command
line options options have changed *a lot*.

Latest Hatari version where 1024x768 VDI mode works with TOS v1.04
is v0.90, and it doesn't anymore work in v1.0.

Guilty commit is this one from 2007:
changeset:   829:363c98718f37
user:        thothy
date:        Sat Nov 24 19:45:49 2007 +0000
summary: The VDI resolution screen size is now calculated in a more flexible way.

It removed padding between VDI screen and RAM end.

After this, TOS dies trying to access memory outside of RAM
(here, with 4MB):
	Bus error wget at 00400000

* It's not because missing mouse drawing clipping as mouse can
  move *within* the bottom right 16x16 area without a crash
* Crash happens when mouse hotspot is vertically within 16 pixels
  of the screen bottom and it crosses the 16 pixel offset from
  the right side of the screen in horizontal direction

-> I'll add a small buffer after VDI screen to avoid this, and
   remove the VDI screen size limits with old TOS versions.

Any idea why these mouse related reads happen only with VDI mode,
and only when mouse moves *horizontally* in this area?

	- Eero

PS. To facilitate the bisecting, I tagged all the Hatari releases
in repository (tags were missing for v0.x versions).

On 05/01/2018 02:31 AM, Eero Tamminen wrote:
On 04/30/2018 01:28 AM, Thorsten Otto wrote:
On Sonntag, 29. April 2018 23:18:02 CEST Eero Tamminen wrote:
Crashes when you move mouse to bottom right corner.

Cannot reproduce that.

It doesn't crash if you use 2MB of RAM, but does if you use *>=4MB*.

And note that you may need to move the mouse in the *16x16 area*
at the *bottom right corner* of the screen for *several seconds*
before the crash happens.

If you can debug what actually happens, maybe propose a workaround,
that would be really great!

 > And i don't use --grab or fullscreen.

You *need* to use either of those to be able to reliable move Atari
mouse in the bottom right corner of the Atari screen.

Without them, your mouse is very likely to move out of the Hatari
window instead of moving the Atari mouse cursor in the Atari screen

If there are
really cases where that crashes, then i would guess because VDI and/or blitter are trying to access memory beyond the end of video memory, and that you need
some gap there before end of physical memory (or ROM).

That gap is really a pain in the exterior too.  Some things don't work
if it's larger than the largest normal resolution on given machine,
but TOS memory detection doesn't work if the gap differs from
the actual (VDI) screen size.

But that still does not
have anything to do with the alignment of the screen width.

Cr*p.  I'm able to reproduce the TOS crashes with >=4MB even with
the alignments, just by moving the mouse up to 5 secs in that screen

And I'm seeing them also with 2.0 WinUAE and 2.1 OldUAE, so it's not
core specific, and if it's a regression, it's not a recent one.

I faintly remember this working at some point, but it's possible that
I hadn't just tested mouse in that corner (diligently enough), only
moving it at the bottom of the screen.

Does somebody have prebuilds of earlier Hatari version to check
whether this worked with e.g. v1.4 or v1.8?

It's also not
clear why (aside from the required memory) a screen width of 1280 is valid in
monochrome, but not in color modes.

That's due to 300KB limit.

And it also does not explain the rather
random limit of 300k for video memory.

It was result of testing.  After more than 300kB was used,
some of the GEM programs I was testing, started to crash.

(I would have liked to use 150kB for TT, which is what the largest
TT mode takes, but on request from Uwe, raised it to 300kB to
support FullHD in mono, as that's most common resolution nowadays.)

Do you have somebody who's willing to go through few hundred most
common GEM applications,

That's imho not necessary. Just the hint that extended VDI modes may work or
not, and that it is up to the user to try it out, will be good enough.

What then happens:

* User tries larger VDI mode and is happy that it works

* User tries it with GEM program he's actually interested to use

* If that doesn't immediately crash, he notices that large screen
   gets updated too slowly to be usable (*), so he adds NVDI

And when things crash, users complain and would then be pissed
at us because we wasted their time by providing something that
"isn't even supposed to work".

(*) fast forward mode does make things fast, but it ruins
     mouse interaction, so while it's fine when e.g. using
     TOS desktop and during program startup, it's not really
     an option for actually using most of applications.

User's don't typically read manuals...

Yes, but that also applies to games. You already expect them
to look at the compatibility list when something goes wrong.

Users do have some expectations about problems with game / demo
emulation.  They don't expect problems with GEM programs, because
those work fine (without the VDI mode) on any emulator.  That
makes a difference.

But don't get me wrong. It would be just a nice feature to be able to use
higher resolutions. If you think that it would too much hassle, then i have to
live with the current limits.

What's the use-case where you want those large color resolutions?

(Only one I have for that is GEM NetHack, and it's fine with
640x480 @ 16 colors. Everything else I would want to use with
larger screen is fine, and much faster, in monochrome.)

     - Eero

Mail converted by MHonArc 2.6.19+