Main HW / Emulator constants (MFP/CPU/DMA sound)

[ljbk]

Hi !



Well, may be this is not the perfect place to open this topic, but this is one of the possible ones.

One of the constants of the ST / STE system is the number of CPU cycles per VBL in PAL at 8 MHz: 160256 that correspond to 313 lines at 512 cycles each.

Something that is not constant anymore is the CPU clock even for 8 MHz versions. I have read somewhere that most of the STs have a 8021247Hz crystal. Mine, from 1986, has a 8007100 Hz crystal. What value are you using in Hatari ?

The MFP crystal i have is a 2457600 Hz one. Do you know if there are other versions ? What value are you using in Hatari ?

Finally, the STE DMA sound is said to work at maximum 50066 Hz and to have low-pass filters after that at 40% of the used replay rate according to the addendum and other HW info found on the Net. For those who have ever run Hextracker, one can see a calculated DMA performance assuming that the MFP crystal is really 2457600 Hz. With STeem, one gets around 50200 Hz. With SainT, one gets around 50100Hz. With Hatari, one gets 50069 Hz.
The thing is that the HW doing the Sound DMA job probably only has a simple counter to divide either the video master clock of 32 MHz or the CPU clock. To respect the MMU refresh rates, if the counter is related to the video master clock then its value has to be even. What if the sound DMA was working once every 80 or 160 CPU cycles depending if one byte or one word is read at once in stereo ? In that case the DMA rate would be exactly in line with the CPU clock. But if we use 8021247 Hz for the CPU, then the maximum DMA rate would be: 8021247 / 160 = 50133 Hz.
If the rate is really 50066 Hz and it is related to the CPU clock, then that CPU clock would be 50066 * 160 = 8010560 Hz.
How are you doing it in Hatari ? Do you have the sound DMA rate independent of the 8 MHz STE clock ?

I hope to have a SW test soon to check if the CPU and Sound DMA are related or not.

Thanks for any help you could provide.


Bye,
Paulo.

PS: My first version of CPU test tells me STeem is running at 8 MHz sharp with the Sound DMA at 50200 Hz while Hatari and SainT are running above 8 MHz but with variable results due to the handling of high frequency interrupts.
In the case of SainT, the values i get lead to a frequency of around 8,114 MHz with a Sound DMA at around 50100 Hz.
In the case of Hatari, the values i get lead to a frequency of around 8,149 MHz with a Sound DMA at around 50068 Hz.
Of course if the high frequency interrupt handling is not ok, then these values may be completly wrong ...
So aparently no relation between Sound DMA rate and CPU clock with the emulators.
The same test works on my real STF giving it a value of 8006805 Hz for a real crystal of 8007100 Hz !!!
I have to try with less frequent interrupts.

[Dio]

Presuming you mean that the /4 freq is 8.0071MHz, that's a new one on me. Any chance you could post a pic of the motherboard (detailed enough to read the marks on the chips)?

The frequencies most usually seen in standard STs are:
PAL and Peritel: 32.084988 -> 8.021247MHz
NTSC pre STE: 32.0424 -> 8.0106MHz
NTSC STE: 32.215905 ->8.053976MHz

I've seen a pic of one early STF which had a 32.02480MHz main crystal, which would give 8.0062MHz. The modulator-less machines presumably had a wider clock tolerance since they were expected to work with an Atari monitor which was known to lock into slightly lower frequencies. Yours is slightly different even to that one. Would yours also be modulator-less? (Ah, in your edit, sounds like yours is indeed a 8.0062MHz STF).

Since you need a lowest-common-denominator clock in an emulator, it's usual to take the PAL ST clock as 8.021248MHz which has a (reasonably) convenient common multiplier with the 2.4576MHz crystal. Exactly 8MHz is miles more convenient, but sometimes it sucks to be an emulator author .

I do have a program to measure the clockrate of a given ST that seems to be pretty accurate on the real hardware, using the MFP to provide a 64Hz tick and counting the CPU cycles executed between two MFP ticks. It's only accurate to about +- 500Hz though, since about 4 cycles is as accurately as you can determine the clockrate. Unfortunately it's tied into a framework with a lot of other code, but the core routine would be easy to chop out if you want to see it.

