Altirra 4.20 released

[ldelsarte]

6 hours ago, phaeron said:

This one I'm not sure about, as it effectively would just be patching the OS ROM. Probably would be better to have a ROM patching tool to create customized ROM images than to add a feature specifically for the character set.

I guess a "Plan B" would be to use a translator disk, to get a RAM version of the OS, then use DOS to LOAD a new character set, erasing the one in place?

[ldelsarte]

6 hours ago, phaeron said:

This would be possible, though it'd be emulating a pretty poor monitor. The only visibly long persistence monitor I've ever used was the Apple Monitor ///, and even that wasn't that visible.

Something like this, I suppose ?
YouTube, "CRT afterglow effect comparison": https://www.youtube.com/watch?v=UUpxkRlKosM

[_The Doctor__]

ah slow phosphors, I personally avoided models with them like the plague

[phaeron]

6 hours ago, ldelsarte said:

I guess a "Plan B" would be to use a translator disk, to get a RAM version of the OS, then use DOS to LOAD a new character set, erasing the one in place?

You could do that, but it'd be easier just to patch the OS ROM file and bind the modified version in Firmware Settings.

 

6 hours ago, ldelsarte said:

Something like this, I suppose ?
YouTube, "CRT afterglow effect comparison": https://www.youtube.com/watch?v=UUpxkRlKosM

The monitor on the right is horrendously slow, that's worse than any monitor I ever used. You could use it to run a radar or oscilloscope.

[serj]

Avery, I want to ask about a problem in the emulator.

It seems to me that the color palette settings in pal mode are incorrect.

the color goes too red.

I run the game "PreliminaryMonty" in the palette - Default pal and it is clear that there is too much red and purple in the image, this should not be so.

please fix it.

Edited May 10 by serj

[Kr0tki]

Indeed, hue $3x in the default PAL palette is a bit too pink when compared to real hardware. I believe this is related to the issue described below.

 

On 5/8/2024 at 8:02 AM, phaeron said:

As Kr0tki notes, the Hue Step slider is equivalent to the color pot. This includes the wonky behavior of the PAL GTIA encoder.

That's not strictly true. Adjusting Hue Step in Altirra does not change the hue of colours $1x, while it does on a real Atari; additionally, the real colour pot also modifies the resulting saturation of all colours. So Altirra's Hue Step is not equivalent to a PAL colour pot.

 

I guess Altirra computes hue $1x directly from the "Hue start" setting and then uses it as a reference point of sorts for all other hues. In comparison, Atari800's "GTIA delay" setting replicates the behaviour of the colour pot accurately. Atari800 decodes PAL colours like a real TV would - its computes the phases of the colourburst as generated by GTIA in even and odd lines, then uses them to recreate the colour subcarrier's frequency and amplitude, and then uses the subcarrier as a reference to all other colours. As a result, the "GTIA delay" setting replicates the changes in colour hues and saturations of the real hardware.

 

I have described the details in comments in Atari800 sources, in src/colours_pal.c.

Edited May 10 by Kr0tki

[phaeron]

20 hours ago, serj said:

Avery, I want to ask about a problem in the emulator.

It seems to me that the color palette settings in pal mode are incorrect.

the color goes too red.

I run the game "PreliminaryMonty" in the palette - Default pal and it is clear that there is too much red and purple in the image, this should not be so.

please fix it.

You can try loading these color settings, which were generated by the Palette Solver against one of Hias' PAL screenshots:

test.atcolors

 

But just a note, I'll need a bit more corroboration against hardware and more programs before changing the default color settings, to avoid another loop of "it doesn't match my hardware."

 

16 hours ago, Kr0tki said:

Indeed, hue $3x in the default PAL palette is a bit too pink when compared to real hardware. I believe this is related to the issue described below.

 

That's not strictly true. Adjusting Hue Step in Altirra does not change the hue of colours $1x, while it does on a real Atari; additionally, the real colour pot also modifies the resulting saturation of all colours. So Altirra's Hue Step is not equivalent to a PAL colour pot.

 

