(Graphics) HGR COLORs are not accurate #254

Open
Michaelangel007 opened this Issue Dec 15, 2014 · 51 comments

Comments

3 participants
@Michaelangel007
Contributor

Michaelangel007 commented Dec 15, 2014

The colors for the Hi-Resolution graphics screen are OK but could use improvement.

Running this AppleSoft Basic program on actual hardware and on AppleWin ...

10 HGR
20 FOR Y=0 TO 63:FOR X=0 TO 7
30 HCOLOR=INT(Y/8)
31 HPLOT X*32,Y*2 TO X*32+30,Y*2
32 HCOLOR=X
33 HPLOT X*32,Y*2+1 TO X*32+30,Y*2+1
40 NEXT:NEXT
50 ? "0=BLACK1  4=BLACK2"
60 ? "1=L.GREEN 5=ORANGE"
70 ? "2=PURPLE  6=MED.BLUE"
80 ? "3=WHITE1  7=WHITE2  8x8 HGR COLOR CHART";
90 GET A$:END

apple_hgr_level_correct


  • Standard

hgr_linards_tweaked_standard


  • TV

hgr_linards_tv

@Michaelangel007 Michaelangel007 self-assigned this Dec 15, 2014

@Michaelangel007 Michaelangel007 added this to the 1.26 milestone Dec 15, 2014

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 15, 2014

Contributor

With commit e64932f I tweaked the HGR colors to better match what I'm seeing on real hardware ...

Color Name Description
0 Black n/a
1 Light Green lightened up too much -- still needs tweaking, needs to be made darker
2 Violet was too dark, made slightly more vibrant
3 White1 n/a
4 Black2 n/a
5 Orange was too washed out, made darker & more pure
6 Medium Blue was too washed out, made darker & more pure
7 White2 n/a

  • Standard

hgr_michael_tweaked_standard


  • TV

hgr_michael_tweaked_tv

Contributor

Michaelangel007 commented Dec 15, 2014

With commit e64932f I tweaked the HGR colors to better match what I'm seeing on real hardware ...

Color Name Description
0 Black n/a
1 Light Green lightened up too much -- still needs tweaking, needs to be made darker
2 Violet was too dark, made slightly more vibrant
3 White1 n/a
4 Black2 n/a
5 Orange was too washed out, made darker & more pure
6 Medium Blue was too washed out, made darker & more pure
7 White2 n/a

  • Standard

hgr_michael_tweaked_standard


  • TV

hgr_michael_tweaked_tv

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 15, 2014

Contributor

I've fixed some of the bad color names that the source code mislabeled ...

  • 3d80c45 - HGR_RED -> HGR_ORANGE
  • ca26296 -> HGR_MAGENTA -> HGR_VIOLET

Contributor

Michaelangel007 commented Dec 15, 2014

I've fixed some of the bad color names that the source code mislabeled ...

  • 3d80c45 - HGR_RED -> HGR_ORANGE
  • ca26296 -> HGR_MAGENTA -> HGR_VIOLET

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 15, 2014

Contributor

We need to investigate the half pixel dim rendering option again ...

hgr_halfpixel_dim

Contributor

Michaelangel007 commented Dec 15, 2014

We need to investigate the half pixel dim rendering option again ...

hgr_halfpixel_dim

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 16, 2014

Contributor
  • Sheldon's NTSC

hgr_ntsc

The HGR medium blue looks too bright, but the rest of the colors look good.

I absolute love the rendering of this! Each pixel is has the "proper" 4 pixels blur/smear.

Contributor

Michaelangel007 commented Dec 16, 2014

  • Sheldon's NTSC

hgr_ntsc

The HGR medium blue looks too bright, but the rest of the colors look good.

I absolute love the rendering of this! Each pixel is has the "proper" 4 pixels blur/smear.

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 16, 2014

Contributor

Also see Bug #253 and https://github.com/AppleWin/AppleWin/blob/master/source/Video.cpp

Reference:

Color Name GR HGR DHGR Chroma Phase Chroma Amplitude Luma R G B
Black 0 0,4 0 0 0 0 0 0 0
Gray 5 n/a 5 0 0 50 156 156 156
Grey 10 n/a 10 0 0 50 156 156 156
White 15 3,7 15 0 0 100 255 255 255
dk Blue 2 n/a 8 0 60 25 96 78 189
lt Blue 7 n/a 13 0 60 75 208 195 255
Purple 3 2 9 45 100 50 255 68 253
dk Red 1 n/a 1 90 60 25 227 30 96
Pink 11 n/a 11 90 60 75 255 160 208
Orange 9 5 3 135 100 50 255 106 60
Brown 8 n/a 2 180 60 25 96 114 3
Yellow 13 n/a 7 180 60 75 208 221 141
lt Green 12 1 6 225 100 50 20 245 60
dk Green 4 n/a 4 270 60 25 0 163 96
Aqua 14 n/a 14 270 60 75 114 255 208
med Blue 6 6 12 315 100 50 20 207 253

Edit: Only show 1 table to prevent clutter.

Contributor

Michaelangel007 commented Dec 16, 2014

Also see Bug #253 and https://github.com/AppleWin/AppleWin/blob/master/source/Video.cpp

Reference:

Color Name GR HGR DHGR Chroma Phase Chroma Amplitude Luma R G B
Black 0 0,4 0 0 0 0 0 0 0
Gray 5 n/a 5 0 0 50 156 156 156
Grey 10 n/a 10 0 0 50 156 156 156
White 15 3,7 15 0 0 100 255 255 255
dk Blue 2 n/a 8 0 60 25 96 78 189
lt Blue 7 n/a 13 0 60 75 208 195 255
Purple 3 2 9 45 100 50 255 68 253
dk Red 1 n/a 1 90 60 25 227 30 96
Pink 11 n/a 11 90 60 75 255 160 208
Orange 9 5 3 135 100 50 255 106 60
Brown 8 n/a 2 180 60 25 96 114 3
Yellow 13 n/a 7 180 60 75 208 221 141
lt Green 12 1 6 225 100 50 20 245 60
dk Green 4 n/a 4 270 60 25 0 163 96
Aqua 14 n/a 14 270 60 75 114 255 208
med Blue 6 6 12 315 100 50 20 207 253

Edit: Only show 1 table to prevent clutter.

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 16, 2014

Contributor

