MSX Z80 clock frequency

Página 1/2
| 2

Por RvS

Expert (95)

Imagen del RvS

29-05-2020, 10:28

I always thought that the Z80 was clocked at 3.58 MHz. But when I checked the clock frequency of my NMS8245, I noticed it was 3.55 MHz. I attributed that to the fact it is over 30 years old, but today I checked the service manual and noticed it is still spot on:

This is approx 0.7% slower.
Is this a difference between MSX1 and 2 or is this specific for the 8245?

Login sesión o register para postear comentarios

Por hap

Paragon (2043)

Imagen del hap

29-05-2020, 12:42

Looks like the XTAL is marked 21328.1 (divide by 6 to get Z80 freq?)
No it won't be the same on every MSX2.

Por Grauw

Ascended (10821)

Imagen del Grauw

29-05-2020, 13:32

Maybe it is tuned to a slightly lower frequency to get better composite video quality? Reducing colour crawl or something like that.

Por Grauw

Ascended (10821)

Imagen del Grauw

29-05-2020, 15:11

Maybe it is tuned to a slightly lower frequency to get better PAL composite video quality / compatibility? It may reduce colour crawl by having a colour subcarrier frequency that’s closer to the spec. Also at 3579545 Hz the frame rate will be 50.60 Hz, at 3554685 it will be 50.25 Hz which may again be closer to PAL specifications.

Por RvS

Expert (95)

Imagen del RvS

29-05-2020, 15:20

Very weird. The NMS8245 has a 21.328125 MHz crystal for the VDP and the NMS8250 has a 21.47727 MHz crystal. Both Philips machines but the 8245 is just a bit slower. The PAL 50Hz spec could be a proper reason, but I don't understand why they would not make the same modification for the 8250.

Por Grauw

Ascended (10821)

Imagen del Grauw

29-05-2020, 15:30

Maybe the NMS 8245 engineers (NEC or Kyocera?) were more strict about adhering to the PAL specifications, while the NMS 8250 engineers (Sanyo) figured using the normal clock values for the V9938 was within tolerances and worked fine as well.

It’s not unusual among retro computers to have a different clock frequency for PAL and NTSC, e.g. similarly the NTSC NES is clocked at 1789773 Hz while the PAL NES is running at 1662607 Hz (7% slower). Though for MSX I think this is the first time I’ve seen that.

Por Pentarou

Hero (563)

Imagen del Pentarou

29-05-2020, 16:42

Maybe the 823x/8245 manufacturers simply had a cache of 21.328 Crystals and wanted to get rid of them? Tongue

@Grauw: Pal color burst is 4.43 MHz, not 3.58 and your NES example is wrong: PAL NES and NTSC NES/FC have different GPUs with different dividers, so they NEED different clock values.
A more fitting example would be the MD (or some PS1), where they used the same Video IC but slightly different clocks.

You could be right in thinking that the 8280/8245/8235 were built to better adhere to the PAL specs, and the 8250 difference may be explained by it being an adaption from an existing NTSC specced machine (MPC-25).

Anyway, the slightly clock difference is known to cause problems on other (non MSX) machines, could it be that the MSX need clock fixes too?

Por hap

Paragon (2043)

Imagen del hap

29-05-2020, 18:25

Pentarou's link: it's only a problem on 'old' 60hz screens. Nowadays we have adaptive sync/freesync, works great with emulators.

Por Pentarou

Hero (563)

Imagen del Pentarou

30-05-2020, 07:21

Yeah, but the thread was about 30+ years old machines which don't have HDMI 2.1

Por Grauw

Ascended (10821)

Imagen del Grauw

30-05-2020, 13:12

I think that even modern digital displays have some tolerance and don’t need exactly 50 or 60 Hz. So if the MSX provides it with 50.16 Hz or 59.92 Hz through an analog signal, it works fine. And if the MSX goes through an OSSC analog to digital HDMI converter, it will still keep the original frequency.

I’ve never seen frame hiccups with my modern digital displays at least.

Either way, this slight reduction in clock frequency does not affect MSX programmers, because if I read the NMS 8245 schematics correctly the CPU is clocked by the VDP, so they still run exactly in sync with each other.

I think it would be nice if this were emulated though! Is there an openMSX bug about this? Smile

Por Manuel

Ascended (19687)

Imagen del Manuel

30-05-2020, 16:52

We discussed this, and the conclusion is that it's not worth the hassle. It's not easy to do, due to the internal timing model openMSX uses, which is based on a master clock of 3579545*960 Hz.
And there are no real benefits either. It only means we emulate that machine imperceiveably faster than the actual machine would run.

Página 1/2
| 2