My presumption has always been that the 'nominal' clock for the DMA hardware is generated as you suggest with a /160. It should be possible to time the sound clock rate, since the current sample pos is visible. Program a timer to 64Hz, take an MFP timer interrupt, read the DMA position, take 64 more interrupts then read it again, and that should be the clockrate. The MFP is a solid realtime reference - the crystal should be rated to about 1 part in 100k, and the accuracy of the CPU timing measurements I've made (with known crystals on the motherboard) seems to back that up.

[ljbk]

Hi !


Thanks for the reply.

Attached you can find a pic of the video crystal.
As you see it is a 32.02840 MHz.
/4 = 8.0071 MHz

May be you have switched 2 digits: 32.02840 MHz to 32.02480 MHz ...

My goal here is to try to find out if we have a relation between the STE DMA rate and the CPU clock and also to have a good CPU clock speed detection.
This piece i built today seems to work fine on my real STF, but not really on emulators. May be it is because of the high MFP interrupt frequency. I have to try with less frequent.
Here is what i am using:

l_cpu_test:
lea vbl(pc),a0
move.l a0,$70.w new VBL handler
lea l_cpu_test_int(pc),a0
move.l a0,$114.w new timer C handler
moveq #50,d5 50 frames to wait for
moveq #-1,d6 start counter value
moveq #0,d1 MFP interrupt counter
move #$2300,sr all interrupts allowed
l_cpu_test0
tst d6
bne.s l_cpu_test0
move.b #10,$FA23.w
or.b #$10,$FA1D.w start timer
l_cpu_test1
cmp d5,d6
bne.s l_cpu_test1
and.b #$0F,$FA1D.w stop timer
rts

vbl:
addq #1,d6
rte

l_cpu_test_int:
addq.l #1,d1
rte

At the end of this test, D1 will have the number of processed interrupts during 50 VBLs.
As 50 VBLs are: 50x160256 = 8012800 cycles and the MFP interrupts are done at 61440 Hz (if the 2.4576 MHz MFP clock is to trust), the machine clock is then: 8012800 x (61440 / D1).
For my machine, i get D1=$F02E, so the clock is (61440 / 61486) x 8012800 = 80006805 Hz.
I repeated the test 3 times and i got the same value always.
With emulators, i always get a different value every time i test.

Bye,
Paulo.

[Dio]

Your method makes sense (although it relies on hidden numbers such as the cycles/VBL, so I didn't choose to go that route). Also agreed that while I may have lots of numbers in my head I have just failed my calculator-operating roll. 8.0071 it is.

I couldn't make that code work in isolation so I can't say what Emu says. I presume it's within a framework that disables all other interrupts and manages saving regs, etc.?

I've observed that high MFP interrupt frequencies can cause confusion with emulators. I haven't been able to make the theoretical numbers for MFP interrupts per second match the ones on a real ST, or therefore to make Emu match the numbers a real ST gives, and other emulators fail this too. The root cause here is probably the weirdness of the CPU talking to the MFP (e.g. the slower clock rate on the transaction, including things like the interrupt acknowledge cycles, but also not being subject to DRAM wait states) but your timing method should be immune to those problems, because the cycles per VBL is a number fixed in the Glue, rather than subject to the vagiaries of the asynchronous bus.

[npomarede]

Hello Paulo, I remember the very interesting thread about various cpu freq with sligth variation in the case of your ST and the impact on some overscan.

In the case of Hatari, we only use one CPU freq, which seems to be the most common European one.
This freq gives 160256 cycles per VBL (68000 at 8 MHz). The number of CPU cycles per VBL is really the key value to emulating most demos effect ; from this value, you then have the correct number of CPU cycles per second.

Regarding the MFP and CPU freq, Hatari uses a method shared by Leonard in Saint (and also used in sc68 sound player) :
the cpu freq is 8021248 (instead of the common 8021247 PAL freq, so nearly no difference, but allows to speed up some cpu/mfp cycles' conversions)
the mfp freq is 2457600
I don't know if there're other MFP freq in use ; but here again, the goal is to have a cpu/mfp freq combination that runs all known demos/games (the same used in my french PAL 520 STF for example).

Regarding DMA sound, from the STE schematic, CPU is using CLK8 and DMA sound is using its own 8.010613 MHz SCLK freq.
Accurate emulation really requires to have a different dma audio freq ; a good example that really required very fine timings is 'More Or Less Zero' by DHS where a very small rounding error would result at one point in skipping a whole audio dma frame and loosing sync between video and audio in the demo.

For Hatari, I also emulates the audio DMA FIFO. All in all, I compared Hatari's result with a real STE ones, using different tests :

1) play dma sound at 50066 Hz mono during 50 VBL, then read the dma counter :

Code: Select all

STE       nb bytes=$c364
Steem     nb_bytes=$c3e6-$c3e8 
Hatari    nb_bytes=$c362

-> CPU/VBL freq and dma audio freqs are nearly identical in Hatari to a real STE. Steem is slightly above.

2) play dma sound at 50066 Hz mono and read the dma counter at each HBL, during 240 HBL :
Here again, Hatari's results are identical to the ones measured on a real STE. Note that Steem's one are also identical. So as the previous test shows that Steem is playing slightly more samples after 50 VBL than expected, we can see that Steem does not use a correct DMA audio clock and that after each VBL a small error is added to the previous one.

