Things the Amiga didn't get right from Day 1

[Thomas Richter]

Thanks for the details on midi. Indeed, PAULA could have profited from a serial input FIFO for higher baud rates, indeed. Contemporary PC serial interface chips had a four-bytes receiver side FIFO which helped for higher baud rates. PAULA was, however, just an upgraded POKEY design with its single-byte fifo.

Actually, the Atari design already showed that the Pokey input buffer of one byte was close to the limits at the SIO transfer speed of 19200 bytes, so I wonder why that wasn't changed, or PAULA wasn't upgraded along with AGA.

[Bruce Abbott]

Originally Posted by Thomas Richter

Thanks for the details on midi. Indeed, PAULA could have profited from a serial input FIFO for higher baud rates, indeed. Contemporary PC serial interface chips had a four-bytes receiver side FIFO which helped for higher baud rates.

As this thread is about "things the Amiga didn't get right from day 1" I dispute the word 'contemporary'. The first FIFO UART chip used in PCs was the 16550, which debuted in 1987 with IBM's PS/2 line. However many PC clones were still using non FIFO 8250/16450 serial chips in the early 1990's, postdating the Amiga 1000's introduction by half a decade and the A500/2000 by several years.

But if we are comparing the Amiga serial port's MIDI performance with that of the PC then whether it used a 16550 or 8250/16450 is irrelevant, because neither was capable of the 31.25k baud rate required. That is why to use MIDI on a PC you needed a special MIDI port, which typically was included on sound cards (most of which still needed a MIDI interface cable to convert the TTL serial signals to optocoupled I/O).

[Bruce Abbott]

Originally Posted by drHirudo

Actually MIDI was problematic on the Amiga in the professional field...

Regarding the MIDI and why it become more standard on the Atari, than on the Amiga: There is a very good article by the author of Music-X, which explains one fundamental issue why the Amiga was never considered as serious MIDI machine:

A good article explaining the author's problem getting reliable MIDI reception, but not admitting why he couldn't - which was due to a fundamental misunderstanding of how the Amiga worked.

So, the Atari ST even with crappier sound chip and not multitasking Operating System, turned out to be better for MIDI than the multimedia machine Amiga.

The Amiga could easily have matched the ST simply by avoiding multitasking, like was done with games and sound samplers etc. So the real problem was that developers didn't understand the 'problem' of multitasking in real-time applications.

This reminds me of a music program by Gold Disk called 'Music' that was bundled with the A500. They made the fundamental mistake of using an 8 color hires screen, which sucked bandwidth from the CPU making response sluggish. Nobody who understood the basics of Amiga hardware would make that mistake. Makes me cringe to think how many A500 users got their first impressions of the machine's capabilities from this poor effort.

Originally Posted by Predseda

Very interesting reading, drHirudo. Another part of the article that is sad, is this one:

Actually I personally had no clue it is sinking until 1994 official bankrupcy announcement.

In reality the Amiga was a submarine from day 1, and never had any chance of matching the PC's user base. This was clear by 1985 when the only question on most people's lips was 'but is it IBM compatible?'.

[Bruce Abbott]

Originally Posted by TEG

Well, I remember an interview of Dave Haynie saying that the ST have buffered MIDI ports and that why the Amiga can't cope with it. If my memory serve me well, he said they made an error of conception by not considering this buffers point.

Not sure what that is supposed to mean, but the ST's MIDI port is implemented with an MC6850 ACIA, which despite being described as 'doubled-buffered' only buffers 1 received byte at a time, just like Paula.

[TEG]

Originally Posted by Bruce Abbott

Not sure what that is supposed to mean, but the ST's MIDI port is implemented with an MC6850 ACIA, which despite being described as 'doubled-buffered' only buffers 1 received byte at a time, just like Paula.

Look like there is subtle differences between how the MOS8520/Paula pair (TX and RX pins are connected to Paula) and the MC6850 handle serial communication. The MC6850 'doubled-buffered' documentation state that "a character can be read from the data register as another character is being received in the shift register". Perhaps this 1 byte buffer make all the difference.

So, is the Amiga able to do the same? And if yes, are the mechanisms to handle errors in the MC6850 are as well effective in the Amiga?

For the record here is the extract of the MC6850 documentation for the receive part:

