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 5 of 5 — ← Prev page 1 2 3 4 [5]

#3590

<anthonypaulo@gmail.com> wrote:
> On Friday, June 23, 2017 at 1:59:32 PM UTC-4, mjm...@aol.com wrote:
>> Mark Lemmert wrote:
>> Woz's primary motivation was to get maximum functionality from a minimal
>> number of chips. That design esthetic is clear in each of his designs. 
>> 
>> While one could wish for a simple XY matrix for graphics, it is a simple
>> transformation from XY to address, either a short code segment or a
>> less-than-a-page table. 
>> 
>> From the astounding number and variety of hi-res games and programs
>> produced, it's clear that the frame buffer organization didn't deprive the
>> platform of software!
>> 
>> Any serious developer easily abstracted from the physical organization. The
>> only real issue was the learning curve for less experienced coders, but
>> that likely had little effect on the commercial software market.
>> 
>> Similar arguments have been made for the amazingly elegant Disk ][
>> Controller, which put most of the disk I/O functionality in software, while
>> delivering excellent speed, capacity, and versatility. 
>> 
>> Both represent excellent engineering tradeoffs in market-leading products. 
>> 
>> -- 
>> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com
> 
> All true, and I do not wish to give the impression that I think Woz
> failed in any way as I really do understand his motivations and the state
> of the union way back when he designed the Apple II; what he managed to
> do in considerably less chips that the competition was truly genius. Now
> from what I understand, Woz was limited by his own budgetary constraints
> but was also guided by his wanting the Apple II to be affordable to the
> masses. As we all know, the Apple II wasn't really affordable to the
> masses in the same vein that the C64 would be, and at some point Markkula
> came in with the big bucks which made it possible to bring the Apple II
> out of the Homebrew Club and to the rest of the world. My question is,
> when the funding was secured and he became privy to the actual cost of
> the system vs the retail cost, I wonder if Woz would have done anything
> different given that the markup was considerable and he didn't have to
> pinch pennies anymore. It's all hypothetical of course but I'd love to
> ask him that if I ever get the chance.
> 

That would be interesting to know. 

But consider that the Apple ][ was designed to use dynamic RAM--an
aggressive design choice in 1975-1976--that greatly reduced the cost (and
chip count) of memory, but required constant refreshing. 

Virtually all other microcomputer designs dealt with this problem by "cycle
stealing" the refresh cycles in a manner similar to DMA. This not only
reduced the compute speed of the processor, it also destroyed the
deterministic timing of processor instructions. 

I'm sure you're aware of the many uses Apple ][ software made of
deterministic timing--DOS being perhaps the most obvious, but even the
"beep" would sound ratty with refresh interference. 

The 6502 has another delightful characteristic that made it possible to
directly display both text and graphics from the microprocessor's
memory--the 6502 only referenced memory on alternate "phases" of its
two-phase clock. This allows video refresh cycles to occur at 1MHz without
any interference with the processor. 

So it was a great idea to use the "don't care" order of the video buffer to
get DRAM refresh "free", without DMA-like complications or processor
interference. 

All the history I've read suggests that Woz' personal metric was
function/chip count, which is related to cost, but is not actually a cost
metric. 

This is yet another case where his puzzle-solving ability was challenged
and triumphed. ;-)

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

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

#3577

On 6/22/2017 8:19 PM, anthonypaulo@gmail.com wrote:
< much snipped >

