Stella 3.7 released

[+stephena]

OK, for the endless loop problem, you're saying that the screen should go blank immediately, or at least when you go over the max # of scanlines (approx 320 or so)? Is this what happens on a real system (I'll have to test myself later this morning)?? There's code in Stella to blank the display on a transition from large scanline count to normal count (eg in Q-Bert, when you let go of the reset key), but not when you transition from normal to high. Perhaps I have the logic reversed.

 

For the NTSC/PAL problem, first of all, what would happen on a real PAL TV and system? What's happening here is that you're running at 312 scanlines (which is automatically detected by Stella, hence the PAL*), but then you later switch to 262 scanlines. So on a PAL machine (which is still PAL, of course), you draw at NTSC framerate and use NTSC colours. But you're still on a PAL machine, so the colours will be off. This can be seen with Alt-L, because although it toggles from 312/PAL to 262/NTSC and back, the actual machine being emulated is still PAL (indicated with PAL*). I think this is accurate. If you're on a PAL machine, changing properties in your ROM can't magically change the properties of the console or TV you're using.

 

Now that being said, there still should be a way of changing this after the autodetection has run. That's what I was referring to with Control-f. My only issue is whether all this should be automatic (ie, Stella will change its internal settings based on what the ROM tells it to do) or manual (ie, you have to explicitly press a key to toggle it).

 

EDIT: Adding an option to do this is another possibility, where the default is ROMs can't change the machine type. Basically, I want the default behaviour to be what would happen on a real system (and not having a PAL machine, I can't say for sure). Perhaps it's time to solicit a donation of a PAL console ...

[LidLikesIntellivision]

(...) Perhaps it's time to solicit a donation of a PAL console ...

 

Haven't you got all systems already? :-o

For your good work you truly deserve all of them.

 

If I had a PAL I would certainly give you.

I only have a bad PAL-M (Brazilian) console wich works with NTSC cartridges... I think it's basicly an NTSC console with some sort of "decoder" to PAL-M.

If you're interested, I can send you my bad PAL-M Atari (have some issues with the image quality) or even look for a good one... But I don't know if it's important to have the Brazilian PAL-M, since it works with NTSC carts...

[+stephena]

(...) Perhaps it's time to solicit a donation of a PAL console ...

 

Haven't you got all systems already? :-o

For your good work you truly deserve all of them.

 

Unfortunately, the hardware I have is pretty limited considering the work I do. You're right that ideally, to properly emulate all systems I'd actually have them on hand. But I don't ...

 

If I had a PAL I would certainly give you.

I only have a bad PAL-M (Brazilian) console wich works with NTSC cartridges... I think it's basicly an NTSC console with some sort of "decoder" to PAL-M.

If you're interested, I can send you my bad PAL-M Atari (have some issues with the image quality) or even look for a good one... But I don't know if it's important to have the Brazilian PAL-M, since it works with NTSC carts...

 

Well, of course I will accept any donation you want to give, but in this case I'd need a real PAL console, to see exactly what would happen. If you're willing to donate the PAL-M you have, please contact me by PM.

[+stephena]

The first issue (EndlessLoop) is confirmed and now fixed. I had the logic reversed, whereby it was blanking on the transition from illegal count to legal count, when it should be the other way around (as soon as you press Reset and the count goes illegal the first time, the screen goes blank). This fix will be included in the next release.

 

As for the second issue, that's more involved, and requires testing on a real PAL machine.

 

EDIT: There are two things going on for the second issue. The second thing (running NTSC code on a PAL machine) has been discussed above. The main issue at this point, though, is that Stella doesn't seem to emulate screen roll. So when starting the ROM, the machine comes up as PAL and properly shows "I'm PAL". Then when switching to NTSC mode, the screen should roll (this needs to be confirmed on actual hardware). Similarly, when launching the ROM on an NTSC machine, it rolls on the default PAL mode, until you switch to NTSC, in which case it properly shows "I'm NTSC". So in both cases, screen roll isn't properly emulated.

[LidLikesIntellivision]

(...) If you're willing to donate the PAL-M you have, please contact me by PM.

 

PM sent

 

That's for the PAL-M, he still needs a PAL for testing and improving our loved Stella.

[+SpiceWare]

I didn't think I'd care for it, but I quite like the RGB setting for the blargg effects!

 

Improving display autodetection is actually on the TODO list, since I've seen other ROMs that can switch from NTSC to PAL at runtime, after the autodetection has already run.

 

I just ran into something yesterday that took half the day to figure out while working on Space Rocks. I think it's related to autodetection.

 

In DPC+ the ROM consists of banks 0-5 and a 4K RAM section known as Display Data. There's actually a bank 6 that holds the initial state of the 4K RAM. While bank 6 cannot be selected via a bank switch hotspot, the C code that the ARM runs can easily access data found there.

 

For Space Rocks, I wrote a vector tool in PHP. It converts solid images into outlined "vector" images. It does this by looking at the inner pixels of the original image (it skips the first and last row of the image as well as bit 0 and 7 of each row) and it turns off any pixel if it's immediate neighbors (north, south, east and west, ignoring diagonals) are all turned on.

 

I'm not using the full 4K of RAM in Space Rocks, so I realized I could write a vector routine in the C code and have it run once when the cartridge is first turned on. When I first wrote it, I used XOR to toggle the bits and the routine didn't work. I then changed it to subtract the bits and the routine resulted in strange looking "shadowed" asteroids. I tried other things like RAM = ROM ^ 255 and confirmed the C init routine was running as I got inverted asteroid graphics.

 

I finally put the ROM into the Harmony and it worked correctly. That's when I realized that in Stella the Initialize() function was getting called twice. This explains the xor method appearing to not work as it turned off the pixels on the first call, but then turned them all back on during the second call.

 

I was able to work around it by manually copying the ROM data to the RAM before it starts to turn bits off.

 

The vectorizing routines increased the C code by 164 bytes, but so far I've been to save 1315 bytes by eliminating the vector images for the medium asteroids and the ship - so my net gain so far is 1151 bytes!

 

For testing, I set up a static counter in my C code's Initialize() function and set the Last Score to the value of the counter.

Stella:

 

Atari:

 

ROM:

spacerocks20120603_init_issue.bin

[Omegamatrix]

The first issue (EndlessLoop) is confirmed and now fixed. I had the logic reversed, whereby it was blanking on the transition from illegal count to legal count, when it should be the other way around (as soon as you press Reset and the count goes illegal the first time, the screen goes blank). This fix will be included in the next release.

 

As for the second issue, that's more involved, and requires testing on a real PAL machine.

 

EDIT: There are two things going on for the second issue. The second thing (running NTSC code on a PAL machine) has been discussed above. The main issue at this point, though, is that Stella doesn't seem to emulate screen roll. So when starting the ROM, the machine comes up as PAL and properly shows "I'm PAL". Then when switching to NTSC mode, the screen should roll (this needs to be confirmed on actual hardware). Similarly, when launching the ROM on an NTSC machine, it rolls on the default PAL mode, until you switch to NTSC, in which case it properly shows "I'm NTSC". So in both cases, screen roll isn't properly emulated.

 

 

I'm glad the Endless Loop bug is fixed. I think the second bug might be related to it. Specifically take a closer look at the rom. The issues is "I'm PAL" should never been drawn once you enter NTSC mode. The "I'm PAL" is left over from a previous frame.

 

 

As for rolling, this is what I would expect on older TV's. I'm really trying to play this on an NTSC TV, so I would expect rolling and "off" colors until I go into NTSC mode.

[+stephena]

I finally put the ROM into the Harmony and it worked correctly. That's when I realized that in Stella the Initialize() function was getting called twice. This explains the xor method appearing to not work as it turned off the pixels on the first call, but then turned them all back on during the second call.

 

Yes, it looks like that's what's happening. In fact, I ran into similar issues with what I call 'smart' controllers like the AtariVox and SaveKey. Running the system for 60 frames at the beginning, reseting and then running again was screwing up the controller state, so I had to completely remove them from the autodetection. Maybe something isn't being reset when CartDPC+ is being reset. I'll look into it.

[+stephena]

I'm glad the Endless Loop bug is fixed. I think the second bug might be related to it. Specifically take a closer look at the rom. The issues is "I'm PAL" should never been drawn once you enter NTSC mode. The "I'm PAL" is left over from a previous frame.

 

