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 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Mark Lemmert <mark.lemmert@gmail.com> |
|---|---|
| Date | 2016-02-20 20:53 -0800 |
| Message-ID | <df41d156-e664-40d0-9f29-ac57dcc5687f@googlegroups.com> |
| In reply to | #2327 |
>And please stop calling bits, columns. This is very unprofessional in computer >language. Clearly you are very knowledgable about the deep workings of Apple graphics, and I totally respect that. And, thank you for the opportunity to explain my posting. I feel like there are two different sets of terminology being in this thread at times and have been puzzled as to the reason why. Here is my perspective: Many graphics books refer to bits as a columns, especially when explaining how the color bit works. Example: Apple II Reference Manual (1979, white cover), page 19, bottom of the page. https://www.dropbox.com/s/wu9u2ksij911zou/Screen%20Shot%202016-02-20%20at%2010.23.31%20PM.png?dl=0 I'm not trying to say you are wrong by referencing the books, I'll take your word for it that there are programmers who consider the term column unprofessional. I didn't know that, and thank you for sharing it. The reason I use the term column is because there are people out there (me being one of them) who learn from books, and then try to refine that knowledge experimentation and asking questions. It is much easier to learn when the terminology in the book can be used as a point of reference. >This was not what was said at all in earlier posts. Please go back and read them >more carefully. Duly noted. I thought that I understood how the information you shared relates to the way graphics are explained in many books, but apparently not. Aside from that, I believe my posting was accurate in all other respects in terms of what will display on the screen in the circumstances I described.
[toc] | [prev] | [next] | [standalone]
| From | gids.rs@sasktel.net |
|---|---|
| Date | 2016-02-20 23:11 -0800 |
| Message-ID | <4fccb972-ff46-46f0-bc87-8ac47595a91e@googlegroups.com> |
| In reply to | #2329 |
On Saturday, February 20, 2016 at 10:53:43 PM UTC-6, Mark Lemmert wrote: > >And please stop calling bits, columns. This is very unprofessional in computer >language. > > > Clearly you are very knowledgable about the deep workings of Apple graphics, and I totally respect that. > > And, thank you for the opportunity to explain my posting. I feel like there are two different sets of terminology being in this thread at times and have been puzzled as to the reason why. > > Here is my perspective: > > Many graphics books refer to bits as a columns, especially when explaining how the color bit works. > > Example: Apple II Reference Manual (1979, white cover), page 19, bottom of the page. > > https://www.dropbox.com/s/wu9u2ksij911zou/Screen%20Shot%202016-02-20%20at%2010.23.31%20PM.png?dl=0 > > > I'm not trying to say you are wrong by referencing the books, I'll take your word for it that there are programmers who consider the term column unprofessional. I didn't know that, and thank you for sharing it. > > The reason I use the term column is because there are people out there (me being one of them) who learn from books, and then try to refine that knowledge experimentation and asking questions. It is much easier to learn when the terminology in the book can be used as a point of reference. > > > > >This was not what was said at all in earlier posts. Please go back and read them >more carefully. > > Duly noted. I thought that I understood how the information you shared relates to the way graphics are explained in many books, but apparently not. > > Aside from that, I believe my posting was accurate in all other respects in terms of what will display on the screen in the circumstances I described. Unfortunately not in way that I could understand it, and I am experienced. And if I can't understand it, how is any one new to these forums would be able to? First off, columns referred to in your manual, refer to a monochrome monitor, yet try to describe what you would see on a color monitor. This already created mis-information on how the screen works. And your book calls orange, red. This author obviously doesn't know what the contrast button does on his tv. I will take one more crack at it. If you can't make heads or tails of it, I will leave it alone. A screen line takes up 40 bytes. 20 odd numbered and 20 even numbered, but I will only deal with one odd and one even as it is the same for the other 38 bytes. Each byte has 7 bits that will display a pixel on the screen time 40 for a total of 280 pixels across the screen. The high bit of each byte designates which group of colors you will see and is called the the color bit (this is not the same as a color pixel). It takes 2 whole bytes to create 7 colored pixels or 14 on/off pixels on a monochrome monitor. A single pixel by itself has no color. It has an on/off state. Off for black and an on for white. Two consecutive bits are needed to create a color pixel. The first bit is an even numbered bit and the 2nd bit is an odd numbered bit. This chart portrays which two consecutive bits refer to which pixel color you will see on the screen. Most books will display bytes with the high-bit first, in the order $80,$40,$20,$10,$8,$4,$2,$1. But for the sake of understanding how bits relate to the screen, it is best to flip the bytes with low-bit first in the order $1,$2,$4,$8,$10,$20,$40,$80. The result and the values are the same but easier to understand. To see how this comes into play, it might be advantageous to get a hex calculator with a binary display. bit #7 has a value of $80 if its bit is set bit #6 has a value of $40 if its bit is set bit #5 has a value of $20 if its bit is set bit #4 has a value of $10 if its bit is set bit #3 has a value of $8 if its bit is set bit #2 has a value of $4 if its bit is set bit #1 has a value of $2 if its bit is set bit #0 has a value of $1 if its bit is set with all the bits set in a byte, you would add all the values up, you should get $FF. If you don't know how to add hexadecimal, this would be a good time to learn before continuing. Here is the breakdown for the even/odd byte pairs that make up the 7 colored pixels. bit # 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 color bit color bit | | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 |_| |_| |_| |_____| |_| |_| |_| pixel# 0 1 2 3 4 5 6 If this chart does not show up correctly, then you will have to copy and paste it into notepad. Take note that it takes two consecutive bits to make a colored pixel, and the color bit is bit#7 of each byte, and that pixel#3 combines bit #6 of the 1st byte with bit #1 of the 2nd byte. The two consecutive bits can have 4 colors numbered from 0 to 3. And the color bit, which has a value of $80 (128 in decimal) decides which group of 4 colors you will see. The two groups of colors are: 1st group with color bit clear (each byte has a value <128) color# - bits - color 0 - 00 - black 1 - 10 - violet 2 - 01 - green 3 - 11 - white 2nd group with color bit set (each byte has a value >127) 0 - 00 - black 1 - 10 - blue 2 - 01 - orange 3 - 11 - white The bits in these tables are referred to as the even/odd columns you have been trying to describe, but I will show that in the 2nd byte, the bits(or columns) are reversed within the byte. bit#0 of byte#1 is an even bit but is not on an even column. This is why the word column should not be used. Even and Odd columns are only used in conjunction with the two sequential bits that make up a colored pixel, according to the 2 color charts above and according to the even/odd byte pairs that make up the 7 colored pixels. You should have also noticed that black and white are duplicated in each group, but are still considered 4 separate colors because they have a 1/2 bit shift, which is really distinct on a monochrome monitor. Hexadecimal math is easy to learn, and makes a lot more sense than decimal mode when dealing with bits, even when you want to write an applesoft program that only deals with decimal mode without special software. with the charts that are given, you should be able to calculate the value of any byte for any given pixel color or combination of pixel colors. example ]HGR ]CALL -151 "DO NOT TYPE THIS LINE IN, THESE ARE THE 8 COLORS FOR PIXEL #0" *2000:0 *2000:80 *2000:1 *2000:81 *2000:2 *2000:82 *2000:3 *2000:83 "DO NOT TYPE THIS LINE IN, THESE ARE THE 8 COLORS FOR PIXEL #1" *2000:0 *2000:80 *2000:4 *2000:84 *2000:8 *2000:88 *2000:C *2000:8C "DO NOT TYPE THIS LINE IN, THESE ARE THE 8 COLORS FOR PIXEL #3" "WHICH COMBINES BIT#6 OF ANY EVEN BYTE *** WITH BIT #1 OF THE NEXT BYTE AFTER THE EVEN BYTE" *2000:0 0 *2000:80 80 *2000:40 0 *2000:C0 80 *2000:0 20 *2000:80 A0 *2000:40 1 *2000:C0 81 The whole key to this is that you must understand hexadecimal and how each bit gives a hex value. To see a good color chart of all the color combinations, download and run graphics magician. This is the best graphics package out there. There should no longer be any reason to mis-interpret what is written here. There is only mis-conscruing it to give mis-information to mis-inform the mis-guided.
[toc] | [prev] | [next] | [standalone]
| From | denisbytezone@gmail.com |
|---|---|
| Date | 2016-02-21 00:23 -0800 |
| Message-ID | <6f54d44b-ef84-4426-b3ec-4999fd5efec5@googlegroups.com> |
| In reply to | #2330 |
This is the 'two-byte' system that I was referring to earlier. Unfortunately I cannot make it work and I believe it is wrong. The description on pp 19-20 of the Apple ][ Reference Manual is brief and quite clear, it explains how everything works without resorting to odd and even bytes. The only thing it doesn't explain is the smudging between non-adjacent pixels, which others have already covered. Personally I would prefer it if everyone used the notation with Most Significant Bit on left (also called the Color Bit) and Least Significant Bit on the right, but I can usually work out what they mean if they use it backwards. I agree it is confusing when the first (least significant, or rightmost) bit of the first byte appears on the left-hand edge of the screen, but that's just the way it is. I think the most important paragraph in the Apple manual is the one which begins - 'Each dot on the screen represents one bit from the picture buffer. Seven of the eight bits in each byte are displayed on the screen, with the remaining bit used to select the colors of the dots in that byte.' In my opinion, any interpretation which disagrees with those two sentences must be wrong. So no need for odd/even bytes, and no using two bytes to represent 7 pixels. Nowhere does it mention 'the two sequential bits that make up a colored pixel' or 'the even/odd byte pairs that make up the 7 colored pixels'. If anyone is interested, my java code is on GitHub and it follows the manual's method exactly.
[toc] | [prev] | [next] | [standalone]
| From | wssimms@gmail.com |
|---|---|
| Date | 2016-02-21 01:41 -0800 |
| Message-ID | <e7357125-a0ff-4ac4-b83b-23c9d5c01b23@googlegroups.com> |
| In reply to | #2331 |
Am Sonntag, 21. Februar 2016 17:23:42 UTC+9 schrieb denisb...@gmail.com: > This is the 'two-byte' system that I was referring to earlier. Unfortunately I cannot make it work and I believe it is wrong. The description on pp 19-20 of the Apple ][ Reference Manual is brief and quite clear, it explains how everything works without resorting to odd and even bytes. > > The only thing it doesn't explain is the smudging between non-adjacent pixels, which others have already covered. > > Personally I would prefer it if everyone used the notation with Most Significant Bit on left (also called the Color Bit) and Least Significant Bit on the right, but I can usually work out what they mean if they use it backwards. I agree it is confusing when the first (least significant, or rightmost) bit of the first byte appears on the left-hand edge of the screen, but that's just the way it is. > > I think the most important paragraph in the Apple manual is the one which begins - 'Each dot on the screen represents one bit from the picture buffer. Seven of the eight bits in each byte are displayed on the screen, with the remaining bit used to select the colors of the dots in that byte.' > > In my opinion, any interpretation which disagrees with those two sentences must be wrong. So no need for odd/even bytes, and no using two bytes to represent 7 pixels. Nowhere does it mention 'the two sequential bits that make up a colored pixel' or 'the even/odd byte pairs that make up the 7 colored pixels'. The way I read this, you aren't wrong. But neither is the person you are responding to. The reason that even and odd bytes come into play is that there are only 7 bits in each byte that correspond to dots on the screen. But it takes two consecutive dots to make a given color. Since 7 is not evenly divisible by two, one of those two-bit pairs is split between the even and odd bytes. Suppose the first two bytes on a line are $55, $55. In binary this is 01010101, 01010101. The video scanner puts these two bytes on the HGR screen low bit first, so it will put them out like this: A A A AB B B B Where As are dots generated from the first byte and Bs are dots generated from the second byte. The first A in the line is going to be colored purple because the first two bits are 10. The second A will also be colored purple because the next two bits are also 10. The third A will also be colored purple because the next two bits are also 10. The fourth A will be colored white, as will the first B, because together they make a 11 bit pair. The second B will be colored green, because the two bits after the AB are 01. The third B will also be colored green because the next two bits are 01. The fourth B will also be colored green because the next two bits (the last two in the sequence) are 01. You see that even though both of the two bytes have the same value ($55), they generate different colors because one is in an even position and the other is in an odd position. You also see that the middle pair of bits contains one bit from each of the bytes, and since they are both ones in this case, together they generate a white dot on the screen. Now, to get back to the question of using two bytes to generate 7 pixels, the fact of the matter is that on a TV set or regular composite color monitor, the purple or green colors generated by a 10 or 01 pair span both pixels of the pair (that is, both the 0 and the 1 appear to take on the color. In other words, if you do the exercise above you don't see a purple dot, a black dot, a purple dot, a black dot, a purple dot, a black dot, two white dots, a black dot, a green dot, etc. Instead you see a short purple line, followed by a white dot, followed by a short purple line, with no black space at all. So effectively, it takes two bits to generate one color dot, and the horizontal color resolution of the Apple II HGR screen is 140 pixels. So if you think of a pixel as 2 bits wide, which is true as a practical matter, then it takes two bytes to generate 7 pixels.
[toc] | [prev] | [next] | [standalone]
| From | wssimms@gmail.com |
|---|---|
| Date | 2016-02-21 01:43 -0800 |
| Message-ID | <8bb3240b-914c-426f-b0e5-18767b956f45@googlegroups.com> |
| In reply to | #2335 |
Am Sonntag, 21. Februar 2016 18:41:05 UTC+9 schrieb wss...@gmail.com: > Instead you see a short purple line, followed by a white dot, followed by a short green line, with no black space at all. Correction
[toc] | [prev] | [next] | [standalone]
| From | denisbytezone@gmail.com |
|---|---|
| Date | 2016-02-21 02:29 -0800 |
| Message-ID | <5e9d07fc-f692-46e6-a455-3c3a358b0ec4@googlegroups.com> |
| In reply to | #2335 |
On Sunday, 21 February 2016 20:41:05 UTC+11, wss...@gmail.com wrote: > Am Sonntag, 21. Februar 2016 17:23:42 UTC+9 schrieb denisb...@gmail.com: > > This is the 'two-byte' system that I was referring to earlier. Unfortunately I cannot make it work and I believe it is wrong. The description on pp 19-20 of the Apple ][ Reference Manual is brief and quite clear, it explains how everything works without resorting to odd and even bytes. > > > > The only thing it doesn't explain is the smudging between non-adjacent pixels, which others have already covered. > > > > Personally I would prefer it if everyone used the notation with Most Significant Bit on left (also called the Color Bit) and Least Significant Bit on the right, but I can usually work out what they mean if they use it backwards. I agree it is confusing when the first (least significant, or rightmost) bit of the first byte appears on the left-hand edge of the screen, but that's just the way it is. > > > > I think the most important paragraph in the Apple manual is the one which begins - 'Each dot on the screen represents one bit from the picture buffer. Seven of the eight bits in each byte are displayed on the screen, with the remaining bit used to select the colors of the dots in that byte.' > > > > In my opinion, any interpretation which disagrees with those two sentences must be wrong. So no need for odd/even bytes, and no using two bytes to represent 7 pixels. Nowhere does it mention 'the two sequential bits that make up a colored pixel' or 'the even/odd byte pairs that make up the 7 colored pixels'. > > The way I read this, you aren't wrong. But neither is the person you are responding to. > > The reason that even and odd bytes come into play is that there are only 7 bits in each byte that correspond to dots on the screen. But it takes two consecutive dots to make a given color. Since 7 is not evenly divisible by two, one of those two-bit pairs is split between the even and odd bytes. > > Suppose the first two bytes on a line are $55, $55. In binary this is 01010101, 01010101. The video scanner puts these two bytes on the HGR screen low bit first, so it will put them out like this: > > A A A AB B B B > > Where As are dots generated from the first byte and Bs are dots generated from the second byte. > > The first A in the line is going to be colored purple because the first two bits are 10. > The second A will also be colored purple because the next two bits are also 10. > The third A will also be colored purple because the next two bits are also 10. > The fourth A will be colored white, as will the first B, because together they make a 11 bit pair. > The second B will be colored green, because the two bits after the AB are 01. > The third B will also be colored green because the next two bits are 01. > The fourth B will also be colored green because the next two bits (the last two in the sequence) are 01. > > You see that even though both of the two bytes have the same value ($55), they generate different colors because one is in an even position and the other is in an odd position. You also see that the middle pair of bits contains one bit from each of the bytes, and since they are both ones in this case, together they generate a white dot on the screen. > > Now, to get back to the question of using two bytes to generate 7 pixels, the fact of the matter is that on a TV set or regular composite color monitor, the purple or green colors generated by a 10 or 01 pair span both pixels of the pair (that is, both the 0 and the 1 appear to take on the color. In other words, if you do the exercise above you don't see a purple dot, a black dot, a purple dot, a black dot, a purple dot, a black dot, two white dots, a black dot, a green dot, etc. > > Instead you see a short purple line, followed by a white dot, followed by a short purple line, with no black space at all. So effectively, it takes two bits to generate one color dot, and the horizontal color resolution of the Apple II HGR screen is 140 pixels. So if you think of a pixel as 2 bits wide, which is true as a practical matter, then it takes two bytes to generate 7 pixels. I would be interested in your description of how the two-byte system interprets $0066. Because when you pair up the bits, you get 00-00-00-01-10-01-10 (after removing the two colour bits which are both zero. I simply must be misunderstanding your explanation because you seem to be saying that this pattern will generate alternating green and purple pixels. But I'm pretty sure that it will generate two lots of two white pixels. As the manual states 'two colored dots side by side always appear white, even if they are in different bytes'.
[toc] | [prev] | [next] | [standalone]
| From | denisbytezone@gmail.com |
|---|---|
| Date | 2016-02-21 02:40 -0800 |
| Message-ID | <ede43489-4474-4a5c-acb6-2d61fd7edc3f@googlegroups.com> |
| In reply to | #2338 |
On Sunday, 21 February 2016 21:29:49 UTC+11, denisb...@gmail.com wrote: > On Sunday, 21 February 2016 20:41:05 UTC+11, wss...@gmail.com wrote: > > Am Sonntag, 21. Februar 2016 17:23:42 UTC+9 schrieb denisb...@gmail.com: > > > This is the 'two-byte' system that I was referring to earlier. Unfortunately I cannot make it work and I believe it is wrong. The description on pp 19-20 of the Apple ][ Reference Manual is brief and quite clear, it explains how everything works without resorting to odd and even bytes. > > > > > > The only thing it doesn't explain is the smudging between non-adjacent pixels, which others have already covered. > > > > > > Personally I would prefer it if everyone used the notation with Most Significant Bit on left (also called the Color Bit) and Least Significant Bit on the right, but I can usually work out what they mean if they use it backwards. I agree it is confusing when the first (least significant, or rightmost) bit of the first byte appears on the left-hand edge of the screen, but that's just the way it is. > > > > > > I think the most important paragraph in the Apple manual is the one which begins - 'Each dot on the screen represents one bit from the picture buffer. Seven of the eight bits in each byte are displayed on the screen, with the remaining bit used to select the colors of the dots in that byte.' > > > > > > In my opinion, any interpretation which disagrees with those two sentences must be wrong. So no need for odd/even bytes, and no using two bytes to represent 7 pixels. Nowhere does it mention 'the two sequential bits that make up a colored pixel' or 'the even/odd byte pairs that make up the 7 colored pixels'. > > > > The way I read this, you aren't wrong. But neither is the person you are responding to. > > > > The reason that even and odd bytes come into play is that there are only 7 bits in each byte that correspond to dots on the screen. But it takes two consecutive dots to make a given color. Since 7 is not evenly divisible by two, one of those two-bit pairs is split between the even and odd bytes. > > > > Suppose the first two bytes on a line are $55, $55. In binary this is 01010101, 01010101. The video scanner puts these two bytes on the HGR screen low bit first, so it will put them out like this: > > > > A A A AB B B B > > > > Where As are dots generated from the first byte and Bs are dots generated from the second byte. > > > > The first A in the line is going to be colored purple because the first two bits are 10. > > The second A will also be colored purple because the next two bits are also 10. > > The third A will also be colored purple because the next two bits are also 10. > > The fourth A will be colored white, as will the first B, because together they make a 11 bit pair. > > The second B will be colored green, because the two bits after the AB are 01. > > The third B will also be colored green because the next two bits are 01. > > The fourth B will also be colored green because the next two bits (the last two in the sequence) are 01. > > > > You see that even though both of the two bytes have the same value ($55), they generate different colors because one is in an even position and the other is in an odd position. You also see that the middle pair of bits contains one bit from each of the bytes, and since they are both ones in this case, together they generate a white dot on the screen. > > > > Now, to get back to the question of using two bytes to generate 7 pixels, the fact of the matter is that on a TV set or regular composite color monitor, the purple or green colors generated by a 10 or 01 pair span both pixels of the pair (that is, both the 0 and the 1 appear to take on the color. In other words, if you do the exercise above you don't see a purple dot, a black dot, a purple dot, a black dot, a purple dot, a black dot, two white dots, a black dot, a green dot, etc. > > > > Instead you see a short purple line, followed by a white dot, followed by a short purple line, with no black space at all. So effectively, it takes two bits to generate one color dot, and the horizontal color resolution of the Apple II HGR screen is 140 pixels. So if you think of a pixel as 2 bits wide, which is true as a practical matter, then it takes two bytes to generate 7 pixels. > > I would be interested in your description of how the two-byte system interprets $0066. Because when you pair up the bits, you get 00-00-00-01-10-01-10 (after removing the two colour bits which are both zero. I simply must be misunderstanding your explanation because you seem to be saying that this pattern will generate alternating green and purple pixels. But I'm pretty sure that it will generate two lots of two white pixels. As the manual states 'two colored dots side by side always appear white, even if they are in different bytes'. Actually, just use $06. Using two bytes just confuses the issue and it's not necessary for the point I'm trying to make.
[toc] | [prev] | [next] | [standalone]
| From | wssimms@gmail.com |
|---|---|
| Date | 2016-02-21 08:03 -0800 |
| Message-ID | <97f9ebb9-e030-4fed-8ca7-48b19f6059a1@googlegroups.com> |
| In reply to | #2338 |
If the two bytes are $00 and $66 then the bitstream to the video screen is 000000001100110, and you are right, you will get white dots. I wasn't sufficiently clear in my post, which an easy proble to have if you want to explain Apple graphics without writing a whole book, but I what I wrote was not wrong, and it explained what the previous poster meant by even and odd bytes behaving differently and two bits making one pixel. But, as this example makes clear, what I wrote wasn't complete. Adjacent set bits at any horizontal position will produce a white dot. Nevertheless, the point stands that it takes two bits to set a color, so the effective horizontal resolution of the color HGR screen remains 140 pixels.
[toc] | [prev] | [next] | [standalone]
| From | gids.rs@sasktel.net |
|---|---|
| Date | 2016-02-21 09:55 -0800 |
| Message-ID | <e2f2149e-a895-4160-8672-4d7d4124788d@googlegroups.com> |
| In reply to | #2338 |
On Sunday, February 21, 2016 at 4:29:49 AM UTC-6, denisb...@gmail.com wrote: > On Sunday, 21 February 2016 20:41:05 UTC+11, wss...@gmail.com wrote: > > Am Sonntag, 21. Februar 2016 17:23:42 UTC+9 schrieb denisb...@gmail.com: > > > This is the 'two-byte' system that I was referring to earlier. Unfortunately I cannot make it work and I believe it is wrong. The description on pp 19-20 of the Apple ][ Reference Manual is brief and quite clear, it explains how everything works without resorting to odd and even bytes. > > > > > > The only thing it doesn't explain is the smudging between non-adjacent pixels, which others have already covered. > > > > > > Personally I would prefer it if everyone used the notation with Most Significant Bit on left (also called the Color Bit) and Least Significant Bit on the right, but I can usually work out what they mean if they use it backwards. I agree it is confusing when the first (least significant, or rightmost) bit of the first byte appears on the left-hand edge of the screen, but that's just the way it is. > > > > > > I think the most important paragraph in the Apple manual is the one which begins - 'Each dot on the screen represents one bit from the picture buffer. Seven of the eight bits in each byte are displayed on the screen, with the remaining bit used to select the colors of the dots in that byte.' > > > > > > In my opinion, any interpretation which disagrees with those two sentences must be wrong. So no need for odd/even bytes, and no using two bytes to represent 7 pixels. Nowhere does it mention 'the two sequential bits that make up a colored pixel' or 'the even/odd byte pairs that make up the 7 colored pixels'. > > > > The way I read this, you aren't wrong. But neither is the person you are responding to. > > > > The reason that even and odd bytes come into play is that there are only 7 bits in each byte that correspond to dots on the screen. But it takes two consecutive dots to make a given color. Since 7 is not evenly divisible by two, one of those two-bit pairs is split between the even and odd bytes. > > > > Suppose the first two bytes on a line are $55, $55. In binary this is 01010101, 01010101. The video scanner puts these two bytes on the HGR screen low bit first, so it will put them out like this: > > > > A A A AB B B B > > > > Where As are dots generated from the first byte and Bs are dots generated from the second byte. > > > > The first A in the line is going to be colored purple because the first two bits are 10. > > The second A will also be colored purple because the next two bits are also 10. > > The third A will also be colored purple because the next two bits are also 10. > > The fourth A will be colored white, as will the first B, because together they make a 11 bit pair. > > The second B will be colored green, because the two bits after the AB are 01. > > The third B will also be colored green because the next two bits are 01. > > The fourth B will also be colored green because the next two bits (the last two in the sequence) are 01. > > > > You see that even though both of the two bytes have the same value ($55), they generate different colors because one is in an even position and the other is in an odd position. You also see that the middle pair of bits contains one bit from each of the bytes, and since they are both ones in this case, together they generate a white dot on the screen. > > > > Now, to get back to the question of using two bytes to generate 7 pixels, the fact of the matter is that on a TV set or regular composite color monitor, the purple or green colors generated by a 10 or 01 pair span both pixels of the pair (that is, both the 0 and the 1 appear to take on the color. In other words, if you do the exercise above you don't see a purple dot, a black dot, a purple dot, a black dot, a purple dot, a black dot, two white dots, a black dot, a green dot, etc. > > > > Instead you see a short purple line, followed by a white dot, followed by a short purple line, with no black space at all. So effectively, it takes two bits to generate one color dot, and the horizontal color resolution of the Apple II HGR screen is 140 pixels. So if you think of a pixel as 2 bits wide, which is true as a practical matter, then it takes two bytes to generate 7 pixels. > > I would be interested in your description of how the two-byte system interprets $0066. Because when you pair up the bits, you get 00-00-00-01-10-01-10 (after removing the two colour bits which are both zero. I simply must be misunderstanding your explanation because you seem to be saying that this pattern will generate alternating green and purple pixels. But I'm pretty sure that it will generate two lots of two white pixels. As the manual states 'two colored dots side by side always appear white, even if they are in different bytes'. Again you are mis-reading the post. It does not say alternating pixels, it says alternating bytes. Which means, the odd byte is the alternate of the even byte to give the same color. For each even/odd byte pair, to get a solid colored line you will have these alternating values, not including the most significant bit (way easier and shorter to say hi-bit or MSB, I will use MSB in the remainder of the post) 2000: 55 2a - violet line 2000: 2a 55 - green line 2000: d5 aa - blue line 2000: aa d5 - orange line breaking down 55 and 2a - the MSB is on the left. 55 - 0101 0101 2a - 0010 1010 as you can see the bits are alternating, not counting the MSB d5 - 1101 0101 - do not confuse the double one's here as a pixel, the MSB only allows the second color group to be displayed blue/orange aa - 1010 1010 And from previous posts, by now you should also be able to assess that bit# 6 of each even byte combines with bit# 1 of the next byte (which is the odd byte) for its pixel color (and in other posts is known as pixel #3).
[toc] | [prev] | [next] | [standalone]
| From | gids.rs@sasktel.net |
|---|---|
| Date | 2016-02-21 10:28 -0800 |
| Message-ID | <727da1ab-6af0-4f28-a2ee-0e7a34928910@googlegroups.com> |
| In reply to | #2341 |
> breaking down 55 and 2a - the MSB is on the left. > > 55 - 0101 0101 > 2a - 0010 1010 > > as you can see the bits are alternating, not counting the MSB This may need some clarification. The comparison of alternating bits is made between the two bytes and not the alternating bits in the byte itself.
[toc] | [prev] | [next] | [standalone]
| From | gids.rs@sasktel.net |
|---|---|
| Date | 2016-02-21 14:42 -0800 |
| Message-ID | <a9d731d0-01eb-4de2-a991-80fe35e28415@googlegroups.com> |
| In reply to | #2342 |
One more thing that should be noted, is that most of the books that try to describe hi-res graphics are doing so in a way to make it simple to understand what you see on the screen. But they are describing it as a pixel plotted in a certain column gives you a certain color. Technically, this is incorrect, as the pixel you just plotted relies on the pixel beside it to produce that color. In applesoft this is easily achieved with these statements 5 HGR 6 EVENCOL = 10:ODDCOL = EVENCOL + 1 10 HCOLOR= 2: HPLOT EVENCOL,20: HPLOT EVENCOL,21: HPLOT EVENCOL,22 20 HCOLOR= 1: HPLOT ODDCOL,24: HPLOT ODDCOL,25: HPLOT ODDCOL,26 30 HCOLOR= 6: HPLOT EVENCOL,28: HPLOT EVENCOL,29: HPLOT EVENCOL,30 40 HCOLOR= 5: HPLOT ODDCOL,32: HPLOT ODDCOL,33: HPLOT ODDCOL,34 but these colors are actually improperly plotted. add these next few lines to the applesoft listing 99 GET A$: HGR 110 HCOLOR= 2: HPLOT EVENCOL,20: HPLOT ODDCOL,20 112 HPLOT EVENCOL,21: HPLOT ODDCOL,21 114 HPLOT EVENCOL,22: HPLOT ODDCOL,22 120 HCOLOR= 1: HPLOT EVENCOL,24: HPLOT ODDCOL,24 122 HPLOT EVENCOL,23: HPLOT ODDCOL,23 124 HPLOT EVENCOL,24: HPLOT ODDCOL,24 130 HCOLOR= 6: HPLOT EVENCOL,26: HPLOT ODDCOL,26 132 HPLOT EVENCOL,27: HPLOT ODDCOL,27 134 HPLOT EVENCOL,28: HPLOT ODDCOL,28 140 HCOLOR= 5: HPLOT EVENCOL,30: HPLOT ODDCOL,30 142 HPLOT EVENCOL,31: HPLOT ODDCOL,31 144 HPLOT EVENCOL,32: HPLOT ODDCOL,32 now when you run this program, you will see the 4 colors that are plotted while only plotted in one column at a time (either the even column or the odd column) then line# 99 pauses for a keypress, clears the screen and redraws the 4 pixels. This time they are plotted in both columns at the same time and they should look exactly the same. The latter half of the listing is the accurate way of plotting color pixels on the screen, but as you can see, it takes up quite a bit more code and slows down your program. So, the books are relying on an adjacent pixel to already be black, which is what usually always happens when clearing the screen with HGR. It greatly reduces the applesoft program and reduces the explanation of how the colored pixel is created. I will admit that it makes sense when you look at the screen and see how the colors relate to the columns. But trust me, when you try to write software with this anology, it doesn't work. I believe you have already said you couldn't get it to work? I repeat, a single pixel cannot have color, although what you read in the manuals makes it look like that is what is happening. This poor description in most manuals of how apple computers displays graphics has probably caused more confusion than good when it comes time for most people to write their own programs. And now to try to translate this even/odd column theory to screen bits and bytes using hexadecimal code does not work, since there are only 7 bits usable in each screen byte. And even/odd col pairs (not be confused with even/odd bytes) would require 8 bits. If you want to learn to program graphics directly to the screen using the monitor and using binary code, you will have to forget the books as being accurate, and only use them as guidelines. They do not tell the whole story. You can still put the even/odd columns in theory into hexadecimal bytes, but only with the two consecutive bits that combine to make a colored pixel. The breakdown of hex bytes and even/odd bytes has already been posted, so I don't need to repeat them here. I hope this helps you better understand what books are portraying, compared to how graphics really works. But if you stick to the books analogy, and keep telling us that what we are telling you is not what you are reading, then I would recommend staying with applesoft. It has all formulas already calculated for you and you just have to memorize which color is being displayed when a pixel is on, in an even or odd column.
[toc] | [prev] | [next] | [standalone]
| From | Michael J. Mahon <mjmahon@aol.com> |
|---|---|
| Date | 2016-02-22 14:13 -0600 |
| Message-ID | <gMKdnc4qvYBq9lbLnZ2dnUU7-bmdnZ2d@giganews.com> |
| In reply to | #2338 |
<denisbytezone@gmail.com> wrote: > On Sunday, 21 February 2016 20:41:05 UTC+11, wss...@gmail.com wrote: >> Am Sonntag, 21. Februar 2016 17:23:42 UTC+9 schrieb denisb...@gmail.com: >>> This is the 'two-byte' system that I was referring to earlier. >>> Unfortunately I cannot make it work and I believe it is wrong. The >>> description on pp 19-20 of the Apple ][ Reference Manual is brief and >>> quite clear, it explains how everything works without resorting to odd and even bytes. >>> >>> The only thing it doesn't explain is the smudging between non-adjacent >>> pixels, which others have already covered. >>> >>> Personally I would prefer it if everyone used the notation with Most >>> Significant Bit on left (also called the Color Bit) and Least >>> Significant Bit on the right, but I can usually work out what they mean >>> if they use it backwards. I agree it is confusing when the first (least >>> significant, or rightmost) bit of the first byte appears on the >>> left-hand edge of the screen, but that's just the way it is. >>> >>> I think the most important paragraph in the Apple manual is the one >>> which begins - 'Each dot on the screen represents one bit from the >>> picture buffer. Seven of the eight bits in each byte are displayed on >>> the screen, with the remaining bit used to select the colors of the dots in that byte.' >>> >>> In my opinion, any interpretation which disagrees with those two >>> sentences must be wrong. So no need for odd/even bytes, and no using >>> two bytes to represent 7 pixels. Nowhere does it mention 'the two >>> sequential bits that make up a colored pixel' or 'the even/odd byte >>> pairs that make up the 7 colored pixels'. >> >> The way I read this, you aren't wrong. But neither is the person you are responding to. >> >> The reason that even and odd bytes come into play is that there are only >> 7 bits in each byte that correspond to dots on the screen. But it takes >> two consecutive dots to make a given color. Since 7 is not evenly >> divisible by two, one of those two-bit pairs is split between the even and odd bytes. >> >> Suppose the first two bytes on a line are $55, $55. In binary this is >> 01010101, 01010101. The video scanner puts these two bytes on the HGR >> screen low bit first, so it will put them out like this: >> >> A A A AB B B B >> >> Where As are dots generated from the first byte and Bs are dots >> generated from the second byte. >> >> The first A in the line is going to be colored purple because the first two bits are 10. >> The second A will also be colored purple because the next two bits are also 10. >> The third A will also be colored purple because the next two bits are also 10. >> The fourth A will be colored white, as will the first B, because >> together they make a 11 bit pair. >> The second B will be colored green, because the two bits after the AB are 01. >> The third B will also be colored green because the next two bits are 01. >> The fourth B will also be colored green because the next two bits (the >> last two in the sequence) are 01. >> >> You see that even though both of the two bytes have the same value >> ($55), they generate different colors because one is in an even position >> and the other is in an odd position. You also see that the middle pair >> of bits contains one bit from each of the bytes, and since they are both >> ones in this case, together they generate a white dot on the screen. >> >> Now, to get back to the question of using two bytes to generate 7 >> pixels, the fact of the matter is that on a TV set or regular composite >> color monitor, the purple or green colors generated by a 10 or 01 pair >> span both pixels of the pair (that is, both the 0 and the 1 appear to >> take on the color. In other words, if you do the exercise above you >> don't see a purple dot, a black dot, a purple dot, a black dot, a purple >> dot, a black dot, two white dots, a black dot, a green dot, etc. >> >> Instead you see a short purple line, followed by a white dot, followed >> by a short purple line, with no black space at all. So effectively, it >> takes two bits to generate one color dot, and the horizontal color >> resolution of the Apple II HGR screen is 140 pixels. So if you think of >> a pixel as 2 bits wide, which is true as a practical matter, then it >> takes two bytes to generate 7 pixels. > > I would be interested in your description of how the two-byte system > interprets $0066. Because when you pair up the bits, you get > 00-00-00-01-10-01-10 (after removing the two colour bits which are both > zero. I simply must be misunderstanding your explanation because you seem > to be saying that this pattern will generate alternating green and purple > pixels. But I'm pretty sure that it will generate two lots of two white > pixels. As the manual states 'two colored dots side by side always appear > white, even if they are in different bytes'. > Correct. Any two or more consecutive 1 bits will produce white, regardless of how they are "aligned" in the byte(s). The residual "fringing" at the ends of a string of 1 bits will depend on the alignment and whether there are an even or odd number of consecutive 1 bits. -- -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
[toc] | [prev] | [next] | [standalone]
| From | Michael Pohoreski <michael.pohoreski@gmail.com> |
|---|---|
| Date | 2016-02-21 20:49 -0800 |
| Message-ID | <99bf8953-6221-4262-9ee9-4170948bfad4@googlegroups.com> |
| In reply to | #2330 |
On Sunday, February 21, 2016 at 12:11:08 AM UTC-7, gid...@sasktel.net wrote: > To see how this comes into play, it might be advantageous to get a hex calculator with a binary display. > > bit #7 has a value of $80 if its bit is set > bit #6 has a value of $40 if its bit is set > bit #5 has a value of $20 if its bit is set > bit #4 has a value of $10 if its bit is set > bit #3 has a value of $8 if its bit is set > bit #2 has a value of $4 if its bit is set > bit #1 has a value of $2 if its bit is set > bit #0 has a value of $1 if its bit is set Or just use my HGRBYTE inspector and you can toggle, shift, rotate, set, clear the bits to yours hearts content AND see the corresponding hex values, both normal and reversed bits & bytes. :-) You can find a DSK image up on GitHub. https://github.com/Michaelangel007/apple2_hgrbyte (Assembly source code will be posted later this week.) Keys ESC Quit G Toggle fullscreen I Move cursor up J Move cursor left K Move cursor right L Move cursor down ^I Move cursor to col 0 ^J Move cursor to col 39 ^K Move cursor to row 0 ^L Move cursor to row 191 RET Center cursor 0..9 "Append" hex nibble to cursor byte A..F ! Toggle bit 0 @ Toggle bit 1 # Toggle bit 2 $ Toggle bit 3 % Toggle bit 4 ^ Toggle bit 5 & Toggle bit 6 * Toggle bit 7 (high bit) SPC Toggle high bit of byte (bit 7) ( Set byte to $FF (Shift-9) ) Clear byte to $00 (Shift-0) ` Flip all bits ~ Flip all bits , Shift byte left (with zero) . Shift byte right (with one ) < Shift byte left (with zero) > Shift byte right (with one ) [ Rotate byte left ] Rotate byte right - Save cursor byte to temporary = Set cursor byte from temporary If you want to try the new Version 16 immediately: 0900:A9 10 2C 54 C0 2C 50 C0 0908:2C 53 C0 2C 57 C0 A2 00 0910:86 FD 86 FF 86 E2 86 FA 0918:86 26 A9 20 85 27 85 E6 0920:BD 16 0A F0 4A 9D D0 06 0928:E8 D0 F5 A5 FD 29 01 AA 0930:9D 52 C0 A5 FD 49 01 85 0938:FD 80 4F 49 80 80 44 C6 0940:FF 10 34 E6 FF A5 FF C9 0948:28 90 2C A9 27 2C A9 00 0950:85 FF 10 23 C6 E2 A5 E2 0958:C9 FF D0 1B E6 E2 A5 E2 0960:C9 C0 90 13 A9 BF 2C A9 0968:00 85 E2 69 01 D0 08 A9 0970:14 85 FF A9 60 85 E2 A0 0978:00 A2 00 A5 E2 20 11 F4 0980:20 DF 0A 85 FC 85 FB 20 0988:3C 0A 20 EA 0A AD 00 C0 0990:10 F8 8D 10 C0 29 7F 85 0998:F9 C9 30 90 04 C9 3A 90 09A0:5F C9 41 90 04 C9 47 90 09A8:57 A2 22 CA 30 DC DD F3 09B0:0A D0 F8 A9 09 48 BD 15 09B8:0B 48 A5 FC 20 E5 0A A2 09C0:00 60 A9 FF D0 BD A9 00 09C8:F0 B9 A2 FF D0 25 C9 80 09D0:2A 80 B0 09 01 4A 90 AB 09D8:09 80 B0 A7 0A A2 4A 80 09E0:A2 E8 E8 E8 E8 E8 E8 E8 09E8:E8 A8 38 A9 00 2A CA D0 09F0:FC AA 98 86 FE 45 FE 80 09F8:8A 85 FA A5 FA 18 90 F7 0A00:A0 03 06 FC 88 10 FB A5 0A08:F9 C9 41 90 02 E9 07 29 0A10:0F 18 65 FC 90 E1 A0 A0 0A18:A0 A0 A0 A0 A0 A0 A0 A0 0A20:A0 A0 D3 C1 D6 C5 BA BF 0A28:BF A0 B7 B6 B5 B4 B3 B2 0A30:B1 B0 A0 31 32 33 34 35 0A38:36 37 38 00 A9 00 85 24 0A40:A9 14 20 5B FB A9 D8 20 0A48:ED FD A5 FF 20 D3 FD A9 0A50:A0 20 ED FD A9 D9 20 ED 0A58:FD A5 E2 20 D3 FD A9 A0 0A60:20 ED FD A9 A4 20 ED FD 0A68:A5 27 20 D3 FD A5 26 18 0A70:65 FF 20 DA FD A9 BA 20 0A78:ED FD A5 FC 20 DA FD A9 0A80:A0 20 ED FD A2 08 A5 FC 0A88:85 FE 06 FE 6A CA D0 FA 0A90:85 FE 48 A2 08 A5 FE 20 0A98:D4 0A 66 FE CA D0 F6 A9 0AA0:FE 20 ED FD A2 08 A5 FC 0AA8:A8 20 D4 0A 98 4A CA D0 0AB0:F7 A9 A4 20 ED FD 68 20 0AB8:DA FD A5 FA 48 4A 4A 4A 0AC0:4A 20 C5 0A 68 29 0F 09 0AC8:30 C9 3A 90 02 E9 39 9D 0AD0:E1 06 E8 60 29 01 F0 02 0AD8:A9 81 49 B0 4C ED FD A4 0AE0:FF B1 26 85 FC A4 FF 91 0AE8:26 60 A5 FB 49 FF 85 FB 0AF0:4C E5 0A 1B 47 08 15 09 0AF8:0A 0B 0C 0D 49 4A 4B 4C 0B00:21 40 23 24 25 5E 26 2A 0B08:20 28 29 60 7E 2C 3C 2E 0B10:3E 5B 5D 2D 3D C0 2A 3E 0B18:42 66 4D 63 4A 6E 53 3E 0B20:5B 42 E7 E6 E5 E4 E3 E2 0B28:E1 E0 3A C1 C5 C9 C9 DB 0B30:CF DD D2 CD D4 F8 FA
[toc] | [prev] | [next] | [standalone]
| From | anthonypaulo@gmail.com |
|---|---|
| Date | 2017-06-22 17:19 -0700 |
| Message-ID | <df3a1389-755e-460f-9f87-3cdb69584146@googlegroups.com> |
| In reply to | #2330 |
On Sunday, February 21, 2016 at 2:11:08 AM UTC-5, gid...@sasktel.net wrote: > On Saturday, February 20, 2016 at 10:53:43 PM UTC-6, Mark Lemmert wrote: > > >And please stop calling bits, columns. This is very unprofessional in computer >language. > > > > > > Clearly you are very knowledgable about the deep workings of Apple graphics, and I totally respect that. > > > > And, thank you for the opportunity to explain my posting. I feel like there are two different sets of terminology being in this thread at times and have been puzzled as to the reason why. > > > > Here is my perspective: > > > > Many graphics books refer to bits as a columns, especially when explaining how the color bit works. > > > > Example: Apple II Reference Manual (1979, white cover), page 19, bottom of the page. > > > > https://www.dropbox.com/s/wu9u2ksij911zou/Screen%20Shot%202016-02-20%20at%2010.23.31%20PM.png?dl=0 > > > > > > I'm not trying to say you are wrong by referencing the books, I'll take your word for it that there are programmers who consider the term column unprofessional. I didn't know that, and thank you for sharing it. > > > > The reason I use the term column is because there are people out there (me being one of them) who learn from books, and then try to refine that knowledge experimentation and asking questions. It is much easier to learn when the terminology in the book can be used as a point of reference. > > > > > > > > >This was not what was said at all in earlier posts. Please go back and read them >more carefully. > > > > Duly noted. I thought that I understood how the information you shared relates to the way graphics are explained in many books, but apparently not. > > > > Aside from that, I believe my posting was accurate in all other respects in terms of what will display on the screen in the circumstances I described. > > > > Unfortunately not in way that I could understand it, and I am experienced. And if I can't understand it, how is any one new to these forums would be able to? > > First off, columns referred to in your manual, refer to a monochrome monitor, yet try to describe what you would see on a color monitor. This already created mis-information on how the screen works. And your book calls orange, red. This author obviously doesn't know what the contrast button does on his tv. > > I will take one more crack at it. > > If you can't make heads or tails of it, I will leave it alone. > > A screen line takes up 40 bytes. 20 odd numbered and 20 even numbered, but I will only deal with one odd and one even as it is the same for the other 38 bytes. Each byte has 7 bits that will display a pixel on the screen time 40 for a total of 280 pixels across the screen. The high bit of each byte designates which group of colors you will see and is called the the color bit (this is not the same as a color pixel). > > It takes 2 whole bytes to create 7 colored pixels or 14 on/off pixels on a monochrome monitor. > > A single pixel by itself has no color. It has an on/off state. Off for black and an on for white. Two consecutive bits are needed to create a color pixel. The first bit is an even numbered bit and the 2nd bit is an odd numbered bit. > > This chart portrays which two consecutive bits refer to which pixel color you will see on the screen. Most books will display bytes with the high-bit first, in the order $80,$40,$20,$10,$8,$4,$2,$1. But for the sake of understanding how bits relate to the screen, it is best to flip the bytes with low-bit first in the order $1,$2,$4,$8,$10,$20,$40,$80. The result and the values are the same but easier to understand. > > To see how this comes into play, it might be advantageous to get a hex calculator with a binary display. > > bit #7 has a value of $80 if its bit is set > bit #6 has a value of $40 if its bit is set > bit #5 has a value of $20 if its bit is set > bit #4 has a value of $10 if its bit is set > bit #3 has a value of $8 if its bit is set > bit #2 has a value of $4 if its bit is set > bit #1 has a value of $2 if its bit is set > bit #0 has a value of $1 if its bit is set > > with all the bits set in a byte, you would add all the values up, you should get $FF. If you don't know how to add hexadecimal, this would be a good time to learn before continuing. > > Here is the breakdown for the even/odd byte pairs that make up the 7 colored pixels. > > bit # > 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 > > color bit color bit > | | > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > |_| |_| |_| |_____| |_| |_| |_| > > pixel# > 0 1 2 3 4 5 6 > > > If this chart does not show up correctly, then you will have to copy and paste it into notepad. > > Take note that it takes two consecutive bits to make a colored pixel, and the color bit is bit#7 of each byte, and that pixel#3 combines bit #6 of the 1st byte with bit #1 of the 2nd byte. > > The two consecutive bits can have 4 colors numbered from 0 to 3. And the color bit, which has a value of $80 (128 in decimal) decides which group of 4 colors you will see. The two groups of colors are: > > 1st group with color bit clear (each byte has a value <128) > color# - bits - color > 0 - 00 - black > 1 - 10 - violet > 2 - 01 - green > 3 - 11 - white > > 2nd group with color bit set (each byte has a value >127) > 0 - 00 - black > 1 - 10 - blue > 2 - 01 - orange > 3 - 11 - white > > The bits in these tables are referred to as the even/odd columns you have been trying to describe, but I will show that in the 2nd byte, the bits(or columns) are reversed within the byte. > > bit#0 of byte#1 is an even bit but is not on an even column. This is why the word column should not be used. > > Even and Odd columns are only used in conjunction with the two sequential bits that make up a colored pixel, according to the 2 color charts above and according to the even/odd byte pairs that make up the 7 colored pixels. > > You should have also noticed that black and white are duplicated in each group, but are still considered 4 separate colors because they have a 1/2 bit shift, which is really distinct on a monochrome monitor. > > Hexadecimal math is easy to learn, and makes a lot more sense than decimal mode when dealing with bits, even when you want to write an applesoft program that only deals with decimal mode without special software. > > with the charts that are given, you should be able to calculate the value of any byte for any given pixel color or combination of pixel colors. > > example > > ]HGR > ]CALL -151 > > "DO NOT TYPE THIS LINE IN, THESE ARE THE 8 COLORS FOR PIXEL #0" > > *2000:0 > *2000:80 > *2000:1 > *2000:81 > *2000:2 > *2000:82 > *2000:3 > *2000:83 > > "DO NOT TYPE THIS LINE IN, THESE ARE THE 8 COLORS FOR PIXEL #1" > > *2000:0 > *2000:80 > *2000:4 > *2000:84 > *2000:8 > *2000:88 > *2000:C > *2000:8C > > > "DO NOT TYPE THIS LINE IN, THESE ARE THE 8 COLORS FOR PIXEL #3" > "WHICH COMBINES BIT#6 OF ANY EVEN BYTE *** WITH BIT #1 OF THE NEXT BYTE AFTER THE EVEN BYTE" > > *2000:0 0 > *2000:80 80 > *2000:40 0 > *2000:C0 80 > *2000:0 20 > *2000:80 A0 > *2000:40 1 > *2000:C0 81 > > > The whole key to this is that you must understand hexadecimal and how each bit gives a hex value. > > > To see a good color chart of all the color combinations, download and run graphics magician. This is the best graphics package out there. > > There should no longer be any reason to mis-interpret what is written here. There is only mis-conscruing it to give mis-information to mis-inform the mis-guided. 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 curious about whether the trade-off was really worth it and how things would have turned out if they had not skimped on the graphics.
[toc] | [prev] | [next] | [standalone]
| From | Mark Lemmert <mark.lemmert@gmail.com> |
|---|---|
| Date | 2017-06-22 18:05 -0700 |
| Message-ID | <ff63cf1c-8e05-49f2-bc4f-c62cb55f94b5@googlegroups.com> |
| In reply to | #3574 |
On Thursday, June 22, 2017 at 7:19:57 PM UTC-5, anthon...@gmail.com wrote: > 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 curious about whether the trade-off >was really worth it and how things would have turned out if they had not skimped on the graphics. I recall this being a very interesting thread. When I made the OP, I could not have imagined it would get as comprehensive as it did with so many knowledgeable people contributing. I’m glad you found it helpful. As to Woz’s decisions about chips and the implications on the graphics scheme. My speculation is that he may have been forced to choose between bad outcomes. Clearly he was under budget constraints and if he spent more on the chips to make graphics easier, something else may have been modified with even more frustrating implications. As you noted, there is a business question of was making an extra $X in profit was worth the implications (i.e should the budget have been increased), but I wouldn’t be surprised if that was largely outside of his control. Mark
[toc] | [prev] | [next] | [standalone]
| From | awanderin <awanderin@gmail.com> |
|---|---|
| Date | 2017-06-22 23:00 -0600 |
| Message-ID | <m38tkjcn88.fsf@gmail.com> |
| In reply to | #3575 |
Mark Lemmert <mark.lemmert@gmail.com> writes: > On Thursday, June 22, 2017 at 7:19:57 PM UTC-5, anthon...@gmail.com wrote: >> 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 curious about whether the trade-off >was really worth it and >> how things would have turned out if they had not skimped on the >> graphics. > > > I recall this being a very interesting thread. When I made the OP, I > could not have imagined it would get as comprehensive as it did with > so many knowledgeable people contributing. I’m glad you found it > helpful. > > As to Woz’s decisions about chips and the implications on the graphics > scheme. My speculation is that he may have been forced to choose > between bad outcomes. Clearly he was under budget constraints and if > he spent more on the chips to make graphics easier, something else may > have been modified with even more frustrating implications. > > As you noted, there is a business question of was making an extra $X > in profit was worth the implications (i.e should the budget have been > increased), but I wouldn’t be surprised if that was largely outside of > his control. I think the speculation on our parts is all hindsight. From everything I've read about Woz, including what he's said himself, he was trying to minimize the chip count. That he got color lo-res, plus hi-res as a bonus, was probably quite satisfying to him at the time. He had no interest in the business side of things; that was Jobs' contribution. And there was no way that either of them could tell that the Apple II was going to take off like it did. After it became successful, there was the issue of compatibility. We could speculate on and on about what could have been done. In fact, this newsgroup has seen quite a number of such discussions over the years. :) When you read about the attitude within Apple during the late 70s and early 80s, they thought the Apple II would "run out of gas" a lot sooner than it did. Coupled with their plans with the Apple III, Lisa, and Macintosh, I doubt they wanted anything to steal the thunder from the new machines. Thus, no "great" graphics improvements. Even the IIgs, while it sported higher resolution and better colors, did not provide state-of-the-art hardware-enabled speedups for graphics. Its graphics were still bottlenecked by the 1MHz bus. Just to add another idea about what they could have done... they could have left the original 40-column mode and its graphics (lo-res and 280-dot hi-res) as-is, but added new video modes in the IIe that were completely decoupled from the old ones. Or even defined a "standard" video card that provided better video capabilities with support from the firmware and DOS/ProDOS, along with room for future improvements. This wouldn't have caused any backwards incompatibility, anymore than the IIe's 80-column mode or double-hi-res did. It might have even allowed for third-parties to offer hardware acceleration with full compatibility. But as it is, they chose the simplest way to squeeze a bit more out of the fewest additional components. -- -- Jerry awanderin at gmail dot com
[toc] | [prev] | [next] | [standalone]
| From | Michael J. Mahon <mjmahon@aol.com> |
|---|---|
| Date | 2017-06-23 12:59 -0500 |
| Message-ID | <lvOdnWm8A7pjy9DEnZ2dnUU7-QfNnZ2d@giganews.com> |
| In reply to | #3575 |
Mark Lemmert <mark.lemmert@gmail.com> wrote: > On Thursday, June 22, 2017 at 7:19:57 PM UTC-5, anthon...@gmail.com wrote: >> 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 curious about whether the trade-off >was really worth >>> it and how things would have turned out if they had not skimped on the graphics. > > > I recall this being a very interesting thread. When I made the OP, I > could not have imagined it would get as comprehensive as it did with so > many knowledgeable people contributing. I’m glad you found it helpful. > > As to Woz’s decisions about chips and the implications on the graphics > scheme. My speculation is that he may have been forced to choose between > bad outcomes. Clearly he was under budget constraints and if he spent > more on the chips to make graphics easier, something else may have been > modified with even more frustrating implications. > > As you noted, there is a business question of was making an extra $X in > profit was worth the implications (i.e should the budget have been > increased), but I wouldn’t be surprised if that was largely outside of his control. > > > > Mark > > 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
[toc] | [prev] | [next] | [standalone]
| From | David Schmenk <dschmenk@gmail.com> |
|---|---|
| Date | 2017-06-23 13:12 -0700 |
| Message-ID | <6b01066f-1d4b-41c1-9298-c5bd5b64b956@googlegroups.com> |
| In reply to | #3580 |
On Friday, 23 June 2017 10:59:32 UTC-7, mjm...@aol.com wrote: > Mark Lemmert <mark.lemmert@gmail.com> wrote: > > On Thursday, June 22, 2017 at 7:19:57 PM UTC-5, anthon...@gmail.com wrote: > >> 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 curious about whether the trade-off >was really worth > >>> it and how things would have turned out if they had not skimped on the graphics. > > > > > > I recall this being a very interesting thread. When I made the OP, I > > could not have imagined it would get as comprehensive as it did with so > > many knowledgeable people contributing. I’m glad you found it helpful. > > > > As to Woz’s decisions about chips and the implications on the graphics > > scheme. My speculation is that he may have been forced to choose between > > bad outcomes. Clearly he was under budget constraints and if he spent > > more on the chips to make graphics easier, something else may have been > > modified with even more frustrating implications. > > > > As you noted, there is a business question of was making an extra $X in > > profit was worth the implications (i.e should the budget have been > > increased), but I wouldn’t be surprised if that was largely outside of his control. > > > > > > > > Mark > > > > > > 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 And to add to that, in 1977, 16K was a good amount of memory. Woz's design allowed for useful hi-res color graphics in a 16K machine! If you ever wondered why the page 1 of hires screen memory is where it is, it takes up the top 8K of a 16K machine. And then he had the foresight to add page 2 for double buffered graphics - truly an advanced concept then.
[toc] | [prev] | [next] | [standalone]
| From | Michael Pohoreski <michael.pohoreski@gmail.com> |
|---|---|
| Date | 2017-06-25 07:30 -0700 |
| Message-ID | <b069efea-9b9f-445e-b862-a4d171d62094@googlegroups.com> |
| In reply to | #3580 |
> 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.
You mean TWO less-then-a-page tables, assuming you are using page = 256 bytes 6502 nomenclature. :-)
Low-Byte array size = 192 bytes
High-Byte array size 192 bytes
192+192 = 384 bytes, or a page-and-a-half.
> 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!
Right, but let's analyze WHY.
When I first got in Apple graphics back in the 80's I used to naively kevitch (internally) about the non-linear framebuffer as well.
But after working with it I realized the non-linear memory layout of the HGR screen
would have made absolutely NO difference -- one STILL would have had a Y lookup table!
Let's pretend Woz made the HGR screen linear. Sure you could have optimized the calculation:
ScanLineAddress = y * 40
with a few lines of assembly as the simplification:
y*32 + y*8
But it is FAR faster to just get the start of an HGR scanline from a 16-bit table ...
LDA HgrLoByte,Y
STA HgrPtr+0
LDA HgrHiByte,Y
STA HgrPtr+1
... regardless if the framebuffer is linear or not.
Now contrast to the (imaginary) linear non-table version:
; Demo of Imaginary Linear Framebuffer
HgrPtr EQU $E5 ; Low byte Pointer to screen destination
Yx8Lo EQU $F5 ;
Yx8Hi EQU $F6 ;
PRNTAX EQU $F941
PRBYTE EQU $FDDA
COUT EQU $FDED
ORG $0900
LDY #191 ; 191*40 = 7640 ($1DD8) + $2000 = $3DD8
TYA
JSR GetHgrAddress
TYA
JSR PRBYTE
LDA #'=' + $80
JSR COUT
LDA HgrPtr+1
ORA #$20
LDX HgrPtr+0
JMP PRNTAX
; INPUT: Y coordinate in A
; ALIAS: MulY40
; y*40 = y*32 + y*8
; = y*(2^5) + y*(2^3)
GetHgrAddress
LDX #0
STX HgrPtr+1 ; High C Low
CLC ; y=00000000 0 abcdefgh
ROL ; y=00000000 a bcdefgh0
ROL HgrPtr+1 ; y=0000000a a bcdefgh0 y*2
ROL ; y=0000000a b cdefgh00
ROL HgrPtr+1 ; y=000000ab b cdefgh00 y*4
ROL ; y=000000ab c defgh000
ROL HgrPtr+1 ; y=00000abc c defgh000 y*8
STA Yx8Lo ; save partial result y*8
LDX HgrPtr+1 ; so we can add it to y*32 later
STX Yx8Hi
ROL ; y=00000abc d efgh0000
ROL HgrPtr+1 ; y=0000abcd d efgh0000 y*16
ROL ; y=0000abcd e fgh00000
ROL HgrPtr+1 ; y=000abcde e fgh00000 y*32
CLC ; fgh00000
ADC Yx8Lo ; + defgh000
STA HgrPtr+0 ; = y*32 + y*8 low byte
LDA Yx8Hi ; 00000abc
ADC HgrPtr+1 ; + 000abcde
STA HgrPtr+1 ; = y*32 + y*8 high byte
RTS
Which produces this binary ...
0900:A0 BF 98 20 18 09 98 20
0908:DA FD A9 BD 20 ED FD A5
0910:E6 09 20 A6 E5 4C 41 F9
0918:A2 00 86 E6 18 2A 26 E6
0920:2A 26 E6 2A 26 E6 85 F5
0928:A6 E6 86 F6 2A 26 E6 2A
0930:26 E6 18 65 F5 85 E5 A5
0938:F6 65 E6 85 E6 60
... and gives this output for y=191
BF=3DD8
One can view the various y*40 results by setting 901 to the desired Y value.
i.e.
901:1
900G
01=2028
901:2
900G
02=2050
So instead of using the current HGR table of ...
; Non-Linear Framebuffer
aHGRloY
DB $00,$00,$00,$00,$00,$00,$00,$00 ; 0
DB $80,$80,$80,$80,$80,$80,$80,$80 ; 8
aHGRhiY
DB $00,$04,$08,$0C,$10,$14,$18,$1C ; 0
DB $00,$04,$08,$0C,$10,$14,$18,$1C ; 8
etc.
all that would changed would be the data.
; Linear Framebuffer
aHGRloY
DB $00,$28,$50,$78,$A0,$C8,$F0,$18 ; 0
DB $40,$68,$90,$B8,$E0,$08,$30,$58 ; 8
aHGRhiY
DB $00,$00,$00,$00,$00,$00,$00,$01 ; 0
DB $01,$01,$01,$01,$01,$02,$02,$02 ; 8
Considering that almost every game used a Y lookup table,
nothing would have changed.
QED.
[toc] | [prev] | [next] | [standalone]
| From | anthonypaulo@gmail.com |
|---|---|
| Date | 2017-06-25 08:30 -0700 |
| Message-ID | <ba4f2451-8c20-4f9a-b5e8-7f8d99597172@googlegroups.com> |
| In reply to | #3580 |
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.
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.sys.apple2.programmer
csiph-web