Atari STE video & DMA sound frequencies


Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

Post Reply
Atari freak
Atari freak
Posts: 55
Joined: Sat Mar 15, 2014 11:23 pm

Atari STE video & DMA sound frequencies

Post by fenarinarsa »

Christmas topic :)

When I developped Bad Apple I found out that the STE DMA frequencies may not exactly be the ones that are in every documentation.
This also applies to vertical video frequencies.

Atari ST video frequencies are often described as:
50Hz (PAL)
60Hz (NTSC)
71Hz (hig-res)

However it seems high-res is actually 71.2Hz and not 71Hz.

The same goes with STE DMA audio:

6258 Hz
12517 Hz
25033 Hz
50066 Hz

I read somewhere (maybe here) that the frequencies are actually derived from a main frequency and the values above are rounded.

For Bad Apple I needed to know all exact frequencies because the audio is multiplexed with the video. If audio frames are too small or too large, there is a sync drift that ends up with audio frames being played twice or skipped.
To be precise, the demo runs at 60Hz and plays a 50066 Hz sound in stereo, so the average audio frame should be 1668,87 bytes. I round it to 1668 and my generator adds a pair of bytes from time to time to stick to 1668,87 globally.

The audio DMA is then set to loop mode and the next audio frame addresses are loaded into the DMA register while an audio frame is already playing. This was to avoid using Timer A which may fire too late because of blitter transfers... and honestly it would make some things more complicated.

But... it doesn't work as expected.

When I fire a Timer A to see where the DMA loop point occurs, I can see a big drift in time. Also I noted that the drift is different on real hardware and on emulators.
I had to change the data used for my calculation and found out that the best result I could get was with (2* 50035)/60 = 1667,83 bytes/vbl.

It works, but I wondered why 50035? Or maybe this is the video frequency that's not 60 but something else?
Or maybe I'm completely wrong and my code is crap :roll:

Now I'm doing a high-res version and I have the exact same issue, except that the audio drift is really huge. Currently the best shot I could get to make it work on emulators is (2*50005)/71.2 = 1404,63 bytes/vbl. And various emulators behave really differently in monochrome. I couldn't test it on real hardware yet.

To be honest I had the exact same kind of issues back in the 1990's when I worked on an Amiga TFMX conversion.
Last edited by fenarinarsa on Sun Dec 24, 2017 11:18 am, edited 1 time in total.
User avatar
Atari God
Atari God
Posts: 1460
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Atari STE video & DMA sound frequencies

Post by troed »

PAL ST VBL is always 160256 cycles. However, there are different clock speeds used (8.007, 8.01, 8.02 and 8.05MHz). For the STE, only 8.02 ("PAL") and 8.05 ("NTSC") are relevant*.

You can back-calculate everything from this I believe, together with the info that "NTSC" (60Hz) scanlines are 508 cycles long, "PAL" (50Hz) are 512, mono are 224 and the number of lines per frame for the different screenmodes are 263, 313 and 501 respectively.

(I have 71.4Hz in my notes for mono for some reason, but 71.2Hz is also commonly stated)

I have no info on how the STE DMA replay frequencies are calculated.


*) Exact clocks are found by taking the circuit on the motherboard's frequency and dividing by four:

32.0424 MHz
- early STF, also NTSC
32.04245 MHz
- Mega ST
32.084988 MHz
32.215905 MHz

Additionally, there exists some, very few, 8.007MHz STs. Paulo Simoes has one, it might be Atari having been cheap or a simple mis-order where 32.0242 was bought instead of 32.0424 (although that would be 8.006MHz .. )
User avatar
10 GOTO 10
10 GOTO 10
Posts: 1964
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Atari STE video & DMA sound frequencies

Post by Cyprian »

In ST/STe Video frequecies are calculated from formula:
- VBL = Mainclock / 4 / CPU clocks per line / Lines per VBLANK
- HBL = Mainclock / 4 / CPU clocks per line

And now some contants:
1) STE Main clock: 32 084 988 HZ

2) Color mode "50Hz":
- CPU clocks per line: 512
- lines per VBLANK 313

3) Color mode "60Hz":
- CPU clocks per line: 508
- lines per VBLANK 263

