Things the Amiga didn't get right from Day 1

[Gorf]

[QUOTE=pandy71;1516927]Only with some limitations - YUV and RGB sharing limited color range, check picture bellow:


As it states in this picture: everything too far away from the RGB-space can not be displayed anyways ... and the eye would not be able to see it, because it is beyond our range.
So nobody would choose such a color in the first place.

What is missing in this picture here is, that these cubes are not fixed in size.
It depends on the gamut...


And its not like the Amiga colour-space is covering sRGB!
So we already have restrictions on what colours the Amiga can display, as it is.
And any dark colors are more or less indistinguishable....

I understand, what you are trying to say here:
Using YUV would waste datapoints ... so roughly half of our 12bit range would end up in nirvana, because it can not be displayed ...

But I would argue: this depends on what gamut we are talking about and what specific YUV representation we choose. We surely could find a sweet-spot here, and providing no worse color resolution as we have now.

We not talking about listening range, we talking about possible Paula audio generation methods - check HRM where this is explicitly mentioned.

No we are not.
OK, maybe you are, but I was not ... so we are just not talking about the same thing here.

How Paula works now and what the HRM describes is irrelevant to my argument, since I suggested to use a totally different approach for a sound chip:
- not longer dependent on the gfx-chips and Agnus.
- using independent DMA together with disk, serial, parallel and MIDI
- sigma-delta based DAC

Yes, you can adjust PCM level by multiplying samples in real time and what happen when you lower 8 bit by 28dB? how many bits remains?

You could easily expand a 8-bit value from your sample to 12 or 16 bits internally and do only shifting to adjust volume, before you enter the upsampling steps.

Or you use more ore less the same method Paula is using now AFTER the first oversampling step where you now have, lets say, 4-bit values at a much higher frequency: now you can periodically set values to zero zu lower the volume ...

[pandy71]

Originally Posted by Gorf

As it states in this picture: everything too far away from the RGB-space can not be displayed anyways ... and the eye would not be able to see it, because it is beyond our range.
So nobody would choose such a color in the first place.

What is missing in this picture here is, that these cubes are not fixed in size.
It depends on the gamut...


And its not like the Amiga color-space is covering sRGB!
So we already have restrictions on what colors the Amiga can display, as it is.
And any dark colors are more or less indistinguishable....

Issue is that YUV converted to RGB will provide negative light values - something against physics and it must be dealt at the HW level before being feed externally... this is only complication without any benefit as there is no display capable to accommodate directly YUV like signal (yes, exception are some broadcast monitors capable to accommodate Y, B-Y, R-Y signal - this is niche professional not consumer market)

Originally Posted by Gorf

I understand, what you are trying to say here:
Using YUV would waste datapoints ... so roughly half of our 12bit range would end up in nirvana, because it can not be displayed ...

Bit I would argue: this depends on what gamut we are talking about and what specific YUV representation we choose. We surely could find a sweet-spot here, and providing no worse color resolution as we have now.

Perhaps we could find color space where loss will be minimized but still loss is unavoidable and having on mind that each CRT use RGB natively then choosing RGB as native Amiga color space was sane, reasonable, justified choice. Every modern graphic hardware took same approach - RGB is native with some enhancements possible...

Originally Posted by Gorf

No we are not.
OK, maybe you are, but I was not ... so we are just not talking about the same thing here.

http://amigadev.elowar.com/read/ADCD.../node00F2.html

If the sampling rate is set much higher than the normal maximum sampling rate (approximately 29 KHz), the two samples in the buffer register will be repeated. If the  filter  on the Amiga is bypassed and the  volume  is set to the maximum ($40), this feature can be used to make modulated carriers up to 1.79 MHz. The modulation is placed in the memory map, with plus values in the even bytes and minus values in the odd bytes.

Originally Posted by Gorf

How Paula works now and haw the HRM describes is irrelevant to my argument, since I suggested to use a totally different approach for a sound chip:
- not longer dependent on the gfx-chips and Agnus.
- using independent DMA together with disk, serial, parallel and MIDI
- sigma-delta based DAC

Then from my perspective this is wrong thread as my assumption based on thread title is "things that could be done right from day 1" i.e. with technology present in first half of the 80's and at the same time having on mind limited time and budget.

