Jo22 wrote:And it seems that special software they use is doing most of the work.
Special software combined with special hardware. That special hardware did not exist for other platforms, as said before, because they weren't designed with genlocking in mind, so you couldn't sync your machine to an external signal.
Jo22 wrote:That's why comparing, say, a pimped Amiga to a consumer's PC isn't quite accurate. Sure, an FPU used to be expensive,
but the performance gain it brought made the whole development more comfortable and bettered the work flow.
Again, it's not as simple as just having an FPU or not.
It's about being able to get a broadcast signal out of your machine, and synchronizing it to external production equipment.
Since this simply wasn't possible on other platforms, the rest of your argument is moot.
The VideoToaster was built for the Amiga for this exact reason. I think you fail to understand that.
It's not a case of "what if they built the VideoToaster for PC?"... They couldn't build it for PC in the first place. If they could, they probably would have, because the PC was a more common platform, so commercially it would have made more sense. Also, by the time the VideoToaster was launched, there were PCs with much more raw processing power than an Amiga available. In that way it would also have made more sense.
So you have it backwards.
But that is exactly the thing: People who only understand PCs, can only think in terms of processing power, raw numbers etc, and cannot understand that some platforms are more than the sum of their parts.
Jo22 wrote:But it also had its shortcomings. Blitter and CPU could never work the same time, for example.
I heard that piece of false information before. Where did you get this?
Because it is false in at least two ways.
The Amiga was specifically designed so that all the custom chips could work together independently. All chips had their own DMA channel allocated at specific slots in the scanline timing, each with their unique priority.
The blitter can obviously access memory at any point during the frame. However, the blitter can only access chip memory.
The CPU can access either chip or fast memory.
So there are two scenarios:
1) CPU accesses fastmem, blitter accesses chipmem.
In this case, they work fully independently. The CPU can read/write fastmem at every cycle, and the blitter can read/write chipmem at every cycle. They work together perfectly.
2) CPU and blitter both access chipmem.
In this case, blitter has priority over the CPU. Depending on the actual operation, the blitter may or may not try to access chipmem at every cycle. The CPU will never access memory at every cycle. The 68000 is simply not that efficient. The CPU can access the 'leftover' cycles from the blitter, so it can continue to run in parallel (and depending on the instructions, the CPU may or may not need a lot of memory acces. For example, mul and div operations take a lot of processing cycles, where no memory is accessed. These can be combined perfectly with blitter access).
In the case where the blitter uses every cycle, there is an arbitration scheme implemented:
http://amigadev.elowar.com/read/ADCD_2.1/Hard … e/node012B.html
If DMAF_BLITHOG is a 0, the DMA manager will monitor the 68000 cycle
requests. If the 68000 is unsatisfied for three consecutive memory
cycles, the blitter will release the bus for one cycle.
This is the default.
So the 68000 will never be delayed for more than 3 cycles when it tries to access the bus. This means that the CPU can still work in parallel with the blitter in these cases (and it will never slow down to less than 1/3rd of its normal speed. In practice the speed is generally much higher, because most of the time the 68000 doesn't even access half of all available memory cycles. It needs the other cycles to decode the instructions and execute them in its ALU. The 68000 also has a total of 16 registers, far more than an x86, so you can keep far more data in registers, without requiring memory access).
Essentially it's not really different from how CGA/EGA/VGA add waitstates on the bus, so the CPU cannot access VRAM at every cycle. Or how the DMA controller in the PC has priority over the CPU.
It's a limitation of the RAM speed, not of the system design. There are only so many memory cycles to go around. You can't have your cake and eat it too.
Setting DMAF_BLITHOG to 1 is something you'd only do when you want maximum performance from the blitter, and there is no need for the CPU to access any chipmem during that time (fastmem and ROM can still be accessed by the CPU in this case).
So I don't get why people would make claims that CPU and blitter cannot work together.
That implies that it's a sequentially operating system, where the blitter would 'take over' the system and the CPU would be idle until the operation is complete. That is absolutely NOT the case. The Amiga is a full multiprocessing system, with all custom chips working in parallel, and sharing of resources.