It looks like the previous frame, but it's a bit more complicated than that (if it were just leftover data, I could simply force a screen refresh and be done with it). What's actually happening is that the virtual TIA still thinks it is PAL, and draws as many lines as PAL would generate, even when there aren't that many generated. I make this distinction because the drawing is active; it's not so much garbage from the previous frame as it is being told to draw more than it should.

[+SpiceWare]

Maybe something isn't being reset when CartDPC+ is being reset. I'll look into it.

It'd be the contents of the RAM. While Display Data has 4K, there's actually 5K that would need to be reset. The extra 1K is the "frequency data" that appears in the memory map just after the Display Data. The ROM image for that 1K would be a "1K bank 7" that appears just after the "4K bank 6"

 

I'm taking a guess that reset() is called after the 60 frame test? If so this might fix it:

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
void CartridgeDPCPlus::reset()
{
 // Update cycles to the current system cycles
 mySystemCycles = mySystem->cycles();
 myFractionalClocks = 0.0;

 // Copy initial DPC display data and Frequency table state to Harmony RAM
 memcpy(myDisplayImage, myProgramImage + 0x6000, 0x1400);

 // Upon reset we switch to the startup bank
 bank(myStartBank);

}

 

I haven't tested it because I've got the old 3.4 source. I'm getting ready to head out to meet some friends for lunch and to see MIB. If you've not tested this by the time I return this evening, then I'll download the latest source and give it a try.

[+stephena]

It'd be the contents of the RAM. While Display Data has 4K, there's actually 5K that would need to be reset. The extra 1K is the "frequency data" that appears in the memory map just after the Display Data. The ROM image for that 1K would be a "1K bank 7" that appears just after the "4K bank 6"

 

I was thinking along similar lines, and noticed that some of the stuff set in the c'tor needs to be reset in ::reset(). And indeed, it seems to take care of the issue. One other thing I noticed though, state saving doesn't seem to be working. Maybe because the Thumb state isn't saved at all (is that even necessary), or something else is missing in the ::save() method.

 

EDIT: State saving is now working too. It was all related to the DPC RAM; it wasn't being properly reset or saved/loaded.

[+stephena]

OK, I got a little sidetracked there; back to the NTSC/PAL issues. Could someone try the ROM that Omega provided above on a PAL machine, and see what happens when you switch the ROM to NTSC (screen roll, stable image nearer to top of screen, colours used, etc). I already know what happens when trying to run in PAL mode on an NTSC machine, and I feel Stella currently emulates it pretty well.

[Omegamatrix]

What I would expect to see on a PAL console (If the TV could handle a NTSC signal) is a top aligned image with PAL colors, with nothing but blackness below:

 

 

 

 

 

If the TV can't handle an NTSC signal then it should roll.

 

 

Edit: And in any case the small portion of "I'm PAL" shouldn't appear at all.

Edited June 3, 2012 by Omegamatrix

[Omegamatrix]

It looks like the previous frame, but it's a bit more complicated than that (if it were just leftover data, I could simply force a screen refresh and be done with it). What's actually happening is that the virtual TIA still thinks it is PAL, and draws as many lines as PAL would generate, even when there aren't that many generated. I make this distinction because the drawing is active; it's not so much garbage from the previous frame as it is being told to draw more than it should.

 

Stephena, just to clarify I understand that when switching to NTSC mode the window size is still remaining at the height it was while drawing the PAL portion of the rom. However, when I go into NTSC mode I am not printing the "I'm PAL" letters at all. In post 32 the tips of the arrows are roughly where I'm starting VSYNC in the NTSC rom.

 

So the "I'm PAL" is only appearing in Stella because it is an older image stored in some buffer. If this was on a real PAL CRT (that could handle the NTSC signal) then the very, very bottom portion would not be striked with the electron beam as the scanlines are to few. If you turned up the brightness you would see a chunk of black screen under the purple/blue that is "blacker then black" as I'm using Vblank. Then below that would be another region of black that is not as dark, where the beam is not hitting.

 

The purpose of the NTSC vs PAL demo is just to illustrate that the "I'm PAL" is still showing up, when it is never drawn.

[+stephena]

