Another emulator

[+SpiceWare]

There's info in this topic that should help with the color phase shift.

[ThomH]

Not bad. The star pattern's a bit off - I took a burst of photos, here's 2 in a row:

IMG_6116.jpg

 

IMG_6117.jpg

 

Some of the stars end up 2x in size.

 

How frustrating. The only thing I'm consciously aware of currently definitely being wrong is that I apply the player number — the bottom two bits of $04 and $05 — to the player objects only, not to the missile objects. Hopefully that sometimes missing second pixel comes from one of those. Otherwise it could still be any one of about a thousand other things.

 

Unless I'm misunderstanding the term the color value for black(phase offset = 0, luma = 0) is not at blanking level. If the monitor's contrast/brightness are misadjusted you can see a difference (from here):

 

Stella:

 

display too bright (I had to turn off the rainbow lines as they confused the camera's exposure):

 

 

 

Space Invaders with brightness too bright. Also note the HMOVE bars are visible on a black screen if the brightness is up.

IMG_6127.jpg

 

Cool. Then that makes a lot more sense. But you'd still have to disable the colour carrier to get greyscale, wouldn't you?

[ThomH]

ThomH, here is a link to a monochrome version of KC:

http://www.pouet.net/prod.php?which=64999

 

It should be helpful testing for screen tearing. If you also wish to implement artifact color support that would be awesome, let me know and I'll send you a developer copy of the release version with the artifacting. Currently no emulators for the Atari exist that support artifacting, though it's common with emulating other platforms like the Color Computer.

 

I've now implemented full composite colour. Which means I'm imagining a lossless modulation and demodulation but I'm doing fairly well on that front. Many other emulation issues remain. Regular monochrome KC still isn't doing much of anything at all. Does it require emulation of the Supercharger hardware?

 

ET screenshot attached. A very slow video is at http://www.youtube.com/watch?v=Dpu9htFCQn8 — my pixel shader is currently atrocious. No attempt at parallelism at all. Really bogging everything down.

 

---

 

Additional edited-in notes:

 

You'll see some stray random noise pixels in the ET image. That's where successive raster beams overlap, since they're painted additively. It's not intended to be some sort of simulation of signal noise, it's a genuine precision problem. Possibly I need to emulate a shadow mask.

 

Because the YIQ encode and decode is written and performed fully functionally with no intermediate buffer, it should produce real pixel-correct results no matter what your display resolution. It is a genuine YIQ decode in which Y can pollute I and Q, and vice versa, though the large solid blocks of colour on display make that largely irrelevant.

 

A consequence of a decision not to bother storing anything or processing output when the beam is at the blanking level produces a bug whereby pixels from one edge of the active area think they're next to pixels from the previous edge. I will fix that.

 

It's a full-frame free-running composite CRT emulation, which only knowingly smudges the details on phase detection (i.e. there is none, it's always magically perfectly synchronised to your Atari). However it's also still buggy so a bunch of games don't synchronise properly in various ways or show evidence of doubly scanned areas. Also I've yet to implement phosphor decay; I'm excited because switching to a formal phosphor model might allow me to break the need for any connection between emulated machine output rate and host machine output rate but we'll see.

 

Additionally attached is an image from the second Dukes of Hazzard, showing something going wrong with horizontal sync detection.

Edited September 2, 2015 by ThomH

[Mr SQL]

 

I've now implemented full composite colour. Which means I'm imagining a lossless modulation and demodulation but I'm doing fairly well on that front. Many other emulation issues remain. Regular monochrome KC still isn't doing much of anything at all. Does it require emulation of the Supercharger hardware?

.

 

Yes, you must emulate enough for the backswitching and the memory access protocol that allows the 6K "ROM" to be addressed as either ROM or RAM.

[ThomH]

Bump of my own volition, to note merely that this is still being worked on, though there's still not much of interest in a world where Stella already exists. It's become a multi-machine emulator and gained support for all of the real-world bank-switching schemes except, ironically, the Supercharger. So I should look at that again.

 

I've been publishing binaries for a while at GitHub. It's still no special cases, no workarounds, but pleasingly Meltdown works. Though there are some oddities elsewhere, mostly things being a small distance from where they should be, which I'm at a loss immediately to explain other than to say that it's not any of the most obvious things.

[DirtyHairy]

