[axilmar]

Originally Posted by Bruce Abbott

Interesting. Can you show us in detail how it could be done with 'very few registers'?


Sounds expensive, and an inefficient use of RAM.

But in fact the Amiga does have dedicated RAM for graphics and sound when you add FastRAM, and it even has a dedicated CPU for graphics (the Copper).

32 bits wasn't the largest bus possible at the time, but the 68020 wasn't available until mid 1985 (well after the Amiga's architecture was designed) so it didn't make sense to have a 32 bit main CPU bus. Graphics and sound chips could have used any bus width, but cost is directly proportional to bus width so 32 bits would have cost twice as much as 16 bits.

Of course in later years they did go to 32 bits, which is how the A1200 can do so much more than the A500.


Why?

I think you may be missing something very important here. You can design a machine with any performance you like (even with 1982 tech) but it won't go anywhere if you can't build it for a good price. The Amiga was originally designed as a gaming / home computer, so it had to be cheap. That's why it used dedicated custom chips, and shared RAM, and no fancy CPUs controlling graphics and sound, and everything squeezed onto a single board with the minimum number of chips to do the job.

In order to find which pixel to reproduce when scaling, you simply need a fixed width integer decimal number computation, an addition of integers, a rounding and a shifting. First you calculate the addition step, which comes from source width/destination width, then you have a pixel index which you increase by the step. Then you round the result, and select the pixel at the specified index.

I.e. in pseudocode:

let source_pixel_step = source_width / destination_width
let source_pixel_index = 0
for dst_pixel_index = 0 to destination_width
    let actual_source_pixel_index = round(source_pixel_index)
    destination[dst_pixel_index] = source[actual_source_pixel_index]
    source_pixel_index += source_pixel_step
end for

Once the pixels are produced, then they can be fed to the regular blitter functions, for actual blitting.

The above is for scaling across the X axis; for the Y axis, the same algorithm computes the source image row.

When the video ram uses bitplanes, the scaling can be done in parallel for each bitplane.

So the registers needed would be source width, destination width, source height, destination height.

Dedicated hardware and a bit of internal RAM could then offer a fixed scaling function, from X1 to X2 and for a specific row size (say, 16 pixels across). Then one could scale larger images by precomputing scale column widths. Or the hardware could be parallelized by splitting up the image into tiles and do the above scaling in parallel (first scaling of tile widths, then scale the tiles).

There is a lot to be done in this area and there is quite a lot of room for optimizations.

Now, regarding bus widths, since the main CPU would be 16-bit, that would have been the main CPU bus. The coprocessors would have 32-bit buses though.

I don't agree that the cost is linearly proportional to the bus width. I.e. I don't agree that a 32-bit bus would have twice the cost as a 16-bit bus. Maybe initially, but then the cost would go down according to how the production would be scaled.

I believe that with clever design, and a few extra bucks more expensive than the Amiga, a machine like the one I described could be created. After all, the Amiga's custom chips were special, weren't they? they weren't off-the-shelve chips, so the cost was mostly the design and the special manufacturing needed.

Well, maybe...;-).