It's strange your test program gives different results when ran several times under Hatari, I will try it under devpac to see what I get.

Nicolas

[ljbk]

Hi !

Thanks for the reply.

If i use the "normal" loop strategy, i get good results with all emulators and my STF:

l_cpu_test2:
lea l_dma_test_int(pc),a0
move.l a0,$114.w new timer C handler
moveq #50,d5 50 frames to wait for
moveq #-1,d6 start counter value
moveq #0,d4
move #$2500,sr only MFP interrupts allowed
move.b #246,$FA23.w
or.b #$70,$FA1D.w start timer
l_cpu_test4
tst d6
bne.s l_cpu_test4
l_cpu_test5
addq.l #1,d4
cmp d5,d6
bne.s l_cpu_test5
move.l d4,d1
rts

The result in D1 will be then corrected due to the 50 Hz timer error and to add the interrupt spent cycles.
This gives me 8020 KHz for STeem, SainT and Hatari. This also gives me 8006 KHz for my STF.
The precision is not too bad.
But if any kind of CPU cache is involved, this will not work.

I will try to put all this together in a simple and single program to:
- measure CPU speed via loops limited by 50 times a 50 Hz timer;
- measure relative CPU speed via VBL and high rate MFP interrupts;
- measure Sound DMA rate if available with 50 times a 50 Hz timer;
- output all values on screen;

The idea for me is of course to gain precision for Hextracker depending on the machine it is running on.


Paulo.

[Steven Seagal]

For Hatari, I also emulates the audio DMA FIFO. All in all, I compared Hatari's result with a real STE ones, using different tests :

1) play dma sound at 50066 Hz mono during 50 VBL, then read the dma counter :

Code: Select all

STE       nb bytes=$c364
Steem     nb_bytes=$c3e6-$c3e8 
Hatari    nb_bytes=$c362

-> CPU/VBL freq and dma audio freqs are nearly identical in Hatari to a real STE. Steem is slightly above.

2) play dma sound at 50066 Hz mono and read the dma counter at each HBL, during 240 HBL :
Here again, Hatari's results are identical to the ones measured on a real STE. Note that Steem's one are also identical. So as the previous test shows that Steem is playing slightly more samples after 50 VBL than expected, we can see that Steem does not use a correct DMA audio clock and that after each VBL a small error is added to the previous one.

Hi,

In 'SSE', I changed CPU and MFP frequencies but only for STF option, I kept STE ratio as measured by Steem authors:

Code: Select all

#define  CPU_STE_TH 8000000 // Steem 3.2 
// Between 2451168 and 2451226 cycles, as measured by Steem authors:
#define  MFP_CLK_STE_EXACT 2451182 // we use this for STE now
#define  CPU_STF_PAL 8021248 // ( 2^8 * 31333 )
#define  MFP_CLK_TH 2457
#define  MFP_CLK_TH_EXACT 2457600 // ( 2^15 * 3 * 5^2 )

Now seeing this table:

Code: Select all

              CPU speed      #samples

Steem         8000000          50152
STE           8021248          50020