I've been publishing binaries for a while at GitHub. It's still no special cases, no workarounds, but pleasingly Meltdown works. Though there are some oddities elsewhere, mostly things being a small distance from where they should be, which I'm at a loss immediately to explain other than to say that it's not any of the most obvious things.

 

Nice work! The Meltdown screenshot looks to me like there is a asymmetry between the two columns to the right and those to the left. We've had the same issue with 6502.ts and the new Stella core, and improved modelling of NUSIZ during draw / decode fixed it --- you can find the corresponding bug with testcases and commits here: https://github.com/stella-emu/stella/issues/63 (and the original meltdown ticket with a less accurate fix here https://github.com/stella-emu/stella/issues/56).

 

In general, if you like, if you're stumped on any aspects of TIA emulation, I'm happy to discuss those --- chances are that we've encountered and fixed the very same corner cases. On the other hand, of course, solving these riddles is part of the fun...

Edited March 27, 2017 by DirtyHairy

[ThomH]

 

Nice work! The Meltdown screenshot looks to me like there is a asymmetry between the two columns to the right and those to the left. We've had the same issue with 6502.ts and the new Stella core, and improved modelling of NUSIZ during draw / decode fixed it --- you can find the corresponding bug with testcases and commits here: https://github.com/stella-emu/stella/issues/63 (and the original meltdown ticket with a less accurate fix here https://github.com/stella-emu/stella/issues/56).

 

In general, if you like, if you're stumped on any aspects of TIA emulation, I'm happy to discuss those --- chances are that we've encountered and fixed the very same corner cases. On the other hand, of course, solving these riddles is part of the fun...

 

When I'm actually playing the game, the individual nuclei are sized independently, so I'm fairly confident that one works†. I don't know when it started working or why, but I'm intending to treat NUSIZ correctly — the sprite size affects when the pixel clock increments, the decision being made on each pixel clock††. A bunch of other games throw up a bunch of other mysteries, but I'm optimistic that implementation errors rather than false structural assumptions underly all of them. Though time will tell.

 

I need to start to track the test cases you've been putting together, as they seem excellent. Hopefully I can find a way to automate them.

 

Immediate mysteries off the top of my head:

• both Pitfall 2 and Double Dragon appear to enable and disable the missiles at the same time as the corresponding players, expecting the missiles to be hidden entirely by the action of HMOVE. But the first pixels of mine show up in column 159, likely an off-by-one counting error somewhere;
• during its first display of the game screen, the players in Yars' Revenge whizz around the screen to indicate some other mistake in HMOVE. But at some point they become their expected static selves. Since this problem suddenly arose without warning, and appears to vanish at some point with the same kernel, uninitialised state is guess number one.

DK VCS also flickers quite extravagently. My emulator has the full CRT emulation in it, which fully decouples when your computer displays a frame and when the Atari or whatever generates one, such that if you have a 144Hz gaming monitor then the emulator will produce 144 different frames per second. All part of the war on latency, but it means that this isn't necessarily as trivial to avoid as if I were forcing a frame buffer into the middle.

 

 

† though there seems to be a scaling error somewhere in my CRT emulation in which some columns end up a different width from others, which might psychologically suggest incorrect symmetry. My NTSC and PAL decoding has been through several changes in the last two years but right now is based upon scaling an input wave to a fixed grid of four samples per colour clock. Which for an Atari should be an integer scale. I may have made a precision error somewhere, but then I'd expect colour artefacts from wandering of phase. So who knows?

 

†† ideologically, anyway, though I'm a batch-it-up guy. The TIA, like every other component in the emulator, is written such that the inner loop runs for n cycles assuming no new input, and accepts input only between those runs. Which sounds like a classic trading of accuracy for code simplicity, except that n isn't fixed. If you write to the TIA at cycle a, then write to it at cycle b then the internal code will ignore the TIA completely until you hit it again, then run it for b - a cycles, then post the write. You could repeatedly ask it to run for a single cycle if you wanted but it'd be slower.

[+SpiceWare]

DK VCS also flickers quite extravagently. My emulator has the full CRT emulation in it, which fully decouples when your computer displays a frame and when the Atari or whatever generates one, such that if you have a 144Hz gaming monitor then the emulator will produce 144 different frames per second. All part of the war on latency, but it means that this isn't necessarily as trivial to avoid as if I were forcing a frame buffer into the middle.

