Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #2226 > unrolled thread

Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules"

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Mark Lemmert <mark.lemmert@gmail.com> - 2016-02-15 11:40 -0800
    Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" gids.rs@sasktel.net - 2016-02-15 12:33 -0800
      Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" gids.rs@sasktel.net - 2016-02-15 12:38 -0800
        Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Mark Lemmert <mark.lemmert@gmail.com> - 2016-02-15 14:11 -0800
          Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" dempson@actrix.gen.nz (David Empson) - 2016-02-16 14:22 +1300
            Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Mark Lemmert <mark.lemmert@gmail.com> - 2016-02-15 18:33 -0800
      Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Mark Lemmert <mark.lemmert@gmail.com> - 2016-02-15 14:08 -0800
        Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" gids.rs@sasktel.net - 2016-02-15 19:39 -0800
          Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" gids.rs@sasktel.net - 2016-02-15 19:47 -0800
            Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" David Schmidt <schmidtd@my-deja.com> - 2016-02-15 23:25 -0500
              Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" gids.rs@sasktel.net - 2016-02-16 08:42 -0800
          Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Mark Lemmert <mark.lemmert@gmail.com> - 2016-02-16 11:28 -0800
          Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" denisbytezone@gmail.com - 2016-02-18 14:53 -0800
            Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Mark Lemmert <mark.lemmert@gmail.com> - 2016-02-18 15:28 -0800
            Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" gids.rs@sasktel.net - 2016-02-18 15:31 -0800
              Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" denisbytezone@gmail.com - 2016-02-18 15:42 -0800
                Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" gids.rs@sasktel.net - 2016-02-18 15:52 -0800
                  Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" gids.rs@sasktel.net - 2016-02-18 16:09 -0800
                Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" gids.rs@sasktel.net - 2016-02-18 16:42 -0800
                Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-02-22 11:01 -0800
            Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" dempson@actrix.gen.nz (David Empson) - 2016-02-19 12:47 +1300
            Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" gids.rs@sasktel.net - 2016-02-18 15:49 -0800
              Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" gids.rs@sasktel.net - 2016-02-18 16:02 -0800
    Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-02-16 11:34 -0800
      Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Mark Lemmert <mark.lemmert@gmail.com> - 2016-02-16 12:00 -0800
        Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-02-16 13:47 -0800
    Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-02-16 13:41 -0800
      Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Mark Lemmert <mark.lemmert@gmail.com> - 2016-02-16 19:02 -0800
      Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Mark Lemmert <mark.lemmert@gmail.com> - 2016-02-17 18:09 -0800
        Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" marc.depeo@brbent.com - 2016-02-18 00:43 -0800
          Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" wssimms@gmail.com - 2016-02-18 01:48 -0800
            Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" AppleIIGSMarc <appleiigsmarc@gmail.com> - 2016-02-18 08:50 -0800
              Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" AppleIIGSMarc <appleiigsmarc@gmail.com> - 2016-02-18 10:45 -0800
                Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-02-18 20:24 -0800
                  Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" wssimms@gmail.com - 2016-02-18 20:32 -0800
                    Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" AppleIIGSMarc <appleiigsmarc@gmail.com> - 2016-02-18 21:05 -0800
              Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" gids.rs@sasktel.net - 2016-02-18 15:08 -0800
              Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Mark Lemmert <mark.lemmert@gmail.com> - 2016-02-18 15:31 -0800
            Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-02-18 13:18 -0800
              Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" wssimms@gmail.com - 2016-02-18 18:15 -0800
            Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-03-01 11:58 -0800
    Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-02-16 14:05 -0800
      Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Mark Lemmert <mark.lemmert@gmail.com> - 2016-02-16 19:12 -0800
        Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" "Michael J. Mahon" <mjmahon@aol.com> - 2016-02-17 15:22 -0800
          Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Mark Lemmert <mark.lemmert@gmail.com> - 2016-02-17 16:14 -0800
    Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" denisbytezone@gmail.com - 2016-02-19 14:34 -0800
      Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Mark Lemmert <mark.lemmert@gmail.com> - 2016-02-19 16:17 -0800
        Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" denisbytezone@gmail.com - 2016-02-19 19:19 -0800
          Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-02-19 22:25 -0800
            Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" denisbytezone@gmail.com - 2016-02-19 23:12 -0800
              Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-02-19 23:27 -0800
                Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-02-19 23:31 -0800
                  Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" wssimms@gmail.com - 2016-02-20 04:02 -0800
                    Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-02-20 11:40 -0800
                    Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-02-20 11:48 -0800
          Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Mark Lemmert <mark.lemmert@gmail.com> - 2016-02-20 08:10 -0800
            Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" denisbytezone@gmail.com - 2016-02-20 16:25 -0800
              Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-02-20 16:37 -0800
              Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Mark Lemmert <mark.lemmert@gmail.com> - 2016-02-20 18:29 -0800
                Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" gids.rs@sasktel.net - 2016-02-20 20:00 -0800
                  Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Mark Lemmert <mark.lemmert@gmail.com> - 2016-02-20 20:53 -0800
                    Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" gids.rs@sasktel.net - 2016-02-20 23:11 -0800
                      Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" denisbytezone@gmail.com - 2016-02-21 00:23 -0800
                        Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" wssimms@gmail.com - 2016-02-21 01:41 -0800
                          Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" wssimms@gmail.com - 2016-02-21 01:43 -0800
                          Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" denisbytezone@gmail.com - 2016-02-21 02:29 -0800
                            Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" denisbytezone@gmail.com - 2016-02-21 02:40 -0800
                            Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" wssimms@gmail.com - 2016-02-21 08:03 -0800
                            Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" gids.rs@sasktel.net - 2016-02-21 09:55 -0800
                              Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" gids.rs@sasktel.net - 2016-02-21 10:28 -0800
                                Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" gids.rs@sasktel.net - 2016-02-21 14:42 -0800
                            Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael J. Mahon <mjmahon@aol.com> - 2016-02-22 14:13 -0600
                      Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-02-21 20:49 -0800
                      Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" anthonypaulo@gmail.com - 2017-06-22 17:19 -0700
                        Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Mark Lemmert <mark.lemmert@gmail.com> - 2017-06-22 18:05 -0700
                          Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" awanderin <awanderin@gmail.com> - 2017-06-22 23:00 -0600
                          Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael J. Mahon <mjmahon@aol.com> - 2017-06-23 12:59 -0500
                            Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" David Schmenk <dschmenk@gmail.com> - 2017-06-23 13:12 -0700
                            Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-06-25 07:30 -0700
                            Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" anthonypaulo@gmail.com - 2017-06-25 08:30 -0700
                              Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael J. Mahon <mjmahon@aol.com> - 2017-06-25 13:55 -0500
                        Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Charlie <charlieDOTd@verEYEzon.net> - 2017-06-23 11:26 -0400
                          Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-06-25 07:45 -0700
                            Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" anthonypaulo@gmail.com - 2017-06-25 08:33 -0700
                              Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" anthonypaulo@gmail.com - 2017-06-25 08:38 -0700
                              Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" David Schmenk <dschmenk@gmail.com> - 2017-06-25 12:07 -0700
                                Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" anthonypaulo@gmail.com - 2017-06-25 16:29 -0700
      Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael J. Mahon <mjmahon@aol.com> - 2016-02-20 00:27 -0600
        Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" denisbytezone@gmail.com - 2016-02-19 23:14 -0800
    Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-03-01 11:48 -0800
      Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael J. Mahon <mjmahon@aol.com> - 2016-03-01 16:24 -0600
      Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Mark Lemmert <mark.lemmert@gmail.com> - 2016-03-02 10:05 -0800
        Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Finger <mike.finger@gmail.com> - 2016-04-06 13:21 -0700
          Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-04-06 13:32 -0700
          Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" gids.rs@sasktel.net - 2016-04-06 15:15 -0700
            Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-06-25 06:17 -0700
              Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" gids.rs@sasktel.net - 2017-06-25 21:33 -0700
                Re: Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules" Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-06-26 11:12 -0700

