|Re: [hatari-devel] emutos-ram and GEMDOS drive emulation|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 03/31/2016 10:53 PM, Thomas Huth wrote:
Am Thu, 31 Mar 2016 21:29:39 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
On 03/31/2016 04:09 AM, Thomas Huth wrote:
Am Thu, 31 Mar 2016 01:11:30 +0200
schrieb Vincent Rivière <vincent.riviere@xxxxxxxxxxx>:
On 07/03/2016 00:34, Vincent Rivière wrote:
1) Hatari must allow to initialize the GEMDOS emulation a second
For the same reason, Hatari GEMDOS drive emulation does not work
after a software reset (Ctrl+Alt+Del).
That's also true for the original TOS (at least for those versions
that support that keyboard combination, like TOS 2.06).
I've committed a fix now (slightly based on your original patch).
Thanks for your detailed report!
While EmuTOS works with this version, and TOS >= v2,
all the older TOS versions get now double bus error
right at start if GEMDOS HD or tracing is enabled:
Bus error wput at 0041fffe
Bus Error at address $41fffe, PC=$fc0170 addr_e3=fc0174 op_e3=3302
Illegal instruction: 000a at 08FA02E2 -> 04FC0B0A
I.e. for some reason PC value returned by WinUAE M68000_GetPC()
has garbage data on the highest byte, and therefore your check
for cartridge area address doesn't match.
Ouch, looks like older TOS versions are not clearing the uppermost byte
of the entry function before jumping to it - the uppermost byte is used
for some configuration bits, see cart_asm.s:
I've now added a test for 24-bit addressing mode, so that the uppermost
byte now gets ignored on old TOS versions, thus it should be working
IMHO it would be good to have is_cart_pc() wrapper
also for old UAE core to minimize differences between
BTW, why did you change the indentation in the old UAE core's
OpCode_SysInit() function? ... that now looks completely strange to me.
Sorry. There was some merge mess when I updated Hatari
and I accidentally commited the wrong way.
I've reverted it now.