RECEIVE

Data is received from a peripheral by means of the Receive Data input. A divide-by-one clock ratio is provided for an externally synchronized clock (to its data) while the divide-by-16 and 64 ratios are provided for internal synchronization. Bit synchronization in the divide-by-16 and 64 modes is initiated by the detection of 8 or 32 low samples on the receive line in the divide-by-16 and 64 modes respectively. False start bit deletion capability insures that a full half bit of a start bit has been received before the internal clock is synchronized to the bit time. As a character is being received, parity (odd or even) will be checked and the error indication will be available in the Status Register along with framing error, overrun error, and Receive Data Register full. In a typical receiving sequence, the Status Register is read to determine if a character has been received from a peripheral. if the Receiver Data Register is full, the character is placed on the 8-bit ACIA bus when a Read Data command is received from the MPU. When parity has been selected for a 7-bit word (7 bits plus parity), the receiver strips the parity bit (D7=0) so that data alone is transferred to the MPU. This feature reduces MPU programming. The Status Register can continue to be read to determine when another character is available in the Receive Data Register. The receiver is also double buffered so that a character can be read from the data register as another character is being received in the shift register. The above sequence continues until all characters have been received.

[Thomas Richter]

PAULA behaves in this respect the same as POKEY, its direct predicessor - and exactly as the 6850 ACIA. It is also double-buffered. While the receive register is being filled, the previous copy can be retrieved by the CPU.

However, the serial port does have problems catching up data at high bitrates, which is why we have these "RADBOOGIE" mode of the serial device which bypasses a couple of tests just to speed up interrupt processing. A four-bytes FIFO would have helped.

[TEG]

Originally Posted by Thomas Richter

PAULA behaves in this respect the same as POKEY, its direct predicessor - and exactly as the 6850 ACIA. It is also double-buffered. While the receive register is being filled, the previous copy can be retrieved by the CPU.

However, the serial port does have problems catching up data at high bitrates, which is why we have these "RADBOOGIE" mode of the serial device which bypasses a couple of tests just to speed up interrupt processing. A four-bytes FIFO would have helped.

Yeah, I forgot about what you said in your previous post about POKEY buffer while I redacted mine. So Dave Haynie sentence was a bit over-simplified or his memory played him some trick. So I conclude that both machines serial port are buffered but the Amiga needed a larger one due to multitasking or simply Interrupts design.

[Gorf]

Its really not like there is no working MIDI-software for the Amiga:

https://aminet.net/package/mus/midi/BarsPipes-demo
https://aminet.net/package/mus/midi/horny-68k
https://aminet.net/package/mus/midi/MIDIMon
https://aminet.net/package/mus/midi/MIDIPlayground
https://aminet.net/package/mus/midi/MIDIstuff_II

Or:
https://aminet.net/package/docs/hard/TriplePlay2

"The TriplePlay MIDI-Interface allowes to use up to 48 MIDI-channels with
Bars&Pipes."

So all reports about the Amiga would be just not capable of MIDI are simply not true.

That said: CBM could have made it a lot easier and better.

As discussed elsewhere on EAB, sound generally should not have been that closely coupled to the gfx-chips.
Paula/Portia should have been combined with CIA and DMAC and probably some FiFos as an independent unit of the system.

[TEG]

Originally Posted by Gorf

Its really not like there is no working MIDI-software for the Amiga:

https://aminet.net/package/mus/midi/BarsPipes-demo
https://aminet.net/package/mus/midi/horny-68k
https://aminet.net/package/mus/midi/MIDIMon
https://aminet.net/package/mus/midi/MIDIPlayground
https://aminet.net/package/mus/midi/MIDIstuff_II

Or:
https://aminet.net/package/docs/hard/TriplePlay2


So all reports about the Amiga would be just not capable of MIDI are simply not true.

That said: CBM could have made it a lot easier and better.

Now you exaggerate. We don't say it can't, we say it was not perfectly reliable. Testimonies (and history) seems to go into this direction. Of course it would be better to have first hand experiences to be sure.

[pandy71]

Originally Posted by Gorf

Why would YUV be more complicated?
Everything would be exactly the same except of the CLUT ... and HAM would look better.
The output signal would be different though - but the A1000 had both anyways RGB and colour-composite.

