Regen 0.93 Beta 4 + new Debuggers

TmEE co.(TM) · Post by **TmEE co.(TM)** » Thu Oct 02, 2008 2:49 pm

MD outputs only fixed amount of lines, doesn't matter if you have interlace enabled or not...

I need to see the stuttering effect...

on LCD, the interlacing cannot be really seen, both lines will smudge together... all thanks to physical properties of LCDs...

tetsuo55 · Post by **tetsuo55** » Thu Oct 02, 2008 4:52 pm

TmEE co.(TM) wrote:MD outputs only fixed amount of lines, doesn't matter if you have interlace enabled or not...

Although thats true, the TV treats progressive and interlaced completely differently

Progressive is rendered to the same odd or even scanlines over and over
Interlaced is alternated between the odd and even scanlines

For NTSC the genesis outputs 60 fields per second, each field is 262,5 scanlines high.

that last ,5 decides if the frame is ODD or EVEN.

In progressive mode the .5 is either always there or never there, resulting in every frame being drawn to the same scanlines at 60fps

In interlaced mode every other frame has the .5 so all scanlines are used each scanline being refreshed at 30fps.

In both cases the image on the tv will be 525 scanlines heigh(in progressive mode half of those are black).

Kell factor reduces the scanline effect in progressive mode and hides flickering and artifacts in interlaced mode.

---------

The way Regen currently seems to be emulating the image is:

The genesis generates an image in its videocard-ram, this image is directly dumped to screen, the image is either stripped of its NTSC/PAL signalling information or this is not rendered at all.

This is how most emulators work though. It is not however how the real system displays the image on screen.

The real system generates a NTSC/PAL broadcast signal. The CRT-TV translates this to an image. This image can be very different from the one in the videocard-ram as you can see in the image posted a few posts back.

HardWareMan · Post by **HardWareMan** » Thu Oct 02, 2008 5:17 pm

It is not correct. There is not 0.5 lines but different number of lines. For example, 625 lines for PAL 50Hz formed as 312/313. Then 312 lines are shorter (312 * 0.064 = 19.968ms), and 313 - longer (313 * 0.064 = 20.032ms). The average frequency is exactly 50Hz. A feature of the formation of linear saws in vertical scan is that charging capacitor constant current. Because both fields are different, the charging time different to, so the magnitude and saws will be slightly different. The amplifier, loaded to coil will respond to this slightly modified height of the vertical size - exactly at the half of scanline. Everything is simple. I think it is true for NTSC systems.

AamirM · Post by **AamirM** » Thu Oct 02, 2008 6:08 pm

Hi,

The genesis generates an image in its videocard-ram, this image is directly dumped to screen, the image is either stripped of its NTSC/PAL signalling information or this is not rendered at all.

I assume that you're thinking of frame buffering here which is not how genesis works. Real genesis works at dot level with tile system meaning vram is not a frame buffer but instead stores pattern data and VDP uses it to create a video signal. Regen works at line level.

stay safe,

AamirM

tomaitheous · Post by **tomaitheous** » Thu Oct 02, 2008 9:34 pm

MD outputs only fixed amount of lines, doesn't matter if you have interlace enabled or not...

Actually that's not entirely true.

If you enable *interlaced* mode of an NTSC Genesis, it will output a series of half lines in the vblank area of the output signal. If you add up the half lines you will get the equivalent of a 262.5 scanlines. Here's the kicker part though; if you count the instances of scanlines without adding two half scanlines, you get 313 (or 312 I forget). Which falls in line with PAL spec if those were full scanlines. One can speculate that they reused some internal circuitry/logic for the NTSC interlaced mode, from the PAL circuitry/logic. Whether this is from the NTSC/PAL video encoder or the VDP itself, I'm not sure. Maybe someone else can verify this? Either way, it's not a legal NTSC interlaced signal. I haven't tried it out on my HDTV set to see how it interprets the interlaced signal. IIRC, some people reported problems with LCDs and that interlaced mode of Sonic 2.

For example, 625 lines for PAL 50Hz formed as 312/313. Then 312 lines are shorter (312 * 0.064 = 19.968ms), and 313 - longer (313 * 0.064 = 20.032ms).

You can use that method for NTSC (some PC-Engine demos use this method), but this is *not* an NTSC spec. It works fine for SDTVs and some capture cards, but I've yet to see an NTSC LCD or HDTV interpret this signal correctly. NTSC interlaced spec calls for a 0.5 half line to reposition the next frame.

