OUTI takes 1 extra cycle on Turbo machine

Page 1/4
| 2 | 3 | 4

By Eugeny_Brychkov

Paragon (1232)

Eugeny_Brychkov's picture

26-07-2018, 19:35

Recently I was told, and actually shown, that GR8NET video player performs worse on Turbo machine than on MSX2+ machine in terms of performance - on Turbo machine it is slower and audio hiccups. I started to investigate the issue using openMSX (do not have real Turbo), and found out that OUTI command takes 18 cycles on MSX2+, and 19 cycles on Turbo. Turbo machine is running in Z80 mode, thus I would expect it to be the same as MSX2+ in terms of performance.

18 must be a correct value: both command bytes are opcode fetch thus +2 to original 16 cycles per MSX specification.

I recall there was something relating to wait cycles on external slots (GR8NET is installed in slot 1 or 2), but I thought it is only about running in R800 mode?

Please advise the cause of this +1 cycle, point me to the doc, and if you know share how to overcome it (maybe some MSX-engine register to turn this extra cycle off?).

Thanks!

Login or register to post comments

By Overflow

Resident (57)

Overflow's picture

27-07-2018, 10:46

Hi! I can confirm that extra cycle.
Read my first thread at MRC forum.

Quote:

Turbo R and some MSX2+, when in z80 mode, slow down IO access to VDP;
- proven by previous measurements (see this thread)
- emulated by BlueMSX (part of source given in this thread)
- also emulated by openMSX (checked by debug, see my cycle counter (explained at thread start))
- exactly 1 cycle added (checked on openMSX by debug, confirmed on real HW by own test)

For those machines I had to self-patch my code - which relies on precise timing (hey! this is demo ;) )

I agree neither I know the (hardware) cause nor I know how to turn this off.

Regards.

By Eugeny_Brychkov

Paragon (1232)

Eugeny_Brychkov's picture

27-07-2018, 16:53

Thank you for details. Unfortunately streaming speed is embedded into video data, so it seems would be better to create another video file from the same frame set with lower fps. But it needs testing.

I researched the matters a little, and see the following:
- there're only several registers known for MSX-Turbo engine, me tracing MSX Turbo BIOS confirmed that. Either there're no more (useful) registers and bits, or they are used as default;
- there's no datasheet for S1990. I wonder there *was* no datasheet at all, or it is so confidential none possessing it did not reveal it so far?
- I have a suspicion that there must be some setting to cancel additional slowdown "features" within S1990, but I do not have Turbo machine to play with, and sure that someone more knowledgeable has already played with it...

So in general - what is current knowledge on the S1990 registers (I found this), and anyone willing to play with it with my assistance?

By Eugeny_Brychkov

Paragon (1232)

Eugeny_Brychkov's picture

27-07-2018, 18:06

Update: using openMSX I see that write to port 98 using OUTI takes 19 cycles, but write to non-VDP port takes 18 cycles as designed. Write using OUT(n) to port 98 takes 13 cycles, to non-VDP port takes 12 cycles.

By Grauw

Ascended (10706)

Grauw's picture

27-07-2018, 20:23

Depends on the MSX-Engine version, even in non-turbo modes.

The Panasonic FS-A1GT has 1 wait on VDP access in Z80 mode (T9769C engine).
The Sanyo PHC-70FD has 2 waits on VDP access (T9769A/B engine).
The Sony HB-F1XV has 0 waits on VDP access (S1985 engine).

So look for those T9769 A/B or C to know if a machine inserts 1 or 2 extra waits. You can find it here on the wiki or in the openMSX machine configurations. Why they did that, no clue. The S1990 in the turboR only adds waits in R800 mode btw, so it’s not to blame.

By Eugeny_Brychkov

Paragon (1232)

Eugeny_Brychkov's picture

27-07-2018, 20:57

Grauw wrote:

The S1990 in the turboR only adds waits in R800 mode btw, so it’s not to blame.

This is not correct according to the tests on real machine and on openMSX. S1990 adds one wait state in Z80 mode to the VDP I/O.

By Grauw

Ascended (10706)

Grauw's picture

27-07-2018, 21:43

No, that is the T9769C MSX-Engine, which is also present on the GT.

By Eugeny_Brychkov

Paragon (1232)

Eugeny_Brychkov's picture

27-07-2018, 23:13

In openMSX with FS-A1GT with S1990 in its configuration file I have 19 T-cycles for OUTI into port 98. I can explain you how I measure and exact configuration of the machine. It seems that all Turbo machines' configuration files I have are having S1990 in them, so I can not check emulation of other MSX-engines.

By Grauw

Ascended (10706)

Grauw's picture

27-07-2018, 23:18

The turboR has both a T9769C MSX-Engine, responsible for a 1-cycle wait for the Z80, the same as for e.g. the FS-A1WSX, and an S1990 which is responsible for inserting up to 54 cycles of wait for the R800.

I don’t know how much more clearly I can say this Smile.

By Eugeny_Brychkov

Paragon (1232)

Eugeny_Brychkov's picture

27-07-2018, 23:28

Now got it - machine has both chips Smile I thought it has one or another.

What frequency is being used when we talk about "up to 54 cycles"? 7.15 MHz (so it appears to be 27 cycles @ 3.57 MHz)?

By Grauw

Ascended (10706)

Grauw's picture

27-07-2018, 23:45

Eugeny_Brychkov wrote:

Now got it - machine has both chips Smile I thought it has one or another.

The Z80 is integrated in the T9769C. It interfaces with RAM through the S1990 and the R800 (the DRAM is connected directly to the R800 on dedicated pins), otherwise it’s functioning basically like an MSX2+ with T9769C while not in R800 mode. The S1990 deals mostly with R800 related stuff and other turboR additions like the timer and PCM. Eventually I’m sure they wanted to combine the two chips (under their 1-chip philosophy), it would probably simplify things and save cost, but they never made it that far.

Eugeny_Brychkov wrote:

What frequency is being used when we talk about "up to 54 cycles"? 7.15 MHz (so it appears to be 27 cycles @ 3.57 MHz)?

Yeah, the S1990 makes sure each OUT is spaced 54 cycles (@ 7.16 MHz) apart, so if you access it more quickly than that the R800 will be put in a wait state. In that manner, it behaves more smartly than most other wait circuits, however the amount of wait is rather excessive.

The openMSX guys’ research is here.

Page 1/4
| 2 | 3 | 4