Re: [hatari-devel] TT-RAM handling regression

[ Thread Index | Date Index | More Archives ]

Le 28/08/2018 à 23:53, Eero Tamminen a écrit :
Hi Nicolas,

I noticed a regression.

When using TT mode with TT-RAM, Hatari claims to enable 32-bit address,
but that seems to be propagated to the WinUAE CPU core only after
emulation is already running (with SPCFLAG_MODE_CHANGE flag), not
before memory ranges are initialized / when it would be needed.

As result, no TT-RAM is allocated.  I think this was broken by
commit ed8214691485 earlier this month.

(One needs now to specify "--addr24 off" also with TT emulation
when wanting TT-RAM, not just with Falcon emulation like earlier.)

Yes, I saw sthg similar with falcon mode, I will look into this.

Hatari state initialization sequence is quite "fragile", because
some settings cause (especially TOS version) cascade changes to
other settings, so things need to be done in very specific order.

-> There may be other things that delaying the CPU core changes
    at emulation initialization has broken.

I agree things need to be done in specific order, bu sometimes we're caught in some nearly circular loops where low level stuffs require higher level stuffs to be initialized then those higher functions (tos version for example) modify low level parameters (force HW settings that are not compatible with the selected tos), this makes it rather hard to follow the startup process.

This is why I tried to have a better interface with the cpu core lately, removing lots of duplicated code.

Hopefully, people will use current devel version of hatari to track possible regressions and it will be stable when next version will be released.


Mail converted by MHonArc 2.6.19+