Steem/STE   0.997351036    1.002638944
STE/Steem   1.002656       0.997368001

It seems Steem's CPU (->video) is too slow vs DMA sound.
Maybe I should change that too, it could help.

[ljbk]

Hi !

The values returned by the attached program, using the code loop strategy are:

SainT: 8020663
Hatari: 8020639
STeem: 8020471
My STF: 8006445

Anyone can use this to measure his or her machine clock.
But, remember that this program assumes that the MFP is REALLY working at 2457600 Hz.
This program might fail if the CPU uses any kind of cache or takes less than the 24 clock cycles for the main loop described above:

l_cpu_test5
addq.l #1,d4
cmp d5,d6
bne.s l_cpu_test5

Paulo.

[npomarede]

Hello
could you also post your program with a smaller loop that gives different results on emulators ?
I'd like to test it on my 520 STF and compare with Hatari to see where's the problem.

Nicolas

[ljbk]

Hi Nicolas !

Here is a new version of the program that presents two results, one with each method.
The program, with MFP, now works with Hatari and SainT and fails with STeem.
There a is a fault in the code about clearing something in the MFP before doing the test. May be the pending interrupts register or something like that. I have to check.
If the MFP/VBL test is done before the CODE LOOP test, like in the attached file, everything works.
If i change the order, some 61.44KHz interrupts do not happen or are not counted, even on my real STF, and i get variable value every time.
Yesterday, this code was in the Hextracker init part, so for STE it was done after the DMA speed test and so i did get variable results. For my STF, as there is no DMA test, it was the first test so i got always the same result.
Today, i moved the code to an independent program doing the MFP test in second and i was always having a different result even on my real STF.
Changing the order solves the issue but i have to find out what is missing.

Anyway the results are:

STeem:
MFP_VBL: 7987190
TIME_LP: 8020471

SainT:
MFP_VBL: 8021155
TIME_LP: 8020663

Hatari:
MFP_VBL: 8021155
TIME_LP: 8020639

My STF:
MFP_VBL: 8006805
TIME_LP: 8006445

Congrats as Hatari seems to work fine.
The problem with STeem is a performance one. If i change the CPU clock to 16 MHz, the test will return 8018020 (because it uses 160256 as constant and not twice that value). For all clock rates above that, i get the same result. For clock rates below 16 MHz, i get different result that will be lower as the rate goes down to the 8 MHz standard.


Regarding the STE Sound DMA, if you say that there is a separate clock, then how does the MMU solve the memory access requests from CPU, Memory refresh, Shifter and Sound DMA to provide "exactly" a 50066 Hz memory reading because the divider is then not multiple of 4 ...


Paulo.

[npomarede]

Regarding the STE Sound DMA, if you say that there is a separate clock, then how does the MMU solve the memory access requests from CPU, Memory refresh, Shifter and Sound DMA to provide "exactly" a 50066 Hz memory reading because the divider is then not multiple of 4 ...
Paulo.

Hi,

the STE uses an 8 byte FIFO for the dma audio. This FIFO is not very well described in any document I found, but from my understanding and based on different demos that required it to work, I think the FIFO is kept filled during each HBL, certainly when the MMU doesn't need to send data to the shifter (around cycles 480 or so of each line maybe, as it doesn't seem to be affected by overscan lines that display pixels during 460 cycles).
The STE's DAC part will then play samples from this FIFO at 50066 Hz for example with its own clock, but the fact that a small FIFO buffer is used allow to solve the problem of the 2 different CPU / DMA audio clocks.

You only need to be sure that you will always be able to provide samples as fast as they're used by the DAC ; as I wrote in Hatari's source :
"on a real STE, the 8 bytes FIFO is refilled on each HBL, which gives a total of 313*8*VBL_PER_SEC=125326 bytes per sec read by the DMA.
As the max freq is 50066 Hz, the STE can play 100132 bytes per sec in stereo ; so on a real STE the FIFO can never be empty while DMA is ON."
(we have ~50.053 VBL per sec in PAL, not exactly 50)

Nicolas

[npomarede]

Hi Nicolas !

