Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.apple2.programmer > #2226 > unrolled thread
| Started by | Mark Lemmert <mark.lemmert@gmail.com> |
|---|---|
| First post | 2016-02-15 11:40 -0800 |
| Last post | 2017-06-26 11:12 -0700 |
| Articles | 20 on this page of 98 — 16 participants |
Back to article view | Back to comp.sys.apple2.programmer
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 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Michael Pohoreski <michael.pohoreski@gmail.com> |
|---|---|
| Date | 2016-03-01 11:58 -0800 |
| Message-ID | <0f6ad8a8-b147-4f25-95e1-0cdf353830cf@googlegroups.com> |
| In reply to | #2261 |
On Thursday, February 18, 2016 at 1:48:05 AM UTC-8, wss...@gmail.com wrote: > Comparisons with standard Applewin aren't very helpful as it has poor emulation of the NTSC display. Here is NTSC Applewin, although unfortunately the "blue guys" aren't present in the screen shot. > > http://wsxyz.net/images/u5ct.png Unfortunately that is not accurate for a few reasons :-/ 1. On the Apple Color Composite monitor, colors are not "solid". If you're talking about *other* Composite monitors, then OK. :-) 2. While I _love_ the 50% scanline option, due to the low DPI, that doesn't match exactly match the shadow mask. I estimate every other scanline needs to be 50% smaller to better emulate the "gaps" in the shadow mask. 3. I'm NOT seeing a yellow bleed, but a GREEN bleed on both of my monitors (Apple Color Composite Monitor and Franklin Composite Monitor.) Can anyone else try this on real hardware and post if they see: i) yellow bleeding, or ii) green bleeding where the green forest hits the right white inside border? 4. That green looks anemic. :-( I've mentioned AppleWin's NTSC color palette needs some TLC before. Close though!
[toc] | [prev] | [next] | [standalone]
| From | Michael Pohoreski <michael.pohoreski@gmail.com> |
|---|---|
| Date | 2016-02-16 14:05 -0800 |
| Message-ID | <73d10537-7de8-461a-a619-00ff732d700e@googlegroups.com> |
| In reply to | #2226 |
On Monday, February 15, 2016 at 11:40:12 AM UTC-8, Mark Lemmert wrote: > 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! Yeah, U5 only uses (single) HGR since it runs on a 64K Apple ][. http://i.ebayimg.com/images/g/eQ8AAOSwUuFWu2zD/s-l1600.jpg
[toc] | [prev] | [next] | [standalone]
| From | Mark Lemmert <mark.lemmert@gmail.com> |
|---|---|
| Date | 2016-02-16 19:12 -0800 |
| Message-ID | <c76480d0-a856-42a8-a08c-c4399cba881d@googlegroups.com> |
| In reply to | #2246 |
On Tuesday, February 16, 2016 at 4:05:11 PM UTC-6, Michael Pohoreski wrote: > On Monday, February 15, 2016 at 11:40:12 AM UTC-8, Mark Lemmert wrote: > > 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! > > Yeah, U5 only uses (single) HGR since it runs on a 64K Apple ][. > > http://i.ebayimg.com/images/g/eQ8AAOSwUuFWu2zD/s-l1600.jpg I started second guessing myself this evening. The observations in my OP were from the introduction screen. Tonight I "journeyed onward" to start the game itself and tracked down one of the Shadowlords and he was displayed different than in the introduction, specifically the odd/even color rules were followed and and empty column appeared between any vertical blue lines or pixels. There is also a slight yellow tint on some of the letters on the intro screen when the game boots up that I didn't notice before. I see this on my physical Apple IIe as well as AppleWIN. This made me start wondering if maybe they did the introduction in double hi-res (not that it should matter for the vertical blue lines since double hi-res as I understand it is only "double" for black & white) But, you make a very good point in your post with the Ultima V system requirements. If it runs on 64k, so no double hi-res. My physical Apple IIe is hooked up to a modern LCD TV so maybe that somehow causes the yellow tint, not sure. Anyway, sharing this additional info in case it sparks any other ideas.
[toc] | [prev] | [next] | [standalone]
| From | "Michael J. Mahon" <mjmahon@aol.com> |
|---|---|
| Date | 2016-02-17 15:22 -0800 |
| Message-ID | <x-udnahiqvEKnVjLnZ2dnUU7-X-dnZ2d@giganews.com> |
| In reply to | #2253 |
On 2/16/2016 7:12 PM, Mark Lemmert wrote: > On Tuesday, February 16, 2016 at 4:05:11 PM UTC-6, Michael Pohoreski wrote: >> On Monday, February 15, 2016 at 11:40:12 AM UTC-8, Mark Lemmert wrote: >>> 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! >> >> Yeah, U5 only uses (single) HGR since it runs on a 64K Apple ][. >> >> http://i.ebayimg.com/images/g/eQ8AAOSwUuFWu2zD/s-l1600.jpg > > > I started second guessing myself this evening. The observations in my OP were from the introduction screen. Tonight I "journeyed onward" to start the game itself and tracked down one of the Shadowlords and he was displayed different than in the introduction, specifically the odd/even color rules were followed and and empty column appeared between any vertical blue lines or pixels. > > There is also a slight yellow tint on some of the letters on the intro screen when the game boots up that I didn't notice before. I see this on my physical Apple IIe as well as AppleWIN. > > This made me start wondering if maybe they did the introduction in double hi-res (not that it should matter for the vertical blue lines since double hi-res as I understand it is only "double" for black & white) > > But, you make a very good point in your post with the Ultima V system requirements. If it runs on 64k, so no double hi-res. > > My physical Apple IIe is hooked up to a modern LCD TV so maybe that somehow causes the yellow tint, not sure. > > Anyway, sharing this additional info in case it sparks any other ideas. > The yellow tint you see is one of the more subtle NTSC color artifacts. Since almost all Apple II color displays were on NTSC color TVs, most game graphic designers had this in mind as they created their graphics. The yellow tint could be intentional or not, but it was certainly seen and approved by the designers. The gap between blue "dots" in a horizontal line is a result of excessively high chroma bandwidth. NTSC chroma bandwidth was on the order of 1MHz, so adjacent blue dots (actually two video dot times for each HGR "color" pixel) did not resolve the two dots fully, instead blending them. The same is true for all solid color areas. The gap between two successive horizontal lines (visible in a vertical line) is the result of the Apple video raster being non-interlaced, meaning that there are less than half as many horizontal lines as in a standard NTSC raster. If the CRT has a well-focused electron beam, then this will result in vertical lines being "dotted" rather than "solid". Most small color TVs used with Apple II's did not focus so well that these dots were obtrusive, though later, larger TVs did show the discontinuous nature of adjacent horizontal scan lines. Most VGA display adapters for the Apple II "double" each scan line, so that the space between adjacent Apple lines is less obtrusive. -- -michael NadaNet 3.1 for Apple II parallel computing! Home page: http://michaeljmahon.com "The wastebasket is our most important design tool--and it's seriously underused."
[toc] | [prev] | [next] | [standalone]
| From | Mark Lemmert <mark.lemmert@gmail.com> |
|---|---|
| Date | 2016-02-17 16:14 -0800 |
| Message-ID | <099d398f-cdae-4ed5-ae1c-22f7d5069081@googlegroups.com> |
| In reply to | #2257 |
> The yellow tint you see is one of the more subtle NTSC color artifacts.
> Since almost all Apple II color displays were on NTSC color TVs, most
> game graphic designers had this in mind as they created their graphics.
> The yellow tint could be intentional or not, but it was certainly seen
> and approved by the designers.
>
> The gap between blue "dots" in a horizontal line is a result of
> excessively high chroma bandwidth. NTSC chroma bandwidth was on the
> order of 1MHz, so adjacent blue dots (actually two video dot times for
> each HGR "color" pixel) did not resolve the two dots fully, instead
> blending them. The same is true for all solid color areas.
>
> The gap between two successive horizontal lines (visible in a vertical
> line) is the result of the Apple video raster being non-interlaced,
> meaning that there are less than half as many horizontal lines as in a
> standard NTSC raster. If the CRT has a well-focused electron beam, then
> this will result in vertical lines being "dotted" rather than "solid".
> Most small color TVs used with Apple II's did not focus so well that
> these dots were obtrusive, though later, larger TVs did show the
> discontinuous nature of adjacent horizontal scan lines.
Michael,
Thanks very much for your reply!
That is great to know the source of the yellow.
Sounds like you know the functionality of the underlying hardware very well.
In the OP I described a situation where I found two vertical blue lines in directly adjacent columns. Does that sound like something the hardware should be capable of?
For example:
(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]
--------------------------
That is supposed to be impossible under the programming rules taught in the graphics book; I've read many and they've all said that blue can only be used on even columns.
[toc] | [prev] | [next] | [standalone]
| From | denisbytezone@gmail.com |
|---|---|
| Date | 2016-02-19 14:34 -0800 |
| Message-ID | <1aa59295-b514-4d91-babf-3fb788e6cd15@googlegroups.com> |
| In reply to | #2226 |
I've been trying to get the double byte method to work, and it mostly does work, but in some instances the resulting images look a bit off. So I was wondering if someone with a physical apple and a colour screen could try an experiment for me. In the following description I have the bits ordered from most significant to least significant, which means the colour bit is on the left, and the pixels are interpreted in right-to-left order. A byte with the value 0x06 converts to 0-0-0-0 0-1-1-0 in binary, which in my understanding means first pixel (column 0) equals 0 (black), the second pixel (column 1) equals 1 (green), the third pixel (column 2) equals 1 (violet) and the fourth pixel (column 3) equals 0 (black). However the two consecutive 1 bits (according to the apple manual) override the colours and become two consecutive white pixels. So what actually appears on a physical apple? A green pixel followed by a violet pixel, or two white pixels? Because according to the double-byte method it should be two coloured pixels as they come from separate double-bytes. For reference, I am using the Apple ][ Reference Manual 1979, pp 19. Please don't make me type in the entire section :)
[toc] | [prev] | [next] | [standalone]
| From | Mark Lemmert <mark.lemmert@gmail.com> |
|---|---|
| Date | 2016-02-19 16:17 -0800 |
| Message-ID | <a299dfc7-573c-4da1-822b-c8180a314cf6@googlegroups.com> |
| In reply to | #2294 |
On Friday, February 19, 2016 at 4:34:15 PM UTC-6, denisb...@gmail.com wrote: > I've been trying to get the double byte method to work, and it mostly does work, but in some instances the resulting images look a bit off. So I was wondering if someone with a physical apple and a colour screen could try an experiment for me. > > In the following description I have the bits ordered from most significant to least significant, which means the colour bit is on the left, and the pixels are interpreted in right-to-left order. > > A byte with the value 0x06 converts to 0-0-0-0 0-1-1-0 in binary, which in my understanding means first pixel (column 0) equals 0 (black), the second pixel (column 1) equals 1 (green), the third pixel (column 2) equals 1 (violet) and the fourth pixel (column 3) equals 0 (black). However the two consecutive 1 bits (according to the apple manual) override the colours and become two consecutive white pixels. > > So what actually appears on a physical apple? A green pixel followed by a violet pixel, or two white pixels? Because according to the double-byte method it should be two coloured pixels as they come from separate double-bytes. > > For reference, I am using the Apple ][ Reference Manual 1979, pp 19. Please don't make me type in the entire section :) I tried it on my physical Apple IIe and the result was two white pixels. Here is a screen shot. If you need any other physical Apple tests done, I'm happy to help with them. https://www.dropbox.com/s/sqw0m4zlx9tky9x/IMG_9307.JPG?dl=0 Heres is exactly what I did: ] HGR ] CALL -151 ] 2000:06 I'm not familiar with the double byte method, so is there something else I would have needed to do to activate it? I checked the Apple ][ Reference manual pp 19 but didn't see anything about double bytes mentioned. It has a white cover with the Woz signature on the front. Maybe I've got the wrong one? > A byte with the value 0x06 converts to 0-0-0-0 0-1-1-0 in binary, which in my understanding means first pixel (column 0) equals 0 (black), the second pixel (column 1) equals 1 (green), the third pixel (column 2) equals 1 (violet) and the fourth pixel (column 3) equals 0 (black). However the two consecutive 1 bits (according to the apple manual) override the colours and become two consecutive white pixels. In my experience this is 100% correct, under the single byte method.
[toc] | [prev] | [next] | [standalone]
| From | denisbytezone@gmail.com |
|---|---|
| Date | 2016-02-19 19:19 -0800 |
| Message-ID | <6c28aabe-cd46-48cf-8644-946d34215ebd@googlegroups.com> |
| In reply to | #2297 |
> > In my experience this is 100% correct, under the single byte method. This is getting interesting. I tried poking the values 0x00 - 0x0F into the the first 16 screen locations going down the left hand side of the screen in AppleWin, and there were some surprising (to me) results. Here is the resulting table: B=black, W=white, V=violet, G=green 2000:00 0-0-0-0 B-B-B-B 2400:01 0-0-0-1 V-B-B-B 2800:02 0-0-1-0 B-G-B-B 2C00:03 0-0-1-1 W-W-B-B 3000:04 0-1-0-0 B-B-V-B 3400:05 0-1-0-1 V-V-V-B **** V-B-V-B 3800:06 0-1-1-0 B-W-W-B 3C00:07 0-1-1-1 W-W-W-B 2080:08 1-0-0-0 B-B-B-G 2480:09 1-0-0-1 V-B-B-G 2880:0A 1-0-1-0 B-G-G-G **** B-G-B-G 2C80:0B 1-0-1-1 W-W-G-G **** W-W-B-G 3080:0C 1-1-0-0 B-B-W-W 3480:0D 1-1-0-1 V-V-W-W **** V-B-W-W 3880:0E 1-1-1-0 B-W-W-W 3C80:0F 1-1-1-1 W-W-W-W I have a photo of the results, but I think I have transcribed them correctly. The results that surprised me are marked above with asterisks, followed by what I expected to see. If someone could write a program to poke these values into the correct memory locations I would be very grateful. In fact why stop at 16, can we do the whole 256 spread over several columns? My assembler skills aren't really up to scratch for that.
[toc] | [prev] | [next] | [standalone]
| From | Michael Pohoreski <michael.pohoreski@gmail.com> |
|---|---|
| Date | 2016-02-19 22:25 -0800 |
| Message-ID | <c40af636-4ecd-4d83-ab77-a83679b17d4a@googlegroups.com> |
| In reply to | #2303 |
On Friday, February 19, 2016 at 7:19:55 PM UTC-8, denisb...@gmail.com wrote: > > > If someone could write a program to poke these values into the correct memory locations I would be very grateful. In fact why stop at 16, can we do the whole 256 spread over several columns? My assembler skills aren't really up to scratch for that. You mean something like this? https://cloud.githubusercontent.com/assets/7876796/5530575/58664c54-89d6-11e4-95f0-6886b770b7e2.JPG You can use Applesoft to generate that: 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 It is saved as "MAKE.256" on my NTSC.dsk http://michael.peopleofhonoronly.com/dev/applewin/ntsc/ntsc.dsk You may find this thread interesting ... https://github.com/AppleWin/AppleWin/issues/254
[toc] | [prev] | [next] | [standalone]
| From | denisbytezone@gmail.com |
|---|---|
| Date | 2016-02-19 23:12 -0800 |
| Message-ID | <dff053db-635c-4b3f-b4bd-fbee76b87523@googlegroups.com> |
| In reply to | #2304 |
On Saturday, 20 February 2016 17:25:49 UTC+11, Michael Pohoreski wrote: > On Friday, February 19, 2016 at 7:19:55 PM UTC-8, denisb...@gmail.com wrote: > > > > > If someone could write a program to poke these values into the correct memory locations I would be very grateful. In fact why stop at 16, can we do the whole 256 spread over several columns? My assembler skills aren't really up to scratch for that. > > You mean something like this? > > https://cloud.githubusercontent.com/assets/7876796/5530575/58664c54-89d6-11e4-95f0-6886b770b7e2.JPG > > You can use Applesoft to generate that: > > 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 > > It is saved as "MAKE.256" on my NTSC.dsk > http://michael.peopleofhonoronly.com/dev/applewin/ntsc/ntsc.dsk > > You may find this thread interesting ... > https://github.com/AppleWin/AppleWin/issues/254 Excellent! Good to know I'm only several years behind on this.
[toc] | [prev] | [next] | [standalone]
| From | Michael Pohoreski <michael.pohoreski@gmail.com> |
|---|---|
| Date | 2016-02-19 23:27 -0800 |
| Message-ID | <8e1522f5-219d-4f3f-a489-db344dd32201@googlegroups.com> |
| In reply to | #2307 |
On Friday, February 19, 2016 at 11:12:08 PM UTC-8, denisb...@gmail.com wrote:
> > > If someone could write a program to poke these values into the correct memory locations I would be very grateful. In fact why stop at 16, can we do the whole 256 spread over several columns? My assembler skills aren't really up to scratch for that.
That's how you learn -- by doing.
You can just use the mini-assembler -- once you keep track of the variables
GBASL = $26 ; HGR pointer to cursor
GBASH = $27
HPOSN = $F411 ; A=row, X=col.lo,Y=col.hi, sets GBASL, GBASH
HGR = $F3E2
high = $FA
byte = $FB
col = $FC
row = $FD
saveX = $FE
saveY = $FF
Copy & Paste ...
- - - 8< - - -
CALL-151
!
300: JSR $F3E2
LDY #0
STY $FB
STY $FC
STY $FA
STY $FD
TYA
LDX $FC
LDY #0
JSR $F411
LDA $FB
LDY $FC
INY
STA ($26),Y
INY
LDA $FA
STA ($26),Y
INC $FB
LDY $FD
INY
INY
STY $FD
CPY #$80
BNE $30D
LDY #0
LDX $FC
INX
INX
INX
INX
STX $FC
TXA
AND #$F
BNE $30B
LDA $FA
EOR #$80
BEQ $348
STA $FA
LDY #0
BEQ $30B
RTS
300G
- - - 8< - - -
[toc] | [prev] | [next] | [standalone]
| From | Michael Pohoreski <michael.pohoreski@gmail.com> |
|---|---|
| Date | 2016-02-19 23:31 -0800 |
| Message-ID | <0dada6de-faef-40c1-bcff-d8cf6cc37b45@googlegroups.com> |
| In reply to | #2309 |
Here's the actual assembly source that I used to generate the alt. source for the mini-assembler.
I'm pulling a Sheldon with no comments. :-)
GBASL = $26 ; HGR pointer to cursor
GBASH = $27
HPOSN = $F411 ; A=row, X=col.lo,Y=col.hi, sets GBASL, GBASH
HGR = $F3E2
high = $FA
byte = $FB
col = $FC
row = $FD
saveX = $FE
saveY = $FF
JSR HGR
LDY #0
STY byte
STY col
STY high
@NextCol
STY row
@NextRow
TYA
LDX col
LDY #0
JSR HPOSN
LDA byte
LDY col
INY
STA (GBASL),Y
INY
LDA high
STA (GBASL),Y
INC byte
LDY row
INY
INY
STY row
CPY #$80
BNE @NextRow
LDY #0
LDX col
INX
INX
INX
INX
STX col
TXA
AND #$F
BNE @NextCol
LDA high
EOR #$80
BEQ @Done
STA high
LDY #0
BEQ @NextCol
@Done
RTS
[toc] | [prev] | [next] | [standalone]
| From | wssimms@gmail.com |
|---|---|
| Date | 2016-02-20 04:02 -0800 |
| Message-ID | <48c76c26-1eab-4227-ba0c-b8093dc7703a@googlegroups.com> |
| In reply to | #2310 |
Am Samstag, 20. Februar 2016 16:31:51 UTC+9 schrieb Michael Pohoreski: > Here's the actual assembly source that I used to generate the alt. source for the mini-assembler. > I'm pulling a Sheldon with no comments. :-) > > GBASL = $26 ; HGR pointer to cursor > GBASH = $27 > HPOSN = $F411 ; A=row, X=col.lo,Y=col.hi, sets GBASL, GBASH > HGR = $F3E2 If only you'd made it all lowercase, and gotten rid of these useless equates, it would be perfect.
[toc] | [prev] | [next] | [standalone]
| From | Michael Pohoreski <michael.pohoreski@gmail.com> |
|---|---|
| Date | 2016-02-20 11:40 -0800 |
| Message-ID | <f91f7217-0f4b-427a-b040-40fbfad658c7@googlegroups.com> |
| In reply to | #2314 |
On Saturday, February 20, 2016 at 4:02:07 AM UTC-8, wss...@gmail.com wrote: > Am Samstag, 20. Februar 2016 16:31:51 UTC+9 schrieb Michael Pohoreski: > > Here's the actual assembly source that I used to generate the alt. source for the mini-assembler. > > I'm pulling a Sheldon with no comments. :-) > > > > GBASL = $26 ; HGR pointer to cursor > > GBASH = $27 > > HPOSN = $F411 ; A=row, X=col.lo,Y=col.hi, sets GBASL, GBASH > > HGR = $F3E2 > > If only you'd made it all lowercase, and gotten rid of these useless equates, it would be perfect. There's always a comedian in every crowd. :-) Yup, that contains some left over crap that I should have deleted. i.e. GBASLH, saveX, saveY, etc. I've tried lowercase assembly on a few occasions. Just not my cup of tea due to SNR; I find it easy to "tune" out the uppercase so I can focus on the lowercase vars. If everything was lowercase it is much harder to read only the variables. i.e. everything becomes "noise". Hell most of the time I ignore the opcode mnemonics since it is so easy with uppercase.
[toc] | [prev] | [next] | [standalone]
| From | Michael Pohoreski <michael.pohoreski@gmail.com> |
|---|---|
| Date | 2016-02-20 11:48 -0800 |
| Message-ID | <ae76fc39-d25a-4de2-8d16-542251d44beb@googlegroups.com> |
| In reply to | #2314 |
On Saturday, February 20, 2016 at 4:02:07 AM UTC-8, wss...@gmail.com wrote:
> If only you'd made it all lowercase, and gotten rid of these useless equates, it would be perfect.
/snarky What, too lazy to select all & press **two** keys in Vim: U~ ? :-)
gbasl = $26 ; hgr pointer to cursor
hposn = $f411 ; a=row, x=col.lo,y=col.hi, sets gbasl, gbash
hgr = $f3e2
high = $fa
byte = $fb
col = $fc
row = $fd
jsr hgr
ldy #0
sty byte
sty col
sty high
@nextcol
sty row
@nextrow
tya
ldx col
ldy #0
jsr hposn
lda byte
ldy col
iny
sta (gbasl),y
iny
lda high
sta (gbasl),y
inc byte
ldy row
iny
iny
sty row
cpy #$80
bne @nextrow
ldy #0
ldx col
inx
inx
inx
inx
stx col
txa
and #$f
bne @nextcol
lda high
eor #$80
beq @done
sta high
ldy #0
beq @nextcol
@done
rts
[toc] | [prev] | [next] | [standalone]
| From | Mark Lemmert <mark.lemmert@gmail.com> |
|---|---|
| Date | 2016-02-20 08:10 -0800 |
| Message-ID | <12e54a16-4fc9-4f5e-90a2-d0f833b6792c@googlegroups.com> |
| In reply to | #2303 |
> This is getting interesting. I tried poking the values 0x00 - 0x0F into the the first 16 screen locations going down the left hand side of the screen in AppleWin, and there were some surprising (to me) results. > > Here is the resulting table: > > B=black, W=white, V=violet, G=green > Great observations! There many posters to this thread who know much more than I do about "why" things work the way they do (getting into hardware, frequencies etc). My respect to all of them for their knowledge and appreciation for sharing it. That said, I've accumulated some "general rules" that are fairly accurate for making sense of the various quirks, which I've used successfully to write complex graphics, including 4 frame animation, game "tile-based" graphics etc. I'm also still not sure what double byte mode is, so everything that follows is coming from the perspective of single byte mode (if that is the correct term). In case it helps, here are two that seems to relate to your observations: >3400:05 0-1-0-1 V-V-V-B **** V-B-V-B >2880:0A 1-0-1-0 B-G-G-G **** B-G-B-G The results you expected to the right of the asterisk are a 100% correct application of the rules in every graphics book I've read. The results to the left of the asterisks are exactly what I've expect to see based on the "undocumented" behavior I've seen in practice. In general, I've found that if two consecutive color columns have their pixels turned on, with the column between them left empty, the display result will be a three pixel color line. i.e. the pixel in that middle column is displayed as though it's turned on in binary and using the color of the adjacent pixels. If the pixel in the middle column on (111) would of course result in a 3 pixel white line. This very reliable, and it's the primary principle I follow to draw horizontal solid color lines. >2C80:0B 1-0-1-1 W-W-G-G **** W-W-B-G >3080:0C 1-1-0-0 B-B-W-W >3480:0D 1-1-0-1 V-V-W-W **** V-B-W-W This is also a very specific bit pattern that I've found to be useful as a general rule. Are you know, two or more adjacent horizontal pixels turned on result in white. If a color pixel is turned on with only one empty column between it and the white pixels, the empty column will be displayed as though it were turned on, using the same color as the as the color pixel that is turned on. I've found this to be fairly reliable, but have occasionally hit some exceptions when the graphics get complicated. But if you were to do a test with this pattern, in my experience you would see it regardless of where on the screen you did it.
[toc] | [prev] | [next] | [standalone]
| From | denisbytezone@gmail.com |
|---|---|
| Date | 2016-02-20 16:25 -0800 |
| Message-ID | <61b2d263-ab64-49a6-bd27-2e336cbf8772@googlegroups.com> |
| In reply to | #2316 |
> If a color pixel is turned on with only one empty column between it and the white pixels, the empty column will be displayed as though it were turned on, using the same color as the as the color pixel that is turned on. > > I've found this to be fairly reliable, but have occasionally hit some exceptions when the graphics get complicated. But if you were to do a test with this pattern, in my experience you would see it regardless of where on the screen you did it. Thanks for the information, I didn't realise it was going to be this weird. I have updated my DiskBrowser to handle these new 'rules', there is now a 'Colour Quirks' menu option so that you can toggle between the two display methods (using alt-Q). It's on GitHub now and should be available through homebrew fairly soon. I have an example of two screens posted here - https://www.dropbox.com/sh/tumzba618qh4hij/AACMDmLcMEO-TWgBJXcTNPEea?dl=0 It uses Michael's excellent ntsc.dsk. Are there any more of these quirks that I should know about? mjm suggested earlier that 10-12 surrounding pixels can affect any pixel.
[toc] | [prev] | [next] | [standalone]
| From | Michael Pohoreski <michael.pohoreski@gmail.com> |
|---|---|
| Date | 2016-02-20 16:37 -0800 |
| Message-ID | <46603f99-fde0-4080-bb51-31ef115f641e@googlegroups.com> |
| In reply to | #2324 |
On Saturday, February 20, 2016 at 4:25:11 PM UTC-8, denisb...@gmail.com wrote: > Are there any more of these quirks that I should know about? mjm suggested earlier that 10-12 surrounding pixels can affect any pixel. Technically the Apple //e can display 12-bit color = 4,096 colors. You'll probably be interested in this project that I ripped out of our sister project "AppleWin NTSC" https://github.com/Michaelangel007/hgr2rgbntsc I need to make another pass since I'm not happy with the accuracy of the colors, but it should be good enough to get started.
[toc] | [prev] | [next] | [standalone]
| From | Mark Lemmert <mark.lemmert@gmail.com> |
|---|---|
| Date | 2016-02-20 18:29 -0800 |
| Message-ID | <a7204633-4abd-4357-94a2-026bd3a4c113@googlegroups.com> |
| In reply to | #2324 |
>Thanks for the information, I didn't realise it was going to be this weird.
Welcome to the twilight zone of Apple II hi-res graphics :-)
The good news is, while it does take a little getting used to, it's not that bad once you do.
>Are there any more of these quirks that I should know about?
Another one is regarding adjacent vertical color lines. For example:
--------------------------
C0 C1 C2 C3 C4 C5 C6 C7
L0 b
L1 b
L2 b
L3 b
L4 b
L5 b
L6 b
(b = the pixels of a blue line, L = line, C = column or bit)
(extract of single hi-res screen, upper left corner)
Note that some of the earlier posts used a diagram which used the terminology color pixel. In the above example C0 & C2 would be color pixel #0, using that terminology.
the binary for line 1 and two would be:
10000001
10000100
As noted in prior posts, C7 and and the 1st column/bit in the next byte would together form a color pixel.
The above example has two adjacent vertical color lines. By this I mean there are two color vertical color lines that are as close together as two lines of the same color can be drawn, with only one empty column between them (column 0 and column 2 in this case, with column 1 being the empty column)
This type of bit pattern varies greatly in how it is rendered on in various emulators and displays. Here is a summary of what I've observed and compiled on this topic:
1) Virtual II Emulator (mac OS X) displays blue, and probably other colors, double wide, which makes the lines appear flush with no empty column between them.
2) AppleWIN 1.25.03 displays blue only in even columns as expected from the "rules" in the graphics books.
3) My physical Apple IIe's display (a modern flatscreen TV), connects blue lines with a smudged, slightly dimmer diagonal line. Sometimes.
I haven't fully quantified this yet, but I'm pretty sure it's location dependent. There are some posts earlier in this thread about what's going on at the hardware/frequency level.
4) I've heard reports that CRT TVs connected to physical Apple IIs display an empty column between the vertical blue lines but it's not as noticeable as it is on AppleWIN due to a little haze around the pixels. Lots of earlier posts about the hardware/frequency reasons for this.
Blue is used as an example but I'm pretty sure it applies to adjacent vertical lines of any color (I haven't tested them all, but have found no exceptions so far).
Conclusion:
The way I manage this quirkiness with the visual difference in vertical color lines on different emulators and displays, is to program to the lowest common denominator.
IMO the least visually appealing rendering above the above displays is AppleWIN (no offense intended to it's creators, I think it's a great program overall, very accessible to many users). So, when I test my graphics the first thing I do is make sure they look acceptable in AppleWIN. Periodically I test in other emulators and on my physical IIe, but generally I've found if it looks acceptable in AppleWIN it will look acceptable or better in the other environments mentioned above.
[toc] | [prev] | [next] | [standalone]
| From | gids.rs@sasktel.net |
|---|---|
| Date | 2016-02-20 20:00 -0800 |
| Message-ID | <88903293-8ad9-4031-9094-795fa8474f51@googlegroups.com> |
| In reply to | #2326 |
On Saturday, February 20, 2016 at 8:29:45 PM UTC-6, Mark Lemmert wrote: > >Thanks for the information, I didn't realise it was going to be this weird. > > Welcome to the twilight zone of Apple II hi-res graphics :-) > > The good news is, while it does take a little getting used to, it's not that bad once you do. > > > >Are there any more of these quirks that I should know about? > > Another one is regarding adjacent vertical color lines. For example: > > > -------------------------- > C0 C1 C2 C3 C4 C5 C6 C7 > L0 b > L1 b > L2 b > L3 b > L4 b > L5 b > L6 b > > (b = the pixels of a blue line, L = line, C = column or bit) > (extract of single hi-res screen, upper left corner) > > Note that some of the earlier posts used a diagram which used the terminology color pixel. In the above example C0 & C2 would be color pixel #0, using that terminology. This was not what was said at all in earlier posts. Please go back and read them more carefully. Your mis-understanding and mis-interpretation of the apple graphics screen is totally off the mark. And please stop calling bits, columns. This is very unprofessional in computer language.
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.sys.apple2.programmer
csiph-web