14

I'm looking for information whether there has ever been an official statement by Commodore back in the days on why the Original Chipset was limited to doing 6 bitplanes only when running in low horizontal resolution.

The Amiga DMA Allocation Channel diagram from the Hardware Reference Manual, 3rd edition clearly shows that 2 more slots are free in low resolution:

enter image description here

Enabling 8 bitplanes in low resolution would have saturated the chip ram bandwidth, much like 4 bitplanes in high resolution, therefore making the machine sluggish as 4 bitplanes high res makes it. But then, why not limit high res to 3 bitplanes?

Adding 2 more bitplane pointers, 2 more shift registers to Denise, and more CLUT registers does not seem to me like a huge hurdle, even in 1984/85.

What other reason could it be?

Improve this question
3
  • 5
    I think the size of the CLUT was the limiting factor. Increasing it from 32 to 256 entries would have been significant. It's the equivalent of 168 more 16-bit registers (since each CLUT entry was 12 bits).
    – Brian H
    Commented May 27, 2017 at 19:07
  • A good example of how bad a good question can evolve when it's based around a link-only picture.
    – tofro
    Commented Nov 11, 2018 at 10:35
  • 2
    I updated the link to PostImg's new domain. If you click now you will see the image.
    – user180940
    Commented Nov 12, 2018 at 13:35

3 Answers 3

Reset to default
15

IIRC, the primary reason for the decision on 6 bit planes was die area. Registers (control and shift, but especially if the LUT was expanded) take up measurable die area. The original bottom end price target was for an under $400 Hi Toro game machine. This allowed only 32 kB of DRAM, and 8 bit plane layers was far more than fit in memory. So why increase costs of the higher volume target?

The higher price target home computer decision came after the chips were floor planned... too late to change things and floorplan larger ASICs, given the extremely limiting R&D budget and aggressive schedule.

Also, hold-and-modify was an option for game designers who wanted to display more colors.

There is no official statement by Commodore because they had no clue how Hi-Toro and Amiga, Inc. designed the system and OCS over a year before their purchase of the technology.

Improve this answer
3
  • 1
    Guess that I must accept this as a the correct answer, coming from one of the original Hi-Toro designers :)
    – user180940
    Commented Jun 18, 2017 at 21:18
  • 1
    @user180940: well, it’s not contradicting. The original 32kB, however, is an interesting additional fact. I always wondered about the original price target, as the first Amiga’s release price was so far away from a home computer…
    – Holger
    Commented Jun 19, 2017 at 7:41
  • Though now I realize that 32KB is not enough to hold a full 6 bitplane low res screen. 320 x 200 x 6 / 8 requires 48KB. So maybe the 32KB later became 64KB, or maybe there originally was a super-low-res mode with 280ns pixels for showing HAM pics in 32KB ? Or was the part of the cartdrige ROM address map meant to be addressable by Agnus in the original games machine design?
    – user180940
    Commented Jun 20, 2017 at 22:07
10

You are underestimating the on-chip costs of additional colors at that time. Supporting six bitplanes was already maxing out the possibilities, which is best illustrated by the fact that there were not enough CLUT registers even for six bitplanes, but only for five (32 colors), so six bitplanes could only be used via EHB, HAM or Dual Playfield mode.

If adding another 32 CLUT registers was that easy, there was no need for the EHB compromise. Not to speak of adding another 224 color registers…

Besides that, reserving all cycles to the display DMA implies that neither Copper, Blitter nor CPU (in the absence of real FastRAM) could do anything while the display data is transferred, i.e. could only work during the blanking phase and that with even more graphic data to process. Such a display mode is not very useful for real applications (you may try a 256 color SuperHires mode on an AGA machine without FastRAM to get the idea)… So the benefit would not have justified the higher chip costs.

Improve this answer
5
  • Expanding the CLUT would have been expensive, but adding more overlay modes might have been helpful. For example, adding an to overlay a single 640-pixel bitplane onto what would otherwise be a 320-wide mode could have been helpful for a wide range of purposes.
    – supercat
    Commented Jun 13, 2017 at 22:27
  • @supercat: that special overlay would require chip space too and the fact that it would steal cycles from blitter and cpu still doesn’t change. But of course, we could discuss a lot of modes that could have been possible with the available technology, not knowing which were considered and rejected and which were never considered.
    – Holger
    Commented Jun 14, 2017 at 6:23
  • The chip space required would have been far less than for expanding the CLUT. It might have been necessary to do something like have the 640-mode layer display alternating pixels from two 320-mode bitplanes, but sufficient bandwidth existed to overlay a single 640-mode bitmap on something like a HAM screen, and drawing text would have been much more efficient than doing all the gymnastics necessary to write text to a HAM screen.
    – supercat
    Commented Jun 14, 2017 at 14:15
  • 1
    @supercat indeed, in the end Commodore with the Hombre chipset (and probably the AAA before that) tried to implement the very same concept: the chipset had 4 8-bit "byteplanes" that could be combined in many ways, to either give 24-bit chunky (3 byteplanes), 16-bit chunky (2 byteplanes needed) or 8-bit CLUT indexed (1 byteplane). So you could have had a 24 bit playfield with a 8 bit playfield overlayed, or two 16-bit playfields.
    – user180940
    Commented Jun 18, 2017 at 21:27
  • Re: Hombre, Wikipedia even asserts that "to reduce costs, Commodore abandoned 256 color mode with Color LUT registers", albeit without evidence. If that turned out to be true it'd reinforce the point about palettes taking up a lot of space.
    – Tommy
    Commented Nov 12, 2018 at 14:54
