Things the Amiga didn't get right from Day 1

[TEG]

Originally Posted by Bruce Abbott

The following rant is a bit off topic, but illustrates why I hate YUV in retro home computers:-

The original ZX Spectrum (not +2 etc.) only produced YUV internally, which was fed into an LM1889 video modulator IC for conversion to composite. The color palette was the same as digital RGBI - 8 saturated colors with darker versions via the 'intensity' bit. Timex Corporation produced their own enhanced version of the ZX Spectrum for the US market, called the Timex Sinclair 2068. This also used the LM1889, but the color palette was different. One annoying difference is that 'bright' black became dark gray. This is a problem for some ZX Spectrum games that expect black to remain black when the color is 'bright'.

I bought a TS2068 off eBay a couple of years ago. As very few titles were produced for it, I wanted a way get the correct colors for ZX Spectrum games. Now you may be thinking "the TS2068 has digital RGB outputs, so just hook them up to an RGB monitor and you're good to go!". But in their 'wisdom' the TS2068's designers decided not to include the intensity signal.

Another problem with my TS2068 (which probably affects all of them) is that the composite signal was very noisy. But why? One reason was the switch-mode DC/DC converter which was putting ripple on the 5V supply. I replaced it with a modern converter module and the varying diagonal lines disappeared, but it still had strong vertical bars that appeared to be synchronized with bus operations.

This is when I realized the purpose of the peculiar video circuit that had 'ground' from another part of the motherboard coupled into it as a signal. They were trying to null out voltage variations induced into the Y signal inside the ULA. I ripped out this circuit and soldered a heavy copper wire between the ULA ground and video ground, which cut the interference in half. The picture now looked a lot cleaner, but still wasn't good enough for what I wanted to do.

My idea was to extract the intensity bit from the YUV signal, but this isn't easy because each color has its own intensity so Y isn't just 3 levels (black/gray/white) but has 16 different levels. To determine whether a color was 'bright' and 'dark' my circuit would have to distinguish between these 16 Y levels, but this turned out to be impossible because the interference exceeded the difference between brightness levels.

I cursed the Timex engineers for trying to fix the video interference problem by bodging the circuit rather than fixing the cause, but more for neglecting to bring out the intensity signal. If only they had brought all the digital RGB signals it would not have been a problem. But no, they decided to generate the analog Y signal inside the ULA, with predictable results - and no practical way to clean it up.

Custom ULAs were expensive to make, especially when they included analog circuitry. Imagine what those engineers thought when they tested the first production run and discovered they had massive video interference. "We can't afford to chuck all these ULAs", the boss probably said, "just bodge the boards and hope nobody notices!"

For the anecdote, my Spectrum experience at the time was mainly coming from a Timex bought in Portugal by my school friend and brought back here, in France. But... the Timex had no Scart plug and output a PAL signal instead of a SECAM one so my friend was unable to use it on the family TV. The Timex brand was not available in France, only the Sinclair one, no potential adapter to bought. Fortunately he found an electronic engineering who made an electronic assembly for him, so he was eventually able to connect the computer to the TV with the SCART plug. I clearly remember the image was perfectly sharp and we had a lot of fun with this computer. I don't know how he did that, only that the assembly was small. Perhaps it was just the composite signal connected to the Scart from the main board with no assembly at all.


By the way interesting to know I played games which did not have the "right" colours!

[TEG]

Originally Posted by Overdoc

However, I am surprised noone mentioned yet what the hell Commodore thought to provide a monochrome cinch output on the Amiga 500, instead of a FBAS coloured one?!
Did anyone ever in the world use that stupid monochrome port?!
Who would buy an expensive computer with 4096 colours, just to use it on a black and white TV or monochrome monitor?!

Yes! Me!

Why? Because my parents did not have the money to buy me a colour monitor. So I had (and still have) a Philips monochrome one, first used with the Commodore 128 and then the Amiga.
When I had some friends at home and we wanted to play some games on the Amiga, I then used the family TV in the living room.

