Regen 0.93 Beta 4 + new Debuggers

[Eke]

Off-Topic again but I love those technical discussions

Btw, I think that what Blaarg's NTSC filters are doing is purely emulating NTSC Video encoder and TV decoder, by doing the RGB<->YIQ transformations and "simulating" artefacts produced by some specific frequencies during the conversions (modern Video encoders probably do a lot more filtering than those old systems)

Apparently, the SNES and Genesis NTSC encoders also differ with the way they are handling the carrier phase: the first one will add an offset on each new field to reduce artefacts where as, in the case of the genesis, it remains constant...

some nice pictures which helped me figuring what NTSC owners were seeing (I always had RGB on my consoles):

http://www.disgruntleddesigner.com/chri ... ml#genesis


and a link I found about NTSC color restriction when dealing with digital graphics:
http://www.gamasutra.com/features/20010 ... son_02.htm

Could it be that this vertical dithering effect (not visible on PAL console btw) is due to the use of "special" color schemes ?

[HardWareMan]

Not for NSTC RF and composite it's not. R-Y and B-Y are mapped to Q and I color space. They are mapped to a 360 degree color phase chart. The color burst signal on the front porch provides the comparison point in which the subcarrier oscillation is compared to (out of phase to). This happens every scanline.

As in PAL. But, decoders is not in vain have a delay line signal exactly at 1 scanline.
But in modern digital TV all decoding in digital DSP, so colors looks much better than analog ones.
In color decoders PAL / NTSC source signal for demodulators switch every scanline between direct and delayed signal. For example:

Code: Select all

 1 - direct signal, 2 - one scanline delayed signal.
1: < ScanLineN > <ScanLineN+1> <ScanLineN+2> <ScanLineN+3> ....
2: <ScanLineN-1> < ScanLineN > <ScanLineN+1> <ScanLineN+2> ....
     R-Y from 1    R-Y from 2    R-Y from 1    R-Y from 2
     B-Y from 2    B-Y from 1    B-Y from 2    B-Y from 1

So is chroma decoder PAL / NTSC works. If i remove delay line then no color signal recieved from decoder (I try this many times at 90x). And decoder still produce R-Y and B-Y every scanline. There a special schematic unit for setting correct switching phase for source signal for the demodulator. If switching phase be wrong (rotated 180 degrees), then the colors are wrong and the decoder does not give output color, forcing the switch to the correct phase.

[AamirM]

Hi,

For the past few days, I've been working heavily on my own M68000 emulator, written in x86 assembly (lets not argue about this ), which I had started the same time I started Regen but never got around any time to finish due to fixing/adding other things. Now its upto a point where it can run many games (read: more than I expected). Still, lots of games don't run/hang/crash the emu so its still gonna take a while before its finally added. But its quite faster than the current one. Seeing it running Sonic 1 was the third most joyful moment for me (after King of Fighter 98 showing "Z80 Error" and Regen successfully running Snow Bros.).

On a related note, I've also added Yakovlev's awesome new 68k debugger.

Off-Topic again but I love those technical discussions Cool

By all means, please continue . Perhaps I can learn something myself from here and make a TV filter myself.

stay safe,

AamirM

[SmartOne]

By all means, please continue . Perhaps I can learn something myself from here and make a TV filter myself.

This stuff is interesting and all, and it's way beyond me how someone could shove all this information into a program and call in an emulator/simulator/whatever. Amazing.

It's still a lot of work to emulate such a crappy video standard. For me, the raw RGB (or raw-er, if possible ) video output from the Genesis is much more desirable. Filters that enhance the image are a higher priority.

*cough* I am still stuck on that scaling 4:3 issue and would like to know the exact formula.

[tetsuo55]

Chilly Willy, HardWareMan, tomaitheous, Eke,

Doesn't blargg's NTSC filter already do all this?

If not which parts is it missing?

By all means, please continue . Perhaps I can learn something myself from here and make a TV filter myself.

This stuff is interesting and all, and it's way beyond me how someone could shove all this information into a program and call in an emulator/simulator/whatever. Amazing.