For DHGR, from:

  • http://apple2.boldt.ca/?page=til/tn.aiie.003

    CALL -151 (to get into the monitor routine/program)
    C050 (This set of instructions puts the computer
    CO57 into double hi-res model.
    C05E
    C00D:0
    2000:0 (This set of instructions clears first one half
    2001<2000.3FFFM of the screen, and then the other half of
    3F8: 4C 11 C3 the screen.)
    2000<2000.3FFF^Y

    2100:11 4 (Two red dots appear on top left of
    screen)
    2102<2100.2126M (A dashed red line appears across screen)

    2150:8 22 (Two green dots appear near bottom left)
    2152<2150.2175M (Dashed green line appears across screen)

    2100<2150.2177^Y (Fills in the red line)

In contrast to conditions in standard hi-res, no half-dot shift occurs, and
the most-significant bit of each byte is not used.

Contributor

Michaelangel007 commented Dec 16, 2014

For DHGR, from:

  • http://apple2.boldt.ca/?page=til/tn.aiie.003

    CALL -151 (to get into the monitor routine/program)
    C050 (This set of instructions puts the computer
    CO57 into double hi-res model.
    C05E
    C00D:0
    2000:0 (This set of instructions clears first one half
    2001<2000.3FFFM of the screen, and then the other half of
    3F8: 4C 11 C3 the screen.)
    2000<2000.3FFF^Y

    2100:11 4 (Two red dots appear on top left of
    screen)
    2102<2100.2126M (A dashed red line appears across screen)

    2150:8 22 (Two green dots appear near bottom left)
    2152<2150.2175M (Dashed green line appears across screen)

    2100<2150.2177^Y (Fills in the red line)

In contrast to conditions in standard hi-res, no half-dot shift occurs, and
the most-significant bit of each byte is not used.

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 17, 2014

Contributor

256 Byte HGR Test Pattern - Sheldon's NTSC

hgr1

Code:

// CALL-151
// C050 C053 C057
unsigned ad;
unsigned char b = 0;
unsigned char *main, *aux;

for( unsigned page = 0; page < 2; page++ )
{
    for( unsigned w = 0; w < 2; w++ ) // 16 cols
    {
        for( unsigned z = 0; z < 2; z++ ) // 8 cols
        {
            b  = 0; // 4 columns * 64 rows
            for( unsigned x = 0; x < 4; x++ ) // 4 cols
            {
                for( unsigned y = 0; y < 64; y++ ) // 1 col
                {
                    unsigned y2 = y*2;
                    ad = 0x2000 + (y2&7)*0x400 + ((y2/8)&7)*0x80 + (y2/64)*0x28 + 2*x + 10*z + 20*w;
                    ad += 0x2000*page;
                    main = MemGetMainPtr(ad);
                    aux  = MemGetAuxPtr (ad);
                    main[0] = b; main[1] = w + page*0x80;
                    aux [0] = z; aux [1] = 0;

                    y2 = y*2 + 1;
                    ad = 0x2000 + (y2&7)*0x400 + ((y2/8)&7)*0x80 + (y2/64)*0x28 + 2*x + 10*z + 20*w;
                    ad += 0x2000*page;
                    main = MemGetMainPtr(ad);
                    aux  = MemGetAuxPtr (ad);
                    main[0] =   0; main[1] = w + page*0x80;
                    aux [0] =   b; aux [1] = 0;

                    b++;
                }
            }
        }
    }
}
Contributor

Michaelangel007 commented Dec 17, 2014

256 Byte HGR Test Pattern - Sheldon's NTSC

hgr1

Code:

// CALL-151
// C050 C053 C057
unsigned ad;
unsigned char b = 0;
unsigned char *main, *aux;

for( unsigned page = 0; page < 2; page++ )
{
    for( unsigned w = 0; w < 2; w++ ) // 16 cols
    {
        for( unsigned z = 0; z < 2; z++ ) // 8 cols
        {
            b  = 0; // 4 columns * 64 rows
            for( unsigned x = 0; x < 4; x++ ) // 4 cols
            {
                for( unsigned y = 0; y < 64; y++ ) // 1 col
                {
                    unsigned y2 = y*2;
                    ad = 0x2000 + (y2&7)*0x400 + ((y2/8)&7)*0x80 + (y2/64)*0x28 + 2*x + 10*z + 20*w;
                    ad += 0x2000*page;
                    main = MemGetMainPtr(ad);
                    aux  = MemGetAuxPtr (ad);
                    main[0] = b; main[1] = w + page*0x80;
                    aux [0] = z; aux [1] = 0;

                    y2 = y*2 + 1;
                    ad = 0x2000 + (y2&7)*0x400 + ((y2/8)&7)*0x80 + (y2/64)*0x28 + 2*x + 10*z + 20*w;
                    ad += 0x2000*page;
                    main = MemGetMainPtr(ad);
                    aux  = MemGetAuxPtr (ad);
                    main[0] =   0; main[1] = w + page*0x80;
                    aux [0] =   b; aux [1] = 0;

                    b++;
                }
            }
        }
    }
}
@sicklittlemonkey

This comment has been minimized.

Show comment
Hide comment
@sicklittlemonkey

sicklittlemonkey Dec 17, 2014

Contributor

Recently I've actually been looking into NTSC emulation and trying to
understand it more.

I actually corresponded with "Rebecca" from of the Apple II font fame:
http://www.kreativekorp.com/software/fonts/apple2.shtml
She had her own take on things after the debate on c.s.a2 about Robert
Munafo (and others') suggested RGB values:
https://docs.google.com/spreadsheets/d/1rKR6A_bVniSCtIP_rrv8QLWJdj4h6jEU1jJj0AebWwg/edit#gid=0

In a reply I linked to those people who I'd seen work of note from in this
area ...


Trevor Blackwell
http://web.mit.edu/ghudson/dev/nokrb/third/xscreensaver/hacks/analogtv.c
Note this emulates several CRT quirks. I usually find this code by googling
a comment that stuck in my head: "This is fixed-point integer DSP, son. No
place for wimps."

Blargg
http://slack.net/~ant/libs/ntsc.html
He had help from another guy whose handle was "New Rising Sun" or
something. I have a version of Blargg's code that renders Apple II video,
but some people take issue with it.

Marc Ressl
https://github.com/OpenEmulatorProject/libemulation
https://web.archive.org/web/20120320154930/http://www.openemulator.org/screenshots.html
Marc has disappeared, unfortunately. He was a very clever engineer, and his

CRT emulation is probably the best ever done. It used the GPU.

Also, this was recently in c.e.a2:
http://mosher.mine.nu/epple2/site/

Christopher has emulated all the timing oddities observed by Sather, and
based his NSTC emulation on Trevor Blackwells.

The pics on his page have the vertical stripes you prefer, which - as far
as I understand - would only happen with a very high bandwidth monitor. I
recall Michael Mahon saying that the Apple //e monitor switches to a higher
bandwidth mode in mono to allow 80-columns to look good.

Anyway, more grist for the mill.

Cheers,
Nick.

Contributor

sicklittlemonkey commented Dec 17, 2014

Recently I've actually been looking into NTSC emulation and trying to
understand it more.

I actually corresponded with "Rebecca" from of the Apple II font fame:
http://www.kreativekorp.com/software/fonts/apple2.shtml
She had her own take on things after the debate on c.s.a2 about Robert
Munafo (and others') suggested RGB values:
https://docs.google.com/spreadsheets/d/1rKR6A_bVniSCtIP_rrv8QLWJdj4h6jEU1jJj0AebWwg/edit#gid=0

In a reply I linked to those people who I'd seen work of note from in this
area ...


Trevor Blackwell
http://web.mit.edu/ghudson/dev/nokrb/third/xscreensaver/hacks/analogtv.c
Note this emulates several CRT quirks. I usually find this code by googling
a comment that stuck in my head: "This is fixed-point integer DSP, son. No
place for wimps."

Blargg
http://slack.net/~ant/libs/ntsc.html
He had help from another guy whose handle was "New Rising Sun" or
something. I have a version of Blargg's code that renders Apple II video,
but some people take issue with it.

Marc Ressl
https://github.com/OpenEmulatorProject/libemulation
https://web.archive.org/web/20120320154930/http://www.openemulator.org/screenshots.html
Marc has disappeared, unfortunately. He was a very clever engineer, and his

CRT emulation is probably the best ever done. It used the GPU.

Also, this was recently in c.e.a2:
http://mosher.mine.nu/epple2/site/

Christopher has emulated all the timing oddities observed by Sather, and
based his NSTC emulation on Trevor Blackwells.

The pics on his page have the vertical stripes you prefer, which - as far
as I understand - would only happen with a very high bandwidth monitor. I
recall Michael Mahon saying that the Apple //e monitor switches to a higher
bandwidth mode in mono to allow 80-columns to look good.

Anyway, more grist for the mill.

Cheers,
Nick.

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 17, 2014

Contributor

Awesome links Nick!

Rebecca provided RGB values? That spreadsheet looks real interesting.

The "modern" way to do this would be to use the GPU - wasn't someone doing something crazy like 21 passes?

I've seen Epple but didn't think it brought anything new to the table -- looks like I should give a try at least once.

Need to track down executables now that I have my HGR test pattern (in latest commit in Sheldon's NTSC branch) and in bug #254 :-)

Sent from my iPhone

On Dec 16, 2014, at 8:39 PM, sicklittlemonkey notifications@github.com wrote:

Recently I've actually been looking into NTSC emulation and trying to
understand it more.

I actually corresponded with "Rebecca" from of the Apple II font fame:
http://www.kreativekorp.com/software/fonts/apple2.shtml
She had her own take on things after the debate on c.s.a2 about Robert
Munafo (and others') suggested RGB values:
https://docs.google.com/spreadsheets/d/1rKR6A_bVniSCtIP_rrv8QLWJdj4h6jEU1jJj0AebWwg/edit#gid=0

In a reply I linked to those people who I'd seen work of note from in this
area ...


Trevor Blackwell
http://web.mit.edu/ghudson/dev/nokrb/third/xscreensaver/hacks/analogtv.c
Note this emulates several CRT quirks. I usually find this code by googling
a comment that stuck in my head: "This is fixed-point integer DSP, son. No
place for wimps."

Blargg
http://slack.net/~ant/libs/ntsc.html
He had help from another guy whose handle was "New Rising Sun" or
something. I have a version of Blargg's code that renders Apple II video,
but some people take issue with it.

Marc Ressl
https://github.com/OpenEmulatorProject/libemulation
https://web.archive.org/web/20120320154930/http://www.openemulator.org/screenshots.html
Marc has disappeared, unfortunately. He was a very clever engineer, and his

CRT emulation is probably the best ever done. It used the GPU.

Also, this was recently in c.e.a2:
http://mosher.mine.nu/epple2/site/

Christopher has emulated all the timing oddities observed by Sather, and
based his NSTC emulation on Trevor Blackwells.

The pics on his page have the vertical stripes you prefer, which - as far
as I understand - would only happen with a very high bandwidth monitor. I
recall Michael Mahon saying that the Apple //e monitor switches to a higher
bandwidth mode in mono to allow 80-columns to look good.

Anyway, more grist for the mill.

Cheers,
Nick.

Reply to this email directly or view it on GitHub.

Contributor

Michaelangel007 commented Dec 17, 2014

Awesome links Nick!

Rebecca provided RGB values? That spreadsheet looks real interesting.

The "modern" way to do this would be to use the GPU - wasn't someone doing something crazy like 21 passes?

I've seen Epple but didn't think it brought anything new to the table -- looks like I should give a try at least once.

Need to track down executables now that I have my HGR test pattern (in latest commit in Sheldon's NTSC branch) and in bug #254 :-)

Sent from my iPhone

On Dec 16, 2014, at 8:39 PM, sicklittlemonkey notifications@github.com wrote:

Recently I've actually been looking into NTSC emulation and trying to
understand it more.

I actually corresponded with "Rebecca" from of the Apple II font fame:
http://www.kreativekorp.com/software/fonts/apple2.shtml
She had her own take on things after the debate on c.s.a2 about Robert
Munafo (and others') suggested RGB values:
https://docs.google.com/spreadsheets/d/1rKR6A_bVniSCtIP_rrv8QLWJdj4h6jEU1jJj0AebWwg/edit#gid=0

In a reply I linked to those people who I'd seen work of note from in this
area ...


Trevor Blackwell
http://web.mit.edu/ghudson/dev/nokrb/third/xscreensaver/hacks/analogtv.c
Note this emulates several CRT quirks. I usually find this code by googling
a comment that stuck in my head: "This is fixed-point integer DSP, son. No
place for wimps."

Blargg
http://slack.net/~ant/libs/ntsc.html
He had help from another guy whose handle was "New Rising Sun" or
something. I have a version of Blargg's code that renders Apple II video,
but some people take issue with it.

Marc Ressl
https://github.com/OpenEmulatorProject/libemulation
https://web.archive.org/web/20120320154930/http://www.openemulator.org/screenshots.html
Marc has disappeared, unfortunately. He was a very clever engineer, and his

CRT emulation is probably the best ever done. It used the GPU.

Also, this was recently in c.e.a2:
http://mosher.mine.nu/epple2/site/

Christopher has emulated all the timing oddities observed by Sather, and
based his NSTC emulation on Trevor Blackwells.

The pics on his page have the vertical stripes you prefer, which - as far
as I understand - would only happen with a very high bandwidth monitor. I
recall Michael Mahon saying that the Apple //e monitor switches to a higher
bandwidth mode in mono to allow 80-columns to look good.

Anyway, more grist for the mill.

Cheers,
Nick.

Reply to this email directly or view it on GitHub.

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 17, 2014

Contributor

Removed since GitHub screwed up the formatting .. see reply below

Contributor

Michaelangel007 commented Dec 17, 2014

Removed since GitHub screwed up the formatting .. see reply below

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 17, 2014

Contributor

Removed since GitHub screwed up the formatting .. see reply below

Contributor

Michaelangel007 commented Dec 17, 2014

Removed since GitHub screwed up the formatting .. see reply below

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 17, 2014

Contributor

Looks like GitHub butchered the last 2 emails ... fixing manually ...

Contributor

Michaelangel007 commented Dec 17, 2014

Looks like GitHub butchered the last 2 emails ... fixing manually ...

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 17, 2014

Contributor

OK, this is what I'm thinking going forward ... excuse the spew of garbled stream of consciousness :-)

  1. Palette collapse cleanup

    We have redundant colors; collapse the palette down to 16 colors. It will be replaced with a single:

      uint32_t g_aApplePalette[ 32 ];
    

    Why 32? First 16 colors are color, 2nd half is for monochrome.

  2. Move the Palette to a Global Array; change output to be 32-bit RGBA.

    This palette crap needs to go. It is (almost!) 2015 and we are STILL dealing with it !?

  3. Add support for importing an external palette

    i.e. https://code.google.com/p/grafx2/issues/detail?id=518

    Because GPL (Gimp PaLette) format is used by many OSS graphics apps (GIMP, Inkscape, Scribus, GPick), it would speed up some processes to support it.

  4. Add a "Video" tab, along with at 1 buttons and 16 color square samples

     i) Import palette.

    Later we'll add 2 more buttons:

     ii) Drop-down with 4 choices

      * Tweaked colors
      * Sheldon's NTSC colors
      * IIgs colors
      * Custom color palette
    

     iii) Export palette

  5. Scan Conversion

    The "proper" way to do scanline conversion Apple Memory -> NTSC -> RGB is to do left-to right conversion keep tracking of the Chroma Phase and Luma at each 560-pixel location. 

    Above is my HGR test pattern on Sheldon's NTSC:

    If you zoom in on the black:

    hgr_test_pattern_ntsc_zoom

    You can see the pureblack screen has a "double slit interference pattern"

    You can also see the chroma shifts phase too in the pure white.

    What we are really doing is adding 16 waves together.  I'm still working the math required for the real-time conversion, but I'll probably end up using 8.8 fixed point; using 'doubles' is over-kill.

    One thing I am NOT happy with Sheldon's NTSC code is that he adds this black border around the output. This screws up taking a pure 560x384 screenshot -- it forces the user to add an additional "crop" step.

  6. Multi-core rendering ...

    We may need to re-think the "dirty cell update" ... For brute-force HGR/DHGR rendering we are doing a simple:

    i) standard 

      for( y = 0; y < 192; y++ ) // line double to output
    

    ii) TV

      for( y = 0; y < 384; y+=2 ) // merge even and odd lines, "line double"
    

    MSVC, GCC, and Clang all support OpenMP ... native compiler supported multi-threading that predates pthreads. It uses #pragma and makes it trivial to parallize code.

      #pragma omp for
       for(int n=0; n<10; ++n)
       {
         printf(" %d", n);
       }
       printf(".\n");
    

    Internally, the above loop becomes into code equivalent to this:

      int this_thread = omp_get_thread_num(), num_threads = omp_get_num_threads();
      int my_start = (this_thread  ) * 10 / num_threads;
      int my_end   = (this_thread+1) * 10 / num_threads;
      for(int n=my_start; n<my_end; ++n)
          printf(" %d", n);
    

    Conceptually I think of it this way ... every single HGR line is assigned a core.

    Getting AppleWin multi-threaded is probably a good long term goal, but at least the scanline conversion can be started (almost) today.

    Thoughts?

Contributor

Michaelangel007 commented Dec 17, 2014

OK, this is what I'm thinking going forward ... excuse the spew of garbled stream of consciousness :-)

  1. Palette collapse cleanup

    We have redundant colors; collapse the palette down to 16 colors. It will be replaced with a single:

      uint32_t g_aApplePalette[ 32 ];
    

    Why 32? First 16 colors are color, 2nd half is for monochrome.

  2. Move the Palette to a Global Array; change output to be 32-bit RGBA.

    This palette crap needs to go. It is (almost!) 2015 and we are STILL dealing with it !?

  3. Add support for importing an external palette

    i.e. https://code.google.com/p/grafx2/issues/detail?id=518

    Because GPL (Gimp PaLette) format is used by many OSS graphics apps (GIMP, Inkscape, Scribus, GPick), it would speed up some processes to support it.

  4. Add a "Video" tab, along with at 1 buttons and 16 color square samples

     i) Import palette.

    Later we'll add 2 more buttons:

     ii) Drop-down with 4 choices

      * Tweaked colors
      * Sheldon's NTSC colors
      * IIgs colors
      * Custom color palette
    

     iii) Export palette

  5. Scan Conversion

    The "proper" way to do scanline conversion Apple Memory -> NTSC -> RGB is to do left-to right conversion keep tracking of the Chroma Phase and Luma at each 560-pixel location. 

    Above is my HGR test pattern on Sheldon's NTSC:

    If you zoom in on the black:

    hgr_test_pattern_ntsc_zoom

    You can see the pureblack screen has a "double slit interference pattern"

    You can also see the chroma shifts phase too in the pure white.

    What we are really doing is adding 16 waves together.  I'm still working the math required for the real-time conversion, but I'll probably end up using 8.8 fixed point; using 'doubles' is over-kill.

    One thing I am NOT happy with Sheldon's NTSC code is that he adds this black border around the output. This screws up taking a pure 560x384 screenshot -- it forces the user to add an additional "crop" step.

  6. Multi-core rendering ...

    We may need to re-think the "dirty cell update" ... For brute-force HGR/DHGR rendering we are doing a simple:

    i) standard 

      for( y = 0; y < 192; y++ ) // line double to output
    

    ii) TV

      for( y = 0; y < 384; y+=2 ) // merge even and odd lines, "line double"
    

    MSVC, GCC, and Clang all support OpenMP ... native compiler supported multi-threading that predates pthreads. It uses #pragma and makes it trivial to parallize code.

      #pragma omp for
       for(int n=0; n<10; ++n)
       {
         printf(" %d", n);
       }
       printf(".\n");
    

    Internally, the above loop becomes into code equivalent to this:

      int this_thread = omp_get_thread_num(), num_threads = omp_get_num_threads();
      int my_start = (this_thread  ) * 10 / num_threads;
      int my_end   = (this_thread+1) * 10 / num_threads;
      for(int n=my_start; n<my_end; ++n)
          printf(" %d", n);
    

    Conceptually I think of it this way ... every single HGR line is assigned a core.

    Getting AppleWin multi-threaded is probably a good long term goal, but at least the scanline conversion can be started (almost) today.

    Thoughts?

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 17, 2014

