Composite Fringe Colors and tohr palette colors

Size: px

Start display at page:

Download "Composite Fringe Colors and tohr palette colors"

Bruce Mosley
5 years ago
Views:

1 Composite Fringe Colors and tohr palette colors Discussion: AppleWin and AppleWin NTSC Rendering - Composite Fringe Colors and tohr palette colors (too old to reply) 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? Post by 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?

2 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. Post by 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? Hi, 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: 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": 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

3 (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: 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. --

4 -michael - NadaNet 3.1 and AppleCrate II: 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. 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

5 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 To me Sheldon's stuff has provided exceptional pure entertainment and enjoyment. Anyway, just saying. Post by Buckels 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:) 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.

6 I've started a new thread, and GitHub bugs to address this: * "AppleWin Color Accuracy" - 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. 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 Links Get a free Evernote account to save this article and view it later on any device. Create account

Win32 and latest version complete with source:

Rolling Your Own Dithers in Bmp2DHR Download Bmp2DHR at the following links: Win32 and latest version complete with source: http://www.appleoldies.ca/cc65/programs/dhgr/bmp2hr.zip MS-DOS: http://www.appleoldies.ca/cc65/programs/dhgr/bmp2dhrmsdos.zip