It's still a lot of work to emulate such a crappy video standard. For me, the raw RGB (or raw-er, if possible ) video output from the Genesis is much more desirable. Filters that enhance the image are a higher priority.

*cough* I am still stuck on that scaling 4:3 issue and would like to know the exact formula.

Keep in mind that lots of systems/games actually need all this CRT TV simulation to display the image. Some games use NTSC artifacts to draw part of the image, and Silent Hill on the psx uses it to create the fog effect (The RGB image looks like a checkerboard)

[AamirM]

Hi,

*cough* I am still stuck on that scaling 4:3 issue and would like to know the exact formula.

The formula is simple and you may know it already.

width/height = 4/3
(square pixels assumed. That is, pixel aspect is 1:1)

Yep, thats the formula used for calculating width and height.

IMO, tetsuo55 is right. Emulation of NTSC is needed for some games to look correct although I haven't seen any game on Genesis needing it (maybe the Sonic 1 waterfall). Here is a excellent example posted by a user on ZSNES boards (for some Atari system):

Without NTSC


With NTSC


stay safe,

AamirM

[Chilly Willy]

I have a lot of experience in hamradio and I can tell where you are wrong.

You have hamradio experience, but clearly not TV experience, and you're wrong about nearly everything but the color subcarrier for PAL. It still doesn't negate the fact that most TVs used to low-pass filter the luminance at 2.5 to 3.5 MHz. Newer TVs used "notch" filters right at the color subcarrier frequency.

You're dead-wrong about R-Y/B-Y... most non-TV people usually goof that up. I/Q uses completely different calculations and is a different colorspace. Some European TVs accepted R-Y/B-Y inputs in addition to the more proper I/Q, but you won't find that on any NTSC TV. I think you're just thinking about modern digital PAL TVs, which is not what most people are going to want.

The delay in the color signal comes from the notch filter used to separate the chrominance signal from the luminance. Some TVs put an additional delay line on the luminance to try to compensate for the delay the notch filter creates, but that has the effect of phase shifting the luminance. Most TVs never bothered until digital processing came around.

Also, the color signal was NOT reduced vertically! Only horizontally by limiting the bandwidth of the I/Q signals. The I/Q actually have a 1.5MHz/0.5Mhz bandlimit, but most TVs were too cheap to deal with the extra bandwidth in the I signal, so they just filtered to 0.5 MHz for both before feeding into the matrix to convert back to RGB.

[Eke]

although I haven't seen any game on Genesis needing it

actually, this artefact is used in many games:
first examples coming in mind are Aladdin (look for dark areas), VectorMan title screen, Sonic 2 tubes, Street of Rage spotlights... this is generally used by devs to create transparency effects or mixed pixels color

Honestly, i didn't notice this effect before until some user told me about, as I always used PAL / RGB (and was used to those vertical lines), but this become clearly noticeable once you know...

That's why I plan to add blargg's filters support unless I found another way to correctly detect and simulate this effect

[SmartOne]

*cough* I am still stuck on that scaling 4:3 issue and would like to know the exact formula.

The formula is simple and you may know it already.

width/height = 4/3
(square pixels assumed. That is, pixel aspect is 1:1)

Yep, thats the formula used for calculating width and height.

I apologize if I'm being really dumb, and I hate to belabor this. However, the information can be beneficial for Regen.

Here are screenshots of the problem (the one with black borders and overscan visible) and the solution using a custom resolution in Kega. Finding the right resolution is not quite as easy as you make it (I think you misunderstand.) There's some kind of formula, but I can't figure it out.

http://www.sendspace.com/file/8mkfy6


-Change Topic-

That's why I plan to add blargg's filters support unless I found another way to correctly detect and simulate this effect

Now that would be cool! I was wondering if that was possible. Anyway, I still prefer the raw output, even if it's not what the developers intended. It's their fault for making the raw video look incorrect in the first place.

[AamirM]

Hi,

I apologize if I'm being really dumb, and I hate to belabor this. However, the information can be beneficial for Regen.

