Which MSX2 has the slowest VDP? Panasonic turbo-R and A1-WSX?

Page 1/2
| 2

Par Bengalack

Hero (594)

Portrait de Bengalack

25-12-2021, 16:45

Which MSX2 has the slowest VDP? Panasonic turbo-R and A1-WSX?

I'm not sure if the title is correct. But different computers run my game differently Sad

openmsx17: panasonic_fs_a1gt.png

openmsx17: Philips_nms_8255

physical: panasonic_a1-wsx

physical: SVI-738 (and I just can't appreciate the retrotink 2x-mini)

Look at the images. These are different configurations, but it seems like they spend a different amount of time doing the same work when

the border is gray

The line which has a blue border, starts at a line interrupt, so we see that some configurations are done with its "gray work" (sets border color to black) before others.

What I find strange, is that this is screen 4, and there is no VDP-commands and the program polling status from the VDP to find out when the VDP is done (like you can do in screen 5 and above). No, this is just plain cpu-commands. The gray area is pushing most of the screen over to the VD

P using unrolled OUTIs like this:

_loop_pr_line_of_32tiles2_:

.rept 32			; 576 cycles pr line. Duration one scanline is around 230 cycles
	outi			; OUTI Reads from (HL) and writes to the (C) port. HL is then incremented, and B is decremented
.endm

	add hl, de

	dec a
	jp 	nz, _loop_pr_line_of_32tiles2_

Is it really so that the cost of outi is different on different HW? It should be 18...

Anyways, I need to maximize the amount of cycles spent inbetween some line-interrupts. To do this, and at the same time make sure the game works on all MSX2s, I need to make things work on the slowest setup. Using openMSX, it seems like the slowest is the Panasonics. And it seemss like FS-A1GT is the same speed as A1-WSX. If so, I'm lucky, as I do possess a physical A1-WSX, and can test on that. If this is not the slowest ... I need ... help :)

!login ou Inscrivez-vous pour poster

Par ARTRAG

Enlighted (6846)

Portrait de ARTRAG

25-12-2021, 16:56

IIRC FS-A1GT has a wait circuit halting the cpu while doing vdp I/O

Par Bengalack

Hero (594)

Portrait de Bengalack

25-12-2021, 16:57

ARTRAG wrote:

IIRC FS-A1GT has a wait circuit halting the cpu while doing vdp I/O

Same with a1-wsx then?

(I run in z80 mode on the turbo-r BTW)

Par sdsnatcher73

Prophet (3412)

Portrait de sdsnatcher73

25-12-2021, 17:22

The delay is probably in the T9769 in these machines. The wiki however writes that the C revision (used in A1ST, A1GT and in A1WSX although A1WSX can also have B revision) has 1 cycle wait while revision A and B have 2 cycles wait during VDP I/O. A and B revisions were used in A1FX, A1WX and Sanyo 35J, 70FD and 70FD2. This could mean these may be even slower…

Also are you running all machines at the same display frequency (either 50Hz or 60Hz)? I guess this could also impact your results).

Par thegeps

Paragon (1035)

Portrait de thegeps

25-12-2021, 17:22

If standard ISR is active (so you don't use your own ISR) frame speed may vary on different machines( ISR does different tasks, due to different hardware)

Par Bengalack

Hero (594)

Portrait de Bengalack

25-12-2021, 21:05

sdsnatcher73 wrote:

The delay is probably in the T9769 in these machines. The wiki however writes that the C revision (used in A1ST, A1GT and in A1WSX although A1WSX can also have B revision) has 1 cycle wait while revision A and B have 2 cycles wait during VDP I/O. A and B revisions were used in A1FX, A1WX and Sanyo 35J, 70FD and 70FD2. This could mean these may be even slower…

Also are you running all machines at the same display frequency (either 50Hz or 60Hz)? I guess this could also impact your results).

Thank you so much. This is *very* informative. Bad also sad. There is quite a big difference in the amount of available cycles here. What were they thinking? Two extra cycles per VDP command? It is massive. A you can see from the images, it's about 7 scanlines. It means that things needs to idle a lot for most machines, just to comply with these specific chips. The overview you gave me also lists up T9763. When I test Panasonic_FS-A1FM (with this chip) in openMSX, I lose another 4 scanlines or so, as this chip is simulated slower (maybe two waits on this?). This means I need to optimitize even more :-O