It looks like the previous frame, but it's a bit more complicated than that (if it were just leftover data, I could simply force a screen refresh and be done with it). What's actually happening is that the virtual TIA still thinks it is PAL, and draws as many lines as PAL would generate, even when there aren't that many generated. I make this distinction because the drawing is active; it's not so much garbage from the previous frame as it is being told to draw more than it should.

 

Stephena, just to clarify I understand that when switching to NTSC mode the window size is still remaining at the height it was while drawing the PAL portion of the rom. However, when I go into NTSC mode I am not printing the "I'm PAL" letters at all. In post 32 the tips of the arrows are roughly where I'm starting VSYNC in the NTSC rom.

 

So the "I'm PAL" is only appearing in Stella because it is an older image stored in some buffer. If this was on a real PAL CRT (that could handle the NTSC signal) then the very, very bottom portion would not be striked with the electron beam as the scanlines are to few. If you turned up the brightness you would see a chunk of black screen under the purple/blue that is "blacker then black" as I'm using Vblank. Then below that would be another region of black that is not as dark, where the beam is not hitting.

 

The purpose of the NTSC vs PAL demo is just to illustrate that the "I'm PAL" is still showing up, when it is never drawn.

 

Right, I understand what you're saying. Perhaps I was just adding too much detail to my explanation. My point was that the 'garbage data' you see is actually being drawn every frame because Stella is drawing past the total # of scanlines that it should. I understand that it wouldn't happen on a real system, I was just clarifying exactly what Stella is (incorrectly) doing.

[alex_79]

Most PAL TVs can display a 60Hz signal correctly. In that case not only the screen doesn't roll, but it's also stretched vertically so that the the picture fills the entire screen without a black bar on the bottom.

This is Omega's test rom on the crt TV I use for gaming:

 

Here another example with the game "oystron" which uses the right difficulty switch to select between 60Hz or 50Hz. As you can see at 60Hz the aspect ratio is the same than on NTSC console/TV, of course with PAL palette.

[+stephena]

Most PAL TVs can display a 60Hz signal correctly. In that case not only the screen doesn't roll, but it's also stretched vertically so that the the picture fills the entire screen without a black bar on the bottom.

 

OK, now I'm confused. In fact, PAL systems have always confused me, since I've never actually seen one before. Is a PAL TV higher than an NTSC one? Or are they the same height, and each line is thinner on the PAL TV?? I'm having a hard time understanding how the NTSC image could be stretched. If there's a 1-to-1 correspondence between NTSC and PAL scanline 'height', I would think an NTSC image would be closer to the top of the screen on a PAL TV. But if it fills out the same area as a PAL image, then the scanline heights must be different. In any event, the former is easy to do (Stella already does it), the latter much less so. I wonder, is there something else going on in this TV, where it stretches the image for you (sort of like how a fullscreen image can be stretched horizontally to get rid of black bars)?

[alex_79]

The screen aspect ratio is 4/3 for both PAL and NTSC, but PAL scanlines are more compressed vertically. Most PAL TVs automatically stretch the display if they detect a 60Hz signal, and in that case the scanline height become the same as in NTSC TVs.

 

If the TV doesn't handle the 60Hz signal, then you can either get a stable image on top of the screen, with a wide black area on the bottom or a rolling picture. I've seen both behaviours on different TVs, so there's not a general rule.

[Eckhard Stolberg]

Most PAL TVs can display a 60Hz signal correctly. In that case not only the screen doesn't roll, but it's also stretched vertically so that the the picture fills the entire screen without a black bar on the bottom.

 

OK, now I'm confused. In fact, PAL systems have always confused me, since I've never actually seen one before. Is a PAL TV higher than an NTSC one? Or are they the same height, and each line is thinner on the PAL TV?? I'm having a hard time understanding how the NTSC image could be stretched. If there's a 1-to-1 correspondence between NTSC and PAL scanline 'height', I would think an NTSC image would be closer to the top of the screen on a PAL TV. But if it fills out the same area as a PAL image, then the scanline heights must be different. In any event, the former is easy to do (Stella already does it), the latter much less so. I wonder, is there something else going on in this TV, where it stretches the image for you (sort of like how a fullscreen image can be stretched horizontally to get rid of black bars)?

