32Mhz oscillator "issue"

[exxos]

The first small "issue" is that I am actually using a standard 32MHz oscillator.. The machine itself will of course work fine.. But only actually just "un-forgot" about the problems in demos

Basically we need to find a source for 32.0424MHz oscillators... Actually a integrated oscillator not a simple crystal oscillator like used on the STFM etc.

We could reuse the oscillators from the STFM's, but it would actually mean creating a small oscillator circuit along with it which I really would prefer to avoid it possible.

If anyone knows all the variations of 32MHz oscillators which work, I think it was something like 8.01,8.02MHz after divisions ? So assume ,32.08,32.04Mhz etc is fine...

But what about, minimum and maximum 32MHz oscillator speeds which would work ?

We could also scale up to 64Mhz is that's easier (doubt it) but it would be a option..

Looking at what mouser sell...

OSC

ms.jpg (6.01 KiB) Viewed 8368 times

CRYSTALS

ms2.jpg (5.8 KiB) Viewed 8365 times

[troed]

1) 32.0424
2) 32.084988
3) 32.215905

(1 = old STF, 2 = PAL STFM and STE, 3 = NTSC STE)

2 is the most compatible one and is the one to target. Closest Mouser clock is 32.11, but demo coders sometimes were "cycle exact" so while it's more compatible than 32.000 it doesn't mean it'll be perfect.

(I also don't want to exaggerate how big of a problem this is. Yes, some things will fail. Might even be lower border in some games. Those of us who have machines that can run at 32.000 already can of course test ... and I have such hardware)

[exxos]

(I also don't want to exaggerate how big of a problem this is. Yes, some things will fail. Might even be lower border in some games. Those of us who have machines that can run at 32.000 already can of course test ... and I have such hardware)

Thanks...

I don't know how all that works, but if its MFP vs CPU, then they are driven from the same master clock I think ? so I don't get exactly whats going on... if cycles are counted, if the CPU was running faster, the MFP would as well.. so the cycles between the 2 would still be the same ?... clueless I am...

[troed]

I don't know how all that works, but if its MFP vs CPU, then they are driven from the same master clock I think ? so I don't get exactly whats going on... if cycles are counted, if the CPU was running faster, the MFP would as well.. so the cycles between the 2 would still be the same ?... clueless I am...

Duplicating our discussion in PM a bit

You're of course right, but the MFP has a 2.4576MHz input clock used for its timers. That one is the same on all ST motherboards, and its the difference between that clock and the motherboard clock (which varies) which causes the difference for coders.

[exxos]

Duplicating our discussion in PM a bit

You're of course right, but the MFP has a 2.4576MHz input clock used for its timers. That one is the same on all ST motherboards, and its the difference between that clock and the motherboard clock (which varies) which causes the difference for coders.

ah yep has its own crystal..

hmmm.. so must be the relating between the 4MHz and 2.45MHz then... ?

hmm.. I guess technically if the 2.45 was a fraction slower, then it would compensate and things would still sync up ?

[SolderGirl]

(I also don't want to exaggerate how big of a problem this is. Yes, some things will fail. Might even be lower border in some games. Those of us who have machines that can run at 32.000 already can of course test ... and I have such hardware)

Thanks...

I don't know how all that works, but if its MFP vs CPU, then they are driven from the same master clock I think ? so I don't get exactly whats going on... if cycles are counted, if the CPU was running faster, the MFP would as well.. so the cycles between the 2 would still be the same ?... clueless I am...

My guess is, because the video timing in the ST is directly derived from the master clock, having a diffrent clock would mess up the video signal.

PS: Ok, i got that all wrong. didn't realize that there is another clock that is asynchronous.

[exxos]

My guess is, because the video timing in the ST is directly derived from the master clock, having a different clock would mess up the video signal.

PS: Ok, i got that all wrong. didn't realize that there is another clock that is asynchronous.

I pretty much don't understand it either.. From what I can gather the master clock of course is just over 32MHz.. And is divided down to 4MHz for the MFP. The MFP also has its own 2.5(ish)MHz oscillator..

From what I understand (properly not very well) the timers in the MFP will trigger so many times during a frame draw. Of course if the master clock is running faster, the amount of interrupts per frame will be more... And then the reverse, the master clock is running slower, there will be less interrupts per frame.

So I would assume something like this, where the CPU may do something like 1,000 cycles per interrupt based on a given master clock. I'm assuming troed's demo works out the number of cycles per interrupt.. Where I assume variations could say it's like 1,001 or 1,002 cycles per interrupt... And those numbers are detectable... But with a 32MHz master clock, the cycles could main well be 1,000 per interrupt, where no demos would factor in that cycle time..

I was just half wondering if we could alter the time of the MFP a tiny amount compensate for the slightly slower master clock.. Basically then number of cycles per to interrupt should end up one of the normal detectable values...

Troed rightly says 2.4576MHz vs 32.084988Mhz.. So if we "lost" 0.085Mhz (2.3726Mhz) then I would assume number of cycles would then be as expected.. But of course we would need to find a 2.3726Mhz osc which probably doesn't exist.. I will check though..

zz.jpg (5.74 KiB) Viewed 8332 times

So 2.4Mhz is the closest.. as to if that would work or not... I guess in theory it would, but also I don't know of side-effects of running the MFP fraction slower either..

I'm sure Troed can explain it a lot better than me.. He is the cycle wizard here..

[troed]

Slowing down the MFP is probably not a great solution. Purists will not like having sound "detuned" (not sure if that would really be audible, but I don't have absolute pitch). Those timers have a fixed clock to make sure MFP timers are .. uhm .. something. I have vague memories of it having something to do with external protocols etc.

I don't think there's a perfect solution. Either 32.000MHz, re-using old ST crystals and build an oscillator circuit, or use 32.11MHz and hope it's at least better than 32.000.

The MFP clock seems to be a common oscillator clock still.

[exxos]

Yeah, once the board is working we can try different values.. I found a couple of potential sources.. asked if they are a osc or cry.. either way, I will buy a load of them if they are not to costly..

Probably be a good idea to use a DIP8 turn pin socket for the OSC so it can be easily changed in the future...

[troed]

If it's socketed - purists can buy an adapter board that takes an ST crystal and produces a correct clock, and everyone else can just use the default provided 32.11 or 32.00 ... ?

It doesn't _look_ too complicated to build a clock from the ST crystal: https://www.radio-electronics.com/info/ ... llator.php

(or I'm just showing my lack of electronics knowledge here