Things the Amiga didn't get right from Day 1

[duga]

Originally Posted by Gorf

Yes: 1990 was the last big deal.
Commodore won the tender to "computerize" the offices of the former East-German railway "Reichsbahn".

So Ali was correct about this in January of 1991.

Also were 1990 and 1991 exceptional good years for Commodore (and Atari) due to the fall of the iron curtain - "cheap" (for west European standards) homecomputers were the only thing many people in Eastern Europe could afford in the first couple of years ...

But this was also very misleading for Commodores executive staff. They did not realize that this was just a lucky incident that would not last ...

Interesting read.

[grond]

Originally Posted by Gorf

According to Dave Haynie a AOS Library should provide the functions and would have been a good match, since the DSP provided some multitasking internally.
I did not have a closer look at the newly rebuild A3000+, but as far as I understand the DSP it is mostly working now...

Well, a DSP needs its executables loaded into some local RAM and has some 0-cycle local memory similar to an addressable cache for storing data sets and intermediate results. For this reason it can't really switch context quickly. Of course, if all DSP-functionality is only accessible through the library, then a unified "executable" with fixed functions would have been in place and could have been used by all programs. However, any program needing the DSP at the same time as another program which is already running a job on the DSP would have to queue until the job of the first program finishes. No round-robin on the DSP because of the 0-cycle local memory.

But why not a least a 14MHz CPU ... and some real upgrades in the chipset would have also been a good idea.

As I said: the idea was not that wrong, but is was implemented cheaply

Yes, I agree that it either shouldn't have been done avoiding the risk and chance the CDTV meant altogether or it should have been done at a higher level of technology. I remember thinking about the CDTV that it was just a very expensive standard Amiga and most people certainly felt so. If you wanted the games, you could get the A500, if you wanted a CD player, you could get one. There weren't many intersections between the two groups of customers, the videogamers on the one hand and the hi-fi enthusiasts on the other. Thus, I believe the CDTV would have flopped even if it effectively had been a CD32 in 1990 (with a 1990 price tag on it => much more expensive than the CD32 was in 1993/94).

[Gorf]

Originally Posted by grond

I don't think anyone would have seen a 2nd set of 32 colours with UV components changed together according to some predefined ratio useful. I guess a 16 colour / 4 shades per colour EHB-type mode would have been more practical to use than that.

Maybe .. but this is much harder to implement.
Just taking the higher bits of the CLUT entry and treating them as lower bits is relatively simple and involves no calculations just "wiring".

But 4 shades would involve some more complicated operations, if you do not want 3 of them being just black.

[Gorf]

Originally Posted by grond

Well, a DSP needs its executables loaded into some local RAM and has some 0-cycle local memory similar to an addressable cache for storing data sets and intermediate results. For this reason it can't really switch context quickly.

I don't think this is true for this particular DSP since it provides a small real-time multitasking OS on its own... so it must provide quick context switches

There weren't many intersections between the two groups of customers, the videogamers on the one hand and the hi-fi enthusiasts on the other. Thus, I believe the CDTV would have flopped even if it effectively had been a CD32 in 1990 (with a 1990 price tag on it => much more expensive than the CD32 was in 1993/94).

Well - I guess in 1990 with CD32 features* it would have been really a high-end machine, and could have been the first model of Commodores "playstation".
Even at a relatively high price in the first two years ... accompanied by a low-cost game-console-version (same chipset but no remote, cheaper drive and case ...) in 92.

I guess this would have blown away the console market at this time.

*) with some FastRAM

[pandy71]

Originally Posted by Gorf

Please read again, what I wrote about this mode.

Of course changing UV and keeping Y would not give you "half bright", but different colours with the same brightness!

So you could choose between an "half bright" mode , as we know it, or a "different tone" mode.

Take spreadsheet and simulate what color you get if you changing UV at the same time, besides UV are usually +-.5 max values so lets assume you have U=-.2 and V=.3 - then you modify by single bit on plane 6 some predefined value - simulate this situation and verify what kind of color you can get...

[Gorf]

Originally Posted by pandy71