Page 1 of 5  [1] 2 3 4 5  Next page →

#2226 — Assembly Hi-Res Graphics, question about color patterns that seem to violate the "rules"

For most Apple II games, I understand how to draw the graphics used in them using assembly. There are a few with graphics that I just can't figure out. I've read several graphics books and am familiar with the odd/even column color rules, high bit, and half bit shift. 


For example, the following screen shots from Ultima V:

https://www.dropbox.com/s/40qlaeth6wfa7ta/screenshot1.PNG?dl=0

The 3 blue guys in the central region of the screen. Does anyone know how to get blue to display on the screen like this? I really appreciate any advice anyone has to offer. 

What I'm finding puzzling about it is that a) it displays as though the blue lines are in adjacent columns, which is not possible under the rules the graphics books teach that I've seen and b) the blue is very smooth, not pixelated at all. 


In contrast, when I try to turn on blue in the first two even columns (column 0 and column 2, I get two blue lines with an empty column in between. Additionally, it looks very pixelated compared to the above. Here is a screen shot:

https://www.dropbox.com/s/l6a6xmb28i6dxe3/screenshot2.JPG?dl=0


Half bit shift, as I understand it, wouldn't explain this. I don't think Ultima V uses double hi-res as the only colors I've ever seen on screen are the single hi-res colors. I'm stumped! 

I get the same result, as it relates to the proximity and pixelation issue, on my physical Apple IIe and AppleWin (the above pics are using AppleWIN). 

Thanks much if anyone has any ideas!



--Additional Information

In my program (the second screenshot), here is how the graphics screen is turned on, in case I'm doing some wrong there. 


	LDA GRAPHICS	;TURN ON GRAPHICS MODE
	LDA HIRES		;SELECT HI-RES MODE
	LDA PAGE1		;SELECT PAGE 1
	LDA MIXOFF		;SELECT FULL SCREEN GRAPHICS (PAGE 1)



GRAPHICS 			.EQ	$C050
HIRES				.EQ	$C057
PAGE1				.EQ	$C054
MIXOFF				.EQ	$C052

[toc] | [next] | [standalone]

#2227

On Monday, February 15, 2016 at 1:40:12 PM UTC-6, Mark Lemmert wrote:
> For most Apple II games, I understand how to draw the graphics used in them using assembly. There are a few with graphics that I just can't figure out. I've read several graphics books and am familiar with the odd/even column color rules, high bit, and half bit shift. 
> 
> 
> For example, the following screen shots from Ultima V:
> 
> https://www.dropbox.com/s/40qlaeth6wfa7ta/screenshot1.PNG?dl=0
> 
> The 3 blue guys in the central region of the screen. Does anyone know how to get blue to display on the screen like this? I really appreciate any advice anyone has to offer. 
> 
> What I'm finding puzzling about it is that a) it displays as though the blue lines are in adjacent columns, which is not possible under the rules the graphics books teach that I've seen and b) the blue is very smooth, not pixelated at all. 
> 
> 
> In contrast, when I try to turn on blue in the first two even columns (column 0 and column 2, I get two blue lines with an empty column in between. Additionally, it looks very pixelated compared to the above. Here is a screen shot:
> 
> https://www.dropbox.com/s/l6a6xmb28i6dxe3/screenshot2.JPG?dl=0
> 
> 
> Half bit shift, as I understand it, wouldn't explain this. I don't think Ultima V uses double hi-res as the only colors I've ever seen on screen are the single hi-res colors. I'm stumped! 
> 
> I get the same result, as it relates to the proximity and pixelation issue, on my physical Apple IIe and AppleWin (the above pics are using AppleWIN). 
> 
> Thanks much if anyone has any ideas!
> 
> 
> 
> --Additional Information
> 
> In my program (the second screenshot), here is how the graphics screen is turned on, in case I'm doing some wrong there. 
> 
> 
> 	LDA GRAPHICS	;TURN ON GRAPHICS MODE
> 	LDA HIRES		;SELECT HI-RES MODE
> 	LDA PAGE1		;SELECT PAGE 1
> 	LDA MIXOFF		;SELECT FULL SCREEN GRAPHICS (PAGE 1)
> 
> 
> 
> GRAPHICS 			.EQ	$C050
> HIRES				.EQ	$C057
> PAGE1				.EQ	$C054
> MIXOFF				.EQ	$C052


The best way to see this is for your self.  In Applewin, at the prompt type this 

]HGR
]CALL -151

