14 November 2021, 18:42 | #661 | ||
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,426
|
[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. Quote:
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 Quote:
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 ... Last edited by Gorf; 14 November 2021 at 22:22. |
||
14 November 2021, 19:38 | #662 | ||||||
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,875
|
Quote:
Quote:
Quote:
Code:
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. Quote:
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). Quote:
Quote:
Neat and simple and with small amount of additional HW you may have Panning implemented in same way. |
||||||
14 November 2021, 19:50 | #663 | ||||
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,426
|
Quote:
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. Quote:
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. Quote:
Again, nothing I wrote indicates the need for faster RAM ... Quote:
|
||||
14 November 2021, 20:13 | #664 | |||
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,875
|
Quote:
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. Quote:
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). Quote:
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. Please elaborate on this. |
|||
14 November 2021, 21:23 | #665 | ||||
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,719
|
Quote:
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. Quote:
Quote:
Quote:
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. |
||||
14 November 2021, 21:24 | #666 | |||||||
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,426
|
Quote:
And as mentioned before you would adjust the gamut of the colour space accordingly. This is not a real world problem Quote:
Quote:
Quote:
This would give us 16-bit range if we combine 2 channels Quote:
Quote:
Quote:
You can do duplicate a channel easily and do 4x mixing .. that would give you 0 ..25%..50%…75% 100% panning Last edited by Gorf; 14 November 2021 at 21:48. |
|||||||
14 November 2021, 21:46 | #667 | |
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,426
|
Quote:
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…. Last edited by Gorf; 14 November 2021 at 22:27. |
|
14 November 2021, 22:04 | #668 | |||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,307
|
Yes, I can. It's really quite trivial.
Code:
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); } Quote:
Quote:
From BT.601: Quote:
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. |
|||
14 November 2021, 22:06 | #669 | ||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,307
|
Quote:
Quote:
|
||
15 November 2021, 07:40 | #670 | |
Registered User
Join Date: Dec 2014
Location: germany
Posts: 439
|
Quote:
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. |
|
15 November 2021, 09:37 | #671 | ||||||
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,719
|
Quote:
Quote:
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). Quote:
Quote:
Quote:
Quote:
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. |
||||||
15 November 2021, 09:53 | #672 | |
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,719
|
Quote:
|
|
15 November 2021, 10:33 | #673 |
cheeky scoundrel
Join Date: Nov 2004
Location: Spijkenisse/Netherlands
Age: 42
Posts: 6,972
|
Ugh. There is such a thing as too green.
|
15 November 2021, 11:43 | #674 |
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,719
|
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!" |
15 November 2021, 17:41 | #675 | ||||||||
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,426
|
Quote:
Quote:
Quote:
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? Quote:
Quote:
one only affecting Y (darker shade of same colour) one affecting U and Y (different colour of same brightness) Quote:
Amber is agnostic to the colour-format anyways: it just stores 12bit values and does not care if there are RGB or YUV. Quote:
Quote:
But at the same time it would have been even better suited to video production as it actually was. |
||||||||
15 November 2021, 20:46 | #676 | ||
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,875
|
Quote:
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. Well Mary was prepared and as such new register appears in DFF space. Quote:
Well, then current Paula 8 bit seem to be nice balance between time and cost. How different? there is transfer from place A to place B - so what kind of different DMA you propose? 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... |
||
15 November 2021, 20:58 | #677 |
Commodore Collector
Join Date: Aug 2001
Location: Austria
Age: 53
Posts: 944
|
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. |
15 November 2021, 21:12 | #678 |
Bit Copying Bard
Join Date: Jan 2017
Location: Kelty, Fife, Scotland
Age: 41
Posts: 1,293
|
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.
|
15 November 2021, 21:25 | #679 | |||
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,875
|
Quote:
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? Quote:
Quote:
|
|||
15 November 2021, 21:37 | #680 | |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,875
|
Quote:
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). |
|
Currently Active Users Viewing This Thread: 2 (0 members and 2 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Non-Amiga things that remind you of Amiga things? | Fingerlickin_B | Retrogaming General Discussion | 1056 | Yesterday 08:36 |
wanting to experiment, using Amiga (emulator) as my day to day machine, need advice | mmace | New to Emulation or Amiga scene | 14 | 19 March 2020 11:32 |
Why game companies didn't make better games for Amiga | ancalimon | Retrogaming General Discussion | 35 | 17 July 2017 12:27 |
New Year Day = throw CD32 in the dishwasher day | Paul_s | Hardware mods | 16 | 03 January 2009 19:45 |
Amazing things you've done with your Amiga | mr_a500 | Amiga scene | 67 | 05 July 2007 19:45 |
|
|