> I am finally learning the quirks of Apple II hi-res graphics due to this thread. I wonder if it was really worth having this crazy graphics scheme with all its quirks and limitations and headache to developers just to save a few bucks in chips given the huge profit margin on the Apple ][. Hindsight is indeed 20/20, but I wonder if Woz would do things a bit differently if he had known how high the markup was going to be. For example, if I knew that I would be making, say, $500 profit on a $1000 computer of my own design, I would gladly give up $50 or $100 of that profit in order to ensure that my graphics mode was the best there was and easy to program compared to any of my competitors (Commodore, Atari, IBM, Tandy, etc...). After all, a better graphics mode that's easier to program means more developers for the system (ease of use), faster development times, more programs, more sales, and ultimately more money in my pocket. Perhaps I'm simplifying things but I've always been curio
us about whether the trade-off was really worth it and how things would have turned out if they had not skimped on the graphics.

When the Apple II graphics were introduced (1977), I believe the 
competitors you mentioned were behind in theirs. Commodore (PET) had no 
hi-res graphics, Atari (400/800) was still a couple years from 
introduction, IBM (PC) was four years away and needed an add on (CGA) 
card and Tandy (TRS-80) had no hi-res graphics.

Charlie

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

#3586

On Friday, June 23, 2017 at 8:23:59 AM UTC-7, Charlie wrote:
> When the Apple II graphics were introduced (1977), I believe the 
> competitors you mentioned were behind in theirs. 

Interesting, I didn't realize that Apple was really THAT far ahead of the competition and "first to market" -- what a difference of even a year made !


Sinclair ZX-81,  March 1981, no high resolution graphics
Vic-20 June 1983
C64 Aug 1982

Considering the Apple 2 had High Resolution Graphics back in 1977 ... WITH page flipping (!!) is really even MORE impressive.


> Tandy (TRS-80) had no NATIVE hi-res graphics. 

FTFY.

There were tons of add-ons providing hi-res graphics
http://www.trs-80.org/high-resolution-graphics-for-the-trs-80/

Radio Shack even sold one that had 640x200 monochrome, on December 30, 1982
http://www.trs-80.org/radio-shack-model-iii-high-resolution-board/

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

#3588

On Sunday, June 25, 2017 at 10:45:50 AM UTC-4, Michael Pohoreski wrote:
> On Friday, June 23, 2017 at 8:23:59 AM UTC-7, Charlie wrote:
> > When the Apple II graphics were introduced (1977), I believe the 
> > competitors you mentioned were behind in theirs. 
> 
> Interesting, I didn't realize that Apple was really THAT far ahead of the competition and "first to market" -- what a difference of even a year made !
> 
> 
> Sinclair ZX-81,  March 1981, no high resolution graphics
> Vic-20 June 1983
> C64 Aug 1982
> 
> Considering the Apple 2 had High Resolution Graphics back in 1977 ... WITH page flipping (!!) is really even MORE impressive.
> 
> 
> > Tandy (TRS-80) had no NATIVE hi-res graphics. 
> 
> FTFY.
> 
> There were tons of add-ons providing hi-res graphics
> http://www.trs-80.org/high-resolution-graphics-for-the-trs-80/
> 
> Radio Shack even sold one that had 640x200 monochrome, on December 30, 1982
> http://www.trs-80.org/radio-shack-model-iii-high-resolution-board/

I didn't realize this either... quite amazing indeed! Given what Woz was able to do with so few chips, I wonder what he would have done with a few more buck in his pocket... like, if he had Mike Markkula's funding from the start!

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

#3589

On Sunday, June 25, 2017 at 11:33:01 AM UTC-4, anthon...@gmail.com wrote:
> I didn't realize this either... quite amazing indeed! Given what Woz was able to do with so few chips, I wonder what he would have done with a few more buck in his pocket... like, if he had Mike Markkula's funding from the start!

But then again, necessity is the mother of all invention so who knows...

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

#3591

On Sunday, June 25, 2017 at 8:33:01 AM UTC-7, anthon...@gmail.com wrote:
> On Sunday, June 25, 2017 at 10:45:50 AM UTC-4, Michael Pohoreski wrote:
> > On Friday, June 23, 2017 at 8:23:59 AM UTC-7, Charlie wrote:
> > > When the Apple II graphics were introduced (1977), I believe the 
> > > competitors you mentioned were behind in theirs. 
> > 
> > Interesting, I didn't realize that Apple was really THAT far ahead of the competition and "first to market" -- what a difference of even a year made !
> > 
> > 
> > Sinclair ZX-81,  March 1981, no high resolution graphics
> > Vic-20 June 1983
> > C64 Aug 1982
> > 
> > Considering the Apple 2 had High Resolution Graphics back in 1977 ... WITH page flipping (!!) is really even MORE impressive.
> > 
> > 
> > > Tandy (TRS-80) had no NATIVE hi-res graphics. 
> > 
> > FTFY.
> > 
> > There were tons of add-ons providing hi-res graphics
> > http://www.trs-80.org/high-resolution-graphics-for-the-trs-80/
> > 
> > Radio Shack even sold one that had 640x200 monochrome, on December 30, 1982
> > http://www.trs-80.org/radio-shack-model-iii-high-resolution-board/
> 
> I didn't realize this either... quite amazing indeed! Given what Woz was able to do with so few chips, I wonder what he would have done with a few more buck in his pocket... like, if he had Mike Markkula's funding from the start!

I think the Apple II was the perfect design for the time. Now the follow-on is another discussion. What if they had decided to design the Apple III as an improved II with both business and home in mind? Like a IIIgs in 1980.

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

#3593

On Sunday, June 25, 2017 at 3:07:59 PM UTC-4, David Schmenk wrote:
> On Sunday, June 25, 2017 at 8:33:01 AM UTC-7, anthon...@gmail.com wrote:
> > On Sunday, June 25, 2017 at 10:45:50 AM UTC-4, Michael Pohoreski wrote:
> > > On Friday, June 23, 2017 at 8:23:59 AM UTC-7, Charlie wrote:
> > > > When the Apple II graphics were introduced (1977), I believe the 
> > > > competitors you mentioned were behind in theirs. 
> > > 
> > > Interesting, I didn't realize that Apple was really THAT far ahead of the competition and "first to market" -- what a difference of even a year made !
> > > 
> > > 
> > > Sinclair ZX-81,  March 1981, no high resolution graphics
> > > Vic-20 June 1983
> > > C64 Aug 1982
> > > 
> > > Considering the Apple 2 had High Resolution Graphics back in 1977 ... WITH page flipping (!!) is really even MORE impressive.
> > > 
> > > 
> > > > Tandy (TRS-80) had no NATIVE hi-res graphics. 
> > > 
> > > FTFY.
> > > 
> > > There were tons of add-ons providing hi-res graphics
> > > http://www.trs-80.org/high-resolution-graphics-for-the-trs-80/
> > > 
> > > Radio Shack even sold one that had 640x200 monochrome, on December 30, 1982
> > > http://www.trs-80.org/radio-shack-model-iii-high-resolution-board/
> > 
> > I didn't realize this either... quite amazing indeed! Given what Woz was able to do with so few chips, I wonder what he would have done with a few more buck in his pocket... like, if he had Mike Markkula's funding from the start!
> 
> I think the Apple II was the perfect design for the time. Now the follow-on is another discussion. What if they had decided to design the Apple III as an improved II with both business and home in mind? Like a IIIgs in 1980.

You know, I wondered the same about the Lisa/Mac as well. When the Mac classic came out, the only thing it seemed to have over the Apple IIgs was the 68K processor which I hear was very well designed; however, the Mac OS was so slow that it overburdened the cpu, making any speed gains negligible. The IIgs had pretty much everything the Mac didn't have : a huge existing software library, backwards compatibility with the Apple II, color graphics, ensoniq sound, memory, expansion, etc... The IIgs also had geos (in color!) and would have been much faster had it not been intentionally hobbled so it wouldn't compete with the Mac. I always wondered what would have happened if Apple had instead poured all of their resources into making the Apple II a "Mac" instead of wasting so much money on the III, Lisa, and 68K Mac. I believe the MOS 6502 based design was a dead-end so the choice of the 68K seems reasonable, but surely something could have been done to build on the II rather than scrap it entirely. Any thoughts?

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

#2306

<denisbytezone@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 :)
> 