*2000:1
*2000:81
*2000:85
*2000:95
*2000:D5


If you have a hex calculator to see the binary display, you would see each of the values entered above have no two bits set that are adjacent, other than the hi-bit, which when not set shows, violet & green, and when set shows, blue and orange.

[toc] | [prev] | [next] | [standalone]

#2228

 
> The best way to see this is for your self.  In Applewin, at the prompt type this 
> 
> ]HGR
> ]CALL -151
> 
> *2000:1
> *2000:81
> *2000:85
> *2000:95
> *2000:D5
> 
> 
> If you have a hex calculator to see the binary display, you would see each of the values entered above have no two bits set that are adjacent, other than the hi-bit, which when not set shows, violet & green, and when set shows, blue and orange.


I should also mention, it takes 2 bits to make a pixel, or in your case a column.  Entering a blue pixel in column 0 and 2 should look exactly the way you describe.  Put a blue pixel in column 1 and you will get the result you are looking for.

[toc] | [prev] | [next] | [standalone]

#2230

> I should also mention, it takes 2 bits to make a pixel, or in your case a column.  Entering a blue pixel in column 0 and 2 should look exactly the way you describe. 


By two bits to make a pixel, are you referring to the high-bit and the bit to turn on the pixel itself? (such as turning on the pixel on column 1 as blue with 10000001 (2 bits turned on)



> Put a blue pixel in column 1 and you will get the result you are looking for.

Could you clarify? If I turn on the pixel in column 1 with the high bit set !82 (01000001) is get an orange pixel and without the high-bet set I get a green pixel. 



Thanks again for your help, I really appreciate it!

[toc] | [prev] | [next] | [standalone]

#2233

Mark Lemmert <mark.lemmert@gmail.com> wrote:

> > I should also mention, it takes 2 bits to make a pixel, or in your case
> > a column.  Entering a blue pixel in column 0 and 2 should look exactly
> > the way you describe.
> 
> By two bits to make a pixel, are you referring to the high-bit and the bit
> to turn on the pixel itself? (such as turning on the pixel on column 1 as
> blue with 10000001 (2 bits turned on)

I interpreted the previous poster's quote as referring to the fact that
two adjacent bits horizontally are required to form a colour pixel. The
high order bit affects which colour set is used (0:
black/green/violet/white; 1: black/orange/blue/white). The two bit
pattern selects which of the four available colours are displayed for
that pixel.

In effect, the horizontal resolution for colour is half that of
monochrome: 140 colour pixels per line, with effectively six colours
available (constrained to four choices within adjacent groups of three
and a half colour pixels, due to the shared high order bit).

Depending on the display hardware (composite or RGB) and monitor, colour
pixels may appear about twice as wide as monochrome pixels, or they may
be the same width, with visible gaps (black) between pixels of the same
colour on the same row.

I rarely had access to a colour monitor on 8-bit Apple II models: I was
using Apple ][+ then //e with green screens at school from 1981 to 1985,
during which time I wrote a hi-res graphics drawing program (including
at least one complete rewrite from BASIC to assembly language). Once I
got my own IIgs I was able to have a better play with the colour stuff.

I never bothered with double hi-res (beyond a brief play), because the
IIgs super hi-res graphics was better in every way, and easier to work
with.

> > Put a blue pixel in column 1 and you will get the result you are looking
> > for.
> 
> Could you clarify? If I turn on the pixel in column 1 with the high bit
> set !82 (01000001) is get an orange pixel and without the high-bet set I
> get a green pixel.

That didn't make sense to me either. You can't "put a blue pixel in
column 1" (assuming columns are numbered 0 to 279, corresponding to
monochrome pixels). As you say, that bit pattern would produce an orange
pixel.

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#2234

> In effect, the horizontal resolution for colour is half that of
> monochrome: 140 colour pixels per line, with effectively six colours
> available (constrained to four choices within adjacent groups of three
> and a half colour pixels, due to the shared high order bit).


David,

Thank you for your reply! I have also noticed some differences between displays, emulator vs. physical Apple. Usually they are subtle. 

In the case of the mysteries adjacent vertical blue lines in Ultima 5, I think there must be an additional element in play. Reason being, if it's the display creating an illusion that the vertical lines are adjacent, then in theory, it would do the same with my code. Yet my vertical blue lines have an empty column in between. This occurs on both AppleWIN and on a physical Apple with color TV as display.  


Screen shot URLs from OP for quick reference. 

https://www.dropbox.com/s/40qlaeth6wfa7ta/screenshot1.PNG?dl=0 

https://www.dropbox.com/s/l6a6xmb28i6dxe3/screenshot2.JPG?dl=0

[toc] | [prev] | [next] | [standalone]

#2229

> The best way to see this is for your self.  In Applewin, at the prompt type this 
> 
> ]HGR
> ]CALL -151
> 
> *2000:1
> *2000:81
> *2000:85
> *2000:95
> *2000:D5
> 
> 
> If you have a hex calculator to see the binary display, you would see each of the values entered above have no two bits set that are adjacent, other than the hi-bit, which when not set shows, violet & green, and when set shows, blue and orange.





