frank1974

Not in a single DMA driven operation. AUDxLEN is limited to 65535 words (128k max per sample) before you need to reload them.

Not correct. Only at 2.06 there is support for higher CPU versions. Although 68010 and 68012 are upward compatible, there is one case where code will fail: move sr to somewhere instruction. It is not privileged on 68000 but is privileged on higher ones. So, if SW performs such instruction in user mode on 68010 it will cause bombs. In TOS 2.06 and higher ones there is special code to override mentioned case, to make older SW runnable. Move sr.ea is a user mode problem not a supervisor one If the OS uses this instruction it won't matter. There might not be a handler in the OS to catch user mode progs using it but the OS should run itself ok on > 68000. Would be an interesting experiment. Next time I'm near my Ste I'll give it a go.

You can also see the internal code word for the blitter in the source Atari called it the BLASTER. I think it's reasonably elegant though rather than clumsy or random Frank

1.4/1.6 is supposed to be 68k CPU independent. Never tried it though.

For the blitter vs 030 try an unaligned blit and compare the TT speed with the STe blitter. You might be surprised at the results Remember the ST desktop and most apps cheat and align graphical elements on 8 pixel boundaries for performance reasons. The 010 works fine on TOS 2.x on an STe. I used it for some time but it did cause problems with hd driver necessitating a switch back to the original. btw you do know the Amiga 1000/500 isn't 100% compatible with the *vanilla* 68k right? Try executing TAS from chip RAM and see what happens. Kaboom. It's documented in the hardware reference manual. That instruction would have been handy for thread safety on the Amiga. The biggest mistake Atari made with the TT was not including the blitter IMHO. I agree with you 100% there. A 16 or 32 mhz version would have been nice. Especially if it allowed 100% concurrency with the CPU executing code from fast RAM like the Amiga. The ST blitter has an undeserved bad rep but it's actually quite nice. You can hflip bitmaps with it in four passes or perform magnification. I posted some hardware banging C code demonstrating it on atari forum some time ago. It's a superset of bitblit. Ie it has halftone support on chip and an indirect addressing mode for "tricks" like the above. There are many things said about the Atari blitter that are wrong. Ie people claim it can't do logical operations, it can't shift (no barrel shifter) etc, no bit boundary support. Check the manual out It's different from the Amiga one but Atari didn't screw it up. There are some nice features on the TT. It has a hardware flood fill video mode for instance. The Amiga/ST/Falcon/Archimedes etc are all nice. I'm a big fan. Frank

Nah I'd rather keep them separate. Both truly awesome computers with great character!

Heh. I didn't think the AY was used till the +2 in 87. Looks like you're right. I forgot about the Sinclair model Plenty of custom silicon in the ST though. It sure as heck wasn't built from off the shelf parts.

Yet the spectrum didn't use that soundchip till about 3 years later. That's another thing people keep repeating. The ST didn't have a spectrum soundchip. It was the other way around. Technically they're not the same sound chip either. The Spectrum used the AY variant. The off the shelf nonsense Amiga owners keep saying is getting tiresome too.

The way I heard it, the ST had to be made quickly using all off the shelf parts. No custom IC's were allowed in order to speed development and help contain costs. JT wanted the ST out the door as far ahead of the Amiga as possible to try to blunt the impact of it's release somewhat. That's why the Yamaha sound chip was chosen. There was no time or budget to make or buy anything more exotic. Last time I looked even the basic ST had some custom silicon. The DMA controller sure as heck isn't an off the shelf part. Neither is the GLUE/Shifter etc.

The single bird version is on the umich ftp site. I can't find the blitter specific version. I'd like to see it.