Matter of fact, I'm pretty sure the 240p60 mode consoles use is not a legal NTSC spec either (some older NTSC TVs don't handle the signal properly and the image bounces). I've never been able to find it anywhere. Maybe someone here has a link providing such?

SmartOne · Post by **SmartOne** » Fri Oct 03, 2008 2:03 am

Sound issue: Phantasy Star III

Disclaimer: I heard this problem using your injected in_gme.dll which I understand is somewhat outdated.

The song "Skyhaven" seems a little louder than the other ones, and it distorts very noticeably. Related to CV: Bloodlines BGM 26 crackles? I think so.

Just noticed that "Satellite" is also pretty loud and might be distorting.

eighty5cacao · Post by **eighty5cacao** » Fri Oct 03, 2008 2:28 am

Comment about the user interface (this isn't really specific to the debugger build, but oh well):

There isn't a very good UI to show whether the "Overclock M68000" feature is enabled. Perhaps a checkmark next to the menu entry might do? Also, what do I need to do to turn the overclocking back off?

SmartOne · Post by **SmartOne** » Fri Oct 03, 2008 2:49 am

Apparently the default is 488 cycles. I want to know the value to emulate the popular real hardware overclocking mod.

tetsuo55 · Post by **tetsuo55** » Fri Oct 03, 2008 7:43 am

tomaitheous wrote:
MD outputs only fixed amount of lines, doesn't matter if you have interlace enabled or not...
Actually that's not entirely true.

If you enable *interlaced* mode of an NTSC Genesis, it will output a series of half lines in the vblank area of the output signal. If you add up the half lines you will get the equivalent of a 262.5 scanlines. Here's the kicker part though; if you count the instances of scanlines without adding two half scanlines, you get 313 (or 312 I forget). Which falls in line with PAL spec if those were full scanlines. One can speculate that they reused some internal circuitry/logic for the NTSC interlaced mode, from the PAL circuitry/logic. Whether this is from the NTSC/PAL video encoder or the VDP itself, I'm not sure. Maybe someone else can verify this? Either way, it's not a legal NTSC interlaced signal. I haven't tried it out on my HDTV set to see how it interprets the interlaced signal. IIRC, some people reported problems with LCDs and that interlaced mode of Sonic 2.

For example, 625 lines for PAL 50Hz formed as 312/313. Then 312 lines are shorter (312 * 0.064 = 19.968ms), and 313 - longer (313 * 0.064 = 20.032ms).
You can use that method for NTSC (some PC-Engine demos use this method), but this is *not* an NTSC spec. It works fine for SDTVs and some capture cards, but I've yet to see an NTSC LCD or HDTV interpret this signal correctly. NTSC interlaced spec calls for a 0.5 half line to reposition the next frame.

Matter of fact, I'm pretty sure the 240p60 mode consoles use is not a legal NTSC spec either (some older NTSC TVs don't handle the signal properly and the image bounces). I've never been able to find it anywhere. Maybe someone here has a link providing such?

I really have no clue what the genesis is doing internally. However to be able to display an image on the tv it has to do something very close to what i said

that 313 number has something to do with the original broadcast system, the first broadcast systems and tv's where designed for 313 lines of image.(more detail was not possible back then, the tv's have always had 525 lines though)

The signal outputted by all progressive consoles is a hack of the NTSC/PAL broadcast signal, the hacky-ness differs on each system. However any ompliant CRT display should have no problem displaying them.
Modern HD panels analyse the signal so it can guess how to display it, many do not expect the "hack" and get confused

HardWareMan · Post by **HardWareMan** » Fri Oct 03, 2008 8:21 am

tetsuo55 wrote:I really have no clue what the genesis is doing internally. However to be able to display an image on the tv it has to do something very close to what i said

that 313 number has something to do with the original broadcast system, the first broadcast systems and tv's where designed for 313 lines of image.(more detail was not possible back then, the tv's have always had 525 lines though)

The signal outputted by all progressive consoles is a hack of the NTSC/PAL broadcast signal, the hacky-ness differs on each system. However any ompliant CRT display should have no problem displaying them.
Modern HD panels analyse the signal so it can guess how to display it, many do not expect the "hack" and get confused

Yeah. Old consoles used small resolution, wich fit in one raster field, so they used it like progrssive scan with twice FPS. And alot of 8-bit computers (like ZX Spectrum, Atari or homebrew computers with TV as display) do the same thing.