Instead of deriving the composite signal from RGB, as it was done, you could do it just the other way around: derive the analog-RGB signal from composite.
The only thing missing would be the TTL-RGB signal (which was not used until gfx-cards pass-through in the 90s...)

For the Video Toaster/Flyer this would have been a good thing, since it is fully digital-YUV internally.

YUV need multiplier with lot of very fast gates to do multiple RGB<>YUV in single video pixel time (sub 70ns) - Commodore had no semiconductor technology capable to do such feature.
of course they could use multiplierless YCoCg color space however it was invented by Microsoft around 2003...
So HAM is RGB limited and RGB itself was sane decision - all computer technology showed that analog RGB was and still it is right choice.
Side to this YUV equation are different for NTSC and for PAL and if Amiga will go for YUV internally then it would need also different scaling factors for Y, B-Y, R-Y as they are not the same for NTSC and PAL so even more complicated design.

In theory there is nothing against coding HAM as YUV and transform YUV embedded on RGB lines to proper RGB externally even nowadays - or instead YUV use YCoCg color space...
This could be embedded to modern (FPGA) Denise/Lisa re-implementation as feature that can be controlled by Copper so MPEG/H.264/H.265 video could be decoded without time consuming YUVtoRGB step...
TTL-RGB was extensively used by all external video modifiers (DCTV, HAM-E, A2024 etc).

Another topic is a MIDI - even on PC most popular MIDI UART was MC6850 (present in Atari ST) - definitely there is no FIFO there, simple external oscillator make possible to produce 31250bps - not possible on PC due NTSC derived frequency (same as on Amiga where system clock is tailored for NTSC or PAL) - simple freq divider prevent PC and Amiga to get 31250 bps.

This lead to biggest Amiga limitation directly affecting audio and serial capabilities - lack of the NCO - with NCO (16 bit NCO means 4 x 74283 - not much when compared to overall system complexity) instead simple digital frequency divider, Paula immediately get proper (music friendly), fine control over sampling frequency and also serial will get way more functionality due possibility to select usable transmission speed (as single NCO can be shared with 4 audio channels and serial port).

Atari ST deals with simple MIDI because it is not multitasking machine so reaction for interrupts is less affected by latency and associated jitter.
FIFO is mandatory for multitasking systems and that's why it was introduced on PC - to deal with time critical events...

btw forgot to add but 1 bit DA converters was understood and properly designed around 5..8 years after Amiga, also dithering and noise shaping is something that was born way after 1990 - single bit DA in Amiga is not feasible if full Paula compatibility is goal (to do 1.79MHz sample rate and at least 20..32 times oversampling necessary for delta sigma then we need at least 30..50MHz clock and design - probably beyond MOS Technology/CSG capabilities as they struggle with 28MHz designs - ECS Denise palette shuffling and limitations - probably they introduced some form ot time interleaving so probably CSG was incapable to do something more complex above 25MHz).

[Thomas Richter]

Originally Posted by pandy71

YUV need multiplier with lot of very fast gates to do multiple RGB<>YUV in single video pixel time (sub 70ns)

No multipliers, no digital technology. YUV-output, as TV is based on YUV, and analog "multipliers" if RGB output would be required. The Amiga predicessor, the Atari, had of course FBAS as output and was of course organized in a colorspace suitable for TVs. Programmable delay of the color clock to modulate the color signal, a resistor ladder for brightness. Think in technology of the 80's, not of the 21st century technology.


How created CRTs RGB color from YUV? Analogue, of course, but I would expect that originally no RGB output was considered, but this was probably relatively late adjustment.

[Gorf]

Originally Posted by pandy71

YUV need multiplier with lot of very fast gates to do multiple RGB<>YUV in single video pixel time (sub 70ns) - Commodore had no semiconductor technology capable to do such feature.

Why would you do that?
You just stay in the YUV space all the time, for all digital purposes.

(The only (analog) conversion one might do is at the output, where it is done in the A1000 as well - just in the other direction.)

[Gorf]

Originally Posted by pandy71

