Testing the new Stella TIA core

[DirtyHairy]

I guess the easiest way would be to add myTia as a property to Cartridge and inject the TIA instance via setter after it has been constructed in Console. What do you think, Stephen?

Edited March 15, 2017 by DirtyHairy

[+stephena]

I'll look into this later this afternoon and let you know.

 

EDIT: I decided to take a quick look before work starts, and remembered that you have access to the TIA object in any cart class through 'mySystem->tia()'. Spice, I guess you forgot about it, but I think you used precisely that call when you were doing the bus-stuffing and the TIA delegate code

[+SpiceWare]

That's what I get for working on it late - I did try this:

myThumbEmulator->run(cycles, mySystem->tia().tvMode() == TvMode::ntsc);

---

but Xcode gave me an error of Member access into incomplete type 'TIA'. Turned out I was missing the TIA header, though I do remember copy/pasting it in there at one point. I must have rolled that back, or maybe put it in the wrong file

 

That code compiles now, but is returning NTSC (the timer should have been 11Fd1F for PAL) even if after I changed the ROM to PAL60 and reload. So that may not be the correct way to ID it.

 

Anyhow time to get ready for work.

[+stephena]

But PAL60 is NTSC (60Hz) with PAL colours. So if the ROM is PAL60, is will be detected as NTSC, since the timing is NTSC.

 

Basically, Stella tracks whether something is NTSC or PAL based on the # of scanlines, first drawn scanline, etc. IOW, it looks at the resulting framerate. The difference between NTSC and PAL60 is simply the colours, not the scanlines/framerate.

[Thomas Jentzsch]

But PAL60 is NTSC (60Hz) with PAL colours. So if the ROM is PAL60, is will be detected as NTSC, since the timing is NTSC.

Not quite right. The speed of the console makes the difference. An NTSC console is slightly faster than a PAL console. So when using NTSC on an NTSC console and PAL60 on a PAL console, Darrell's code can detect that speed difference.

 

And theoretically this should work in Stella too. In NTSC mode, Stella should use the slightly higher NTSC console frequency and in PAL50 or 60 mode, Stella should use the PAL console frequency.

[+SpiceWare]

PAL60's typically run on PAL consoles, where the 6507 is at 1.182298 MHz instead of NTSC's 1.193182 MHz. That's what I'm trying to detect so the ARM's timer will be correct.

const double NTSC = 58.6664323021;
const double PAL  = 59.2061068702;

---

The Harmony's clocked at 70 MHz. Using the above:

• 58.6664323021 * 1.193182 = 69.9997310271
• 59.2061068702 * 1.182298 = 69.9992617404

So it appears what I need to get is the Display->Format as shown on the above screenshot, then select the MHz as NTSC if the format is NTSC or NTSC50.

[+stephena]

I get what you're saying, but in Stella there is no NTSC or PAL console; it's simply a console that runs the ROM at the specified framerate. So when "tvMode() == TvMode::ntsc", this simply means that it detected NTSC timings based on scanlines and framerate, NOT that the console is NTSC or PAL.

 

I agree that if you want to 'detect' PAL (as much as it can be detected in an emulator), then you need to look at the format: NTSC/NTSC50 imply NTSC, and PAL/PAL60 imply PAL. Perhaps we can add a method for that.

 

Overall, this is just part of the confusion I have in Stella wrt what a TV mode actually is. Stella knows about NTSC, PAL, SECAM, NTSC50, PAL60 and SECAM60. But the TVMode only knows about NTSC vs. PAL. And finally, there's the issue of the timing that is generated by the ROM itself (how many scanlines it has), and the different timings of the console itself. Arrgh

 

EDIT: Put another way, there's no way to auto-detect what type of console we have; we set it to be NTSC or PAL. Perhaps we need a ConsoleMode that is somewhat analogous to TvMode, but returns 'ntsc' for NTSC/NTSC50 and 'pal' for PAL/PAL60 (and which also takes SECAM into account).

