Re: [hatari-devel] ENABLE_SMALL_MEM problem

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 23/12/2017 09:16, Thomas Huth wrote:
>   Hi,
>
> I recently tried to compile Hatari with ENABLE_SMALL_MEM again, but it
> is currently broken: Main_Init() calls STMemory_Init() which again
> calls STMemory_Reset() and that accesses IoMem[], causing a
> segmentation fault. IoMem[] is not available in ENABLE_SMALL_MODE until
> memory_init() has been called during TOS_LoadImage(), which happens
> later in Main_Init() (when it calls Reset_Cold()).
>
> So we either have got to change the order here a little bit, or maybe
> remove the call to STMemory_Reset() from STMemory_Init() ? The latter
> should likely be OK since STMemory_Reset() is called again from
> Reset_ST()? Nicolas, do you have an idea what's the right fix here?

Hi
looking at this, there might be several ways to fix it, but none really 
satify me at the moment with current code :(

For example, in main.c we could add a call to memory_init() before 
calling STMemory_Init() (with default to tos address at $fc0000, until 
real tos is loaded later). Would it work for you ?

The problem is that we have several "layers" of init functions, some of 
them calling each other with nearly circular dependancies sometimes.

For example in this case, I think memory_init should not be called from 
TOS_LoadImage(). TOS_LoadImage() should be a higher level function that 
can patch tos, show warnings depending on some TOS/HW combinations, but 
it should not call memory_init (or just a subset to change TOS address 
between FC0000 and E00000).

I already tried to create some _Init and _Reset funtion for each HW 
component (which is why I'd rather keep the call to STMemory_Reset), but 
it's not complete yet.

In main.c we should reach something like this :
 - set default params
 - load config
 - init "low level" HW
    - call all _Init functions (eg init should alloc whatever memory is 
necessary for the component)
    - call all _Reset functions (this should set each component in the 
state described in its HW documentation, setting the correct default 
value for each registers and so on)

 - do higher level functions : load tos, set HD emul, "connect" the low 
level HW parts, ...

Actually, some parts are not always in this order, but we're not that 
far from it (but I'd rather change this after next release as this often 
requires a lot of testing between starting, resetting, loading memory 
savestate, ...)


Nicolas