Contributor

It looks like Rebecca's values are not gamma corrected which would explain the discrepancy.

i.e.

Bit Pattern x x
ApplePC Gray
COLOR= 5
Y 0.5
I (Naïve) 0
Q (Naïve) 0
I (Actual) 0
Q (Actual) 0
R (0-1) +0.5
G (0-1) +0.5
B (0-1) +0.5
R (0-255) 128
G (0-255) 128
B (0-255) 128
RGB (Hex) 808080
Calculated Gray

hgr_bit_pattern_grey

However this is fantastic she has derived all the values along the way!
Michael

Contributor

Michaelangel007 commented Dec 17, 2014

It looks like Rebecca's values are not gamma corrected which would explain the discrepancy.

i.e.

Bit Pattern x x
ApplePC Gray
COLOR= 5
Y 0.5
I (Naïve) 0
Q (Naïve) 0
I (Actual) 0
Q (Actual) 0
R (0-1) +0.5
G (0-1) +0.5
B (0-1) +0.5
R (0-255) 128
G (0-255) 128
B (0-255) 128
RGB (Hex) 808080
Calculated Gray

hgr_bit_pattern_grey

However this is fantastic she has derived all the values along the way!
Michael

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 17, 2014

Contributor

@sicklittlemonkey Ha! That "This is fixed-point integer DSP, son. No place for wimps." comment is priceless !

Contributor

Michaelangel007 commented Dec 17, 2014

@sicklittlemonkey Ha! That "This is fixed-point integer DSP, son. No place for wimps." comment is priceless !

@sicklittlemonkey

This comment has been minimized.

Show comment
Hide comment
@sicklittlemonkey

sicklittlemonkey Dec 17, 2014

Contributor

Yes, it's easy to find that code, as I never forget that comment. ; - )

I have some other links I'll post when I get home.

Off the top of my head, if you google for "video demystified" you'll find a
PDF link to the 3rd or 4th edition of that book to download. Or buy it if
you prefer. It has sections on encoding/decoding NTSC - just useful
background for those of us (like me) who aren't engineers, never studied
DSP, QAM, FIRs etc! Wimps, basically.

There's also another book that Marc referenced ...

Apart from Marc's work, there are a bunch of GPU shaders around, eg:
https://github.com/libretro/common-shaders/tree/master/ntsc

Cheers,
Nick.

Contributor

sicklittlemonkey commented Dec 17, 2014

Yes, it's easy to find that code, as I never forget that comment. ; - )

I have some other links I'll post when I get home.

Off the top of my head, if you google for "video demystified" you'll find a
PDF link to the 3rd or 4th edition of that book to download. Or buy it if
you prefer. It has sections on encoding/decoding NTSC - just useful
background for those of us (like me) who aren't engineers, never studied
DSP, QAM, FIRs etc! Wimps, basically.

There's also another book that Marc referenced ...

Apart from Marc's work, there are a bunch of GPU shaders around, eg:
https://github.com/libretro/common-shaders/tree/master/ntsc

Cheers,
Nick.

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 18, 2014

Contributor

Awesome links Nick!

I managed to snag a complete .pdf copy of "Video Demystified" -- looks like a great reference! It doesn't have optimized color space conversion but I can find shaders do that if needed. This is going to be a FUN read!

Those shaders are a gold mine! The author, Themaister, has a great license too: Public domain!

I've written a GLSL-to-CPP stub that allows you to compile GL shader code to C++ :-) While those shaders are HLSL/Cg they are quite readable so I might be "converting" them over to OpenGL/WebGL. I haven't used that automatic convert - cg2glsl - so that would be an option to.

Keep those links coming!

Contributor

Michaelangel007 commented Dec 18, 2014

Awesome links Nick!

I managed to snag a complete .pdf copy of "Video Demystified" -- looks like a great reference! It doesn't have optimized color space conversion but I can find shaders do that if needed. This is going to be a FUN read!

Those shaders are a gold mine! The author, Themaister, has a great license too: Public domain!

I've written a GLSL-to-CPP stub that allows you to compile GL shader code to C++ :-) While those shaders are HLSL/Cg they are quite readable so I might be "converting" them over to OpenGL/WebGL. I haven't used that automatic convert - cg2glsl - so that would be an option to.

Keep those links coming!

@sicklittlemonkey

This comment has been minimized.

Show comment
Hide comment
@sicklittlemonkey

sicklittlemonkey Dec 18, 2014

Contributor

More semi-random notes and links ...

About Marc Ressl's
From http://www.digitalfaq.com/forum/video-restore/2944-ntsc-pal-video.html
"Regarding the filter: It's a simple Lanczos lowpass filter with variable
cutoff.
I also multiply this filter with a Chebyshev window, so that the stopband
is consistently below a certain level (I use 50 dB, which corresponds to
the SNR of a typical eye)."
His source links to:
Computing Chebyshev Window Sequences
http://www.dsprelated.com/showarticle/42.php
His source also refers to:
Poynton C., Digital Video and HDTV Algorithms and Interfaces

This guy did a decoder and also added better NSTC decoding for MESS. Source
is crtsim.zip and crtc6845.zip
http://www.reenigne.org/blog/ntsc-hacking/
http://www.reenigne.org/blog/crtc-emulation-for-mess/

This guy decodes a real signal with a scope and RPi. Source included.
http://codeandlife.com/2012/10/09/composite-video-decoding-theory-and-practice/
And here's where he got advice on a forum:
http://www.edaboard.com/thread263318.html

This guy also did it for a real signal. No details but says everything
needed is described in "Video Demystified"
"most of what you'd need is in the Video Demystified book. Note that chroma
decoding requires only a digital PLL and a mixer -- no FFT is required.
"All you really need to do, in the software domain, is fit a sine wave to
the color burst. You can use a least-mean-square technique for this"
https://www.physicsforums.com/threads/software-ntsc-decoding.47403/

These real signal decoders have extra complexity we don't face, like
finding the actual color burst etc.

Contributor

sicklittlemonkey commented Dec 18, 2014

More semi-random notes and links ...

About Marc Ressl's
From http://www.digitalfaq.com/forum/video-restore/2944-ntsc-pal-video.html
"Regarding the filter: It's a simple Lanczos lowpass filter with variable
cutoff.
I also multiply this filter with a Chebyshev window, so that the stopband
is consistently below a certain level (I use 50 dB, which corresponds to
the SNR of a typical eye)."
His source links to:
Computing Chebyshev Window Sequences
http://www.dsprelated.com/showarticle/42.php
His source also refers to:
Poynton C., Digital Video and HDTV Algorithms and Interfaces

This guy did a decoder and also added better NSTC decoding for MESS. Source
is crtsim.zip and crtc6845.zip
http://www.reenigne.org/blog/ntsc-hacking/
http://www.reenigne.org/blog/crtc-emulation-for-mess/

This guy decodes a real signal with a scope and RPi. Source included.
http://codeandlife.com/2012/10/09/composite-video-decoding-theory-and-practice/
And here's where he got advice on a forum:
http://www.edaboard.com/thread263318.html

This guy also did it for a real signal. No details but says everything
needed is described in "Video Demystified"
"most of what you'd need is in the Video Demystified book. Note that chroma
decoding requires only a digital PLL and a mixer -- no FFT is required.
"All you really need to do, in the software domain, is fit a sine wave to
the color burst. You can use a least-mean-square technique for this"
https://www.physicsforums.com/threads/software-ntsc-decoding.47403/

These real signal decoders have extra complexity we don't face, like
finding the actual color burst etc.

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 18, 2014

Contributor

More great links Nick; Thanks!

Ah I had been wondering if a FFT was required. Fitting a sine wave to color burst makes sense.

On Dec 18, 2014, at 12:24 AM, sicklittlemonkey notifications@github.com wrote:

More semi-random notes and links ...

About Marc Ressl's
From http://www.digitalfaq.com/forum/video-restore/2944-ntsc-pal-video.html
"Regarding the filter: It's a simple Lanczos lowpass filter with variable
cutoff.
I also multiply this filter with a Chebyshev window, so that the stopband
is consistently below a certain level (I use 50 dB, which corresponds to
the SNR of a typical eye)."
His source links to:
Computing Chebyshev Window Sequences
http://www.dsprelated.com/showarticle/42.php
His source also refers to:
Poynton C., Digital Video and HDTV Algorithms and Interfaces

This guy did a decoder and also added better NSTC decoding for MESS. Source
is crtsim.zip and crtc6845.zip
http://www.reenigne.org/blog/ntsc-hacking/
http://www.reenigne.org/blog/crtc-emulation-for-mess/

This guy decodes a real signal with a scope and RPi. Source included.
http://codeandlife.com/2012/10/09/composite-video-decoding-theory-and-practice/
And here's where he got advice on a forum:
http://www.edaboard.com/thread263318.html

This guy also did it for a real signal. No details but says everything
needed is described in "Video Demystified"
"most of what you'd need is in the Video Demystified book. Note that chroma
decoding requires only a digital PLL and a mixer -- no FFT is required.
"All you really need to do, in the software domain, is fit a sine wave to
the color burst. You can use a least-mean-square technique for this"
https://www.physicsforums.com/threads/software-ntsc-decoding.47403/

These real signal decoders have extra complexity we don't face, like
finding the actual color burst etc.

Reply to this email directly or view it on GitHub.

Contributor

Michaelangel007 commented Dec 18, 2014

More great links Nick; Thanks!

Ah I had been wondering if a FFT was required. Fitting a sine wave to color burst makes sense.

On Dec 18, 2014, at 12:24 AM, sicklittlemonkey notifications@github.com wrote:

More semi-random notes and links ...

About Marc Ressl's
From http://www.digitalfaq.com/forum/video-restore/2944-ntsc-pal-video.html
"Regarding the filter: It's a simple Lanczos lowpass filter with variable
cutoff.
I also multiply this filter with a Chebyshev window, so that the stopband
is consistently below a certain level (I use 50 dB, which corresponds to
the SNR of a typical eye)."
His source links to:
Computing Chebyshev Window Sequences
http://www.dsprelated.com/showarticle/42.php
His source also refers to:
Poynton C., Digital Video and HDTV Algorithms and Interfaces

This guy did a decoder and also added better NSTC decoding for MESS. Source
is crtsim.zip and crtc6845.zip
http://www.reenigne.org/blog/ntsc-hacking/
http://www.reenigne.org/blog/crtc-emulation-for-mess/

This guy decodes a real signal with a scope and RPi. Source included.
http://codeandlife.com/2012/10/09/composite-video-decoding-theory-and-practice/
And here's where he got advice on a forum:
http://www.edaboard.com/thread263318.html

This guy also did it for a real signal. No details but says everything
needed is described in "Video Demystified"
"most of what you'd need is in the Video Demystified book. Note that chroma
decoding requires only a digital PLL and a mixer -- no FFT is required.
"All you really need to do, in the software domain, is fit a sine wave to
the color burst. You can use a least-mean-square technique for this"
https://www.physicsforums.com/threads/software-ntsc-decoding.47403/

These real signal decoders have extra complexity we don't face, like
finding the actual color burst etc.

Reply to this email directly or view it on GitHub.

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 18, 2014

Contributor

I restored/fixed Sheldon's alt. NTSC rendering; here are screenshots, hgr memory dumps, and pre-built binaries for you guys to play with: :-)

http://michael.peopleofhonoronly.com/dev/applewin/ntsc/

Top Left: Original NTSC
Top Right: Alt. Chroma: as-is
Bot Left: Alt Chroma: soft
Bot Right: Alt. Chroma smooth, using original chroma filtering

Contributor

Michaelangel007 commented Dec 18, 2014

I restored/fixed Sheldon's alt. NTSC rendering; here are screenshots, hgr memory dumps, and pre-built binaries for you guys to play with: :-)

http://michael.peopleofhonoronly.com/dev/applewin/ntsc/

Top Left: Original NTSC
Top Right: Alt. Chroma: as-is
Bot Left: Alt Chroma: soft
Bot Right: Alt. Chroma smooth, using original chroma filtering

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 18, 2014

Contributor

Here are the additional problems with Sheldon's rendering ...

  • Hard-codes the I,Q values - use can't provide their own palette

    This really sucks for those wanting to tweak the colors. While we currently do a poor job of this, at least you can (re)compile to get new colors.

  • While mathematically the colors "should" be correct, some of them look off.

    NOTE: The following commentary is based on GR colors, on Sheldon's stock colors whilst comparing to actual hardware. (Almost getting whiplash from all the comparisons. :-)

    Commentary on Color Monitor mode:

    Value Description Comment
    1 Red It looks violet but should be a deeper red
    3 Purple Has correct hue but brightness looks like it could be tab brighter
    6 Med.Blue Looks almost cyan!? This is WAY off in hue and brightness. Color should be deeper blue.
    11 Pink Has right hue, but alternating vertical lines of white looks bad
    15 White Has too much ringing.

    Commentary on the TV mode:

    Value Description Comment
    1 Red same problem in Monitor mode
    2 Deep Blue Very happy with this one
    3 Purple Looks way better but brightness is still off
    7 Light Blue Very happy with this one
    11 Pink Looks way better but hue & brightness are still a little off
    12 Light Green Perfect hue, brightness too high
    14 Aqua Perfect
    15 White Has WAY too much ringing.

    I've been playing around with the phi phase offsets. In Sheldon's branch are now 4 release binaries:

    • NTSC (CHROMA_BLUR=1)
    • chroma_sharp.exe (CHROMA_FILTER=0)
    • chroma_soft (CHROMA_FILTER=1)
    • chroma_smooth (CHROMA_FILTER=2)

    Using chroma_soft I found the perfect red that accurate matches the Color Monitor.

  • Grrr, he disabled the F11, and F12 hotkeys to save/load the emulator states. However, you CAN still use the configuration dialog to save/load them though ... :-) I've provided a hgr_colors.aws for both GR and HGR colors ... use the usual soft-switches C056 C057
  • The framebuffer has been resized from 560x384 to 600x420. While this provide a nice black border:
    • it destroys the aspect ratio
    • forces users to manually crop their images

