Re: [hatari-devel] ENABLE_SMALL_MEM problem

[ Thread Index | Date Index | More Archives ]

On 23/12/2017 09:16, Thomas Huth wrote:


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?

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, ...)


Mail converted by MHonArc 2.6.19+