btw forgot to add but 1 bit DA converters was understood and properly designed around 5..8 years after Amiga, also dithering and noise shaping is something that was born way after 1990 - single bit DA in Amiga is not feasible if full Paula compatibility is goal (to do 1.79MHz sample rate and at least 20..32 times oversampling necessary for delta sigma then we need at least 30..50MHz clock and design - probably beyond MOS Technology/CSG capabilities as they struggle with 28MHz designs - ECS Denise palette shuffling and limitations - probably they introduced some form ot time interleaving so probably CSG was incapable to do something more complex above 25MHz).

Article from 1981 about noise shaping in sigma-delta modulation
https://ieeexplore.ieee.org/document/1095151

H. R. Schindler, “Delta Modulation,” IEEE Spectrum, Oct. 1970
(with circuitry)

H. S. McDonald, “Pulse Code Modulation and Differential Pulse Code Modulation Encoders” U.S. Patent 3,526,855 filed Mar. 18, 1968

H. Inose and Y. Yasuda, “A Unity Bit Coding Method by Negative Feedback,” IEEE Proceedings, Nov. 1963.

And no: we do certainly not need "30..50MHz" for that!
The Super Audio CD has only a 2.8 MHz sampling frequency for it's bitstream.

[pandy71]

Originally Posted by Thomas Richter

No multipliers, no digital technology. YUV-output, as TV is based on YUV, and analog "multipliers" if RGB output would be required. The Amiga predicessor, the Atari, had of course FBAS as output and was of course organized in a colorspace suitable for TVs. Programmable delay of the color clock to modulate the color signal, a resistor ladder for brightness. Think in technology of the 80's, not of the 21st century technology.

Nope, there is no such thing as YUV based TV - TV's are RGB and YUV is to create broadcast signal compatible with monochromatic TV.
There is no consumer TV equipped with YUV input, some broadcast monitors may have Y, B-Y, R-Y inputs but still this is not YUV - recently (with HD introduction i.e. almost 30 years ago) YPbPr component interface was present at TV's - mostly US but still this is not YUV but rather something like RGB.
Most if not all "YUV" based computers are simple delay logic where "sine" and "cosine" are created as taps in some serial shifter - good for maybe 100..200 colors.
So you can have FBAS or rather CVBS or perhaps S-Video (Y+C where Y bandwidth is max 5.5MHz and C bandwidth somewhere around 2..3MHz).
RGB was simply better as native representation natural for video world (cameras and displays work natively in RGB space)

Originally Posted by Thomas Richter

How created CRTs RGB color from YUV? Analogue, of course, but I would expect that originally no RGB output was considered, but this was probably relatively late adjustment.

Well, for game machine perhaps "YUV" was good enough and allow to natively create some form of the composite signal, later when situation on market was changed and Amiga suddenly became Personal Computer using RGB color space was rather natural choice.

Originally Posted by Gorf

Why would you do that?
You just stay in the YUV space all the time, for all digital purposes.

(The only (analog) conversion one might do is at the output, where it is done in the A1000 as well - just in the other direction.)

Nope... it is rather painful to perform some operation in "YUV" and that's why computers use primary component space - RGB - natural selection for RGB displays - YUV is used only in color composite signals mostly tailored for RF broadcast... plenty of limitations... RGB is free from those limitations, native, simple etc - HAM as kind of Delta compression will work better with "YUV" as it's nature fit for "YUV" limitations (Y is decorrelated from C signal i.e. luminance important from resolution perspective is almost independent from color information)

Originally Posted by Gorf

Article from 1981 about noise shaping in sigma-delta modulation
https://ieeexplore.ieee.org/document/1095151

H. R. Schindler, “Delta Modulation,” IEEE Spectrum, Oct. 1970
(with circuitry)

H. S. McDonald, “Pulse Code Modulation and Differential Pulse Code Modulation Encoders” U.S. Patent 3,526,855 filed Mar. 18, 1968

H. Inose and Y. Yasuda, “A Unity Bit Coding Method by Negative Feedback,” IEEE Proceedings, Nov. 1963.

And no: we do certainly not need "30..50MHz" for that!
The Super Audio CD has only a 2.8 MHz sampling frequency for it's bitstream.

