Patching IO demo

Hi Manuel! your request does make sense.

a) cpu freq.
Launched estimates the number of cpu-cycles between 2 VBLs.
If it is not around 313*228=71364, demo won't run.
This occurs on real NMS8280 (which has 228.5 cycle on a line WTF?)
This should occur on overclocked/kit-ed msx.
This likely occurs on russian (?) msx2 (see msg@pouet)
This is what may occur on Toshiba HX10 (from izy?)
About openmsx: it seems it always assumes 71364 cycles on all 50Hz VDP?
(Note: launcher detects R800 or MSX2+ w/ native overclocking
and then tries to lower freq to standard z80 mode;
launched also tries to switch from 60Hz to 50Hz)

b) 2 clocks
When 2 clocks are detected, intro is changed.
Splitrasters showing some black/blue stairs is removed,
replaced by a simple black rasters falling on blue background.
Openmsx does not simulate (yet) those 2 clocks.
Different clocks for cpu & vdp implies that perfect timing is impossible:
splitrasters would slowly move/slide horizontally.
2 ways to watch this thru the demo:
at launch, watch the small red bar at bottom; does it move?
at last scene, does it start by a static screen, or does screen slide horizontally?
Final note about 2 clocks: on the machines I had for tests,
I had an average of 71361 cycles by frame (and not 313*228=71364).
So the patch changes timing for last scene ( -3 cycles exactly)
in order to slide more slowly.
I'm wondering about other real machines: other clocks, other results?

c) slow-down on turbo R and some msx2+
Openmsx emulates this perfectly:
when outing to vdp, an extra-cycle is added to each opcode(!).
Patch from demo changes the last scene:
each column/splitraster is larger, and one column is missing.
To check this thru openmsx: compare last scene
on MSX2 setting and on Turbo R setting.

d) X position of sprite
IO logo in text mode is replaced by IO logo as a sprite.
It seems that on real msx1, screen when in text mode is 3 pixels left.
When real msx1 is detected, IO logo sprite.X = X-3.
Note: nothing done/patched on real msx2 or more.

e) sync by 5S sprite
Briefly: to synchronize at top of the screen,
5+ sprites are set with Y=-1 so that bit 5S=1 at 1st screen-line.
On openmsx, you can rely on testing bit 5S to synchronize at this line.
On real msx1, sync randomly occurs at next line, WTF?
To fix this, when real msx is dectect, sync is then made on bits 5S and C.
I mean: IN A,(#99):AND #40:JR NZ,$-4
replaced by IN A,(#99):AND #60:JR NZ,$-4

f) 5S timing: openmsx VS msx1 VS msx2&more
I'm not very clear about this.
For perfect timing, see before: testing bit 5S.
First openmsx VS msx1: bit 5S is set earlier;
how much time earlier? 20-30 cpu-cycles or so.
Then msx2: argh! I didn't find the logic behind it;
I just can say it depends on sprites.Y... and also sprites.X
When real MSX2&more are detected, patch enables some dynamic tempo:
testing bit 5S then "waiting" for perfect timing;
this "wait time" is changed during the flow of an fx;
for instance: changed 5 times during plasma,
depending on where the sprites are set on screen (!).

I've written this when looking at code which patches,
so it should be complete.

Olivier

OMG

For (e), the reason why it seems the MSX sometimes has 1 scanline delay is because if you read 5S at the same time it is accessed for write by the VDP, it returns 0 and is reset***. To solve this, you'd have to create a loop of x cycles long where 228/x is not an integer.

*** something like this i guess?
Z80 reads status reg, 5S is 0
VDP position is at 5S, it sets status bit
VDP recognizes that Z80 has read status
VDP resets status reg bits

That Russian MSX2 problem might be solved by removing the network adapter (if any), as it messes up the interrupt system and probably some more.

That's a very interesting reading, thank you guys, no doubt I have much to learn about msx.