Thanks a lot for your help!

I entered in this code and I see a horizontal blue line get progressively longer after each hex value is entered.

I do see that there are no two adjacent bits set.


Is there a way to get this effect vertically? I'm trying to get two blue vertical lines without an empty column between them. 

[toc] | [prev] | [next] | [standalone]

#2235

bit #
0 1 2 3 4 5 6 7   0 1 2 3 4 5 6 7

         color bit          color bit
              |                 |    
0 0 0 0 0 0 0 0   0 0 0 0 0 0 0 0
|_| |_| |_| |_____| |_| |_| |_| 

 0   1   2     3     4   5   6


every 2 bytes starting on an even number ($2000.2001) gives seven pixels.
  As you can see, pixel #3 uses a bit from byte $2000 and byte 2001 to form a pixel.

if any two bits are consecutive (except the color bit) you get two white pixels.
with color bit clear, each group of bits will show violet or green.
with color bit set, each group of bits will show blue or orange.

color bit clear
bits-color
00 - black
10 - violet
01 - green
11 - white

color bit set
00 - black
10 - blue
01 - orange
11 - white


To get the value in each byte
even byte ($2000,2002,2004 etc...)
bit # value #
 0   _ $1
 1  |_ $2
 2   _ $4
 3  |_ $8
 4   _ $10
 5  |_ $20
 6   _ $40
 7  |  $80  - color bit
    |
bit#| value# - odd bytes ($2001,2003 etc...)
 0  |_ $1
 1   _ $2
 2  |_ $4
 3   _ $8
 4  |_ $10
 5   _ $20
 6  |_ $40
 7     $80  - color bit


Using the chart directly above, you can add the values that make up each pixel

For each column or pixels  - add put a 0 or 1 into each group of bits according to the color chart

for pixel#0
so for a violet pixel - bit#0=1 & bit#1=0 from the color chart above - for a total of $1
for a green pixel - bit#0=0 & bit#1=1 for a total of $2
for a blue pixel - bit#0=1 & bit#1=0 equals 1 plus the value of the color bit $80 = $81
for an orange pixel - bit#0=0 & bit#1=1 equals 2 plus the color bit = $82


for pixel#1
violet - bit#2=1 & bit#3=0 = 4
green - bit#2=0 & bit#3=1 = 8
blue - bit#2=1 & bit#3=0 equals 4 + colorbit = $84
orange - bit#2=0 & bit+3=1 equals 8 + colorbit = $88

for two consecutive blue pixels you would add
a blue pixel in pixel#0 equals $1 + a blue pixel in pixel#1 equals $4 + color bit = $85


now you should be able to see how I added up the values for a blue line

2000:$81
2000:$85
2000:$95
2000:$D5
2001:82
2001:8a
2001:aa

and $2002.2003 would be the same values for a blue line

$2002:81
$2002:85
$2002:95
$2002:D5
$2003:82
$2003:8a
$2003:aa



Vertical Lines have an unorthodox way as well and count from 0-$C0 (0-191)

$2000: Line #0
$2400: Line #1
$2800: Line #2


but instead of using lines this way, use the calculator in ROM @$F417

enter this routine in and enter the starting row# you want in $301 and it will display the starting address for that row.

300:A9 00 A2 20 86 E6 20 17 F4 A5 27 A6 26 20 41 F9 4C 8E FD 00

301:0
300G
2000

301:1
300G
2400

301:2
300G
2800
...

301:BF
300G
3FD0

[toc] | [prev] | [next] | [standalone]

#2236

On Monday, February 15, 2016 at 9:39:28 PM UTC-6, gid...@sasktel.net wrote:
> bit #
> 0 1 2 3 4 5 6 7   0 1 2 3 4 5 6 7
> 
>          color bit          color bit
>               |                 |    
> 0 0 0 0 0 0 0 0   0 0 0 0 0 0 0 0
> |_| |_| |_| |_____| |_| |_| |_| 
> 
>  0   1   2     3     4   5   6
> 


Doh!
That didn't come out right.  The google editor must use a non-proportional font and whatever web browser used displays using a proportional font.

You will have to copy and paste this into notepad to view it properly.

[toc] | [prev] | [next] | [standalone]

#2237

On 2/15/2016 10:47 PM, gids.rs@sasktel.net wrote:
> On Monday, February 15, 2016 at 9:39:28 PM UTC-6, gid...@sasktel.net wrote:
>> bit #
>> 0 1 2 3 4 5 6 7   0 1 2 3 4 5 6 7
>>
>>           color bit          color bit
>>                |                 |
>> 0 0 0 0 0 0 0 0   0 0 0 0 0 0 0 0
>> |_| |_| |_| |_____| |_| |_| |_|
>>
>>   0   1   2     3     4   5   6
>>
>
>
> Doh!
> That didn't come out right.  The google editor must use a non-proportional font and whatever web browser used displays using a proportional font.