Papers you are referring to are mostly dedicated to Delta modulation where Delta Sigma is something slightly different (negative feedback) - also this is not about theory of signal coding (proposed somewhere at the first half of 60's) but practical implementation in integrated circuits (cheap) - 1 bit coding materialized and matured as a product after 1990... (perhaps you recall MASH - first generation of MASH DAC's was big fail due poor understanding of some Delta Sigma phenomenons), Delta modulation was used in telephony but has rather poor spectral efficiency. PCM and DPCM are not synonyms for Delta/Delta Sigma.
SACD has only 2.8MHz but comparable bandwidth to PCM with sampling around 50ksps - Paula 8 bit PCM sampling rate is 1.79MHz so you need to oversample signal at least 20..32 times to get comparable 8 bit quality (around 40..50dB) in Delta Sigma (my assumption is that they will use first or second order Delta Sigma max due stability issues for higher DS orders).
Btw FPGA DS DAC implementations are usually clocked with 50..100MHz and still they are rather poor DAC's (somewhere around 60dB i.e. 10 bit quality).

[Gorf]

Originally Posted by pandy71

Nope, there is no such thing as YUV based TV - TV's are RGB and YUV is to create broadcast signal compatible with monochromatic TV.
There is no consumer TV equipped with YUV input, some broadcast monitors may have Y, B-Y, R-Y inputs but still this is not YUV - recently (with HD introduction i.e. almost 30 years ago) YPbPr component interface was present at TV's - mostly US but still this is not YUV but rather something like RGB.
Most if not all "YUV" based computers are simple delay logic where "sine" and "cosine" are created as taps in some serial shifter - good for maybe 100..200 colors.
So you can have FBAS or rather CVBS or perhaps S-Video (Y+C where Y bandwidth is max 5.5MHz and C bandwidth somewhere around 2..3MHz).
RGB was simply better as native representation natural for video world (cameras and displays work natively in RGB space)

This does not really matter since most monitors and TVs in 1985 had composite luma-chroma based inputs, and the A1000 had a composite output.
You can derive the composite signal even easier from YUV than from RGB, since the Y is actually luma...
Same goes for S-Video.
There is absolutely no benefit to having a RGB signal except for dedicated monitors with RGB input.
As a reminder most CGS or EGS pc-colormonitors, the most common monitors back in 1985, had only digital RGB color inputs and 16 fixed colors ... but most also had a composite input ...
Real analog RGB monitors became only fashionable with VGA.

So it is actually a little bit awkward, that CMB was insisting on RGB, while they were in a hurry to get then chipset done...

Well, for game machine perhaps "YUV" was good enough and allow to natively create some form of the composite signal, later when situation on market was changed and Amiga suddenly became Personal Computer using RGB color space was rather natural choice.

For most TVs and early monitors the RGB output was no benefit but actually made the signal quality a little bit worse since first RGB was converted into luma-chroma composite - send to the TV/Monitor and converted back into RGB to drive the three electron beams...

Later it was an advantage, but by then an additional RGB output could have been added to new models.

On the other hand: all video codecs as well as jpeg use some kind of YUV, and it would have been also easier to implement some Gouraud shading when early 3D games become fashionable.
(the Atari Jaguar did this)

Nope... it is rather painful to perform some operation in "YUV" and that's why computers use primary component space - RGB - natural selection for RGB displays - YUV is used only in color composite signals mostly tailored for RF broadcast... plenty of limitations... RGB is free from those limitations, native, simple etc - HAM as kind of Delta compression will work better with "YUV" as it's nature fit for "YUV" limitations (Y is decorrelated from C signal i.e. luminance important from resolution perspective is almost independent from color information)

What "operations" would you perform?
99.9% of all programs or games for the Amiga perform no operations on the color-space.
With YUV you only fill your colour registers with slightly different values. And the firs 4-bit nibble of your 12-bit value would be Y = brightness.
So it you want a slightly darker tone of the same colour, you just lower the first nibble by 1.

Papers you are referring to are mostly dedicated to Delta modulation where Delta Sigma is something slightly different (negative feedback)

That's why I posted a paper about negative feedback as well!

SACD has only 2.8MHz but comparable bandwidth to PCM with sampling around 50ksps - Paula 8 bit PCM sampling rate is 1.79MHz so you need to oversample signal at least 20..32 times to get comparable 8 bit quality (around 40..50dB)