The aspect ratio is 4:3 or 16:9 on PAL TVs as it is on NTSC TVs. So the lines on a PAL TV are thinner than on a NTSC TV. But Alex's TV isn't a PAL TV, it's a multi-standard TV that is capable of displaying many different TV standards from all around the world. This is why it can change the thickness of the lines when switching from 50 Hz images to 60 Hz images. Most TVs in Europe are like this nowadays. On an old PAL-only TV things would be as you expected. The 60 Hz image would be displayed at the top of the screen with black filling the bottom.

[+stephena]

OK, I prefer to emulate a real 50Hz-only PAL TV with NTSC image at the top, as Stella already does this. There will also be keys to dynamically switch between PAL and NTSC modes, which simulates what Alex's TV does automatically.

[Eckhard Stolberg]

OK, I prefer to emulate a real 50Hz-only PAL TV with NTSC image at the top, as Stella already does this. There will also be keys to dynamically switch between PAL and NTSC modes, which simulates what Alex's TV does automatically.

You'd still need to address the issue with Omegamatrix's ROM though. I think the problem could be fixed if you filled the remainder of the internal screen buffer with black pixels if necessary when VSYNC is triggered. That might also be useful if a badly programmed game occasionally does too little scanlines.

[Omegamatrix]

Stephen, just wanted to say thanks once again for all your improvements to Stella. I really so hope these test roms help. Most of them aren't so bad to make. The RSYNC one was a little involved ha ha. At least when it comes time for implementation you can compare Stella to what you are seeing on your TV.

 

 

OK, now I'm confused. In fact, PAL systems have always confused me, since I've never actually seen one before. Is a PAL TV higher than an NTSC one? Or are they the same height, and each line is thinner on the PAL TV?? I'm having a hard time understanding how the NTSC image could be stretched. If there's a 1-to-1 correspondence between NTSC and PAL scanline 'height', I would think an NTSC image would be closer to the top of the screen on a PAL TV. But if it fills out the same area as a PAL image, then the scanline heights must be different. In any event, the former is easy to do (Stella already does it), the latter much less so. I wonder, is there something else going on in this TV, where it stretches the image for you (sort of like how a fullscreen image can be stretched horizontally to get rid of black bars)?

 

 

A little off topic, but I used to be confused by PAL-M. I originally understood it as PAL-M ran at 60 HZ like NTSC, but used PAL colors. This is true for the PAL-M TV's. However, when you program a PAL-M game for the 2600 you need to use NTSC colors. This is because the PAL-M 2600 hardware does a conversion from the NTSC palette to the PAL one.

 

 

This seems like a clever idea made by the hardware designers. This way the programmers don't have to change anything to have their NTSC program run on a PAL-M 2600. It will work as is.

[+stephena]

You'd still need to address the issue with Omegamatrix's ROM though. I think the problem could be fixed if you filled the remainder of the internal screen buffer with black pixels if necessary when VSYNC is triggered. That might also be useful if a badly programmed game occasionally does too little scanlines.

 

Of course you're right, and that is approach I'm going to take (in fact, there's already related code there that blanks the screen if the scanline count goes past a certain point). I just wanted to make sure I fully understand what is supposed to be happening before I start coding it.

[+stephena]

The garbage data generated by irregular scanline counts is now fixed. If the display tries to generate too many scanlines, the entire screen is blanked. And if the current frame has less scanlines than the previous one, the excess scanlines are blanked. This will be present in 3.7.1.

[+SpiceWare]

I was thinking along similar lines, and noticed that some of the stuff set in the c'tor needs to be reset in ::reset().

 

Three additional changings, all in the constructor function:

  // Pointer to the Frequency RAM
 myFrequencyImage = myDisplayImage + 0x1000;
...
 // If the image is larger than 29K, we assume any excess at the
 // beginning is ARM code, and skip over it
 if(size > 29 * 1024)
 {
int offset = size - 29 * 1024;
myProgramImage   += offset;
//	myDisplayImage   += offset;
//	myFrequencyImage += offset;
 }
...
 // Copy initial DPC display data and Frequency table state to Harmony RAM
 memcpy(myDisplayImage, myProgramImage + 0x6000, 0x1400);

 

myFrequencyImage should be pointing to the RAM copy of the frequency data as the frequency table can be changed on the fly. I'll be using that when I add digitized speech back into Frantic.

 

Edit: I forgot to include the change in the offset adjustment.

Edited June 4, 2012 by SpiceWare