OCS discussion

[thedocbwarren]

I've always wondered about how the Amiga modes are derived.  Like for instance, we have EHB 320 mode, but no 640 32 colour EHB.  Or a form of HAM in 640 with 4 index and almost all control bits.

Someone mentioned ECS can handle 1280 in HAM.  Plus, any idea why 640 mode was not used more often since the Atari ST did a lot of 320x200x16 and Amiga can do the same in 640x200x16 with standard OCS?

Was is because 640 is buggered with 7MHz 68000s (or slow that is?)

[commodorejohn]

A lot of it has to do with chip-RAM throughput. The 6-plane 320px modes are pushing the limits of the bandwidth alotted to the bitplane-fetch channels. 640px mode requires twice as much data for the same bit-depth, so 6-plane 640px is well beyond its capabilities. (IIRC, 4-plane 640px takes all the video bandwidth on OCS.)

As for 640px being slow, that's because when running from chip RAM, the CPU has to compete with the chipset for RAM access, and the more the video takes up, the less chance the CPU has to fetch instructions and data, so it winds up just spinning its wheels more often than in less intensive modes. (This isn't a problem when you have some fast RAM, of course, but since none of the OCS home-computer models shipped with fast RAM, and the A500's default 512KB expander is "slow RAM" that's subject to the same restrictions as chip RAM, it's understandable why programmers shied away from it.)

[fishy_fiz]

Using hires (640px) uses twice the bandwidth of low res. Upping the color depth is proportionally less of a hit (from 4bit (16col) to 6bit (ehb) color is only a 50% jump (technically a little less, but for conversations sake)). The higher color depths (32colours through to HAM) are available in interlace modes though (320x400/512).
Additionally hardware sprites use colour registers 16 through 31, so even in 2-16 color modes regardless of resolution hardware sprites will use thier own colours.

There's no reason a stock ocs machine couldnt do games using higher resolutions, but being that required bandwidth at least doubles and moving gfx are twice the size (assuming same dimensions onscreen as a low res games) there'd typically have to be less moving gfx (ergo arcade style games arent really options). Put simply a game would have to be written and styled around these restrictions. RAM speed does play a part, but the amount of ram also comes into play here (bigger higher resolutions gfx require more RAM).

As for ECS being able to use super high res (1280px) in HAM, Im somewhat sceptical about that. So far as I know the super high res modes are restricted to 2bit colour for ECS. Feel free to correct me if Im wrong though someone.

[Zac67]

IIRC, 4-plane 640px takes all the video bandwidth on OCS.

Actually, 4-plane Hires takes all the chip RAM bandwidth there is. (Excluding horizontal and vertical blanking times that is, but with severe overscan there's not too much left.)
8-plane Lores could bandwidth-wise be possible but there are no such modes.

[psxphill]

As for ECS being able to use super high res (1280px) in HAM, Im somewhat sceptical about that. So far as I know the super high res modes are restricted to 2bit colour for ECS. Feel free to correct me if Im wrong though someone.

You're right ECS can only do 4 colours in super hires (1280 @15khz 640@31khz). The colour registers need to be setup in a special way as well because it's a bit of a hack.

[thedocbwarren]

All extremely interesting.  It does make sense there would be bandwidth limits to the graphics modes.  Nature of the beast I suppose.  If it weren't for that it seems the Amiga design is limitless with how much resolution and depth.

It's my understanding AGA can handle HAM in super high res, but then isn't HAM emulated and not really the same technology in AGA?

Do accelerators remove this memory bandwidth contention or do they sit on top of it?

[Kronos]

Hires-HAM wouldn't made alot of sense as you can only use 4Bits.

2 for mode (R,G,B or direct color) leaves only 2Bits for data.

So you'd have 4 direct colors and set every gun to only 4 values.... not very usefull for a mode only sensible for displaying pictures ....

But there was a pseudo-HAM mode were a viever would let the copper set a new pallete on every new line. Quite impressive results ....

[commodorejohn]

Do accelerators remove this memory bandwidth contention or do they sit on top of it?

Accelerators don't change anything about the chipset, only the CPU. (Matter of fact, they don't even affect fast RAM, which is why all the really good accelerators have on-board memory that runs as fast as the new CPU.) That's why RTG makes such a difference in performance: access to chip RAM is still constrained by the chipset speed and contention, whereas Z2/Z3 access is unconstrained (and, for Zorro III, faster in general.)

[Zac67]

It's my understanding AGA can handle HAM in super high res, but then isn't HAM emulated and not really the same technology in AGA?

HAM6 isn't emulated, it's still native to AGA. In addition to OCS/ECS's HAM6, AGA introduced HAM8 - 2^6=64 color palette or 6 bits of R/G/B variance. Since AGA quadruples video bandwidth (double clock & double width) it can run 8 bitplanes (planar or HAM8) even in SuperHires.

Do accelerators remove this memory bandwidth contention or do they sit on top of it?

Accelerators have no impact whatsoever on graphics capabilities, chip RAM bandwidth and such. For that you'll need to head the RTG route.

[Zac67]

(double post, sorry)

[freqmax]

What makes "slow RAM".. slow ?

[commodorejohn]

What makes "slow RAM".. slow ?

It suffers the same contention with the chipset for access as chip RAM does.

[freqmax]

But why RAM that suffers chip accesses, but still can't be accessed by the same chips?

[commodorejohn]

It's a quirk of Agnus/Fat Agnus, I believe. It was fixed in later versions, but unfortunately most/all stock 500s have it.

[freqmax]

The A501 expansion RAM and Zorro-II RAM all becomes slow-RAM in an A500 ..?