More DMA cycles means faster memory that didn't existed then - it is quite easy to say bump number of the DMA cycles but it can't ignore DRAM technology limitations present when Amiga was designed...
And DS DAC is not miracle... way more interesting from possible usage scenarios would be time shared DAC (one per Left and second for Right) as in theory this could give chance to twice sample rate audio and at the same time significantly reduce Paula silicone area i.e. perhaps possibility to introduce serial FIFO and/or some audio enhancements...
Same for time shared NCO (even 16 bit NCO will give audio frequency uniform 54Hz frequency resolution).

Originally Posted by Gorf

You could easily expand a 8-bit value from your sample to 12 or 16 bits internally and do only shifting to adjust volume, before you enter the decimation steps.

This will made more complex circuitry without any benefit when compared to already existing one.

Originally Posted by Gorf

Or you use more ore less the same method Paula is using now AFTER the first oversampling step where you now have, lets say, 4-bit values at a much higher frequency: now you can periodically set values to zero zu lower the volume ...

Yes, i've proposed 4066 switch controlled trough PWM at the analog (after DAC and reconstruction filter) side but isn't simpler to control PWM in digital domain by clocking register that holds data before monolithic DAC.
Neat and simple and with small amount of additional HW you may have Panning implemented in same way.

[Gorf]

Originally Posted by pandy71

Issue is that YUV converted to RGB will provide negative light values

No it won't.
Such conversions are done all the time. Every video-codec we daily use stores the picture information in some form of YUV representation and your computer decodes ist transform it to RGB und displays it perfectly fine on your RGB monitor.

Then from my perspective this is wrong thread as my assumption based on thread title is "things that could be done right from day 1" i.e. with technology present in first half of the 80's and at the same time having on mind limited time and budget.

My argument is that the sigma-delta approach is doable with the technology at hand in the mit 80s and was done even before that time.
It is an elegant way that saves complexity at the analog end and would have provided even better sound.

This is certainly not a "must have" or a mistake, but just some missed opportunity.

More DMA cycles means faster memory that didn't existed then - it is quite easy to say bump number of the DMA cycles but it can't ignore DRAM technology limitations present when Amiga was designed...

??
Again, nothing I wrote indicates the need for faster RAM ...

Yes, i've proposed 4066 switch controlled trough PWM at the analog (after DAC and reconstruction filter) side but isn't simpler to control PWM in digital domain by clocking register that holds data before monolithic DAC.
Neat and simple and with small amount of additional HW you may have Panning implemented in same way.

Panning or channel mixing ist very easy with bitstreams ....

[pandy71]

Originally Posted by Gorf

No it won't.
Such conversions are done all the time. Every video-codec we daily use stores the picture information in some form of YUV representation and your computer decodes ist transform it to RGB und displays it perfectly fine on your RGB monitor.

Of course and they are LOSSY YCbCr<>RGB is always lossy conversion.
And we not discuss on YUV where RGB is source but about case where YUV is synthetic and as such not derived from RGB - this is place where all colors not possible to display in RGB space are born.

Originally Posted by Gorf

My argument is that the sigma-delta approach is doable with the technology at hand in the mit 80s and was done even before that time.
It is an elegant way that saves complexity at the analog end and would have provided even better sound.

Nope, DS DAC will increase complexity and will not give any added value for Amiga. It could be option if 16 bit Paula was ever designed.
Besides PWM volume control is very similar to DS - perhaps 6 bit volume control DS modulator could be even simpler to design than 6 bit PWM (less logic/resources).

Originally Posted by Gorf

This is certainly not a "must have" or a mistake, but just some missed opportunity.

8 bit monolithic DAC was available from shelf at the prototype stage and feasible in silicone level - you could provide 16 bit using hybrid DAC, 8 bit from DS modulator and 8 bit from DAC but still assumption is 16 bit audio is goal but reality is simple - small RAM prefer 8 bit than 16 bit and Fairlight CMI is 8 bit sample depth - so Amiga natively outperformed musical synthesizer that cost 10 times more.

Originally Posted by Gorf

??
Again, nothing I wrote indicates the need for faster RAM ...

