How really fast is your ST?

[ijor]

Do you know the exact speed of your ST machine?

I was lately studying the Overscan/full screen topic. I think I found some answers and explanations that were never found before (or at least they were not disclosed), including some interesting new stuff. Expect some articles to be published shortly. In the meantime here it is an issue, perhaps not directly related, but very relevant to the topic.

As you may know, an MFP timer interrupt was a common method for opening the top border. But the full screen coders soon found out that the interrupt time depends on the specific machine:

(from Alien’s great article)
Third bet, the latency to service the MFP interrupt will always be the same. This is true for the ST/STF series, but some STEs that I was able to test (thanks to Laurent) triggered the interrupt 60 cycles later than on a STF!

I was quite amazed when I read that. A few cycles is reasonable as interrupt jitter or because minute differences among machines in the interrupt latency. But 60 cycles is far too much.

Then Paolo gives a better explanation:

MFP handling also has another problem: it has a separate clock from the CPU and the 68000 does NOT have the same frequency for every ST: 8007100 for mine but 8021247 for most

Well, that certainly explains the difference. But I still thought that it is extremely weird that the machine clock is not the same in all the computers. But … wait ... is it really weird? Not at all, and it is actually obvious why. Considering that many ST coders come from the 8-bit or were also Amiga coders, it is amazing that the actual reason was not known.

Do you get it now? No … hint, hint: Why some Atari 8-bit computers have a slightly different clock than others? Why this happens also in the Amiga?

YES, you got it. There are PAL machines, and there are NTSC machines. And STs are not the exception. And there is no other possibility. The color clock that drives the TV signal must be different for both TV norms. And this is actually described in newer ST and STe schematics.

So Paolo, you have an NTSC computer! Note that the PAL vs. NTSC clock is important only for the modulator. The vertical and horizontal frequency doesn’t need to be exact as per the norm. Only the color clock must be. So it is very possible that computers without modulator in Europe had the NTSC clock. Actually, it is possible that all the earlier models (that didn’t have modulator) had the NTSC clock.

Below is a small program that will measure the main clock of the computer, in relation to the clock of the MFP timers (which is supposed to be constant). The program doesn’t attempt to measure the clock with extreme precision. Just with two decimal digits accuracy that is enough to distinguish the machine. It shows the value of the main clock/oscilator, which is ~32 Mhz (four times the CPU clock).

Note that according to the schematics there is a big difference between the clock on NTSC STf, and NTSC STe models. I’m not sure exactly why. Would be interesting if somebody with an US STe to see the actual result.

[bolle]

Thanks ijor for this great article. More of that stuff!

I've no experience in the full screen issue and will never program anything in that direction, but I really like those kind of technical readings.

Besides, it's well written and was easy to read and understand.

So again: More of that stuff! I'm waiting.

[ijor]

A couple of additional notes.

The program above is mostly useful for computers without modulator. On those with modulators all computers should have the crystal corresponding to the TV norm. Mega STe users need to set 8Mhz and disable cache.

These are the nominal values of the crystals:

Code: Select all

32.0424   MHz   NTSC ST (non STe)
32.04245  MHz   NTSC Mega ST
32.084988 MHz   All PAL computers.
32.215905 MHz   NSTC STe/MEGA STe

Note the very small difference in the Mega ST (no idea why). Btw, I don’t know if there is such thing as a PAL Mega ST.

Note also the quite big difference between NTSC ST and NTSC STE. I’m not sure exactly why. I suspect this is related to the fact that the STe has separate clocks for sound and floppy.

[leonard]

Hi Ijor,

As always, very interesting stuff. When coding MFP in SainT, I had some accuracy problem with MFP and CPU clock.

Could you provide the source code of your "cpu speed tester" please? I'm interested the way it works. (what's your time base: MFP ?)

Thanks !

[ijor]

Hi Leonard,

Btw, congratulations to you and all the french atarians in reaching the final ... not sure you are in the mood for computing right now

Could you provide the source code of your "cpu speed tester" please? I'm interested the way it works. (what's your time base: MFP ?)

Sure, I will send you the source.

Yes, I am using the MFP timers as the time base. Or more precisely, I am measuring the relation betwen CPU and MFP (timer) cycles. It is pretty simple.

The most complicated part is that I am using 64-bit fixed-point arythmetics. It is not really needed for the precision shown by the program. Initially I wanted to compute it with much higher accuracy. But then I found out that I didn't reach the expected values on real hardware. I thought that it could be a bug in the program. But then I realized that it is probably that just the crystals are not precise enough.