@sicklittlemonkey Can you dig up the code for the lamba reference pattern? I'm talking about this image ... http://michael.peopleofhonoronly.com/dev/applewin/nightlybuild/colorhalfpixel/real_lambda_zoom.jpg

Contributor

Michaelangel007 commented Dec 18, 2014

Here are the additional problems with Sheldon's rendering ...

  • Hard-codes the I,Q values - use can't provide their own palette

    This really sucks for those wanting to tweak the colors. While we currently do a poor job of this, at least you can (re)compile to get new colors.

  • While mathematically the colors "should" be correct, some of them look off.

    NOTE: The following commentary is based on GR colors, on Sheldon's stock colors whilst comparing to actual hardware. (Almost getting whiplash from all the comparisons. :-)

    Commentary on Color Monitor mode:

    Value Description Comment
    1 Red It looks violet but should be a deeper red
    3 Purple Has correct hue but brightness looks like it could be tab brighter
    6 Med.Blue Looks almost cyan!? This is WAY off in hue and brightness. Color should be deeper blue.
    11 Pink Has right hue, but alternating vertical lines of white looks bad
    15 White Has too much ringing.

    Commentary on the TV mode:

    Value Description Comment
    1 Red same problem in Monitor mode
    2 Deep Blue Very happy with this one
    3 Purple Looks way better but brightness is still off
    7 Light Blue Very happy with this one
    11 Pink Looks way better but hue & brightness are still a little off
    12 Light Green Perfect hue, brightness too high
    14 Aqua Perfect
    15 White Has WAY too much ringing.

    I've been playing around with the phi phase offsets. In Sheldon's branch are now 4 release binaries:

    • NTSC (CHROMA_BLUR=1)
    • chroma_sharp.exe (CHROMA_FILTER=0)
    • chroma_soft (CHROMA_FILTER=1)
    • chroma_smooth (CHROMA_FILTER=2)

    Using chroma_soft I found the perfect red that accurate matches the Color Monitor.

  • Grrr, he disabled the F11, and F12 hotkeys to save/load the emulator states. However, you CAN still use the configuration dialog to save/load them though ... :-) I've provided a hgr_colors.aws for both GR and HGR colors ... use the usual soft-switches C056 C057
  • The framebuffer has been resized from 560x384 to 600x420. While this provide a nice black border:
    • it destroys the aspect ratio
    • forces users to manually crop their images

@sicklittlemonkey Can you dig up the code for the lamba reference pattern? I'm talking about this image ... http://michael.peopleofhonoronly.com/dev/applewin/nightlybuild/colorhalfpixel/real_lambda_zoom.jpg

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 18, 2014

Contributor
  • Regarding the white ringing .. .this test patterns demonstrate it in spades

    • Archon

    Legend:

      Top Left: Original NTSC
      Top Right: Alt. Chroma: as-is (looks like garbage)
      Bot Left: Alt Chroma: soft
      Bot Right: Alt. Chroma smooth, using original chroma filtering (looks like garbage)
    

4ntsc_archon_orgtl_sharptr_softbl_smoothbr

This the corresponding code in wsvideo.cpp filterloop()

#if CHROMA_BLUR
    #define CYCLESTART (PI/4.0) // PI/4 = 45 degrees
#else // sharpness is higher, less color bleed
    #if CHROMA_FILTER == 2
        #define CYCLESTART (PI/4.0) // PI/4 = 45 degrees // c = signal_prefilter(z);
    #else
        #define CYCLESTART DEG_TO_RAD(115) // GR perfect match of slow method
    #endif
#endif


            for(int k = 0; k < 2; k++ )
            {
    #if CHROMA_BLUR
                //z = z * 1.25;
                zz = signal_prefilter(z);
                c = chroma_filter(zz); // "Mostly" correct _if_ CYCLESTART = PI/4 = 45 degrees
                y0 = luma0_filter(zz);
                y1 = luma1_filter(zz - c);
    #else // CHROMA_BLUR
                y0 = y0 + (z - y0) / 4.0;
                y1 = y0; // fix TV mode

#if CHROMA_FILTER == 0
                c = z; // sharper; "Mostly" correct _if_ CYCLESTART = 115 degrees
#endif // CHROMA_FILTER
#if CHROMA_FILTER == 1 // soft chroma blur, strong color fringes
                // NOTE: This has incorrect colors! Chroma is (115-45)=70 degrees out of phase! violet <-> orange, green <-> blue
                c = (z - y0); // Original -- smoother, white is solid, brighter; other colors
                //   ->
                // c = (z - (y0 + (z-y0)/4))
                // c = z - y0 - (z-y0)/4
                // c = z - y0 - z/4 + y0/4
                // c = z-z/4 - y0+y0/4; // Which is clearly wrong, unless CYCLESTART DEG_TO_RAD(115)
                // This mode looks the most accurate for white, has better color fringes
#endif
#if CHROMA_FILTER == 2 // more blur, muted chroma fringe
                // White has too much ringing, and the color fringes are muted
                c = signal_prefilter(z); // "Mostly" correct _if_ CYCLESTART = PI/4 = 45 degrees
#endif

#endif // CHROMA_BLUR

Contributor

Michaelangel007 commented Dec 18, 2014

  • Regarding the white ringing .. .this test patterns demonstrate it in spades

    • Archon

    Legend:

      Top Left: Original NTSC
      Top Right: Alt. Chroma: as-is (looks like garbage)
      Bot Left: Alt Chroma: soft
      Bot Right: Alt. Chroma smooth, using original chroma filtering (looks like garbage)
    

4ntsc_archon_orgtl_sharptr_softbl_smoothbr

This the corresponding code in wsvideo.cpp filterloop()

#if CHROMA_BLUR
    #define CYCLESTART (PI/4.0) // PI/4 = 45 degrees
#else // sharpness is higher, less color bleed
    #if CHROMA_FILTER == 2
        #define CYCLESTART (PI/4.0) // PI/4 = 45 degrees // c = signal_prefilter(z);
    #else
        #define CYCLESTART DEG_TO_RAD(115) // GR perfect match of slow method
    #endif
#endif


            for(int k = 0; k < 2; k++ )
            {
    #if CHROMA_BLUR
                //z = z * 1.25;
                zz = signal_prefilter(z);
                c = chroma_filter(zz); // "Mostly" correct _if_ CYCLESTART = PI/4 = 45 degrees
                y0 = luma0_filter(zz);
                y1 = luma1_filter(zz - c);
    #else // CHROMA_BLUR
                y0 = y0 + (z - y0) / 4.0;
                y1 = y0; // fix TV mode

#if CHROMA_FILTER == 0
                c = z; // sharper; "Mostly" correct _if_ CYCLESTART = 115 degrees
#endif // CHROMA_FILTER
#if CHROMA_FILTER == 1 // soft chroma blur, strong color fringes
                // NOTE: This has incorrect colors! Chroma is (115-45)=70 degrees out of phase! violet <-> orange, green <-> blue
                c = (z - y0); // Original -- smoother, white is solid, brighter; other colors
                //   ->
                // c = (z - (y0 + (z-y0)/4))
                // c = z - y0 - (z-y0)/4
                // c = z - y0 - z/4 + y0/4
                // c = z-z/4 - y0+y0/4; // Which is clearly wrong, unless CYCLESTART DEG_TO_RAD(115)
                // This mode looks the most accurate for white, has better color fringes
#endif
#if CHROMA_FILTER == 2 // more blur, muted chroma fringe
                // White has too much ringing, and the color fringes are muted
                c = signal_prefilter(z); // "Mostly" correct _if_ CYCLESTART = PI/4 = 45 degrees
#endif

#endif // CHROMA_BLUR

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 18, 2014

Contributor

OK, Nick I think I am close to understanding this at a high level ...

  1. Allow user to customize the 16 colors
  2. Convert the RGB colors to YIV and save in g_aYIVpalette[ 16 ]
  3. For each scan line
    • keep a rolling YIV window
    • as we move along the scan line, peel off the a 4-bit packed YIV
    • Use the userYIV look up table to adjust/tweak/offset the YIV
    • Convert YIV to RGB
    • output RGB to framebuffer

If we didn't want to provide the user with the ability to customize the palette this whole thing would be much simpler ... :)

Contributor

Michaelangel007 commented Dec 18, 2014

OK, Nick I think I am close to understanding this at a high level ...

  1. Allow user to customize the 16 colors
  2. Convert the RGB colors to YIV and save in g_aYIVpalette[ 16 ]
  3. For each scan line
    • keep a rolling YIV window
    • as we move along the scan line, peel off the a 4-bit packed YIV
    • Use the userYIV look up table to adjust/tweak/offset the YIV
    • Convert YIV to RGB
    • output RGB to framebuffer

If we didn't want to provide the user with the ability to customize the palette this whole thing would be much simpler ... :)

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 19, 2014

Contributor

I picked up a copy of Archon off eBay ... waiting for it to ship/arrive, but will post a picture of that on the color monitor when it arrives.

Also waiting for ADTPro and Serial cables to get here that I ordered from: http://retrofloppy.com/products.html

Expect many more pictures of games on actual hardware next year now that I actually have a working DOS again. :-)

Contributor

Michaelangel007 commented Dec 19, 2014

I picked up a copy of Archon off eBay ... waiting for it to ship/arrive, but will post a picture of that on the color monitor when it arrives.

Also waiting for ADTPro and Serial cables to get here that I ordered from: http://retrofloppy.com/products.html

Expect many more pictures of games on actual hardware next year now that I actually have a working DOS again. :-)

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 19, 2014

Contributor

Hmm, maybe the HGR blue is supposed to be this bright ...

http://i.ebayimg.com/00/s/MTIzMlgxNjAw/z/TFQAAOSwofxUgy7W/$_57.JPG

_57

Contributor

Michaelangel007 commented Dec 19, 2014

Hmm, maybe the HGR blue is supposed to be this bright ...

http://i.ebayimg.com/00/s/MTIzMlgxNjAw/z/TFQAAOSwofxUgy7W/$_57.JPG

_57

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 22, 2014

Contributor

First pass Applesoft program

10 HGR:HCOLOR=0:B=0
20 FOR X=0 TO 3:FOR Y=0 TO 63
30 D=0:GOSUB 80
40 POKE P,B:POKE P+1,0
50 D=1:GOSUB 80
60 POKE P,0: POKE P+1,0
70 B=B+1:NEXT:NEXT:END
80 HPLOT X*14,Y*2+D
90 A=PEEK(38)+256*PEEK(39):P=A+2*X:RETURN
Contributor

Michaelangel007 commented Dec 22, 2014

First pass Applesoft program

10 HGR:HCOLOR=0:B=0
20 FOR X=0 TO 3:FOR Y=0 TO 63
30 D=0:GOSUB 80
40 POKE P,B:POKE P+1,0
50 D=1:GOSUB 80
60 POKE P,0: POKE P+1,0
70 B=B+1:NEXT:NEXT:END
80 HPLOT X*14,Y*2+D
90 A=PEEK(38)+256*PEEK(39):P=A+2*X:RETURN
@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 22, 2014

Contributor

2nd pass Applesoft Program Make HGR Test Pattern

  • Even Bytes

  • Odd Bytes

  • 7F White Even and Odd

  • FF White Even and Odd

    10 HGR:HCOLOR=0:B=0
    20 FOR X=0 TO 3:FOR Y=0 TO 63
    30 D=0:GOSUB 80
    40 D=1:GOSUB 80
    50 B=B+1:NEXT:NEXT
    70 FOR I=0 TO 7:HCOLOR=I:HPLOT 0,132+I*2 TO 28,132+I*2:NEXT:END
    80 HPLOT X*14,Y*2+D:A=PEEK(38)+256*PEEK(39):P=A+X*2
    90 POKE P,B*(1-D):POKE P+1,0:
       POKE P+9,B*(1-D):POKE P+10,0:
       POKE A+18,127:POKE A+20,255:
       POKE A+23,127:POKE A+25,255
    99 RETURN
    
Contributor

Michaelangel007 commented Dec 22, 2014

