Is a MSX2 machine slower than a MSX1 one?

ページ 1/3
| 2 | 3

By jltursan

Prophet (2619)

jltursan さんの画像

15-10-2019, 19:01

Right now I can't explain what I'm seeing but if you look closely to this pic, you'll see a game, running in two different emulated machines (using OpenMSX) and rendering the same scene.

Both are performing quite different, the MSX2 (right pic) has slightly larger times processing each routine, denoted by a color bar. The MSX1 is faster enough to even show the yellow routine being executed inside the frame, in the MSX2 there's no yellow at all. Looking at the core routines, the colored bars in the last third of the screen you can see that they're being executed first when running in the MSX1.

The VDP has nothing to do, they're executing the same code and in fact, MSX2 accesses are faster. There's no RAM contention in MSX and AFAIK the wait cycles are the same at least between an MSX2 and a MSX1. I can only think in the H.TIMI or H.KEYI being heavier in a MSX2 machine; but this looks weird to me.

I've also tested a HB-700P with exactly the same results and even BlueMSX, with this same behaviour.


By Manuel

Ascended (19691)

Manuel さんの画像

15-10-2019, 19:24

When the turboR came out, some magazines said it was slower than MSX1. AFAIK the cause is a heavier standard interrupt routine. There is simply more to do there, apparently.

By zeilemaker54

Champion (356)

zeilemaker54 さんの画像

15-10-2019, 19:59

Is this an existing program/game or own code ?
There are minor differences in the bios between msx1 and msx2.
Some routines involve slotswitching to the msx2 subrom which add some extra cycles.
Interrupt routines are nearly identical but machines with a diskdrive use some extra cycles. But this can be ruled out by starting the machine with the SHIFT key pressed.

By jltursan

Prophet (2619)

jltursan さんの画像

15-10-2019, 20:01

Thanks to both!, so indeed all is pointing to heavier interrupts. It's somewhat own code, it's from a debugging session of the AGD port and I've found this behaviour.
Not a big deal tho, as right now I don't have a custom ISR, I cannot do anything to avoid this extra cycles, both machines have disk system installed and they need it to load the game.

So, without replacing the standard BIOS ISR, and always after the game is loaded, can I completely disable the diskdrive?

By theNestruo

Champion (431)

theNestruo さんの画像

15-10-2019, 20:32

Hi, jltursan!

If you don't need the BIOS reading the keyboard into OLDKEY and NEWKEY system variables (quite likely, as you are already reading the cursors/joystick elsewhere), you can skip a long part of the ISR by adding this near the end of your H.TIMI hook (or maybe you are already doing it):

; Tricks BIOS' KEYINT to skip keyboard scan, TRGFLG, OLDKEY/NEWKEY, ON STRIG...
	xor	a
	ld	[SCNCNT], a
	ld	[INTCNT], a

I don't think this solves the MSX-MSX2 differences, but may free some cycles per frame for you. As the keyboard scan is every third frame, you will also get more stable color border bars :-P

Good job with that AGD engine!!

P.S.: A friend of mine wants to port one of its games (made in AGD) to MSX. Is there any possibility of getting an alpha or beta version of your AGD engine?

By jltursan

Prophet (2619)

jltursan さんの画像

15-10-2019, 20:54

Yep, I know the patches that mostly disable the BIOS interrupt routine; but sadly I'm using the BIOS keyboard reading. If I only could keep this and disable the rest!

I'm going to update the main AGD port thread right now...

By thegeps

Paragon (1260)

thegeps さんの画像

15-10-2019, 22:01

Hi all! Where Can I find these patches that mostly disable the BIOS ISR? I'd like to know more, thanks!

By jltursan

Prophet (2619)

jltursan さんの画像

15-10-2019, 22:57

That's old stuff but you can read about it here:

By Grauw

Ascended (10824)

Grauw さんの画像

16-10-2019, 01:22

jltursan wrote:

Thanks to both!, so indeed all is pointing to heavier interrupts.

I measured in openMSX while idling in Basic without diskdrive (boot with SHIFT key).

  • The MSX1 BIOS ISR takes 871 cycles. Every 3rd frame it takes 5278 cycles.
  • The NTSC MSX2 BIOS ISR takes 933 cycles. Every 2nd frame it takes 5310 cycles.
  • The PAL MSX2 BIOS ISR takes 4109 cycles. Every 2nd frame it takes 5310 cycles.

The 3rd / 2nd frame thing is when SCNCNT reaches 0, then it does keyboard scanning etc. On MSX1 SCNCNT is always reset to 3 regardless of region so it runs the expensive path every 3 frames. On NTSC MSX2 this resets to 2 (so slower on average). And on PAL MSX2 this is reset to 1, in other words it always runs! (Although there still seems to be some part that’s skipped further in.)

The latter is quite shocking actually, I did know PAL scanned more frequently but I thought NTSC did it every 3 and PAL every 2 frames. Not so! Every frame’s pretty bad, even though of course there’s plenty of frame time comparatively, until you switch the VDP to 60 Hz that is!

So in the basis the MSX2 ISR is only marginally slower (due to the addition of light pen support). But it became much slower because they messed with the SCNCNT reset value, especially on PAL. Though the worst case didn’t change, even on MSX1 you will get frames where the ISR is about as slow as on MSX2.

Either way, the simplest code solution is to manually write SCNCNT yourself (e.g. in a H.TIMI hook). I think this is better than making a custom ISR. Set it to 0 continuously to make it always take the fast path (and scan manually). Set it to JIFFY & 1 to make PAL MSX2 behave as NTSC MSX2 does. Set it to JIFFY % 3 to make MSX2 behave as MSX1, or more easily JIFFY & 3 which then scans every 4 frames.

The machines I tested this in were Yamaha CX5M (PAL), Sony HB-75P (PAL), Philips NMS 8245 (PAL) and Panasonic FS-A1 (NTSC).

p.s. The increased scan frequency does probably make MSX2 machines actually feel a bit more responsive to the user (less latency).


Enlighted (6098)


16-10-2019, 03:53

Grauw gave a good overview of the problem, but the whole situation is not this simple.

If you try this program on different MSX setups you will be surprised, how many variations of different localizations you will find. The program will reveal you good overview of the weird things going on inside the machine... ie. some Brazilian machines scan keyboard more like "once a day".

BTW, you will get different numbers if you run the BIN-version... ROM-version shows the situation only as it looks like when ROM-game is booted while BIN gives idea of more like "normal" situation... but a little warning: All the numbers that it gives are not guaranteed to be 100% accurate although close. It also seems to be typical that real computers give different test results compared to their emulated versions.

... and then there is also indeed the usage of BIOS-calls. Maybe worst case scenario is if you try to print text to SCREEN 3... If you compare ie. MSX1 and MSX tR, MSX1 can do it about 4.5x faster.

By Metalion

Paragon (1629)

Metalion さんの画像

16-10-2019, 12:37

Grauw wrote:

Either way, the simplest code solution is to manually write SCNCNT yourself (e.g. in a H.TIMI hook). I think this is better than making a custom ISR. Set it to 0 continuously to make it always take the fast path (and scan manually).

Not sure about that. The BIOS code in MSX1 is :

DEC     (HL)            ;Need to scan?
JR      NZ,INTRET       ;No, return soon
LD      (HL),3          ;Time delay of first repeat

Therefore it scans when SCNCNT is equal to zero.
Is MSX2 BIOS different ?

ページ 1/3
| 2 | 3