It's two white pixels. 

Two consecutive one bits produce *no* 3.58MHz frequency component, and
therefore no chroma signal. Since there two consecutive one bits produce
only one pulse, two pixels wide, there is only a two-pixel wide white
"dash", not two separate dots. 

Color in Apple II video is *entirely* a consequence of how an analog NTSC
monitor interprets the binary video bit stream. The luminance is determined
by the number of one bits in a "pixel group" (2 bits for HGR, 4 bits for
DHGR), the hue is determined by the phase of the 3.58MHz component of the
bit stream, and the saturation by the amplitude of the 3.58MHz component. 

There truly are no "colored pixels", only a monitor's interpretation of the
video bit stream as an analog composite video signal. If that signal
contains a color burst on the "back porch" of the horizontal blanking
pulse, the monitor will interpret any 3.58MHz frequency component in the
video as a chroma subcarrier and display colors. 

If it's what you intended, it's called color graphics, if not, it's called
"fringing" or "artifacts". ;-)

If you really want to understand, you need to study how NTSC video is
encoded/decoded, including the bandpass limitations on the luminance and
chrominance signals. Without that understanding, Apple II color just seems
"approximate" (which is good enough for pie charts, but insufficient for
subtle artistic effects. 

For example, the actual color displayed by an NTSC monitor depends on at
least 10-12 bits surrounding the "pixel". 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

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

#2308

> 
> If you really want to understand, you need to study how NTSC video is
> encoded/decoded, including the bandpass limitations on the luminance and
> chrominance signals. Without that understanding, Apple II color just seems
> "approximate" (which is good enough for pie charts, but insufficient for
> subtle artistic effects. 
> 
> For example, the actual color displayed by an NTSC monitor depends on at
> least 10-12 bits surrounding the "pixel". 
> 

Very interesting, thank you. Bizarre, but interesting.

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

#2406

On Monday, February 15, 2016 at 11:40:12 AM UTC-8, Mark Lemmert wrote:
> For example, the following screen shots from Ultima V:

OK, you guys will enjoy this!

Dealing with Real Life (TM) crap this week BUT (as promised) I managed to take a few "high resolution pictures" on **actual** hardware.  I used ADTPro to transfer my u5 test image DSK to a real floppy and boot that.


= Hardware =
Camera: Digital Rebel T5 + 18-55mm Lens (stock)
Monitor1: Apple //e + Apple Color Composite Monitor (left of CameraTrax color chart)
Monitor2: Apple //c + Franklin Composite Monitor (right of CameraTrax color chart)

Pictures are not as "in focus" as I would prefer but I tried with and without auto-focus. Due to lack of time I figured some pictures are better then no pictures. :-)

I've included both the file size and image resolution so you know beforehand what you're downloading in-case anyone is not on broadband.

= Pics =
Pic1: Apple Composite (Left) vs Franklin Composite (Right)
Size: 9.5 MB
Res: 5100x2100 (cropped)
http://michael.peopleofhonoronly.com/dev/applewin/u5/u5_a_5100x2100_apple_composite_vs_franklin_composite_0960.png

Pic 2: Apple Composite
Size: 17.5 MB
Res: 5184x3456
http://michael.peopleofhonoronly.com/dev/applewin/u5/u5_b_5184x3456_apple_composite_0969.png

Pic 3: Franklin Composite
Size: 16.9 MB
Res: 5184x3456
http://michael.peopleofhonoronly.com/dev/applewin/u5/u5_c_5184x3456_franklin_composite_0970.png

Pic 4: Zoomed in right border edge Apple Composite (cropped)
Size: 2.6 MB
Res: 2324x1796
http://michael.peopleofhonoronly.com/dev/applewin/u5/u5_zoom_apple_composite_0984.png

= Notes =
A. The Franklin Color Composite monitor doesn't show the same hard on-off color pattern that the Apple Color Composite monitor does. Colors look solid.  You could say this does a better job of displaying a composite signal but the I prefer the Apple Color Composite "poor" signal reconstruction since it better matches the monochrome experience and "nostalgia" / "authenticity".

B. My Apple Color Composite monitor has (really) bad color "bleeding". Namely:

i) Pic #4 shows the green trees on the right edge bleeding into the inside white border.  I didn't provide a zoomed-in shot of the Franklin Color Composite monitor because while technically the bleed is there, it is hardly noticeable.  If you zoom in on the full-size image you'll see a very fain green tint of the white border.