This is direct outcome for more DMA cycles in computers with unified memory architecture - anyway all memory cycles are eaten by graphics in hires 4 BPL mode - unless you provide faster memory by increasing clock and reducing access cycle alternatively you may try to increase available bandwidth by introducing memory interleaving and by increasing word size but this work only with assumption of linear access (something like FPM or Nibble also work unless you stay on same page or doing burst access).
remember in first half of 80's typical DRAM has 250ns cycle i.e. Amiga using 280ns cycle fit in this, you could reduce cycle to for example 140ns but your memory must be something like 125ns cycle - IIRC such access time was available around 1985. Anyway every technique to make faster RAM will lead to increased cost and Amiga will not cost like 2500$ but rather 4000$ or more.

Originally Posted by Gorf

Panning or channel mixing ist very easy with bitstreams ....

Please elaborate on this.

[Bruce Abbott]

Originally Posted by Gorf

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

If Denise's output was YUV it would need to be converted to RGB for use with high quality monitors. The analog circuit required is not trivial, and would have been an extra expense that was not needed for normal screen modes.

And it have made no difference to the quality of composite and s-video because conversion suffers the same degradation as RGB. The only thing it might be better for is YPbPr Component, but that wasn't a thing in 1985. No TVs or monitors had (or ever would have) YUV inputs, so it would require extra conversion circuitry for everything except feeding into a composite/s-video encoder chip that accepted YUV inputs.

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 strange. Analog RGB was the coming standard for professional computer systems. If the Amiga 1000 had YUV video out instead of RGB it would be yet another thing people complained about (and rightly so).

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

Early monitors without RGB were either monochrome (which the A500 and A2000 directly supported), or composite / s-video with low resolution TV screens (eg. Commodore 1802). The Amiga 1000 required higher resolution color, and RGB was the obvious way to get it.

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.

This discussion about color spaces, digital video formats and shading etc. is off topic. The only reason YUV was used in computers in 1985 was that broadcast TV used it, and not because it was superior as far as image quality was concerned. It was simply a way to shoehorn color into the existing TV signal in a way that was compatible with old monochrome TVs - a horrible compromise that computers shouldn't have to be limited by.

Note too that converting YUV to NTSC/PAL and back was not trivial. TVs had quite complex and sensitive circuits to do the job, and result was not great. In later years methods of 'enhancing' the picture were developed, using ever more complex and expensive analog chips until eventually giving way to digital techniques. But this was always putting lipstick on a pig.

[Gorf]

Originally Posted by pandy71

Of course and they are LOSSY YCbCr<>RGB is always lossy conversion.
And we not discuss on YUV where RGB is source but about case where YUV is synthetic and as such not derived from RGB - this is place where all colors not possible to display in RGB space are born.

Nobody would choose a colour for a palette, that can not be displayed.
And as mentioned before you would adjust the gamut of the colour space accordingly.
This is not a real world problem

Nope, DS DAC will increase complexity

Not really

and will not give any added value for Amiga. It could be option if 16 bit Paula was ever designed.

well, we are talking about things, that did not happen

Besides PWM volume control is very similar to DS - perhaps 6 bit volume control DS modulator could be even simpler to design than 6 bit PWM (less logic/resources).

You could go full 8bit here.
This would give us 16-bit range if we combine 2 channels

8 bit monolithic DAC was available from shelf at the prototype stage and feasible in silicone level - you could provide 16 bit using hybrid DAC, 8 bit from DS modulator and 8 bit from DAC but still assumption is 16 bit audio is goal

Actually I never said 16-bit per channel should be the goal

This is direct outcome for more DMA cycles in computers with unified memory architecture

I never said anything about more DMA cycles - just different ones.

Please elaborate on this.

Mixing two bitstreams is just a 1-bit adder and a 2-bit latch.
You can do duplicate a channel easily and do 4x mixing .. that would give you 0 ..25%..50%…75% 100% panning

[Gorf]

Originally Posted by Bruce Abbott

Early monitors without RGB were either monochrome (which the A500 and A2000 directly supported), or composite / s-video with low resolution TV screens (eg. Commodore 1802). The Amiga 1000 required higher resolution color, and RGB was the obvious way to get it.

The A1000 as all OCS Amiga does not provide higher resolutions. (Which was also a missed opportunity)

Composite / S-Video are much closer to YUV as to RGB, so a S-Video signal derived from YUV is likely to have better quality than a signal stemming from RGB.

For monitors with RGB input a high quality RGB signal would have been created from Denise’s YUV output.

So the A1000 would still give you all connections you want, but the composite output would likely be better, HAM would be more useful
And even EHB could provide different colors this way and would be more useful.

