Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can we have the option Color (TV Emulation) back? #616

Open
tomcw opened this Issue Jan 12, 2019 · 32 comments

Comments

Projects
None yet
4 participants
@tomcw
Copy link
Contributor

tomcw commented Jan 12, 2019

Spun off from #357.

Mark / @6502-workshop is requesting this:


Hi Tom,

My current preference is not to just reinstate the old 1.25 "Color (TV Emulation)"... although admittedly just adding it is the easiest option. Let me think about it.

Thanks for considering it! Currently there is no Apple II emulator I'm aware of which does vertical blending in a way where colors like yellow and dark blue are visible (other than AppleWIN 1.25.04 of course), it would be really great to have Color (TV Emulation) as a workaround until a better solution is implemented, such as #344.

But, I totally understand if you decide not to do it. I'm sure there are factors like technical debt, prioritization, and other things to consider.

Again, thanks for even considering it!

Mark


I also commented:

I see "text optimized" similar to "vertical blending", ie. as a style or post-effect.

And Michael asked:

I guess that raises a question -- are we going to bring back Text Optimized mode for 1.27 ?

I've no plans to at the moment. I'd rather limit the feature set to those that there's strong demand for (initially). Mark (above) nails it with "factors like technical debt, prioritization", and also increased testing matrix.

@tomcw tomcw added the enhancement label Feb 17, 2019

@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Feb 17, 2019

@6502-workshop: I'm considering adding this back in as an experimental feature, as I'd like to get this old 1.25 code into the mainline before I forget too much(!).

Here's what I'm thinking:

  • support "vertical color blending" (for hires only) as a video style (so not as a 1st class video type).
  • when this style is enabled, then it's available only when you select the "Color (RGB Monitor)" video type.
    • so the current hires rendering (for "Color (RGB Monitor)") gets replaced by this "vertical color blending".
  • initially only allow this style to be enabled via a command line switch.
    • there's no way to disable it without quitting AppleWin, then relaunching without the switch.

Does this sound useful to you at all?

@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Feb 17, 2019

Perhaps for the final point (about enabling via a command line switch), it'll be easy to extend the Config's UI with a checkbox...

@6502-workshop

This comment has been minimized.

Copy link

6502-workshop commented Feb 18, 2019

Thanks for the update!

Having "vertical color blending" only available via a command line switch wouldn't be that useful (I doubt many of our players would take the time to do it), but it sounds like you'd eventually connect the switch to the Config's UI and that I think would be useful. I think we can get a lot of players to tick a box in the config.

In the long run, such as via #344, do you envision "vertical color blending" being be part of the default video mode at some point?

Thanks again for considering this topic.

Mark

tomcw added a commit that referenced this issue Feb 24, 2019

