6502.ts / Stellerator: A new, web-based VCS emulator

[DirtyHairy]

Hi all!

 

I am happy to announce Stellerator, a newcomer to the arena of VCS emulation created solely for the fun of it and for exploring the boundaries of current web technology

 

Stellerator is part of 6502.ts, a project aiming at the browser-based emulation of 6502 based systems written in Typescript (a typed version of Javascript) using modern web technology. It fully runs in the browser, including audio and WebGL accelerated video with afterglow simulation. Compatibility is quite good; the emulator runs almost all historic games flawlessly, including quirks like the Cosmic Ark startfield. Homebrew runs as well, but support for undocumented 6502 opcodes is still a work in progress, so some homebrew will currently fail. Also, some of the more exotic cartridge formats are currently unsupported, including supercharger and DPC.

 

If you're curious, you can try it out on github.io: https://6502ts.github.io/stellerator The emulator has been tested and runs on current versions of Chrome and Firefox; your mileage with other browsers may vary. The source code is also hosted on github and can be found here: https://github.com/6502ts/6502.ts

 

Feel free to report any bugs and glitches in this thread or on github.

[ClassicGMR]

I just tried it with Firefox 48.0.2.

 

Adventure played just fine as far as I could tell.

Asteroids had the slightest of slowdowns on a screen full of asteroids - played fine after I shot one or two out of the sky - but when I clicked the framerate limiter off wow did it fly!

Pressure Cooker suffered from lag throughout the gameplay. Not unplayable but you could tell the music and gameplay were chugging along.

Yars' Revenge also suffered from a small amount of slowdown but if you weren't looking for it you might not see it right away.

 

Overall needs optimization obviously but very nice work.

[DirtyHairy]

Hi ClassicGMR!

 

Thanks for trying it out and for the heads up ☺️ I am curious what machine and OS you tried it on. Did you see what the speed display in the upper right corner read when you experienced the slowdown? Did Pressure Cooker run faster without the limit?

 

Generally speaking, I myself have not encountered any performance issues on x86 machines yet. In Chrome, I can get about three times the original speed without frame limiting, in Firefox, it's about two times for me. Admittedly, that's on a pretty modern i7 laptop though.

 

However, it is difficult to render at a truly constant frame rate in a web browser, and I do get occasional rendering hickups in Firefox. Does turning of the web worker in the settings change anything for you (you have to reload for this to take effect)?

 

Another thing that can happen is that the JavaScript VM deoptimizes certain code paths between playing different games which causes slow downs. This can be fixed by a page reload. Also, some games run mysteriously slower than most, again due to different optimizations by the VM. However, I have observed these effects only in Chrome, not in Firefox, and they were only visible without rate limiting.

 

Unfortunately, it is hard to squeeze more speed out of it by optimizing the code. CPU usage is slightly less than Javatarijs in my tests, which make me assume that this is about as far as you can go without aggressive caching concepts in the emulation core.

 

Cheers

-Christian

[DirtyHairy]

[duplicate deleted]

Edited September 24, 2016 by DirtyHairy

[ClassicGMR]

I'm using : MSI GT70 Dominator running Windows 10. My internet is very fast - 6gb down from toast.net using Blue Angels and Lunar Pages in CA (across the country from me). The wifi in the house is 5GHz and I get excellent signal.

 

Replayed Pressure Cooker just now. I found the speed display you mentioned - I didn't see that before - and as the game slowed down the timer dipped into the high 2.XX MHz range.

[DirtyHairy]

OK, there's definitely something funky going on here This beast is faster than my (already speedy) laptop and should have no trouble running the emulator whatsoever. Network speed is irrelevant; the emulation is 100% Javascript and runs locally in the browser. Data is stored locally, and nothing is transferred over the web (apart from the website itself).

 