[DirtyHairy]

Overall, this is just part of the confusion I have in Stella wrt what a TV mode actually is. Stella knows about NTSC, PAL, SECAM, NTSC50, PAL60 and SECAM60. But the TVMode only knows about NTSC vs. PAL. And finally, there's the issue of the timing that is generated by the ROM itself (how many scanlines it has), and the different timings of the console itself. Arrgh

 

I agree, the situation is mildly confusing. Actually, the name TVMode is a leftover from 6502.ts where it denotes the console type, PAL, SECAM or NTSC. As such, in 6502.ts, it determines oscillator frequency and palette (the display code automatically adapts to the frame timing). In Stella, it just denotes the frame timing.

 

Perhaps it makes sense to refactor things at some point:

 

* Rename TVMode to FrameTiming

* Replace Display->Format with a new enum that describes the console type: NTSC / PAL / SECAM and determines oscillator and palette.

 

PAL50/60, NTSC50/60 and SECAM50/60 would just be the six different combinations of those two settings.

 

Thinking of it, there is a minor bug in the new code: the simulation of the paddle readout circuit uses TVMode for determining the time base. This is slightly off for PAL60 & friends. I'll open a corresponding bug later.

Edited March 15, 2017 by DirtyHairy

[+stephena]

I agree, the situation is mildly confusing. Actually, the name TVMode is a leftover from 6502.ts where it denotes the console type, PAL, SECAM or NTSC. As such, in 6502.ts, it determines oscillator frequency and palette (the display code automatically adapts to the frame timing). In Stella, it just denotes the frame timing.

 

Perhaps it makes sense to refactor things at some point:

 

* Rename TVMode to FrameTiming

* Replace Display->Format with a new enum that describes the console type: NTSC / PAL / SECAM and determines oscillator and palette.

 

PAL50/60, NTSC50/60 and SECAM50/60 would just be the six different combinations of those two settings.

 

Thinking of it, there is a minor bug in the new code: the simulation of the paddle readout circuit uses TVMode for determining the time base. This is slightly off for PAL60 & friends. I'll open a corresponding bug later.

 

No time like the present to do this FrameTiming can be what TvMode currently is, and introduce ConsoleTiming for what I discussed above. I will open a bug later and take of this. DirtyHairy, you can then use the new code to fix the paddle stuff. Then finally, Spice will have what he needs to continue working on CDF.

[+SpiceWare]

Awesome! This'll end up in BUS and DPC+ as well as they can also make use of the timer.

[Thomas Jentzsch]

PAL50/60, NTSC50/60 and SECAM50/60 would just be the six different combinations of those two settings.

I know we got used to those terms.

 

But e.g. PAL50 doesn't describe a framerate in Stella. It describes the console type (speed and palette used) plus the vertical size of of the displayed frame. So, do we really need those anymore? IMO the ROM should define the vertical size (based on frame rate and/or really used space) and the emulator should only define the console type.

[+stephena]

I think it's still useful to have them named that way, and be selectable (with Ctrl-f). That way, one can see the effects of various timings on different systems (all the combinations). In any event, it's more work to remove it now than to leave it in. Similarly, even if after making the changes above we don't need one of the methods, it doesn't hurt to have it there in case it's needed in the future. If I had been thinking about this in more detail from the beginning, the required method would have already been there, and Spice wouldn't be having an issue. So better to have a method that's not (currently) used than the other way around.

 

Besides, there are times when we want to override the auto-detection. so there still needs to be a specific string to do that.

[alex_79]

Maybe you could separate the settings for the console type (NTSC/PAL/SECAM) from the display type (60Hz/50Hz).

e.g. CTRL-F would only cycle through NTSC-PAL-SECAM consoles, keeping the current display vertical resolution and aspect ratio, while a different key-combo would cycle through 60Hz-50Hz display keeping the current console type.

