32Mhz oscillator "issue"

[rpineau]

The 2.4576MHz is used by the MFP to generate the serial port baud rate,, if you change it, you might have issues when connecting via serial port to modem, other machines..
Now how bad the issue is will depends on how far off you end up from the perfect baud rate.
Rodolphe

[exxos]

32MHz (what I sent with the kits) will do to get the STF running.. then we can look at the exact 32MHz osc..

Normally the circuits I have seen are like this...

osc32a.gif

I will see if I can track down a source for the osc first... if not, I can do a little board and use a crystal to get the correct clocks... its fixable either way..

[dhedberg]

Hmm, what's the accuracy of the original oscillators in the ST? Oscillators usually also deviate from the nominal value with time and temperature, but all the fullscreen demos I've tested on my now 30+ years old ST machines still work fine. How much can the oscillators deviate from the nominal value before we would start experience problems with opening of the borders?

[troed]

Hmm, what's the accuracy of the original oscillators in the ST? Oscillators usually also deviate from the nominal value with time and temperature, but all the fullscreen demos I've tested on my now 30+ years old ST machines still work fine. How much can the oscillators deviate from the nominal value before we would start experience problems with opening of the borders?

They don't deviate with heat or age in any detectable way.

Fullscreen demos don't use timers. Worst case here is a demo screen opening the lower border using timer a to wait from vbl until line 199

[exxos]

Found these...

32.084988MHz (falcon/STE osc) so 8.021247Mhz...

No idea if they would work or not ?

[troed]

Found these...

32.084988MHz (falcon/STE osc) so 8.021247Mhz...

No idea if they would work or not ?

Sure, that's the most compatible clock - PAL STFM and STE

[exxos]

Sure, that's the most compatible clock - PAL STFM and STE

ah but STFM is 32.0424 MHz .. slightly different than the STE...

osc.JPG

EDIT:

Nevermind I see your posted from before...https://www.exxosforum.co.uk/forum/viewt ... 1139#p9125

So will order 100x 32.084988MHZ.... the only slight issue is they are the larger DIP14 package, I used DIP8 on my STF :roll: So I guess that will be the first hack job...

$10 is silly price from BEST.. but after item cost and postage etc, my price still ends up being $5 to obtain them, but half price of BEST!

[troed]

They don't deviate with heat or age in any detectable way.

(Sorry, that came our a little short. Wrote it from mobile while on a plane, or the gate, or something)

Since Closure is one of those demos that work* on 8.01 and 8.02MHz CPUs (I have both variants) but not 8.05 (NTSC STE), for v1.1 (which is unreleased) I added code to my demo shell that detects the speed of the CPU accurately. It's a small loop running on the CPU increasing a counter until an MFP timer interrupts it - and from that counter you can then easily see how fast the CPU is. This counter has shown the exact same values on every computer I've run it, from ancient 520STs up to the latest recapped STEs etc. And there's no influence from machines being "cold" or "warm" that I've been able to see either.

/Troed

*) The vertical-scrolling-dude will flake out badly on 8.05MHz since the timer removing the lower border fails. All the other screens are fine. v1.1 will be released when it will be released ... ;)

[ijor]

Hmm, what's the accuracy of the original oscillators in the ST? Oscillators usually also deviate from the nominal value with time and temperature, but all the fullscreen demos I've tested on my now 30+ years old ST machines still work fine. How much can the oscillators deviate from the nominal value before we would start experience problems with opening of the borders?

They don't deviate with heat or age in any detectable way.

Of course they do. Crystals are obviously not perfect. They even have some jitter that you can detect. Check Paulo's and my program that measure the relation between both clocks. You would see the jitter and the variations across different machines.

If you are not detecting any deviation, then you are probably measuring wrong or not long enough.

Note that for computers with modulators the clock is adjusted from a third crystal. But I understand there won't be any modulator here?

[ijor]

I added code to my demo shell that detects the speed of the CPU accurately. It's a small loop running on the CPU increasing a counter until an MFP timer interrupts it - and from that counter you can then easily see how fast the CPU is. This counter has shown the exact same values on every computer I've run it, from ancient 520STs up to the latest recapped STEs etc. And there's no influence from machines being "cold" or "warm" that I've been able to see either.

Interrupt is not the best way to measure the frequency. Interrupts are triggered on an instruction border only. So you are measuring with a 4 cycles accuracy, in the best case.

If you want to measure the clock precisely (which you might not need for Closure), you start a timer, perform a software delay (as long as possible), and then you read the timer value again. The longer the delay the more accurate the measurement. If it's very long you might need to add periodic readings of the timer to detect and count overwraps.