Video processing equipment would benefit from digital YUV signal lines of the internal video slot….

[Thomas Richter]

Originally Posted by pandy71

Nope - you can't

Yes, I can. It's really quite trivial.

void rct_pixel(rct_t r,rct_t g,rct_t b,rct_t* y, rct_t* cb, rct_t* cr)
{
        *y = (rct_t) (r+2*g+b)>>2;
        *cb = (rct_t) b-g; 
        *cr = (rct_t) r-g;
}

void irct_pixel(rct_t y, rct_t cb, rct_t cr,rct_t* r,rct_t* g,rct_t* b)
{
        *g = (rct_t) (y-((cb+cr)>>2));
        *r = (rct_t) (*g + cr);
        *b = (rct_t) (*g + cb);
}

It is *really* that simple.

Originally Posted by pandy71

So technically you need introduce higher bitdepth and saturation arithmetic i.e. build some typical DSP function in video path...

As I said, the dynamic range of chroma extends by 1 bit. Which is expected as the chroma signal it is a color-difference signal. The difference of two 8-bit numbers is 9-bit, -255 to 255. It does not matter much in the inverse direction - the chroma resolution does not matter too much in first place. You loose one bit in precision then, who cares, you don't see chroma that precise in first place.

Originally Posted by pandy71

A:B:C notation is obviously impossible but we can try to calculate luma/chroma relation based on or BT.601 sampling frequency and/or Amiga sampling frequency

From BT.601:

Sampling frequency:–luminance signal–each colour-difference signal

13.5 MHz6.75 MHz

Guess what. Half the bandwidth, half the resolution. It's 422 sampled.

Originally Posted by pandy71

Btw there is nothing wrong to think on "YUV" in Amiga as 4:4:4 i.e. same resolution/bandwidth for all components.

No, of course that would have been a possibility, but the whole point was that YUV is the "natural" color system for broadcast TV, which is something the Amiga was originally considered to output, and that is 422 subsampled in NTSC land, and even 420 in PAL land.

[Thomas Richter]

Originally Posted by chb

You're mixing up some things here. 422 or 420 color subsampling is perfect for the absolute majority of text output.

That depends on whether the text has the same color as the background, obviously.

Originally Posted by chb

Well, as said, that's not the issue here. Analogue NTSC TV btw. is not 422 subsampled (as pandy said, that is for digital), but bandwidth limited, and as the I and Q components have different bandwidths, it's even not possible to describe it in terms of the A:B:C notation.

That depends a bit on the color system, and its clearly an approximation, but close enough to describe where the problem comes from, and why it has been avoided in the final design.

[chb]

Originally Posted by Thomas Richter

That depends on whether the text has the same color as the background, obviously.

Yes, obviously. But as I wrote, in real life text mostly has the same chroma value as the background (black on white, white on black, black on gray, even green or amber or whatever color on black, as black can have every chroma value) and can be perfectly displayed with 4:2:2 or 4:2:0. Chroma subsampling is simply almost always not the reason why text looks blurry via composite.

Originally Posted by Thomas Richter

That depends a bit on the color system, and its clearly an approximation, but close enough to describe where the problem comes from, and why it has been avoided in the final design.

No, again, the main problem stems from the limitations of FBAS/composite, and those are just in for a small part coming from 4:2:2 or 4:2:0 like chroma subsampling. The luma bandwidth is limited, because the color signal is transmitted on the same line via mixing with the color carrier. S-Video has limitations that are close to chroma subsampling, and that would have been a quite usable YUV-like output (inferior to RGB ofc), but wasn't very widespread in consumer hardware.

[Bruce Abbott]

Originally Posted by Gorf

The A1000 as all OCS Amiga does not provide higher resolutions. (Which was also a missed opportunity)

OCS 'high' resolution is higher than composite is capable of displaying sharply.

Composite / S-Video are much closer to YUV as to RGB, so a S-Video signal derived from YUV is likely to have better quality than a signal stemming from RGB.

Converting from RGB to YUV is relatively easy to do without significant loss of 'quality'. It just needs some precision resistors and video buffer amps with sufficient bandwidth.