[Thomas Jentzsch]

But there is no 50 or 60Hz display. No matter if you select e.g. PAL60, PAL50, NTSC, the framerate for the ROM will still be the same. Only the size of the emulator frame is changed.

[alex_79]

PAL60's typically run on PAL consoles, where the 6507 is at 1.182298 MHz instead of NTSC's 1.193182 MHz. That's what I'm trying to detect so the ARM's timer will be correct.

BTW, I have a SECAM VCS (pcb CO17868 rev 2) and the crystal driving the TIA is 3.562500 MHz, which means that the CPU clock is 1.187500 MHz.

 

 

The board is lacking the TV-TYPE switch at the moment (so it only outputs in B/W) and I managed to tune the channel on a LCD TV. Picture is terrible and the TV treats the signal as interlaced, but it was enough to try the NTSCvsPAL2.bin test rom with it.

 

Results are 11E8F7 - 11E8FD

 

 

 

According to the service manual, PAL-M consoles use a 3.575611 MHz crystal, so the CPU is clocked at 1.191870 MHz (the palette is the same, or very similar, to NTSC. So there's probably no reason to detect that in a game...)

Edited March 15, 2017 by alex_79

[alex_79]

But there is no 50 or 60Hz display. No matter if you select e.g. PAL60, PAL50, NTSC, the framerate for the ROM will still be the same. Only the size of the emulator frame is changed.

Yes, when selecting the wrong display, the screen should roll, like when you run a 60Hz game on a PAL TV that can only sync to 50Hz and vice-versa. But it could be useful to test a game that can switch between 50 or 60Hz. The other option would be to autodetect the change in framerate and automatically change the display type (like a multistandard TV)

Edited March 15, 2017 by alex_79

[+SpiceWare]

BTW, I have a SECAM VCS (pcb CO17868 rev 2) and the crystal driving the TIA is 3.562500 MHz, which means that the CPU clock is 1.187500 MHz.

 

...

 

Results are 11E8F7 - 11E8FD

Great! Based on that I'll be able to autodetect NTSC, PAL or SECAM. I'll add that in the next update.

 

According to the service manual, PAL-M consoles use a 3.575611 MHz crystal, so the CPU is clocked at 1.191870 MHz (the palette is the same, or very similar, to NTSC. So there's probably no reason to detect that in a game...)

Good to know, thanks!

[+stephena]

I think we're getting hung up on the naming used here. You're right that PAL60 doesn't force a ROM to run at 60Hz; it's kernel does that. But PAL60 also encodes the information for palette as well. So using the enumerations we're going to define, PAL60 will mean:

 

FrameTiming = ntsc (and NTSC colours)

ConsoleTiming = pal

 

Either way we look at it, we need to keep track of these two items somewhere. Now I could separate it out into two ROM properties, and have two key-combos to cycle through each variation individually, but I don't really see the point of doing that. Put another way, PAL60 means "NTSC colours on a PAL system, with an NTSC-sized window". Now I could name it that way, or name it PAL60. I leave it to you to decide which is more concise

[Thomas Jentzsch]

I am getting confused. Please let us sort this out:

• Console: defines CPU frequency and color palette
• TV: defines sync range (IMO we do not have to emulate this) and color palette
• ROM: defines frame rate and colors used

Stella emulates console and TV. IMO we don't have to emulate combinations like NTSC console with PAL TV. So Stella only has to emulate either NTSC, PAL or SECAM consoles with matching TVs.

 

The ROMs define the number of scanlines displayed, which define the framerate (based on the console speed). This is somewhere between ~45 (Acid Drop) and ~65 (Artillery Duel) Hz.

 

Currently in Stella each scanline has the same height. On a real TV, the height of a scanline depends on the number of scanlines displayed. Stella compensates this by selecting two different default emulator window heights, one for ~50Hz (PAL) and one for ~60Hz (NTSC) games. With the Stella properties this default height can be adjusted.

 

Correct?

[alex_79]

Yeah, using 60/50Hz to indicate the display is confusing. Anyway, the reason it would be better to separate the two settings (IMO), is that the correct display type can be autodetected by looking at the game framerate, and there's no reason to ever change it (except in those rare cases when a game can switch the framerate).

[Thomas Jentzsch]

Unrelated BTW:

 

It just occurred to me, that a PAL60 conversion ROM should display 2-3 scanlines less than its NTSC counterpart to get the speed right on a slower PAL console.

[+stephena]

OK, I need to think about this a little more and come up with examples, and make sure we're all on the same page. To me, PAL60 implies PAL console with NTSC timings (and colours). So the 60 implies NTSC. Slightly confusing, I guess, but it's been in Stella for some time now. I think calling the format "PAL_NTSC" is more confusing ??

[Keatah]

But there is no 50 or 60Hz display. No matter if you select e.g. PAL60, PAL50, NTSC, the framerate for the ROM will still be the same. Only the size of the emulator frame is changed.

Maybe you could separate the settings for the console type (NTSC/PAL/SECAM) from the display type (60Hz/50Hz).

 

e.g. CTRL-F would only cycle through NTSC-PAL-SECAM consoles, keeping the current display vertical resolution and aspect ratio, while a different key-combo would cycle through 60Hz-50Hz display keeping the current console type.

 

Wouldn't that require vertical rescaling and resizing?

[Thomas Jentzsch]

OK, I need to think about this a little more and come up with examples, and make sure we're all on the same page. To me, PAL60 implies PAL console with NTSC timings (and colours). So the 60 implies NTSC. Slightly confusing, I guess, but it's been in Stella for some time now. I think calling the format "PAL_NTSC" is more confusing ??

Correction: PAL60 has PAL colors.

 

No clue how to name that better. Actually I hope we might not need that at all. E.g. displaying a PAL60 ROM with a PAL50 setting makes no sense. The only difference is a larger black area at the bottom.

 

IMO the emulator should be able to calculate the required display window based at least on the number of scanlines displayed (minus an average top and bottom area). And where possible fine tuning this value by checking the screen for changes.

[+stephena]

OK, here is my understanding of how things should be, based on what was discussed above and also what is closest to that currently in Stella (to minimize code changes):

enum FrameTiming {

ntsc, // ROM display has NTSC timings (~60Hz, ~262 scanlines, etc)

pal // ROM display has PAL timings (~50Hz, ~312 scanlines, etc)

};

 

Note that FrameTiming is indeed auto-detected, and determined by the ROM itself. The actual framerate and # of scanlines is irrelevant (and there are other methods to get those anyway). This enum simply tells us that the ROM is running at NTSC or PAL timings.

 

enum ConsoleTiming {

ntsc, // console with CPU running at 1.193182 MHz, NTSC colours

pal, // console with CPU running at 1.182298 MHz, PAL colours

secam // console with CPU running at (whatever it is determined to be), SECAM colours

};

 

Note that ConsoleTiming is what Spice needs to pass into Thumbulator run method.

 

Now, a crude table to illustrate how the enum's work together:

/ Console ntsc pal secam

Frame ntsc NTSC PAL60 SECAM60

pal NTSC50 PAL SECAM

 

 

What's in uppercase above is what's actually stored in the ROM properties (in addition to 'Auto', of course), and what is displayed when pressing Alt-l in Stella. Pressing Ctrl-f switches between all 6 modes (actually 7, since 'Auto' is done too).

 

In all cases, we have all the info we need. Is this more or less confusing than what others have in mind??

 

EDIT: I forgot to add that in the case that Display.Format is set to "Auto" in the ROM properties (which it is for most ROMS), the ConsoleTiming variable will basically 'inherit' from FrameTiming: ie FrameTiming == ntsc implies that ConsoleTiming is also NTSC, and so on.