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

[+SpiceWare]

Nice!

 

Here's another one:

DPC+Timer.zip

 

 

 

Nothing uses the ARM's timer yet, but I will be using it for Draconian as detailed in this blog entry. The address in the error message doesn't make sense for the timer though aha - looks like it's treating it as a signed value.

 

These were added in the Thumbulator for the timer:

  public:
    string run(uInt32 cycles); // pass the # of 6507 cycles since last call to run()

    void setConsoleTiming(ConsoleTiming timing); // selects NTSC(default), SECAM or PAL

  private: 
    void updateTimer(uInt32 cycles); // run(cycles) calls this, then the original run()

    uInt32 T1TCR;  // Timer 1 Timer Control Register
    uInt32 T1TC;   // Timer 1 Timer Counter
    double timing_factor;

[DirtyHairy]

[deleted duplicate]

Edited May 2, 2017 by DirtyHairy

[DirtyHairy]

Thanks for the testcase I am aware of the timer and the Stella implementation, but, evidently, I haven't implemented it yet. I will do so, but I don't know when, depends on how much time I can allocate for Stella and 6502.ts in the next few weeks. The formatting as a signed number is due to me carelessly using intrinsic Javascript formatting functions: in JS, there is only a single number type that is either treated as a signed 32 bit integer (if it can be represented as such) or as a double Needless to say, this has some interesting performance implications. If you take the two's complement, you end up with 0xE0008008, which makes a lot more sense. I guess I should fix the formatting there.

 

For the time being, I have created two bugs:

• https://github.com/6502ts/6502.ts/issues/57
• https://github.com/6502ts/6502.ts/issues/56

[+SpiceWare]

Sounds good.

 

As a temporary solution to at least allow such ROMs to run, make it so these two registers:

#define T1TCR   *(unsigned int*)0xE0008004 // Timer Control Register
#define T1TC    *(unsigned int*)0xE0008008 // Timer Counter

---

can be written to and read from. Ignore the writes, return 0 for the reads, and the games will detect as NTSC due to how console type is detected:

        if (T1TC < (0x11e8ff + 0x11d329)/2)
            MM_TV_TYPE = 0; //NTSC;
        else if (T1TC > (0x11fd2b + 0x11e8ff)/2)
            MM_TV_TYPE = 1; //PAL;
        else
            MM_TV_TYPE = 2; //SECAM;

[DirtyHairy]

Implemented and works in rolling build (7e6342), together with the formatting issue a few other DPC+ - unrelated fixes That should do the trick until I find time to do a proper implementation.

[+SpiceWare]

That should do the trick until I find time to do a proper implementation.

Nice - probably should leave #56 open though until the timer's really implemented.

[DirtyHairy]

Nice - probably should leave #56 open though until the timer's really implemented.

 

Indeed, didn't think when wrote the commit message (that's what closed the ticket).

[Mr SQL]

DirtyHairy,

Have you thought about having Stellerator not merge frames by default for more accurate emulation?

 

Merging frames is a nice feature because it enhances many games; by merging 4 frames you can render 20 sprite objects on the same scanlines with no flicker but then your emulator starts to be become it's own platform. Many demo's, some new games and classics like ESB break apart when only two frames are merged like in your configuration.

 

Any plans to add support for more classics like SuperCharger games? The modern ARM games written in C are better than their arcade counterparts but I prefer classic gaming and playing new classics that could survive a trip in the Delorean.

 

[DirtyHairy]

Have you thought about having Stellerator not merge frames by default for more accurate emulation?

 

Merging frames is a nice feature because it enhances many games; by merging 4 frames you can render 20 sprite objects on the same scanlines with no flicker but then your emulator starts to be become it's own platform. Many demo's, some new games and classics like ESB break apart when only two frames are merged like in your configuration.

 

There are three things that Stellerator currently can do

1. Do a refresh each frame and calculate a weighted average over the last three frames. That's what happens in WebGL mode (it's done in a shader, that's why it's GL only).
2. Display each frame separately. That's what happens when WebGL is turned off.
3. Merge frames in pair and drive the rendering at a reduced framerate. That happens before (1) or (2) and is toggled by "Reduce framerate". The result looks similar to Stella's phosphor mode without WebGL, but gives very blurry results with WebGL enabled.

What I plan to implement once I find the time to do so is:

• Make the number of frames averaged in WebGL mode configurable, including no averaging at all. This will also render frame merging usable in WebGL mode.
• Revise the settings to be more transparent about what happens.
• Add a way to override those settings on a per-game basis.

I find the absence of any merging to be the most annoying setting as is it pronounces beating effects between the 50/60 HZ framerate (manifesting as irregularities in the flicker pattern) and the monitor refresh rate, but this depends on personal taste and setup. My inclination is to keep the default as it is, but the setting is persistent, so I don't think it is a big deal. I also plan to add an API for embedding the emulator in other webpages at some point (provided anyone shows interest in this), and in this case, this would be a configuration option.

 

Any plans to add support for more classics like SuperCharger games? The modern ARM games written in C are better than their arcade counterparts but I prefer classic gaming and playing new classics that could survive a trip in the Delorean.

 

Supercharger images are fully supported (as are all "classic" bankswitch types). They should identify as "bankswitched supercharger" and play just fine.

Edited May 3, 2017 by DirtyHairy