Re: [hatari-devel] Possible 1.7 regression

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On keskiviikko 12 kesäkuu 2013, Troed Sångberg wrote:
> I unfortunately don't have a Windows or Linux setup to test with.
> 
> I've done some further debugging. As I wrote, all looks ok and executes
> ok when run from an emulated harddrive. When run from floppy the TOS
> commands (F_OPEN, F_READ and F_CLOSE) return all the correct values -
> but there are issues with the loaded data if my program runs from the
> AUTO folder. New information since my last mail is that it works fine if
> I first boot to desktop and then run the program (now from the root of
> the floppy though) off the floppy image.
>
> My code loads something to a specific memory address, and comparing the
> data I load to what ends up there show the following differences:
> 
> 1) The first 1024 bytes are zero.
> 2) From offset 2560 and onwards everything looks ok. There are a few
> bytes that are and should be zero around $a00 which means it could be a
> few bytes later as well.
> 3) I don't immediately recognize the data between 1024 and ~1760, but it
> doesn't look random (see below).
> 4) From ~1760 to 2560 it's all zeroes again.
> 
> I load a single large (~80KB) block with one gemdos call - I doubt
> there's much room in that code for partial loading of content (and, as I
> wrote, it works on earlier versions of Hatari as well as on target hw).

Can you reproduce your issue with EmuTOS?  As debug symbols and
sources are available for that, it's much nicer for debugging TOS
call related issues.


Although you would run things from a floppy disk, you should be
able to get GEMDOS tracing by providing directory to Hatari before
giving the floppy image:
	hatari --tos etos512k.img -d . --trace gemdos floppy.st


If you want to see return values to GEMDOS calls, do:
echo "b  GemdosOpcode ! 0xFFFF :noinit :quiet :file entry.ini" > debug.ini
echo "b pc = "NextPC"  :noinit :quiet :once :file exit.ini" > entry.ini
echo "e d0" > exit.ini

and then add "--parse debug.ini" to Hatari options.

"debug.ini" will then be parsed at Hatari startup and it will set
a breakpoint that parses "entry.ini" whenever GEMDOS is called.
"entry.ini" will on its turn set ("single-shot") breakpoint for the
instruction following the GEMDOS call, which will execute command from
"exit.ini" to show GEMDOS call return value in D0.


(If one enables profiling, one can get also stack traces to calls,
and by enabling history one can get also instructions leading to
the breakpoint.  All kinds of things can be automated with
breakpoint chaining.)


	- Eero