Support vertical blending for 'RGB (Color Monitor)' for hires (#616) …
…(PR #624)

Support the old AppleWin 1.25 vertical blending for hires:
- extended Config dialog to include 'Vertical Blend' checkbox
- Persist 'Video Styles' to Registry
- new cmd line options to select this style & also select 'RGB (Color Monitor)'
- code refactor to support enum VideoStyle_e (and replaced g_uHalfScanLines with a bit in g_eVideoStyles)

Bumped version to 1.28.2.0.
@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Feb 25, 2019

Hi Mark,

OK, I've added this new video style: "Vertical blend". It's a UI checkbox on the Configuration dialog, and is only active for the "RGB (Color Monitor)" video mode - basically it's the same(*) as AppleWin 1.25.0's "Color (TV Emulation)".

You can try it in AppleWin 1.28.2.0 here.

Let me know how you get on.

(*) Hmm... actually for AZTEC's title screen, the top-left "©1982" is very clear in 1.25.04, and virtually unreadable in 1.28.2.0. I'll take a look at this, but it's not a show-stopper(!).

@sicklittlemonkey

This comment has been minimized.

Copy link
Contributor

sicklittlemonkey commented Feb 25, 2019

If you load up screenshots of the new 1.28 blended and unblended into Paint.NET or similar, there's a whole lotta shifting going on that doesn't happen in 1.25.

Otherwise, interesting.

Cheers,
Nick.

@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Feb 26, 2019

The reason for the difference (1.28.2 vs 1.25) is that for 1.25.0.4:

  • 'Color (TV emulation)' uses V_CreateLookup_Hires()
  • 'Color (Standard)' uses V_CreateLookup_HiResHalfPixel_Authentic()

Whereas for 1.28.2, I was just using V_CreateLookup_HiResHalfPixel_Authentic().

1.25.0.4 vertical blended:
aztec_tv 1 25 0 4

1.28.2 vertical blended:
aztec_blended 1 28 2

1.28.2 not blended:
aztec_not_blended 1 28 2

@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Feb 26, 2019

Zooming in on the detail between 1.28.2 (not-blended vs blended), the blended version doesn't support the half-dot shift, which explains by "©1982" is so "ragged" or unreadable.

Here's a zoom-in on the "1" character, showing the purple and blue dots being 2 pixels apart for the blended image:

aztec-1-zoom
NB. Using Beyond Compare v4 (comparing 2 picture files).

Also from the code, you can clearly see that CopyMixedSource() operates on 7M pixel units (by duplicating 2x 14M pixels), with my recent comment:

// NB. This operates at the 7M pixel level: 2 identical 14M pixels are written per inner loop (so no support for half-dot-shift, eg. Archon's title)
@6502-workshop

This comment has been minimized.

Copy link

6502-workshop commented Feb 26, 2019

Thanks Tom!

I booted up Nox Archaist in 1.28 and here are the results:

The vertical blending to display the yellow in the treasure pile looks great, just like 1.25.04
screen shot 2019-02-26 at 5 27 37 pm

The only downside I'm seeing is some orange lines to the left of the player and some mobs. I'm not sure if this is something different than what you and Nick are talking about so I thought I'd mention it

1.28 Color Monitor (RGB), vertical blend
screen shot 2019-02-26 at 5 31 57 pm

This also happens in 1.28 Color Monitor (RGB, no vertical blend)

screen shot 2019-02-26 at 5 54 57 pm

But not in 1.28 Color Monitor (NTSC)
screen shot 2019-02-26 at 5 48 10 pm

And not in 1.25.04 Color (TV Emulation)
screen shot 2019-02-26 at 5 52 58 pm

@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Feb 27, 2019

Hi Mark,

I don't know about the orange line.
Can you send me a memory dump of the HGR screens?

EG, from the debugger (F7):
bsave "hgr1+2.bin",2000:5fff

You can paste this line in with CTRL+V.
NB. The files get saved to the current working directory - use pwd to show this.
Then attach them in a zip file here.

@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Feb 27, 2019

Hi Nick,

I changed CopyMixedSource() to operate on 14M pixels, which now shows AZTEC correctly, and Archon's logo with a smooth "A". This now makes this vertical blend rendering consistent with all the other video modes (ie. they all operate on 14M pixels).

Here's the same zoomed-in "1" character as before, now (RHS) the purple and blue dots are blended on the vertical overlap:

aztec-1-diff

@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Feb 27, 2019

So the old 1.25.0.4 'Color (TV Emulation)' mode (ie. vertical blended) offers the worst horizontal resolution since it only operates on 7M pixels, or 280 horizontal pixels - ie. has no ability to render half-dot shifted pixels.

@sicklittlemonkey

This comment has been minimized.

Copy link
Contributor

sicklittlemonkey commented Feb 27, 2019

@6502-workshop

This comment has been minimized.

Copy link

6502-workshop commented Feb 28, 2019

Hi Tom,

Thanks for taking a look!

The hi-res memory dump is attached, generated from the same screen as shared above, using 1.28 Color Monitor (RGB), vertical blend

hgr1+2.bin.zip

@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Feb 28, 2019

Hi Mark,
Hmm... that memory dump just contains (what looks like) power-on values for memory (eg. repeated 0xFF FF 00 00... values for the whole 16K). I don't know why this doesn't contain the HGR screens... unless it's dumped the aux memory?

Could you try again with these:
bsave "hgr1+2-main.bin",0:2000:5fff
bsave "hgr1+2-aux.bin",1:2000:5fff

Thanks.

@sicklittlemonkey

This comment has been minimized.

Copy link
Contributor

sicklittlemonkey commented Feb 28, 2019

It can't be from aux because it looks like aux doesn't get the FF init values.

I used this to test the saving behaviour, which does save aux if you don't specify and it's switched in:

!
300: STA $C000
 STA $C005
 LDA #4C
 STA $318
 LDA #18
 STA $319
 LDA #03
 STA $31A
 STA $C003
 RTS

@6502-workshop

This comment has been minimized.

Copy link

6502-workshop commented Feb 28, 2019

Hi Tom,

Sorry for the mix up. I'm not sure what happened.

I ran the commands you suggested and this time the BIN file for main appears to match the contents of HGR in main.

Both BINs are in this zip file but the graphics are being rendered from main memory.

hgr.zip

@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Mar 1, 2019

Thanks Mark - this contains the HGR video data. I'll take a look at this in the coming days.

@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Mar 1, 2019

@nick: yes, you're right: only main mem gets init'ed with values on power-on.

And the bsave/bload syntax is a bit cryptic:

bsave "file",start:end		; for currently mapped (virtual) memory (RAM or ROM or IO space)
bsave "file",bank:start:end	; for physical memory (RAM-only)
@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Mar 2, 2019

Hi Mark,

I'm looking at your HGR video data now...

The slightly longer (horizontal) orange line to the left of the player is because the graphics go from green (high bit=0) to orange (high bit=1), so 1.5 hires dots of orange are drawn (1.5 hires dots = 3 x 14MHz dots).

Below is a comparison of 1.25-'Text Optimized' vs 1.25-'Color TV' videos modes:

player1 25 textopt-vs-colortv

As stated above, the old 1.25 'Color TV' mode only rendered 280 horizontal pixels, and so didn't cater for the high-dot shift (ie. high bit=1), so wasn't very accurate.

OTOH, the old 1.25 'Standard' (or 'Text Optimized') video modes don't seem to do a good job of rendering this extended 1.5 hires dot - resulting in this slightly longer orange line that you noticed.

Finally, 1.28.2 uses a 560-pixel look-up table (for horizontal colour), then does 280-pixel vertical blending, which gives some poor results: eg. the "©1982" (for Aztec) and the the missing right-hand edge of the shield in the image you included above (which is half an orange hires pixel hide).

tomcw added a commit that referenced this issue Mar 2, 2019

@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Mar 2, 2019

Development note about CopyMixedSource() for Debug builds:

  • 7M mode it takes ~40% of a core @ cba3b76.
  • 14M mode it takes ~100% of a core (resulting in some noisy sound) @ 82c2f3d.

Release builds only show as 0% in Task Manager.

@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Mar 3, 2019

Using Michael's HGR screen explorer tool (https://github.com/Michaelangel007/apple2_hgrbyte) the rendering issue is with these HGR video bytes:

$3E37: 40 9E
-> [0]000 0001 [1]011 1100 ; [high-bit] + 7 pixels, bit-reversed
-> 00 00 00 00 00 00 11, 100 11 11 11 11 00 00 ; expanded to 14M pixels, where the bold 1 is for the half-dot shift gap (verified by looking at the monochrome rendering)

In V_CreateLookup_HiResHalfPixel_Authentic(), the look-up table corresponding to this is:

; aPixels[idx]:
; idx:                01   2345678   9A
; 7M video bits: -----01 | 0111100 | ??-----

if( hibit )
	if ( aPixels[1] ) // preceding pixel on?
		if (aPixels[2] || aPixels[0])	* not true
		{...}
		else   // Optimization:   odd = (iPixel & 1); if (!odd) case is same as if(odd) !!! // Reference: Gumball - Gumball Machine
		{
			SETSOURCEPIXEL(SRCOFFS_HIRES+offsetx+x+0 ,y  , HGR_ORANGE ); // left half of orange pixels 
			SETSOURCEPIXEL(SRCOFFS_HIRES+offsetx+x+0 ,y+1, HGR_ORANGE );
			...
		}

In SETSOURCEPIXEL(), changing HGR_ORANGE to HGR_BLACK corrects the Nox Archiast case, but leads to half-pixel black gaps when the screen has consecutive orange bytes, eg:

HGR:HCOLOR=5:HPLOT0,0TO279,0

To correct this perhaps we'd need to account for the previous video byte's high bit?
(EG. If previous hibit=0 and current hibit=1, then HGR won't be showing continuous orange)
But this doesn't fit with the current look-up table design.

@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Mar 3, 2019

FYI, I did a new release (AppleWin 1.28.3) which does vertical blending using 560-pixel granularity for half-dot shift support (consistent with all other video modes).

@mark: This doesn't address your orange-line issue.

@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Mar 4, 2019

1.25.0.4 (Color TV):
1 25 0 4

Current 1.28.3 (with orange line to the left of the player):
1 28 3-orange-line

To correct this perhaps we'd need to account for the previous video byte's high bit?

Instead, I've tried looking at the bits to the right, and under a special condition, don't replicate the half-dot of orange in the gap between a non-shift and shift video byte. Instead I use a half-black dot:
(Orange to the left of the player and left of the dog's tail)
1 28 4-orange-corrected

@6502-workshop

This comment has been minimized.

Copy link

6502-workshop commented Mar 4, 2019

Tom, thanks for taking a look!

Instead, I've tried looking at the bits to the right, and under a special condition, don't replicate the half-dot of orange in the gap between a non-shift and shift video byte. Instead I use a half-black dot:
(Orange to the left of the player and left of the dog's tail)

screen shot 2019-03-04 at 4 20 28 pm

This is definitely an improvement. I think the only remaining difference vs. 1.25.04 I can see are the orange pixels to the right of the green pixels (grass) in two locations: left/center from the player and left/lower from the dog.

@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Mar 9, 2019

Instead, I've tried looking at the bits to the right, and under a special condition, don't replicate the half-dot of orange in the gap between a non-shift and shift video byte.

I extended this to correct "the orange pixels to the right of the green pixels (grass)...":

1 28 4-orange-corrected2

But unfortunately this results in poor rendering for Sherwood Forest's orange "stipple" pattern and also Fantavision's mixed palette:

Sherwood-Detail-OrangeCorrected2
(Orange stipple isn't uniform)

Fantavision-Palette3-OrangeCorrected2-2x
(Bottom row, both 3rd and 2nd from right side have a half-pixel black vertical (dashed) line)

I'll have a go at changing the look-up table to take the previous byte's high-bit into account...

@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Mar 10, 2019

Hi Mark,

Here's an experimental AppleWin 1.28.3.1: Applewin1.28.3.1.zip

  • just unzip over your previous AppleWin installation.

(NB. It's been run ok through the full suite of regression tests.)

It now solves the rendering issues you highlighted by only applying my prior fix if there's a half-dot gap, ie. previous video byte has high bit=0 and current video byte has high bit=1 (and a few other conditions too!).

I've also made a few implementation changes to this "Color (RGB Monitor)" mode, ie for lores, hires, dhires. So if you see anything different then let me know.

Assuming this looks good for you, then I'll put it out a more formal GitHub release (+ there are a few other things I want to look at).

@6502-workshop

This comment has been minimized.

Copy link

6502-workshop commented Mar 14, 2019

Hi Tom,

Sorry for the delay.

1.28.3.1 look great! I don't see any issues.

Thanks much!

Mark

@H82lose

This comment has been minimized.

Copy link

H82lose commented Mar 14, 2019

@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Mar 15, 2019

Hi Patrick,
Pig Font Chip for the II+: done at #205
WOZ disk image support: no progress since last time, but watch #544
Thanks.

@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Mar 15, 2019

@6502-workshop: thanks Mark.

1.28.3.1 look great! I don't see any issues.

I'll put out an official release for this (+another fix) in ~a week's time.

tomcw added a commit that referenced this issue Mar 16, 2019

Support better RGB fro hires video (#616) (PR #630)
For the RGB hires look-up table:
- extended to include the previous video byte's high bit
- so it's now: {previous high bit + prev 2 video bits + next 2 video bits} & current byte

For all the RGB look-up tables:
- reduced from 512 to 256 lines (only 256 were being used, so it was just wasting space)

Refactored CopyMixedSource():
- fixed the Rainbow demo (#627)
- sped up in Debug config

Bumped version to 1.28.3.1.
@tomcw

This comment has been minimized.

Copy link
Contributor Author

tomcw commented Mar 16, 2019

@6502-workshop / Mark:
There's a release build here of AppleWin 1.28.4.0.

This fixes a few issues since 1.28.3.1, but doesn't change anything visually from your POV.
Let me know when you've given this a go, and then I'll close this issue.

@6502-workshop

This comment has been minimized.

Copy link

6502-workshop commented Mar 16, 2019

Thanks Tom! Everything looks great in 1.28.4.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.