2nd pass Applesoft Program Make HGR Test Pattern

  • Even Bytes

  • Odd Bytes

  • 7F White Even and Odd

  • FF White Even and Odd

    10 HGR:HCOLOR=0:B=0
    20 FOR X=0 TO 3:FOR Y=0 TO 63
    30 D=0:GOSUB 80
    40 D=1:GOSUB 80
    50 B=B+1:NEXT:NEXT
    70 FOR I=0 TO 7:HCOLOR=I:HPLOT 0,132+I*2 TO 28,132+I*2:NEXT:END
    80 HPLOT X*14,Y*2+D:A=PEEK(38)+256*PEEK(39):P=A+X*2
    90 POKE P,B*(1-D):POKE P+1,0:
       POKE P+9,B*(1-D):POKE P+10,0:
       POKE A+18,127:POKE A+20,255:
       POKE A+23,127:POKE A+25,255
    99 RETURN
    
@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
Contributor

Michaelangel007 commented Dec 22, 2014

hgr_test_pattern_img_2298

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 22, 2014

Contributor

This is what I'm seeing on my 1st color monitor ...

  • a) 4th column; blue pixels on right hand side
      1. 1/2 blue pixel
      1. bright blue + 1/2 blue pixel
      1. orange + 1/2 purple (!) pixel
      1. white + 1/2 purple (!) pixel
  • b) 8th column; orange pixels on right hand side
      1. 1/4 brown pixel
      1. orange + 1/4 brown pixel
      1. blue + 1/4 green-brown pixel
      1. white + 1/4 green-brown pixel
  • c) color fringes in white bars
      1. purple fringe leading edge; purplish white; pink fringe trailing edge
      1. blue fringe leading edge; white; pink fringe trailing edge
      1. green fringe leading edge; greenish white; pale light green trailing edge
      1. brown leading edge; brownish white; pale light green trailing edge
Contributor

Michaelangel007 commented Dec 22, 2014

This is what I'm seeing on my 1st color monitor ...

  • a) 4th column; blue pixels on right hand side
      1. 1/2 blue pixel
      1. bright blue + 1/2 blue pixel
      1. orange + 1/2 purple (!) pixel
      1. white + 1/2 purple (!) pixel
  • b) 8th column; orange pixels on right hand side
      1. 1/4 brown pixel
      1. orange + 1/4 brown pixel
      1. blue + 1/4 green-brown pixel
      1. white + 1/4 green-brown pixel
  • c) color fringes in white bars
      1. purple fringe leading edge; purplish white; pink fringe trailing edge
      1. blue fringe leading edge; white; pink fringe trailing edge
      1. green fringe leading edge; greenish white; pale light green trailing edge
      1. brown leading edge; brownish white; pale light green trailing edge
@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 22, 2014

Contributor

Archon on real hardware

archon_img_2316

  • Zoom on white color fringes

archon_zoom_img_2322

Contributor

Michaelangel007 commented Dec 22, 2014

Archon on real hardware

archon_img_2316

  • Zoom on white color fringes

archon_zoom_img_2322

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 28, 2014

Contributor

The new renderer must pass Jim Sather's video test: (cleaned up shoddy Applesoft line numbers & variable name)

CALL -151
1F00:AC 54 C0 A0 27 20 27 1F
1F08:AC 10 C0 AC 00 C0 30 F3
1F10:69 01 29 01 AA BC 56 C0
1F18:A2 08 20 31 1F A0 31 20
1F20:27 1F 18 90 E6 D0 01 88
1F28:88 EA D0 F9 60 48 68 EA
1F30:EA A0 62 20 27 1F EA CA
1F38:D0 F3 60
E000G

10 HGR : HOME : VTAB 21 : PRINT "1  7  D  2  8  E  B  4  5  A 3 6 C 9 F 8"
20 DIM C(39), X(21)
30 FOR A = 0 TO 39 : READ C(A) : COLOR = C(A) : VLIN 0, 39 AT A : NEXT A
40 FOR A = 0 TO 21 : READ C(A) : READ X(A) : HCOLOR = C(A)
50 HPLOT X(A), 0 TO X(A), 159 : NEXT A
60 FOR A = 8319 TO 16383 STEP 128 : POKE A, 64 : NEXT A
70 CALL 7936
80 REM  LORES DATA
81 DATA 1,0,7,7,0,13,13,0,2,2,0,8,8,0,14,14,0,11,11,0
82 DATA 4,4,0,0,5,0,0,10,0,3,0,6,0,12,0,9,0,15,0,8
90 REM  HIRES DATA
91 DATA 4,0,3,20,4,21,3,41,4,42,7,62,7,83,7,104,3,105,7,125,3,126,7,159,3,161
92 DATA 7,180,3,182,3,206,7,220,3,233,7,247,3,262,3,263,7,279

RUN
Contributor

Michaelangel007 commented Dec 28, 2014

The new renderer must pass Jim Sather's video test: (cleaned up shoddy Applesoft line numbers & variable name)

CALL -151
1F00:AC 54 C0 A0 27 20 27 1F
1F08:AC 10 C0 AC 00 C0 30 F3
1F10:69 01 29 01 AA BC 56 C0
1F18:A2 08 20 31 1F A0 31 20
1F20:27 1F 18 90 E6 D0 01 88
1F28:88 EA D0 F9 60 48 68 EA
1F30:EA A0 62 20 27 1F EA CA
1F38:D0 F3 60
E000G

10 HGR : HOME : VTAB 21 : PRINT "1  7  D  2  8  E  B  4  5  A 3 6 C 9 F 8"
20 DIM C(39), X(21)
30 FOR A = 0 TO 39 : READ C(A) : COLOR = C(A) : VLIN 0, 39 AT A : NEXT A
40 FOR A = 0 TO 21 : READ C(A) : READ X(A) : HCOLOR = C(A)
50 HPLOT X(A), 0 TO X(A), 159 : NEXT A
60 FOR A = 8319 TO 16383 STEP 128 : POKE A, 64 : NEXT A
70 CALL 7936
80 REM  LORES DATA
81 DATA 1,0,7,7,0,13,13,0,2,2,0,8,8,0,14,14,0,11,11,0
82 DATA 4,4,0,0,5,0,0,10,0,3,0,6,0,12,0,9,0,15,0,8
90 REM  HIRES DATA
91 DATA 4,0,3,20,4,21,3,41,4,42,7,62,7,83,7,104,3,105,7,125,3,126,7,159,3,161
92 DATA 7,180,3,182,3,206,7,220,3,233,7,247,3,262,3,263,7,279

RUN
@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 29, 2014

Contributor

From a sister project hgr2rgbntsc

alt text

Will post comments about the problems with this image later.

Contributor

Michaelangel007 commented Dec 29, 2014

From a sister project hgr2rgbntsc

alt text

Will post comments about the problems with this image later.

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 29, 2014

Contributor

Problems with Sheldon's NTSC init_chroma_phase_table()

  1. The EA logo, [ ]O/, in the top right should have orange fringes on the leading edge on the left of the square.

  2. In the black dragon on the right there are "ghosting" in the post trailing edge. This is a bigger problem of "white ringing" -- you can see this with the alt. rendering

    #define CHROMA_BLUR 0
    #define CHROMA_FILTER 1
    
  3. The color fringes are weak.

  4. There are no green color fridges on the right edge.

Contributor

Michaelangel007 commented Dec 29, 2014

Problems with Sheldon's NTSC init_chroma_phase_table()

  1. The EA logo, [ ]O/, in the top right should have orange fringes on the leading edge on the left of the square.

  2. In the black dragon on the right there are "ghosting" in the post trailing edge. This is a bigger problem of "white ringing" -- you can see this with the alt. rendering

    #define CHROMA_BLUR 0
    #define CHROMA_FILTER 1
    
  3. The color fringes are weak.

  4. There are no green color fridges on the right edge.

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Dec 29, 2014

Contributor

Zoomed top right

archon_zoom

Contributor

Michaelangel007 commented Dec 29, 2014

Zoomed top right

archon_zoom

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Jan 3, 2015

Contributor

Rainbow Reference
https://groups.google.com/forum/m/#!topic/comp.sys.apple2.programmer/C70j36jSKvQ

10 A = 9200 :B = 13168:C=100:X=279
20 TEXT : HOME :GOTO 40
30 HPLOT 0,Y TO X,Y:RETURN
40 DATA 173,87,192,173,83,192,173,84,192,173,80,192
50 DATA 208,251,173,86,192,160,22,136,208,253,234,173,87,192,76,9,3
60 FOR I = 768 TO 796:READ N:POKE I,N:NEXT
70 HGR : POKE  - 16302,0 
80 HCOLOR= 4:HPLOT 0,0: CALL 62454 
90 HCOLOR= 2:Y=63:GOSUB 30:Y=62:GOSUB 30
100 HCOLOR= 6:Y=61:GOSUB 30:Y=60:GOSUB 30
110 HCOLOR= 1:Y=59:GOSUB 30:Y=58:GOSUB 30
120 HCOLOR= 5:Y=55:GOSUB 30:Y=54:GOSUB 30
130 HCOLOR= 0:X=C
140 Y=123:GOSUB 30:Y=122:GOSUB 30
150 Y=119:GOSUB 30:Y=118:GOSUB 30
160 COLOR= 0:FOR I = 0 TO 39:VLIN 0,39 AT I:NEXT 
170 COLOR= 13:HLIN 0,39 AT 14 
180 FOR I = 0 TO 7:POKE A + I,0:POKE B + I,0:NEXT
190 COLOR= 1:HLIN 0,39 AT 13 
200 VTAB 21:? TAB( 16)"RAINBOW"
210 ?:? "MIXED GRAPHICS (HI-RES/COLOR)" 
220 CALL 768
Contributor

Michaelangel007 commented Jan 3, 2015

Rainbow Reference
https://groups.google.com/forum/m/#!topic/comp.sys.apple2.programmer/C70j36jSKvQ

10 A = 9200 :B = 13168:C=100:X=279
20 TEXT : HOME :GOTO 40
30 HPLOT 0,Y TO X,Y:RETURN
40 DATA 173,87,192,173,83,192,173,84,192,173,80,192
50 DATA 208,251,173,86,192,160,22,136,208,253,234,173,87,192,76,9,3
60 FOR I = 768 TO 796:READ N:POKE I,N:NEXT
70 HGR : POKE  - 16302,0 
80 HCOLOR= 4:HPLOT 0,0: CALL 62454 
90 HCOLOR= 2:Y=63:GOSUB 30:Y=62:GOSUB 30
100 HCOLOR= 6:Y=61:GOSUB 30:Y=60:GOSUB 30
110 HCOLOR= 1:Y=59:GOSUB 30:Y=58:GOSUB 30
120 HCOLOR= 5:Y=55:GOSUB 30:Y=54:GOSUB 30
130 HCOLOR= 0:X=C
140 Y=123:GOSUB 30:Y=122:GOSUB 30
150 Y=119:GOSUB 30:Y=118:GOSUB 30
160 COLOR= 0:FOR I = 0 TO 39:VLIN 0,39 AT I:NEXT 
170 COLOR= 13:HLIN 0,39 AT 14 
180 FOR I = 0 TO 7:POKE A + I,0:POKE B + I,0:NEXT
190 COLOR= 1:HLIN 0,39 AT 13 
200 VTAB 21:? TAB( 16)"RAINBOW"
210 ?:? "MIXED GRAPHICS (HI-RES/COLOR)" 
220 CALL 768
@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Jan 3, 2015

Contributor

Note: AppleWin 1.26 NTSC Alpha, Rainbow requires this to work correctly:

BYTE MemReadFloatingBus(const ULONG uExecutedCycles)
// NTSC: It is tempting to replace with
// return NTSC_VideoGetByte( uExecutedCycles );
// But that breaks "Rainbow" Bug #254

Contributor

Michaelangel007 commented Jan 3, 2015

Note: AppleWin 1.26 NTSC Alpha, Rainbow requires this to work correctly:

BYTE MemReadFloatingBus(const ULONG uExecutedCycles)
// NTSC: It is tempting to replace with
// return NTSC_VideoGetByte( uExecutedCycles );
// But that breaks "Rainbow" Bug #254

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Jan 5, 2015

Contributor

Regarding the proper white fringes

Thread: How does the IIGS convert Hi or Double Hi-Res to RGB?
Newsgroups: comp.sys.apple2

http://www.lazilong.com/apple_II/a2pix/dgr2.htm

The problem with the method in tn-aiie-003 and IIGS Hardware Reference is:

(example)
Take a white DHR pixel at bit 4 of first byte:

|0123456012345601234560123456
|  ab0 |  mb1 |  ab2 |  mb3 |
|    ####

Take 4 bit windows at every bit (|    | is a 4 bit window). Look in the DHR table 
at the window's postion and match the 4 bits with a color:
DHR color table

|0123456012345601234560123456
|                             Black
|   #   #   #   #   #   #   # Magenta
|  ##  ##  ##  ##  ##  ##  ## Orange
| ### ### ### ### ### ### ### Yellow
|#   #   #   #   #   #   #    Dark Blue
|##  ##  ##  ##  ##  ##  ##   Blue
|### ### ### ### ### ### ###  Aqua
|############################ White


V-bit position of moving window
  Vvvvvvvvvvvvvv-bits in the window
                 Vvvvvvvvvvv- color the window represents
                             V- abbreviation
_|______________|___________|_
0|    |          Black       K 
1||   #|         Dark Blue   D
2| |  ##|        Blue        B
3|  | ###|       Aqua        A
4|   |####|      White       W
5|    |### |     Yellow      Y
6|     |##  |    Orange      O
7|      |#   |   Magenta     M
8|       |    |  Black       K

