Re: [hatari-devel] Possible 1.7 regression

Followup:

I knew I recognized a few of the numbers as well as the content and it's been bugging me since I sent the previous email. The content loaded at offset 1024 is the same as in the .ST floppy image at offset 512 and 3072. It's the FAT, right? ;)

If so I guess a good description of the problem would be that when my program uses gem bdos file access after having been executed from AUTO the F_READ will have the first 10*256 bytes replaced with the first track (although, with the 512 -> 1024 offset difference so there's something else to it). The rest of the loaded content is fine.

Without having looked at the Hatari source it almost sounds like leftover debug code.

/Troed

On Wed, Jun 12, 2013 at 5:20 PM, Troed Sångberg <troed@xxxxxxxxxxx> wrote:

Hi,

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).

/Troed

The data that gets loaded instead of my file content at offset 1024 starts with this:

030400: f9 ff ff ff 4f 05 05 60 00 07 80 00 09 a0 00 0b ....O..`........
030410: c0 00 0d e0 00 0f 00 01 11 20 01 13 40 01 15 60 ......... ..@..`
030420: 01 17 80 01 19 a0 01 1b c0 01 1d e0 01 1f 00 02 .................
030430: 21 20 02 23 40 02 25 60 02 27 80 02 29 a0 02 2b ! .#@.%`.'..)..+
030440: c0 02 2d e0 02 2f 00 03 31 20 03 33 40 03 35 60 ..-../..1 .3@.5`

030450: 03 37 80 03 39 a0 03 3b c0 03 3d e0 03 3f 00 04 .7..9..;..=..?..
030460: 41 20 04 43 40 04 45 60 04 47 80 04 49 a0 04 4b A .C@.E`.G..I..K

On Wed, Jun 12, 2013 at 3:14 PM, Jerome Vernet <vernet.jerome@xxxxxxxxxx> wrote:
Le 12/06/13 01:23, Troed Sångberg a écrit :

Hi,

I don't want to raise any unnecessary alarms, but as per my post on atari-forum, http://www.atari-forum.com/viewtopic.php?f=51&t=25123#p232595 , I tried out the recent Mac build discussed here on my system. I usually run a 1.6.2 build from june 2012 (that I don't remember if I compiled myself or used someone elses).

I only exchanged hatari.app, no other changes, but suddenly the thing I'm currently coding (which, admittedly, might do some tricky stuff) stopped working in Hatari. The thing is, besides working fine on 1.6.2 my program also works fine on target hw, my regular STE that I make sure to test with as well.

What I see are 22 bombs (which probably isn't indicative, see below), and it doesn't drop out into the debug console (I run with -D). Manual breaks and continues tell me TOS is still doing work.

Hi,

Did you try also with another build for Windows or Linux ? I don't think that your problem are Mac Specific, as there is no change in Hatari Core on the Mac build...

J.V.