I guess Altirra computes hue $1x directly from the "Hue start" setting and then uses it as a reference point of sorts for all other hues. In comparison, Atari800's "GTIA delay" setting replicates the behaviour of the colour pot accurately. Atari800 decodes PAL colours like a real TV would - its computes the phases of the colourburst as generated by GTIA in even and odd lines, then uses them to recreate the colour subcarrier's frequency and amplitude, and then uses the subcarrier as a reference to all other colours. As a result, the "GTIA delay" setting replicates the changes in colour hues and saturations of the real hardware.

 

I have described the details in comments in Atari800 sources, in src/colours_pal.c.

I missed that it was referring to PAL above. In NTSC, the color pot definitely doesn't affect hue $1x; I don't have a PAL machine to verify against, but you're correct that the PAL generation logic in Altirra anchors $1x to hue start, though it does emulate the other PAL quirks. I wrote that under the assumption that the PAL receiver syncs to each colorburst, but it looking at the diagrams and descriptions from the BBC (http://www.bbceng.info/additions/2019/ETD Books/Television Principles Vol. 3 - TV Signal Coding - ETD Training Book - G. Oxley.pdf), it looks like that's incorrect and the receiver syncs to the average of the two swinging colorburst phases instead. That would explain the hue shift you're describing.

 

There are a couple of comments in your referenced source code that I'm a bit confused about, though. If you look at the BBC's block diagrams for PAL encoding and decoding, the swinging color subcarrier and the phase shifted color waveforms are generated by summing U and V aligned carriers and negating V on every other line. It isn't generated by variable delays between the luma and chroma signals. GTIA does that to its color subcarrier reference, but that's just the way it generates different phases. Summing the swinging color bursts also seems odd, that's definitely not how the encoders are generally depicted, and the BBC's decoder diagram doesn't show that being done in the decoder either -- instead, it describes the oscillator error signal being heavily damped with a long time constant. The BBC literature unfortunately doesn't recommend a strategy for chroma AGC, and the datasheets for the various decoder chips I've been able to find typically just mention something vague like the amplitude of the chroma signal. Do you have a reference for this behavior?

 

[serj]

Phaeron, thank you, this palette is better.
but, I set the value “hue start = 40”, in my opinion it’s better.

Edited May 11 by serj

[Mclaneinc]

A rare one from me...

 

Colours / colors...I get that people want what they perceive as proper colours, but are they the PROPER colours?

 

All the machines and all the TV / monitors showed what you took as proper colours, but as we know what I saw and what you saw varied across the board, and that's without the PAL / NTSC variations. Avery has given you the most practical way to adjust the palette possible. OK it looks daunting, but with a bit of time and a reference, you can set the colours to what you remember. That won't address the things like Pole Position that deliberately had different colours for the regions as opposed to the regional TV difference, but Avery says there's a way around that.

 

I'm not trying to start ANOTHER what colours I like, set of posts, they should be in the main forum and not the Altirra test  thread, also, they have been done to death over the years, and it's boiled down to a sort of agree to disagree level..Probably best left at that. I'm just saying that there;'s a reasonably simple way  to create your own palette.

 

On a more on topic point, yes, mechanical sounds would be nice..Very immersive..

 

Rewind is ok, personally I've never used it on any system. Does that mean I'm a super stud brilliant player, sadly not, I simply don't play much these days due to pain, but if it can be added, then another useful feature by Avery...

[baktra]

19 minutes ago, Mclaneinc said:

 

Rewind is ok, personally I've never used it on any system. Does that mean I'm a super stud brilliant player, sadly not, I simply don't play much these days due to pain, but if it can be added, then another useful feature by Avery...

You can try rewind with the most recent releases of the XFormer emulator.

[Kr0tki]

On 5/11/2024 at 8:40 AM, phaeron said:

In NTSC, the color pot definitely doesn't affect hue $1x