Take spreadsheet and simulate what color you get if you changing UV at the same time, besides UV are usually +-.5 max values so lets assume you have U=-.2 and V=.3 - then you modify by single bit on plane 6 some predefined value - simulate this situation and verify what kind of color you can get...

I despise spreadsheets, but I can give you some examples:

In 4-bit values (1-16) YUV notation
Leaving Y constant at 8
shifting U and V by one (division by 2)


8 16 8 is:



8 8 4 (UV/2) is:



or
8 6 16 is:



and
8 3 8 (UV/2) is:



Try it yourself:

https://www.mikekohn.net/file_format..._converter.php

[grond]

Originally Posted by Gorf

In 4-bit values (0-16) YUV notation
Leaving Y constant at 8
shifting U and V by one (division by 2)


8 16 8 is:

8 8 4 (UV/2) is:

4-bits would be 0..15. Your examples then would become 7, 15, 7 and then 7, 7, 3 and so on.

The secondary colours seem pretty random to me (meaning they don't seem to fit an algorithm like the brightness bit easily does) but perhaps one could indeed fake a (rather gaudy) 64 colours palette because the extra set of coulors that is indirectly derived from the primary palette will likely fall into gaps between the freely defined colours. I wonder what a graphician would say about this. My impression is that they tend to define some primary colours and then define shades of those colours with e.g. a few more shades for greys and blues and less shades for reds a.s.o.

[jotd]

sharing a palette between sprites (which limits to 4 color palettes, each palette is shared by 2 sprites). That is super annoying.

Old 1980 arcade games hardware like Pacman etc.. have 6 sprites (probably 16-bit wide, like the amiga) so 2 less than the amiga which has 8, but the colors are separated.

So for instance on Pacman you can have 4 ghosts and pacman (plus another sprite for score or whatnot).

On amiga you can use sprites for ghosts, but then for Pacman you have to use a bob because yellow isn't in the ghosts palette.

So re-creating even simple games like old arcade games requires the blitter, masking, cookie-cutting, etc...

[Gorf]

Originally Posted by grond

4-bits would be 0..15. Your examples then would become 7, 15, 7 and then 7, 7, 3 and so on.

You are right of course:
I actually used 1-16 here - fixed that in the comment now.

You can do -1 on every value, if you prefer 0-15

The secondary colours seem pretty random to me (meaning they don't seem to fit an algorithm like the brightness bit easily does) but perhaps one could indeed fake a (rather gaudy) 64 colours palette because the extra set of coulors that is indirectly derived from the primary palette will likely fall into gaps between the freely defined colours.

exactly

I wonder what a graphician would say about this. My impression is that they tend to define some primary colours and then define shades of those colours with e.g. a few more shades for greys and blues and less shades for reds a.s.o.

One could do that here:
define 5 shades of purple and get 5 shades of green "for free".
and so on

[pandy71]

Originally Posted by Gorf

I despise spreadsheets, but I can give you some examples:

Nope, use spreadsheet, perform proper error processing (this cost a lot of silicone unless you decide to use some LUT and LUT's can cost also a lot on silicone). It is not easy to design such color output with necessary offsets and scaling coefficients to get valid RGB from YUV. Check original equation for YCbCr - they are only scaled but they not prevent to go RGB value negative so you need additional block able to cope with such cases... Don't forget that at the video output you can't produce bad voltage - all displays expect video between 0 and 1V (sometimes between 0 and 0.7V).

As i said before - it is very easy to use abstract language where arithmetic is performed with floats and it is easy to deal with all problems, also higher bitdepth allow to mask/hide some issues however in 4 bit arithmetic in 1984
some issues can be really challenging.

My goal was to show you that your request from chipset designers to use YUV color space need to be analyzed for pros and cons and as i'm aware of YUV limitations then i don't think that this will be particularly good idea.
Of course it would be nice if Amiga can perform some operations by HW in YUV space so for example MPEG could be less CPU intense but still - your example shows that those colors will be completely random from average developer/user perspective and to control them you will be forced to use special approach where current implementations albeit limited is pretty obvious.
Hope it is clear now - i fully understand decision about abandoning YIQ and choosing RGB it is best thing that happened to Amiga - less functional HAM is minimal cost worth to pay especially as mentioned earlier - it has no practical use due bus saturation with 6 bitplanes active. To be usable Amiga should have way faster CPU and different DMA cycles (at least twice faster RAM clock)

[Gorf]

Originally Posted by pandy71

Hope it is clear now - i fully understand decision about abandoning YIQ and choosing RGB it is best thing that happened to Amiga - less functional HAM is minimal cost worth to pay especially as mentioned earlier - it has no practical use due bus saturation with 6 bitplanes active. To be usable Amiga should have way faster CPU and different DMA cycles (at least twice faster RAM clock)

Not really entirely clear to me … but that is ok

Well there wasn’t really (affordable) faster DRAM available in 1984/85… some Japanese producers and Inmos in UK had some DRAM with a RAM cycle below 200ns so 10.6MHz (3 times 3.5) for the CPU and 5.3 MHz DMA slots would have been the next logical step and the maximum of what would have been possible

[Thomas Richter]

A couple of annoying features of my A2000: The proprietary RGB output connector - I'm not sure whether the PC style VGA connector was already an established standard, but if so, this would have certainly helped. The 15kHz horizontal time basis was probably the best they could do back then, and something CBM tried to address with ECS and "productivity", but the result was not very useful - the available bandwidth on the chip mem bus was too small to make this a "productive" mode.

Last but not least: Why is the power switch at the back of the A2000? This is just annoying. It should have been wired to the front.

[Gorf]

Originally Posted by Thomas Richter

A couple of annoying features of my A2000: The proprietary RGB output connector - I'm not sure whether the PC style VGA connector was already an established standard, but if so, this would have certainly helped. The 15kHz horizontal time basis was probably the best they could do back then, and something CBM tried to address with ECS and "productivity", but the result was not very useful - the available bandwidth on the chip mem bus was too small to make this a "productive" mode.

Last but not least: Why is the power switch at the back of the A2000? This is just annoying. It should have been wired to the front.

ESC Denise with 640*400@60Hz should would have been possible right fro the start … or at least for the A2000 in 87.
And with 1 bitplane it is not more demanding than the normal Workbench mode.
(Atari fans constantly praise the monochrom high res mode of the ST and there were in deed a couple of productivity applications making good use of it…)

Edit:
With a theoretical 10.6/5.3 MHz a 640*350 EGA-like mode with two bitplanes would have been possible - and many monitors supported this back then.

[chb]

Originally Posted by Gorf

Well there wasn’t really (affordable) faster DRAM available in 1984/85… some Japanese producers and Inmos in UK had some DRAM with a RAM cycle below 200ns so 10.6MHz (3 times 3.5) for the CPU and 5.3 MHz DMA slots would have been the next logical step and the maximum of what would have been possible

That's true, but for sequential access DRAM was faster already then. The Acorn Archimedes made extensive use of that, and earlier the Sinclair Spectrum(!) used page mode to read bitmap data and attributes in character mode without the need for a second bus like the C64's color ram. Probably the Acorn Electron with its 4-Bit memory bus also used some similar access scheme.



But for some reason, outside of the UK that technique was seldomly used...

[pandy71]

Originally Posted by Gorf

Not really entirely clear to me … but that is ok

My opinion is clear not something else - not trying to change your view - if you try to do some exercise with real numbers (formulas) in spreadsheet then you will see some limitations of YUV-like spaces. I'm not against YUV but i appreciate RGB in Amiga.

Originally Posted by Gorf

Well there wasn’t really (affordable) faster DRAM available in 1984/85… some Japanese producers and Inmos in UK had some DRAM with a RAM cycle below 200ns so 10.6MHz (3 times 3.5) for the CPU and 5.3 MHz DMA slots would have been the next logical step and the maximum of what would have been possible

Doubt on this knowing US economic patriotism - Lorraine was US and i doubt if Jay will use something from Japan, some 41256 DRAM had no implemented page mode, CAS before RAS or Hidden REFRESH functions - this is quite visible in Amiga as none of this features is used. Page mode seem to be used very first time in AGA and nibble DRAM with A3000. Page mode will require at least some comparator on address bus to verify if transaction is on already on opened page.
It is important to remember that Lorraine was designed around 4464 chips and some of them (for example TI) are equipped with page mode but nothing like this was used in ICS/OCS/ECS.
If Amiga was designed only 2 years later then we may expect twice faster DRAM - 1985..87 was kind of breakthrough in semiconductor (outcome of Reagan SDI where sub 1um semiconductor technology was founded).

[Bruce Abbott]

Originally Posted by Thomas Richter

A couple of annoying features of my A2000: The proprietary RGB output connector - I'm not sure whether the PC style VGA connector was already an established standard,

The 23 pin standard was established in 1985 with the Amiga 1000.

VGA didn't exist until April 1987, and even then it wasn't clear that it would become a standard. Most analog monitors before that were using either a 9 pin D or separate BNC connectors for each signal.

IBM's PGA adapter - released in 1984, used the larger DB15 connector. But this graphics card was not widely adopted, and it would not have been useful anyway because its pinout didn't support the features required for the Amiga. If the A1000 used a 15 pin connector for video it would have needed yet another connector for genlocking etc.

Today 23 pin D connectors are quite rare, but in 1985 they were readily available. So there was no reason not to use a 'proprietary' connector, and a good reason for using a 23 pin D over the more popular 25 pin - it prevented users from accidentally plugging in the wrong cable.

but if so, this would have certainly helped. The 15kHz horizontal time basis was probably the best they could do back then,

Not so much that they 'couldn't' do it as that it wasn't the focus of the design. At that time popular 'high scan rate' monitors used arbitrary frequencies that needed a special monitor (eg. MDA, EGA) and were incompatible with the broadcast video standards that the Amiga was based on.

and something CBM tried to address with ECS and "productivity", but the result was not very useful - the available bandwidth on the chip mem bus was too small to make this a "productive" mode.

Not exactly true. In monochrome (1 bitplane) there is plenty of bandwidth. This would have been fine for productivity apps similar to those on the Mac and Atari ST.

Unfortunately the Amiga's Workbench and most apps wanted at least 4 colors to look 'pretty', so the incentive to use ECS in monochrome was low. But the biggest problem with ECS was that it was introduced with the A3000, which didn't need it because it had a built-in flicker fixer!

Last but not least: Why is the power switch at the back of the A2000? This is just annoying. It should have been wired to the front.

Because you don't want mains voltage wiring going through the case where it might be a hazard. That's why most modern PCs have the power switch at the back - though of course they also have a 'soft' power button at the front, operating at a safe low voltage.

Personally I never had a problem reaching around to the A2000's power switch. It felt solid and reliable compared to the front-mounted mains push-buttons of typical PCs, and didn't feel like you were launching a missile like those huge PS/2 power switch levers did.

[pandy71]

DB23 carry signals not present in VGA standard - like external system clock with strobe, CCK output, digital and analog video and power lines - as such it is truly versatile video connector. You can for example feed externally variable system clock - used in Mac emulator to simulate variable speed Mac floppy or you can very nicely solve synchronization problem in for example TV studio's (so additional plus to external H and V sync trough ERSY bit).

Atari ST 640x400 mode should be possible with more than 70Hz so flicker less annoying especially on CRT's with long persistence phosphor (as dominant type on PC market in 80's), VGA, especially SVGA moved CRT's to different, short persistence type phosphor especially in 90's. ECS provided possibility to do this in non interlaced way and bus bandwidth is comparable between Atari ST and Amiga (as they use same technology of DRAM).

And switch could be arranged like many PC makers made - they use ISOSTAT-like power switch and pusher/taper - so way less clunky solution than IBM (seem IBM designed machines in fashion to survive nuclear blast).

[Gorf]

Originally Posted by chb

That's true, but for sequential access DRAM was faster already then. The Acorn Archimedes made extensive use of that, and earlier the Sinclair Spectrum(!) used page mode to read bitmap data and attributes in character mode without the need for a second bus like the C64's color ram. Probably the Acorn Electron with its 4-Bit memory bus also used some similar access scheme.



But for some reason, outside of the UK that technique was seldomly used...

Interesting!
I need to do some research on this … I was under the impression page mode was introduced around 87 or 88. (Which still would be early enough for the A500 and A2000)
But if it was already used in the Electron and Spectrum this is clearly a missed opportunity and qualifies as "did not get right from the start".

[Bruce Abbott]

Originally Posted by Gorf

Interesting!
I need to do some research on this … I was under the impression page mode was introduced around 87 or 88. (Which still would be early enough for the A500 and A2000).

Some DRAMs were capable of 'page' mode in 1984, but a lot weren't - so using page mode would have limited what DRAM chips they could use.

But what if they had used page mode? A DRAM rated for 150ns access time has a typical normal cycle time of 260ns. With 'page' mode it might get 155ns cycle time, but only for the second and subsequent cycles. So two cycles would be 260ns + 155ns = 415ns or 208ns per cycle. Clearly this is not fast enough to double the bus speed from 280ns to 140ns.

To make page mode useful you would have to use 'premium' (more expensive) DRAMs with a shorter access time. In those days RAM was a large part of the cost of the machine. The A1000 only shipped with 256k of 150ns DRAMs, and they were not page mode capable.

'Fast' page mode was introduced in 1986. With this and a faster access rating you might be able to double the bus speed. However by this time the OCS chipset's design was 'baked in', and fast page mode might have been difficult to add without breaking compatibility.

But hey, why not do it? Then Commodore could tell all those A1000 owners that their machines are redundant now so they will have buy the 'next generation' if they want to run the latest software. Then do it again next year. Massive profits guaranteed!

But if it was already used in the Electron and Spectrum this is clearly a missed opportunity and qualifies as "did not get right from the start".

The Spectrum still needed clock stretching to slow the CPU down in video memory. The Electron is probably not a good example since it only has a single 4 bit DRAM which is cycled twice to get 8 bits (and slowing the CPU down to half speed when accessing RAM). That's what I would call "not getting it right from day 1".

[Thomas Richter]

Originally Posted by Bruce Abbott

The 23 pin standard was established in 1985 with the Amiga 1000.

That's a bit what I was afraid of.

Originally Posted by Bruce Abbott

Not so much that they 'couldn't' do it as that it wasn't the focus of the design. At that time popular 'high scan rate' monitors used arbitrary frequencies that needed a special monitor (eg. MDA, EGA) and were incompatible with the broadcast video standards that the Amiga was based on.

The Amiga was designed to be a games console, yes, and thus depended on the 15kHz scan rates.

Originally Posted by Bruce Abbott

Unfortunately the Amiga's Workbench and most apps wanted at least 4 colors to look 'pretty', so the incentive to use ECS in monochrome was low.

Even in Workbench 3.9, the workbench.library has a couple of bugs that prevents its usage in a 1-bitplane mode (i.e. some things are just unreadable). That was all fixed in 3.1.4, allowing monochrome, but it doesn't look pretty.

Originally Posted by Bruce Abbott

But the biggest problem with ECS was that it was introduced with the A3000, which didn't need it because it had a built-in flicker fixer!

The flicker fixer is rather a hot-fix than a solution. It showed that (expensive) dual ported RAM that was fast enough to support 31kHz was available at A3000 times, yet CBM didn't use it for the custom chips and enhanced those, but rather came up with a technical kludge. Yes, it works, but it's not the right solution. AGA then came with a better solution to the same problem, but it was too late at this point.

Originally Posted by Bruce Abbott

Because you don't want mains voltage wiring going through the case where it might be a hazard. That's why most modern PCs have the power switch at the back - though of course they also have a 'soft' power button at the front, operating at a safe low voltage.

That is one solution, a soft-power button. Another solution would be to connect the switch with a pole to the front, an even better solution would be to layout the PCB differently and place the video slot in parallel to one of the expansion boards (as they did later on), and move the power supply to the right hand side. The overall layout of the A2000 is somewhat clumbsy and not well thought-about.