Testing the new Stella TIA core

[+SpiceWare]

Confirmed, and issue created here.

That was fast, looks like the fix is already in place!

 

Tonight I'll have to read up on the new way to get the latest source as I'd nabbed the zipped source for pre4 from here when I started to work on the new CDF bankswitch scheme.

[+SpiceWare]

In regards to TV jitter Issue #11, I have a sticky note on my dashboard about a bug that was introduced into the jitter logic.

 

That link is to this:

Yes, on real hardware. I just tested it using jitter.bin to confirm it by changing the number to 127 (or 129) then repeatedly hitting fire - the screen jitters up/down.

 

It should have in Stella too, it did so when I first implemented jitter support. I just tested that build and the second one to confirm it; however, as of the third build it only jitters if the difference is 2 scanlines. As such I must have changed something on accident when I added recovery time(that's when it takes multiple frames to recover from a large change in scanline count). I've added looking into that to my To Do list.

I don't know if this is common knowledge, but you can use the curved arrow at the top-right of the quoted text to jump to the original reply in order to see it in context.

[Keatah]

This homebrew w.i.p. doesn't seem to work in stella. But it supposedly works on real hardware.

http://atariage.com/forums/topic/262864-defender-iii-atari-flashback-portable/?do=findComment&comment=3709415

[+stephena]

This homebrew w.i.p. doesn't seem to work in stella. But it supposedly works on real hardware.

http://atariage.com/forums/topic/262864-defender-iii-atari-flashback-portable/?do=findComment&comment=3709415

 

Added as issue https://github.com/stella-emu/stella/issues/98.

[DirtyHairy]

I think that this an issue connected to the initial state of CBS and RIOT RAM (and thus propably not an emulation issue). In this case, testing on harmony won't get much closer to real hardware as CBS RAM is emulated there, too.

[+stephena]

Stella 5.0.0-pre5 is now available for testing: https://github.com/stella-emu/stella/releases

[Keatah]

The tick-mark is back in VideoChess. In pre5.

Edited March 4, 2017 by Keatah

[+stephena]

The tick-mark is back in VideoChess. In pre5.

 

If you're referring to the little bit of extra scanline extending into the black area on the left side of the image, then this is correct behaviour as observed on a real console. This comes from either the improvements to NUSIZ or RESMx (I forget which one).

[+stephena]

BTW, unrelated to this, but has anyone noticed that AtariAge is extremely laggy for the past day or so. I'm getting timeouts waiting for pages to load, unable to leave comments, etc.

[Keatah]

Also noticed (near the same area) another stray glitchy pixel in Activision Grand Prix. Left side at the edge, little down from the top. It flashes momentarily. Best way to see it is reset the game and press the fire button continuously. After the first car passes off the screen it happens. Always repeatable. Seems to be present for 1 or 2 frames. It will happen in other positions later, but always on the left side.

Edited March 5, 2017 by Keatah

[+stephena]

Confirmed. It was much larger in pre4, so it's fixed somewhat here, but still not fully complete. Referenced in https://github.com/stella-emu/stella/issues/82.

[Trebor]

Demon Attack

 

Real Hardware (Woody): Bottom most "floor" scanline flickers around the center to various lengths. This is typically not visible though with a centered screen on the CRT being utilized:

 

If the V-Hold is released, it is noticeable with a rolling screen:

 

Stella 5.0.0-pre5: - Bottom most "floor" scanline flickering visible on screen. The behavior is accurate; however, the screen centering likely needs adjusting to better match Real Hardware, or/and closer to the centering positioning of Stella 4.7.3:

 

Stella 5.0.0-pre4: - Bottom most "floor" scanline not flickering on screen. The behavior is deemed inaccurate in light of the aforementioned results; pre4 and pre5 screens are "centered" similar, if not exactly the same:

 

Stella 4.7.3: - Bottom most floor (and at least a scanline or two above it) are not present on the screen, behavior of last floor scanline is unknown. Screen centering though appears to better, comparing similarly to real hardware:

[+stephena]

Actually, both Stella 4.7.3 and pre4 are accurate, it's pre5 that contains a regression. To see the flickering line in the former, press Alt-PageUp to change YStart. You'll see that the bottom scanline remains constant and non-flickering until ystart is 46 or so, after which you can see the flicker (which is normally hidden, as it should be).

 

In pre5, the bottom line flickers no matter what line it actually appears on. That is, you'll see every bottom line flicker when pressing Alt-PageUp, no matter what the YStart is. This is a bug that has nothing to do with centering.

 

EDIT: referenced in https://github.com/stella-emu/stella/issues/100

[Keatah]

In Atom Smasher the playfield vibrates by +/- 1 scanline, when you hit the fire button it seems to stabilize mostly. I observed the opposite behavior couple of times in 3.9.3, it begins vibrating after you fire.

 

Seems a little intermittent like the Maze Craze problem was.

[DirtyHairy]

Actually, both Stella 4.7.3 and pre4 are accurate, it's pre5 that contains a regression. To see the flickering line in the former, press Alt-PageUp to change YStart. You'll see that the bottom scanline remains constant and non-flickering until ystart is 46 or so, after which you can see the flicker (which is normally hidden, as it should be).

 

In pre5, the bottom line flickers no matter what line it actually appears on. That is, you'll see every bottom line flicker when pressing Alt-PageUp, no matter what the YStart is. This is a bug that has nothing to do with centering.

 

EDIT: referenced in https://github.com/stella-emu/stella/issues/100

Fixed in git

Edited March 5, 2017 by DirtyHairy

[DirtyHairy]

Also noticed (near the same area) another stray glitchy pixel in Activision Grand Prix. Left side at the edge, little down from the top. It flashes momentarily. Best way to see it is reset the game and press the fire button continuously. After the first car passes off the screen it happens. Always repeatable. Seems to be present for 1 or 2 frames. It will happen in other positions later, but always on the left side.

Grand Prix (1982) (Activision)_26.pngGrand Prix (1982) (Activision)_27.png

The glitch is a byproduct of the emulation of NUSIZ during player decode / draw. This aspect of TIA emulation is considerably improved over Stella 4 in pre-5, but there are still some corner cases that I have to investigate, emulating which will hopefully fix this for good.

[DirtyHairy]

In Atom Smasher the playfield vibrates by +/- 1 scanline, when you hit the fire button it seems to stabilize mostly. I observed the opposite behavior couple of times in 3.9.3, it begins vibrating after you fire.

 

Seems a little intermittent like the Maze Craze problem was.

I can reproduce this in Stella 4, too. Note that, while the playfield vibrates up and down, the score stays fixed, so this is not a bug with frame start detection (as opposed to Marble Craze), but rather a ROM bug (it's a proto, after all ).

[+SpiceWare]

The tick-mark is back in VideoChess. In pre5.

That's accurate:

[Mr SQL]

This homebrew w.i.p. doesn't seem to work in stella. But it supposedly works on real hardware.

http://atariage.com/forums/topic/262864-defender-iii-atari-flashback-portable/?do=findComment&comment=3709415

 

 

Added as issue https://github.com/stella-emu/stella/issues/98.

 

imo you should not close bugs as not emulator related that can't be reproduced on a real Atari.

 

Defender III now works in Stella, but the only way to play the prototype is on Javatari or via that trick to clear the RAM. I was surprised to learn RIOT used static RAM, but I think by 1983 CBS RAM was cleared by powering off.

 

Perhaps someone could verify with a CBS RAM cart but Shouldn't Stella support the Atari Flashback console?

 

Here's another Stella bug for SuperCharger RAM, this one is also present in Javatari:

 

http://atariage.com/forums/topic/221197-sprites-stuck-on-supercharger/?entry2923260

 

Stella is pretty awesome, fixing these bugs in expanded and extended memory access protocols will just make it more awesome!

[Keatah]

The main engine of a traditional VCS is the three-chip chipset. That's what Stella emulates. The main engine of the portable flashback console is a SoC + emulator. Quite distant from the three original chips. I don't necessarily believe an emulator should be emulating an emulator.

 

I do believe that Stella should properly emulate power-up states of original internal hardware and external cartridge hardware where possible; whether it be randomized, or zero'd, or whatever.

[+SpiceWare]

I'm working on a couple new cartridge formats in pre5. BUS and CDF.

 

BUS is for Bus Stuffing, which works well for most systems but is hit or miss on Juniors and 7800s. ZackAttack has determined there is an electrical issue with the Juniors. Al doesn't wish to sell games that won't work on the Juniors, so while I won't be writing games for sale using it, I will write things using BUS for the Harmony Cart.

 

CDF is an updated version of DPC+, it takes what we learned while creating BUS to make the driver smaller (which increases the resources the game can use by 2K of ROM and 2K of RAM!), it has 32 improved datastreams (they all support fractional in the format of M.N, vs DPC+ where you had 8 at 1.0 and 8 at 0.N), slightly improved 3-voice music (DPC+ uses 32 byte waveforms, CDF is under user control for 2, 4, 8, etc. up to 4096 though that'd use up all of Display Data RAM) plus built in support to play packed digital samples directly from ROM (in Frantic I had to dedicate 2K of RAM for sample playback and unpack the data myself). This weekend I'll be rebooting Draconian to use CDF.

 

I'll probably be ready to add these into Stella later on this month - what will I need to do for that?

[+stephena]

First read through https://stella-emu.github.io/development.html.

 

But long story short, clone the project, make your changes locally, and then do a pull request. That way, I can review the code, making sure it doesn't break anything else, etc. Finally, I will just accept the pull request, and your code will be committed to the repo.

 

So no more sending patch files, etc, like one would have to do in SVN.

 

As for the BS schemes themselves, there are other classes that need to be added to the debugger stuff (to show internal state for that specific BS type). And then there's the question of auto-detection and associated code in Cart.cxx. But since you've submitted BS schemes before, I think you know about all this.

[+SpiceWare]

Thanks, will do!

 

Yep - autodetect and such is already done. The debugger tab for BUS is mostly finished, haven't worked on it yet for CDF.

 

I think the main thing that'll need to be reviewed is how I implemented Bus Stuffing. This was added to the cartridge class header and so far only BUS overrides it:

	    virtual uInt8 busOverdrive(uInt16 address) { return 0xFF; } 

---

 

and this was added to the beginning of poke() in system class:

	  value &= myCart.busOverdrive(addr);

---

 

I also added a couple new formats, F_16_2_2 and F_16_3_2, that I may need help to fully implement. At the moment they're view only, you can see them in action in the screenshot above for the Datastream Pointers and Datastream Increments. Datastreams are now fractional - the last byte, displayed after the period, is the fractional value.

[+stephena]

We can discuss it further when I look at the code, but the only thing I have some apprehension about is introducing a new virtual method that is called on every poke(). This can slow down the entire emulation for the sake of one bankswitch type. So testing will be required. Perhaps we can modify the scheme so that the busOverdrive() call only happens directly in CartBUS::poke(), so only it will pay the price for the call.

[+SpiceWare]

Hmm, didn't think I could redirect zero page access to the cartridge class.

 

 

So I gather something in here would change to include zero page:

void CartridgeBUS::install(System& system)
{
  mySystem = &system;
 
  // Map all of the accesses to call peek and poke
  System::PageAccess access(this, System::PA_READ);
  for(uInt32 i = 0x1000; i < 0x1040; i += (1 << System::PAGE_SHIFT))
    mySystem->setPageAccess(i >> System::PAGE_SHIFT, access);
  
  // Install pages for the startup bank
  bank(myStartBank);
}

---

Then something here would change:

bool CartridgeBUS::poke(uInt16 address, uInt8 value)
{
  // handle zero page pokes
  if (address <= 0xFF)
  {
    value &= busOverdrive(address);

    // update TIA or RAM

    return;
  }

  // handle cartridge pokes
  address &= 0x0FFF;
 
  if ((address >= 0x10) && (address <= 0x1F))
...
}

---