[hatari-devel] Problem with NVDI and latest hatari sources
Eero Tamminen
oak at helsinkinet.fi
Sun Jan 30 15:57:55 CET 2011
Hi,
On sunnuntai 23 tammikuu 2011, Uwe Seimet wrote:
> Yes, I'm using the old CPU core.
>
> > I guess the issue isn't reproducible if you disable extended VDI
> > resolution and e.g. use TT TOS and TT high resolution?
>
> Yes, if I switch off the extended resolution in the config file before
> starting Hatari the issue is gone. But in this case I have a different
> problem: The Hatari window is placed elsewhere on the screen (looks as
> if the Window manager now places the window at a location not yet used
> by other windows) and the Hatari and X11 mouse cursor are not properly
> synchronized anymore.
To keep mouse cursor in sync, you need to enable mouse grabbing. To have it
in sync from the beginning, you need to have mouse grab enabled from the
beginning. There's a "--grab" command line option for latter and keyboard
shortcut just for former.
If you want cursor to be permanently grabbed, run Hatari in fullscreen
and save that setting.
> > Could you try switching ENABLE_TRACING to "OFF" from cmake
> > configuration, rebuild Hatari and see whether anything changes?
>
> There is no change when setting ENABLE_TRACING to 0.
Ok, so the issue wasn't added AES tracing...
When you earlier said that:
the print preview (as well as the actualprintout) do not correctly
recognize the paper size (A4) anymore. The output is clipped, so that
only the upper left corner is visible.
to what size it's clipped? E.g. size of ST-low or ST-high screen size?
Do similar issues happen with any other software?
> My guess is that NVDI relies on data returned by the actual VDI
> and these data are probably not correct anymore.
They shouldn't have changed...
I need some way to reproduce the issue, otherwise I cannot debug it.
Is this software available somewhere?
(You could try enabling "trace vdi" from the debugger before the issue
happens and try to guess what kind of VDI calls could have the issue.
If you can pinpoint the broken VDI call, that would help.)
>> Could you send your hatari.cfg file so that I can try whether I can
>> reproduce the issue with that? Can you reproduce it if you don't
>> have anything started when the emulated machine boots?
>> What Hatari outputs when the emulation is reseted?
>
> I have added my hatari.cfg as an attachment. During the reboot nothing
> was running, i.e. TOS was still running its RAM test. This is the output
> I get after disabling the extended VDI mode and returning to the main
> menu:
>
> Segmentation fault
With your config I could reproduce the crash and it happened also with v1.4
release.
I've commited a fix to the crash and to another issue revealed by the fix.
- Eero
More information about the hatari-devel
mailing list