Here is a new version of the program that presents two results, one with each method.
The program, with MFP, now works with Hatari and SainT and fails with STeem.
There a is a fault in the code about clearing something in the MFP before doing the test. May be the pending interrupts register or something like that. I have to check.
If the MFP/VBL test is done before the CODE LOOP test, like in the attached file, everything works.
If i change the order, some 61.44KHz interrupts do not happen or are not counted, even on my real STF, and i get variable value every time.

Maybe you should change the order in which you init the MFP ? Clear IER A/B regs, then clear IPR A/B regs ?

Anyway the results are:

STeem:
MFP_VBL: 7987190
TIME_LP: 8020471

SainT:
MFP_VBL: 8021155
TIME_LP: 8020663

Hatari:
MFP_VBL: 8021155
TIME_LP: 8020639

My STF:
MFP_VBL: 8006805
TIME_LP: 8006445

My 520 STF (French PAL model) : I get different results from time to time. The 3 combinations seem to be :
MFP_VBL 8010583 and TIME_LP 8010162
MFP_VBL 8010583 and TIME_LP 8010186
MFP_VBL 8010713 and TIME_LP 8010186

This is strange, it looks like a 32042400 NTSC base freq (8.010600 MHz), instead of the 32084988 freq (8.021247 MHz).
So my CPU freq would be different from most 8.021 models and from your 8.007 model ?

[ljbk]

Hello again !

I just solved the order problem.
Nothing to do with the MFP.
As i had the VBLs disabled for quite a while after the first test, when i enabled them, to do the second test, i get one imediatly fooling the sync mechanism. So the solution is to wait for 2 VBLs: start at -2 in D6 and wait for 0. This explains the different results as there was no sync ...
As you can see the MFP_VBL value is always bigger than the TIME_LP value and seems to be more reliable.
The loop time size is quite small (24 cycles) so the error should be a maximum of 24 cycles and i even correct the result adding 68 cycles for each of 50 interrupts: 44 for set-up, 4 for addq and 20 for rte.
The reason might be the precision of the MFP clock that is taken out of the MFP_VBL case.
As we have: clock = (50*160256)*(61440 / read_value), the MFP precision is in both sides of the division (61440 Hz interrupts and read value) and gets simplified.
It can also be something else, but i can not figure out what at the moment.
At least you know something about your machine you did not until now.

Now to the STE Sound DMA.
Thanks for you explanations.
That is a real possibility but only if the DMA only reads the data it needs at every scan line. It might fill the 2 FIFOs with 4 bytes each in stereo or 1 FIFO of 4 bytes in mono, and then at every scan line it only reads what it needs to fill the FIFOs.
If that is the case, then the DMA counter should increase 8 bytes in stereo or 4 bytes in mono after the first HBL and then increase some bytes at every HBL up to 8. There is a simple way to prove this behaviour: we just need to sync to the screen and read the DMA counter every 256 cycles (1/2 line). One of the two reads should have an increment of ... 0 bytes .
I will try to do that later.
If this is true then my last STE MFP mode in Hextracker 0.848 is limited to a sampling rate of 15.6 KHz (the HBL rate)despite having a 50 KHz looped replay ...


Paulo.

[npomarede]

At least you know something about your machine you did not until now.

Yes, as I have the serial nomber of my STF, I should try to find if there's a list somewhere of all SN and the possible characteristics of each model.

Now to the STE Sound DMA.
Thanks for you explanations.
That is a real possibility but only if the DMA only reads the data it needs at every scan line. It might fill the 2 FIFOs with 4 bytes each in stereo or 1 FIFO of 4 bytes in mono, and then at every scan line it only reads what it needs to fill the FIFOs.
If that is the case, then the DMA counter should increase 8 bytes in stereo or 4 bytes in mono after the first HBL and then increase some bytes at every HBL up to 8. There is a simple way to prove this behaviour: we just need to sync to the screen and read the DMA counter every 256 cycles (1/2 line). One of the two reads should have anincrement of ... 0 bytes .
I will try to do that later.

I don't think the dma cares about whether it's mono or stereo sound, I think it's much simpler hardware-side to always keep the fifo full by reading as much as 8 bytes each HBL. Anyway, if the audio's dac outputs stereo sound, the fifo will be read 2 bytes at a time, so in the end you get the same result, you will need to read 2 bytes again on the next HBL to fill the fifo again.