ii) Pure white has bad chroma smearing.  This is most noticeable in the "V" in the title.  The Franklin monitor has better convergence.  Colors are kept sharp and tight.


I'm looking to pick up another **two more** Apple Color Composite Monitors later this year to have a large sample size so I can track down if my monitor has simply bad convergence or if all the Apple Color Composite Monitors behave the same way.

C. Each HGR "pixel" takes up # slots in the shadow mask.

Apple: 5 slots
Franklin: 4 slots

This means emulators need an effective resolution of 280*5*2 = 2240 horizontal resolution to accurate emulate the shadow mask of the AppleColor Composite Monitor IIe. A 2Kp monitor (4K sic.) has a resolution of 3840x2160 which means I can finally achieve my dream of having a proper CRT emulation on my 2Kp monitor. :-)
https://en.wikipedia.org/wiki/ColorMonitor_IIe/AppleColor_Composite_Monitor_IIe

D. Ignore the "Venetian Blinds" in the top right Franklin Composite monitor picture.  I didn't have time to block them out.


You can find the full list of files here:
http://michael.peopleofhonoronly.com/dev/applewin/u5/

Enjoy!

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

#2412

Michael Pohoreski <michael.pohoreski@gmail.com> wrote:
> On Monday, February 15, 2016 at 11:40:12 AM UTC-8, Mark Lemmert wrote:
>> For example, the following screen shots from Ultima V:
> 
> OK, you guys will enjoy this!
> 
> Dealing with Real Life (TM) crap this week BUT (as promised) I managed to
> take a few "high resolution pictures" on **actual** hardware.  I used
> ADTPro to transfer my u5 test image DSK to a real floppy and boot that.
> 
> 
> = Hardware Camera: Digital Rebel T5 + 18-55mm Lens (stock)
> Monitor1: Apple //e + Apple Color Composite Monitor (left of CameraTrax color chart)
> Monitor2: Apple //c + Franklin Composite Monitor (right of CameraTrax color chart)
> 
> Pictures are not as "in focus" as I would prefer but I tried with and
> without auto-focus. Due to lack of time I figured some pictures are
> better then no pictures. :-)
> 
> I've included both the file size and image resolution so you know
> beforehand what you're downloading in-case anyone is not on broadband.
> 
> = Pics Pic1: Apple Composite (Left) vs Franklin Composite (Right)
> Size: 9.5 MB
> Res: 5100x2100 (cropped)
> http://michael.peopleofhonoronly.com/dev/applewin/u5/u5_a_5100x2100_apple_composite_vs_franklin_composite_0960.png
> 
> Pic 2: Apple Composite
> Size: 17.5 MB
> Res: 5184x3456
> http://michael.peopleofhonoronly.com/dev/applewin/u5/u5_b_5184x3456_apple_composite_0969.png
> 
> Pic 3: Franklin Composite
> Size: 16.9 MB
> Res: 5184x3456
> http://michael.peopleofhonoronly.com/dev/applewin/u5/u5_c_5184x3456_franklin_composite_0970.png
> 
> Pic 4: Zoomed in right border edge Apple Composite (cropped)
> Size: 2.6 MB
> Res: 2324x1796
> http://michael.peopleofhonoronly.com/dev/applewin/u5/u5_zoom_apple_composite_0984.png
> 
> = Notes A. The Franklin Color Composite monitor doesn't show the same
> hard on-off color pattern that the Apple Color Composite monitor does.
> Colors look solid.  You could say this does a better job of displaying a
> composite signal but the I prefer the Apple Color Composite "poor" signal
> reconstruction since it better matches the monochrome experience and
> "nostalgia" / "authenticity".