4) Mono "71Hz":
- CPU clocks per line: 224
- lines per VBLANK 500 or 501 (I'm not sure)

"VBL = Mainclock / 4 / CPU clocks per line / Lines per VBLANK"
- Color mode "50Hz": 32084988 / 4 / 512 / 313 = 50,05270941 Hz
- Color mode "60Hz": 32084988 / 4 / 508 / 263 = 60,03747642 Hz
- Mono "71Hz"
32084988 / 4 / 224 / 500 = 71,61827679 Hz
32084988 / 4 / 224 / 501 = 71,47532613 Hz

Btw, check this topic Test your CPU speed (and Sound DMA speed)

Troed was faster :)
Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
Atari freak
Atari freak
Posts: 55
Joined: Sat Mar 15, 2014 11:23 pm

Re: Atari STE video & DMA sound frequencies

Post by fenarinarsa »


No matter how hard I searched, I couldn't find those numbers (even here, I didn't find that thread Cyprian). And the Atari wiki has been down for years :(

So if I compare the result I found by trial & error
(2*50035)/60 = 1667,83 bytes/vbl

to the actual numbers
(2*50066)/60.03747642 = 1667,82 bytes/vbl

Aaaaaaaaand that's it. I knew the numbers we can read everywhere were surely rounded.

That's why I was looking for the correct info. Again thank you so much both of you \o/
Posts: 5
Joined: Tue Jul 31, 2018 10:22 pm

Re: Atari STE video & DMA sound frequencies

Post by MarkP »

I can't speak for anyone's STe's, but here's a potentially disruptive datapoint for the above list: my own 1040 STF (with a sticker on the bottom suggesting a June '87 manufacture date, but with only the Nov '85 v1.00 TOS) that I have had eyes on the motherboard of in the last couple days... and was somewhat surprised to find had a 32.04245 MHz master crystal (so CPU/bus frequency of 8010612.5Hz) installed. From what else I've read about the crystals in STs, I was expecting something a touch slower. Oh, and it's a PAL machine... which never offered any suggestion of it being anything other than absolutely normal up until this point.

(It's not running at the moment so I can't use the speed measurement program in the linked thread, and in any case that seems to be dead since a couple years ago already)

Anyway, maybe slightly cold info, but something else that is worth considering when trying to precisely time STe audio and that I only found out to my surprise not that long ago: regardless of your actual system clock, the machine *also* has a 8.010613MHz crystal install *specifically* to run the DMA audio system. I had originally figured all STe's ran at 8.010613MHz (and so had a 32.042452MHz master crystal) given that the official very specific sample rate of 50066.33Hz is 1/160th of that frequency, hence the surprise at finding both different clocks for PAL/NTSC, and then the matching clock inside my STF. Presumably Atari developed the DMA system using that particular STF clock then found that for some reason they needed to change the actual system speed, after already defining the sample rates (strange that they never seemed to be that bothered about fiddling the monitor scan rates around as a side effect of changing clocks, or the Yamaha soundchip tuning and replay rate of software-produced samples), so had to include the additional clock. Otherwise the actual DMA frequencies would instead end up based off anything up to 50337.35Hz in some systems, which would produce a noticeable transposition of tuned samples...

So if you're having trouble figuring an accurate relationship between the DMA clock and the rest of the system... that's the reason. Not only is the relationship going to be different in an NTSC machine vs a PAL one (and particularly, make your samples go out of tune vs the YM on different machines if you use both in concert; particularly I think the TT uses the NTSC crystal regardless of region, so if you're in PAL-land and try to play something written on an STe on a TT or vice versa... bad news, like trying to play music from a PAL and NTSC Amiga in sync without genlocking them together), but the effect of temperature dragging the exact crystal frequency up or down could well act on one of the oscillators to a greater degree than the other and so cause them to desync in spite of your best efforts at precalculating the relationship.

Probably your only real way to lock them together is to use the CPU to throw values at the DACs directly, if that's even possible in the STe in the same way that it is in the Amiga... or at least set up a 2-sample buffer in memory, set the DMA rate to maximum, and just write the same value into both samples at your preferred replay rate (25kHz or less of course)...

Of course, there's always the option of modding your STe so the DMA system is fed from the main system 8MHz clock instead (snip a leg, run a single jumper wire... so long as it doesn't mess up the signal buffering...), and then there *should* be a constant cycle count per sample - 160 for 50kHz stereo, 320 for 50k mono/25k stereo, 640 for 25k mono/12.5k stereo, 1280 for 12.5k mono/6.25k stereo, and 2560 for 6.25k mono.

Now, a question... has anyone actually straightened out what the mono line count and therefore the vsync rate actually is, and if it's constant across all machines? The few results from that timer routine suggests 501 lines, but in other literature (including even SM-series service manuals) there's been about as much suggestion for that as for 500 lines, and the surrounding H/Vsync periods and frequencies are little help because they work out to all kinds of numbers from about 499.5 to 503.5 lines, including a lot of fractional answers and the hugely helpful 500.5... and the varying system clocks mean that Hsync can be from about 35.743 to 35.955kHz, with 500 lines meaning Vsync runs from 71.49 to 71.91Hz, or 501 meaning 71.34 to 71.77Hz (the oft quoted "35.714kHz" requires a clock of *exactly* 32MHz / 8MHz or in fact a little below, and "71.43Hz" is as close to 500 lines as rounding will allow when dividing down from there). Neither of them produce a "71.2Hz" outcome, and only 500 lines can be realistically called "71.5Hz" at the original (8.0064 and 8.010613MHz) clocks. In contrast, if we want to keep the same general Vsync (and so keep any VBL-linked routine running at the same speed, and certainly within ~2 sec per hour drift) with a TT / MSTe / NTSC STe clock, then it needs to be 503 lines instead...

It'd be good to get a digital scope on an example of every differently clocked machine to see what's what, but more practically a simple program that used successive VBL interrupts to start and then stop an HBL-linked counter then print the result successively across the screen (so squeezing in 28 per line with 6x6 font with a 5-pixel space in between each count, about 2.6 lines per second, filling 66 lines of text in about 25 seconds before halting, having made and written 1848 samples, which should be pretty statistically valid, then inverting the screen using a big blocky font to display the average out to 3 decimal places just to be sure... and similar in med rez just with only 33 lines, to check the colour modes) would do the job. Dunno how you'd make an accurate cycles per second count without reference to any other internal clock, though; I thought everything including the keyboard controller RTC came off the same main clock at the end of the day...?

Similarly, as well as there being internal hardware solutions to open up the monochrome screen into overscan sizes, I've seen that some software tricks are at least able to open up the right and lower borders (top left is about as tight to the syncs as you can get already, at least without holding DE permanently high) ... do we know what actual active pixel/line counts those routines produce, or can it be easily calculated? My own figuring from the already determined and published cycles and lines that various things (which are either skippable to produce overscan, or are absolutely enforced by hardware) happen suggests a fairly impressive 736x466, which isn't far off the supposed hardware overscans of 752~768 x 480... does that seem realistic?

(It's all largely academic, and my own purposes for the information are, at least at the moment, purely thought exercises, but I feel it might be useful for further emulator tuning as well as improving how scalers and framegrabbers deal with mono screens, seeing as their structure is rather unlike that of any particular Japanese, Apple or IBM compatible mode...)

And I suppose there's no way of controlling that stuff from an external module... Genlock only affects the pixel clock and nothing else, right? And there's no clock *output* of any kind anywhere, even the cartridge port, just input? (What clock rate do you even need to make the STe sync to standard video, in that case? Presumably exactly 32MHz for PAL, 31.972028MHz for NTSC, and you just hope the attached system doesn't absolutely demand 262.5/312.5 line interlace and will still be happy with 263/313 line progressive?)

Pulling all that together, has anyone actually produced usable interlace from any ST? There are hypercolour type demos that claim to run "704x440i" resolution (medium rez with rapid palette swapping, temporal dithering, and supposed interlacing on top?), but I don't know if that's true or is actually 704x220 with interframe flipping to increase the perceived colours. I figure you can manage something like it on a fully analogue CRT monitor or projector by running 64 lines of the "wrong" frequency (50 or 60hz) right at the top of every other frame, gradually advancing (60hz in place of 50hz) or retarding (50 in place of 60) the vertical raster position (by 4 cycles out of 508/512 per line) in relation to where it would be on a normal single-frequency frame, with it being shifted just enough to get away with by the normal start line of a 60hz screen, but that's only theory and it'd probably fail even on a digitally auto-adjusting multisync CRT, let alone any LCD TV or (LCD/DMD/laser) projector. Of course you could try running 8 lines of 71hz (50hz; or 10 x 71 and 12 x 50 for 60hz) with a Hsync-killing trick every other (71hz) line and hoping the screen is responsive enough to actually sync at ~18kHz for a few lines and so be able to produce interlace across essentially the entire visible height (whether the reverse might also allow mono interlace, though...)

...bit of a drag-on post, but that's a bunch of things I've been trying to figure out independently for a while and hit a wall without being able to properly clarify everything... as well as a little extra info that I hope is useful to someone in some way ;)
Post Reply

Return to “Coding”