True, that's because GTIA's colourburst signal and hue $1x are always equal in phase. But here's an interesting issue (though tangential to the topic): If I understand the GTIA C014805 specs correctly (section 9.3, sheets 21 and 22), the colour pot should affect phases of all 15 hues including the colourburst/hue $1x. Now I cannot test it myself as I don't own an NTSC machine, but this means the colour pot should affect hues of NTSC artifact colours (because it would effectively change phase difference between the colourburst and the pixel clock). Have you ever seen this happening, by any chance?

 

On 5/11/2024 at 8:40 AM, phaeron said:

I wrote that under the assumption that the PAL receiver syncs to each colorburst, but it looking at the diagrams and descriptions from the BBC (http://www.bbceng.info/additions/2019/ETD Books/Television Principles Vol. 3 - TV Signal Coding - ETD Training Book - G. Oxley.pdf), it looks like that's incorrect and the receiver syncs to the average of the two swinging colorburst phases instead. That would explain the hue shift you're describing.

Yes, it explains the hue shift and, depending on how the decoder "reconstructs" the average of the colourbursts, it may also explain the changes in saturation. More on this below.

 

On 5/11/2024 at 8:40 AM, phaeron said:

There are a couple of comments in your referenced source code that I'm a bit confused about, though. If you look at the BBC's block diagrams for PAL encoding and decoding, the swinging color subcarrier and the phase shifted color waveforms are generated by summing U and V aligned carriers and negating V on every other line. It isn't generated by variable delays between the luma and chroma signals.

Reading them after all these years, I am aware that my comments are somewhat confusing, maybe I was trying to explain the chip's behaviour from an "opposite direction". But for certain, the GTIA does generate the swinging colourbursts and the colour waveforms by delaying the input 4.43 MHz subcarrier by variable amounts. Also, I don't understand why the luma signal has crept into the discussion.

 

On 5/11/2024 at 8:40 AM, phaeron said:

Summing the swinging color bursts also seems odd, that's definitely not how the encoders are generally depicted, and the BBC's decoder diagram doesn't show that being done in the decoder either -- instead, it describes the oscillator error signal being heavily damped with a long time constant. The BBC literature unfortunately doesn't recommend a strategy for chroma AGC, and the datasheets for the various decoder chips I've been able to find typically just mention something vague like the amplitude of the chroma signal. Do you have a reference for this behavior?

I did not know any documentation that would describe in enough detail how a PAL decoder works, so I did not know (and still don't) if summing the swinging colourbursts in order to retrieve the phase of the -U carrier is what any existing decoders actually do. But summing two sine waves, one at +135° and another at +225°, gives a sine wave shifted +180° with a higher amplitude, so this approach at least results with a wave with a correct -U phase. But on a PAL GTIA, the phase shift between the swinging colourbursts is not always 90°. The PAL GTIA's colourburst is always equal in phase to hue $1x - just as in NTSC - but the delays of hue $1x on even and odd lines are both dependent on the colour pot such that the difference between the two is 90° only on a certain pot setting. Since no PAL documentation describes how a decoder should behave in such a standard-defying situation, I had no choice but to resort to experimenting with actual TV sets.

 

I had a 14'' Crown and a 26'' Philips (don't know the exact model numbers), both CRT TVs from the early 2000s, so probably both contained a digital PAL decoder. Both were connected to an Atari via RF antenna input. On both sets I was experiencing the following symptoms:

1. When turning the colour pot toward "the maximum", not only the hues of colours were changing, but the TV was also displaying them with increasing saturation.

2. When turning the pot past around 80% of its range, when the colours were very saturated, the TV would suddenly stop interpreting the colours at all and display a black-and-white image, with every colour surface covered with a dotted pattern - a visible hallmark of displaying colour composite signal as if it was plain B&W.

3. The turning the pot further near the end of its range, the colours would come back on the TV, very saturated but all of them "reversed".

 

An assumption that a PAL decoder in those TVs recreates the -U phase by adding the swinging colourbursts together, has turned out to explain all of the above properties.

1. Turning the colour pot towards the maximum increases the phase difference between the colourbursts in the even and odd lines. Summing two such colourbursts always gives us a sine wave with a certain phase, but its amplitude is smaller the bigger the phase difference. If the amplitude of such a recreated signal is used as a reference for decoding of the colours, it would explain the observable changes in saturation: since the recreated reference signal has lower amplitude compared to the colour signal in the rest of the scanline, those colour signals should be interpreted as having higher saturation.

2. At a certain point of the colour pot the phase shift between the swinging colourbursts becomes so close to 180°, so the reference signal obtained by summing them up has the amplitude that nears zero. This explains the loss of colours: the decoder ceases to detect the colour reference signal altogether, and treats the signal as a purely black-and-white one.

3. Turning the colour pot further increases the difference between the swinging colourbursts past 180° and more, and summing them up results with a sine wave with phase that is inverted compared to the less-than-180° angles. This is interpreted by the PAL decoder as the -U signal, but since it is inverted, the decoder inverts all decoded colours too.

 

As a result, the current implementation in Atari800 was designed to replicate the behaviour of these two TV sets that I had access to. Thanks for pointing out that this might be non-standard and other TV sets could behave differently. I might have access to a few more PAL TVs in the following weeks, so I might be able to test them as well. Unfortunately, all of them are from the 2000s, so it is not going to be sufficient. A 1970s/1980s TV would be nice to have, to verify how it would interpret the PAL GTIA.

[phaeron]

6 hours ago, Kr0tki said:

True, that's because GTIA's colourburst signal and hue $1x are always equal in phase. But here's an interesting issue (though tangential to the topic): If I understand the GTIA C014805 specs correctly (section 9.3, sheets 21 and 22), the colour pot should affect phases of all 15 hues including the colourburst/hue $1x. Now I cannot test it myself as I don't own an NTSC machine, but this means the colour pot should affect hues of NTSC artifact colours (because it would effectively change phase difference between the colourburst and the pixel clock). Have you ever seen this happening, by any chance?

Yes, it does. It's subtle, because it's only a few degrees, but it is visible.

 

From an NTSC 130XE, adjusting the color pot:

 

Low

 

Mid (color $1 = $F / 25.7° step)

 

High

 

You can see it in the first row (0) of the Artifacting column, where pure black and white are used. It changes subtly from sea green/mauve to blue/red. Note that this is a cell phone pic of an LCD monitor, so the colors aren't super accurate, but it should be enough to see the change. (I would grab a video, but I don't have a tripod....)

 

Also, in general, the artifacted colors are quite saturated and out of gamut, so they can be subject to clamping effects on some displays, though not in the case -- typically purple/green is the result when it occurs. But for that reason, it's not entirely accurate to attribute specific artifacting colors to the computer alone.

 

[phaeron]

To celebrate my new cheapo tripod... so here's the video version:

 

 

[Mclaneinc]

On 5/11/2024 at 2:02 PM, baktra said:

You can try rewind with the most recent releases of the XFormer emulator.

Yeah, it's on most of the emulators of consoles I use, just never given it much if any time. Nearest I guess would be playing the PC / Console game, Braid, where it's a gameplay element. Would I like to see it on Altirra, yes, of course, any feature that helps out is a great addition..

[ldelsarte]

On 5/14/2024 at 6:33 AM, phaeron said:

To celebrate my new cheapo tripod... so here's the video version:

 

 

Can I ask what is this program you're running + where to get it? Thanks

[+MrFish]

30 minutes ago, ldelsarte said:

Can I ask what is this program you're running + where to get it? Thanks

Colormap (Phaeron).xex

 

[phaeron]

To clarify, the COLORMAP tool in question comes from the additions disk that ships with Altirra (Additions.atr). Not that it's changed in a while.

 

[cathrynm]

Could we get an option to output to a tcp/ip connection here? A port and ip/dns name.  850 Serial port already has a 'Networked Serial Port' which is basically that.

I've managed to get printertopdf compiled on linux and I have another emulator (kegs lately) connecting to a virtual Epson printer that then talks to cups.  It mostly works, give or take some  quirks.

Thanks.