The AppleColor Composite monitor has higher than normal (for NTSC TVs)
luminance bandwidth, so the pixel "edges" are sharper and the amplitude of
isolated pixels is higher, so a "dottier" image.

The 10+MHz luminance is needed for 80-column text, but is reduced for color
graphics--just not as low as the typical 3MHz for ordinary NTSC monitors. 

If you could only afford a color TV, the Franklin looks more like what
you're used to. 

> B. My Apple Color Composite monitor has (really) bad color "bleeding". Namely:
> 
> i) Pic #4 shows the green trees on the right edge bleeding into the
> inside white border.  I didn't provide a zoomed-in shot of the Franklin
> Color Composite monitor because while technically the bleed is there, it
> is hardly noticeable.  If you zoom in on the full-size image you'll see a
> very fain green tint of the white border.

This "bleeding" isn't bleeding in the sense that the earlier green pixels
are bleeding into the white. It is the result of the white being "white1"
(color set high bit off) since it is in the same byte with green pixels. 

Put another way, even if the green pixels were black, the white border
would still show some green artifact. If the pair of white pixels were
moved one pixel to the left, it would show a purple artifact. Note that the
other parts of the border show an orange artifact, since they are "white2"
(color set high bit on).

> ii) Pure white has bad chroma smearing.  This is most noticeable in the
> "V" in the title.  The Franklin monitor has better convergence.  Colors
> are kept sharp and tight.

I think you are seeing the difference in adjustment of the two monitors. 

The color balance of both monitors is a little off. The Apple monitor has
too much green gain/background, while the Franklin has too much blue. 

Both monitors look pretty well converged:  solid colors are pretty pure
wherever they appear on the screen. I think most of the differences are the
result of different level/gain/bandwidth in the color channels of the two
monitors.

Analog color monitors are pretty bad at "absolute" color, because of many
variations in phosphors, channel gammas, gains, background levels, and even
surrounding lighting. They depend greatly on the huge adaptability of the
human color vision system to produce an acceptable color perception in the
face of significant objective variations. (Many of these variables also
apply to modern digital monitors, but the range of variations is reduced.)

> I'm looking to pick up another **two more** Apple Color Composite
> Monitors later this year to have a large sample size so I can track down
> if my monitor has simply bad convergence or if all the Apple Color
> Composite Monitors behave the same way.

The comparison will be interesting. 

> C. Each HGR "pixel" takes up # slots in the shadow mask.
> 
> Apple: 5 slots
> Franklin: 4 slots
> 
> This means emulators need an effective resolution of 280*5*2 = 2240
> horizontal resolution to accurate emulate the shadow mask of the
> AppleColor Composite Monitor IIe. A 2Kp monitor (4K sic.) has a
> resolution of 3840x2160 which means I can finally achieve my dream of
> having a proper CRT emulation on my 2Kp monitor. :-)
> https://en.wikipedia.org/wiki/ColorMonitor_IIe/AppleColor_Composite_Monitor_IIe

Wow--since monitors were intended to be viewed from a distance that
rendered the shadow mask all but invisible, this kind of "fidelity" hardly
seems to contribute to user enjoyment. ;-)  (I have the same issue with
emulating geometric distortions, like pincushioning.)

> D. Ignore the "Venetian Blinds" in the top right Franklin Composite
> monitor picture.  I didn't have time to block them out.

No!  They should be there for the full authentic experience!!  ;-)

> You can find the full list of files here:
> http://michael.peopleofhonoronly.com/dev/applewin/u5/
> 
> Enjoy!