1

HotPaw2, the "best answer" is probably incorrect:

This allowed only 32 kB of DRAM, and 8 bit plane layers was far more than fit in memory.

4 Hi-Res bitplanes take up the exact same amount of memory as 8 Low-Res bitplanes.

At Max overscan, the NTSC Amiga can fetch 768 pixels, and in PAL mode can do at least 566 lines, which adds up to 54,336 bytes, not 32K.

Claims that there would be problems with copper, blitter and 68K are inaccurate, since we have all see 16 color, Hi-Res Amiga OCS screens. That's the exact same same amount of data as an 8 bitplane low-res display. In short, if you can do 4 bitplanes in high-res, you can do 8 in low-res. The color register count is the real issue.

Also, "CLUT" does not really apply to the Amiga. "Lookup tables" is a crass PC concept used by software people who don't understand hardware. You know, the kind of guys who think everything is a Sprite. The Amiga uses Indirection to gate RGB values from the color registers. Even the Sprite output goes through the same circuit. There is no "lookup". There is no table. A 5 bit value selects which of the RGB registers have their bit patterns gated out to the DACs.

While the OCS chipset has the bandwidth for 6, 7 or 8 planes in Low_res mode, there are only 32 color registers. Sure, the cycles for 8 bitplanes are there. But the difference between 5 bitplanes and 8 bitplanes, means you go from needing 32 color registers to 256 registers. That's 8X as much space on die!

It should have been done. But at the time, 32 color regs, whose RGB levels you could change, plus a HAM mode must have seen like a ton when the specs were set in 1984. Hell it was still viable in 1994.

Commodore seemed to realize that more was better, and EHB mode was added. I can't recall if this was an OCS revision or only in ECS and later. It used 6 bitplanes but was saddled by having only 32 color registers, so they used the 6th plane for a half-as-bright modification to the register define by planes 1-5.

You have to wonder why they didn't add more color registers- it should have been doable without blowing compatibility.

Improve this answer
9
  • 2
    "lookup table" is a common phrase used to indicate a memory block used to translate an input (used as the address) to an output (the value stored in the memory), which seems to be exactly the context that it's being used in here. CF "LUT" (an abbreviation of lookup table) as used in FPGAs. I don't see how this is any different to the technique used in PC graphics hardware that supported modifiable pallets, e.g. EGA, so I'm not sure what exactly you're getting at here.
    – Jules
    Commented Nov 11, 2018 at 8:34
  • 1
    Also, note that you're looking at the publicised information from 1984 -- but the development of the Amiga began back in 1982. Decisions were made before there was any public knowledge, and there were substantial changes in the market in the interim -- DRAM prices were much lower in 1984 than 1982, and more importantly the target market had changed substantially: something that could only function as a games machine was considered a viable product in 1982, but in 1984 being a useful desktop computer was absolutely essential. Original target resolution was 320x240, not full-res NTSC/PAL.
    – Jules
    Commented Nov 11, 2018 at 9:00
  • 1
    Besides lookup table clearly being correct in context — it exactly is one extra level of indirection, e.g. where RGB values are looked up — I'd be surprised if many of your imagined people "who think that everything is a sprite" come from the world of the PC, being notably a platform that doesn't provide sprites.
    – Tommy
    Commented Nov 11, 2018 at 14:58
  • 1
    @Tommy - I believe the "everything is a sprite" line is a dig at the many game-oriented graphics libraries starting from the mid-80s and onwards that use the word "sprite" to refer to anything that is designed to move around the screen rather than be static (a tendency I first encountered along with this Forth implementation) rather than something that the hardware provides an ability to automatically move.
    – Jules
    Commented Nov 11, 2018 at 21:52
  • 1
    768×566 pixel “adds up to 54,336 bytes”— for a single bitplane. If you wanted 256 colors for that, you’d need >400kiB, but that would be the maximum that no one would exploit in practice. Let’s start with a conservative approach instead: 320×200×6 need 48kB, raising it to 8 planes would need 64kB. You are right in that four planes in Hires mode need the same amount as 8 planes in Lores (640×200×4 is 64k too), but that only allows the conclusion that this Hires mode was not really planned in the original 32kiB design. But of course, it was easier to add when the memory restriction was lifted.
    – Holger
    Commented Nov 12, 2018 at 8:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .