Stella 2.4.1 released

[Telex]

Hello Everyone,

 

I am new to the boards, but not new to emulation.

 

Forgive me if this is a stupid question, but I am trying to figure out why the "Game Properties" and "Cheat" functions on the new Stella are grayed out. I have all the roms in the default directory, but I can't figure it out. Perhaps I am missing some sort of text files with info or something that it tries to output?

 

Thanks,

 

Telex

[Telex]

Hmm.. I have read the instructions and saw info about this "stella.pro" file, but I don't have it for any rom. I reinstalled Stella just to make sure and no other luck as well.

 

Any ideas? Thanks for your time!

[+stephena]

Hello Everyone,

 

I am new to the boards, but not new to emulation.

 

Forgive me if this is a stupid question, but I am trying to figure out why the "Game Properties" and "Cheat" functions on the new Stella are grayed out. I have all the roms in the default directory, but I can't figure it out. Perhaps I am missing some sort of text files with info or something that it tries to output?

You need to be in 'emulation' mode for those options to be available. Start playing a ROM and then press 'Tab' key; the options will now be available. When you think about it, it makes sense; game properties and cheats are specific to a game, so you can't edit them unless you're actually playing a game

Hmm.. I have read the instructions and saw info about this "stella.pro" file, but I don't have it for any rom. I reinstalled Stella just to make sure and no other luck as well.

You don't need a stella.pro file for newer versions of Stella; all the required info is built into the application. The stella.pro file is used to override the built-in ROM properties. Basically, only developers will ever really have a need for it. And Stella will generate it automatically when required. Essentially, you don't have to worry about it. Just make sure Stella can find your ROMs (by navigating to your ROMs folder within Stella, or setting the default ROM folder in 'Config Files'), and just click 'Play' to start a game.

[Telex]

Hello Everyone,

 

I am new to the boards, but not new to emulation.

 

Forgive me if this is a stupid question, but I am trying to figure out why the "Game Properties" and "Cheat" functions on the new Stella are grayed out. I have all the roms in the default directory, but I can't figure it out. Perhaps I am missing some sort of text files with info or something that it tries to output?

You need to be in 'emulation' mode for those options to be available. Start playing a ROM and then press 'Tab' key; the options will now be available. When you think about it, it makes sense; game properties and cheats are specific to a game, so you can't edit them unless you're actually playing a game

Hmm.. I have read the instructions and saw info about this "stella.pro" file, but I don't have it for any rom. I reinstalled Stella just to make sure and no other luck as well.

You don't need a stella.pro file for newer versions of Stella; all the required info is built into the application. The stella.pro file is used to override the built-in ROM properties. Basically, only developers will ever really have a need for it. And Stella will generate it automatically when required. Essentially, you don't have to worry about it. Just make sure Stella can find your ROMs (by navigating to your ROMs folder within Stella, or setting the default ROM folder in 'Config Files'), and just click 'Play' to start a game.

 

 

Hehehe.. I feel like a total idiot now. Thanks so much for your time! It works perfectly.

 

I figured you could look at rariety stats when you weren't actually playing a particular rom, but I guess that is not how it works. Is this something to easily implement in the future, or would it be too much of a pain? Thanks again.

[+stephena]

Hehehe.. I feel like a total idiot now. Thanks so much for your time! It works perfectly.

 

I figured you could look at rariety stats when you weren't actually playing a particular rom, but I guess that is not how it works. Is this something to easily implement in the future, or would it be too much of a pain? Thanks again.

I'm working on something like that right now, which will be included in the next release. See one of the above message for a preview of the new snapshot mode. Under the snapshots, there's a place to show some relevant info on a ROM, including its rarity. Of course, the information built into Stella is woefully out of date, but that will be fixed before the next release as well.

[+batari]

Today I tried OpenGL mode, and the result was a totally black screen, but Stella was still running because the sound of the game was still playing, just no screen. And with a black screen, you can't see the menus to change it back.

 

This is a 1.4 GHz iBook G4 running OSX 10.4. I have used OpenGL on Stella 2.0 without issues.

 

I got it back to Software rendering by running Stella at the command line with -video soft. I don't know if it's a Stella bug or just outdated OpenGL hardware on my iBook, but I thought I'd report it anyway.

[+stephena]

Today I tried OpenGL mode, and the result was a totally black screen, but Stella was still running because the sound of the game was still playing, just no screen. And with a black screen, you can't see the menus to change it back.

There's also the keyboard shortcut 'Shift-Cmd g' to toggle between Software and OpenGL rendering dynamically (which I notice isn't actually in the manual ).

This is a 1.4 GHz iBook G4 running OSX 10.4. I have used OpenGL on Stella 2.0 without issues.

What video hardware does it have? I have limited access to OSX machines. Basically only the newer Intel iMacs (w/ ATI 9600 video) and PowerMac G5's (w/ Nvidia video). I've had reports things are working on Macbooks with Intel GMA950 video as well. The fact that it worked in 2.0 means that something changed in the code, so it's a good chance it can be fixed if I can track down the problem. And it's too bad, because Stella works best in OSX under OpenGL; better, in fact, than on Windows.

 

I don't suppose you're up to doing some bug testing? Try using the commandline option '-showinfo true', start Stella and switch to OpenGL mode, and let me know what output you get.

 

EDIT: Also, let me know what color depth and resolution you're using, as well as any other info you think might help.

Edited September 8, 2007 by stephena

[+batari]

Today I tried OpenGL mode, and the result was a totally black screen, but Stella was still running because the sound of the game was still playing, just no screen. And with a black screen, you can't see the menus to change it back.

There's also the keyboard shortcut 'Shift-Cmd g' to toggle between Software and OpenGL rendering dynamically (which I notice isn't actually in the manual ).

This is a 1.4 GHz iBook G4 running OSX 10.4. I have used OpenGL on Stella 2.0 without issues.

What video hardware does it have? I have limited access to OSX machines. Basically only the newer Intel iMacs (w/ ATI 9600 video) and PowerMac G5's (w/ Nvidia video). I've had reports things are working on Macbooks with Intel GMA950 video as well. The fact that it worked in 2.0 means that something changed in the code, so it's a good chance it can be fixed if I can track down the problem. And it's too bad, because Stella works best in OSX under OpenGL; better, in fact, than on Windows.

 

I don't suppose you're up to doing some bug testing? Try using the commandline option '-showinfo true', start Stella and switch to OpenGL mode, and let me know what output you get.

 

EDIT: Also, let me know what color depth and resolution you're using, as well as any other info you think might help.

Yes, OpenGL mode was a lot faster with Stella 2.0, especially with games with lots of screen activity.

 

Here's the info (edited for brevity.) My screen resolution is 1024x768.

Video rendering: Software mode

Color: 32 bit

Rmask = ff0000, Rshift = 16, Rloss = 0

Gmask = ff00, Gshift = 8, Gloss = 0

Bmask = ff, Bshift = 0, Bloss = 0

 

 

Video rendering: OpenGL mode

Vendor: ATI Technologies Inc.

Renderer: ATI Radeon 9200 OpenGL Engine

Version: 1.3 ATI-1.4.18

Color: 32 bit, 8-8-8-8

Filter: GL_NEAREST

Extensions: GL_TEXTURE_RECTANGLE_ARB

[+stephena]

Yes, OpenGL mode was a lot faster with Stella 2.0, especially with games with lots of screen activity.

 

Here's the info (edited for brevity.) My screen resolution is 1024x768.

Video rendering: Software mode

Color: 32 bit

Rmask = ff0000, Rshift = 16, Rloss = 0

Gmask = ff00, Gshift = 8, Gloss = 0

Bmask = ff, Bshift = 0, Bloss = 0

 

 

Video rendering: OpenGL mode

Vendor: ATI Technologies Inc.

Renderer: ATI Radeon 9200 OpenGL Engine

Version: 1.3 ATI-1.4.18

Color: 32 bit, 8-8-8-8

Filter: GL_NEAREST

Extensions: GL_TEXTURE_RECTANGLE_ARB

OK, I'll compare the code between the 2.0 and 2.4.1 release to see what's changed. I don't suppose you could try each version individually to see where it stopped working (2.0, 2.1, 2.2, 2.3, 2.3.5, 2.4, 2.4.1), to narrow it down a little? I suspect it was around 2.1/2.2 or so, when I went from statically linking the GL libaries to dynamic loading (although it could be the OSX improvments in 2.4 as well).

[+batari]

Yes, OpenGL mode was a lot faster with Stella 2.0, especially with games with lots of screen activity.

 

Here's the info (edited for brevity.) My screen resolution is 1024x768.

Video rendering: Software mode

Color: 32 bit

Rmask = ff0000, Rshift = 16, Rloss = 0

Gmask = ff00, Gshift = 8, Gloss = 0

Bmask = ff, Bshift = 0, Bloss = 0

 

 

Video rendering: OpenGL mode

Vendor: ATI Technologies Inc.

Renderer: ATI Radeon 9200 OpenGL Engine

Version: 1.3 ATI-1.4.18

Color: 32 bit, 8-8-8-8

Filter: GL_NEAREST

Extensions: GL_TEXTURE_RECTANGLE_ARB

OK, I'll compare the code between the 2.0 and 2.4.1 release to see what's changed. I don't suppose you could try each version individually to see where it stopped working (2.0, 2.1, 2.2, 2.3, 2.3.5, 2.4, 2.4.1), to narrow it down a little? I suspect it was around 2.1/2.2 or so, when I went from statically linking the GL libaries to dynamic loading (although it could be the OSX improvments in 2.4 as well).

OK, OpenGL works in 2.2, but not in 2.3.5. I haven't tested 2.3 but I can if that will help.

[+stephena]

Yes, OpenGL mode was a lot faster with Stella 2.0, especially with games with lots of screen activity.

 

Here's the info (edited for brevity.) My screen resolution is 1024x768.

Video rendering: Software mode

Color: 32 bit

Rmask = ff0000, Rshift = 16, Rloss = 0

Gmask = ff00, Gshift = 8, Gloss = 0

Bmask = ff, Bshift = 0, Bloss = 0

 

 

Video rendering: OpenGL mode

Vendor: ATI Technologies Inc.

Renderer: ATI Radeon 9200 OpenGL Engine

Version: 1.3 ATI-1.4.18

Color: 32 bit, 8-8-8-8

Filter: GL_NEAREST

Extensions: GL_TEXTURE_RECTANGLE_ARB

OK, I'll compare the code between the 2.0 and 2.4.1 release to see what's changed. I don't suppose you could try each version individually to see where it stopped working (2.0, 2.1, 2.2, 2.3, 2.3.5, 2.4, 2.4.1), to narrow it down a little? I suspect it was around 2.1/2.2 or so, when I went from statically linking the GL libaries to dynamic loading (although it could be the OSX improvments in 2.4 as well).

OK, OpenGL works in 2.2, but not in 2.3.5. I haven't tested 2.3 but I can if that will help.

If you can, please test 2.3 as well. I'd like to narrow it down as much as possible.

[alex_79]

Hi!

I've installed Stella 2.4.1 and I have problems with Secam emulation. All the PAL roms I've tried run slower in Secam mode (either by changing the game properties or using CTRL+F), while the speed should be the same for PAL and SECAM. I tried some of the PAL games adjusted for SECAM, like Mario Bros, Asteroids, Battlezone, Pole Position and Obelix.

Moreover I suggest to change the way Stella handle the TV format: currently it affects both speed/framerate (50 or 60Hz) and palette (PAL, NTSC and SECAM), while on real hardware the framerate results from the rom and not from the format of the console on which the game is running. So I think the speed should be determined only by the scanline count, no matter what palette is selected (Z26 works this way). This would avoid the need for a "PAL 60" mode too.

[+stephena]

Hi!

I've installed Stella 2.4.1 and I have problems with Secam emulation. All the PAL roms I've tried run slower in Secam mode (either by changing the game properties or using CTRL+F), while the speed should be the same for PAL and SECAM. I tried some of the PAL games adjusted for SECAM, like Mario Bros, Asteroids, Battlezone, Pole Position and Obelix.

Moreover I suggest to change the way Stella handle the TV format: currently it affects both speed/framerate (50 or 60Hz) and palette (PAL, NTSC and SECAM), while on real hardware the framerate results from the rom and not from the format of the console on which the game is running. So I think the speed should be determined only by the scanline count, no matter what palette is selected (Z26 works this way). This would avoid the need for a "PAL 60" mode too.

I may have screwed up the SECAM handling, since I don't have any of those carts, and have zero experience with it. My interpretation of the different modes is as follows (this is what's in Stella right now):

 

NTSC - 60 Hz, ~262 scanlines, NTSC palette

PAL - 50 Hz, ~312 scanlines, PAL palette

SECAM - 50 Hz, ~312 scanlines, SECAM palette

PAL60 - 60 Hz, ~262 scanlines, PAL palette

 

The speed currently is determined by the scanline count, at least when the cart type is set to 'Auto-detect' (which it is by default). However, there still needs to be a way to specify SECAM and PAL60, otherwise PAL60 ROMs are mis-detected as NTSC, and SECAM are mis-detected as PAL. The scanline count alone isn't enough to uniquely identify the 4 possibilities; it will only determine NTSC or PAL.

 

What I really need is (a) a definitive description of all 4 possibilities (and if my assumptions are correct), and (b) a sample of all 4 types of ROMs, including snapshots from an actual system.

[alex_79]

My interpretation of the different modes is as follows (this is what's in Stella right now):

 

NTSC - 60 Hz, ~262 scanlines, NTSC palette

PAL - 50 Hz, ~312 scanlines, PAL palette

SECAM - 50 Hz, ~312 scanlines, SECAM palette

PAL60 - 60 Hz, ~262 scanlines, PAL palette

they are correct. The fact is that the PAL roms I listed in my previous thread run slower in Stella when in SECAM mode, while the speed should be the same (50 Hz, 312 scanlines). Those games were programmed by Atari to show proper colors on both PAL and SECAM consoles (there aren't SECAM-only roms).

 

The speed currently is determined by the scanline count, at least when the cart type is set to 'Auto-detect' (which it is by default).

 

Yes, and it's correct in autodetect mode. What I mean is that the speed shouldn't change even when you force a different TV format, to properly emulate what happens when you mix different carts and consoles. On real hardware, a NTSC cart will run at 60Hz no matter what the format of the console is. Only the colors will be wrong on PAL and SECAM machines. Since PAL TV usually can do 60Hz without problems, some homebrews' authors converted their NTSC games for use with PAL consoles only by changing the palette, obtaining PAL60 games. So Stella should allow to cycle only through:

 

NTSC, PAL60 and SECAM60, for games with ~262 scanlines

NTSC50, PAL and SECAM, for games with ~312 scanlines

 

However, there still needs to be a way to specify SECAM and PAL60, otherwise PAL60 ROMs are mis-detected as NTSC, and SECAM are mis-detected as PAL. The scanline count alone isn't enough to uniquely identify the 4 possibilities; it will only determine NTSC or PAL.

There's no way to autodetect the difference between NTSC and PAL60 (and there aren't SECAM-only games, but only a few PAL games programmed to show decent colors on SECAM), so assuming NTSC for 60Hz and PAL for 50Hz is the best way IMO.

[+stephena]

Yes, and it's correct in autodetect mode. What I mean is that the speed shouldn't change even when you force a different TV format, to properly emulate what happens when you mix different carts and consoles. On real hardware, a NTSC cart will run at 60Hz no matter what the format of the console is. Only the colors will be wrong on PAL and SECAM machines. Since PAL TV usually can do 60Hz without problems, some homebrews' authors converted their NTSC games for use with PAL consoles only by changing the palette, obtaining PAL60 games. So Stella should allow to cycle only through:

 

NTSC, PAL60 and SECAM60, for games with ~262 scanlines

NTSC50, PAL and SECAM, for games with ~312 scanlines

OK, but that means I need to create formats for SECAM60 and NTSC50 as well. You see, the current cycling goes through all the possibilities, and sets certain internal properties based on the current mode. So if, for example, I switch to NTSC50, there must be a corresponding 'configuration' for it, since we might want to save that particular mode for use with that ROM. Basically, I'd need to create the modes NTSC, PAL60, SECAM60, NTSC50, PAL, SECAM, and cycle through the ones that correspond to the respective scanline count.

 

So to be clear, I need these modes:

 

NTSC - 60 Hz, ~262 scanlines, NTSC palette

PAL60 - 60 Hz, ~262 scanlines, PAL palette

SECAM60 - 60 Hz, ~262 scanlines, SECAM palette

 

NTSC50 - 50 Hz, ~312 scanlines, NTSC palette

PAL - 50 Hz, ~312 scanlines, PAL palette

SECAM - 50 Hz, ~312 scanlines, SECAM palette

 

And if there are 262 scanlines, cycle through the first list, otherwise use the second. Does this cover all possibilities??

[+batari]

If you can, please test 2.3 as well. I'd like to narrow it down as much as possible.

OpenGL works in 2.3.

[Mauvila]

Version 2.4 : It sort of works with my setup...if I TAB into the menu, I can set it to OpenGL and it will run, but when I hit escape after that, it crashes. When I restart with OpenGL already set, I can select a game, but it silently crashes instead of opening it. I seem to remember this on whatever version was out a few months ago (2.2?)...at least I remember that OpenGL mode didn't work with my setup.

[+stephena]

If you can, please test 2.3 as well. I'd like to narrow it down as much as possible.

OpenGL works in 2.3.

So the problem is between 2.3 and 2.3.5, is that correct? OK, at least I have somewhere to start now. And here I was thinking the problem was in 2.3, and already had a possible solution

[+stephena]

Version 2.4 : It sort of works with my setup...if I TAB into the menu, I can set it to OpenGL and it will run, but when I hit escape after that, it crashes. When I restart with OpenGL already set, I can select a game, but it silently crashes instead of opening it. I seem to remember this on whatever version was out a few months ago (2.2?)...at least I remember that OpenGL mode didn't work with my setup.

Are you using Vista? I've seen this problem in Vista, where it seems OpenGL works only when you open the first window (ie, you start the game or the launcher). But as soon as a new SDL window is created (launching a game from the launcher), it crashes. Try dynamically switching between software and OpenGL modes with 'Alt g'. I'll bet it happens then, too. I'm looking into this, but I think it's a problem with OpenGL/SDL and Vista in general.

 

If you're not using Vista, then I have no idea what's going on. Please provide your version of Windows, video card, drivers, etc.

[Mauvila]

Version 2.4 : It sort of works with my setup...if I TAB into the menu, I can set it to OpenGL and it will run, but when I hit escape after that, it crashes. When I restart with OpenGL already set, I can select a game, but it silently crashes instead of opening it. I seem to remember this on whatever version was out a few months ago (2.2?)...at least I remember that OpenGL mode didn't work with my setup.

Are you using Vista? I've seen this problem in Vista, where it seems OpenGL works only when you open the first window (ie, you start the game or the launcher). But as soon as a new SDL window is created (launching a game from the launcher), it crashes. Try dynamically switching between software and OpenGL modes with 'Alt g'. I'll bet it happens then, too. I'm looking into this, but I think it's a problem with OpenGL/SDL and Vista in general.

 

If you're not using Vista, then I have no idea what's going on. Please provide your version of Windows, video card, drivers, etc.

 

Yup, Vista. That's why I wasn't really phased by it not working this time. Half my stuff doesn't work on Vista. Vista doesn't work well with iPhone either. Which reminds me... iStella - Stella for the iPhone & iPod Touch. Someone should do that.

[alex_79]

So to be clear, I need these modes:

 

NTSC - 60 Hz, ~262 scanlines, NTSC palette

PAL60 - 60 Hz, ~262 scanlines, PAL palette

SECAM60 - 60 Hz, ~262 scanlines, SECAM palette

 

NTSC50 - 50 Hz, ~312 scanlines, NTSC palette

PAL - 50 Hz, ~312 scanlines, PAL palette

SECAM - 50 Hz, ~312 scanlines, SECAM palette

 

And if there are 262 scanlines, cycle through the first list, otherwise use the second. Does this cover all possibilities??

Yes.

 

It's just a detail, but another issue with SECAM consoles is that the "software" TV TYPE switch is hardwired to B&W (bit D3 of SWCHB is always 0). The actual switch on the console is wired to the video circuitry instead and turn the colors off when in B&W position. If it's simple to implement, Stella could automatically set that switch to B&W when chosing SECAM mode. Or you can mention in the manual that for proper SECAM emulation users must do that by pressing F4.

[+stephena]

So to be clear, I need these modes:

 

NTSC - 60 Hz, ~262 scanlines, NTSC palette

PAL60 - 60 Hz, ~262 scanlines, PAL palette

SECAM60 - 60 Hz, ~262 scanlines, SECAM palette

 

NTSC50 - 50 Hz, ~312 scanlines, NTSC palette

PAL - 50 Hz, ~312 scanlines, PAL palette

SECAM - 50 Hz, ~312 scanlines, SECAM palette

 

And if there are 262 scanlines, cycle through the first list, otherwise use the second. Does this cover all possibilities??

Yes.

 

It's just a detail, but another issue with SECAM consoles is that the "software" TV TYPE switch is hardwired to B&W (bit D3 of SWCHB is always 0). The actual switch on the console is wired to the video circuitry instead and turn the colors off when in B&W position. If it's simple to implement, Stella could automatically set that switch to B&W when chosing SECAM mode. Or you can mention in the manual that for proper SECAM emulation users must do that by pressing F4.

OK, I went ahead and implemented the modes as described above, and it will be included in the next release of Stella. I'll have to look into your suggestion about the TV Type/B&W switch. Do you know where can I find documentation on these SECAM 'quirks'?

[alex_79]

OK, I went ahead and implemented the modes as described above, and it will be included in the next release of Stella.

Great! Thanks!

 

I'll have to look into your suggestion about the TV Type/B&W switch. Do you know where can I find documentation on these SECAM 'quirks'?

There are some info in the "Stella programmer's guide":

 

 

PAL/SECAM CONVERSIONS

PAL
 1. The number of scan lines, and therefore the frame time
 increases from NTSC to PAL according to the following
 table:

						  NTSC						 PAL
					 scan micro		  scan micro
					 lines	 seconds   lines	 seconds
		   VBLANK	40   2548	  48   3085
		   KERNAL	192  12228		  228  14656
		   OVERSCAN  30   1910	  36   2314
		   FRAME		  262  16686		  312  20055

 2. Sounds will drop a little in pitch (frequency) because
 of a slower crystal clock.  Some sounds may need the
 AUDF0/AUDF1 touched up.

 3. PAL operates at 50 Hz compared to NTSC 60Hz, a 17%
 reduction.  If game play speed is based on frames per
 second, it will slow down by 17%.  This can be disastrous
 for most skill/action carts.  If the NTSC version is
 designed with 2 byte fractional addition techniques (or
 anything not based on frames per second) to move objects,
 then PAL conversion can be as simple as changing the
 fraction tables, avoiding major surgery on the program.

SECAM
 1. SECAM is a little weird.  It takes the PAL software, but
 the console color/black & white switch is hardwired as
 black & white.  Therefore, it reads the PAL black & white
 tables in software and assigns a fixed color to each lum of
 black & white according to the following table:

				Lum  Color
				0	Black
				2	Blue
				4	Red
				6	Magenta
				8	green
				A	cyan
				C	yellow
				E	white

 There is a trap here:  the manual is the same for NTSC,
 PAL, & SECAM.  This means that the descriptions for black &
 white must jive between NTSC & PAL.  If you make major
 changes to PAL black & white to achieve good SECAM color,
 NTSC black & white must be made similar.

 2. PAL sounds work fine on SECAM with one exception: when a
 sound is to be turned off, it must be one by setting
 AUDV0/AUDV1 to 0, not by setting AUDC0/AUDC1 to 0.
 Otherwise, you get an obnoxious background sound.

 

 

The odd design allowed the use of existing hardware and the ability to produce only one version of a game for both PAL and SECAM. Creating a new TIA for French market only was too expensive, so the solution was to connect the 3 TIA luma pins to an external circuit which generates the 8 colors of SECAM palette. (Actually there's a NTSC TIA on secam boards! See this topic). IMO The TV TYPE switch was hardwired to B&W so that even PAL games programmed before the SECAM vcs release (~1980) could be played on the console. Those early games usually have separate palette for color and b&w and only the b&w one assures that different objects on the screen are displayed with different luma values (= different colors in SECAM palette). Moreover this would have allowed to program new PAL games with a separate palette for SECAM, but none of the PAL/SECAM games I tried use that: there's only one palette with luma values adjusted to show decent SECAM colors.

 

 

here some threads about SECAM 2600:

 

http://www.atariage.com/forums/index.php?showtopic=29222

http://www.atariage.com/forums/index.php?showtopic=51963

http://www.atariage.com/forums/index.php?showtopic=10800

 

 

Activision PAL/Secam games:

 

http://www.atariage.com/forums/index.php?showtopic=101241

http://www.atariage.com/forums/index.php?showtopic=50225

[+stephena]

here some threads about SECAM 2600:

 

http://www.atariage.com/forums/index.php?showtopic=29222

http://www.atariage.com/forums/index.php?showtopic=51963

http://www.atariage.com/forums/index.php?showtopic=10800

 

 

Activision PAL/Secam games:

 

http://www.atariage.com/forums/index.php?showtopic=101241

http://www.atariage.com/forums/index.php?showtopic=50225

OK, this is good stuff; it should really help me out. This part of the SECAM emulation will probably have to wait until the TIA rewrite, since it interacts with that part of the code. But the modes you described in a previous message have already been completed, and will be included in the next point release (which will be out very soon, as it fixes an OpenGL bug as well).

[supercat]

The odd design allowed the use of existing hardware and the ability to produce only one version of a game for both PAL and SECAM. Creating a new TIA for French market only was too expensive, so the solution was to connect the 3 TIA luma pins to an external circuit which generates the 8 colors of SECAM palette. (Actually there's a NTSC TIA on secam boards! See this topic).

 

Since SECAM totally ignores the TIA's color-encoding circuitry, and since the NTSC 2600 only requires one crystal compared with two for PAL, using an NTSC chip makes sense I would think.

 

I guess using the luma pins as RGB was a quick and easy way of getting RGB "color" out of a TIA chip, but I'm a little puzzled as to why Atari didn't use the chroma signal at all. If nothing else, generating R & Sysclk & Chroma, B & Sysclk & Chroma, and G & SysClk & Chroma, and filtering those outputs would have allowed for 15 brightness levels of 6 colors/gray.