Re: NTSC Emulation

[BLuRry <brendan.robert@gmail.com>]

On Jan 23, 11:58 pm, Sheldon Simms <wsspa...@gmail.com> wrote:
> On 2011-01-24 00:30:16 -0500, Steve Nickolas said:
>
>
>
>
>
>
>
>
>
> > On Mon, 24 Jan 2011, Sheldon Simms wrote:
>
> >> 50% is maximum load, not typical. The main reason it consumes so
> >> much CPU is that the display routine is ideally called after every
> >> emulated instruction. You can save CPU at the cost a loss of emulation
> >> accuracy by calling it less often.
>
> > If I recall correctly, the rewritten video core in Dapple called the
> > display routine once every 65 emulated 65SC02 cycles, covering a single
> > scanline at a time.
>
> > Whatever it did, it did well - within the limit that it was drawing to
> > a 320x200 buffer (as it was the only way we could get reasonable speed
> > at the time).  I suppose if Holger Picker's line by line strategy and
> > your actual emulation were combined, the results would be utterly
> > mindblowing.
>
> It's interesting that you mention Holger because I had some lengthy email
> discussions with him about 10 years ago on the topic of video emulation.
> He's one of the few people that ever saw my IIe emulator of the time, which
> had a very accurate emulation of video scanning (but no NTSC emulation).
> I wrote some simple demos that did weird things with switching video modes
> and made sure my emulator displayed them properly. It was the thought of
> dragging that corpse back up out of the grave that got me working on the
> stuff we're talking about now.
>
> I don't recall ever trying Dapple, but my emulator of the time called the
> display routine after every instruction. If you only call it once per scanline
> then you have to keep track of anything that happens during those 65
> cycles and apply it after the fact anyway. I'm skeptical that you gain anything
> by doing that, well besides about 10 * function call overhead, unless you
> decide that you don't care if the video mode switches mid scanline, but
> that would just be Wrong (TM).
>
> > How much overhead does SDL have?  I'd recommend any new emus are best
> > done to target a multi-OS library if possible.
>
> I wouldn't want to use SDL. The system-specifc parts of this code are
> currently very small. All you need is an offscreen drawing area and a way
> to copy it to your window.
>
> Actually the core of any emulation is almost completely system-independent.
> It's just all the user interface stuff that's so system-specific.

That is a really nice NTSC emulation routine!  Is it open source?  ;-)

If your're rendering per-scanline, then you could also trap when a
scanline changes and keep a table of boolean values to capture if a
scanline has been modified.  Also keep a global boolean to indicate if
the whole screen should be redrawn (when video modes change).  Doing
this, you can bypass redrawing a scanline if it wasn't changed at all
-- and also avoid redrawing the whole screen (scaling to window) if
there hasn't been a single change.  After I did this, JACE is still
very fuel-efficient even when set to 1920x1080 resolution using Java2D
image scaling.

-B