The current issue happens in both 50Hz and 60Hz. I've read somewhere that the speed of "printing" pixels on screen is the same for 50 and 60, and that the difference between the two modes is the amount of time that is spent in the "border"-area, between last line (192) and the first (0).

I will need to get someone with these setups to test for me, I guess, just to make sure things runs everywhere.

Strange that I haven't seen these facts before - this is crucial info for anyone doing framerate-dependent games on the MSX2 :)

Par Bengalack

Hero (594)

Portrait de Bengalack

25-12-2021, 21:09

thegeps wrote:

If standard ISR is active (so you don't use your own ISR) frame speed may vary on different machines( ISR does different tasks, due to different hardware)

Thanks, but no, I have my own code at 0x0038 and doing IM 1. But it would not have mattered though, as the code that runs when I color the border gray, is happening at a line-interrupt (which is one of the nice features of the v9938). This image may explain this a bit better:

Oh! -Those limited, precious, cycles are becoming even fewer :O

Par Bengalack

Hero (594)

Portrait de Bengalack

25-12-2021, 23:13

sdsnatcher73 wrote:

The delay is probably in the T9769 in these machines. The wiki however writes that the C revision (used in A1ST, A1GT and in A1WSX although A1WSX can also have B revision) has 1 cycle wait while revision A and B have 2 cycles wait during VDP I/O. A and B revisions were used in A1FX, A1WX and Sanyo 35J, 70FD and 70FD2.

I opened my own a1-wsx, and found that it states "T9769C" on it. openmsx17 emulates speed on that machine very close to, but not 100%. But that does unfortunately mean that I do not have the worst case real machine to test on.

I found out that openmsx emulates bigger delay, probably two waits, on this: https://www.msx.org/wiki/Sanyo_PHC-70FD2 just like this https://www.msx.org/wiki/Panasonic_FS-A1FM so I'll work with those :)

Par Manuel

Ascended (18876)

Portrait de Manuel

26-12-2021, 00:24

You can see in the XML config which T9769 type is emulated:

share/machines/Al_Alamiah_AX370.xml:      < subtype>A< /subtype> 
share/machines/Aucnet_NIA-2001.xml:      < subtype>C< /subtype>
share/machines/Panasonic_FS-A1FM.xml:      < subtype>< /subtype>
share/machines/Panasonic_FS-A1FX.xml:      < subtype>B< /subtype>
share/machines/Panasonic_FS-A1GT.xml:      < subtype>C< /subtype>
share/machines/Panasonic_FS-A1ST.xml:      < subtype>C< /subtype>
share/machines/Panasonic_FS-A1WSX.xml:      < subtype>C< /subtype>
share/machines/Panasonic_FS-A1WX.xml:      < subtype>B< /subtype>
share/machines/Panasonic_VW-KT300.xml:      < subtype>B< /subtype>
share/machines/Sanyo_PHC-35J.xml:      < subtype>A< /subtype>
share/machines/Sanyo_PHC-70FD2.xml:      < subtype>A< /subtype>
share/machines/Sanyo_PHC-70FD.xml:      < subtype>A< /subtype>

and In VDP.cc you'll see:

static byte getDelayCycles(const XMLElement& devices) {
        byte cycles = 0;
        if (const auto* t9769Dev = devices.findChild("T9769")) {
                if (t9769Dev->getChildData("subtype") == "C") {
                        cycles = 1;
                } else {
                        cycles = 2;
                }
        } else if (devices.findChild("S1990")) {
                // this case is purely there for backwards compatibility for
                // turboR configs which do not have the T9769 tag yet.
                cycles = 1;
        }
        return cycles;
}

Par sdsnatcher73

Prophet (3412)

Portrait de sdsnatcher73

26-12-2021, 08:08

I have A1FM, A1FX, A1WSX (unsure which revision), A1ST if you want to test on real HW.

Par Bengalack

Hero (594)

Portrait de Bengalack

26-12-2021, 08:13

Thanks. This info is brilliant. I will test around here. This list is probably the list of the slowest MSX2s out there, then Smile

We should have a section for this here: https://www.msx.org/wiki/Compatibility_testing

(That page is really good, BTW. It has, amongst other things, forced me to not go easy on slot-routines (https://www.msx.org/wiki/Compatibility_testing#Test_on_the_e...)

There are sections I don't follow, like https://www.msx.org/wiki/Compatibility_testing#Illegal_Direc... but the idea that this (ports) is a tricky area is just great for someone coming late to the table. Like me :))

Page 1/2
| 2