Now your calculation is completely off.
Just because Paula treats 8bit-samples internally up to 1.79MHz it does not add any information to it (except loudness). It is just repeating the same value up to 64 times ...

So this are just some inner workings of Paula that do not matter at all, if you would design a new chip with sigma-delta output in mind.

You only have to take the PCM sample frequency as it comes from RAM into account.

There are a lot of discrete circuit designs from the 70s and early 80s around doing just that ... AT&T was experimenting with that for voice transmission and finally AMD mass-produced a modem-chip with sigma-delta DAC in 84...

So yeah, it would have been bleeding edge technology, but not impossible.

[chb]

Originally Posted by Gorf

As a reminder most CGS or EGS pc-colormonitors, the most common monitors back in 1985, had only digital RGB color inputs and 16 fixed colors ... but most also had a composite input ...
Real analog RGB monitors became only fashionable with VGA.

So it is actually a little bit awkward, that CMB was insisting on RGB, while they were in a hurry to get then chipset done...

Color composite is extremely bandwidth limited, esp. for NTSC - there's just 2-2.5 MHz for the Y signal, even a horizontal resolution of 160 pixels looks blurry. That was acceptable for a home computer system, but the Amiga was aiming for a different market. The decision to change to RGB from NTSC composite was a very sane one.

Originally Posted by Gorf

On the other hand: all video codecs as well as jpeg use some kind of YUV, and it would have been also easier to implement some Gouraud shading when early 3D games become fashionable.
(the Atari Jaguar did this)

The Jag actually used CRY, its very own color model developed by flare. Similar to YUV (luminance + two color components), but not the same, and it's not straightforward to convert from CRY to YUV.

[Bruce Abbott]

Originally Posted by Gorf

This does not really matter since most monitors and TVs in 1985 had composite luma-chroma based inputs, and the A1000 had a composite output.

I had a PAL A1000 and the composite output was terrible - color bleed, ghosting, massive dot crawl and iffy colors - just like all those other shitty home computers with composite output. I didn't pay $2700 for that!

There is absolutely no benefit to having a RGB signal except for dedicated monitors with RGB input.

Perhaps, but that is a huge benefit. It may also have helped for genlocking, converting to different standards and working with professional video equipment that used RGB.

As a reminder most CGS or EGS pc-colormonitors, the most common monitors back in 1985, had only digital RGB color inputs and 16 fixed colors ... but most also had a composite input ...

The Amiga was not a PC, so why should it be limited by PC monitors? If it wasn't for the PC, digital color monitors would probably have been rare due to their inflexibility and extra circuitry required to convert from digital to analog RGB inside the monitor.

Real analog RGB monitors became only fashionable with VGA.

Analog RGB was a widely used standard since 1980 when it became compulsory on all new TVs sold in France. It was used in the popular Amstrad CPC series (introduced in 1984), the Atari ST, the Tandy Color Computer 3 and many MSX machines, and later in consoles like the Sega Megadrive and Sony Playstation. Having a sharp display with a large palette of accurate colors was a good selling point, especially in Europe where many people had TVs with SCART. It also made sense to produce an 'international' computer that wasn't bound to a particular composite video standard (there are lot more of them than you might think!).

So it is actually a little bit awkward, that CMB was insisting on RGB, while they were in a hurry to get then chipset done...

If the Amiga didn't have analog RGB I would not have bought one. I was already enjoying the sharp analog RGB output of my Amstrad CPC664, and didn't want to 'downgrade' to the shitty composite outputs of earlier machines - particularly when I intended to spend a lot of time doing software development on it.

The idea that Commodore only put RGB in the Amiga because they were in a hurry is laughable. Analog RGB was considered the gold standard for video displays, which is why IBM used it in their high-end systems (and later for VGA).

RGB is the natural method because that is how our eyes see color. Composite/YUV was only invented to get around the severe bandwidth limitations of broadcast TV. It sucks, but was the only way to 'compress' the color information to be compatible with monochrome transmission. Unfortunately it continued to be used in the digital age (for similar reasons).

