MOD playing on Atari and Amiga

[dml]

From what I remember, Copper is pretty easy. Just a chain of commands and some register offsets to be written etc. At the required time it just writes the appropriate register with whatever was specified as the source. IIRC one of the command types is a conditional 'wait', which achieves the scanline sync. I think it has access to the full register set so you can do weird things with it - but really only used it for colour changes at the time (long ago now).

Aside from low cost, the main benefit was that it happened at a cycle-specific time without any wobble. But that takes some of the fun out of it too

[Zamuel_a]

Aside from low cost, the main benefit was that it happened at a cycle-specific time without any wobble. But that takes some of the fun out of it too

Using all the Amiga special chips were good for games, but for creating demos I think the ST was much better. Seeing rasterbars in perfect sync on the Amiga wasn't so impressive

[Frank B]

I'm absloutely sure it was. I bought my A500 in 1991 and I had A500 board with 1MB Fat Agnus inside. A friend of me bought his A500 a copule of moths later in the same shop and had A500+ motherboard inside. He later upgraded the machine to a full A500+ just by adding four missing RAM chips and replaced ROM. Perhaps there was also some missing 74xx chip near the trapdoor connector needed for further 2MB upgrade.

Nice. The extra chipset display features couldn't be used without 2.x
Bit of an own goal there!

[Frank B]

From what I remember, Copper is pretty easy. Just a chain of commands and some register offsets to be written etc. At the required time it just writes the appropriate register with whatever was specified as the source. IIRC one of the command types is a conditional 'wait', which achieves the scanline sync. I think it has access to the full register set so you can do weird things with it - but really only used it for colour changes at the time (long ago now).

Aside from low cost, the main benefit was that it happened at a cycle-specific time without any wobble. But that takes some of the fun out of it too

From memory something like this...

If the first word is even it's a move instruction

$180, $fff ; load white value into colour register 0

If the first word is odd it's a wait instruction..

dc.b 20,10, $ff,$fe ; wait for vertical position 20 and horiz 10. (Mask off the comparator bits and combine with skip for loops)

[ctirad]

The extra display features were not much usable even with KS2+. The productivity mode required a special monitor, it was quite slow even in two color mode and totally ignored by most of the software. For most users the only benefit of the ECS chipset was 2MB of chip RAM.

[dml]

Frank, you have all those STs & Amigas kicking around and memorized HW registers - maybe its time to hit the old text editor again!

(subtle hint hint!)

[Frank B]

Frank, you have all those STs & Amigas kicking around and memorized HW registers - maybe its time to hit the old text editor again!

(subtle hint hint!)

I know but I've got nearly no bandwidth left If I fix my hatari config I can do some coding on long plane journeys

[Frank B]

The extra display features were not much usable even with KS2+. The productivity mode required a special monitor, it was quite slow even in two color mode and totally ignored by most of the software. For most users the only benefit of the ECS chipset was 2MB of chip RAM.

There are a couple of features useful for RGB displays. Border blank and SHIRES sprites/play fields.
The ECS blitter has a much larger max blit size too. The old one maxed out at 64 words a line IIRC.

[Frank B]

I'm sure genlock support was improved as well.

[qq1975b]

veeeeery interesting topic.

Maybe Amiga is very powerful with its dedicated chips but the Atari, in hands of a good programmer, isn't too far away. The lack of hardware made Atari programmers be more efficient and I read that program for Atari was easier than for Amiga...

I have always thought that they could have used another chipmusic for the STe like the YM2608 or install a 4 channel DAC. Cost was on the way, I suppose

[Frank B]

I like some of the sid voice stuff. Tao of cream has written some amazing music on the Yamaha. I prefer that to tracker music these days

[ctirad]

It's a pity the ST hasn't a custom soundchip (read: AMY) from the very beginning. Not sure if it was a just lack of the time or the developes (or managers) expected the YM will be here mainly for a system sounds and for true music there will be an external MIDI device.

[simonsunnyboy]

The latter is probably true. The ST was designed as a Mac competitior, not as a games machine.

[mc6809e]

Not quite sure why you think the Amiga can only play back at 28 khz, but it can actually play back at 56 khz (interleave mode) - higher than the STe and the Amiga's Paula sound system supports variable playback sample rate, the STe only supports a few fixed rates. This makes playing samples as instrument voices MUCH easier on the Amiga.

Yes. But only if you use a VGA style monitor. That's a bug not a feature btw!

Happy accident?

Anyway, it's a myth that 28K samples per second is the output limit under OCS. That's only the per voice DMA sample output limit. The CPU or copper can load the sample registers directly. Timing is simplified since Paula still controls the sample output rate, even well above 56K. No cycle counting is needed to get the correct output rate with the CPU. For the copper, its timing is easily determined. A simple way to use the copper would be to wait for the beginning of a scanline, write two samples with one word write, wait for the middle of the scanline, then write another two samples. That would give an output rate of over 60K samples per second. As to cost, an interrupt bit has to be reset to get paula to output the next sample, making for four moves total per scanline. Two wait instructions are also needed. That would take eight DMA cycles for the moves per voice, plus four DMA cycles for the waits. Very cheap. The problem with the copper method is that getting variable rates is difficult, though not impossible. And of course the CPU would probably have to take over some of the functions of the copper.

A hybrid arrangement is possible, too. Some channels can be DMA driven while others are CPU or copper driven. This allows DMA to be used for sounds that primarily contain lower frequencies while the CPU or copper can generate a bright cymbal crash at 60Ksps, for instance.

As far as interleaving is concerned, it actually is possible to interleave, with a certain amount of overlap, the samples of two different voices using DMA, by timing when output begins for each voice.

This is possible since each voice has its own counter that counts down between samples and resets when a new sample is loaded. By starting one voice and waiting half a sample period, the second voice can be started so that its output changes half way between the samples of the first voice. Paula will happily output a sample from one voice, wait half a period, and output a sample from the second voice, and repeat the process as long as desired, using DMA to fetch new samples.

But of course the true output rate per stereo channel has always been the sum of the output rates of the two voices that share the channel, whether they're intensionally interleaved or not. Playing one voice at 25K samples per second and another voice on the same stereo channel at 20K samples per second gives an output of 45K samples per second on that stereo channel, for example (technically slightly lower if two samples are output at precisely the same time).