Audio vs Amiga

All about ST/STE games

Moderators: simonsunnyboy, Mug UK, ICS, Doctor Bob Gordon, Moderator Team

User avatar
nativ
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4088
Joined: Mon Jul 30, 2007 10:26 am
Location: South West, UK

Re: Audio vs Amiga

Postby nativ » Tue Apr 24, 2012 8:22 pm

There is the Falcon BitMaster replayer that plays 4ch Mods on the DSP and uses something like 0% CPU time :)
Atari STFM 512 / STe 4MB / Mega ST+DSP / Falcon 4MB 16Mhz 68882 - DVD/CDRW/ZIP/DAT - FDI / Jaguar / Lynx 1&2 / 7800 / 2600 / XE 130+SD Card // Sega Dreamcast / Mega2+CD2 // Apple G4

http://soundcloud.com/nativ ~ http://soundcloud.com/nativ-1 ~ http://soundcloud.com/knot_music
http://soundcloud.com/push-sounds ~ http://soundcloud.com/push-records

mc6809e
Captain Atari
Captain Atari
Posts: 159
Joined: Sun Jan 29, 2012 10:22 pm

Re: Audio vs Amiga

Postby mc6809e » Wed Apr 25, 2012 4:53 am

Zamuel_a wrote:The Amiga runs at 7.09Mhz and the STE at 8, that's a 13% difference so if you make a mod player on atari that run's at 13% the speed left for other stuff would be the same on atari and the amiga. Maybe a mod player at 13% is abit optimistic, but let's say a 25khz player at 20% must be possible? (The 50khz lance tracker runs at 30%).
Also one thing I came up with once then I was thinking about mod playing is that isn't it much faster if the player runs 7bit samples instead of 8bit? You don't need to compare each sample you add if they are higher than 255. Instead you just add them and don't have to do anything else. Doing a 7 bit mod player at 25khz must be possible then at arount 15% and then you get the same time left as the amiga.


Oh, I see what you're wondering.

For relatively good accuracy, I think 50 KHz is a requirement, though, because while an individual voice on the Amiga will output samples at up to 28.8Ksps, the voices aren't necessarily outputting their samples at the same frequency or at the same phase with respect to one another. For the Amiga, the maximum output rate per stereo channel is the sum of the output frequencies of the two voices on that channel. For example, one waveform may output at 12Ksps while another outputs at 21Ksps. The total samples per second on the channel then is 33Ksps. This doesn't mean the Amiga can produce arbitrary waveforms at up to 57Ksps, though. The samples from each voice are overlapping so the effect you get is like interpolation with one bit of added precision.

But that aside, the big issue of course is using the CPU for software audio mixing. Now I once wrote in assembly language a software-only polyphonic music player for a machine with an MC6809 processor and 6-bit DAC. The basic idea is to use a pointer to each voice and its envelope and use fixed point arithmetic to adjust the pointer values for each new output. After the values are read, multiply the value in the envelope table with the current sample value to get the final value for that voice. Then use simple addition to combine the voices that share a channel and write the result to the buffer for the channel.

The same technique can be used with the MC68000.

But the trouble comes down to handling all the multiplies for the envelopes. Granted, the envelope values are only 6-bit. This means the multiplies won't take a full 70 cycles to execute, but they'll still take at least 40. That means 160 cycles for four voices, minimum. Even at 25Ksps, this is going to require at least 7 million CPU cycles per second. 88% of the CPU time is consumed just handling the envelopes.

The solution of course is to precompute each waveform for each of the 64 volume levels that make up each envelope, thus avoiding the expensive multiplies. With this technique, I'm guessing at least 60 cycles are required per stereo pair of outputs. Even at 25Ksps, this takes about 19% of CPU. There might be a way to get the cycle count down lower. At a minimum, though, the CPU is going to have to read four values, create two sums, write the results to two buffers and adjust six pointers per sample. And that doesn't include the restore/saves that must be done to get the values into the registers that are used to adjust the waveform pointers for each chunk of samples. 60 cycles might be hard to beat. In fact, 60 cycles is probably optimistic. I remember reading somewhere in another thread that one of the better mod players used 128 cycles per sample pair in the best case. That consumes 40% of the CPU at 25Ksps.

