Steven Seagal wrote:I figure it's quite easier to emulate in Steem thanks to the clever video system: you just need to force rendering when MOVE.W ..., (d16, An) goes to the SDP zone, just like it was a shifter event.
I think the left border of the scroller wasn't "1 VBL" compliant, but it's hard to tell on youtube, the framerate is different anyway. Check it if you fix it on Hatari.
Yes, it's quite easy to implement ; but as I said, the problem is not the implementation, it's that it will slow down emulation a lot, because for any write to RAM you need to update the video address on each access and do some comparisons to see if the ram location and the video address overlaps.
About the VBL timing, one of my glorious hacks is to reduce timing by 4 (52 instead of 56). It helps some programs and breaks nothing, maybe because on a STF, the delay before execution is 64, in Steem it's hardwired as 68. Just a thought.
I'm afraid you didn't fix anything this way. The time needed between the interrupt and the execution of the code in the interrupt handler is 56. I measured it very precisely with some video synced code (and I guess steem's author and other people did it too, this value doesn't come from approximation). Fixing problems by changing a value that is known to be the correct one is not a correct fix. This just means somewhere else in the code there might be a 4 cycles error, but it's not in the interrupt timing.
Apart from that, It's true on STE the VBL starts 4 cycles later than on STF. This has to be taken into account depending on the STF/STE mode.
Beware of thought such as "It helps some programs and breaks nothing", in my experience this will often turn out to be wrong, one day you find even a very simple program that is now broken. The only accurate way to validate an emulation method IMHO is to write a very simple asm program that tests only this point very precisely on real hardware, disabling all other components that could interfere and check you get the exact same result in emulation. At one point, using a set of demos/games to decide whether the emulation is good or not is not accurate enough, many times you will find that your set of testing programs was too restrictive.
- another solution is to use a bus driven approach (instead of cpu driven, as done in WinUAE most accurate mode) : give 4 cycles to the CPU, 4 cycles to the MMU/shifter and draw 4 pixels (you need to share bus cycle with blitter, disk dma, sound dma, ... too). This is the most generic way to run the emulation, the closest to how the hardware really works, but it will be sloooowww, it really requires a lot of cpu.
Surely you mean 2 cycles for the CPU, 2 for the shifter?
No, it's 4 cycles on ST. The shifter gets data from the mmu every 4 cycles, not 2 (note than on ST bus accesses are rounded to 4 cycles, whereas on amiga for example this is not the case. This is not due to the 68000 but to the rest of the hardware).