Both systems are too amazing for words.

Streaming PCM straight off the harddrive using the Atari-specific DMA, actually ;)

@@gwenynorisu6883 And the previously mentioned Yamaha 3-voice beeper mixed in!

+blinddarm You have to run it from SD-card, translated drives will be too slow. And the SD card need HDDRIVER to be configured with "Fast ACSI" option enabled.

I have CosmosEx and PP driver on my SD card - no problems on my STe. Version 1.2 removed the random noise pixels in animations (it was OK under emulator, but not on real hardware).

Aside from the fact that you are so pitiful for mocking a system from 25 years ago, the STE was capable of displaying 512 or 4096 colors on screen at a time through programming tricks just like that other machine, what was it? Oh ya, Amiga. Their demo scene did the same thing. So, grow up, move on. Both machines are outdated. The ST massively outsold the Amiga in the beginning. The Amiga massively outsold the ST in the late 80's. The STE matched the Amiga several years too late. Wow, that wasn't so hard to admit. I guess I grew up.

@@bljakkl I don't think his comment was intended to mock the system, rather the opposite.

Why do you assume mockery? Sounds like it's celebrating the clever hacks.

@@johanbergman311 You are right :) I am a old Atari ST demomaker so i know we can break the boundaries. And that was what was exciting! :)

+Carlos Del Alamo (Estrayk) They synced CPU and blitter with GFX chip (Shifter) so they could gradually swap that 16-color palette several times at each scanline at exact points of screen. This way they can use a new color every few pixels (but lose one at the same time). And the process started over at next line. This combined with clever dithering/blinking of similar colors on two 'half-screens' expanded the color capabilities to something around 18-bit RGB (instead of 12-bit indexed), at a cost of a huge CPU load. At this point it is even more impressive, that they can actually do other stuff (3d, bump maps, plasmas ect.) while using this mode.

Przemek Kobel I understand, like amiga copper but without it. how many raster-time cost this process in each frame?

+Carlos Del Alamo (Estrayk) Without overscan you had tiny amount of free time at the end of each scanline (this depended on how wide was your image), there was some potential before first line of framebuffer (initial routines of this kind just tried to figure out where we are on top border, and then did series of NOP commands before actual work), and the CPU was all yours after the image (and before next vsync). So without optimisations CPU load was 70% or so.

+Przemek Kobel thank you very much for your information

+Carlos Del Alamo (Estrayk) The fullscreen animations (intro+endtro) and the still pictures are using 274 scanlines out of 313 available (88% CPU). The consumption of CPU is a combination of changing the colour palette and opening the sideborders. The code is CPU-based and does not use blitter. The pictures and animations are 400*273 pixels in size and uses 48 unique colours per scanline. The still pictures adds interlace to expand the perceived colour palette and on-screen colours. Of course that looks a lot better on a real Atari than emulator or video. The first effect (@ 00:48) is using a "copper chunky" with the blitter (no copper available). It's using about 70% CPU on the visible scanlines and no CPU where there is no effect. The actual code to make the effect runs both on free scanlines and in the blitter-chunky scanlines. Please note that this needs to be cycle accurate as the CPU and blitter does not run in parallell. We're interleaving even/odd pixels on two scanlines, giving a psuedo 4*2 look. Britelite did this on Amiga first. The chunky resolution is 80*70 (displayed size 320*140) with effect at 50 Hz. The bumpmap effect (@ 02:04) is again using the blitter to create a "copper chunky" field. But it's using a special blitter mode with an internal mask memory of the blitter, the colours are blitted twice as fast, giving half as large chunky blocks - there are tradeoffs with the technique, the internal mask memory is only 32 bytes large. It's also using CPU movem.l to complement the blitter. Here there are no (or very few) cycles left for each scanline where the chunky graphics is shown. So the actual effect code is only running on the lines above and under the chunky display. The surrounding graphics is only one colour over the chunky area, the remaining colours are used up for the chunky field. It is also interleaving even/odd pixels on two scanlines giving a psuedo 2*2 field. The chunky resolution is 84*86 (displayed size 168*172) with effect running at 25 Hz. The plasma (@ 03:52) is a standard blitter plasma with different colour data for odd/even lines. Using up 274 out of 313 scanlines cpu, leaving only 12% cpu for calculations (sin, jumplist creation). Displayed size is 416*273. Needless to say, 50 Hz. The final screen (@ 04:37) is the same blitter code as the first screen. The screen runs at a slower framerate due to more complicated effect with 128 colour alpha blending. The remaining effects not described are video chip tricks and and doesn't use blitter or CPU in a large way except for border removal and colour updates. Worth to know is that the Atari ST/STe cannot do overscan in hardware. Especially the sideborders is a bitch. For each scanline you need to: * Set the video chip to 71 Hz for a few cycles, then back to 50 Hz (left border) * Set the video chip to 60 Hz for a few cycles, then back to 50 Hz (right border) These frequency switches has to be done on a precise cycle, every scanline where the borders are killed. So all other code needs to be cycle counted to fit between the frequency changes. Hope it helps understanding the demo and effort to create these kind of Atari demos a little bit better :-)