I can run Pressure Cooker in Firefox 49 on linux just fine (apart from know fullscreen issues on FF, gotta fix those one of these days). Speed is constant at ~3.55MHz und goes to ~7MHz without frame limiter. I am very curious what the difference is. Some questions (provided you feel motivited to find out what's going on here):

 

* Do you observe similar lags or speed drops in other games?

* What speed do you get in Pressure Cooker when you disable the frame rate limit?

* Does anything change if you go to the settings and disable webgl?

* Does anything change if you go to the settings and disable the worker (the very first option, needs a reload to take effect)?

* Do similar issues occur in Chrome?

 

Btw, thanks alot for testing

[Thomas Jentzsch]

Quite good TIA emulation, even Meltdown works well.

 

Did you reuse an existing core or did you do it all on your own?

[+Gemintronic]

Still testing but this works with several of my batari BASIC games.

 

Edge works with WebGL disabled. It's slow though. <- Not complaining

[DirtyHairy]

Hi Thomas, hi theloon!

 

Thanks for testing and for the thumbs up

 

Quite good TIA emulation, even Meltdown works well.

 

Did you reuse an existing core or did you do it all on your own?

 

Thanks! The emulation core, including TIA, is original and written from scratch using Andrew Tower's TIA hardware notes and bits and pieces collected from the Atariage forums. Of course, debugging and trial'n'error was also required (there also is a debugger frontend that is, however, much less polished). In addition, I looked at the Stella source for inspiration at some points (mainly the latched TIA input ports and cartridge autodetection), and audio was modelled after code from Adam Wozniak by a pal of mine.

 

Still testing but this works with several of my batari BASIC games.

 

Edge works with WebGL disabled. It's slow though. <- Not complaining

 

Interesting, good to know. Out of curiosity: have you tried turning the worker off (you'll need to reload the page for this to take effect)? I am not sure whether edge supports transferables, and lack of this has the potential to cause considerable overhead in web worker mode.

[Thomas Jentzsch]

Thanks! The emulation core, including TIA, is original and written from scratch using Andrew Tower's TIA hardware notes and bits and pieces collected from the Atariage forums. Of course, debugging and trial'n'error was also required (there also is a debugger frontend that is, however, much less polished).

In that case, would you be interested to contribute to Stella? For quite some time we are looking for someone who rebuilds the TIA emulation core, which is pretty old by now.

[DirtyHairy]

Hi Thomas!

 

In that case, would you be interested to contribute to Stella? For quite some time we are looking for someone who rebuilds the TIA emulation core, which is pretty old by now.

 

Now I'm flattered I thought that TIA emulation was a solved problem in stella --- actually, Meltdown is the first example I'm seeing where stella seems to be off. What are the other issues with the current core?

 

Of course, I am open to the idea of helping in rebuilding the core or contributing a C++ version of the 6502.ts core rewritten for Stella. However, I would assume that the are currently more cases where the Stella implementation is superior to mine than vice versa. I know that there must be some effects relevant to horizontal positioning I am currently missing; for example, the crocodiles in Jungle Hunt start out with a vertical line in the middle for the first 8 or so pixels, and the little droids in Duck Attack are slightly shifted to the left. Also, there is currently no emulation of rsync. All in all, I think that some tuning is / would still be required to be on par with Stella's current core.

 

What do you think?

 

Cheers

-Christian

[Thomas Jentzsch]

Stella has a few more problems. E.g. the attached code shows unwanted copies on the left and right. It already looks better in your emulator (though not 100% correct).

 

When you are able to create you own emulation which is that good (and identify existing problems), I am sure you can be a valuable help for Stella too. Please contact Stephen Anthony, I am sure he will be very happy.

 

BTW: I would test more corner cases, but my own test ROMs use undocumented opcodes.

Tominv5.bin

[DirtyHairy]

 

 

Stella has a few more problems. E.g. the attached code shows unwanted copies on the left and right. It already looks better in your emulator (though not 100% correct).

 

Interesting; I'm curious to take a closer look at this in the debugger these days. I presume the white lines that appear at the left in 6502.ts when the invaders are getting close to the right edge are garbage?

 

 

 

When you are able to create you own emulation which is that good (and identify existing problems), I am sure you can be a valuable help for Stella too. Please contact Stephen Anthony, I am sure he will be very happy.

 

Thanks for the kind words I'll be sure to drop him a note.

 

 

 

BTW: I would test more corner cases, but my own test ROMs use undocumented opcodes.

 

Ahhhh, the infamous "invalid instruction" trap We'll that can be helped. A friend of mine is in the process of implementing the missing opcodes. Currently, we have dop, top, alr, axs, dcp and lax implemented, and I think he has arr ready, but not commited yet. If you give me a list or send me a few testcases, we'll add the missing ones. If you feel adventurous, you can also identify the missing opcodes in the debugger CLI at https://6502ts.github.io/dev/stella.html. I'm afraid there's polish and documentation missing, but there's at least tab completion

• Load the cartridge -> CLI goes from setup to debug mode
• Enter "trace-on" -> activates execution tracing
• Enter "run" -> run until the trap is encoutered
• Enter "trace" -> shows the last few opcodes and adresses, up to the unidentified instruction (you can also do "state" to dump the registers, p will point to the invalid instruction)
• Inspect memory at the offending address with "dump <address>" (the CLI accepts hex formatted like $FFFF or 0xFFFF)

Edited September 25, 2016 by DirtyHairy

[Keatah]

In that case, would you be interested to contribute to Stella? For quite some time we are looking for someone who rebuilds the TIA emulation core, which is pretty old by now.

 

I love it when Top Talent collaborates on a single project!

 

Edited September 26, 2016 by Keatah

[Thomas Jentzsch]

Interesting; I'm curious to take a closer look at this in the debugger these days. I presume the white lines that appear at the left in 6502.ts when the invaders are getting close to the right edge are garbage?

Exactly. On real hardware, the 11 invaders are displayed flawlessly.

 

Thanks for the kind words I'll be sure to drop him a note.

Great! Please keep us updated.

 

Ahhhh, the infamous "invalid instruction" trap We'll that can be helped. A friend of mine is in the process of implementing the missing opcodes. Currently, we have dop, top, alr, axs, dcp and lax implemented, and I think he has arr ready, but not commited yet.

That's sufficient. I ran a few tests and found no further flaws.

 

I suppose your core is trying to replicate the TIA to the bits and (for historical reasons) not to emulate it (like Stella does), correct?

[DirtyHairy]

That's sufficient. I ran a few tests and found no further flaws.

 

I suppose your core is trying to replicate the TIA to the bits and (for historical reasons) not to emulate it (like Stella does), correct?

 

Nice That's correct at least to some degree. My code tries to simulate the various interacting counters and clocking delays between register writes and actual effect precisely (the delays are a mixture of empiric data gained through debugging and my interpretation of Andrew Tower's notes). However, I do not simulate the multiple step increment stuff; all counters increment by one per clock, and the trip points are adjusted accordingly. Other things also simulated on a more effective basis --- for example, adjusting the player width will not change the clock at which the graphic register is shifted, but switches between precomputed bitmasks instead (I guess that switching player width during draw will currently produce an incorrect result, but I did not check). Still, I think my core is reasonably simple and pretty close to the hardware logic; I purposefully did not include any hacks that are just effective remedies for specific emulation failures.

Edited September 26, 2016 by DirtyHairy

[Thomas Jentzsch]

I purposefully did not include any hacks that are just effective remedies for specific emulation failures.

IMO THAT's the key point for getting close to 100% correctness. Those hacks and tweaks where required when the computer hardware was much less powerful than today. Back then you had to take shortcuts to make the emulation efficient. Stella's TIA core largely comes from that time.

 

So, if you would be able to implement your core into Stella, we all would gain a big improvement. And maybe, in a second step, we could also add parameters, which would allow emulating the various hardware variations.

[+stephena]

Just wanted to say that I'm still around, but dealing with an illness for the past several months (the last few weeks have been particularly brutal). That, and a backlog at work haven't allowed much time to work on Stella, or any of my personal projects for that matter.

 

The author of 6502.ts has indeed contacted me, and we are now working out how to proceed on developing a C++ core that can integrate into Stella. As soon as we get more info, we'll keep you updated.

[Thomas Jentzsch]

Get well soon!

[DirtyHairy]

Just a short status update: I am in communication with Stephen and working on porting the 6502.ts core to Stella. Work is happening in a fork of Stella hosted on Github (we'll merge back later), so you can have a look if you are curious: https://github.com/DirtyHairy/stella

 

All work I have done so far consists of the plumbing necessary to accomodate multiple core implementations and choose between them, so there is nothing to see apart from a (planned) segfault, yet Life currently doesn't leave me with much time for my private software projects, so progress is slow, but I guess there should be more coming in the next weeks.

[Thomas Jentzsch]

Thanks for the (positive) update. I was about to ask.

[DirtyHairy]

I am not currently tagging releases for 6502.ts (having a rolling release build at https://6502ts.github.io/stellerator/) and thus, I won't start a new release thread. Still, there has been a ton of improvements to 6502.ts since I originally started this thread. Most notably

• TIA emulation has evolved together with Stella and reflects the current state of Stella 5
• Timers have been vastly improved; all RIOT-related bugs should be gone now
• CPU emulation has slightly improved, and many undocumented opcodes are now implemented
• I have implemented a few new bankswitch schemes, including supercharger
• There is a new experimentlal "merge frames" setting that reduces the frame rate pumped out by the emulator. I would be interested whether this option improves things if you are experiencing slowdowns on desktop grade machines

As before, the emulator runs best on Chrome and Firefox. Edge and Safari work to varying degrees --- Edge reportedly only with WebGL disabled, and Safari may show have with importing and managing cartridges due to its broken IndexedDB implementation.

 

If you'd like to report bugs, please include the build number at the bottom of the help page.

Edited March 5, 2017 by DirtyHairy

[DirtyHairy]

A slab of improvements has landed in 6502.ts since my last post above, so I guess it is time for another update The most significant changes are:

• DPC and DPC+ (including ARM!) emulation has been added. Mind you that there is currently no music support for these as the current oscillator-based approach is ill-suited for this. This will change eventually.
• Still more accurate timers; fixes a bunch of hangs (e.g. Panda Chase)
• Palette updated to match Stella
• Performance improvements (actual speedup depends on the way the code utilizes the TIA and can be up to 100% for some games)

As before, there is no fixed release, but the changes are live in the rolling build at https://6502ts.github.io/stellerator/, so feel free to test if you like.

Edited May 1, 2017 by DirtyHairy

[+SpiceWare]

Nicely done

 

 

 

 

Though surprisingly Space Rocks isn't working. At first I see just this:

 

But if I click on a different menu (like Settings) then on Emulation I see this:

[DirtyHairy]

Thanks alot, fixed After refreshing, the current build number (on the help page) should now read 5eeb3a .

 

 

"Trap 0" is a bit of a misnomer as it really means that the ARM runs the max number of cycles without returning, so the emulator assumes it has gone fishing. I've increased the max cycle count to match stella --- I guess I shouldn've done so in the first place . Actually, I have two versions for Space Rocks here: an older one labeled spacerocks20120430.bin and a newer one labeled spacerocks20121129_PAL.bin. I only tested the older one before which worked fine without this change

Edited May 1, 2017 by DirtyHairy