Regen can already do what you want . But anyways, lets see how Steve calculated that resolution:

As I said,

width/height = 4/3
=> width = height x (4/3)
put height 800 and you'll get width of 1066.

Now since most games use 224 height so:
240 - 224 = 16

this means there are borders of 8 (16/2) pixels above and below. Since you don't want borders, final height will be

height + ((height/240) * 16)

put height 800 and you'll get 854.

There you have it. There are cases when width/height doesn't fit in the given resolution so the calculations are slightly changed. But I won't tell those here. Thats your homework .

It's their fault for making the raw video look incorrect in the first place. Razz

They didn't knew back in the late 90s that someone would be playing it on a PC using emulator over a decade and a half later . And what you are seeing on the emulator is not "raw" as you say it. If you want pure "raw" output, get a memory viewer and watch the video buffer in hex/binary/whatever. Thats "raw" .

EDIT:

Btw, I looked at the sound problems you reported. Phantasy star II, as I suspected, is using SSG-EG though it seems unintentionally (0xFF writes). And Rocket Knight Adventure problem was sound buffering related.

stay safe,

AamirM

[HardWareMan]

I have a lot of experience in hamradio and I can tell where you are wrong.

You have hamradio experience, but clearly not TV experience, and you're wrong about nearly everything but the color subcarrier for PAL. It still doesn't negate the fact that most TVs used to low-pass filter the luminance at 2.5 to 3.5 MHz. Newer TVs used "notch" filters right at the color subcarrier frequency.

You're dead-wrong about R-Y/B-Y... most non-TV people usually goof that up. I/Q uses completely different calculations and is a different colorspace. Some European TVs accepted R-Y/B-Y inputs in addition to the more proper I/Q, but you won't find that on any NTSC TV. I think you're just thinking about modern digital PAL TVs, which is not what most people are going to want.

The delay in the color signal comes from the notch filter used to separate the chrominance signal from the luminance. Some TVs put an additional delay line on the luminance to try to compensate for the delay the notch filter creates, but that has the effect of phase shifting the luminance. Most TVs never bothered until digital processing came around.

Also, the color signal was NOT reduced vertically! Only horizontally by limiting the bandwidth of the I/Q signals. The I/Q actually have a 1.5MHz/0.5Mhz bandlimit, but most TVs were too cheap to deal with the extra bandwidth in the I signal, so they just filtered to 0.5 MHz for both before feeding into the matrix to convert back to RGB.

I am engaged in electronics since 1990 and believe, have very much experience. Especially in the color coding systems. No theoretical experience that is practical.
1. All the old TVs in the channel brightness have a notch filter, which on/off by decoder, which removes only the chroma subcarrier (if right tuned). This does not filter low frequencies. It is the notch filter with resonance at a frequency of the color subcarrier.
2. In PAL, and NTSC used in quadrature modulation color subcarrier signal chroma. But if the system NTSC angle between the vector sum and the axis vector B-Y, determines the color tone in the transfer of the color field is constant, the PAL system is changing its sign each scanline. Hence the name of the system - Phase Alternation Line. Ie B-Y always shifted 90 degrees in phase, and R-Y in NTSC is always constant (0 degrees) and in PAL each line is changed to 180 degrees. Reducing sensitivity to the differential-phase distortion is achieved by averaging chroma signals in two adjacent lines, resulting in a reduction of vertical color clarity doubled compared to NTSC. This feature is a lack of PAL.
3. In the NTSC signal contains full color on each scanline representing the brightness and chroma signal is transmitted through subcarrier lying in the frequency signal brightness. Subcarrier modulated in each scanline of the two signals chromaticity Er-y and Eb-y. To chroma signals do not create interference, the NTSC system used balanced quadrature modulation. However, the NTSC system has flaws and, most important of which is its high sensitivity to distortions in the signal transmission channels. Distortion signal in the form of amplitude modulation (AM), known as differential distortions. As a result of these distortions color saturation of bright and dark parts produced different. These distortions can not be addressed through the chain of automatic gain control (AGC) color, as well as differences in the amplitudes of the color subcarrier are in the same line. Distortions in the phase modulation of the color subcarrier signal to the brightness called differential-phase distortion. They are changing color tone depending on the brightness of the image area. For example, the human person colored in reddish color in shadows and greenish - on the lighted areas. To reduce the visibility of differential-phase distortion in NTSC TV provides operational control color tone, which allows more natural color components with the same brightness. However, distortion of color more vivid colors or darker areas while increasing.


