Re: [hatari-users] AssemPro Debugger Hang

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

Sorry for the late reply.

On 5/15/20 1:35 PM, Mike Harbour wrote:
> Thanks for your detailled info about GEMDOS HD.
>
> > Please provide "--trace gemdos" Hatari output from
> > successful and failing runs, so that I can see
> > what fails (but shouldn't).
>
> I have attached a log file and a trace file of the procedure failing.

AssemPro doesn't seem to do anything fancy with GEMDOS according to 
trace, So GEMDOS emulation
itself doesn't look like an issue.

=> It would be better to track all OS calls with:
	--trace os_all

It's also better if you don't redirect trace
output to a separate file.  That way we can see
after which OS call the problems start.  I don't
think the problem is OS calls though.


> I have edited them slightly to delete the many repetitions of a particular warning message,
> and to annotate at the beginning the intent.


Looking at the errors:
----------------
....
DEBUG: Loaded TOS version 1.04, starting at $fc0000, country code = 3, PAL
....
DEBUG: Illegal ROMmem wput at 00fc92d6
WARN : Bus Error writing at address $fc92d6, PC=$fc9396 addr_e3=fc939a 
op_e3=211f
----------------

This is odd.  It seems that your TOS 1.04 tries to
modify it's own code/data in ROM, which obviously
won't work as ROM is read-only.


I tried several TOS v1.04 versions, and they all did just:
----------------
DEBUG: Bus error wput at 0041fffe
WARN : Bus Error writing at address $41fffe, PC=$fc0170 addr_e3=fc0174 
op_e3=3302
WARN : Bus Error reading at address $ffff8a00, PC=$fc0ee0 addr_e3=fc0ee2 
op_e3=4a68
----------------

I.e. 4MB RAM and Blitter checks, nothing like
your TOS version.

Are you sure your TOS version is OK?


Rest of the errors:
----------------
WARN : Bus Error reading at address $0, PC=$0 addr_e3=2 op_e3=4e75
WARN : Bus Error reading at address $0, PC=$0 addr_e3=2 op_e3=4e75

....this line repeated about 200 times.... (deleted)
----------------

Is something trying to execute code from address zero, which is 
obviously is bad.


> I tried to generate the same files for the procedure succeeding, but was not able to for the following reason:
> -when using the --trace gemdos switch, a cartridge image appears on the ATARI desktop, which has the hatari.tos application in it.
> -when the cartridge image is present, the original 'AssemPro Debugger Hang' symptom occurs.

Can you verify that it hangs even without GEMDOS
HD emulation being enabled, just having the
cartridge present & GEMDOS tracing enabled is
enough?

There have been some minor fixes to how GEMDOS
emulation and its interaction with the cartridge
code works since latest Hatari release.

Can triy latest Hatari snapshot builds, or
building Hatari from source and test that?


> -I have not found a way around this yet, (when I 'uninstall' this cartridge from the Atari desktop, the symptom reoccurs.

Cartridge image has a bit of native code to help
handling TOS side allocations for GEMDOS calls,
mainly Pexec.

I think that's still needed even for GEMDOS
tracing despite the rewrite Thomas did to minimize
GEMDOS HD emulation needs for the native cartridge
code.

Thomas?


> Many thanks for your attention in this problem. In generating these files, I'm seeing more of Hatari's facilities, and how they can be useful in my programming and learning about assembly language. It's good stuff!

To get the latest features, it's best if you can
build Hatari from sources, as time between Hatari
releases can sometimes be a bit long, and time
between those getting to distributions is even
longer....


	- Eero

PS. Note that you can use autostart also with
images, just specify the drive / path:
  hatari --auto 'A:ASSEMPRO.PRG' disk-a.st