Eke · Post by **Eke** » Fri Oct 03, 2008 8:52 am

According to the TMS9918 manual & timings page 86 (which the genesis VDP is derivated from), the output signal is not a "perfect" NTSC spec signal (active video line width and horizontal sync is a little longer, refresh rate is not exactly 59.94hz, there are 262 lines output...) but made "NTSC-compatible"... anyway, NTSC is naturally interlaced so they had to hack things to work in non-interlaced way.

I don't have either any idea how the interlaced signal is exactly output but I guess it has something to do with some "half lines" or lines being slighty longer so the timings falls in the NTSC interlaced signal spec.

this is certainly handled by the VDP and the way it ouputs HSYNC/VSYNC/CSYNC to the video encoder (btw, I wonder what happen in the case of my french megadrive which have RGB output ? does it really still need a video encoder or are the VDP signals enoug ?)

HardWareMan · Post by **HardWareMan** » Fri Oct 03, 2008 9:23 am

Eke wrote:(btw, I wonder what happen in the case of my french megadrive which have RGB output ? does it really still need a video encoder or are the VDP signals enoug ?)

Nothing. RGB output limited only raster timings and can be various (like PC monitor). I switch on 60Hz on my MD, while it in PAL mode and get PAL60 (but I had to cut off color subcarrier from VDP and used 4.43MHz quartz and 35pF capacitor right on CXA1145 pins, wich have internal CMOS oscillator). RGB always works with any combinations of PAL/NTSC VDP modes on my TV monitor or TV with RGB inputs.

tetsuo55 · Post by **tetsuo55** » Fri Oct 03, 2008 11:27 am

Eke wrote:According to the TMS9918 manual

That Document is really good, awesome stuff for genesis programmers.
Anyway i got the information i need for accurate image size and aspect ratio calculation.

(PixelClock)*0.00005266 = (NumberOfGeneratedPixels)

The pixel clock is 5.3mhz so:

5300000*0.00005266 = 279,098

So each frame will be:
279x243

Correcting the aspect ratio gives us:
324x243

correcting the height to crt tv dimensions:
648x486

Interlaced uses all the 648 lines, progressive uses half of them, other half is black

(The only problem with this is that i heard the genesis outputs 320pixels of wide resolution, if this is really true then the pixel clock has to have a different frequency (around 6mhz according to the doc the VDP crystal should be 12mhz in that case))

tomaitheous · Post by **tomaitheous** » Fri Oct 03, 2008 12:18 pm

(The only problem with this is that i heard the genesis outputs 320pixels of wide resolution, if this is really true then the pixel clock has to have a different frequency (around 6mhz according to the doc the VDP crystal should be 12mhz in that case))

It's 6.71mhz DOT clock for 320 pixel mode (~360 active pixels but a clipped image).

that 313 number has something to do with the original broadcast system, the first broadcast systems and tv's where designed for 313 lines of image.(more detail was not possible back then, the tv's have always had 525 lines though)

I really doubt it. It's more of a coincidence that it happens to be the number of scanlines per field in PAL. 240p60 mode on a NTSC doesn't employ this series of half lines.

Eke · Post by **Eke** » Fri Oct 03, 2008 12:23 pm

@tetsuo: There is already a topic talking about this, look for "TV Safe Area" topic or something like that.

To be more precise, the VDP pixel clock depends on the mode:

.H32 use MCLK/10
.H40 use MCLK/8

MCLK is the main crystal clock from which all other clocks are derivated and is exactly 53.693175 Mhz on a NTSC Genesis, which gives you the following dot clocks:

.H32: 5.37Mhz
.H40: 6.71 Mhz

Now, according to the TM9918 doc:

-->full line width is 63.69 us which gives you
342 pixels in H32 mode (this has been verified)
428 pixels in H40 mode (this is unverified)

-->display line width (without border) is 47.67 us (this is the recommended "safe" area to take overscan on TV in account) which gives you:
256 active pixels in H32 mode
320 pixels in H40 mode

-->active line width (with borders) is 52.89 us (notice that it is a little longer than NTSC signal spec) which gives you:
284 active pixels in H32 mode (this has been verified)
355 active pixels in H40 mode (this is unverified)

Vertically, in 60hz mode, the VDP generate 243 active lines:
. top border: 11 lines
. active display: 224 lines
. bottom border: 8 lines