Patching IO demo

Page 1/2
| 2

By Overflow

Resident (57)

Overflow's picture

15-03-2015, 22:28

As promised in the news thread about IO demo, I start a thread about patches.

More than 2 months were spent on compatibility issues, and there are still some which are not fixed.

As a start check this: com + source.
This is the launcher of the demo.
Disclaimer: this might be some dirty code, without comment, or with french comments, ...
I believe we will have most of this thread about what's going on in it.

Some previous stand-alone tests/commands can be found there,
zip with commands .COM, plus zip with sources... but in French @

That's all as a start. More to come later!

Login or register to post comments

By Manuel

Ascended (19469)

Manuel's picture

16-03-2015, 16:32

Can you describe in words what you had to patch and why?

By Overflow

Resident (57)

Overflow's picture

16-03-2015, 17:34

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.


By Overflow

Resident (57)

Overflow's picture

16-03-2015, 17:40

EDIT on e)
I mean: IN A,(#99):AND #40:JR Z,$-4
replaced by IN A,(#99):AND #60:JR Z,$-4
( actually code is different: in a,(#99):and b:jp z,$-3 )

By PingPong

Enlighted (4140)

PingPong's picture

16-03-2015, 19:04

OMG oO Crying

By Grauw

Ascended (10771)

Grauw's picture

16-03-2015, 19:21

Nice to read those details Overflow.

By hap

Paragon (2042)

hap's picture

16-03-2015, 20:11

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

By hap

Paragon (2042)

hap's picture

16-03-2015, 20:13

For (b), yeah I have a Canon V-20 with 2 XTALS, this causes the VDP and Z80 to be in imperfect sync. It was really annoying to do tests on back when this was my only MSX1.

By Marq

Champion (387)

Marq's picture

16-03-2015, 20:16

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.

By cax

Prophet (3740)

cax's picture

16-03-2015, 20:48

That's why we always disabled networking on Russian MSX2 with _NETE (short version of CALL NETEND)
On a standalone (not networked) machine you do not need network module at all, so indeed removing it is a good idea.
I personally just covered module contacts with piece of paper and inserted it back to its slot.

By Overflow

Resident (57)

Overflow's picture

16-03-2015, 22:41

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

Page 1/2
| 2