Thank you for making the effort to allow this comparison--and to show the
NTSC palette subtleties exploited by Ultima's graphic artists. 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

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

#2419

On Tuesday, March 1, 2016 at 1:48:37 PM UTC-6, Michael Pohoreski wrote:
> Dealing with Real Life (TM) crap this week BUT (as promised) I managed to take a few "high resolution pictures" on **actual** hardware.  I used ADTPro to transfer my u5 test image DSK to a real floppy and boot that.
> 
> 
> = Hardware =
> Camera: Digital Rebel T5 + 18-55mm Lens (stock)
> Monitor1: Apple //e + Apple Color Composite Monitor (left of CameraTrax color chart)
> Monitor2: Apple //c + Franklin Composite Monitor (right of CameraTrax color chart)
> 
> Pictures are not as "in focus" as I would prefer but I tried with and without auto-focus. Due to lack of time I figured some pictures are better then no pictures. :-)
> 
> I've included both the file size and image resolution so you know beforehand what you're downloading in-case anyone is not on broadband.
> 
> = Pics =
> Pic1: Apple Composite (Left) vs Franklin Composite (Right)
> Size: 9.5 MB
> Res: 5100x2100 (cropped)
> http://michael.peopleofhonoronly.com/dev/applewin/u5/u5_a_5100x2100_apple_composite_vs_franklin_composite_0960.png
> 
> Pic 2: Apple Composite
> Size: 17.5 MB
> Res: 5184x3456
> http://michael.peopleofhonoronly.com/dev/applewin/u5/u5_b_5184x3456_apple_composite_0969.png
> 
> Pic 3: Franklin Composite
> Size: 16.9 MB
> Res: 5184x3456
> http://michael.peopleofhonoronly.com/dev/applewin/u5/u5_c_5184x3456_franklin_composite_0970.png
> 
> Pic 4: Zoomed in right border edge Apple Composite (cropped)
> Size: 2.6 MB
> Res: 2324x1796
> http://michael.peopleofhonoronly.com/dev/applewin/u5/u5_zoom_apple_composite_0984.png
> 
> = Notes =
> A. The Franklin Color Composite monitor doesn't show the same hard on-off color pattern that the Apple Color Composite monitor does. Colors look solid.  You could say this does a better job of displaying a composite signal but the I prefer the Apple Color Composite "poor" signal reconstruction since it better matches the monochrome experience and "nostalgia" / "authenticity".
> 

Michael,

That's very interesting, thanks for posting! I also prefer the Apple Color Composite rendering.

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

#2668

On Wednesday, March 2, 2016 at 12:05:15 PM UTC-6, Mark Lemmert wrote:
> On Tuesday, March 1, 2016 at 1:48:37 PM UTC-6, Michael Pohoreski wrote:
> > Dealing with Real Life (TM) crap this week BUT (as promised) I managed to take a few "high resolution pictures" on **actual** hardware.  I used ADTPro to transfer my u5 test image DSK to a real floppy and boot that.
> > 
> > 
> > = Hardware =
> > Camera: Digital Rebel T5 + 18-55mm Lens (stock)
> > Monitor1: Apple //e + Apple Color Composite Monitor (left of CameraTrax color chart)
> > Monitor2: Apple //c + Franklin Composite Monitor (right of CameraTrax color chart)
> > 
> > Pictures are not as "in focus" as I would prefer but I tried with and without auto-focus. Due to lack of time I figured some pictures are better then no pictures. :-)
> > 
> > I've included both the file size and image resolution so you know beforehand what you're downloading in-case anyone is not on broadband.
> > 
> > = Pics =
> > Pic1: Apple Composite (Left) vs Franklin Composite (Right)
> > Size: 9.5 MB
> > Res: 5100x2100 (cropped)
> > http://michael.peopleofhonoronly.com/dev/applewin/u5/u5_a_5100x2100_apple_composite_vs_franklin_composite_0960.png
> > 
> > Pic 2: Apple Composite
> > Size: 17.5 MB
> > Res: 5184x3456
> > http://michael.peopleofhonoronly.com/dev/applewin/u5/u5_b_5184x3456_apple_composite_0969.png
> > 
> > Pic 3: Franklin Composite
> > Size: 16.9 MB
> > Res: 5184x3456
> > http://michael.peopleofhonoronly.com/dev/applewin/u5/u5_c_5184x3456_franklin_composite_0970.png
> > 
> > Pic 4: Zoomed in right border edge Apple Composite (cropped)
> > Size: 2.6 MB
> > Res: 2324x1796
> > http://michael.peopleofhonoronly.com/dev/applewin/u5/u5_zoom_apple_composite_0984.png
> > 
> > = Notes =
> > A. The Franklin Color Composite monitor doesn't show the same hard on-off color pattern that the Apple Color Composite monitor does. Colors look solid.  You could say this does a better job of displaying a composite signal but the I prefer the Apple Color Composite "poor" signal reconstruction since it better matches the monochrome experience and "nostalgia" / "authenticity".
> > 
> 
> Michael,
> 
> That's very interesting, thanks for posting! I also prefer the Apple Color Composite rendering.