It looks fine in Thunderbird newsreader.  Don't be too hasty and assume 
everyone uses GG. ;-)

OTOH - I can't imagine why any usenet reader, web or otherwise, would 
use a proportional font... it's simply not in keeping with the spirit, 
history, and utility of the thing.  Kids (i.e. Google) these days...

[toc] | [prev] | [next] | [standalone]

#2240

On Monday, February 15, 2016 at 10:25:05 PM UTC-6, schmidtd wrote:
> On 2/15/2016 10:47 PM, Rob wrote:
> > On Monday, February 15, 2016 at 9:39:28 PM UTC-6, Rob wrote:
> >> bit #
> >> 0 1 2 3 4 5 6 7   0 1 2 3 4 5 6 7
> >>
> >>           color bit          color bit
> >>                |                 |
> >> 0 0 0 0 0 0 0 0   0 0 0 0 0 0 0 0
> >> |_| |_| |_| |_____| |_| |_| |_|
> >>
> >>   0   1   2     3     4   5   6
> >>
> >
> >
> > Doh!
> > That didn't come out right.  The google editor must use a non-proportional font and whatever web browser used displays using a proportional font.
> 
> It looks fine in Thunderbird newsreader.  Don't be too hasty and assume 
> everyone uses GG. ;-)
> 
> OTOH - I can't imagine why any usenet reader, web or otherwise, would 
> use a proportional font... it's simply not in keeping with the spirit, 
> history, and utility of the thing.  Kids (i.e. Google) these days...


I don't assume anything, but it is more likely that anyone new to, or re-visiting, apple computers did not find these forums through a newsreader, but are most like viewing it using google groups.

If you do a search for programming on apple computers with any search engine, how many links come up using google groups?  Quite a few, no?

I also believe anyone using news readers for these forums are also advanced at programming the apple and are more likely to understand this post, even if it were out of alignment.

But would leave a new-comer scratching their heads.

Is that also assuming too much?  :)

[toc] | [prev] | [next] | [standalone]

#2241

On Monday, February 15, 2016 at 9:39:28 PM UTC-6, gid...@sasktel.net wrote:
> bit #
> 0 1 2 3 4 5 6 7   0 1 2 3 4 5 6 7
> 
>          color bit          color bit
>               |                 |    
> 0 0 0 0 0 0 0 0   0 0 0 0 0 0 0 0
> |_| |_| |_| |_____| |_| |_| |_| 
> 
>  0   1   2     3     4   5   6
> 
> 
> every 2 bytes starting on an even number ($2000.2001) gives seven pixels.
>   As you can see, pixel #3 uses a bit from byte $2000 and byte 2001 to form a pixel.
> 
> if any two bits are consecutive (except the color bit) you get two white pixels.
> with color bit clear, each group of bits will show violet or green.
> with color bit set, each group of bits will show blue or orange.


Thank you very much for the detailed response. I was able to read the charts without a problem, they displayed for me just fine. 


I am on the same page with you regarding which bit is the color bit and which bits in binary are associated with which pixels on the screen, and also Apple's interwoven scheme for line numbers on the graphics screen (personally I use a lookup tables for the speed advantage but the ROM routine is a great way to go too)

On a side note, for anyone who may find it helpful, I created a spreadsheet template recently which automates generate the binary and hex for shapes 2 screen bytes wide X 16 lines deep. The hex generated is formatted to be directly paste into the SBASM cross assembler and could be modified for other formats too. 

I've made is available for download here: 

https://www.dropbox.com/s/t9gzn8krb3dj8q4/Template.xlsx?dl=0



Do you know of a way to produce a vertical blue line that appears on the screen like this, using byte 1 and bye 2? (where b = the pixels of the blue line, L = line, B = screen byte). This seems to violate the rules as byte 1 is an odd numbered byte/column. 

--------------------------
    B0 B1 B2 B3 B4 B5 B6
L0     b
L1      b
L2     b
L3          b
L4          b
L5          b
L6          b

*extract of single hi-res screen [!40 bytes (columns) x !192 lines]
--------------------------

I apologize if the answer to this was in your last post and it alluded me somehow. I think I understood the content and I can totally see from it how to draw a horizontal blue line, any many other things, but I'm still stumped on how to draw a vertical line in two adjacent bytes (columns) as illustrated above. 

If this is possible could you provide the exact binary and hex codes to do it? 

For context for anyone reading in at this point: I fully understand that the conventional single hi-res rules say blue/violet are even columns only. As described in the OP, I think I found evidence of it being done (Ultima V) and I am trying to unravel the mystery.

[toc] | [prev] | [next] | [standalone]

#2271

On Tuesday, 16 February 2016 14:39:28 UTC+11, gid...@sasktel.net  wrote:
> bit #
> 0 1 2 3 4 5 6 7   0 1 2 3 4 5 6 7
> 
>          color bit          color bit
>               |                 |    
> 0 0 0 0 0 0 0 0   0 0 0 0 0 0 0 0
> |_| |_| |_| |_____| |_| |_| |_| 
> 
>  0   1   2     3     4   5   6
> 

Is this to do with double hi-res, or something else I completely misunderstand? Because according to the Apple II reference manual every bit maps to a pixel and there is no concept of odd/even bytes.

In the scheme described above, which color bit controls pixel #3?

[toc] | [prev] | [next] | [standalone]

#2274