I have a Samsung SyncMaster 940MW LCD monitor/TV. These are very rare in New Zealand because we didn't embrace SCART here, but I was lucky enough to get one from the local op shop for $75. It's a good screen except for one very annoying limitation - the upscaler only works with YUV encoded color, optimized for low bandwidth composite - so it first coverts the RGB to this format before upscaling it. I got into the secret service menu and turned off every 'enhancement' I could that was trying to compensate for the lack of color bandwidth, but it still applies some edge enhancement. The SCART RGB picture is 'OK', but would be so much better if they had upscaled it directly!

For most TVs and early monitors the RGB output was no benefit but actually made the signal quality a little bit worse since first RGB was converted into luma-chroma composite - send to the TV/Monitor and converted back into RGB to drive the three electron beams...

Not if the TV or monitor had RGB inputs! Color monitors with composite inputs needed expensive extra hardware which manufacturers would have loved to eliminate - especially since a different circuit was required for each region (Amstrad actually did this. They took a standard TV and removed the stuff they didn't need, making for a cheaper system with a better display!).

Slightly OT - in New Zealand the importers hot-glued a bung over the composite input on Amiga monitors. Why? Consumer electronics attracted 40% sales tax, but computer monitors were a 'business' item so the tax was only 25%. Of course customers simply pulled the bung off as soon as they got it home.

On the other hand: all video codecs as well as jpeg use some kind of YUV, and it would have been also easier to implement some Gouraud shading when early 3D games become fashionable. (the Atari Jaguar did this)

Gouraud shading? 3D games? In 1985?

[Thomas Richter]

Originally Posted by pandy71

Nope, there is no such thing as YUV based TV

TV signals are all YUV based. Of course not YUV-component based, but composite or FBAS, which was the conventional form how home computers back then supplied a signal to a monitor. Of course, the quality is worse due to the lower bandwidth, which was probably the reason why they changed their mind.

Originally Posted by pandy71

There is no consumer TV equipped with YUV input

Certainly, all of them, or most of them, just that it's modulated. FBAS, or component, as I said.

Originally Posted by pandy71

So you can have FBAS or rather CVBS or perhaps S-Video (Y+C where Y bandwidth is max 5.5MHz and C bandwidth somewhere around 2..3MHz).
RGB was simply better as native representation natural for video world (cameras and displays work natively in RGB space)

Yes, of course RGB has a better bandwidth than FBAS.

Originally Posted by pandy71

Well, for game machine perhaps "YUV" was good enough and allow to natively create some form of the composite signal, later when situation on market was changed and Amiga suddenly became Personal Computer using RGB color space was rather natural choice.

But this was exactly what was happening. Originally considered a games console, they changed it into a PC. HAM was originally for YUV, and there it would have made more sense. Actually, instead of HAM, 422 sampled data (YUYV) would have made even more sense.

[Thomas Richter]

Originally Posted by Bruce Abbott

RGB is the natural method because that is how our eyes see color.

But not the brain behind the eye. The human vision system is much less sensible to hue variations than to luma variations, so something like YUV that separates out the luminance makes a lot of sense.

[Gorf]

Originally Posted by Bruce Abbott

I had a PAL A1000 and the composite output was terrible - color bleed, ghosting, massive dot crawl and iffy colors - just like all those other shitty home computers with composite output. I didn't pay $2700 for that!

Yes - largely because it was derived from RGB. And in addition the A1000 composite signal might not really been well adjusted to the slightly lower PAL clock. I doubt it looks that terrible on NTSC machines.

(Or are you talking about these RF-modulators? These are terrible of course, but that’s a different thing.. )

If Denises output was YUV the composite (and S-Video) output would have been better.

The idea that Commodore only put RGB in the Amiga because they were in a hurry is laughable.

You did not understand me here.
CMB changed the design of the custom chips from YUV to RGB despite of being in a hurry to get the new machine out!
That is the strange thing…

Not if the TV or monitor had RGB inputs! Color monitors with composite inputs needed expensive extra hardware which manufacturers would have loved to eliminate - especially since a different circuit was required for each region (Amstrad actually did this. They took a standard TV and removed the stuff they didn't need, making for a cheaper system with a better display!).

Here I was referring to early TVs and monitors without RGB input.
In this case native YUV would improve the signal quality.

Gouraud shading? 3D games? In 1985?

No, not in 1985.
You take this out of context here. At this point the discussion was about general advantages of the RGB colour-space in computing, so I brought the counterargument of video-codecs and shading.