AppleWin and AppleWin NTSC Rendering - Composite Fringe Colors and tohr palette colors

Discussion:

(too old to reply)

Bill Buckels

2014-11-13 02:27:45 UTC

I have been working with Sheldon Simms AppleWin NTSC along with my DHGR
converter. Sheldon's rendering is just excellent and so is his composite
palette for his tohgr converter's DHGR output.

It has taken me quite awhile to get up to speed on some of this.

So now where I am is either wanting Sheldon's Source code or to reverse
engineer his rendering routines.

What are your comments on any of this?

Bill

Ralph Glatt

2014-11-13 19:25:27 UTC

Permalink

Post by Bill Buckels
I have been working with Sheldon Simms AppleWin NTSC along with my DHGR
converter. Sheldon's rendering is just excellent and so is his composite
palette for his tohgr converter's DHGR output.
It has taken me quite awhile to get up to speed on some of this.
So now where I am is either wanting Sheldon's Source code or to reverse
engineer his rendering routines.
What are your comments on any of this?
Bill

I don't see what harm there is to ask Sheldon, but if he can't help you, you'll probably have to do the reverse engineering.

TomCh

2014-11-16 20:14:35 UTC

Permalink

Hi Bill,

Some background: a few years ago (actually 4 years now!), Sheldon GPL'd the code and committed it to the AppleWin repository. This now resides in github:
https://github.com/AppleWin/AppleWin/tree/AppleWin-Sheldon

Recently, I've been looking at Sheldon's work to try to figure out the best way to integrate it into the current AppleWin main-line.

Sheldon's code not only supports 4 NTSC modes: {b/w, colour} x {TV, monitor}; but is also cycle accurate, meaning it supports video mode switching, albeit with mixed success (try the end credits of French Touch's "Ansi Story": http://www.ctrl-pomme-reset.fr/french-touch/).

The cycle accuracy means that emulation is slower then regular AppleWin. Keeping up with a 1MHz 6502 is easy, but AppleWin will switch to unthrottled emulation speed when the Disk][ motor is on as a way to significantly reduce load times. Also being able to use the ScrollLock key to temporarily apply an emulation "burst" to skip through unwanted game sections is very useful.

I'd first like to support the NTSC modes without the cycle accuracy (since there's only a handful of intros/demos that use this technique). Then make cycle accuracy an option.

Dropping the existing AppleWin display modes is also an option, but there is still value in some of these modes, eg 'Color (TV Emulation)' which does vertical colour blending (used by many titles, eg. Karateka, Blazing Paddles, MindShadow, etc). Obviously this vertical blending can be applied to Sheldon's NTSC colour TV mode, but one step at a time, right? :)

So my initial focus would be on adding the NTSC modes (to sit alongside the existing mode).

Tom

Michael J. Mahon

2014-11-17 01:48:25 UTC

Permalink

Post by TomCh

Hi Bill,
Some background: a few years ago (actually 4 years now!), Sheldon GPL'd
https://github.com/AppleWin/AppleWin/tree/AppleWin-Sheldon
Recently, I've been looking at Sheldon's work to try to figure out the
best way to integrate it into the current AppleWin main-line.
Sheldon's code not only supports 4 NTSC modes: {b/w, colour} x {TV,
monitor}; but is also cycle accurate, meaning it supports video mode
switching, albeit with mixed success (try the end credits of French
Touch's "Ansi Story": http://www.ctrl-pomme-reset.fr/french-touch/).
The cycle accuracy means that emulation is slower then regular AppleWin.
Keeping up with a 1MHz 6502 is easy, but AppleWin will switch to
unthrottled emulation speed when the Disk][ motor is on as a way to
significantly reduce load times. Also being able to use the ScrollLock
key to temporarily apply an emulation "burst" to skip through unwanted
game sections is very useful.
I'd first like to support the NTSC modes without the cycle accuracy
(since there's only a handful of intros/demos that use this technique).
Then make cycle accuracy an option.
Dropping the existing AppleWin display modes is also an option, but there
is still value in some of these modes, eg 'Color (TV Emulation)' which
does vertical colour blending (used by many titles, eg. Karateka, Blazing
Paddles, MindShadow, etc). Obviously this vertical blending can be
applied to Sheldon's NTSC colour TV mode, but one step at a time, right? :)
So my initial focus would be on adding the NTSC modes (to sit alongside the existing mode).
Tom

I was under the impression that Sheldon's emulations looked great without
needing vertical blending--after all, most color monitors displayed
discrete, non-overlapping scan lines when displaying the Apple's
non-interlaced video.

Also, cycle-accuracy is only needed when running at authentic 1MHz speed,
where there should be plenty of spare time to keep cycle-accurate. Any
program splitting the video modes will sync with the video generator just
prior to doing the splitting, so it's not necessary to stay synced while
running accelerated.

--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

TomCh

2014-11-17 21:01:15 UTC

Permalink

Post by Michael J. Mahon

Post by TomCh

I was under the impression that Sheldon's emulations looked great without
needing vertical blending--after all, most color monitors displayed
discrete, non-overlapping scan lines when displaying the Apple's
non-interlaced video.
Also, cycle-accuracy is only needed when running at authentic 1MHz speed,
where there should be plenty of spare time to keep cycle-accurate. Any
program splitting the video modes will sync with the video generator just
prior to doing the splitting, so it's not necessary to stay synced while
running accelerated.
--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

Nope, Sheldon's rendering doesn't do the (TV only) vertical blending, eg. the grey floor during Karateka gameplay.

But good point (re. cycle accuracy) it can be disabled during disk access or burst (ScrollLock) full-speed modes.

Tom

Michael J. Mahon

2014-11-17 21:38:36 UTC

Permalink

Post by TomCh

Post by Michael J. Mahon

Post by TomCh

I was under the impression that Sheldon's emulations looked great without
needing vertical blending--after all, most color monitors displayed
discrete, non-overlapping scan lines when displaying the Apple's
non-interlaced video.
Also, cycle-accuracy is only needed when running at authentic 1MHz speed,
where there should be plenty of spare time to keep cycle-accurate. Any
program splitting the video modes will sync with the video generator just
prior to doing the splitting, so it's not necessary to stay synced while
running accelerated.
--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

Nope, Sheldon's rendering doesn't do the (TV only) vertical blending, eg.
the grey floor during Karateka gameplay.
But good point (re. cycle accuracy) it can be disabled during disk access
or burst (ScrollLock) full-speed modes.
Tom

That's good.

WRT vertical blending, I was actually saying that real monitors didn't do
it either, unless they were badly out of focus. ;-)

Blending of adjacent scan lines is more a function of the human eye than
the monitor. I don't see it as an appropriate emulator function.

--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

Michael AppleWin Debugger Dev

2014-11-19 12:45:13 UTC

Permalink

Post by Michael J. Mahon
WRT vertical blending, I was actually saying that real monitors didn't do
it either, unless they were badly out of focus. ;-)
Blending of adjacent scan lines is more a function of the human eye than
the monitor. I don't see it as an appropriate emulator function.