Using this method, the white dot is output not as WWWW but as DBAWYOMK (in very 
small color pixels). But this doesn't seem it would look white on the IIGS's screen 
(and it won't look white on a Mac screen). It's supposed to be a white dot. Maybe 
the colors just blend together to make it look more white? (because of the size of 
the phosphors compared to the size of the pixels..) Maybe it's like dithering in 
640 Super Hi-Res mode? (DHR is 560)

Does the Mega II actually use this method for it's DHR conversion to RGB? It 
definitely has to do more than just say 010 is green and 101 is purple and any 
2 adjacent 1's is white.. etc.
Contributor

Michaelangel007 commented Jan 5, 2015

Regarding the proper white fringes

Thread: How does the IIGS convert Hi or Double Hi-Res to RGB?
Newsgroups: comp.sys.apple2

http://www.lazilong.com/apple_II/a2pix/dgr2.htm

The problem with the method in tn-aiie-003 and IIGS Hardware Reference is:

(example)
Take a white DHR pixel at bit 4 of first byte:

|0123456012345601234560123456
|  ab0 |  mb1 |  ab2 |  mb3 |
|    ####

Take 4 bit windows at every bit (|    | is a 4 bit window). Look in the DHR table 
at the window's postion and match the 4 bits with a color:
DHR color table

|0123456012345601234560123456
|                             Black
|   #   #   #   #   #   #   # Magenta
|  ##  ##  ##  ##  ##  ##  ## Orange
| ### ### ### ### ### ### ### Yellow
|#   #   #   #   #   #   #    Dark Blue
|##  ##  ##  ##  ##  ##  ##   Blue
|### ### ### ### ### ### ###  Aqua
|############################ White


V-bit position of moving window
  Vvvvvvvvvvvvvv-bits in the window
                 Vvvvvvvvvvv- color the window represents
                             V- abbreviation
_|______________|___________|_
0|    |          Black       K 
1||   #|         Dark Blue   D
2| |  ##|        Blue        B
3|  | ###|       Aqua        A
4|   |####|      White       W
5|    |### |     Yellow      Y
6|     |##  |    Orange      O
7|      |#   |   Magenta     M
8|       |    |  Black       K

Using this method, the white dot is output not as WWWW but as DBAWYOMK (in very 
small color pixels). But this doesn't seem it would look white on the IIGS's screen 
(and it won't look white on a Mac screen). It's supposed to be a white dot. Maybe 
the colors just blend together to make it look more white? (because of the size of 
the phosphors compared to the size of the pixels..) Maybe it's like dithering in 
640 Super Hi-Res mode? (DHR is 560)

Does the Mega II actually use this method for it's DHR conversion to RGB? It 
definitely has to do more than just say 010 is green and 101 is purple and any 
2 adjacent 1's is white.. etc.
@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Jan 5, 2015

Contributor
10  PRINT  CHR$ (4)"PR#3"
20  TEXT : HOME : VTAB 20: HGR
30  REM ****** COLOR BANDS PURPLE BLUE GREEN ORANGE (ORDERED BY HALF DOT
40  REM        POSITIONS FROM LEFT SIDE OF SCREEN).
50  HCOLOR= 2: HPLOT 0,10 TO 279,10
60  HCOLOR= 6: HPLOT 0,11 TO 279,11
70  HCOLOR= 1: HPLOT 0,12 TO 279,12
80  HCOLOR= 5: HPLOT 0,13 TO 279,13
90  HCOLOR= 3: HPLOT 0,14 TO 279,14
100  HCOLOR= 7: HPLOT 0,15 TO 279,15
110  GET A$
120  HGR
130 C(0) = 2:C(1) = 6:C(2) = 1:C(3) = 5
140  REM ****** DRAW 2 COLORS SIDE BY SIDE.
150  REM        LEFT COLOR ON EVEN BYTE, RIGHT ON ODD.
160 XL(0) = 6:XL(1) = 6:XL(2) = 5:XL(3) = 5
170 XR(0) = 8:XR(1) = 8:XR(2) = 7:XR(3) = 7
180  FOR CL = 0 TO 3: FOR CR = 0 TO 3:X = (CL * 4 + CR) * 14
190  HCOLOR= C(CL): HPLOT X + XL(CL),0 TO X + XL(CL),79
200  GET A$
210  HCOLOR= C(CR): HPLOT X + XR(CR),0 TO X + XR(CR),79
220  GET A$
230  NEXT : NEXT
240  REM ****** DRAW 2 COLORS SIDE BY SIDE.
250  REM        LEFT COLOR ON ODD BYTE, RIGHT ON EVEN.
260 XL(0) = 12:XL(1) = 12:XL(2) = 13:XL(3) = 13
270 XR(0) = 14:XR(1) = 14:XR(2) = 15:XR(3) = 15
280  FOR CL = 0 TO 3: FOR CR = 0 TO 3:X = (CL * 4 + CR) * 14
290  HCOLOR= C(CL): HPLOT X + XL(CL),80 TO X + XL(CL),159
300  GET A$
310  HCOLOR= C(CR): HPLOT X + XR(CR),80 TO X + XR(CR),159
320  GET A$
330  NEXT : NEXT
340  REM ****** DRAW DARK BLUE, BROWN, LIGHT BLUE, YELLOW LINES.
350  HCOLOR= 7: HPLOT 230,0 TO 230,79: HPLOT 237,80 TO 237,159
360  HCOLOR= 3: HPLOT 244,0 TO 244,79: HPLOT 251,80 TO 251,159
370  GET A$
380  HCOLOR= 4: HPLOT 245,0 TO 245,79: HPLOT 252,80 TO 252,159
390  GET A$
400  REM ****** LABEL THE COLOR LINES WITH THE COLORS USED ON THE LEFT AND
410  REM        RIGHT SIDE OF THE BYTE BOUNDARY. ALSO LABEL OTHER COLORS.
420 C$(0) = "P":C$(1) = "B":C$(2) = "G":C$(3) = "O"
430  VTAB 21
440  FOR CL = 0 TO 3: FOR CR = 0 TO 3: PRINT "  "C$(CL)C$(CR);: NEXT : NEXT
450  PRINT "  BcOcPsGs"
460  PRINT "TOP ROW: EVEN BYTE/ODD BYTE             ";
470  PRINT "BOTTOM ROW: ODD BYTE/EVEN BYTE"
480  REM ****** CLEAR AND SET HIGH BITS OF SOME ROWS OF EVEN/ODD COLOR LINES.
490  FOR I = 0 TO 279 STEP 14
500  HCOLOR= 0: HPLOT I,30 TO I,39: HPLOT I + 13,30 TO I + 13,39
510  HCOLOR= 4: HPLOT I,40 TO I,49: HPLOT I + 13,40 TO I + 13,49: NEXT
520  REM ****** CLEAR AND SET HIGH BITS OF SOME ROWS OF ODD/EVEN COLOR LINES.
530  FOR I = 7 TO 266 STEP 14
540  HCOLOR= 0: HPLOT I,110 TO I,119: HPLOT I + 13,110 TO I + 13,119
550  HCOLOR= 4: HPLOT I,120 TO I,129: HPLOT I + 13,120 TO I + 13,129: NEXT
Contributor

Michaelangel007 commented Jan 5, 2015

10  PRINT  CHR$ (4)"PR#3"
20  TEXT : HOME : VTAB 20: HGR
30  REM ****** COLOR BANDS PURPLE BLUE GREEN ORANGE (ORDERED BY HALF DOT
40  REM        POSITIONS FROM LEFT SIDE OF SCREEN).
50  HCOLOR= 2: HPLOT 0,10 TO 279,10
60  HCOLOR= 6: HPLOT 0,11 TO 279,11
70  HCOLOR= 1: HPLOT 0,12 TO 279,12
80  HCOLOR= 5: HPLOT 0,13 TO 279,13
90  HCOLOR= 3: HPLOT 0,14 TO 279,14
100  HCOLOR= 7: HPLOT 0,15 TO 279,15
110  GET A$
120  HGR
130 C(0) = 2:C(1) = 6:C(2) = 1:C(3) = 5
140  REM ****** DRAW 2 COLORS SIDE BY SIDE.
150  REM        LEFT COLOR ON EVEN BYTE, RIGHT ON ODD.
160 XL(0) = 6:XL(1) = 6:XL(2) = 5:XL(3) = 5
170 XR(0) = 8:XR(1) = 8:XR(2) = 7:XR(3) = 7
180  FOR CL = 0 TO 3: FOR CR = 0 TO 3:X = (CL * 4 + CR) * 14
190  HCOLOR= C(CL): HPLOT X + XL(CL),0 TO X + XL(CL),79
200  GET A$
210  HCOLOR= C(CR): HPLOT X + XR(CR),0 TO X + XR(CR),79
220  GET A$
230  NEXT : NEXT
240  REM ****** DRAW 2 COLORS SIDE BY SIDE.
250  REM        LEFT COLOR ON ODD BYTE, RIGHT ON EVEN.
260 XL(0) = 12:XL(1) = 12:XL(2) = 13:XL(3) = 13
270 XR(0) = 14:XR(1) = 14:XR(2) = 15:XR(3) = 15
280  FOR CL = 0 TO 3: FOR CR = 0 TO 3:X = (CL * 4 + CR) * 14
290  HCOLOR= C(CL): HPLOT X + XL(CL),80 TO X + XL(CL),159
300  GET A$
310  HCOLOR= C(CR): HPLOT X + XR(CR),80 TO X + XR(CR),159
320  GET A$
330  NEXT : NEXT
340  REM ****** DRAW DARK BLUE, BROWN, LIGHT BLUE, YELLOW LINES.
350  HCOLOR= 7: HPLOT 230,0 TO 230,79: HPLOT 237,80 TO 237,159
360  HCOLOR= 3: HPLOT 244,0 TO 244,79: HPLOT 251,80 TO 251,159
370  GET A$
380  HCOLOR= 4: HPLOT 245,0 TO 245,79: HPLOT 252,80 TO 252,159
390  GET A$
400  REM ****** LABEL THE COLOR LINES WITH THE COLORS USED ON THE LEFT AND
410  REM        RIGHT SIDE OF THE BYTE BOUNDARY. ALSO LABEL OTHER COLORS.
420 C$(0) = "P":C$(1) = "B":C$(2) = "G":C$(3) = "O"
430  VTAB 21
440  FOR CL = 0 TO 3: FOR CR = 0 TO 3: PRINT "  "C$(CL)C$(CR);: NEXT : NEXT
450  PRINT "  BcOcPsGs"
460  PRINT "TOP ROW: EVEN BYTE/ODD BYTE             ";
470  PRINT "BOTTOM ROW: ODD BYTE/EVEN BYTE"
480  REM ****** CLEAR AND SET HIGH BITS OF SOME ROWS OF EVEN/ODD COLOR LINES.
490  FOR I = 0 TO 279 STEP 14
500  HCOLOR= 0: HPLOT I,30 TO I,39: HPLOT I + 13,30 TO I + 13,39
510  HCOLOR= 4: HPLOT I,40 TO I,49: HPLOT I + 13,40 TO I + 13,49: NEXT
520  REM ****** CLEAR AND SET HIGH BITS OF SOME ROWS OF ODD/EVEN COLOR LINES.
530  FOR I = 7 TO 266 STEP 14
540  HCOLOR= 0: HPLOT I,110 TO I,119: HPLOT I + 13,110 TO I + 13,119
550  HCOLOR= 4: HPLOT I,120 TO I,129: HPLOT I + 13,120 TO I + 13,129: NEXT
@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Jan 7, 2015

Contributor

Screenshot of ApplePC running under OSX with DOSBox

applepc_dosbox_hgrbytes

Contributor

Michaelangel007 commented Jan 7, 2015

Screenshot of ApplePC running under OSX with DOSBox

applepc_dosbox_hgrbytes

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Jan 7, 2015

Contributor

Screenshot of ApplePC running under OSX with DOSBox

applepc_dosbox_archon

Contributor

Michaelangel007 commented Jan 7, 2015

Screenshot of ApplePC running under OSX with DOSBox

applepc_dosbox_archon

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Jan 7, 2015

Contributor

Screenshot of ApplePC running under OSX with DOSBox

applepc_dosbox_hgr8x8

Contributor

Michaelangel007 commented Jan 7, 2015

Screenshot of ApplePC running under OSX with DOSBox

applepc_dosbox_hgr8x8

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Jan 13, 2015

Contributor

Thread: Re: AppleWin Video Mode: Monochrome (Half-Shift)
Author: mmphosis

"From what I can tell, the half pixel shifting used in drawing the Lambda's look the same in both emulators, except that Catakig is in color."

9000 N = 95
9001  HGR : HCOLOR= 4
9002  FOR I = 1 TO 191 STEP 2
9003  HPLOT 0,I TO 279,I: NEXT
9004 D = 3
9005 S = N / D
9009  FOR I = 0 TO N
9010  HCOLOR= 3
9011 X = I + S
9012 Y = I * 2
9013  HPLOT I,Y TO X,Y
9015  IF I >  = N / 2 THEN 9021
9016 Y = (N - I) * 2 + 1
9017  HPLOT I,Y TO X,Y
9021 Y = I * 2 + 1
9025  HCOLOR= 7
9027  HPLOT I,Y TO X,Y
9029  IF I >  = N / 2 THEN 9040
9030 Y = (N - I) * 2
9031  HPLOT I,Y TO X,Y
9040  NEXT : VTAB 24
9050  POKE  - 16302,0
Contributor

Michaelangel007 commented Jan 13, 2015

Thread: Re: AppleWin Video Mode: Monochrome (Half-Shift)
Author: mmphosis

"From what I can tell, the half pixel shifting used in drawing the Lambda's look the same in both emulators, except that Catakig is in color."

9000 N = 95
9001  HGR : HCOLOR= 4
9002  FOR I = 1 TO 191 STEP 2
9003  HPLOT 0,I TO 279,I: NEXT
9004 D = 3
9005 S = N / D
9009  FOR I = 0 TO N
9010  HCOLOR= 3
9011 X = I + S
9012 Y = I * 2
9013  HPLOT I,Y TO X,Y
9015  IF I >  = N / 2 THEN 9021
9016 Y = (N - I) * 2 + 1
9017  HPLOT I,Y TO X,Y
9021 Y = I * 2 + 1
9025  HCOLOR= 7
9027  HPLOT I,Y TO X,Y
9029  IF I >  = N / 2 THEN 9040
9030 Y = (N - I) * 2
9031  HPLOT I,Y TO X,Y
9040  NEXT : VTAB 24
9050  POKE  - 16302,0
@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Aug 25, 2015

Contributor

Cleaned up Make.HGR

1 HGR:HCOLOR=0:B=0:GOTO 5
2 HPLOT X*14,Y*2+D:A=PEEK(38)+256*PEEK(39):P=A+X*2
3 POKE P,B*(1-D):POKE P+1,0: POKE P+9,B*(1-D):POKE P+10,0: POKE A+18,127:POKE A+20,255: POKE A+23,127:POKE A+25,255
4 RETURN
5 FOR X=0 TO 3:FOR Y=0 TO 63
6 D=0:GOSUB 2
7 D=1:GOSUB 2
8 B=B+1:NEXT:NEXT:B=0
9 FOR I=0 TO 7:HCOLOR=I:HPLOT 0,132+I*2 TO 28,132+I*2:NEXT
Contributor

Michaelangel007 commented Aug 25, 2015

Cleaned up Make.HGR

1 HGR:HCOLOR=0:B=0:GOTO 5
2 HPLOT X*14,Y*2+D:A=PEEK(38)+256*PEEK(39):P=A+X*2
3 POKE P,B*(1-D):POKE P+1,0: POKE P+9,B*(1-D):POKE P+10,0: POKE A+18,127:POKE A+20,255: POKE A+23,127:POKE A+25,255
4 RETURN
5 FOR X=0 TO 3:FOR Y=0 TO 63
6 D=0:GOSUB 2
7 D=1:GOSUB 2
8 B=B+1:NEXT:NEXT:B=0
9 FOR I=0 TO 7:HCOLOR=I:HPLOT 0,132+I*2 TO 28,132+I*2:NEXT
@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Aug 26, 2015

Contributor

My custom Color Reference Disk of various HGR images for comparison on the various emulators. Version 3 menu:

[A] ARCHON 
[B] BYTES 
[C] CAPTAIN.GOODNIGHT.SKULL 
[D] DROLL 
[E] BEAGLE.COLOR 
[F] FANTAVISION 
[G] GUMBALL 
[H] COLOR 
[K] KARATEKA 
[L] LADYTUT 
[M] MONO560 
[S] SWASHBUCKLER 
[U] U4 
[Y] LAMBDA 
[Z] AZTEC 
[1] PAGE 1                               
[2] PAGE 2                               
[3] GR TEST PATTERN                     
[4] VIEW HGR                             
[5] SPLIT HGR                           
Contributor

Michaelangel007 commented Aug 26, 2015

My custom Color Reference Disk of various HGR images for comparison on the various emulators. Version 3 menu:

[A] ARCHON 
[B] BYTES 
[C] CAPTAIN.GOODNIGHT.SKULL 
[D] DROLL 
[E] BEAGLE.COLOR 
[F] FANTAVISION 
[G] GUMBALL 
[H] COLOR 
[K] KARATEKA 
[L] LADYTUT 
[M] MONO560 
[S] SWASHBUCKLER 
[U] U4 
[Y] LAMBDA 
[Z] AZTEC 
[1] PAGE 1                               
[2] PAGE 2                               
[3] GR TEST PATTERN                     
[4] VIEW HGR                             
[5] SPLIT HGR                           
@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Aug 26, 2015

Contributor

Cleaned up MAKE.LAMBDA Applesoft source code so it only takes 2 sectors instead of wasting 3 sectors:

1 N = 95: HGR : POKE 49234,0: HCOLOR = 4: FOR I = 1 TO 191 STEP 2: HPLOT  0,I TO 279,I: NEXT :D = 3:S = N / D
2 FOR I = 0 TO N: HCOLOR= 3:X = I + S:Y = I * 2: HPLOT I,Y TO X,Y: IF I >  = N / 2 THEN 4
3 Y = (N - I) * 2 + 1: HPLOT I,Y TO X,Y
4 Y = I * 2 + 1: HCOLOR= 7: HPLOT I,Y TO X,Y: IF I >  = N / 2 THEN 6
5 Y = (N - I) * 2: HPLOT I,Y TO X,Y
6 NEXT
Contributor

Michaelangel007 commented Aug 26, 2015

Cleaned up MAKE.LAMBDA Applesoft source code so it only takes 2 sectors instead of wasting 3 sectors:

1 N = 95: HGR : POKE 49234,0: HCOLOR = 4: FOR I = 1 TO 191 STEP 2: HPLOT  0,I TO 279,I: NEXT :D = 3:S = N / D
2 FOR I = 0 TO N: HCOLOR= 3:X = I + S:Y = I * 2: HPLOT I,Y TO X,Y: IF I >  = N / 2 THEN 4
3 Y = (N - I) * 2 + 1: HPLOT I,Y TO X,Y
4 Y = I * 2 + 1: HCOLOR= 7: HPLOT I,Y TO X,Y: IF I >  = N / 2 THEN 6
5 Y = (N - I) * 2: HPLOT I,Y TO X,Y
6 NEXT
@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Aug 26, 2015

Contributor

Original MAKE.MULTICOLOR

 1  REM *** THIS DEMONSTRATES DOUBLE-HIRES COLORS ON THE HIRES SCREEN
 2  REM     USING ABBERRATIONS OF THE APPLE II VIDEO HARDWARE
 3  REM *** FOUND ON THE WEB, APPARENTLY FROM A COMP.SYS.APPLE2
 4  REM     POSTING BY VANTUNE@FRASER.SFU.CA (JOSEPH VAN TUNEN)
 5  REM     (MODIFIED SLIGHTLY)
 6  REM *** RUN THIS TO SEE BROWN, YELLOW, AND SOME OTHERS...
 7  REM     VERIFIED ON A IIGS, BOTH COMPOSITE AND RGB OUTPUTS.
 10  PRINT  CHR$ (4)"PR#3"
 20  TEXT : HOME : VTAB 20: HGR 
 30 PAUSE = 0
 120  HGR 
 130 C(0) = 2:C(1) = 6:C(2) = 1:C(3) = 5
 140  REM *** DRAW 2 COLORS SIDE BY SIDE
 150  REM     LEFT COLOR ON EVEN BYTE, RIGHT ON ODD.
 160 XL(0) = 6:XL(1) = 6:XL(2) = 5:XL(3) = 5
 170 XR(0) = 8:XR(1) = 8:XR(2) = 7:XR(3) = 7
 180  FOR CL = 0 TO 3: FOR CR = 0 TO 3:X = (CL * 4 + CR) * 14
 190  HCOLOR= C(CL): HPLOT X + XL(CL),0 TO X + XL(CL),79
 200  IF PAUSE THEN  GET A$
 210  HCOLOR= C(CR): HPLOT X + XR(CR),0 TO X + XR(CR),79
 220  IF PAUSE THEN  GET A$
 230  NEXT : NEXT 
 240  REM *** DRAW 2 COLORS SIDE BY SIDE
 250  REM     LEFT COLOR ON ODD BYTE, RIGHT ON EVEN.
 260 XL(0) = 12:XL(1) = 12:XL(2) = 13:XL(3) = 13
 270 XR(0) = 14:XR(1) = 14:XR(2) = 15:XR(3) = 15
 280  FOR CL = 0 TO 3: FOR CR = 0 TO 3:X = (CL * 4 + CR) * 14
 290  HCOLOR= C(CL): HPLOT X + XL(CL),80 TO X + XL(CL),159
 300  IF PAUSE THEN  GET A$
 310  HCOLOR= C(CR): HPLOT X + XR(CR),80 TO X + XR(CR),159
 320  IF PAUSE THEN  GET A$
 330  NEXT : NEXT 
 350  HCOLOR= 7: HPLOT 230,0 TO 230,79: HPLOT 237,80 TO 237,159
 360  HCOLOR= 3: HPLOT 244,0 TO 244,79: HPLOT 251,80 TO 251,159
 370  IF PAUSE THEN  GET A$
 380  HCOLOR= 4: HPLOT 245,0 TO 245,79: HPLOT 252,80 TO 252,159
 390  IF PAUSE THEN  GET A$
 400  REM *** LABEL THE COLOR LINES WITH THE COLORS USED ON THE LEFT AND
 410  REM     RIGHT SIDE OF THE BYTE BOUNDARY.  ALSO LABEL OTHER COLORS.
 420 C$(0) = "P":C$(1) = "B":C$(2) = "G":C$(3) = "O"
 430  VTAB 21
 440  FOR CL = 0 TO 3: FOR CR = 0 TO 3: PRINT "  "C$(CL)C$(CR);: NEXT : NEXT 
 450  PRINT "  BcOcPsGs"
 460  PRINT "TOP ROW: EVEN BYTE/ODD BYTE             ";
 470  PRINT "BOTTOM ROW: ODD BYTE/EVEN BYTE"
 480  REM *** CLEAR AND SET HIGH BITS OF SOME ROWS OF EVEN/ODD COLOR LINES
 490  FOR I = 0 TO 279 STEP 14
 500  HCOLOR= 0: HPLOT I,30 TO I,39: HPLOT I + 13,30 TO I + 13,39
 510  HCOLOR= 4: HPLOT I,40 TO I,49: HPLOT I + 13,40 TO I + 13,49: NEXT 
 520  REM *** CLEAR AND SET HIGH BITS OF SOME ROWS OF ODD/EVEN COLOR LINES
 530  FOR I = 7 TO 266 STEP 14
 540  HCOLOR= 0: HPLOT I,110 TO I,119: HPLOT I + 13,110 TO I + 13,119
 550  HCOLOR= 4: HPLOT I,120 TO I,129: HPLOT I + 13,120 TO I + 13,129: NEXT 
Contributor

Michaelangel007 commented Aug 26, 2015

Original MAKE.MULTICOLOR

 1  REM *** THIS DEMONSTRATES DOUBLE-HIRES COLORS ON THE HIRES SCREEN
 2  REM     USING ABBERRATIONS OF THE APPLE II VIDEO HARDWARE
 3  REM *** FOUND ON THE WEB, APPARENTLY FROM A COMP.SYS.APPLE2
 4  REM     POSTING BY VANTUNE@FRASER.SFU.CA (JOSEPH VAN TUNEN)
 5  REM     (MODIFIED SLIGHTLY)
 6  REM *** RUN THIS TO SEE BROWN, YELLOW, AND SOME OTHERS...
 7  REM     VERIFIED ON A IIGS, BOTH COMPOSITE AND RGB OUTPUTS.
 10  PRINT  CHR$ (4)"PR#3"
 20  TEXT : HOME : VTAB 20: HGR 
 30 PAUSE = 0
 120  HGR 
 130 C(0) = 2:C(1) = 6:C(2) = 1:C(3) = 5
 140  REM *** DRAW 2 COLORS SIDE BY SIDE
 150  REM     LEFT COLOR ON EVEN BYTE, RIGHT ON ODD.
 160 XL(0) = 6:XL(1) = 6:XL(2) = 5:XL(3) = 5
 170 XR(0) = 8:XR(1) = 8:XR(2) = 7:XR(3) = 7
 180  FOR CL = 0 TO 3: FOR CR = 0 TO 3:X = (CL * 4 + CR) * 14
 190  HCOLOR= C(CL): HPLOT X + XL(CL),0 TO X + XL(CL),79
 200  IF PAUSE THEN  GET A$
 210  HCOLOR= C(CR): HPLOT X + XR(CR),0 TO X + XR(CR),79
 220  IF PAUSE THEN  GET A$
 230  NEXT : NEXT 
 240  REM *** DRAW 2 COLORS SIDE BY SIDE
 250  REM     LEFT COLOR ON ODD BYTE, RIGHT ON EVEN.
 260 XL(0) = 12:XL(1) = 12:XL(2) = 13:XL(3) = 13
 270 XR(0) = 14:XR(1) = 14:XR(2) = 15:XR(3) = 15
 280  FOR CL = 0 TO 3: FOR CR = 0 TO 3:X = (CL * 4 + CR) * 14
 290  HCOLOR= C(CL): HPLOT X + XL(CL),80 TO X + XL(CL),159
 300  IF PAUSE THEN  GET A$
 310  HCOLOR= C(CR): HPLOT X + XR(CR),80 TO X + XR(CR),159
 320  IF PAUSE THEN  GET A$
 330  NEXT : NEXT 
 350  HCOLOR= 7: HPLOT 230,0 TO 230,79: HPLOT 237,80 TO 237,159
 360  HCOLOR= 3: HPLOT 244,0 TO 244,79: HPLOT 251,80 TO 251,159
 370  IF PAUSE THEN  GET A$
 380  HCOLOR= 4: HPLOT 245,0 TO 245,79: HPLOT 252,80 TO 252,159
 390  IF PAUSE THEN  GET A$
 400  REM *** LABEL THE COLOR LINES WITH THE COLORS USED ON THE LEFT AND
 410  REM     RIGHT SIDE OF THE BYTE BOUNDARY.  ALSO LABEL OTHER COLORS.
 420 C$(0) = "P":C$(1) = "B":C$(2) = "G":C$(3) = "O"
 430  VTAB 21
 440  FOR CL = 0 TO 3: FOR CR = 0 TO 3: PRINT "  "C$(CL)C$(CR);: NEXT : NEXT 
 450  PRINT "  BcOcPsGs"
 460  PRINT "TOP ROW: EVEN BYTE/ODD BYTE             ";
 470  PRINT "BOTTOM ROW: ODD BYTE/EVEN BYTE"
 480  REM *** CLEAR AND SET HIGH BITS OF SOME ROWS OF EVEN/ODD COLOR LINES
 490  FOR I = 0 TO 279 STEP 14
 500  HCOLOR= 0: HPLOT I,30 TO I,39: HPLOT I + 13,30 TO I + 13,39
 510  HCOLOR= 4: HPLOT I,40 TO I,49: HPLOT I + 13,40 TO I + 13,49: NEXT 
 520  REM *** CLEAR AND SET HIGH BITS OF SOME ROWS OF ODD/EVEN COLOR LINES
 530  FOR I = 7 TO 266 STEP 14
 540  HCOLOR= 0: HPLOT I,110 TO I,119: HPLOT I + 13,110 TO I + 13,119
 550  HCOLOR= 4: HPLOT I,120 TO I,129: HPLOT I + 13,120 TO I + 13,129: NEXT 
@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Aug 26, 2015

Contributor

Minified MAKE.MULTICOLOR

20  HGR: C(0) = 2:C(1) = 6:C(2) = 1:C(3) = 5: L(0) = 6:L(1) = 6:L(2) = 5:L(3) = 5: R(0) = 8:R(1) = 8:R(2) = 7:R(3) = 7: L(4) = 12:L(5) = 12:L(6) = 13:L(7) = 13: R(4) = 14:R(5) = 14:R(6) = 15:R(7) = 15
180 FOR U = 0 TO 3: FOR V = 0 TO 3:X = (U * 4 + V) * 14:HCOLOR= C(U): HPLOT X + L(U),0 TO X + L(L),79:HCOLOR= C(V): HPLOT X + R(V),0 TO X + R(V),79
290 HCOLOR= C(U): HPLOT X + L(U+4),80 TO X + L(U+4),159:HCOLOR= C(V): HPLOT X + R(V+4),80 TO X + R(V+4),159:NEXT : NEXT 
350 HCOLOR= 7: HPLOT 230,0 TO 230,79: HPLOT 237,80 TO 237,159 : HCOLOR= 3: HPLOT 244,0 TO 244,79: HPLOT 251,80 TO 251,159:HCOLOR= 4: HPLOT 245,0 TO 245,79: HPLOT 252,80 TO 252,159
490 FOR I = 0 TO 279 STEP 14:HCOLOR= 0: HPLOT I, 30 TO I, 39: HPLOT I + 13, 30 TO I + 13, 39: HCOLOR= 4: HPLOT I, 40 TO I, 49: HPLOT I + 13, 40 TO I + 13, 49: NEXT 
530 FOR I = 7 TO 266 STEP 14:HCOLOR= 0: HPLOT I,110 TO I,119: HPLOT I + 13,110 TO I + 13,119: HCOLOR= 4: HPLOT I,120 TO I,129: HPLOT I + 13,120 TO I + 13,129: NEXT 
560 VTAB 21: ? "PpPbPgPoBpBbBgBoGpGbGgGoOpObOgOoBcOcPsGsTOP ROW: EVEN BYTE/ODD  BYTE": ? "BOT ROW: ODD  BYTE/EVEN BYTE":VTAB 23
Contributor

Michaelangel007 commented Aug 26, 2015

Minified MAKE.MULTICOLOR

20  HGR: C(0) = 2:C(1) = 6:C(2) = 1:C(3) = 5: L(0) = 6:L(1) = 6:L(2) = 5:L(3) = 5: R(0) = 8:R(1) = 8:R(2) = 7:R(3) = 7: L(4) = 12:L(5) = 12:L(6) = 13:L(7) = 13: R(4) = 14:R(5) = 14:R(6) = 15:R(7) = 15
180 FOR U = 0 TO 3: FOR V = 0 TO 3:X = (U * 4 + V) * 14:HCOLOR= C(U): HPLOT X + L(U),0 TO X + L(L),79:HCOLOR= C(V): HPLOT X + R(V),0 TO X + R(V),79
290 HCOLOR= C(U): HPLOT X + L(U+4),80 TO X + L(U+4),159:HCOLOR= C(V): HPLOT X + R(V+4),80 TO X + R(V+4),159:NEXT : NEXT 
350 HCOLOR= 7: HPLOT 230,0 TO 230,79: HPLOT 237,80 TO 237,159 : HCOLOR= 3: HPLOT 244,0 TO 244,79: HPLOT 251,80 TO 251,159:HCOLOR= 4: HPLOT 245,0 TO 245,79: HPLOT 252,80 TO 252,159
490 FOR I = 0 TO 279 STEP 14:HCOLOR= 0: HPLOT I, 30 TO I, 39: HPLOT I + 13, 30 TO I + 13, 39: HCOLOR= 4: HPLOT I, 40 TO I, 49: HPLOT I + 13, 40 TO I + 13, 49: NEXT 
530 FOR I = 7 TO 266 STEP 14:HCOLOR= 0: HPLOT I,110 TO I,119: HPLOT I + 13,110 TO I + 13,119: HCOLOR= 4: HPLOT I,120 TO I,129: HPLOT I + 13,120 TO I + 13,129: NEXT 
560 VTAB 21: ? "PpPbPgPoBpBbBgBoGpGbGgGoOpObOgOoBcOcPsGsTOP ROW: EVEN BYTE/ODD  BYTE": ? "BOT ROW: ODD  BYTE/EVEN BYTE":VTAB 23
@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Aug 26, 2015

Contributor

Continue minification

1 GOTO 20
2 HPLOT I,0 TO I,Y-1:HPLOT J,Y TO J,Y*2-1:RETURN
3 HPLOT I,Y TO I,Y+9:HPLOT K, Y TO K, Y+9: HPLOT J,Y+80 TO J,Y+89: IF A = 1 THEN HPLOT L,Y+80 TO L,Y+89
4 RETURN
20 HGR: C(0) = 2:C(1) = 6:C(2) = 1:C(3) = 5: L(0) = 6:L(1) = 6:L(2) = 5:L(3) = 5: R(0) = 8:R(1) = 8:R(2) = 7:R(3) = 7: L(4) = 12:L(5) = 12:L(6) = 13:L(7) = 13: R(4) = 14:R(5) = 14:R(6) = 15:R(7) = 15
180 Y=80:FOR U = 0 TO 3: FOR V = 0 TO 3:X = (U * 4 + V) * 14:HCOLOR= C(U):I=X+L(U):J=X+L(U+4):GOSUB 2 : HCOLOR= C(V):I=X+R(V):J=X+R(V+4): GOSUB 2: NEXT : NEXT 
350 HCOLOR= 7: HPLOT 230,0 TO 230,Y: HPLOT 237,Y TO 237,Y*2 : HCOLOR= 3: HPLOT 244,0 TO 244,Y: HPLOT 251,Y TO 251,2*Y : HCOLOR= 4: HPLOT 245,0 TO 245,Y: HPLOT 252,Y TO 252,2*Y
490 FOR I = 0 TO 279 STEP 14: A=I+20<280:J=I+7:K=I+13:L=I+20:HCOLOR= 0: Y=30:GOSUB 3:HCOLOR=4:Y=40:GOSUB 3:NEXT
560 VTAB 21: ? "PpPbPgPoBpBbBgBoGpGbGgGoOpObOgOoBcOcPsGsTOP ROW: EVEN BYTE/ODD  BYTE": ? "BOT ROW: ODD  BYTE/EVEN BYTE":VTAB 23
Contributor

Michaelangel007 commented Aug 26, 2015

Continue minification

1 GOTO 20
2 HPLOT I,0 TO I,Y-1:HPLOT J,Y TO J,Y*2-1:RETURN
3 HPLOT I,Y TO I,Y+9:HPLOT K, Y TO K, Y+9: HPLOT J,Y+80 TO J,Y+89: IF A = 1 THEN HPLOT L,Y+80 TO L,Y+89
4 RETURN
20 HGR: C(0) = 2:C(1) = 6:C(2) = 1:C(3) = 5: L(0) = 6:L(1) = 6:L(2) = 5:L(3) = 5: R(0) = 8:R(1) = 8:R(2) = 7:R(3) = 7: L(4) = 12:L(5) = 12:L(6) = 13:L(7) = 13: R(4) = 14:R(5) = 14:R(6) = 15:R(7) = 15
180 Y=80:FOR U = 0 TO 3: FOR V = 0 TO 3:X = (U * 4 + V) * 14:HCOLOR= C(U):I=X+L(U):J=X+L(U+4):GOSUB 2 : HCOLOR= C(V):I=X+R(V):J=X+R(V+4): GOSUB 2: NEXT : NEXT 
350 HCOLOR= 7: HPLOT 230,0 TO 230,Y: HPLOT 237,Y TO 237,Y*2 : HCOLOR= 3: HPLOT 244,0 TO 244,Y: HPLOT 251,Y TO 251,2*Y : HCOLOR= 4: HPLOT 245,0 TO 245,Y: HPLOT 252,Y TO 252,2*Y
490 FOR I = 0 TO 279 STEP 14: A=I+20<280:J=I+7:K=I+13:L=I+20:HCOLOR= 0: Y=30:GOSUB 3:HCOLOR=4:Y=40:GOSUB 3:NEXT
560 VTAB 21: ? "PpPbPgPoBpBbBgBoGpGbGgGoOpObOgOoBcOcPsGsTOP ROW: EVEN BYTE/ODD  BYTE": ? "BOT ROW: ODD  BYTE/EVEN BYTE":VTAB 23
@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Feb 20, 2016

Contributor

make.256 running on Jace OSX

make 256 jace

Contributor

Michaelangel007 commented Feb 20, 2016

make.256 running on Jace OSX

make 256 jace

@Michaelangel007

This comment has been minimized.

Show comment
Hide comment
@Michaelangel007

Michaelangel007 Aug 1, 2016

Contributor

TV vs Color Monitor vertical blurring test:

HGR grey test that clearly shows grey 1 2A 55 != grey 2 55 D5 alternating lines, as used in Beagle Bro's Alpha Plot, file COLOR CHART

!
300:  LDY #0
 LDA #2A
 JSR $31B
 LDA #AA
 JSR $334
 INY
 LDA #55
 JSR $31B
 LDA #D5
 JSR $334
 INY
 BPL $302
 RTS
 STA $2000,Y
 STA $2401,Y
 STA $2800,Y
 STA $2C01,Y
 STA $3000,Y
 STA $3401,Y
 STA $3800,Y
 STA $3C01,Y
 RTS
 STA $2080,Y
 STA $2481,Y
 STA $2880,Y
 STA $2C81,Y
 STA $3080,Y
 STA $3481,Y
 STA $3880,Y
 STA $3C81,Y
 RTS
Contributor

Michaelangel007 commented Aug 1, 2016

TV vs Color Monitor vertical blurring test:

HGR grey test that clearly shows grey 1 2A 55 != grey 2 55 D5 alternating lines, as used in Beagle Bro's Alpha Plot, file COLOR CHART

!
300:  LDY #0
 LDA #2A
 JSR $31B
 LDA #AA
 JSR $334
 INY
 LDA #55
 JSR $31B
 LDA #D5
 JSR $334
 INY
 BPL $302
 RTS
 STA $2000,Y
 STA $2401,Y
 STA $2800,Y
 STA $2C01,Y
 STA $3000,Y
 STA $3401,Y
 STA $3800,Y
 STA $3C01,Y
 RTS
 STA $2080,Y
 STA $2481,Y
 STA $2880,Y
 STA $2C81,Y
 STA $3080,Y
 STA $3481,Y
 STA $3880,Y
 STA $3C81,Y
 RTS

@tomcw tomcw modified the milestones: 1.26, 1.27 Oct 16, 2016

@st3fan st3fan referenced this issue in st3fan/ewm Dec 9, 2016

Closed

Implement color HGR support #65

@tomcw tomcw modified the milestones: 1.27, 1.28 Dec 17, 2017

@tomcw tomcw added this to To Do in Michael's issues May 27, 2018

@tomcw tomcw removed this from the 1.28 milestone May 27, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment