Things the Amiga didn't get right from Day 1

[LocalH]

Dynamic Hires/SHAM is not real HAM6. True HAM6 relies on the hardware allowing the standard "hold-and-modify" technique to access non-paletted colors, and can easily generate more than 16 colors on a single scanline. SHAM/dynamic hires simply changes up to 16 colors per line on a 16-color hires display, and can not access colors that aren't on the palette for a given scanline.

There is no way prior to AGA to use HAM6 on anything but lores.

[Foebane]

Originally Posted by LocalH

There is no way prior to AGA to use HAM6 on anything but lores.

Why was it that the OCS/ECS Amigas were limited to 16 colours in hires and no HAM, but the AGA Amigas were able to achieve ridiculously high resolutions AND colour depths like Super Hires HAM8, albeit at the cost of speed? I've never understood this "unshackling of graphical limitations" between chipsets.

[Jope]

Hardware and custom chips are designed with constraints:
- Time
- Money
- What is good enough at the time

4096 colours was good enough at the time and the ICS/OCS chipset had a maximum Chip RAM space of 512k. You can't fit a lot of stuff in there anyway, so the limits they deemed "good enough" were ok for the machine the chips were going to go in to.

AGA came six years later, RAM prices had fallen and micro chip fab techniques had gone forward to enable higher speeds / larger chips with more pins.

[robinsonb5]

Originally Posted by Foebane

Why was it that the OCS/ECS Amigas were limited to 16 colours in hires and no HAM, but the AGA Amigas were able to achieve ridiculously high resolutions AND colour depths like Super Hires HAM8, albeit at the cost of speed? I've never understood this "unshackling of graphical limitations" between chipsets.

It's just a question of bandwidth. The "unshackling" was done by making the Chip RAM bus 32-bits wide instead of 16-bits wide, and by doubling the transfer rate between the Chip RAM and chipset, which means AGA in its fastest fetch mode can fetch 64 bits of data in the same time ECS takes to fetch 16 bits.
These improvements were possible due to advances in technology, improved speeds, miniaturisation, surface-mount techology for circuit boards (routing a 32-bit data bus for chips with through-hole pins? Not anyone's idea of fun!), and not least, the falling costs of more advanced tech.

The real tragedy is that only the bitplane hardware was able to make use of this extra bandwidth, and the audio, disk and blitter weren't updated.

[plasmab]

Originally Posted by Juz400

Buying an off the shelf chip and drive could have been easier and cheaper to start with but when you are fabbing your own chips would that have been cheaper once you go over 100k units?
Were there licencing issues?
If you use the off the shelf, would you have to licence the code from WD to read/write to the format in your OS?
CBM didnt like to spend money on that sort of thing

CBM didn’t design the Amiga though. Amiga Inc did. Its just my opinion but I think they would have got to market sooner with more standard parts and have had more money left over. Plus we would have an easier time maintaining the machines.

[drHirudo]

Originally Posted by plasmab

CBM didn’t design the Amiga though. Amiga Inc did. Its just my opinion but I think they would have got to market sooner with more standard parts and have had more money left over. Plus we would have an easier time maintaining the machines.

This happened in the Atari land with the ST (The Jackintosh). Both Macs and Atari's used mostly off the shelf parts - one of them succeeded, the other miserably failed.

[Dunny]

Originally Posted by Foebane

Why was it that the OCS/ECS Amigas were limited to 16 colours in hires and no HAM, but the AGA Amigas were able to achieve ridiculously high resolutions AND colour depths like Super Hires HAM8, albeit at the cost of speed? I've never understood this "unshackling of graphical limitations" between chipsets.

For the same reason your C64 and ZXSpectrum didn't have hardware accelerated 3D graphics cards, nor quad-core GHz-class CPUs and GBs of RAM.

[plasmab]

Originally Posted by drHirudo

This happened in the Atari land with the ST (The Jackintosh). Both Macs and Atari's used mostly off the shelf parts - one of them succeeded, the other miserably failed.

Don’t think that either was a failure. ST and Mac both sold in good numbers. Atari and Amiga both suffered from the rise or PCs. Apple barely survived that period then rose again

[NorthWay]

Originally Posted by NorthWay

2. Copper has two different sources of control input, but can only act on one at a time (screen position and blitter done).

For some reason copper blitting has been churning around in my head as of lately and I thought I had a solution. Until I went back to the docs and read them:
"When the BFD bit is a 0, the logic of the Copper WAIT instruction is
modified. The Copper will WAIT until the beam counter comparison is true
_and_ the blitter has finished." (My emphasis)

If they simply had made that into an OR condition then you could have had lots more use of the copper in driving the blitter! (If it could have been a busy->nonbusy change test it would have been even better.)
(Though not perfectly as you could risk doing a blit twice if the copper was reset by top of screen in-between blit start and copper list pointer self-update.)

[sandruzzo]

Lack of true fast ram on A500, and better ChipRam, since Amiga was born as Computer instead of consolle

[Thomas Richter]

Sorry to jump in so late, but there are so many misconceptions here it is hard to start...

Originally Posted by drHirudo

1. Digital joystick - the same one as in Atari 2600 with SINGLE button! Like what the hell they were thinking?

Wrong. The Amiga (as well as many other contemporary machines) can support digital joysticks with up to 3 buttons, or analog joysticks with up to 4 buttons. That is certainly sufficient. However, the de-facto standard back then was digital-one button, Atari connector. Thus, it was a wise choice to use the connector/port that was state of the art, and allow users to pick from the huge third party joystick market. That nobody made a better joystick was not a choice made at Amiga nor CBM, neither is it a hardware limitation.

Originally Posted by drHirudo

2. No MIDI port!

That was probably not considered important for a machine with a built-in sound processor, primarily designed for simulations. It was really a matter of good luck that the ST could enter this market niche - it was not foreseen back then that there was some demand in this area. The hardware is capable enough for midi, so third party add-ons easily allowed to connect midi to the system, but it was too late. The ST occupied this niche.

Originally Posted by drHirudo

3. HAM mode was a hack, mostly useless for other than static pictures!

HAM was a left-over as the machine was initially designed to create YCbCr output rather than RGB output. HAM on YCbCr would have been more useful. However, leaving the mode in is more useful than removing it. It did establish the Amiga in the "budget art" segment.

Originally Posted by drHirudo

4. Non standard floppy disk format, very error prone!

Wrong, in multiple ways. So first, some physical facts: The density by which an Amiga writes data to the disk is exactly the same as the PC. No difference. The reason why more data fits on an Amiga disk is not because the density is higher, but because the sector gaps are shorter.


The reason for the shorter sector gaps is that the Amiga reads entire tracks anyhow, so there is no need for a sector gap. A PC floppy controller, however, fires up the hardware to read or write a single sector, so it needs to position the data correctly at the right time, and thus needs a larger gap to compensate for tolerances.


The reason for the Amiga custom format is also that it was made such that the blitter (yes, really) can decode and encode the tracks, so the CPU does not have to do it.



Hence, the resulting trackdisk format is considerably more efficient in storage and in resource usage than a PC format can be.


The file system is neither more error prone than the PC FAT system. OFS has checksums all over the place, and allocates data and directories dynamically, quite unlike the FAT which does not have checksums, and a static storage area for the directory. Hence, the only reason why you saw more errors are because the OFS can detect more errors - unlike FAT.

Originally Posted by drHirudo

5. No hard disk controller on board. Back in 1985 there were already 10 MB hard disks for under $1000.

Wrong. Consider a machine with a price point of $1000. Add another $500 for a hard disk controller. Now consider who is the typical client for such a machine, and you see your error. No problem adding a harddisk externally, the gap was closed by the A2000 which offered sufficient expansion slots for harddisks. Models with harddisk were sold later on.


Other things wrongly reported here:


DMA/Chip bus bottleneck: Actually, this is wrong. The memory throughput at the time the chipset was designed was cutting edge, and as fast as you could possibly go with the technology available. With 4 hires bitplanes, the bus is saturated, but not by choice, but by available technology, i.e. RAM speed.



Spires: The Amiga 8 sprites were pretty much state of the art, sprite channel re-usage advanced state of the art. Actually, you can draw as many sprites on the screen as you like, provided there are at most 8 per line. I can hardly remember any other system that allowed that. The TI 99/4A had a 32 sprite limitation, with - IIRC - 8 per line max as well.



Sprite colors do not overlap with bitplane colors, except on 5 or 6 bitplane data, so we are good.


CPU speed: Again, check the price point. The 68000 was already a (comparably) expensive piece of hardware compared to the budget contemporary 6502. I consider it unlikely that 14MHz chips would have been available. Besides - it is not that easy: Just adding up the CPU frequency does not help: The CPU has to integrate nicely into the rather tricky DMA slot allocation scheme of Agnus. With a 7MHz CPU, and 2 hires bitplanes, the CPU gets every other DMA slot, and hence every slot on a 7Mhz base frequency. With a 14MHz CPU, 2 bitplanes hires already means that Agnus steals every other slot for display DMA, hence - essentially - slowing the CPU down to a 7MHz clock. Hence, even if you had a 14MHz CPU in the system, the overall design would not be twice as fast. It would probably 20% faster or so, with a standard workbench. Thus, it was simply not worth the trouble.



However, a couple of design issues have not been mentioned:


Hardware wise, the bitplane concept was a mistake. An understandable one because this concept made it easier to add a line-drawer to the blitter, but one even Jay mentioned. It means that you have to fire up the blitter up to 6 times for an operation, slowing everything down. For some operations, one can be clever with interleaving properly, but it is still a problem. It also means that everything is harder for the CPU. A four-bit or two-bit chunky format would have helped.


Software wise: Oh well, the Os was written in a rush, and it shows. Graphics was designed without any proper abstraction in mind, just a very thin layer around the hardware, which made it almost impossible to update it to any other graphics systems. RTG systems have to run in circles to work around its awkward construction.


The dos.library was just a rush port of Tripos. While Tripos itself had a couple of interesting concepts, it messed up the entire design with its BPTR illness and it feels totally alien to the rest of the system as it duplicates a lot of structures (processes/tasks, getvec/allocmem, dospackets/messages, handlers/devices).

[robinsonb5]

Originally Posted by Thomas Richter

Hardware wise, the bitplane concept was a mistake. An understandable one because this concept made it easier to add a line-drawer to the blitter, but one even Jay mentioned.

Indeed - although bitplanes were at least useful in keeping memory usage down, considering 256K was considered a lot of RAM when the chipset was designed.

[sandruzzo]

Blitter needed to be able to draw 6 planes without cpu aid. Some sort of display list, plus a way to do the same at pixel level without cpu usage

[roondar]

Hardware wise, the bitplane concept was a mistake. An understandable one because this concept made it easier to add a line-drawer to the blitter, but one even Jay mentioned.

To be fair here, he specifically said in his 1989 interview that at the time of the Amiga's design bitplanes were the right choice (due to memory restraints), but in hindsight now in 1989 he sees byte/pixel would've been better.

Originally Posted by sandruzzo

Blitter needed to be able to draw 6 planes without cpu aid. Some sort of display list, plus a way to do the same at pixel level without cpu usage

You can do this already using the Copper, can't you?

[tarr]

More sprites!!!

[roondar]

Originally Posted by tarr

More sprites!!!

I often wondered what an Amiga with a more "C64 style"/console approach to sprites & graphics would have looked like. Personally, I have a hunch it would've been better in many ways and worse in many others. Better for some types of games, worse for applications for sure.

Interestingly, if the Amiga had used every cycle available after refresh, bitplane, disk and audio DMA are done for sprites (and making the utter fantasy assumption that the designers had infinite space on the graphics chip ), it would have been able to fetch & display something like 60-70 sprite channels per scanline on top of a 16 colour screen.

Of course, that would be a ludicrous design (one that entirely blocks the CPU/Copper/Blitter from working during the entire display area) and like I said it's basically fantasy in terms of how much silicon would be needed... But nonetheless, the bandwidth is there

[Thomas Richter]

Originally Posted by tarr

More sprites!!!

Enough sprites? These are hundreds of sprites, with ECS hardware, on a standard 2 bitplane screen. Not even hardware banging, just using the graphics.library VSPrite engine.

[sandruzzo]

@roondar

By heavly using copper, and dmas' cicles waste.. Think about if blitter could have been done this by itself..

[roondar]

Originally Posted by sandruzzo

@roondar

By heavly using copper, and dmas' cicles waste.. Think about if blitter could have been done this by itself..

The only thing that would've changed is that the Blitter then would've wasted those cycles. One way or another, you have to get that display list to the Blitter. It doesn't matter all that much for DMA cycle use whether you use CPU, Copper or the Blitter itself to get that data.

Not that I can't find some possible improvements that would fit within the level of technology we're talking about here.

One would be to allow direct X/Y coordinates instead of needing conversion. Another would be to have the Blitter, like the STE one, not need the last word of the mask for objects that are aligned in memory. A third one would be for the Blitter to be able to blit across multiple planes without needing the mask data to be read for all planes. A fourth one would be to look at the STE Blitter some more and consider it's half-tone system, which really was quite interesting. A fifth one would've been to have scaling built into the Blitter (though that may be a stretch for a 1985 chip).

Lastly, it would've been nice if the Blitter clearing functionality didn't have half of it's cycles being idle.

For AGA systems (again, assuming we're sticking with the same overal tech), I'd add variable CPU-Blitter priorities to that list as well as 32/64 bit wide blitting.

[sandruzzo]

@roondar

A little better blitter design, would have give him the opportunity to cache mask during cookie-cut, among other things.

I still think that some part of Amiga HW ARE unfinished. It miss so simple optimizations...