And then there's the memory cost. A waveform on the Amiga can be 128K byte long. It would take 8 megabytes to store all 64 volume levels. Some mod files are simply going to be unplayable without a lot of memory.

I just don't think the 13% difference in speed is going to be enough to make up for the lack of hardware based audio mixing.

Look at it this way: at 25Ksps per channel, the CPU needs to come up with 50Ksps. There are 8000000 CPU cycles per second meaning the CPU has at most 160 cycles available for each sample. It takes 4 cycles just to touch memory so you have at most 40 memory accesses total for each sample. And some of those accesses are needed just to fetch instructions before you can even touch the buffers!

All that assumes you want stereo output, of course. If you're willing to settle for mono output at 25Ksps, then you can save a few cycles by avoiding the need to generate a second sample stream. The savings aren't great, but with that you just might be able to have a mod player that consumes only 15% CPU. You still need to come up with large amounts of memory for all the precomputations.

Zamuel_a
Atari God
Atari God
Posts: 1223
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: Audio vs Amiga

Postby Zamuel_a » Wed Apr 25, 2012 9:55 pm

No I guess it's hard to beat the Amigas hardware, but it sure helps that the Atari is faster :D
Anyway a regular game that use mod playing and hardware scroller, blitter and so on should be possible to convert to an STE without loosing anything I think. A simple platform game (giana sisters or something) wouldn't take 100% CPU power on the Amiga so convert it to an STE should be as fast.

What about mod playing on a MEGA STE? That one must be able to compete with an Amiga if you calculate the time left after a mod are played.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
christos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2367
Joined: Tue Apr 13, 2004 8:24 pm
Location: Greece
Contact:

Re: Audio vs Amiga

Postby christos » Thu Apr 26, 2012 2:33 am