On Thursday, February 18, 2016 at 4:53:50 PM UTC-6, denisb...@gmail.com wrote:
> On Tuesday, 16 February 2016 14:39:28 UTC+11, gid...@sasktel.net  wrote:
> > bit #
> > 0 1 2 3 4 5 6 7   0 1 2 3 4 5 6 7
> > 
> >          color bit          color bit
> >               |                 |    
> > 0 0 0 0 0 0 0 0   0 0 0 0 0 0 0 0
> > |_| |_| |_| |_____| |_| |_| |_| 
> > 
> >  0   1   2     3     4   5   6
> > 
> 
> Is this to do with double hi-res, or something else I completely misunderstand? Because according to the Apple II reference manual every bit maps to a pixel and there is no concept of odd/even bytes.
> 
> In the scheme described above, which color bit controls pixel #3?

The original poster of the above and I were discussing single hi-res at the time, so I'd say it's safe to assume it has nothing to do with hi-res.

As to the bit/pixel mapping, here is how I learned it from several graphics books. I'm doing a lot of graphics programming right now and have found this model to be very accurate. 


COL# = column 

              BYTE 0                BYTE1
COL# 0 1 2 3 4 5 6       7 8 9 A B C D   
BIT#   0 1 2 3 4 5 6  7   0 1 2 3  4 5 6 7

This is an extract of bit map of the first two bytes in the upper left corner of the screen.

Bit #7 in byte0 controls the color for bits in byte0. Bit #7 in byte1 controls the color for bits in byte1

So for example you asked about pixel #3:

00010001

This binary would turn on pixel #3 and would turn on the color bit that affects it.

Regarding odd/even bytes. It is really odd/even columns that is the consideration. Blue/violet can only be drawn in even columns and green/orange can only be drawn in odd columns. There are a few quirks but I've found in practice this to be generally accurate. 

Also note how the first bit in the byte 0 is column #0 (an even numbered column) and how the first bit in byte 1 is column #7 (an odd column). This is because the color bits don't "count" for purposes of counting columns.

In this way, the layout of the odd/even columns follows a pattern that repeats every 2 bytes. This is relevant when drawing color, because in essence, which bits turn on the odd vs. even pixels are different depending on where on the screen the byte is mapped to. 

Converting the binary to a hex value to store in memory is a whole other topic, it's not a simple as calculating the hex equivalent of the binary number as written (happy to elaborate if that's of interest).  



Here are few graphics books I found very helpful. They are game focused, but the concepts are relevant for many graphics applications. They really break it all down.

Apple Graphics & Arcade Game Design (Jeffery Stanton)
Hi-Res Graphics and Animation Using Assembly Language (Leonard Malkin)

[toc] | [prev] | [next] | [standalone]

#2275

On Thursday, February 18, 2016 at 4:53:50 PM UTC-6, denisb...@gmail.com wrote:
> On Tuesday, 16 February 2016 14:39:28 UTC+11, gid...@sasktel.net  wrote:
> > bit #
> > 0 1 2 3 4 5 6 7   0 1 2 3 4 5 6 7
> > 
> >          color bit          color bit
> >               |                 |    
> > 0 0 0 0 0 0 0 0   0 0 0 0 0 0 0 0
> > |_| |_| |_| |_____| |_| |_| |_| 
> > 
> >  0   1   2     3     4   5   6
> > 
> 
> Is this to do with double hi-res, or something else I completely misunderstand? Because according to the Apple II reference manual every bit maps to a pixel and there is no concept of odd/even bytes.
> 
> In the scheme described above, which color bit controls pixel #3?


No, this is not double hi-res.

Yes, the manual is correct where every bit maps to a pixel.  And on a monochrome monitor you will see each pixel individually.  And each bit will display a pixel but only has an on and off state.  This may be considered or known as monochrome or Black&White. 

But it takes more than one bit to display color on any computer or monitor.  And on a color monitor or tv, these on/off bits combine to make colors.  That is why text that is only one bit wide, is very hard to read on a color monitor.  The colors become random and have what is called, bleeding.  And this can even be defined as "dithering", which means to combine 2 colors and see a different effect.  Dithered text is not very readable with single pixels but can have a nice effect on wider characters.

To view color pixels though, 2 bits are combined to make a color, and the color bit (being the hi-bit of each byte) designates which group you will see.

But hey, you say, if 2 bits make a colored pixel and the hi-bit is used to designate a group, that leaves 7 bits.  Which means only 3-1/2 colored pixels can be displayed per byte.

As you can see in the chart above, pixel #3 combines the second highest bit, with the first bit of the next byte, to make a color pixel.

Thus, for every 2-bytes, you can have 7 colored pixels.


The colored charts are displayed in my other post.

[toc] | [prev] | [next] | [standalone]

#2277