So I was very pleased the Amiga 500 had a monochrome connector. I had my own screen, it was the important thing. Later when I was able to earn some money by myself I bought a colour monitor of course.

[dreadnought]

It's easy to be clever about it all now, with ~40 years of hindsight and in the era when everything follows some well established standards. But back then it was all Wild West and people made things up as they went. Sure, sometimes these tech decisions were caused by greed as well, but mostly probably just about survival instinct in an incredibly crowded, young market.

About composite, yeah, it's not so great for productivity but for gaming it was just fine, in fact a luxury coming from RF, and often utilised to produce some ingenious visual effects.

[vrxguy]

Agree the floppy size is prob the biggest issue i had. But I think all being done and said it made it interesting not being another clone or similar.

[Gorf]

Originally Posted by pandy71

Once again - limited time and budget - your proposal cost more silicone area than all Denise functionality - you can't ignore reality.

How so?
Ist would take exactly the same silicon area as the transistor count would be more or less the same.

Actually DS DAC environment will cost more than this what was implemented on Paula and still you just replace same functionality. - please don't ignore reality.

Again: how so?

In my account it would be the same or even lower transistor count and better sound quality.

Well Mary was prepared and as such new register appears in DFF space.

we are talking about "day one" = mid 80s.
Mary was mid 90s

no, you can't with current clocking scheme - yes you can if Paula clock will be 4 times faster i.e. not 3.58MHz but 14.18MHz.

Again: you give absolutely no reason, why this should be the case ...

Well, then current Paula 8 bit seem to be nice balance between time and cost.

sure - I just pointed out how it could be done better...

How different? there is transfer from place A to place B - so what kind of different DMA you propose?

the same DMA the the DMAC in the Zorro2 hard disk controller provided (16bit) ... or the SuperDMAC in the A3000 (were it is 32bit obviously ...)
Or the ACSI DMA chip in the Atari ST for that matter...

It would "steal" cycles from the CPU for sound, serial, parallel, MIDI and floppy (and potentially hard disk). For all usual use-cases this would be "neutral" speed wise, since it frees the cpu from several interrupts ... and of course floppy and sound would no longer be fixed to the horizontal frequency ...

And you have no longer bit stream but some 2 bit word - this is idea of MASH converters - anyway modern DS are usually multi-bit structures but still - lot of silicone to emulate what is currently implemented on Paula and in exchange no gain at all...

You can do it quite simple and maybe a little bit crude, but with very few logic elements ... and still end up with a much better SNR as Paula does.

[Gorf]

Originally Posted by Overdoc

However, I am surprised noone mentioned yet what the hell Commodore thought to provide a monochrom cinch output on the Amiga 500, instead of a FBAS coloured one?!

Because it is much cheaper (only passive elements) than colour composite ... but frankly I do not unterstand why CBM did not go the full length here and scrapped that output completely ...

Did anyone ever in the world use that stupid monochrome port?!

I hope not!

Who would buy an expensive computer with 4096 colours, just to use it on a black and white TV or monochrome monitor?!

.....
So, it would have been logical to provide a way to hook it up to a TV, like other homecomputers and consoles.

But while Atari quickly realized, and already brought 520STFM and 1040STFM models somewhere around 1986 on the market, Commodore needed until 1992 to provide a way too hook up an Amiga directly to a TV....

SCART

[Gorf]

Originally Posted by pandy71

Once again - you have 4 bit (12 bit) - quantization error is 16 times higher than for 8 bit - any additional bit will cost silicone and this must be fast silicone... (14/28MHz)...

While this would have probably been done in an analog way outside of Denise ... the "calculations" are not really a big thing:

you do not need a ALU or something like that, because this are just 3 fixed operations you would do in parallel on transistor level.
the "divivion by 4" or "two shifts" are actually just connecting the two topmost flip-flops (that hold that value) to the two last entries of the adder that follows next ... and so on.

[Bruce Abbott]

Originally Posted by TEG

For the anecdote, my Spectrum experience at the time was mainly coming from a Timex bought in Portugal by my school friend and brought back here, in France. But... the Timex had no Scart plug and output a PAL signal instead of a SECAM one...