DK VCS makes heavy use of flicker. As an example, Donkey Kong himself is drawn using these 2 alternating frames:

 

Stella has a Phosphor mode option:

 

Which blends the two frames together, creating this:

 

Which simulates the persistence of vision you experience on a real CRT.

[DirtyHairy]

 

When I'm actually playing the game, the individual nuclei are sized independently, so I'm fairly confident that one works†. I don't know when it started working or why, but I'm intending to treat NUSIZ correctly — the sprite size affects when the pixel clock increments, the decision being made on each pixel clock††. A bunch of other games throw up a bunch of other mysteries, but I'm optimistic that implementation errors rather than false structural assumptions underly all of them. Though time will tell.

 

My bad, my second (borked) link points to the wrong issue. I meant to link https://github.com/stella-emu/stella/issues/36 , which also doesn't show the asymmetry I refer to Check out the last of Keatah's screenshots in the form post to see what I mean: http://atariage.com/forums/topic/259633-testing-the-new-stella-tia-core/page-2?do=findComment&comment=3651891 The second to colums are blockier than the left two columns, which was due to the missing emulation of a clocking glitch triggered by NUSIZ during decode. It is hard to tell for sure from your screenshot, but it seems to be off in the same way (can't test, I'm on linux).

 

Considering the Pitfall and Double Dragon, those don't look like any edge cases (as in "deviations from Andrew Tower's notes" ) that I have encountered. If implemented correctly, under normal circumstances, a sprite never shows up on the line in which it has been positioned (the exception being multiple NUSIZ copies). However, the sprite counters get a two pixel offset if hit during hblank and a one pixel offset if hit during the very last cycles of an extended hblank (shifting the sprite to the left). I don't know what is going on at the low level there (and schematics make my eyes hurt ), but there are remnants of similar peculiarities during extended hblank in other edge cases, too. There is a chance that this may be connected to your issues. Testcases that come to mind are Jungle Hunt (a horizontal rift in the crocodiles as they appear on the left) and G.I. Joe (a hole in the roof of the house). Looking for slightly different issues, Topy and DK Junior are games that are very sensitive to HMOVE timing --- if those are glitched, I would suspect an issue related to RESx and HMOVE timing.

 

No idea about Yar's revenge. As Spiceware says, DK Arcade makes very heave use of flicker, so there's likely nothing wrong there (unless you skip frames).

Edited March 27, 2017 by DirtyHairy

[ThomH]

DK VCS makes heavy use of flicker. As an example, Donkey Kong himself is drawn using these 2 alternating frames:

Donkey Kong VCS (2017) (1.0)_dbg_10d5867c.png Donkey Kong VCS (2017) (1.0)_dbg_10d57586.png

 

Stella has a Phosphor mode option:

Screen Shot 2017-03-27 at 12.36.29 PM.png

 

Which blends the two frames together, creating this:

Donkey Kong VCS (2017) (1.0)_dbg_10d5a3bf.png

 

Which simulates the persistence of vision you experience on a real CRT.

 

 

I'm aware of all of that, but my issues are distinct for the reasons as given. My simulated CRT simulates something closer to the real physics of phosphor — exponential decay, most recently painted thing most prominent — and works by decoding a genuine NTSC or PAL signal. So it's only ever dealing with a 1d signal, discriminating syncs and painting stripes of data with a defined width.

 

If you had a 144Hz monitor, it will paint 144 different frames per second. Just like if you pointed a 144Hz camera at a CRT, you'd get 144 different frames per second.

 

The phosphors themselves are effectively an infinite impulse response filter. Except that they're in a computer so obviously they underflow. I would dare imagine you're getting traces of four to five frames worth, though very little of the older ones remains. It's not actually doing "I have a complete new frame, let's add it to the queue of frames and then mix them", or any other sort of frame-based-timing. Even if it were, they wouldn't be evenly weighted because they're not in real life.

 

The major disadvantage is that I need smarter filtering. In this case I'm possibly picking up a beat frequency but, more likely, as DirtyHairy guesses, I'm probably just suffering from frame skipping. So e.g. I'm sometimes seeing more of those where Kong's background is the most recently painted thing (and therefore more prominent) than where Kong's features are the most recently painted thing. It certainly seems to vary over time.

 

