ITotalJustice
commented
1 year ago i found an error with the above solution. in gb, halt is delayed. it is ideal to have this as an event. the problem then becomes that the halt delay event now calls halt, which means halt is no longer delayed and halt is back on the scheduler :/
this was triggered by final fantasy adventure.
so what happens is that an apu channel has a very low freq of 2, and the delta for that channel is >= 2, halt is due to fire at the same cycle as well.
fire()->cb()->add()->find_next_no_fire()->find_next_fire()->fire()->goto_start:
the reason for the second fire is due to halt being in the list.
all events behave normally, they usually ad themselves back after the callback is called.
the issue is that halt basically takes over the scheduler by firing events from within the halt callback, this advances the scheduler_cycles as well.
because of this, lots of special code was added in the scheduler, its a mess. the problem is halt, so the solution is to simply remove halt from being an event! when halt is enabled within gb/gba, it should call a common function like
on_halt().however that still isn't perfect as potentially, a dma event could write to halt (gba) thus enabling it. although, i am not sure if this is allowed on gba, need to test it. if it is allowed then uh idk.