As for the test you're talking about, guess what, I already wrote it some months ago and tested it on a real STE

Code: Select all

        lea     $ffff890d.w,a1          ; low
        lea     $ffff890b.w,a2          ; mid
        lea     DMA_Init_Stereo_50K_Buf,a3

        lea     $ffff8209.w,a0

        moveq   #0,d0
.wait_video
        move.b  (a0),d0
        beq.s   .wait_video             ; wait for video counter to start (video line 63)
        not.w   d0
        lsr.w   d0,d0                   ; sync with the video
;-- 212

        move.b  #1,$ff8901              ; start dma audio

        REPT    100
        move.b  (a0),(a3)+              ; 12 cycles : video addr low
        move.b  (a1),(a3)+              ; 12 cycles : counter low
        ENDR

        move.b  #0,$ff8901              ; stop dma audio

        move.b  (a0),(a3)+              ; 12 cycles : video addr low
        move.b  (a1),(a3)+              ; 12 cycles : counter low
        move.b  (a0),(a3)+              ; 12 cycles : video addr low
        move.b  (a1),(a3)+              ; 12 cycles : counter low
        move.b  (a0),(a3)+              ; 12 cycles : video addr low
        move.b  (a1),(a3)+              ; 12 cycles : counter low

So, I start audio from $10000 to $20000 in stereo 50066 Hz, then I continuously read the the video counter and the lower byte of the current audio counter.
Of course, during the border, video counter will be always $a0 for example, but as each read takes 12 cycles, we now where we are (this loops takes 24 cycles, so it's not the maximum precision possible, but that's close enough to see how the dma counter is changing).
After synching with video, dma audio is started at cycle 212. We read 100 values, which gives some measures during approx 5 HBL.

Here's the results of an STE (video counter low value and audio counter low value) :

Code: Select all

; STE :
; Audio DMA 50066 Hz stereo init :
; 56 00 62 00 6e 00 7a 00 86 00 92 00 9e 04 a0 08 a0 08 a0 08
; a0 08 a0 08 a0 0a a0 0a a0 0a aa 0a b6 0a c2 0a ce 0a da 0a
; e6 0a f2 0a fe 0a 0a 0a 16 0a 22 0a 2e 0a 3a 0a 40 0e 40 0e
; 40 0e 40 0e 40 10 40 10 40 10 40 10 46 10 52 10 5e 10 6a 10
; 76 10 82 10 8e 10 9a 10 a6 10 b2 10 be 10 ca 10 d6 10 e0 14
; e0 14 e0 14 e0 16 e0 16 e0 16 e0 16 e0 16 e2 16 ee 16 fa 16
; 06 16 12 16 1e 16 2a 16 36 16 42 16 4e 16 5a 16 66 16 72 16
; 7e 1a 80 1a 80 1c 80 1c 80 1c 80 1c 80 1c 80 1c 80 1c 8a 1c
; 96 1c a2 1c ae 1c ba 1c c6 1c d2 1c de 1c ea 1c f6 1c 02 1c
; 0e 1c 1a 1c 20 22 20 22 20 22 20 22 20 22 20 22 20 22 20 24
; 30 00 3c 00 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