On Friday, 19 February 2016 10:31:34 UTC+11, gid...@sasktel.net  wrote:
> On Thursday, February 18, 2016 at 4:53:50 PM UTC-6, denisb...@gmail.com wrote:
> > On Tuesday, 16 February 2016 14:39:28 UTC+11, gid...@sasktel.net  wrote:
> > > bit #
> > > 0 1 2 3 4 5 6 7   0 1 2 3 4 5 6 7
> > > 
> > >          color bit          color bit
> > >               |                 |    
> > > 0 0 0 0 0 0 0 0   0 0 0 0 0 0 0 0
> > > |_| |_| |_| |_____| |_| |_| |_| 
> > > 
> > >  0   1   2     3     4   5   6
> > > 
> > 
> > Is this to do with double hi-res, or something else I completely misunderstand? Because according to the Apple II reference manual every bit maps to a pixel and there is no concept of odd/even bytes.
> > 
> > In the scheme described above, which color bit controls pixel #3?
> 
> 
> No, this is not double hi-res.
> 
> Yes, the manual is correct where every bit maps to a pixel.  And on a monochrome monitor you will see each pixel individually.  And each bit will display a pixel but only has an on and off state.  This may be considered or known as monochrome or Black&White. 
> 
> But it takes more than one bit to display color on any computer or monitor.  And on a color monitor or tv, these on/off bits combine to make colors.  That is why text that is only one bit wide, is very hard to read on a color monitor.  The colors become random and have what is called, bleeding.  And this can even be defined as "dithering", which means to combine 2 colors and see a different effect.  Dithered text is not very readable with single pixels but can have a nice effect on wider characters.
> 
> To view color pixels though, 2 bits are combined to make a color, and the color bit (being the hi-bit of each byte) designates which group you will see.
> 
> But hey, you say, if 2 bits make a colored pixel and the hi-bit is used to designate a group, that leaves 7 bits.  Which means only 3-1/2 colored pixels can be displayed per byte.
> 
> As you can see in the chart above, pixel #3 combines the second highest bit, with the first bit of the next byte, to make a color pixel.
> 
> Thus, for every 2-bytes, you can have 7 colored pixels.
> 
> 
> The colored charts are displayed in my other post.

I think I understand what you are saying now, for every two bytes you can have 7 coloured pixels, but you also have to have 7 black pixels as well. My problem was making 53,760 pixels on the screen fit into 8192 bytes at two bits per pixel (plus the colour bit).

I tried using your scheme in my DiskBrowser, but I couldn't make it work. Going back to one bit per pixel works fine, but of course there are a lot of empty pixels.

The code is here if anyone is interested - https://github.com/dmolony/DiskBrowser/blob/master/src/com/bytezone/diskbrowser/applefile/HiResImage.java

See lines 85-137. It also draws the Ultima V screenshot accurately.

[toc] | [prev] | [next] | [standalone]

#2280

On Thursday, February 18, 2016 at 5:42:30 PM UTC-6, denisb...@gmail.com wrote:
> On Friday, 19 February 2016 10:31:34 UTC+11, gid...@sasktel.net  wrote:
> > On Thursday, February 18, 2016 at 4:53:50 PM UTC-6, denisb...@gmail.com wrote:
> > > On Tuesday, 16 February 2016 14:39:28 UTC+11, gid...@sasktel.net  wrote:
> > > > bit #
> > > > 0 1 2 3 4 5 6 7   0 1 2 3 4 5 6 7
> > > > 
> > > >          color bit          color bit
> > > >               |                 |    
> > > > 0 0 0 0 0 0 0 0   0 0 0 0 0 0 0 0
> > > > |_| |_| |_| |_____| |_| |_| |_| 
> > > > 
> > > >  0   1   2     3     4   5   6
> > > > 
> > > 
> > > Is this to do with double hi-res, or something else I completely misunderstand? Because according to the Apple II reference manual every bit maps to a pixel and there is no concept of odd/even bytes.
> > > 
> > > In the scheme described above, which color bit controls pixel #3?
> > 
> > 
> > No, this is not double hi-res.
> > 
> > Yes, the manual is correct where every bit maps to a pixel.  And on a monochrome monitor you will see each pixel individually.  And each bit will display a pixel but only has an on and off state.  This may be considered or known as monochrome or Black&White. 
> > 
> > But it takes more than one bit to display color on any computer or monitor.  And on a color monitor or tv, these on/off bits combine to make colors.  That is why text that is only one bit wide, is very hard to read on a color monitor.  The colors become random and have what is called, bleeding.  And this can even be defined as "dithering", which means to combine 2 colors and see a different effect.  Dithered text is not very readable with single pixels but can have a nice effect on wider characters.
> > 
> > To view color pixels though, 2 bits are combined to make a color, and the color bit (being the hi-bit of each byte) designates which group you will see.
> > 
> > But hey, you say, if 2 bits make a colored pixel and the hi-bit is used to designate a group, that leaves 7 bits.  Which means only 3-1/2 colored pixels can be displayed per byte.
> > 
> > As you can see in the chart above, pixel #3 combines the second highest bit, with the first bit of the next byte, to make a color pixel.
> > 
> > Thus, for every 2-bytes, you can have 7 colored pixels.
> > 
> > 
> > The colored charts are displayed in my other post.
> 
> I think I understand what you are saying now, for every two bytes you can have 7 coloured pixels, but you also have to have 7 black pixels as well. My problem was making 53,760 pixels on the screen fit into 8192 bytes at two bits per pixel (plus the colour bit).
> 
> I tried using your scheme in my DiskBrowser, but I couldn't make it work. Going back to one bit per pixel works fine, but of course there are a lot of empty pixels.
> 
> The code is here if anyone is interested - https://github.com/dmolony/DiskBrowser/blob/master/src/com/bytezone/diskbrowser/applefile/HiResImage.java
> 
> See lines 85-137. It also draws the Ultima V screenshot accurately.


That is because 53,760 is not the number of colored pixels, it is the number of on and off bits.  To calculate the # of colored pixels, multiply 140x192 to get the number of colored pixels to fit in 8192 bytes.

[toc] | [prev] | [next] | [standalone]

#2283