I'll try to grab a new video. But key point: emulation of the real device. No workarounds, no hacks.

 

So, yeah, noble intentions. But probably I've written a cheque I'll never be able to cash. Though in theory all of the following would be emulated correctly:

• given that programmatic sync and the automatic horizontal sync are exclusive ORd, using the programmatic one to eliminate the built in one (and placing it elsewhere, hopefully);
• generating an interlaced display;
• deliberately introducing roll as a video effect.

... plus the stated intention of latency reduction if the user has spent the money on their hardware. With much better PAL display than naive 5->6 mapping being a side effect.

 

(appropriate observation: that'd all be lovely if, you know, the actual chips were good emulations too)

 

 

My bad, my second (borked) link points to the wrong issue. I meant to link https://github.com/stella-emu/stella/issues/36 , which also doesn't show the asymmetry I refer to Check out the last of Keatah's screenshots in the form post to see what I mean: http://atariage.com/forums/topic/259633-testing-the-new-stella-tia-core/page-2?do=findComment&comment=3651891 The second to colums are blockier than the left two columns, which was due to the missing emulation of a clocking glitch triggered by NUSIZ during decode. It is hard to tell for sure from your screenshot, but it seems to be off in the same way (can't test, I'm on linux).

 

Considering the Pitfall and Double Dragon, those don't look like any edge cases (as in "deviations from Andrew Tower's notes" ) that I have encountered. If implemented correctly, under normal circumstances, a sprite never shows up on the line in which it has been positioned (the exception being multiple NUSIZ copies). However, the sprite counters get a two pixel offset if hit during hblank and a one pixel offset if hit during the very last cycles of an extended hblank (shifting the sprite to the left). I don't know what is going on at the low level there (and schematics make my eyes hurt ), but there are remnants of similar peculiarities during extended hblank in other edge cases, too. There is a chance that this may be connected to your issues. Testcases that come to mind are Jungle Hunt (a horizontal rift in the crocodiles as they appear on the left) and G.I. Joe (a hole in the roof of the house). Looking for slightly different issues, Topy and DK Junior are games that are very sensitive to HMOVE timing --- if those are glitched, I would suspect an issue related to RESx and HMOVE timing.

 

No idea about Yar's revenge. As Spiceware says, DK Arcade makes very heave use of flicker, so there's likely nothing wrong there (unless you skip frames).

 

Oh, it's okay, when Meltdown's running you can clearly see it alternating between a left frame and a right frame, perceptually to create something much closer to round. But since real phosphors aren't an equal weighting of the two most recent frames and then an instant drop off before the third, it doesn't look like that in a screenshot.

 

Pitfall 2 and Double Dragon are showing missiles on the final column before right border which I think means they're being triggered a clock early. I don't think it's an unobserved hardware feature, I think it's just that my code does not conform to spec. Ditto Yars'. Clearly an issue entirely of my own making, not an interesting new observation. But if I'm going to sit here explaining what I've tried to do, it would be an omission not also to mention the things I've so far failed to do.

[+SpiceWare]

Have you run DK VCS on actual hardware? Stella's phosphor mode is "better than life" - it ends up completely suppressing flicker in games like DK VCS even though it's still quite obvious when run on real hardware.

[Mr SQL]

 

 

I'm aware of all of that, but my issues are distinct for the reasons as given. My simulated CRT simulates something closer to the real physics of phosphor — exponential decay, most recently painted thing most prominent — and works by decoding a genuine NTSC or PAL signal. So it's only ever dealing with a 1d signal, discriminating syncs and painting stripes of data with a defined width.

 

If you had a 144Hz monitor, it will paint 144 different frames per second. Just like if you pointed a 144Hz camera at a CRT, you'd get 144 different frames per second.

 

The phosphors themselves are effectively an infinite impulse response filter. Except that they're in a computer so obviously they underflow. I would dare imagine you're getting traces of four to five frames worth, though very little of the older ones remains. It's not actually doing "I have a complete new frame, let's add it to the queue of frames and then mix them", or any other sort of frame-based-timing. Even if it were, they wouldn't be evenly weighted because they're not in real life.

 

The major disadvantage is that I need smarter filtering. In this case I'm possibly picking up a beat frequency but, more likely, as DirtyHairy guesses, I'm probably just suffering from frame skipping. So e.g. I'm sometimes seeing more of those where Kong's background is the most recently painted thing (and therefore more prominent) than where Kong's features are the most recently painted thing. It certainly seems to vary over time.

 

I'll try to grab a new video. But key point: emulation of the real device. No workarounds, no hacks.

 

So, yeah, noble intentions. But probably I've written a cheque I'll never be able to cash. Though in theory all of the following would be emulated correctly:

• given that programmatic sync and the automatic horizontal sync are exclusive ORd, using the programmatic one to eliminate the built in one (and placing it elsewhere, hopefully);
• generating an interlaced display;
• deliberately introducing roll as a video effect.

... plus the stated intention of latency reduction if the user has spent the money on their hardware. With much better PAL display than naive 5->6 mapping being a side effect.

 

(appropriate observation: that'd all be lovely if, you know, the actual chips were good emulations too)

 

 

Oh, it's okay, when Meltdown's running you can clearly see it alternating between a left frame and a right frame, perceptually to create something much closer to round. But since real phosphors aren't an equal weighting of the two most recent frames and then an instant drop off before the third, it doesn't look like that in a screenshot.

 

Pitfall 2 and Double Dragon are showing missiles on the final column before right border which I think means they're being triggered a clock early. I don't think it's an unobserved hardware feature, I think it's just that my code does not conform to spec. Ditto Yars'. Clearly an issue entirely of my own making, not an interesting new observation. But if I'm going to sit here explaining what I've tried to do, it would be an omission not also to mention the things I've so far failed to do.

ThomH,

Awesome your emulator is rendering more than 60 frames per second, agree that is the only way to approach phosphor emulation!

 

Here is a link to WARPDRIVE in Javatari with the ROM in the URL (Dirtyhairy, I tried 6502.ts also but only heard the audio):

 

http://javatari.org/?ROM=http://relationalframework.com/WARPDRIVE_AFP.rom

 

This game is unique in that it can render 60 FPS of fullscreen animation at 60 HZ with the WARP drive activated (the BW switch), it's at 30 FPS and 60 HZ otherwise.

 

There's also a third toggle setting for 30 FPS and 30 HZ (bw switch again but during full screen text rendering).

 

Stella falls apart if you turn on phosphor simply because it only has 60 frames to work with - you need at least 120 frames to start emulating phosphor and you've got it, very cool!

 

Phosphor can be emulated on other systems at less than that but not on the VCS, at least not for games that push the performance and don't just flicker alot - there is no flicker in WarpDrive.

 

Or in Defender III for that matter and it falls apart with Phosphor in Stella too:

http://javatari.org/?ROM=http://relationalframework.com/Defender_III_v1.bin

 

These games should work in your emu since they are 6K CBS RAM games, they can also be recompiled for the SuperCharger without changing any of the code (and vice versa with some SuperCharger games).

 

Sometimes programmers write a great game that works fantastic in Stella with phosphor on which is really cool too though, just some difference to be aware of for emu authors.

[ThomH]

Here's a video mostly showing the current flaws, mostly as identified above (but also featuring some other errors that I'm aware of but didn't mention); I'll try those other ROMs and see what happens.

[RevEng]

The phosphors themselves are effectively an infinite impulse response filter. Except that they're in a computer so obviously they underflow. I would dare imagine you're getting traces of four to five frames worth, though very little of the older ones remains. It's not actually doing "I have a complete new frame, let's add it to the queue of frames and then mix them", or any other sort of frame-based-timing. Even if it were, they wouldn't be evenly weighted because they're not in real life.

CRT phosphors don't have that kind of hang time. They've decayed to be mostly imperceptible just a dozen or so lines after being lit.

 

 

POV is why the frames seem to blend together, as Spice indicated. This is an important distinction if you're trying to realistically emulate the physics of frame blending.

[ThomH]

Clearly my terminology is askew; the coefficients I'm using were derived from pointing a camera at a screen. So it's partly decay, partly a time integral (via shutter time), then a not unreasonable amount about what works well on a GPU. Which all makes it sound much fancier than the implementation actually ends up being, but is at least a real basis.

 

It's an attempt to leverage the things computers can do now which were not realistic previously; a terrible attempt possibly but hopefully that's instructive as to motive.

[+stephena]

Mr SQL, I really wish you'd stop bad-mouthing Stella in every emulator thread that pops up. Stella isn't "falling apart", and it's not crap because it's 'bloated' C++ instead of asm, etc, or any other the other claims you've made over the years. If you don't want to use the emulator, fine, but kindly stop calling it crap every chance you get. A lot of the problems you have with Stella are of your own making, as have been explained to you over the years, yet you STILL insist that it can't possibly be a problem on your end. We get it, you don't like Stella; STOP TRASH-TALKING ABOUT IT. And as for your claim that "This game is unique in that it can render 60 FPS of fullscreen animation at 60 HZ", it's irrelevant, since all games that don't use 30Hz flicker and render at a full 60fps work that way. Your game is not unique in any way in that regard.

[Mr SQL]

Mr SQL, I really wish you'd stop bad-mouthing Stella in every emulator thread that pops up. Stella isn't "falling apart", and it's not crap because it's 'bloated' C++ instead of asm, etc, or any other the other claims you've made over the years. If you don't want to use the emulator, fine, but kindly stop calling it crap every chance you get. A lot of the problems you have with Stella are of your own making, as have been explained to you over the years, yet you STILL insist that it can't possibly be a problem on your end. We get it, you don't like Stella; STOP TRASH-TALKING ABOUT IT. And as for your claim that "This game is unique in that it can render 60 FPS of fullscreen animation at 60 HZ", it's irrelevant, since all games that don't use 30Hz flicker and render at a full 60fps work that way. Your game is not unique in any way in that regard.

 

stephena,

I think Stella is awesome - don't take my comments the wong way, I reccomend Stella as the preferred emulator with both Virtual World BASIC and Flashback BASIC !

 

Javatari is also an awesome emulator I can embedd in a web page or link, like it was an Atari youtube video - I think that's tremendous!

 

That being said there is room for improvement with phosphor, artifacting and SuperCharger support (you still haven't patched the SuperCharger bug I posted, but Batari did for the Harmony cart). I think you should patch the CBS RAM bug too (RAM chips from 1983, lost their contents when powered off).

 

And there aren't any games that push 60 frames of full screen animation like WarpDrive, or even 30 FPS, just demos. That makes WarpDrive an excellent game to test emulators with and the controls are a great emu test too - if they don't respond at 30 FPS (or 60 FPS in warp mode) you cannot beat the game (Stella passes with flying colors, Javatari I think needs faster polling).

 

The only game I can think that comes close rendering wise is ESB and it's just updating tiny strips of the screen while the soft blitter chip in the vw and Flashback BASIC runtimes can push 100% of the playfield and dynamically recalculate all of the relative positioning to update the tilemapped sprites like in this Display List demo:

 

http://javatari.org/?ROM=http://relationalframework.com/Flashback_BASIC_DLI_Demo.bin

 

BASIC games are tremendous fun imo and a cross-compiler that can write for CBS RAM or SuperCharger formats is pretty cool and unique imo; why not help support it along with those new fancy chips? I also can't understand why your not inclined to support the new Atari console, it's a pretty cool addition.

 

You're correct I think c++ is bloated and slow compared to Assembly, and BASIC compilers tend to generate far more efficient asm; it would be cool to see someone write a tiny C with similar performance and footprint though, I think there is already one such project underway (Atac-C).

 

There's room for many emulators and many languages.... just more fun!

[Thomas Jentzsch]

@Stephen: Some people are better ignored.

[Mr SQL]

@Stephen: Some people are better ignored.

 

TJ, why not send such posts privately or act like an adult and join the conversation?

 

You're welcome to converse but peekaboo posts like that are inapproriate and not ignoring so make up your mind; if you close it you'll miss the fun!

 

How's your BoulderDash BASIC project going? I remember you were going to study complier design and follow a structured university approach; I still reccommend the Woz technique of writing it from scratch.

 

The discussion on c++ vs asm is certainly interesting, asm still has a foothold for video drivers and anything timing related - high performance Database cores too.

 

The example Stephena cited had to do with the soft rendering routines in Stella not being able to render full motion video without falling apart; passing control to native windows drivers by default fixed that issue, so did installing 3rd party drivers written in Assembly. And An Assembly based phosphor routine with 120+ frames sounds exciting - how could you possibly emulate phosphor rendering only 60 frames?

 

Try turning on phosphor in Stella with Warpdrive rendering 60 FPS of full motion video (BW switch on) and you'll see playfield fall apart with pixels in the wrong spots, not just the softer blur you get at 30 FPS.

[DirtyHairy]

I propably should resist the urge to answer, but here it goes anyway Mr. SQL, I am sorry to say, but most of your claims are half-truths at best, and much is simply wrong.

 

1. With modern compilers, the speed of C++ written with performance in mind is virtually indistinguishable from that of hand-written assembly (and easily surpasses that of poorly written assembly), with the added benefits of portapability, readability and maintainability. There is almost no reason to directly code anything in assembly these days, with the exception of low-level OS bootstrapping code or software targetting highly constrained systems.
2. The tearing issues you claim to observe on your system with your stuff are not the consequence of any mystical performance issue within Stella, but just vsync issues peculiar to your own particular video stack (OS - driver - window manager - SDL2 - Stella). In fact, I can run your stuff fine in Stella, 6502.ts and Javatari on my own system. You disprove your hypothesis of "mystical missing assembly optimizations" yourself by praising Javatari for rendering your stuff perfectly: like 6502.ts, Javatari is JITted Javascript (a dynamically typed, rubbery nightmare when it comes to performance) running on the browser API, with several layers between the code and the display hardware, and no hand-written assembly in sight.
3. There is no CBS RAM bug, there just are differences in the treatment of uninitialized memory between the various emulators. If you come up with evidence that CBS RAM worked differently (like a failing historic cartridge) we can talk again, but without that, you are basically asking emulation authors to tailor their memory initialization to your own interpretation of how this piece of hardware might have acted in absence of proper initialization.
4. The flashback is arguably not a new VCS iteration, but a modern, ARM-based handheld that runs a VCS emulator of mediocre accuracy and that is manufactured by a company that purchased the right to use the Atari brand from whatever entity that currently holds the right of the former company's brand assets. You have all right to be of different opinion, but you'll have a hard time convincing emulation authors to emulate the flaws and idiosyncracies of another emulator.

Edited March 28, 2017 by DirtyHairy

[DirtyHairy]

Here's a video mostly showing the current flaws, mostly as identified above (but also featuring some other errors that I'm aware of but didn't mention); I'll try those other ROMs and see what happens.

Looking at the video, I agree, the issues in Pitfall 2 are likely nothing exotic, but just a plain bug in sprite positioning If you like, I have some positioning testcases that compare sprite positions to the playfield here: https://github.com/6502ts/6502.ts/tree/master/aux/2600/positioning

 

The video also shows some displacement of the holes in the title screen "Donkey Kong" font.

[Thomas Jentzsch]

@StephenChristian: Some people are better ignored.

[ThomH]

Looking at the video, I agree, the issues in Pitfall 2 are likely nothing exotic, but just a plain bug in sprite positioning If you like, I have some positioning testcases that compare sprite positions to the playfield here: https://github.com/6502ts/6502.ts/tree/master/aux/2600/positioning

 

The video also shows some displacement of the holes in the title screen "Donkey Kong" font.

 

Cool, thanks! In an ideal world I'll find time to boil those down to providing a version of how the output should look in data (my internal representation is nothing exotic; a six-bit bit field per output pixel); if so then I'll contribute back, naturally. With something I'll probably end up wanting to optimise, automated testing should be a win.

[Mr SQL]

 

@StephenChristian: Some people are better ignored.

 

 

Why not stop making unfriendly posts and join the conversation?

 

 

I propably should resist the urge to answer, but here it goes anyway Mr. SQL, I am sorry to say, but most of your claims are half-truths at best, and much is simply wrong.

 

1. With modern compilers, the speed of C++ written with performance in mind is virtually indistinguishable from that of hand-written assembly (and easily surpasses that of poorly written assembly), with the added benefits of portapability, readability and maintainability. There is almost no reason to directly code anything in assembly these days, with the exception of low-level OS bootstrapping code or software targetting highly constrained systems.
2. The tearing issues you claim to observe on your system with your stuff are not the consequence of any mystical performance issue within Stella, but just vsync issues peculiar to your own particular video stack (OS - driver - window manager - SDL2 - Stella). In fact, I can run your stuff fine in Stella, 6502.ts and Javatari on my own system. You disprove your hypothesis of "mystical missing assembly optimizations" yourself by praising Javatari for rendering your stuff perfectly: like 6502.ts, Javatari is JITted Javascript (a dynamically typed, rubbery nightmare when it comes to performance) running on the browser API, with several layers between the code and the display hardware, and no hand-written assembly in sight.
3. There is no CBS RAM bug, there just are differences in the treatment of uninitialized memory between the various emulators. If you come up with evidence that CBS RAM worked differently (like a failing historic cartridge) we can talk again, but without that, you are basically asking emulation authors to tailor their memory initialization to your own interpretation of how this piece of hardware might have acted in absence of proper initialization.
4. The flashback is arguably not a new VCS iteration, but a modern, ARM-based handheld that runs a VCS emulator of mediocre accuracy and that is manufactured by a company that purchased the right to use the Atari brand from whatever entity that currently holds the right of the former company's brand assets. You have all right to be of different opinion, but you'll have a hard time convincing emulation authors to emulate the flaws and idiosyncracies of another emulator.

 

 

Dirtyhairy,

#1: I'm talking about highly constrained systems, a stock Atari. Database cores too on unconstrained systems; the hotspots (most of the core) are pure asm. Same with the video drivers like OpenGL and Direct3D. And I disagree C++ is indistinguishable from optimized Assembly.

 

#2 If you start a game of WARPDRIVE (press the button to start) and then turn on the BW switch, Stella will only render it properly with phosphor off. Turn phosphor on and off and you can see the difference for yourself.

 

#3 You have an excellent argument but since I provided hardware evidence of a SuperCharger bug and only the other emulators were patched, you should wait until that bug is patched before asking for a CBS RAM hardware example.

 

#4 I think you could make that argument as soon as Warner bought Atari and changed the culture, however from a programmers perspective, and from the perspective of creating a programming language compatible with all consoles I treat it no differently than other Atari's - form is the factor here and it is indeed marketed as a handheld Atari console and does a great job with a pretty good screen considering it is not a CRT. The 3rd party cartridge slot for tiny cartridges is awesome and makes it feel like a real Atari, the carts even insert backwards into the console (nice touch).

 

I think that makes for pretty cool new Atari hardware and we should all support it with fully compatible Atari games, programming languages and emulation - here's a thread for that topic that you may be interested in:

 

http://atariage.com/forums/topic/260084-will-you-support-the-new-atari-console/

[ThomH]

Looking at the video, I agree, the issues in Pitfall 2 are likely nothing exotic, but just a plain bug in sprite positioning If you like, I have some positioning testcases that compare sprite positions to the playfield here: https://github.com/6502ts/6502.ts/tree/master/aux/2600/positioning

 

The video also shows some displacement of the holes in the title screen "Donkey Kong" font.

 

I think these tests might have revealed that the issue is comprehension, not coding. Or, at least, that comprehension is a first issue.

 

E.g. I see in the ball test that the following causes the initial ball positioning:

 

F0A3 85 02 STA $02

F0A5 84 09 STY $09

F0A7 85 14 STA $14

So that's a WSYNC, then a background colour set, then a ball reset.

In Stellarator the ball first appears in the third pixel column. In my emulator it first appears right at the left edge of the screen. Which is also where I would place it if working by hand:

STA $02 activates the ready line.

The CPU attempts to read the opcode at FOA5 but ready is asserted, so it pauses. TIA stops asserting the ready line upon entering the right-hand blank area and the CPU resumes.

It spends three cycles performing the STY that changes the background colour. So it is now 9/228ths beyond the start of the right-hand blank area.

Two cycles pass while it reads the STA to $14. On the third cycle it does the write that will reset the ball position.

So the ball is reset during the three colour cycles that begin 15/228ths beyond the start of the right-hand blank area. And, because it's the ball, even a programmatic reset causes a start drawing signal.

So that all happens outside of the visible portion of the screen. And HMOVE has not been triggered.

So if you asked me, the human being, what happens:

• the counter is now reset, but isn't currently clocked;
• it will not receive any further clocks until pixels resume;
• once it receives a clock input, it will begin drawing;
• it'll be clocked at the same time as the play field and has the same output delay, so that means it'll appear in the first pixel column.

I believe that I've made a mistake somewhere in this reasoning, because my results do not agree with Stellarator's and, in any case, show issues elsewhere.

Can anybody tell me what my error is?