Did ST's have concept of Fast(CPU-only) ram .. i.e. the 68000 could run fullspeed in fastram (or running ROM routines) while bitplane+blitter used ALL cycles in chipram Amigas had more memory intensive video modes (68000+4 bitplanes = full CPU speed, but 5,6bitplanes started to steal cpu cycles i think; intensive copper use i.e. changing background color continously across scanline could also do that) also how did the ST blitter behave, surely it would also have to do cycle stealing Maybe i'm missing a detail here: Why was the amiga at 7.14mhz and the ST at 8mhz, if so rigorously tied to video scanout both clocks would be identical in 320pixels x 4bpp They more or less round all 68k instructions up into multiples of four cycles. The ST is unlike the Amiga fully compatible with the 68k. TAS executed from chip ram clashes with DMA on the Amiga and hangs the machine. As you say anything over 4 bitplane low res on the Amiga will steal cycles from the CPU. Did you know that *any* bitplane switched on or DMA activity (sprites etc) eats away at the Miggy's blitter bandwidth? The Amiga blitter is fully async with the 68k providing the CPU isn't doing reads/writes from chip memory. Unfortunately the custom chip registers on the Amiga are on the chip RAM bus too. The ST blitter is fast enough because it doesn't have any contention with the display DMA but it's not dynamic like the Amigas in that you have to poll to get good performance out of bus sharing mode. Both cool machines.. Both nice blitters...

The fastest instruction on the ST takes 4 clocks. It's possible to hit 2 mips using 4 cycle instructions. As you say times vary dramatically depending on the instructions used so the rating is kinda meaningless. The Blitter on the ST does steal cycles from the CPU. 50% on an async transfer or 90 - 100% on a synchronous transfer. 90% using the restart method or less if there are interrupts during a transfer.

When using GEM it makes no difference at all really, but obviously for games it's a different story because the blitter is not compensating for badly written OS routines. The Amiga blitter has a better DMA design and also a higher mb/s throughput I think. But then the ST only has to shift 16 colour image blocks in a 16 colour screen too so half the data. The bandwidth is actually higher on the ST one for clearing or filling. The story is different for more complex operations which take multiple passes (masking). There's nothing really wrong with the way the blitter is integrated into the ST IMHO. It yields to other DMA devices if necessary and it allows interrupts with 90% hog mode performance. The Amiga one is a bit more dynamic in that it's more intelligent about yielding to the CPU during a blit nice operation. The Amiga one can also run at full speed assuming the CPU is only accessing fast RAM during a blit. On the other hand the Atari one has access to all of the RAM (4 mb for the ST/ 14 for the Falcon) along with the ROM and the chip registers. If you want to see the difference having a blitter makes to the speed of GEM try running ST zip and moving the window around with the blitter active/inactive. That app doesn't force 8 pixel window alignment and you will see the update speed depends on what shifts the CPU does. With the blitter the update speed is constant.

It's not so bad. And it's free! A lot of this thread and the other ST vs threads have been about the need for different monitors, using RGB vs composite, etc. Euro36 plus the 2.x or above color scheme gave a great poor man's solution. A better solution would have been to add an AGA2000 (my Amiga 1000 had a slot for one, but I chose FFV becuse it was somehting like $120) and then add a cheap 13 or 14" VGA monitor and have 60Hz plus in all video modes. Again, I know there were better solutions. I just marvel at what the Amiga was able to do in just software alone with the existing hardware. I need to try out Euro36 1200x400 on a 1080 monitor -edit- BTW that's a handy chart in your link. I thought the resolutions were too low at first but then realized it was Workbench-centric so it lacked the overscan modes most of us used for any serious graphics work. Is indivision the new internal scan doubler? I heard you can "stack" them for dual monitor output. Yeah. I've only seen the AGA version. There's an ECS version too. One good thing about flicker fixers/scan doublers is that you aren't restricted to system legal software. Amusingly enough any SCART enabled LCD tends to do both these days. Looks great for workbench/GEM but they also suffer from 25hz screen updates. It makes games look terrible.

Early/mid 90s actually, and only the first (1993-94) season used Amigas, after that they switched to using lightwave on other platforms. (Pentium based workstations iirc, I seem to remember something about Alpha based systems as well) I was thinking of the Cyberstudio suite, which paved the way for modern 3D packages. Were all those tv things done on early Amigas? Good god they must have had the patience of saints! The rendering must have taken decades.. Was that a standard 8 MHz 68k machine? Those would have been 32-bit Amigas, probably with 68060 accelerators and probably PPC coprocessors as well. (and there were similar upgrades for ST I beleive, at least for some models) Even the A4000 came with a 68040 stock. (I think the tower version of the 3000 might have as well) If you have the DVD box set for babylon five you can watch an extra where the composer shows you what's in the studio. He uses an ST for the music. Now that geeked me out. ST for sound and Amiga for the gfx on the pilot Frank