Re: [hatari-devel] TT emulation crashes when there is no ACSI drive |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
I only now took a closer look where things are failing:
Bus Error writing at address $23000002, PC=$fa005c addr_e3=fa005c
op_e3=42ae
Write address is around 560MB i.e. bogus memory address.
And code address is at the very beginning of the Hatari cartridge
Pexec code:
---------------------------------------------------------
pexec:
move usp,a0 ; Parameters on user stack pointer?
btst #5,(sp) ; Check if program was in user or
supervisor mode
beq.s p_ok
lea 6(sp),a0 ; Parameters are on SSP
tst.w _longframe.w ; Do we use a CPU > 68000?
beq.s p_ok ; No: A0 is OK
addq #2,a0 ; Skip 2 additional stack frame bytes
on CPUs >= 68010
p_ok:
addq #2,a0 ; Skip GEMDOS function number
tst (a0) ; Test pexec mode
bne.s no_0
; Simulate pexec mode 0
move.l a6,-(sp)
move.l a0,a6
bsr.s find_prog
bsr load_n_reloc
clr.l 2(a6) <==== *** HERE ****
clr.l 10(a6)
move.l d0,6(a6)
move.w #48,-(sp) ; Sversion: get GEMDOS version
trap #1 ; call GEMDOS
---------------------------------------------------------
This part of code and find_prog haven't changed in 14-18 years,
but there's some code later on that's from 2015. Header flag check
and memory clearing at end of load_n_reloc is from 2019-06 though.
It seems like either a6 got overwritten load_n_reloc, or it
somehow cause stack area pointed by a6 to be overwritten. Or
TOS gives "bad" data for Pexec() during AUTO/ in your case,
when TT-RAM is present (which I can't reproduce).
=> Uwe, are there any other programs in AUTO folder? If yes,
do you get the issue also if only NF_SCSI.PRG is in AUTO?
Thomas, any comments?
To recap the currently provided info:
* NF scsidrv client fails, but only when run from AUTO folder,
with TT-RAM enabled and ACSI disabled. Client program doesn't
crash when run from desktop, TT-RAM is disabled, or ACSI drive
enabled
* So far Uwe has tested only with TT emulation + TOS v3 + GEMDOS HD +
CPU prefetch & cycle-exact disabled, with no MMU. He hasn't tested
with MMU, floppy, other HW/TOS versions or with compatible CPU
* Program works with Hatari 2.2.1, but not with some unknown
later Hatari Git version Uwe is using
* Because issue happens in cartridge Pexec code, it should be
reproducible without NF SCSIDRV. However, as I can't reproduce
it, so there's some other factor that Uwe hasn't told yet
- Eero
PS. IMHO minimum info provided in these kind of cases should be output
from "--trace os_base", so that one at least seems what is being
run in which order and at which point the problem happens.