OK, you are right - delay line is not used in NTSC, but talking about luminance channel, I am still right.

[TascoDLX]

lets see how Steve calculated that resolution:

As I said,

width/height = 4/3
=> width = height x (4/3)
put height 800 and you'll get width of 1066.

Now since most games use 224 height so:
240 - 224 = 16

this means there are borders of 8 (16/2) pixels above and below. Since you don't want borders, final height will be

height + ((height/240) * 16)

put height 800 and you'll get 854.

Partial credit.

First, there's no indication of the monitor's aspect ratio. So, you're assuming it is the same as the display resolution's (1280:800 = 16:10) which may be the case.

[This is the point where I'd mention your display resolution -- at least in regards to emulation (if you're finicky) -- should ideally have the same ratio as your monitor's display. If you're not sure, get a ruler and measure your screen. Divide width by height and try to find a resolution that matches. If you're using a CRT, you may have to adjust the width and height of the image after switching resolutions.]

For the resolution 1280 by 800, the base expert setting is:

1280,800,60,100,1280,800
; this will strech the image to fill the screen

expert-H / H = scale-H
expert-V / V = scale-V

H = 1280 and V = 800. Initially, expert-H = 1280 and expert-V = 800, so scale-H = 1.0 and scale-V = 1.0

Part A (the horizontal):

First, scale down horizontally to get a 1:1 picture. We'll assume the monitor's aspect ratio is 16:10 (1.6) here.

scale-H = 1 / monitor's aspect ratio = 1 / 1.6 or 10 / 16
1280 * scale-H = 1280 * 10 / 16 = expert-H = 800

1280,800,60,100,800,800
; this will result in a square image

Now, scale up to 4:3.

800 * 4/3 = expert-H = 1066.67

Round this value to an even number.

1280,800,60,100,1066,800
; correct aspect with top and bottom borders

Part B (the vertical):

This is easy. You're scaling up here, not down, so 224 lines become 240 lines.

scale-V = 240 / 224
800 * scale-V = 800 * 240 / 224 = expert-V = 857.14286

Again, round to an even number.

1280,800,60,100,1066,858
; stretched and aspect corrected

854 would seem acceptable but it looks to leave a line of border on the top and bottom of the display. This also appears when using Fusion's Fixed Aspect (Zoom).

expert-H = H / (monitor's display width / monitor's display height) * (4/3)
expert-V = V * (240/224)

This is what I came up with: 1920,1080,60,100,1498,1158

1920:1080 = 16:9, so it really depends if your monitor is 16:9 or 16:10.
I would guess 16:10 based on your numbers (and general popularity of aspect ratios).

; 16:9 :
1920,1080,60,100,1440,1158

; 16:10 :
1920,1080,60,100,1600,1158

[I.S.T.]

Hi,

Here is a excellent example posted by a user on ZSNES boards (for some Atari system):

Without NTSC


With NTSC


stay safe,

AamirM

It was Gil_Hamilton, and the system was the Atari 7800, in case you or someone else is curious.

[AamirM]

Hi,

; 16:9 :
1920,1080,60,100,1440,1158

; 16:10 :
1920,1080,60,100,1600,1158

Hey, you just did his homework .

By the way, shouldn't Kega be doing this itself with those fixed aspect options? It seems to only set multiples of 320x240 (or am I missing something?).

stay safe,

AamirM

[TmEE co.(TM)]

On my poor work machine, if multiples would not be used, things would be unplayable. 320x240 works great, 320x239 will be 5FPS...