I think amiga beats the ST when it comes to machine produced audio but when you achieve a certain level of excellence you can get some wonderful music from the ST(e) that even beats the amiga. From my part I think an STE game/demo should have a YM+DMA soundtrack, something like blubber songs or what DMA=Sc does (can't stop listening to travellers) and I stop here because it would become a list ;) . That I think gives a special character that we would be wrong to miss.
Felix qui potuit rerum cognoscere causas.
My Atari blog

STOT Email address: stot(NoSPAM)atari(DOT)org

Zamuel_a
Atari God
Atari God
Posts: 1223
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: Audio vs Amiga

Postby Zamuel_a » Thu Apr 26, 2012 7:50 am

One thing that isn't so easy to do on the Amiga is to play a mod and have soundeffects at the same time. Often it's either music or effects or like it was in one game I tried, the music pause when a effect is playing. You would need a 6ch mod player to handle music and effects and that will ofcourse take cpu time. On an STE it would be possible to play YM music with DMA effects or DMA music with YM effects.

Shouldn't it be possible to make a 25khz mod player that runs at abount 20% cpu time on an STE? The Lancetracker runns at 30% with 50khz playback, so running it at half speed must make it abit faster :wink:

There is another way to add two samples together instead of add, check overflow and so on... If you have two 25khz samples and run the player at 50khz, when you can alternate so that every odd bytes are from one sample and every even bytes from the other one. You get 50khz/2 as an output and it will be 8 bit resolution. I have tried to mix two samples like this and it works. It gives the same hearable result as combining them the "right way". I guess you can increase the resolution two from 8 bit to 16 maybe by combining two samples of the right values. It's the same thing as alternating between two images to simulate more colors.





Back in the 80ths an Amiga was probibly better than an Atari if you want to play games and don't care so much about anything else, but today I think you get more fun on an Atari if you like to program. I prefer to see a good game with nice scrolling and everything on an Atari compared to see it on an Amiga there it's "no big deal".
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
ljbk
Atari Super Hero
Atari Super Hero
Posts: 514
Joined: Thu Feb 19, 2004 4:37 pm
Location: Estoril, Portugal

Re: Audio vs Amiga

Postby ljbk » Mon Jul 16, 2012 7:58 pm

Hi !

The tricks used by "really" fast MOD players on the ST require at least a replay frequency of 31.x KHz so that the highest speed at which the sample data is read is 1.00 bytes . If you have an average speed of 1.01 bytes per access at a certain pitch then a byte will have to be skipped at a certain time and so you need a different addressing scheme when reading the memory which turns everything slower ...
So as i said, a "Lance" player at 25 KHz using just a bit of processor time is NOT possible !
Besides, in order to achieve the 50 KHz, there are a few "optimizations" in the "Lance" player with the volume control for example that you might not ear but that are real: microwire volume (with less resolution) instead of volume table or hardware volume on Amiga.
Tha Amiga was built to play MODs and as i have already written (viewtopic.php?f=16&t=17957&p=187834#p187834), the ST and especially the STE can only try to get close to it but consumming a lot of CPU time.


Bye,
Paulo.

Zamuel_a
Atari God
Atari God
Posts: 1223
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: Audio vs Amiga

Postby Zamuel_a » Tue Jul 17, 2012 6:56 pm

So a 25khz player wouldn't be faster than the 50khz player? I know it would take alot of processor power, but if it was possible to get it to somethere close to 20% it would be close to the same as the Amiga if you count that the Amiga runs at a lower frequenzy. Ofcourse the MOD PLAYER would be faster on the Amiga, but the amount of processor time left for other things might be the same.

I don't think it's such a problem that playing MODs takes time on Atari, the problem is that there aren't many games for the STE. A simple platform game doesn't need to much processor power anyway if you use the hardware scroller and you would have time to play MODs. Giana sisters for example must be possible to make 100% equal to the Amiga version on an STE. The graphic isn't that advanced either.
On the Atari you could always use the YM chip for sound effects. On Amiga you usually have either sound effects or music.

One interessting way to play MODs (I think) would be to convert the samples to 7 bits instead of 8. Two 7 bit numbers added together is at most an 8 bit number so you don't have to check for overflow when you mix the samples for each channel. That must decrease the processor time alot.
Another thing I tried once (but not on an Atari) was so mix two samples by combine them so that every even bytes were from one sample and the odd ones from the other. The ear can't hear that they are mixed like that and it sounds just as a normal mix. You would have to play the sample at 50khz but the mixed output would be 25khz. I don't know if it would be faster than the 7 bit version but could be.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
ljbk
Atari Super Hero
Atari Super Hero
Posts: 514
Joined: Thu Feb 19, 2004 4:37 pm
Location: Estoril, Portugal

Re: Audio vs Amiga

Postby ljbk » Tue Jul 17, 2012 7:19 pm

Hi !

The 7 sample bit trick is used by probably all fast MOD players on the ST(E) as is it by the "Lance" player.
Even 6 bit samples are used for some 8 voices mixing routines.
If you check my program, Hextracker(viewtopic.php?f=28&t=20760), even if it was not designed for STE, you will see that to play a dificult MOD like the Agony Intro at 25 KHz in Stereo (STE mode) with 7 bit samples you will need 54% of the CPU.
There is no cheating at all except the 7 bit samples and you can force the player to use 8 bit samples but you will need more CPU power.
If you play it in Mono, you will need less CPU power.
If you play it at 50 KHz, you will need 84% of the CPU which is not two times 54%: the routines to read the samples become more efective with high reply frequency because of relatively slower sample reading.
This is also the case for the "Lance" player together with a lot of optimizations like the ones i refered before: only in this special case you get a low CPU usage at a high replay frequency which MUST be higher than 31.x KHz.


Bye,
Paulo.

Zamuel_a
Atari God
Atari God
Posts: 1223
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: Audio vs Amiga

Postby Zamuel_a » Tue Jul 17, 2012 7:26 pm

hehe ok, so my "invention" wasn't so new then, hehe. Well I guess all smart ways are already thought out already.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
ljbk
Atari Super Hero
Atari Super Hero
Posts: 514
Joined: Thu Feb 19, 2004 4:37 pm
Location: Estoril, Portugal

Re: Audio vs Amiga

Postby ljbk » Tue Jul 17, 2012 7:40 pm

Zamuel_a wrote:hehe ok, so my "invention" wasn't so new then, hehe. Well I guess all smart ways are already thought out already.


Other performance values:

12.5 KHz Stereo: around 33 % CPU needed
16.7 KHz Stereo: around 44 % CPU needed

As you see the higher the replay frequency, the best performance the routine returns.

Enjoy,
Paulo.

Zamuel_a
Atari God
Atari God
Posts: 1223
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: Audio vs Amiga

Postby Zamuel_a » Tue Jul 17, 2012 8:21 pm

But this is an ST player? Not STE?
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
ljbk
Atari Super Hero
Atari Super Hero
Posts: 514
Joined: Thu Feb 19, 2004 4:37 pm
Location: Estoril, Portugal

Re: Audio vs Amiga

Postby ljbk » Tue Jul 17, 2012 10:01 pm

Zamuel_a wrote:But this is an ST player? Not STE?


The core of the player was designed in the 90s on STF.
But the performance i refer is on STE using the STE DMA in Stereo.
Using the program you can select the "output" type you want. The default output on STE will be STE DMA in Stereo.
Playing the Agony Intro at 50 KHz on STF is NOT possible. With that MOD you can only achieve 47 KHz on STF with the YM 2149 output in Mono using nearly 100% CPU: one YM update every 172/168 CPU cycles at 8 MHz. That is the maximum frequency possible on STF to play any 4 voices MOD that does not use BPM.
But more than 95% of the MODs can be played at 50 KHz on STF using nearly all CPU power with YM50K (included in the Hextracker package) launched in 2005.
Anyway, both in STF and STE, it is not only CPU power that is needed. You also need a big amount of memory for tables (also for "Lance" player).
This explains why you only had game intros with MODs on ST because the game had to run with 512KB.
An intro example is SOTB 2.

1MB is almost mandatory for a STF/STE game with MOD music during game and you will have maximum 60% or 70% CPU free.

Bye,
Paulo.

Zamuel_a
Atari God
Atari God
Posts: 1223
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: Audio vs Amiga

Postby Zamuel_a » Tue Jul 17, 2012 10:33 pm

16.7 KHz Stereo: around 44 % CPU needed


Hmm ok, but if it's on an STE how can 16.7khz even be played and why 44% since 50khz takes 30% with the lance tracker. Am I missing something here?
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
ljbk
Atari Super Hero
Atari Super Hero
Posts: 514
Joined: Thu Feb 19, 2004 4:37 pm
Location: Estoril, Portugal

Re: Audio vs Amiga

Postby ljbk » Wed Jul 18, 2012 6:26 am

Zamuel_a wrote:
16.7 KHz Stereo: around 44 % CPU needed


Hmm ok, but if it's on an STE how can 16.7khz even be played and why 44% since 50khz takes 30% with the lance tracker. Am I missing something here?


You can have 16.7 KHz output with STE by selecting 50 KHz DMA, doing a 16.7 KHz mixing and padding the DMA buffer with the same byte 3 times: 3 x 16.7 = 50.1 ...
This way, you can also have other mixing frequencies on STE but that 16.7 one is the most interesting together with the 10 KHz one (5 bytes padding).

The higher the replay (mixing) frequency is, the higher are the memory needs.
Besides, with Hextracker you can have any number of voices between 1 and 16 allowing to control the CPU and memory needs (why not a 3 voices MOD ? ).
Such program "should" also be possible on Amiga but you will get also high CPU requirements in case the number of selected voices is higher than 4 if you want to keep all features like volume control.
As far as i know, Oktalyzer on Amiga, with 8 voices, used 7 bit samples and volume control was applied to two voices at the same time or not possible ...


Bye,
Paulo.

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2163
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Audio vs Amiga

Postby calimero » Wed Jul 18, 2012 7:14 am

Zamuel_a wrote:One thing that isn't so easy to do on the Amiga is to play a mod and have soundeffects at the same time. Often it's either music or effects or like it was in one game I tried, the music pause when a effect is playing. You would need a 6ch mod player to handle music and effects and that will ofcourse take cpu time. On an STE it would be possible to play YM music with DMA effects or DMA music with YM effects.

Pinball Obsession on STe use 6 channels: 4 for mod play and 2 for ingame effects. Guess it is same on Amiga...
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

Zamuel_a
Atari God
Atari God
Posts: 1223
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: Audio vs Amiga

Postby Zamuel_a » Wed Jul 18, 2012 8:03 am

Pinball Obsession on STe use 6 channels: 4 for mod play and 2 for ingame effects. Guess it is same on Amiga...


Yes but the UDS guys were rather skilled to :wink: The easy way was to just have 4 voices and skip effects. It's to bad that most games were just made to be done quickly and to earn money.

Anyway, would it be possible to make a MOD player on an STE that is faster than 30% processor time when it's playing at 25khz? If it would be possible to get it down to 15% it would leave you with the same amount of processor time left as on an Amiga :wink:
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

mc6809e
Captain Atari
Captain Atari
Posts: 159
Joined: Sun Jan 29, 2012 10:22 pm

Re: Audio vs Amiga

Postby mc6809e » Wed Jul 18, 2012 2:16 pm

Zamuel_a wrote:Anyway, would it be possible to make a MOD player on an STE that is faster than 30% processor time when it's playing at 25khz? If it would be possible to get it down to 15% it would leave you with the same amount of processor time left as on an Amiga :wink:


There still may be room for improvement, but I doubt it's possible to cut the CPU time in half. Quality programmers have been working on this for years. It's unlikely they've missed an opportunity to cut the required CPU time by 50%.

Besides, you'd have to do even better than that. The clock rate difference between the Amiga and ST is 12.8% for PAL machines (11.2% between NTSC machines). And even then, the Amiga allows the CPU access to odd memory cycles when they're available and requested while the ST forces the CPU to wait. This makes a small difference, but it further erodes the clock rate advantage of the Atari ST (depending on the code sequence). There are even (admittedly ridiculous)* codes for which the Amiga's CPU beats the ST's CPU despite the clock rate difference because the ST forces the CPU to wait more often. In practice, the speed difference between the two machines is about 10% for most codes. For code heavy with MULs and DIVs (3d vector graphics calculations, for example) the difference is closer to the theoretical 12.8%.

*Admittedly ridiculous would be something like an unrolled loop of 256 CLR.L D0 instructions. You'd never do this in real code.

User avatar
Cyprian
Atari God
Atari God
Posts: 1488
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Audio vs Amiga

Postby Cyprian » Wed Jul 18, 2012 4:10 pm

mc6809e wrote:And even then, the Amiga allows the CPU access to odd memory cycles when they're available and requested while the ST forces the CPU to wait.


Amiga Hardware, in Blitter section states that 68000 instruction are always rounded to 4 (even cycles) by Amiga hardware:

Some 68000 instructions do not match perfectly with the allocation of
even cycles and cause cycles to be missed. If cycles are missed, the
68000 must wait until its next available memory slot before continuing.
However, most instructions do not cause cycles to be missed, so the 68000
runs at full speed most of the time if there is no blitter DMA
interference.


Have you checked that? If yes, under what conditions 68000 is not aligned with even cycles? I'd like to check it in WinUAE (via EmuTOS, thx Vincent :) )
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

User avatar
Frank B
Atari Super Hero
Atari Super Hero
Posts: 962
Joined: Wed Jan 04, 2006 1:28 am
Location: Boston

Re: Audio vs Amiga

Postby Frank B » Wed Jul 18, 2012 5:53 pm

Cyprian wrote:
mc6809e wrote:And even then, the Amiga allows the CPU access to odd memory cycles when they're available and requested while the ST forces the CPU to wait.


Amiga Hardware, in Blitter section states that 68000 instruction are always rounded to 4 (even cycles) by Amiga hardware:

Some 68000 instructions do not match perfectly with the allocation of
even cycles and cause cycles to be missed. If cycles are missed, the
68000 must wait until its next available memory slot before continuing.
However, most instructions do not cause cycles to be missed, so the 68000
runs at full speed most of the time if there is no blitter DMA
interference.


Have you checked that? If yes, under what conditions 68000 is not aligned with even cycles? I'd like to check it in WinUAE (via EmuTOS, thx Vincent :) )


Raster time it with zero planes active running code from chip memory. You might be surprised ;)
I checked with < 4 planes and code was faster running from fast RAM. I went out of my way to test branches and shifts.
I'll double check when I'm home as it's been a few years. Need to set up the 500 plus too.

Zamuel_a
Atari God
Atari God
Posts: 1223
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: Audio vs Amiga

Postby Zamuel_a » Wed Jul 18, 2012 5:58 pm

Well, even if you couldn't get a MOD player to run at 15%, maybe 20-25 anyway and most games on the Amiga doesn't need 100% cpu time anyway so I think there could have been alot of games that would be possible to make the same on an STE as on the Amiga.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

mc6809e
Captain Atari
Captain Atari
Posts: 159
Joined: Sun Jan 29, 2012 10:22 pm

Re: Audio vs Amiga

Postby mc6809e » Wed Jul 18, 2012 6:37 pm

Cyprian wrote:
mc6809e wrote:And even then, the Amiga allows the CPU access to odd memory cycles when they're available and requested while the ST forces the CPU to wait.


Amiga Hardware, in Blitter section states that 68000 instruction are always rounded to 4 (even cycles) by Amiga hardware:

Some 68000 instructions do not match perfectly with the allocation of
even cycles and cause cycles to be missed. If cycles are missed, the
68000 must wait until its next available memory slot before continuing.
However, most instructions do not cause cycles to be missed, so the 68000
runs at full speed most of the time if there is no blitter DMA
interference.


Have you checked that? If yes, under what conditions 68000 is not aligned with even cycles? I'd like to check it in WinUAE (via EmuTOS, thx Vincent :) )


The HRM is over-simplifying.

When the Amiga was released, there was some confusion about the extent to which DMA would slowdown the CPU. Critics were claiming that the CPU was only running at half speed during normal 16 color 4-bitplane DMA. The HRM simplifies the description of what happens to allay fears about a slowdown by illustrating the interleaving of bitplane DMA with CPU accesses. The Atari ST does the same sort of interleaving.

It's not a terrible over-simplification. Most of the time the CPU appears to access even cycles while bitplane/sprite/audio/disk DMA gets the odd cycles.

But the HRM still gives several clues about the true details. It mentions that there are 227.5 memory access cycles per scan line NTSC (it alternates between 227 and 228) with 226 available for CPU/DMA. For the 227 case (PAL is always 227), that extra memory access cycle is 2 CPU clocks. How can the CPU continue to access even memory cycles only when there are 2 extra CPU clocks in a line? The answer is: it can't. If the CPU finishes accessing on memory cycle #224 near the end of a scanline, for example, and attempts to access the next even memory cycle 4 CPU cycles later it will run into memory refresh DMA and the hardware will add 2 wait states forcing the CPU to begin accessing memory on what looks like an odd cycles on the next scan line.

And take look a close look at the DMA Time Slot Allocation chart given in the HRM. The un-shaded areas are described as being available to the blitter/CPU. Notice the difference between the shaded slots for refresh and other slots? The refresh slots can't be disabled so they are shown as vertical bars running top to bottom. But the other slots for other DMA are not similarly illustrated and show un-shaded areas above and below the shaded block. Audio/sprite/bitplane DMA can be turned off and those slots can become available to the blitter/CPU.

And because the chart groups the blitter/CPU memory slot accesses, and we know from the HRM that the blitter can access any available slot, we know that the CPU also has that ability (though it rarely takes advantage of it). For proof that the blitter can access on any available cycle, look at the formula for blitter. An A->D copy takes 4 CPU cycles per word. That can only happen if every slot is available.

But the real proof is to just try running code. Turn off all DMA except bitplane DMA and try doing a large blitter memory clear with just the D channel and blitter nasty turned on. This should consume every "even" cycle and block the CPU completely. You'll discover, though, the the CPU can still execute instructions. An old trick is to use these instructions to help the blitter clear memory giving a boost in speed.

Another test is to execute a loop containing a run of (512, for instance) CLR.L D0 instructions. If the CPU can only access memory on "even" cycles, then the average number of CPU cycles per CLR.L D0 instruction will be slightly more than 8 cycles instead of the 6 mentioned in the Motorola documentation. You'll discover, though, that the average cycles per instruction is about 7.5 cycles/CLR.L D0 for a 320x256 4 bitplane screen. If you turn off all DMA, the average is less than 7 cycles/CLR.L D0.

User avatar
Frank B
Atari Super Hero
Atari Super Hero
Posts: 962
Joined: Wed Jan 04, 2006 1:28 am
Location: Boston

Re: Audio vs Amiga

Postby Frank B » Wed Jul 18, 2012 7:07 pm

mc6809e wrote:
Another test is to execute a loop containing a run of (512, for instance) CLR.L D0 instructions. If the CPU can only access memory on "even" cycles, then the average number of CPU cycles per CLR.L D0 instruction will be slightly more than 8 cycles instead of the 6 mentioned in the Motorola documentation. You'll discover, though, that the average cycles per instruction is about 7.5 cycles/CLR.L D0 for a 320x256 4 bitplane screen. If you turn off all DMA, the average is less than 7 cycles/CLR.L D0.


Just do that with a raster test and change the number of planes every few seconds and see if it changes when < 4 compared to running the same code from fast RAM. It's trivial to do. I've done it and I'm sure the speed doesn't remain constant for less than 4 planes.
Anyone got an a500 handy?

mc6809e
Captain Atari
Captain Atari
Posts: 159
Joined: Sun Jan 29, 2012 10:22 pm

Re: Audio vs Amiga

Postby mc6809e » Wed Jul 18, 2012 9:26 pm

Frank B wrote:
mc6809e wrote:
Another test is to execute a loop containing a run of (512, for instance) CLR.L D0 instructions. If the CPU can only access memory on "even" cycles, then the average number of CPU cycles per CLR.L D0 instruction will be slightly more than 8 cycles instead of the 6 mentioned in the Motorola documentation. You'll discover, though, that the average cycles per instruction is about 7.5 cycles/CLR.L D0 for a 320x256 4 bitplane screen. If you turn off all DMA, the average is less than 7 cycles/CLR.L D0.


Just do that with a raster test and change the number of planes every few seconds and see if it changes when < 4 compared to running the same code from fast RAM. It's trivial to do. I've done it and I'm sure the speed doesn't remain constant for less than 4 planes.


And you don't even need fast ram, really. Just turn all DMA off to establish a baseline, then gradually add planes.

The code sequence is important, though. A bunch of NOPs won't see any change for 4 or fewer planes since a NOP is a "typical" instruction. The difference between zero planes and one plane should be noticeable with CLR.L D0 or any similar instruction that takes 6/10/14 etc CPU cycles.

User avatar
ljbk
Atari Super Hero
Atari Super Hero
Posts: 514
Joined: Thu Feb 19, 2004 4:37 pm
Location: Estoril, Portugal

Re: Audio vs Amiga

Postby ljbk » Wed Jul 18, 2012 10:51 pm

Zamuel_a wrote:Well, even if you couldn't get a MOD player to run at 15%, maybe 20-25 anyway and most games on the Amiga doesn't need 100% cpu time anyway so I think there could have been alot of games that would be possible to make the same on an STE as on the Amiga.


Here is the read-me file from "The Player", downloaded from DHS site, that uses Lances routines:
"
________ ___ _________ ___ ___ _____ _______
| | | / \ | | : | | | \
| __ | | : | | | : . : | - | __ |
| | | | . | __ | | . . | |_ | _
| __/ | | : | | | |
| | | |____ . \__ __/ | __| | |\
| | | | . | |__ |
| . | | | | | : | | \
|___: |_________| |___| |_ |___| |________ |___| |___|


11 000000
111 000 000
1111 000 000
111 000 000
111 000 000
111 000 000
111 ... 0000000000
11111 ... 00000000


--- Features --------------------------------------------------------------


o Supports 4, 6 or 8 channels of MODs, with basespeed 16kHz (most modules
have has basespeed).

o 50 kHz 4 channels full volumecontrol and frequensecontrol, taking max 40%
of CPUtime on a ordinary STe!

o 50 kHz 8 channels full volumecontrol and frequensecontrol, taking max 90%
of CPUtime on a ordinary STe!

o Runs both as an ACC and APP/PRG!

o Supports both VA_START and modulename on commandline!

o Max 20 modules loaded at once!

o Saves windowpositions and path/filename when saving the options!

o Swedish and English RSC-file (please rename PLAYERSV.RSC or PLAYEREN.RSC
to PLAYER.RSC)!

o Tested on TOS 1.62, TOS 2.06, MTOS (MiNT 1.12) and Mag!X 2.01!


--- Contact - adresses ----------------------------------------------------


Shell and feeder written by Christian Dahl, please write to me about
buggs, problems or of pure gratitude!

Christian Dahl
Fr”dingsh”jd 21
654 73 Karlstad
Sweden
+(46)-54-839483

di3dah@f_utbserv.adbutb.hks.se (InterNet)
cd@p4.tnogobl.ct.se (InterNet)
Christian Dahl 2:203/611.4 (FidoNet)
Christian Dahl 90:1103/104.0 (NeST)
Christian Dahl 7:108/102.0 (FujiNet)


UMP-modules written by M†rten R†nge!

M†rten R†nge
Mejerigatan 2/232
412 76 G™TEBORG
SVERIGE

d3marten@dtek.chalmers.se (InterNet)


--- End of File -----------------------------------------------------------
"

As you can read, the routines can take up to 40% CPU for STE. And as i suspected that is the case for the MOD i refered previously: the Agony Intro.

Just try it and also listen to the sound for this and other MODs and compare carefully the sound output results with a replay using Octalyser STE that is probably the best STE player/tracker.
Too much cheating can sometimes lead to unexpected results.
Speed is not the only goal. Accurracy is also important.
You do not have the required permissions to view the files attached to this post.

User avatar
Frank B
Atari Super Hero
Atari Super Hero
Posts: 962
Joined: Wed Jan 04, 2006 1:28 am
Location: Boston

Re: Audio vs Amiga

Postby Frank B » Thu Jul 19, 2012 5:22 am

mc6809e wrote:
Frank B wrote:
mc6809e wrote:
Another test is to execute a loop containing a run of (512, for instance) CLR.L D0 instructions. If the CPU can only access memory on "even" cycles, then the average number of CPU cycles per CLR.L D0 instruction will be slightly more than 8 cycles instead of the 6 mentioned in the Motorola documentation. You'll discover, though, that the average cycles per instruction is about 7.5 cycles/CLR.L D0 for a 320x256 4 bitplane screen. If you turn off all DMA, the average is less than 7 cycles/CLR.L D0.


Just do that with a raster test and change the number of planes every few seconds and see if it changes when < 4 compared to running the same code from fast RAM. It's trivial to do. I've done it and I'm sure the speed doesn't remain constant for less than 4 planes.


And you don't even need fast ram, really. Just turn all DMA off to establish a baseline, then gradually add planes.

The code sequence is important, though. A bunch of NOPs won't see any change for 4 or fewer planes since a NOP is a "typical" instruction. The difference between zero planes and one plane should be noticeable with CLR.L D0 or any similar instruction that takes 6/10/14 etc CPU cycles.


Of course. The idea is to test with instructions which don't take a multiple of 4 cycles.


Social Media

     

Return to “Games - General”

Who is online

Users browsing this forum: No registered users and 1 guest