| Re: [hatari-devel] DSP "running" on non-falcon |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Le 29/07/2022 à 14:01, Thorsten Otto a écrit :
On Freitag, 29. Juli 2022 00:43:18 CEST Eero Tamminen wrote:
> In that case I guess TOS check should be done first, and initializing
> everything else after that.
For EmuTOS that would not work. EmuTOS (at least the 512k/1024k roms)
are not tied to a particular machine type. So i think the machine type
should be the first one to be taken into account.
I think we must follow the same order that on real HW :
- machine is switched on -> you know which machine type it is (based
on option or config file)
- depending on machine type, HW components are known ; we should call
an "_Init()" function for each of them (for example RAM_Init (based on
amount of ram in config file), CPU_Init, Sound_Init, Blitter_Init, ...)
The _Init functions should allocate internal buffers if needed, set some
variables and so on. An _Init function should not depend on some other
_Init functions results, else we can get some different result depending
on which order we call all the _Init functions
- then all/most HW components receive a reset signal -> you start from
a "clean" state (some HW might not have a reset pin, but at least they
often have a known state at power up). Similar to "_Init" function, we
call a "_Reset()" function for each one.
Same as _Init, _Reset should not depend from other _Reset functions
- then cpu boots, tos starts
When machine type changes, we should call some "_UnInit()" functions for
each component, then apply new machine type and start from above.
At the moment, some components are a little "fuzzy" between Init and
Reset, sometimes mixing both in a single function.
But eventually we should have _Init, _UnInit and _Reset call for all
components. I think we're not too far from that and it doesn't prevent
Hatari from working in the meantime.
Nicolas