Re: [hatari-devel] DSP performance

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


IMO, it can. You know, in advance, how many cycles it will take to emulate instruction, so you know when it 'happens'. knowing microcode (or internal CPU layout) would be perfect, but not really necessary, you just need to 'measure' when instruction tries to access the bus. It wouldn't be much slower, bacause there would b a lot of empty cycles, and computation of some instructions would 'smear' on many cycles. This could be also a good base for otherwise tricky emulation of border remowal, palette tricks, sync scrolling and so on.

AdamK

2015-07-01 10:34 GMT+02:00 Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
Le 01/07/2015 10:16, Adam Klobukowski a écrit :
Just a thought: why not emulate a global ticks (with one cycle per tick
for DSP and one cycle per two ticks for CPU) counter? Then CPU and DSP
know exactly what cycle the're on and should they finish current
instruction or not. Even proper bus emulation might come out of this one
day.

AdamK

It can't work this way, this is something that would work when building a hardware emulation board in VHDL (such as Mist) because you really have a clock, but unless you know the microcode for each 68030 instruction, you can't tell the cpu part "just run for 2 cycles"  (plus it would be awfully slow to split each emulated parts at the bus level)






--
Semper Fidelis

Adam Klobukowski
adamklobukowski@xxxxxxxxx


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/