The conversion from YUV to luminance/chrominance and composite is a different story. The UV signals have to phase modulate the color subcarrier, with limited bandwidth. This introduces a delay which shifts the color signal to the right on-screen relative to the luma signal. To get them back into alignment the luma signal is passed through a delay line, which in 1985 was an analog circuit consisting of a series of coils and capacitors. The delay line reduces the luma bandwidth and introduces those ringing and 'ghosting' artifacts that we are all familiar with. Some home computers didn't bother with one, and suffered massive color 'bleeding' (which can produce some interesting effects, but is otherwise very annoying and looks terrible).

For monitors with RGB input a high quality RGB signal would have been created from Denise’s YUV output.

All high quality monitors had RGB input, so this conversion would have been essential, requiring precision circuitry that would unnecessarily raise the cost - all just to support a single screen mode that used YUV instead of HAM.

So the A1000 would still give you all connections you want, but the composite output would likely be better,

No, it wouldn't.

HAM would be more useful
And even EHB could provide different colors this way and would be more useful.

Perhaps, but EHB was another cheap 'hack' that required almost no silicon to implement. Doing EHB in YUV might have been even simpler, but the result would be similar (darker colors with no independent control over their palette).

Video processing equipment would benefit from digital YUV signal lines of the internal video slot….

But flicker fixers would have to convert from YUV to RGB, making them more complex and expensive. I'm betting that market was more price-sensitive, as well as being more important to the Amiga's survival.

We can go on about the theoretical advantages of YUV over RGB, but the fact is that if the Amiga had used YUV it would have been an outlier. The industry was settling on RGB to the point where even gaming consoles like the Sega Megadrive, Super Nintendo and Sony Playstation outputted it, and many others used RGB internally. And when we look at where the Amiga was heading (RTG), YUV would have been yet another impediment. In hindsight it is clear that RGB was the right way to go, just like we thought it was the time.

[Bruce Abbott]

Originally Posted by chb

Yes, obviously. But as I wrote, in real life text mostly has the same chroma value as the background (black on white, white on black, black on gray, even green or amber or whatever color on black, as black can have every chroma value) and can be perfectly displayed with 4:2:2 or 4:2:0. Chroma subsampling is simply almost always not the reason why text looks blurry via composite.

If only that was true. Those of us who were forced to use composite tried to make it so as much as possible, but in RGB land it was common to see different colors used. The attached screenshot - from a form layout package that was produced for various platforms including the IBM PC and Amiga - is a particularly egregious example. One wonders what the person who designed it was smoking...

[gimbal]

Ugh. There is such a thing as too green.

[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!"

[Gorf]

Originally Posted by Bruce Abbott

OCS 'high' resolution is higher than composite is capable of displaying sharply.

Converting from RGB to YUV is relatively easy to do without significant loss of 'quality'. It just needs some precision resistors and video buffer amps with sufficient bandwidth.

same is true for the other way around.

The conversion from YUV to luminance/chrominance and composite is a different story. The UV signals have to phase modulate the color subcarrier, with limited bandwidth. ....

This is even worse on RGB to luminance/chrominance

All high quality monitors had RGB input, so this conversion would have been essential, requiring precision circuitry that would unnecessarily raise the cost - all just to support a single screen mode that used YUV instead of HAM.

I fail to see your argument here.

We have already established that a high quality transformation from RGB tor YUV or from YUV to RTB is no problem.

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?

No, it wouldn't.

Yes, it would

Perhaps, but EHB was another cheap 'hack' that required almost no silicon to implement. Doing EHB in YUV might have been even simpler, but the result would be similar (darker colors with no independent control over their palette).

It you e.g. only shift U and/or Y, you get a different tone - 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)

But flicker fixers would have to convert from YUV to RGB, making them more complex and expensive.

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.

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

I'm betting that market was more price-sensitive, as well as being more important to the Amiga's survival.

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

We can go on about the theoretical advantages of YUV over RGB, but the fact is that if the Amiga had used YUV it would have been an outlier.

Why? It would have had a good RGB output as well.

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

[pandy71]

Originally Posted by Gorf

Nobody would choose a colour for a palette, that can not be displayed.
And as mentioned before you would adjust the gamut of the colour space accordingly.
This is not a real world problem

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

Originally Posted by Gorf

Not really

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.

Originally Posted by Gorf

well, we are talking about things, that did not happen

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

Originally Posted by Gorf

You could go full 8bit here.
This would give us 16-bit range if we combine 2 channels

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.

Originally Posted by Gorf

