Re: [hatari-devel] ENABLE_SMALL_MEM problem

[ Thread Index | Date Index | More Archives ]


Am Tue, 26 Dec 2017 23:34:12 +0100
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

> 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? 
> 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)

I agree with you. But then the _Init functions should not call the
_Reset functions directly - that should be part of Reset_ST later.

So to fix the current ENABLE_SMALL_MEM problem, I think it's the
easiest and best solution to remove the call to STMemory_Reset() from
the STMemory_Init() function. Then, after the release, we can consider
whether we also want to rework memory_init() or not, OK?


Mail converted by MHonArc 2.6.19+