I know I'm "late to the party" on this one.  But, I was also going through learning hi-res graphics as part of getting back into retro-programming.  And struggled with it, as well.  I documented and am continuing to document what I'm learning on my journey on my (newish) blog.

Here is a post that shows the some examples of setting certain bits in a byte and how it affects the color, if it's helpful to anyone.

http://retro2neo.org/2016/03/18/apple-hi-res-graphics-learning-the-screen/

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

#2669

On Wednesday, April 6, 2016 at 1:21:56 PM UTC-7, Michael Finger wrote:

"One does not simply Bit-Shift an Apple ][ bitmap"

LOL !

Nice series!

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

#2672

On Wednesday, April 6, 2016 at 2:21:56 PM UTC-6, Michael Finger wrote:
> On Wednesday, March 2, 2016 at 12:05:15 PM UTC-6, Mark Lemmert wrote:
> > On Tuesday, March 1, 2016 at 1:48:37 PM UTC-6, Michael Pohoreski wrote:
> > > Dealing with Real Life (TM) crap this week BUT (as promised) I managed to take a few "high resolution pictures" on **actual** hardware.  I used ADTPro to transfer my u5 test image DSK to a real floppy and boot that.
> > > 
> > > 
> > > = Hardware =
> > > Camera: Digital Rebel T5 + 18-55mm Lens (stock)
> > > Monitor1: Apple //e + Apple Color Composite Monitor (left of CameraTrax color chart)
> > > Monitor2: Apple //c + Franklin Composite Monitor (right of CameraTrax color chart)
> > > 
> > > Pictures are not as "in focus" as I would prefer but I tried with and without auto-focus. Due to lack of time I figured some pictures are better then no pictures. :-)
> > > 
> > > I've included both the file size and image resolution so you know beforehand what you're downloading in-case anyone is not on broadband.
> > > 
> > > = Pics =
> > > Pic1: Apple Composite (Left) vs Franklin Composite (Right)
> > > Size: 9.5 MB
> > > Res: 5100x2100 (cropped)
> > > http://michael.peopleofhonoronly.com/dev/applewin/u5/u5_a_5100x2100_apple_composite_vs_franklin_composite_0960.png
> > > 
> > > Pic 2: Apple Composite
> > > Size: 17.5 MB
> > > Res: 5184x3456
> > > http://michael.peopleofhonoronly.com/dev/applewin/u5/u5_b_5184x3456_apple_composite_0969.png
> > > 
> > > Pic 3: Franklin Composite
> > > Size: 16.9 MB
> > > Res: 5184x3456
> > > http://michael.peopleofhonoronly.com/dev/applewin/u5/u5_c_5184x3456_franklin_composite_0970.png
> > > 
> > > Pic 4: Zoomed in right border edge Apple Composite (cropped)
> > > Size: 2.6 MB
> > > Res: 2324x1796
> > > http://michael.peopleofhonoronly.com/dev/applewin/u5/u5_zoom_apple_composite_0984.png
> > > 
> > > = Notes =
> > > A. The Franklin Color Composite monitor doesn't show the same hard on-off color pattern that the Apple Color Composite monitor does. Colors look solid.  You could say this does a better job of displaying a composite signal but the I prefer the Apple Color Composite "poor" signal reconstruction since it better matches the monochrome experience and "nostalgia" / "authenticity".
> > > 
> > 
> > Michael,
> > 
> > That's very interesting, thanks for posting! I also prefer the Apple Color Composite rendering.
> 
> I know I'm "late to the party" on this one.  But, I was also going through learning hi-res graphics as part of getting back into retro-programming.  And struggled with it, as well.  I documented and am continuing to document what I'm learning on my journey on my (newish) blog.
> 
> Here is a post that shows the some examples of setting certain bits in a byte and how it affects the color, if it's helpful to anyone.
> 
> http://retro2neo.org/2016/03/18/apple-hi-res-graphics-learning-the-screen/


It surprises me that no one can grasp the idea that the bits come in pairs to set a certain color.  And also that certain colors can not show up beside one another and, others can, but only in the byte next to it.

It is not about setting a bit in an even column or odd column and you get this color.

I think I have found an example that might demonstrate this better.

