Jump to content
IGNORED

Another emulator


ThomH
 Share

Recommended Posts

For no reason other than fun, I am jumping on the Atari 2600 emulator bandwagon. It looks like you've had only one other this year (kudos, Zarek) so maybe it's a lean period? A couple of screenshots are attached. Issues that jump right out:

  • Enduro shows that I'm probably doing something wrong with vertical sync — those four bright lines at the top are the machine starting to output data again while the vertical sync is still ongoing;
  • ... though it appears as though horizontal sync is largely correct since the double scanned lines only slowly leave the correct horizontal area (and then if you look closely at the top, the emulated CRT gets back into phase with only a very slight roll; does the 2600 continue to output horizontal syncs while vertical sync is enabled, e.g. by pulsing blank appropriately?);
  • both Enduro's score line and the exact position of the invaders in the interlace gif show that I'm probably getting the stuff behind CPU/TIA sync strobe at least slightly wrong. I had a check while I was writing this and have immediately spotted at least one of the problems: I've implemented RDY as though it were like e.g. the z80's HALT, when it should pause read cycles only. This probably isn't the only error there though since the Enduro score is quite a bit too far to the left.

The 6502 itself has passed a bunch of test suites; can anybody advise on good test cases for specific video features?

post-24504-0-31692800-1438306920_thumb.png

post-24504-0-06077100-1438306971_thumb.gif

Link to comment
Share on other sites

I second Keatah too. Rewriting the emu core of Stella would provide much more benefit to the community.

I think if you want to imrpove Stella's core you should rewrite it in Assembly or at least the hot spots to reduce latency.

 

ThomH, cool screenshots, looks like you are making excellent progress. Keep at it!

Link to comment
Share on other sites

I think if you want to imrpove Stella's core you should rewrite it in Assembly or at least the hot spots to reduce latency.

AFAIK Stella has no latency. And C++ and today's hardware are more than fast enough.

 

The problem is, that Stella is emulating the TIA and not replicating it. The latter requires much more CPU power (which we have today) but the result is perfect. One could even replicate the model incompatibilities then.

Link to comment
Share on other sites

Why another emulator? Why not put efforts toward perfecting Stella, the gold standard.

 

Stella is already perfect as judged by its objectives. It would be arrogant to think I could possibly have anything to add.

 

Or, I guess, after twenty years you could argue that it's either already perfect or impossible to perfect. Which I think cuts to perfection not being objective.

 

I second Keatah too. Rewriting the emu core of Stella would provide much more benefit to the community.

 

I don't see a substantial distinction between rewriting one thing and writing another that satisfies the same specification. But, more importantly, I don't see that there's anything much to add to Stella — it hits its goals excellently. The authors should be proud.

 

AFAIK Stella has no latency. And C++ and today's hardware are more than fast enough.

 

The problem is, that Stella is emulating the TIA and not replicating it. The latter requires much more CPU power (which we have today) but the result is perfect. One could even replicate the model incompatibilities then.

 

I think there's a spectrum from Visual6502 that can provide a perfect electrical-level emulation to Stella which costs several orders of magnitude less to run but, technically, limits itself in the scope of its emulation (if "to all commercial software ever released and most non-commercial too" can be described as 'limited'). I think that the advances in processing power made available by the twenty years since Stella began have allowed some further movement towards full-system emulation* but that, no, it's not something that enough people care about to be worth pursuing other than for personal interest. This is all just for fun.

 

* particularly: my emulator can run a full pretend CRT rather than attempting directly to map source pixels to destination pixels. It can produce a raw sound output at the 6507's clock rate and then lowpass filter it down to something a sound card can actually output. It can do these things most definitely not because I'm smarter or because anybody desperately wants these things but because it's 2015, not 1996.

Link to comment
Share on other sites

Stella is already perfect as judged by its objectives. It would be arrogant to think I could possibly have anything to add.

 

Or, I guess, after twenty years you could argue that it's either already perfect or impossible to perfect. Which I think cuts to perfection not being objective.

 

 

I don't see a substantial distinction between rewriting one thing and writing another that satisfies the same specification. But, more importantly, I don't see that there's anything much to add to Stella — it hits its goals excellently. The authors should be proud.

The whole framework and all the features are great, no doubt about that. But Stephen (who maintains Stella for many years now) has explicitly asked for someone to improve the (TIA) emulation core.

 

There are still a few games, which do not display properly on Stella (e.g. Meltdown, my own 11 space invaders demo) for several years now.

Link to comment
Share on other sites

AFAIK Stella has no latency. And C++ and today's hardware are more than fast enough.

 

The problem is, that Stella is emulating the TIA and not replicating it. The latter requires much more CPU power (which we have today) but the result is perfect. One could even replicate the model incompatibilities then.

 

Stella finally uses DirectX; their native drivers were not fast enough to display KCMM without the screen tearing apart, I'd call that latency. Z26 is written in asm and it's native drivers handled it fine, that's the difference between C++ (bloated and slow) and asm.

 

Was the display the only hotspot? How about controls?

Link to comment
Share on other sites

Stella finally uses DirectX; their native drivers were not fast enough to display KCMM without the screen tearing apart, I'd call that latency.

I have never seen that. Maybe you did have VSYNC disabled? How can I replicate?

 

Z26 is written in asm and it's native drivers handled it fine, that's the difference between C++ (bloated and slow) and asm.

Hand optimized assembler can be faster than C++. But Stella is maybe 10% CPU, TIA and other hardware emulation and 90% for user interface etc. With assembler this would have required several extra years. Also modern compilers usually produce faster code than assembler (except when you really, really invest a lot of time into optimizing), because the CPUs have become way too complex for the human brain. And C++ code is platform independent.

 

Was the display the only hotspot? How about controls?

Not that I am aware about.
Link to comment
Share on other sites

The whole framework and all the features are great, no doubt about that. But Stephen (who maintains Stella for many years now) has explicitly asked for someone to improve the (TIA) emulation core.

 

There are still a few games, which do not display properly on Stella (e.g. Meltdown, my own 11 space invaders demo) for several years now.

 

Okay, so I was wrong about that. I was trying to make the point that I wasn't aware of anything substantially wrong with Stella and that I don't think I'm going to produce anything of value even close to Stella — in effect that I'm not intending to contribute to Stella because I'm not expecting to have anything to contribute. In practice I made the point that I definitely don't know enough about Stella to start contributing to it. Either one will do. But let's say this: if I find one day that my little thing is running Meltdown correctly, I'll get in touch with Stephen.

 

(follow-up query: is Meltdown available for download? All I could find were references to the 1983 Fox prototype, which appears quite definitively not to have any invaders whatsoever)

 

 

Stella finally uses DirectX; their native drivers were not fast enough to display KCMM without the screen tearing apart, I'd call that latency. Z26 is written in asm and it's native drivers handled it fine, that's the difference between C++ (bloated and slow) and asm.

 

Was the display the only hotspot? How about controls?

 

I'm primarily dumping display work onto the GPU. Which means using a high-level language for those parts that might have any effect on screen tearing. I'm specifically using GLSL because I know it (and it's the least platform-specific of the shading languages, which is a bonus). The output from the emulator is of the form "CRT gun started firing at (x, y), here's a sample buffer of what it fired during the run, it ended at (m, n)". So inherently stuff that the GPU is best equipped to handle.

 

(follow-up query: KCMM was a recent commercial release; by what avenue might I be able to obtain it for emulator testing? Are copies still available? Ideally for less than $130,000!)

Link to comment
Share on other sites

But, more importantly, I don't see that there's anything much to add to Stella . . .

Besides what has been mentioned, the sound still isn't quite right. This is an old video, but the sound hasn't been improved since then:

 

youtube.com/watch?v=Njvf9L_NxHI

https://www.youtube.com/watch?v=Njvf9L_NxHI

 

Another thing that has been on the to-do list for a fairly long time is giving Stella the ability to record gameplay videos.

Link to comment
Share on other sites

Besides what has been mentioned, the sound still isn't quite right. This is an old video, but the sound hasn't been improved since then: [...]

 

Okay, then unexpectedly that's something I may actually be capable of contributing constructively on. I'll see how I go. I was writing emulators back in the '90s too and have acquired some DSP experience in the interim so I'm aware of the difference between what we had to do then and what we can do now. My little effort doesn't have any sound code in it whatsoever at the time of writing though and I've not looked at the Stella code so the obvious caveat applies: at present there's no meaningful evidence that I can do any better than whatever Stella is already doing. Just a take-it-on-trust guess.

Link to comment
Share on other sites

Thanks for the kudos, but I haven't made anything :P I'm still a green leaf! ResolaQQ deserves all the credit, he's the one that started the thread and made the emulator. I only replied to it.

 

Honestly though, creating an emulator sounds like a good programming project and an excellent way to learn, but so does improving Stella really. I can't really speak about what's involved, but this forum is full of people that know how.

Edited by Zarek
Link to comment
Share on other sites

 

Okay, so I was wrong about that. I was trying to make the point that I wasn't aware of anything substantially wrong with Stella and that I don't think I'm going to produce anything of value even close to Stella — in effect that I'm not intending to contribute to Stella because I'm not expecting to have anything to contribute. In practice I made the point that I definitely don't know enough about Stella to start contributing to it. Either one will do. But let's say this: if I find one day that my little thing is running Meltdown correctly, I'll get in touch with Stephen.

 

(follow-up query: is Meltdown available for download? All I could find were references to the 1983 Fox prototype, which appears quite definitively not to have any invaders whatsoever)

 

 

I'm primarily dumping display work onto the GPU. Which means using a high-level language for those parts that might have any effect on screen tearing. I'm specifically using GLSL because I know it (and it's the least platform-specific of the shading languages, which is a bonus). The output from the emulator is of the form "CRT gun started firing at (x, y), here's a sample buffer of what it fired during the run, it ended at (m, n)". So inherently stuff that the GPU is best equipped to handle.

 

(follow-up query: KCMM was a recent commercial release; by what avenue might I be able to obtain it for emulator testing? Are copies still available? Ideally for less than $130,000!)

 

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.

Link to comment
Share on other sites

I have never seen that. Maybe you did have VSYNC disabled? How can I replicate?

 

Hand optimized assembler can be faster than C++. But Stella is maybe 10% CPU, TIA and other hardware emulation and 90% for user interface etc. With assembler this would have required several extra years. Also modern compilers usually produce faster code than assembler (except when you really, really invest a lot of time into optimizing), because the CPUs have become way too complex for the human brain. And C++ code is platform independent.

 

Not that I am aware about.

To replicate this, try to play KC with the previous version of stella and the default screen driver selected (no OpenGL).

 

I agree there's no need to write everything in asm but display drivers are generally a must; Stephena agreed as well since the move to DirectX was about getting rid of their custom display driver; DirectX is asm, just like OpenGL but it doesn't have to be installed.

 

The Z26 emulator is written in asm, so it's custom display driver is fast enough the screen won't tear apart.

 

Our discussion on this is here:

http://atariage.com/forums/topic/200972-tile-based-scrolling-and-expanding-engines/page-2?do=findComment&comment=2586454

Link to comment
Share on other sites

 

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.

 

Cool, thanks. I've yet even to implement paged ROM support so it'll be a while.

 

Like any developer I definitely have my limits but one of the reasons I'm doing this is an unhealthy recent interest in all things NTSC and PAL — I would ideally get to a position where the Atari 2600 module spits out genuine composite which the CRT part of the emulator genuinely ingests, but right now the Atari 2600 is fictionally putting out RGBA video. All the CRT is doing is attempting to catch the syncs, put together its record of raster scans and associated data outputs, and pass that on to whomever knows about drawing to the host machine's display.

 

While I'm kicking that final chunk over to the GPU it would not, taking a step back, be very difficult instead for the Atari to generate composite video, like real Ataris do, and for the GPU later to decode it, with colour artefacts emerging naturally (and some sort of transmission error being insertable if required; the physics of cables usually implies some sort of low-pass filter). The AM demodulation is the only part I lack the experience in, since on a GPU you'd want it to be purely functional, but it's pretty much guaranteed to end up being a weighted sum of nearby samples once I figure the maths out so it's definitely within a modern processing budget.

 

Which is all very grand talk but right now either my Atari emulation isn't always producing correct sync signals or my CRT isn't always correctly recognising them. So I'm a long way from anything advanced. I've at least simulated what I think are the correct tests — edge triggered hsync, a pretend capacitor charge for vsync — so there's nothing phoney in my assumptions. Just some sort of error in implementation.

 

As and when (and if) monochrome KC works, I'll get in touch. It definitely looks like one of the Atari masterpieces.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

So, things are going reasonably well — e.g. the Cosmic Ark star field just works (it's against my nature and my objective to put in special cases, so there are none), but then vertically travelling asteroids are too far to the right so possibly I've got something wrong in my ready line timing but probably one of my 6502 parts is wrong.

 

 

KC Munch Man just isn't doing much of anything — I get the occasional flash of an image but my CRT isn't syncing to it properly. Which is not an uncommon theme. Possibly I should have started with a hacky approach of just taking an enabling of the vertical sync output to magically cause the CRT to recognise a vertical sync but I'm sure I'll figure it out.

 

E.T. at least displays something of a title screen so I'm probably going to take a detour into audio next, having the actual original above to compare to.

 

However, quick TIA question:

 

Of the 7 bit colour format, the lowest three bits are the luminance and the top four bits are a phase offset for the colour subcarrier.

 

Resulting questions:

  1. it appears that a phase offset of zero is black, and that a luminance of 0 produces the blanking level. Therefore is there a special case that the colour subcarrier is disabled for chrominance 0?
  2. by what formula is the colour phase offset applied? Just add n/15th of a cycle?
Link to comment
Share on other sites

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

post-3056-0-31582100-1439767299_thumb.jpg

 

post-3056-0-97948900-1439767303_thumb.jpg

 

Some of the stars end up 2x in size.

 

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:

blogentry-3056-0-28021700-1304813687.png

 

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

blogentry-3056-0-94044700-1304817811.jpg

 

 

 

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

post-3056-0-62177500-1439768101_thumb.jpg

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...