On Thursday, February 18, 2016 at 5:52:44 PM UTC-6, gid...@sasktel.net wrote:
> On Thursday, February 18, 2016 at 5:42:30 PM UTC-6, denisb...@gmail.com wrote:
> > On Friday, 19 February 2016 10:31:34 UTC+11, gid...@sasktel.net  wrote:
> > > On Thursday, February 18, 2016 at 4:53:50 PM UTC-6, denisb...@gmail.com wrote:
> > > > On Tuesday, 16 February 2016 14:39:28 UTC+11, gid...@sasktel.net  wrote:
> > > > > bit #
> > > > > 0 1 2 3 4 5 6 7   0 1 2 3 4 5 6 7
> > > > > 
> > > > >          color bit          color bit
> > > > >               |                 |    
> > > > > 0 0 0 0 0 0 0 0   0 0 0 0 0 0 0 0
> > > > > |_| |_| |_| |_____| |_| |_| |_| 
> > > > > 
> > > > >  0   1   2     3     4   5   6
> > > > > 
> > > > 
> > > > Is this to do with double hi-res, or something else I completely misunderstand? Because according to the Apple II reference manual every bit maps to a pixel and there is no concept of odd/even bytes.
> > > > 
> > > > In the scheme described above, which color bit controls pixel #3?
> > > 
> > > 
> > > No, this is not double hi-res.
> > > 
> > > Yes, the manual is correct where every bit maps to a pixel.  And on a monochrome monitor you will see each pixel individually.  And each bit will display a pixel but only has an on and off state.  This may be considered or known as monochrome or Black&White. 
> > > 
> > > But it takes more than one bit to display color on any computer or monitor.  And on a color monitor or tv, these on/off bits combine to make colors.  That is why text that is only one bit wide, is very hard to read on a color monitor.  The colors become random and have what is called, bleeding.  And this can even be defined as "dithering", which means to combine 2 colors and see a different effect.  Dithered text is not very readable with single pixels but can have a nice effect on wider characters.
> > > 
> > > To view color pixels though, 2 bits are combined to make a color, and the color bit (being the hi-bit of each byte) designates which group you will see.
> > > 
> > > But hey, you say, if 2 bits make a colored pixel and the hi-bit is used to designate a group, that leaves 7 bits.  Which means only 3-1/2 colored pixels can be displayed per byte.
> > > 
> > > As you can see in the chart above, pixel #3 combines the second highest bit, with the first bit of the next byte, to make a color pixel.
> > > 
> > > Thus, for every 2-bytes, you can have 7 colored pixels.
> > > 
> > > 
> > > The colored charts are displayed in my other post.
> > 
> > I think I understand what you are saying now, for every two bytes you can have 7 coloured pixels, but you also have to have 7 black pixels as well. My problem was making 53,760 pixels on the screen fit into 8192 bytes at two bits per pixel (plus the colour bit).
> > 
> > I tried using your scheme in my DiskBrowser, but I couldn't make it work. Going back to one bit per pixel works fine, but of course there are a lot of empty pixels.
> > 
> > The code is here if anyone is interested - https://github.com/dmolony/DiskBrowser/blob/master/src/com/bytezone/diskbrowser/applefile/HiResImage.java
> > 
> > See lines 85-137. It also draws the Ultima V screenshot accurately.
> 
> 
> That is because 53,760 is not the number of colored pixels, it is the number of on and off bits.  To calculate the # of colored pixels, multiply 140x192 to get the number of colored pixels to fit in 8192 bytes.



by the way, the actual # of on/off bits for 8192 bytes is 65536.  8192 x 8 = 65536.  There are some bytes not used for screen display and the color bits are not counted when you mutiply 280x192.

[toc] | [prev] | [next] | [standalone]

#2284

> I think I understand what you are saying now, for every two bytes you can have 7 coloured pixels, but you also have to have 7 black pixels as well.


Black is considered a color when viewing on a color monitor or tv.  Each 2 bits makes up a group of 4 colors.

color bit clear
bits-color
00 - black
10 - violet
01 - green
11 - white

color bit set
00 - black
10 - blue
01 - orange
11 - white


For Black or White colors with the color bit on.

On a monochrome monitor on a real computer, what you will see is a monochrome bit (color depends on your monochrome monitor, can be white, orange, green)

with a white pixel on a black background, turning the color bit on will have the effect of shifting the pixel, a half pixel to the right.

with a black pixel on a white background, turning the color bit on does the same thing.  It shows a black pixel shifting a half-pixel to the right.

There is software that can show the hi-res screen seeming to have 560 distinct pixels.  This effect does not work in any emulators, AFAIK, and is not easily visible using color monitor/tv.

[toc] | [prev] | [next] | [standalone]

#2353

On Thursday, February 18, 2016 at 4:42:30 PM UTC-7, denisb...@gmail.com wrote:
> My problem was making 53,760 pixels on the screen fit into 8192 bytes at two bits per pixel (plus the colour bit).

Technically, there are only 7,680 bytes that are used to display a HGR screen. The remaining 512 bytes are *not* used (at all!)  They are "screen holes".

Where does 7,680 comes from?

# Screen holes bytes = (192 scanlines / 3 scanlines/hole) * 8 bytes/hole
 = 64 * 3
 = 512 bytes

HGR page $2000..$3FFF = 8,192 bytes

Actual used bytes = 8,192 - 512 = 7,680 bytes.

See "Table 1: HGR Y Address for every scanline" in section "Non-Linear Memory" in my "HGR Font Tutorial"
* https://github.com/Michaelangel007/apple2_hgr_font_tutorial/#non-linear-memory

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.sys.apple2.programmer

csiph-web