We used to have our Apple ][+ hooked up to a TV.
I could of swore that the TV made Karateka's floor look grayish.
Since we all use LCD monitor these days we don't get the bad NTSC color "bleed" like we used to on a CRT.

From a "purist's" POV, we shouldn't be doing perceptual "hacks" like this.
However from a QoL POV, emulating the color bleed is perfectly fine when it is an option that the user can toggle based on their preferences.

Bill Buckels

2014-11-21 01:54:08 UTC

Permalink

Post by Michael AppleWin Debugger Dev
From a "purist's" POV, we shouldn't be doing perceptual "hacks" like this.

I know what you are saying and why, but I really disagree when it comes to a
presentation layer for graphics modes. The graphics UI should be all about
perceptual hacks. AppleWin's colors are really poor, not pure. Not pure at
all. What's with the 2 greys in AppleWin anyway? An identity crisis:)

The Kegs32 colors are for an RGB display which has 2 greys, and they are
directly from Super Convert. CiderPress's RGB colors aren't from Super
Convert and it shows.

Apple II NTSC Palettes seem to be awful, like what Cybernesto used with VBMP
or the Wikipedia Palette that I ran around with for several months before I
realized that Sheldon Simms AppleWin NTSC and toghr have the best NTSC
colors with Blurry's Jace being close when it comes to color.

Post by Michael AppleWin Debugger Dev
However from a QoL POV, emulating the color bleed is perfectly fine when it
is an option that the user can toggle based on their preferences.

From a purist perspective if it's not going to be an Apple IIe emulator with
the proper colors and color effects, then someone may as well add a VOC to
it, and use IIgs RGB colors and support Super Hi-Res and Arbitrary Palettes
that suit the LCD display and be done with NTSC authenticity. And DHGR and
HGR will look even worse.

But then I am becoming more of a purist. BTW my Apple II's always had good
monitors and good color TVs too. So do my C64 and C128. But from pretty much
the time of the first IBM-PC I usually had several good ones kicking-around
so didn't get traumatized and neither did my kids because there were lots of
good monitors and computers and gaming systems and good TV's for them too.

I bought my first Sony Trinitron in 1976.

To me Sheldon's stuff has provided exceptional pure entertainment and
enjoyment.

Anyway, just saying.

Bill

Michael AppleWin Debugger Dev

2014-12-15 20:28:42 UTC

Permalink

Post by Bill Buckels

Post by Michael AppleWin Debugger Dev
From a "purist's" POV, we shouldn't be doing perceptual "hacks" like this.

Agreed AppleWin's color accuracy, uhm, leaves a lot to be desired. I almost blew a gasket when I saw how bad the GR colors were!

I spent some time cleaning up the code this weekend. At least some of the internal names are at least correct! (HGR_ORANGE was called RED, HGR_VIOLET was called MAGENTA.)

The color palette stuff was really hacked together. My goal is to "collapse" all the colors down to around 20 colors instead of having separate colors for GR, HGR, and DHGR.

I've started a new thread, and GitHub bugs to address this:

* "AppleWin Color Accuracy" - https://groups.google.com/forum/#!topic/comp.emulators.apple2/CfUzR1tVndM

Truth be told, I haven't actually done any DHGR programming before. But now that the debugger BSAVE command supports the AUX memory bank it should be relatively easy to through together a 4x4 DHGR color chart for comparison.

TomCh

2014-11-17 21:36:58 UTC

Permalink

Post by Michael J. Mahon

Post by TomCh

I was under the impression that Sheldon's emulations looked great without
needing vertical blending--after all, most color monitors displayed
discrete, non-overlapping scan lines when displaying the Apple's
non-interlaced video.
Also, cycle-accuracy is only needed when running at authentic 1MHz speed,
where there should be plenty of spare time to keep cycle-accurate. Any
program splitting the video modes will sync with the video generator just
prior to doing the splitting, so it's not necessary to stay synced while
running accelerated.
--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

btw. the video splitting is very nice: DLORES -> TEXT80 -> DLORES each scanline.
The vertical text scrolling whilst maintaining the split is nicely done!

See 3:20 here (and clearer in monochrome at 5:05):

Tom