That would be the Timex Computer 2068, a later model produced by Timex of Portugal. This had analog RGB output from the ULA feeding an MC1377 (same chip used in the A1000 and A520) to produce PAL composite. It also brought all the digital RGBI signals out to the edge connector, which is probably how your friend was able to get a sharp display with SCART.

The TC2068 fixed some ZX Spectrum hardware incompatibilities, and was bundled with an 'emulator' cartridge (modified system ROM) that allowed it to run 97% of ZX Spectrum games. These machines seem to be very rare today (or at least aren't for sale on eBay).

[Bruce Abbott]

Originally Posted by Gorf

The A1000 had already the "costly" part of generating a color composite signal from RGB built in.

So it is ok to do it in one direction but not in the other?

It makes sense to produce signals in the format used by the highest bandwidth display device (ie. RGB monitor), then other (lower bandwidth) formats are not compromised by the quality of the source.

The A1000 used an MC1377, which has RGB to YUV conversion built in. This could be done relatively cheaply because the YUV signals only had to exceed the low bandwidth of its internal chroma modulator (~250kHz chroma bandwidth and 4.5MHz luma bandwidth).

Going the other way is not the same. To maintain quality going from YUV to RGB the circuit must have a much higher bandwidth than is required for composite output. This alone makes it more expensive. The other problem was the lack of demand meant no 'cheap' off-the-shelf chips were available to do the job (plenty were available that did YUV to RGB conversion, but they were optimized for use in TVs where the source was low bandwidth composite).

It also made sense for the 'standard' format to be a simple one that was easy to implement accurately. YUV is not a simple format. It has different color spaces depending on the application (NTSC, PAL, YPbPr etc.). With RGB there is no argument over whether the signal is compatible with your equipment. With YUV it's which 'YUV'?

it would make sense in a YUV configuration to have two different EHB modes:
one only affecting Y (darker shade of same colour)
one affecting U and Y (different colour of same brightness)

Two different EHB modes now? Already your idea is suffering from feature creep. But this is typical. If the average Amiga fan had been in charge of the A1000's design it never would have seen the light of day.

Flickerfixers are a terrible workaround for a shortcoming anyways, that should not have been necessary - ECS should have been out 1987 at the latest ... and should have included a line doubler.

That's easy for you to say, but producing a design that accurately promoted all existing screen modes to VGA without ballooning the cost was not easy. Commodore's first attempt failed because they couldn't get it to work.

Amber is agnostic to the colour-format anyways: it just stores 12bit values and does not care if there are RGB or YUV.

Of course Amber was 'agnostic', but it was not responsible for producing the video output. A circuit was still required to convert the digital bits to analog. If the data was stored in YUV format then that circuit would have the added burden of converting high bandwidth YUV to RGB.

"cheap cheap cheap" is what killed Commodore and the Amiga ...

No, it was what kept them going. If the Amiga had been a similar price to a PC then few people would have bought it. We know this because few people bought the more expensive models. The Amiga was never about just getting amazing hardware and software - it was about getting it cheaper. The custom chips were part of that because they integrated stuff that cost a lot to do separately. Using RGB was part of it too, because you could buy the base machine and hook it up to a TV to save money, with the option of purchasing a low cost RGB monitor to improve the picture quality when you could afford it.

What really killed Commodore was squandering development resources trying to chase the high end (with the A3000 etc.). But they had a long tradition of doing this, producing a slew of business machines you never heard of while getting most of their sales from the VIC20, C64 and A500 - all 'low-end' home computers built down to an affordable price. The key to holding onto this market is to produce a machine that has amazing capabilities for the price, and does it with the minimum amount of hardware. That means not filling it up with features of dubious advantage that only appeal to technogeeks.

But at the same time it would have been even better suited to video production as it actually was.

The video production industry was well used to paying high prices for specialist gear. For them the Amiga was an incredible bargain even without YUV (which wasn't used much). For the rest of us, having YUV instead of RGB would have just been another compatibility issue (like those parallel and serial ports on the A1000 that had the wrong gender - what were they thinking?).

[Thomas Richter]

Originally Posted by pandy71

Once again - you have 4 bit (12 bit) - quantization error is 16 times higher than for 8 bit - any additional bit will cost silicone and this must be fast silicone... (14/28MHz)...

No digital silicon. Analog. Resistor ladders, same stuff as used for the video DAC right now.

Originally Posted by pandy71

Btw i've check your previous equations and you seem to ignore negative numbers visible there - this is something you can't ignore - how you will deal with negative numbers in silicone without increasing circuit complexity significantly and with this how accurate conversion to RGB can be?

I don't propose to deal with them in silicon at all. This is all analog, and shifting a signal = adding a DC offset - is the easiest thing in the world.


But hey, even in silicon, that's four 8-bit adders - that's it. Adding signed or unsigned does not make a difference in two's complement representation, and a constant shift is just connecting wires correctly.

Originally Posted by pandy71

Guess what - this will be something like 4:-1:-1 notation (bandwidth for UV/IQ is 5..11 lower than Y) - quite bizarre convention

Have you actually read the BT.601 specs? It's 422, really. But this is really a separate question. You need subsampling or bandwidth lmitations if you modulate the signal on a carrier, such as for FBAS or composite. If the chips output YUV natively, and you convert the output to RGB externally in analog, there is no bandwidth limit.

Originally Posted by pandy71

YUV is artificial color space in display and in physical world - RGB additive light color model is primary not YUV which is space of composite color encoder where you need combine monochrome compliant video with color and sent this in single wire or even worse you need to sent this trough RF waves...

Look, I'm not sure what you are arguing about. The primary color space that is used scientifically isn't RGB either, it's XYZ, yet I'm not proposing to use that for encoding, and whether a model is additive or not does not limit its applicability as internal representation.

Originally Posted by pandy71

there is plenty of compromises there and seem your idea is to have something with quality of the S-Video VCR at best...

No, wait. Confusion here. I'm not saying that a "component output" would have been better quality wise. CBM switched to RGB for simplicity and better quality, that's all fine. All I'm saying is that it would have been fine to continue the chips operating in YUV, and perform a YUV->RGB conversion externally, which would have improved HAM, and that you would not need to accept a quality drop.


Yes, CBM didn't select that option, we know. It's all too late, it's completely academic, all I'm saying is that it is feasible without much overhead.

[Overdoc]

Originally Posted by Gorf

SCART

Yes, but TVs did not support RGB on the Scart until about 1990 or so?
All the earlier ones supported only CVBS on the Scart.

And even on some of those which later supported RGB it was not possible to switch into RGB mode manually. Instead they needed 5V on one pin of the Scart to be able to switch into RGB mode.

Also think Scart was not very popular outside Europe?
So, RGB on Scart was not an option to hook up an Amiga 500 to a TV.

[Gorf]

Originally Posted by Overdoc

Yes, but TVs did not support RGB on the Scart until about 1990 or so?
All the earlier ones supported only CVBS on the Scart. In Austria, France an

Germany in all almost all new TV sets since 1982.

And even on some of those which later supported RGB it was not possible to switch into RGB mode manually. Instead they needed 5V on one pin of the Scart to be able to switch into RGB mode.

Also think Scart was not very popular outside Europe?
So, RGB on Scart was not an option to hook up an Amiga 500 to a TV.

Well … outside Europe the Amiga was not very popular either

[pandy71]

Originally Posted by Gorf

How so?
Ist would take exactly the same silicon area as the transistor count would be more or less the same.

Not as you already said - not all 4096 colors in YUV space can be displayed in RGB and at some point you need to prevent such situation.
Of course you can rely on external analog circuitry but analog is more expensive than digital...

Originally Posted by Gorf

Again: how so?

In my account it would be the same or even lower transistor count and better sound quality.

Not if you wish to keep same functionality as present in Paula with same number of pins... And how it can provide higher audio quality (DS sigma DAC's are not better than good monolithic DAC's - they are just cheaper)
Once again - more or less your ideas are corrected but they cost silicone - yuo need DSP-like features and plenty of multiplications that cost very serious amount of transistors.

Originally Posted by Gorf

we are talking about "day one" = mid 80s.
Mary was mid 90s

But it was picture how Commodore thinks as such 16 bit audio was one of important things to do in enhanced chipset but limitation was not DAC but DMA

Originally Posted by Gorf

Again: you give absolutely no reason, why this should be the case ...

this is simple - your volume regulation need to be sampled 64 times faster than sample rate of your audio samples, in case of 8 bit this 256 times faster i.e. your clock must faster 4 times... currently 3.58MHz and 6 bit PWM produce 55ksps maximum with volume control.

Originally Posted by Gorf

sure - I just pointed out how it could be done better...

partially, in theory you could do something similar as it was done in SID - use 8 bit DS DAC to feed bitstream to 8 bit multiplying DAC but this mean different state machine for Paula and maybe higher quality of audio. This could be done since day 1 different - not necessarily better.

Originally Posted by Gorf

the same DMA the the DMAC in the Zorro2 hard disk controller provided (16bit) ... or the SuperDMAC in the A3000 (were it is 32bit obviously ...)
Or the ACSI DMA chip in the Atari ST for that matter...

nope, not in A1000 and same - shared RAM between CPU and graphics (UMA), yes it can be done if you have faster RAM. In fact modern chipsets with embedded graphics suffer from same limitations only RAM interfaces are way more faster - but if you need really high graphic performance you are going for separate graphic card with local RAM and wide bus

Originally Posted by Gorf

It would "steal" cycles from the CPU for sound, serial, parallel, MIDI and floppy (and potentially hard disk). For all usual use-cases this would be "neutral" speed wise, since it frees the cpu from several interrupts ... and of course floppy and sound would no longer be fixed to the horizontal frequency ...

Hires and 4BPL already steal all CPU cycles i.e. RAM bandwidth is eaten by non CPU related cycles - you can have more DMA slots only if you reduce RAM cycle.

Originally Posted by Gorf

You can do it quite simple and maybe a little bit crude, but with very few logic elements ... and still end up with a much better SNR as Paula does.

Cost of packaging is more important than SNR... and Paula SNR can be improved by proper PCB layout and better decoupling + higher quality power.

Issue is that knowhow exist now (perhaps since 2000) - before it was not so obvious.

Rules for signal integrity on PCB in 2020 since 1985 also definitely improved.

[pandy71]

Originally Posted by Gorf

While this would have probably been done in an analog way outside of Denise ... the "calculations" are not really a big thing:

you do not need a ALU or something like that, because this are just 3 fixed operations you would do in parallel on transistor level.
the "divivion by 4" or "two shifts" are actually just connecting the two topmost flip-flops (that hold that value) to the two last entries of the adder that follows next ... and so on.

Shifts from 4 bit to? Divide 4 bits by 4 and how many bits left?
There is no 8 bit bitdepth but 4 bit, if you loose 2 bits then you loose half of range.

[pandy71]

Originally Posted by Thomas Richter

No digital silicon. Analog. Resistor ladders, same stuff as used for the video DAC right now.

You need active conversion, so circuit will be more complicated and costly - choosing RGB was very good choice from CBM business perspective and from consumer perspective. Ubiquity of HAM can't justify something else and still how HAM looks with YUV-like color space can be done today by using YPbPr to RGB converter and some python script to produce HAM-fakeRGB images.

Originally Posted by Thomas Richter

I don't propose to deal with them in silicon at all. This is all analog, and shifting a signal = adding a DC offset - is the easiest thing in the world.

Not in mass production especially if you use capacitors to remove DC bias from other components - take A1000 schematic and check antialiasing filter - there is plenty of inductance's there - they are magically vanished from A500/A2000 and higher models - why? due of cost - they where better but more complex and higher cost.

Originally Posted by Thomas Richter

But hey, even in silicon, that's four 8-bit adders - that's it. Adding signed or unsigned does not make a difference in two's complement representation, and a constant shift is just connecting wires correctly.

https://uber-leet.com/HistoryOfTheAmiga/

Yeep, this guy can't wait to add bunch of 8 bit TTL (4x8bit adders means at least 8x 74283 - not even sure if 283 exist in 1982 so perhaps they will be forced to use 8x 7483 combined with 4x 74182)...

Originally Posted by Thomas Richter

Have you actually read the BT.601 specs? It's 422, really. But this is really a separate question. You need subsampling or bandwidth lmitations if you modulate the signal on a carrier, such as for FBAS or composite. If the chips output YUV natively, and you convert the output to RGB externally in analog, there is no bandwidth limit.

Amiga is not BT.601 compliant and bandwidth for UV/IQ is way lower than YCbCr - trying to use naming from BT.601 in YUV have no sense you can also write 4:1:4 or- it will have same sense in Amiga...
Once again - using inferior and artificial color space have no sense then and today - having something like YUV would be nice but as additional feature that can be active on demand - however RGB shall be basic and primary color space.

Originally Posted by Thomas Richter

Look, I'm not sure what you are arguing about. The primary color space that is used scientifically isn't RGB either, it's XYZ, yet I'm not proposing to use that for encoding, and whether a model is additive or not does not limit its applicability as internal representation.

I know what is my position - from my perspective RGB was right choice since 1 day - and i don't see any sane - engineering argument contradictory to Amiga design team choice.
What is yours, not sure...

Originally Posted by Thomas Richter

No, wait. Confusion here. I'm not saying that a "component output" would have been better quality wise. CBM switched to RGB for simplicity and better quality, that's all fine. All I'm saying is that it would have been fine to continue the chips operating in YUV, and perform a YUV->RGB conversion externally, which would have improved HAM, and that you would not need to accept a quality drop.

But using RGB color space give us 4096 colors (insufficient as even 2^24 is insufficient to prevent banding), internal YUV converted externally means less colors than 4096 available in display.

Originally Posted by Thomas Richter

Yes, CBM didn't select that option, we know. It's all too late, it's completely academic, all I'm saying is that it is feasible without much overhead.

nope, i intend to build firstly such video DAC capable to do conversion and later perhaps Denise replacement - having YCoCg supported in Amiga at the HW level give opportunity to support MPEG/H.264 native color so avoiding costly in software conversion to RGB.

[Gorf]

Originally Posted by pandy71

Shifts from 4 bit to? Divide 4 bits by 4 and how many bits left?
There is no 8 bit bitdepth but 4 bit, if you loose 2 bits then you loose half of range.

Look at the calculation Thomas provided - there you will find a division by four, which is a shift by two - or on transistor level just connecting the right wires.

(Again: this is if you would do it digitally, which would probably not be the way it would have been done …)

[Gorf]

Originally Posted by pandy71

Yeep, this guy can't wait to add bunch of 8 bit TTL (4x8bit adders means at least 8x 74283 - not even sure if 283 exist in 1982 so perhaps they will be forced to use 8x 7483 combined with 4x 74182)...

Probably as they just could not wait to change their already working YUV based design to RGB when Commodore took over …

[pandy71]

Originally Posted by Gorf

Look at the calculation Thomas provided - there you will find a division by four, which is a shift by two - or on transistor level just connecting the right wires.

(Again: this is if you would do it digitally, which would probably not be the way it would have been done …)

I know what is proposed by Thomas, even provided results for maximum values and 2 bits removed from 4 bits mean half of the colors lost...
How difficult is to understand that something coded in software with plenty of bits, perhaps even floats will not work such simple in limited HW.
You have 4 bits per Y, 4 bits per U, 4 bits per V - you shifting 2 bits and you have only 2 bits left - you don't have 8 bit to loose 2 and keep 6.
Increasing bitdepth to improve accuracy will be anyway costly and inefficient as you can dedicate this HW for 5 bit RGB so instead 2^12 color space you will have 2^15 space but still you need 3 more pins for this so you no longer use CERDIP 48 but you need to use CERDIP 52 and your fab machines may not have such possibility so you need to put this in PLCC but not sure if in 1985 they could use PLCC as Agnus is 48 pin CERDIP.

Originally Posted by Gorf

Probably as they just could not wait to change their already working YUV based design to RGB when Commodore took over …

Please allow me to address your concerns by quoting Jay Miner (excuse for poor OCR from Byte 1985/11 - not my work) - 36 years ago Jay says:

DIGITAL RGB, ANALOG
RGB, AND NTSC
BYTE: When you put out RGB |red-green-
blue| data. how does it come out?
Miner: It comes out as 4 bits. 4 bits.
and 4 bits.
BYTE: And that's how RGB monitors nor-
mally take their information?
Miner: Off chip it goes into a ladder.
There are three groups of 4 bits com-
ing right out of the 3 2 color registers.
and then there's a four-resistor ladder
on each one of those that converts it
into three analog values. That's what
goes to the monitors.
BYTE: Then the values of that analog
data-which you've changed from the digital
data-determine how strong each of the RGB
guns is when it's firing at a particular
point?
Miner: Yes. on the so-called analog
RGB. There are two kinds of RGB:
digital and analog. This is important
to stress because IBM talks about 16
colors. but what IBM really means is
two shades of eight colors. and those
two shades are always the same color.
There's no way to change them. That's
what's called digital RGB. or RGBi. It's
got red on and off. it's got green on
and off. it's got blue on and off. and
it's got an intensity level that deter-
mines brightness or darkness for each
one of those. It's a four-wire control.
but it's completely digital. We put that
out too. in order to be compatible. but
we also put out the analog RGB. which
has 4 bits. 4 bits. and 4 bits. into lad-
ders. so you get 16 values of red. 16
values of green. and 16 values of blue.
It's equivalent to 2^12 total colors and
luminances~
BYTE: So on the analog output. you could
have any number of bits that you wanted?
You could put out I 0 bits on each line?
178
BYTE • NOVEMBER 1985
AMIGA'S CUSlDM CHIPS
Miner: Yes. if you had big enough
registers. In fact. that's probably one
of the things we'll be expanding in the
future chip set.
BYTE: Why did you choose 4 bits in the first
place?
Miner: Originally. this wasn't going to
be RGB; it was going to follow the
NTSC !National Tulevision System
Committee! standard. NTSC works on
intensity. hue. and saturation. Color
and luminance. YIO is what they call
it. The Y is the intensity. and the I and
the 0 define a vector that determines
the saturation. Having 4 bits of each
was about the best we could tackle in
terms of having on-chip ladders that
would take the 4 bits for each one of
these and convert them into an actual
phase angle.
BYTE: So that ladder is on Denise?
Miner: No. it was when we had the
YIO; when we were emphasizing
NTSC. we had a ladder on board.
Then we deemphasized it. We found
a Motorola chip that did a good job
of converting RGB into NTSC. We
needed the extra room on the Denise
chip for extra resolution on the color
registers. so we dropped the YIO
NTSC completely. But we've still stuck
with the 4. 4. 4 bits. Also. you've got
a real pin limitation on a chip like this.
We tried to keep the chip simple and
low-cost to manufacture. and on-chip
ladders take up a lot of area. They're
notoriously inaccurate. and you can
buy I percent resistors external for a
penny apiece.
BYTE: Is there still NTSC output from the
Amiga?
Miner: In the box there is. yes. But not
in the chips.

[grond]

Just one comment on the 16bit audio discussion. With 16 bit audio resolution the LSB represents some tens of microvolts. I doubt this would have been feasible even with dedicated analogue MOS processes of the time and delta-sigma-modulation. You wouldn't get anywhere near that with the poor power supply and lousy transistors with low output resistance. You just wouldn't get the required power-supply rejection ratio.

[Thomas Richter]

Originally Posted by pandy71

I know what is proposed by Thomas, even provided results for maximum values and 2 bits removed from 4 bits mean half of the colors lost...

Nothing is lost. Just to note that again: This is a LOSSLESS transformation. For 8 bit RGB, you need 8 bit Y, 9 bit Cb and 9 bit Cr. (8 bit plus sign). Yes, really.