First it would be easier to understand if we flipped the byte.  But only on paper.  So instead of the bits having values of $80-$40-$20-$10-8-4-2-1, with the byte flipped we have  1-2-4-8-$10-$20-$40-$80.  The math will go so much easier.

Put another way
bit #1 has the value 1
bit #2 has the value 2
bit #3 has the value 4
bit #4 has the value 8
bit #5 has the value $10 - if you don't know hexadecimal, 8 + 8 = $10
bit #6 has the value $20
bit #7 has the value $40
bit #8 has the value $80

sometimes the bits are labeled as 0 to 7, but I find 1 to 8 is easier to understand due to the values 1,2 & 8 having the values 1,2 & $80

type TEXT at the prompt to get the cursor to the bottom of the screen
type HGR at the prompt
then CALL -151
each command is followed by pressing the RETURN key

I know this is obvious to most programmers, but for someone new, it may help them.

we will only deal with the first 4 pixels but remember it takes 2 pixels to make a color.  And 2 consecutive on bits will always show a white pixel whether they are part of the pair of bits that makes the color, or the bits are on next to each other with the next pair of bits.  This will make more sense in the examples.

The first 4 bits have the values 1-2-4-8 for a total of $F, and the hi-bit of each byte will toggle another color palette.

To see how the colors are displayed when a pair of bits are turned on and off, type in these values.

2000:0     - bits #1 and #2 are both off (you see black)
2000:80    - still black, these are sometimes known as black1 and black2
2000:1     - bit #1 is on, bit #2 is off (you see green)
2000:81    - bit #1 is on, bit #2 is off (you see orange)
2000:2     - bit #1 is off, bit #2 is on (you see violet)
2000:82    - bit #1 is off, bit #2 is on (you see blue)
2000:3     - bits #1 and #2 are both on (you see white)
2000:83    - still white, and are sometimes known as white1 and white2


Now, hopefully this will all come clear as to which colors can be beside each other as we turn on the next pair of bits.

2000:0
2000:80
2000:5  (turning on bits 1,3,5 & 7) will make a longer green line)
2000:85 (with the color bit set these same bits will make an orange line)
2000:6  (turning on bits 2,4,6) will make a longer violet line)
2000:86 (with the color bit set these same bits will make a blue line)


So far we have only shown alternating bits.  But now see what happens when bits are turned when next to each other. a zero mean bits are off, and a 1 means bits are on.

0000 (0)- bits 1-4 are off = 0 - this is black
1001 (9)- this is a violet pixel then a green pixel
0110 (6)- this cannot display a green pixel with a violet pixel, so you will see a white pixel
1111 - ($F) this is 2 white pixels next to each other.

and with the color bit set ($80) will use the 2nd palette of colors (blue/orange)

the values are in parenthesis, so lets punch these in

2000:9   - this will show a violet pixel then a green pixel
2000:6   - cannot display green/violet, shows up as white
2000:F   - white1
2000:89  - this will show an orange pixel then a blue pixel
2000:86  - cannot display blue/orange, shows up as white
2000:8F  - white2


I will stop here.  If there is any more interest in how I interpret the bit-pairs to display color, I will follow up with a description of the third pixel which shares an odd and even byte to make its color.

Plus how to get a violet/green color beside a blue/orange color.

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

#3584

> I will stop here.  If there is any more interest in how I interpret the bit-pairs to display color, 
> I will follow up with a description of the third pixel which shares an odd and even byte to make its color. 
> Plus how to get a violet/green color beside a blue/orange color. 

Rob, fantastic write-up.

Don't leave us hanging -- post the followup ! :-) 
It never hurts to review fundamentals.

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

#3594

On Sunday, June 25, 2017 at 7:17:35 AM UTC-6, Michael Pohoreski wrote:
> > I will stop here.  If there is any more interest in how I interpret the bit-pairs to display color, 
> > I will follow up with a description of the third pixel which shares an odd and even byte to make its color. 
> > Plus how to get a violet/green color beside a blue/orange color. 
> 
> Rob, fantastic write-up.
> 
> Don't leave us hanging -- post the followup ! :-) 
> It never hurts to review fundamentals.


You do realize that was over a year ago, and I kind of lost my train of thought  :)

Also summer is not the best time for me to do long write-ups.  It may have to wait til winter.

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

#3595

On Sunday, June 25, 2017 at 9:33:44 PM UTC-7, gid...@sasktel.net wrote:
> You do realize that was over a year ago, and I kind of lost my train of thought  :)

Yes. :-/
And Yes. :-(
 
> Also summer is not the best time for me to do long write-ups.  It may have to wait til winter.

No prob.

[toc] | [prev] | [standalone]

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

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

csiph-web