Crystals have manufacturing tolerance (they don't come out of the factory exactly at the nominal value). They have jitter. And they also have aging, which might be quite significant in crystals that are 20 years old.

So I finally decided to chop the output to 2 decimal digits, even when the program computes a few more. Of course that this crystal jitter/aging issue is not relevant under emulation. So the full precision might be handy for your tests.

[leonard]

Btw, congratulations to you and all the french atarians in reaching the final ... not sure you are in the mood for computing right now

Yeahhhh !!! Everybody said french team were old and ugly, and we're in final !

Ok, feel free to post your source code. 64bits arithmetic is funny to code with 68000 cpu

[ijor]

Here it is the souce of the routine. Sorry for the delay, I just wanted to add detailed comments.

It is not the complete program. The prolog and the epilog are missing (they are trivial). The 64-bit routines are also missing. They are missing just because they are buried in libraries and aren't part of the same source file. I can provide them if needed.

Code: Select all

;
; Routine to compute actual ST main clock.
; by Ijor
;
; The MFP timers crystal is used as the time base.
;
; The result is accurate to 3 decimal digits, it could
; easily be adapted for more digits. And for this
; purpose 64-bit integer division is used.
;
; The routine counts the cycles of an MFP timer
; for a constant number of CPU cycles.
;
; Then, from the two constants (CPU cycles and MFP
; clock) plus the counter timer cycles, the CPU
; clock can be computed.
;

;
;
; Must come here on Supervisor mode
; with interrupts disabled
;

; This bits value shifts left the number of
; iterations. Higher values might be needed
; for higher precision, but it would then be
; also slower.

NBITS	= 4

	; We use Timer B. But any MFP timer in delay
	; mode is just fine.

	lea		(TBDR).w,A1	; Timer B data register
	clr.b	(TBCR).w	; Stop timer
	clr.b	(A1)		; Set timer value to 0 (256)

	moveq	#0,D6		; Init counters
	moveq	#0,D1		; Will be used in addx
	move.l	#($1000<<NBITS)-1,D7
	moveq	#-1,D2		; Init previous value
	moveq	#-1,D4		; Init higher bits of start value

	move.b	#1,(TBCR).w	; Start timer with divide by 4

	; Delay to make sure timer is running. This way
	; we also avoid dealing with internal MFP Delays.

	rept	8
	nop
	endr

	; Number of CPU cycles start here

	move.b	(A1),D4			; Fetch initial timer value

	; This delay is to compensate for the last part
	; of the loop after reading the timer.
	; The idea is that the number of CPU cycles
	; between the two first timer readings, would
	; be the same as the loop cycles.
	; It is not strictly necessary, but it makes
	; easier to compute the total number of CPU
	; cycles

	rept	8
	nop
	endr

	; The close loop is just for the purpose
	; of monitoring timer overwrap. It might
	; be possible to get along using interrupts.
	; But this way is much simpler.
	; We need to increment a counter after each
	; timer overwrap. Because the loop is small
	; we know the timer overwrapped whenever the
	; new value is higher than the previous (MFP
	; timers are countdown). A reading of zero
	; would actually be an overwarp. We don't need
	; to deal with this on the loop. We adjust for
	; this special case after the loop.
	;
	; We avoid a conditional branch, again just
	; for an easier cycle counting.

.next
	nop
	move	D2,D3			; Save previous value
							; Number of CPU cycles end here.
	move.b	(A1),D2			; Fetch timer
	sub.b	D2,D3			; If new values > previous
	addx.l	D1,D6			; then we get a carry

	subq.l	#1,D7			; Avoid DBF in case we want
	bcc.s	.next			; more than $10000 iterations
							; The loop takes 52 CPU cycles

	neg.b	D2				; From countdown to countup
	bne.s	.notz			; Deal with special case of zero
	addq.l	#1,D6			; MFP timer overwraps before zero
.notz						; So $00 is actually $100
	lsl.l	#8,D6			; Combine higher bits counter
	or.b	D2,D6			; 
	add.l	D4,D6			; Substract starting cycles (it's negative)


	; D6 now holds the total # of timer cycles.
	;
	; We know exactly the # of CPU cycles between
	; the first and last reading of the timer.
	; It is fixed and can be pre-computed. In this
	; case is (4096 * 52) << NBITS
	; If NBITs = 0. It is 212,992 cycles.

	; MFP timers clock is: 2.4576 Mhz
	; We used a division by 4 prescaler.
	; So the effective clock is (2.4576/4) = 0.6144 MHz.

	; The computation required to get CPU clock is:
	; (Total # of CPU cycles) * (timer clock) / (timer cycles)

	; The multiplication is between two constants. Can be
	; precomputed then. For NBITS = 0 is:
	; 130862.2848 (4096 * 52 * 0.6144)
	; To avoid floating point, we just multiply by 10,000
	; So we get: 1,308,622,848
	; This happens to be (not by chance) a nice round hex
	; number: $4E000000

	; We still need to shift left by NBITS.
	; Could be done at assemble time as well.
	; But most assemblers can't deal with 64-bits integers.
	; It could be still be done at assemble-time using some
	; small trickery if you insist.

	move.l	#$4E000000,D0
	moveq	#NBITS+2,D1	; Two bits more for getting the main clock
	bsr		lshft64		; Shifts left, gets a 64-bit result

	; Dividend is now in D1:D0

	move.l	D6,D2		; Timer cycles, divisor
	bsr		div64		; 64-bits by 32-bit division

	; Result is now in D0
	; It is the computed main crystal * 10,000
	; Main crystal is 4 times CPU clock.

[DrCoolZic]

Btw, I don’t know if there is such thing as a PAL Mega ST.

I have looked at the original schematics from Atari and for the STF and STE, the crystal values you indicate are clearly differentiated for PAL/NTSC version. However on the Mega STF schematics (I do not have Mega STe schematics) there is no indication of a PAL/NTSC versions which seems to indicate that the Mega ST only existed in one version?

While on the clock subject I have looked at the complete ST clocks distribution and if I read the schematic correctly for an STF we have:

• The ~32 MHz clock is transformed to a 16 MHz clock by the shifter
  The 16MHz clock is processed by the MMU to produce an 8MHz clock (for the CPU / FDC and GLue chip) and a 4MHz clock (for the MFP)
  The 8 MHz clock is processed by the Glue to produce a 2MHz clock (for the PSG) and a 500KHz clock for the ACIA.
  The MFP received another 2.4576MHz clock from a separate signal.
  The RF modulator receives a 3.579545MHz clock in NTSC and a 4.433618MHz clock in PAL

There are some other miscelaneous clock ignored in this description.

Then Paolo gives a better explanation:
ljbk wrote:
MFP handling also has another problem: it has a separate clock from the CPU and the 68000 does NOT have the same frequency for every ST: 8007100 for mine but 8021247 for most

The 8021247 (i.e. 32.084988MHz) makes sense as comming from a PAL system but what about the 8007100 (i.e. 32.028400MHz) ???

The distribution is very similar in the STe (except chips differs) but found an interesting difference: in the STf the FDC receives the same ~8Mhz clock as the CPU while the STe has a separate crystal @ 8.010613 MHz (and apparently some models with the Ajax chips have 16MHz) for the FDC.

Back to the subject of overscan: is this somehow related the "wakeup up" mode you describe in http://www.atari-forum.com/viewtopic.php?t=9056 ?

I have also read in an article on overscan where they mention the following:

At 60 Hz, the picture starts at line 34 and ends at line 234.
At 50Hz, the picture starts at line X and ends at line X+200.
The value X depends on the genation of the GLUE:
For older STs: X = 63-16 = 47 for "newer" STs: X = 63.
In other words, on older STs, the picture is shifted upwards by 16 lines at 50Hz: this explains why some obtains only 249 lines whereas others get 271 lines for a simple Low-Border Overscan.

Do you know if this could be an incorrect interpretation of the fact that we have ST with different clock? or is this a totally different issue?

Jean

[leonard]

quite funny program

SainT gives exactly 32.08 (saying it's pal).

[Marcer]

ijor. to be honest. about how fast is your computer..

steem is slower than my comp (in 8mhz mode).. since some of my old gfa demos seems to not make it in 1 vbl in Steem.. but they work perfect on my real ste

// Marcer

[ijor]

The 8021247 (i.e. 32.084988MHz) makes sense as comming from a PAL system but what about the 8007100 (i.e. 32.028400MHz) ???

I don't know. But I guess that Paolo made a mistake. Either he made a typo on the post. Or either he measured it wrong (if he did). Or something like that.

The distribution is very similar in the STe (except chips differs) but found an interesting difference:

Yes, the STe has a couple of extra crystals. See my last paragraph in my second post of this thread.

is this somehow related the "wakeup up"

No. It shouldn't have any relation at all.

I have also read in an article on overscan where they mention the following:
At 50Hz, the picture starts at line X and ends at line X+200.
The value X depends on the genation of the GLUE:

No. No relation with this issue either.

[ijor]

steem is slower than my comp (in 8mhz mode).. since some of my old gfa demos seems to not make it in 1 vbl in Steem.. but they work perfect on my real ste

I doubt this is related to the crystal issue.

I would suspect this is related to inaccurate emulation. But can't really say without more details.

[karlm]

Btw, I don’t know if there is such thing as a PAL Mega ST.

I have looked at the original schematics from Atari and for the STF and STE, the crystal values you indicate are clearly differentiated for PAL/NTSC version. However on the Mega STF schematics (I do not have Mega STe schematics) there is no indication of a PAL/NTSC versions which seems to indicate that the Mega ST only existed in one version?

Might this be because the Mega never had a modulator? I don't recall if they had one, but that may be why no difference as the crystal oscillators would not need to be different.

karlm

[ljbk]

Hello all,

Well i can assure you that all STs do not have the same CPU speed.
My ST has a video cristal of 32028400 Hz (read in the real HW not measured).
This means that the 68000 receives 1/4 of that: 8007100 Hz.
This also explains why the Dark Side Of The Spoon does not work on my ST for all screens that use a complete full screen: no top, no bottom, no left and no right.
I found about those differences when writing the Overscan Demos.
Here in Portugal, we have several generations of STs, but mainly the first ones with UK or US TOS and the latter ones with Spanish TOS.
When testing the Earth screen on a Spanish TOS ST, i found out that it did not work.
The reason was a real CPU time difference for an exactly same timer delay.
The MFP has a fixed clock of 2457600 Hz due to compatibility requirements with modem speeds.
At exactly the same video screen timing, 45 lines after the bottom border removal (if i remember it right), a timer is started counting for a certain amount of time to trigger the top border removal.
But on the Spanish TOS machines, the timer expires too early or too late (i can't remember) and so the border was not removed.
So i solved the problem at the time by testing the timer speed against the CPU and determining a value for a DBF wait loop that would be dependent on the machine. This worked then on all machines i had access to.
Later on, i found some better ways to remove the top border.
If you check the thread regarding the Panic screen:

http://www.atari-forum.com/viewtopic.php?t=5253

you will see that the first version did not work on some real machines.
I only changed 1 byte (in fact 1 bit) between the first and the second version: yes it is a timer data value.
I had to use a timer way to trigger the top border removal because the screen uses almost every single one of the 160256 CPU cycles per VBL in PAL.


Cheers,
Paulo.

[ljbk]

Hi !

I just tested your program.
I get:

Computed clock: ~32.02 MHz
Machine: NTSC


32.02 / 4 = 8.005 MHz for the 68000
In fact as i said the crystal is a 32028400 Hz one.

Cheers,
Paulo.

[ijor]

Hi Paulo,

Computed clock: ~32.02 MHz
Machine: NTSC

32.02 / 4 = 8.005 MHz for the 68000
In fact as i said the crystal is a 32028400 Hz one.

That's quite interesting, and strange. ST (non STe) machines should have a crystal value of 32.04245 MHz (NTSC) or 32.084988 MHz (PAL). That's according to the schematics, and also according to the parts sold by Best Electronics.

I don't know if your case is unique (don't see any crystal/oscillator at that frequency on Best Electronics). Or if there are more machines like yours.

Which model exactly is your ST (STfm/STf/STm/ST)?

[ljbk]

Hi !

My machine is a 1040STF (no modulator) i bought i December 1986 with english TOS even if the sticker where the serial number is refers 1040STFM (the place for it is there on the PBA, but it is not there).

Serial number: A1 65 4008220.

I can even open the box once again and post a pic of the crystal if you insist but is it really necessary ?

Btw, my name is Paulo (Paolo is the italian variant as Pablo is the spanish one and Paul is the french one ...)

[ijor]

I can even open the box once again and post a pic of the crystal if you insist but is it really necessary ?

Nah, of course that that won't be necessary.

What could be interesting if others with old ST (non STe) computers, specially those without modulators would run the test.

Btw, my name is Paulo

Yeah, I know, I realized my mistake. Sorry about that. editing my post ...