Actually I never said 16-bit per channel should be the goal

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

Originally Posted by Gorf

I never said anything about more DMA cycles - just different ones.

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

Originally Posted by Gorf

Mixing two bitstreams is just a 1-bit adder and a 2-bit latch.
You can do duplicate a channel easily and do 4x mixing .. that would give you 0 ..25%..50%…75% 100% panning

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...

[Overdoc]

Very interesting discussions about whether RGB or YUV would have been a better choice.
And I am quite impressed about all the technical knowlege of most of you guys.

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?!
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?!

While the Amiga 1000 was marketed as a groundbreaking new computer for experts, with monitor and separate keyboard, the Amiga 500 was already marketed as an all-in-one computer for the broad public, and ofcourse also for gamers.

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....

In contrary to the A-1000 or 2000, the A-500's case was not even designed to put a monitor on top of it, and for playing games a monitor with brilliant sharp RGB input was simply way too expensive and not needed at all - CVBS to TV is completely sufficient for most games.

But instead of providing this needed coloured Cinch video output, they made us buy that ugly A-520 modulator, which was a wobbly thing, often fell out, etc.

At least they did it right in the end with the A-600, 1200 and CD32.
So this is not a thing done not right from the start, but something not done right for the Amiga-500 like it was marketed.

Ofcourse it would have made the Amiga 500 slightly more expensive, but certainly cheaper than when you had to buy that A-520 for extra costs.

[indigolemon]

Oddly, that was never a problem in the UK. All 500's were shipped with an A520 in the box - definitely a good move by Commodore UK.

[pandy71]

Originally Posted by Thomas Richter

Yes, I can. It's really quite trivial.

void rct_pixel(rct_t r,rct_t g,rct_t b,rct_t* y, rct_t* cb, rct_t* cr)
{
        *y = (rct_t) (r+2*g+b)>>2;
        *cb = (rct_t) b-g; 
        *cr = (rct_t) r-g;
}

void irct_pixel(rct_t y, rct_t cb, rct_t cr,rct_t* r,rct_t* g,rct_t* b)
{
        *g = (rct_t) (y-((cb+cr)>>2));
        *r = (rct_t) (*g + cr);
        *b = (rct_t) (*g + cb);
}

It is *really* that simple.

As I said, the dynamic range of chroma extends by 1 bit. Which is expected as the chroma signal it is a color-difference signal. The difference of two 8-bit numbers is 9-bit, -255 to 255. It does not matter much in the inverse direction - the chroma resolution does not matter too much in first place. You loose one bit in precision then, who cares, you don't see chroma that precise in first place.

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)...
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?

Originally Posted by Thomas Richter

From BT.601:
Guess what. Half the bandwidth, half the resolution. It's 422 sampled.

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

Originally Posted by Thomas Richter

No, of course that would have been a possibility, but the whole point was that YUV is the "natural" color system for broadcast TV, which is something the Amiga was originally considered to output, and that is 422 subsampled in NTSC land, and even 420 in PAL land.

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... there is plenty of compromises there and seem your idea is to have something with quality of the S-Video VCR at best... luckily to us this not happened and still if someone wish to verify how HAM will work with "YUV" space then YPbPr converter can be used to convert YUV embedded to RGB in current Amiga - just code image in software as fake RGB HAM and then convert such YUV to RGB in analog domain and verify results on display with RGB - this can be done today - there is neat IC https://www.ti.com/product/LMH1251 to do such thing and you can nicely switch between RGB and YPbPr (for example ZD pin so with pixel accuracy).

[pandy71]

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?!
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?!

Ofcourse it would have made the Amiga 500 slightly more expensive, but certainly cheaper than when you had to buy that A-520 for extra costs.

From my perspective what you say is quite true, and yes, for some time i've used grayscale RCA video as Amiga to SCART cable was not easily available in my country and if available then pretty expensive - at some point i've made my own cable using DB25 plug (and yes. i've made DB23 plug from DB25 as DB23 was also not available easily).
Quite important info is that this monochrome output offered 4096 gray levels.

And lack of color composite in A500 can be explained by fact that A500 was cost reduction and if you produce million computers then each 1$ saved is your 1 million $ profit and you can even increase profit by selling A520 (it was quite popular) so i bet that from Commodore perspective this was proper business strategy (they profit was probably over 20 million $... only because A500 have no color composite video out).