We can see that at position $9e, dma counter is already filled with 4 bytes (this is possible since the shifter doesn't need new data 16 cycles before the border that starts at $a0). From this, it seems the audio dma reads data as soon as the shifter doesn't need to be filled anymore for this line.
While video counter is $a0, we see we reach $0a in audio counter, so this means 8 bytes were read by DMA, but 2 were already played by the DAC. So the DMA can read 2 new bytes immediatly as the shifter has not started to display pixels yet.

We can also see that as soon as dma audio is stopped, current audio counter immediatly goes to the audio start address.

Nicolas

[Steven Seagal]

I know that my first contribution in this thread was superbly ignored, but here's what the program cpuclk2 gives in the current Steem beta anyway:

mfp_vbl 7987449
time_lp 8020639

edit:
and here's a comment in Steem source that probably explains the why and how to solve (Steem uses a ratio):

// To make this more accurate for short timers, we should store the fractional
// part as well. Then every time it times out, increase the fractional part and
// see if it goes over one. If it does, make the next time-out a bit later.

[npomarede]

I know that my first contribution in this thread was superbly ignored, but here's what the program cpuclk2 gives in the current Steem beta anyway:

mfp_vbl 7987449
time_lp 8020639

Those are not the same values Paulo reported, maybe you used a different STF/STE mode than he did ? (Or maybe you get different values when running the program several times ?). Anyway the difference with his values if not really big.

I can't say if you should change cpu freq from 8000000 to 8021247 for example, as maybe Steem is using this value to compute some other important timings and this could break other things (it's true that for correctness a cpu freq close to 8.02 MHz would be better in the mfp_vbl test)
But what is sure is that you should get slightly identical cpu freq in the 2 tests made by Paulo and this is not be the case (the mfp code is using a cpu/mfp ratio based on a 8021248 freq, while rest of Steem is using a cpu freq of 8000000)
It could be harmless for now not to change it, but maybe some programs are relying on this to work fully (as the audio/video sync problem I had in DHS' More Or Less Zero demo).

Nicolas

[Dio]

From this, it seems the audio dma reads data as soon as the shifter doesn't need to be filled anymore for this line.

Yeah, that's what I'd expect, the simplest logic is just to insert the FIFO-not-full signal (I presume this is SREQ from the GST shifter to the MCU, on the board) as the next logic on the MMU phrase bus priority list, so:
next_MMU_phase = (DE* ? video_phase) : (SREQ ? sound_phase) : refresh_phase;

So the 8-byte FIFO will fill from empty in 32 clocks. Good research to prove it.

(* - not quite DE in the STE - at least, not the same DE that's capturable on the motherboard in the earlier STEs, because of the 4-word extra readahead for H-scrolling).

[Steven Seagal]

Those are not the same values Paulo reported, maybe you used a different STF/STE mode than he did ?

Obviously Paulo uses Steem 3.2 and I use the last beta of SSE 3.5.1.

I just made a little mod as suggested by Steem authors for short timers (see edited post above), and with that it gives the exact same values as SainT:

MFP_VBL: 8021155
TIME_LP: 8020663

Of course it's some more computing.

[ljbk]

I know that my first contribution in this thread was superbly ignored, but here's what the program cpuclk2 gives in the current Steem beta anyway:

mfp_vbl 7987449
time_lp 8020639

edit:
and here's a comment in Steem source that probably explains the why and how to solve (Steem uses a ratio):

// To make this more accurate for short timers, we should store the fractional
// part as well. Then every time it times out, increase the fractional part and
// see if it goes over one. If it does, make the next time-out a bit later.

Hello !

Your contribution was not ignored at all.
I already included all the values detected with STeem 3.2 above and even described that the behaviour changes if you have a higher cpu clock:

"
STeem:
MFP_VBL: 7987190
TIME_LP: 8020471

SainT:
MFP_VBL: 8021155
TIME_LP: 8020663

Hatari:
MFP_VBL: 8021155
TIME_LP: 8020639

My STF:
MFP_VBL: 8006805
TIME_LP: 8006445

Congrats as Hatari seems to work fine.
The problem with STeem is a performance one. If i change the CPU clock to 16 MHz, the test will return 8018020 (because it uses 160256 as constant and not twice that value). For all clock rates above that, i get the same result. For clock rates below 16 MHz, i get different result that will be lower as the rate goes down to the 8 MHz standard.
"

Nicolas,

Many thanks for your perfectly clear Sound DMA test program proven on STE.
I adapted a bit my Sound DMA speed test and then i get 50066 most of the times with Hatari.

So, i offer you the last version of this HW test program that will show:
- the VBL cycles;
- the MFP VBL clock (if cpu is at 8 MHz);
- the calculated MFP VBL clock using above values (if cpu is not at 8 MHz);
- the TIME LOOP clock;
- the Sound DMA speed when possible;

With this you can clearly see that STeem uses a 50200 Hz rate for Sound DMA and SainT uses a 50100 Hz rate for Sound DMA.

But for me, the idea behing this is to adapt precisely Hextracker to the machine it runs on, even if it is a Falcon and the Sound DMA speed is below 50 KHz(done already) or if there is a 0.25% difference in the CPU clock and the replay mode is not synched to a MFP timer but to the VBL or a HBL. In that case, the 50 Hz frame time length depends on the CPU clock and not on the MFP. This means that the number of mixings will not be exactly the same as if the replay was synched to a MFP timer.
These are details, but at sound level and with high replay frequency, they can matter.


Enjoy,
Paulo.

[npomarede]

Many thanks for your perfectly clear Sound DMA test program proven on STE.
I adapted a bit my Sound DMA speed test and then i get 50066 most of the times with Hatari.

So, i offer you the last version of this HW test program that will show:
- the VBL cycles;
- the MFP VBL clock (if cpu is at 8 MHz);
- the calculated MFP VBL clock using above values (if cpu is not at 8 MHz);
- the TIME LOOP clock;
- the Sound DMA speed when possible;

With this you can clearly see that STeem uses a 50200 Hz rate for Sound DMA and SainT uses a 50100 Hz rate for Sound DMA.

Thanks, it's always interesting to have simple test programs we can run under different configurations to benchmark emulation's accuracy.

I tested this on my 520 STF TOS 1.0 FR (SN A17714012804) and I'm putting the results here just for the record :

• VBL CYCLES: 160244 (160256 / 8 MHz)
  MFP_VBL CLOCK: 8010583 or 8010713 or 8010583 (IF CPU @ 8 MHz)
  MFPCALC CLOCK: 800997 or 8010101
  TIME_LP CLOCK: 8010145 or 8010170
  SOUND DMA: TEST NOT POSSIBLE !

Hatari 1.7 dev version :

• VBL CYCLES: 160244 (160256 / 8 MHz)
  MFP_VBL CLOCK: 8021155 (IF CPU @ 8 MHz)
  MFPCALC CLOCK: 8020543
  TIME_LP CLOCK: 8020639
  SOUND DMA: 50066

Nicolas

[ljbk]

For the record, my 1040 STF, with the 8.0071 MHz crystal, SN is: A1 65 4008220.

Paulo.

[Dio]

Is yours the same revision, etc. as this one, which has also has the 'unusual' crystal?

[ljbk]

Is yours the same revision, etc. as this one, which has also has the 'unusual' crystal?

Yes, this is exactly the same board.
In the back of my keyboard, "made in japan", there is a date: 14/04/1986.
But i only got my STF in December 1986.
As already discussed with Ijor in a topic in 2011, my HW displays the complete 29 lines for the top border. It is not one of those that only displays 13 lines. Otherwise i would not have made "The Overscan Demos" back in 1990.

Cheers,
Paulo.

PS: I moved the HW talk to the Hardware section: http://www.atari-forum.com/viewtopic.ph ... 20#p229120

[Dio]

Yeah, I think most 1986 machines have the -38A Glue, even STMs. I haven't yet seen a -38 that's got a 1986 time code on the Glue itself (or in an STF case) - the latest I've seen as a build date is Q1 86 (although I don't have clear data for Q2/Q3, so the most I can say for certain is that the -38A started shipping between Q1 and Q4).

Most of the chips are time coded "YYWW" where WW is the week of the year. The early ST custom chips are YL# where Y is the year and L# is, I think, (letter*4)+# week. Generally the machine's manufacturing date is a month or two after the latest date code on the chips, and where I've got info the sale date is roughly 2-3 months after that for the most popular machines like the 520STFMs, but longer, 6-9 months for less common ones like STFs, and STMs once the FM was available.

I've got a spreadsheet with about 20 machines on it now, been collecting motherboard pictures. Later STs are almost comically random in their motherboard and parts choices, they were making at least 3 and maybe as many as 5 different major variants simultaneously, possibly to exploit cheap sources for DRAM that required the ability to handle lots of different DRAM package types.

I've 2 STF boards (plus yours now) and the other 70523- C is that one, also with the 32.0284 crystal. The 70789-D pic has a standard PAL ST crystal.

[Steven Seagal]

Steem will not be left behind!

Since in Steem there's no independent DMA clock, it is computed using CPU clock, it is important to have the latter right.

Sometimes the value for MFP_VBL is different, eg 8021286, the others are more stable. Could be a problem with VBI, that isn't always perfect in Steem.