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 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | dempson@actrix.gen.nz (David Empson) |
|---|---|
| Date | 2016-02-19 12:47 +1300 |
| Message-ID | <1miv8wg.13wdyyn1g1arm3N%dempson@actrix.gen.nz> |
| In reply to | #2271 |
<denisbytezone@gmail.com> wrote: > On Tuesday, 16 February 2016 14:39:28 UTC+11, gid...@sasktel.net wrote: > > bit # > > 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 > > > > color bit color bit > > | | > > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > > |_| |_| |_| |_____| |_| |_| |_| > > > > 0 1 2 3 4 5 6 > > > > Is this to do with double hi-res, or something else I completely > misunderstand? Because according to the Apple II reference manual every > bit maps to a pixel and there is no concept of odd/even bytes. When a composite colour display is connected to an Apple II, standard hi-res graphics displays colour using a system where two adjacent monochrome pixels generate a particular frequency which results in a single colour pixel (up to twice as wide as a monochrome pixel, depending on the response of the display). The colour is determined by the bit pattern of the pair (00, 01, 10 or 11), and modified by the bit 7 of the byte, which controls a half-bit shift in timing of the output (one cycle at 14.31818 MHz in the case of an NTSC model). Odd/even bytes are signficant because there are 7 bits per byte which drive pixels, so a pixel pair straddles the byte boundary at the even to odd address boundaries (pixel 3 in the diagram above). This mechanism is emulated (to varying degrees of success) by various RGB display hardware options which can be used with Apple II models (or built in, for the IIgs). Double hi-res has more colours available than standard hi-res because it is higher frequency (14 MHz instead of 7 MHz) and therefore has more bit patterns which can be output in the same amount of time, resulting in the full selection of 16 colours (same as lo-res and double lo-res). > In the scheme described above, which color bit controls pixel #3? I'd have to look up a reference or do some testing (with a monitor I don't have) to confirm, but I think it is both of them. If the colour bits are different, it changes the relative output timing of the first and second bits, which will change the pixel colour. This results in unusual colours like yellow, brown, light blue and dark blue, which can only appear (apart from fringing effects) at the even-to-odd byte boundaries, i.e. colour pixel 3 and every subsequent 7 pixels. https://en.wikipedia.org/wiki/Apple_II_graphics More specifically, this colour chart (for lo-res graphics, also double hi-res though possibly in a different order) is helpful: https://en.wikipedia.org/wiki/File:Apple_II_low-resolution_graphics_demo_2.png The standard hi-res colours are the top left, bottom right, and the trailing diagonal from top right to bottom left. The "unsual" colours for pixel 3, 10, ... are the next two that complete the squares in the top right and bottom left corners (colours 2 and 7, and 8 and 13). Standard hi-res can't generate the remaining colours. -- David Empson dempson@actrix.gen.nz
[toc] | [prev] | [next] | [standalone]
| From | gids.rs@sasktel.net |
|---|---|
| Date | 2016-02-18 15:49 -0800 |
| Message-ID | <25676807-9ee4-4710-9e00-c31267428963@googlegroups.com> |
| In reply to | #2271 |
On Thursday, February 18, 2016 at 4:53:50 PM UTC-6, denisb...@gmail.com wrote: > On Tuesday, 16 February 2016 14:39:28 UTC+11, gid...@sasktel.net wrote: > > bit # > > 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 > > > > color bit color bit > > | | > > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > > |_| |_| |_| |_____| |_| |_| |_| > > > > 0 1 2 3 4 5 6 > > > > Is this to do with double hi-res, or something else I completely misunderstand? Because according to the Apple II reference manual every bit maps to a pixel and there is no concept of odd/even bytes. > > In the scheme described above, which color bit controls pixel #3? forgot to answer your last question. only one of the two bits that make up pixel#3 can be on, otherwise if both are on you will see a white pixel. If both are off you will see black. if the first bit that makes up pixel#3 is on, then the color bit of the first byte designates the color. if the second bit that makes up pixel#3 is on, then the color bit of the second byte designates the color of that pair. Try this on your computer. ]HGR ]CALL -151 (violet pixel) *2000:40 00 *2400:40 00 *2800:40 00 (blue pixel) *2000:C0 00 *2400:C0 00 *2800:C0 00 (green pixel) *2000:00 01 *2400:00 01 *2800:00 01 (orange pixel) 2000:00 81 2400:00 81 2800:00 81
[toc] | [prev] | [next] | [standalone]
| From | gids.rs@sasktel.net |
|---|---|
| Date | 2016-02-18 16:02 -0800 |
| Message-ID | <cbb82701-54d3-4da7-9dec-bf1c86ac64ae@googlegroups.com> |
| In reply to | #2279 |
On Thursday, February 18, 2016 at 5:49:39 PM UTC-6, gid...@sasktel.net wrote: > On Thursday, February 18, 2016 at 4:53:50 PM UTC-6, denisb...@gmail.com wrote: > > On Tuesday, 16 February 2016 14:39:28 UTC+11, gid...@sasktel.net wrote: > > > bit # > > > 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 > > > > > > color bit color bit > > > | | > > > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > > > |_| |_| |_| |_____| |_| |_| |_| > > > > > > 0 1 2 3 4 5 6 > > > > > > > Is this to do with double hi-res, or something else I completely misunderstand? Because according to the Apple II reference manual every bit maps to a pixel and there is no concept of odd/even bytes. > > > > In the scheme described above, which color bit controls pixel #3? > > > forgot to answer your last question. > only one of the two bits that make up pixel#3 can be on, otherwise if both are on you will see a white pixel. If both are off you will see black. > > if the first bit that makes up pixel#3 is on, then the color bit of the first byte designates the color. > > if the second bit that makes up pixel#3 is on, then the color bit of the second byte designates the color of that pair. > > Try this on your computer. > > ]HGR > ]CALL -151 > > (violet pixel) > *2000:40 00 > *2400:40 00 > *2800:40 00 > > (blue pixel) > *2000:C0 00 > *2400:C0 00 > *2800:C0 00 > > (green pixel) > *2000:00 01 > *2400:00 01 > *2800:00 01 > > (orange pixel) > 2000:00 81 > 2400:00 81 > 2800:00 81 What this also means is that the other 3 pixels in each byte are also dependent on the color bit. That is why you cannot display violet or green, and, blue or orange in the same byte. And although the second byte shares a bit with the first byte, you can still display the first byte as violet/green and the second byte as blue/orange. And pixel #3 takes on the color of the byte where it's bit is turned on.
[toc] | [prev] | [next] | [standalone]
| From | Michael Pohoreski <michael.pohoreski@gmail.com> |
|---|---|
| Date | 2016-02-16 11:34 -0800 |
| Message-ID | <b64335b2-1a44-4be6-8426-115034a2ad5e@googlegroups.com> |
| In reply to | #2226 |
You'll be interested in my HGR Byte Inspector that lets you play with all the fun graphics bit twiddling. :-)
I'll be throwing this up on GitHub soonish.
0900:A9 0C 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 F8 09 F0 3C 9D D0 06
0928:E8 D0 F5 A5 FD 29 01 AA
0930:9D 52 C0 A5 FD 49 01 85
0938:FD 18 90 40 49 80 18 90
0940:34 C6 FF 10 24 E6 FF A5
0948:FF C9 28 B0 F4 90 1A C6
0950:E2 A5 E2 C9 FF D0 12 E6
0958:E2 A5 E2 C9 C0 B0 F0 90
0960:08 A9 14 85 FF A9 60 85
0968:E2 A0 00 A2 00 A5 E2 20
0970:11 F4 20 C1 0A 85 FC 85
0978:FB 20 1E 0A A5 FB 49 FF
0980:85 FB 20 C7 0A AD 00 C0
0988:10 F2 8D 10 C0 29 7F A2
0990:1F DD CC 0A F0 05 CA 10
0998:F8 30 E1 A9 09 48 BD EC
09A0:0A 48 A5 FC 20 C7 0A 60
09A8:A9 FF D0 C9 A9 00 F0 C5
09B0:A2 FF D0 36 38 B0 02 C9
09B8:80 2A 18 90 B8 09 01 4A
09C0:90 B3 09 80 B0 AF 0A A2
09C8:4A 18 90 A9 A2 01 D0 1A
09D0:A2 02 D0 16 A2 04 D0 12
09D8:A2 08 D0 0E A2 10 D0 0A
09E0:A2 20 D0 06 A2 40 D0 02
09E8:A2 80 86 FE 45 FE 18 90
09F0:84 85 FA A5 FA 18 90 F6
09F8:A0 A0 A0 A0 A0 A0 A0 A0
0A00:A0 A0 A0 A0 D3 C1 D6 C5
0A08:BA BF BF A0 B7 B6 B5 B4
0A10:B3 B2 B1 B0 A0 31 32 33
0A18:34 35 36 37 38 00 A9 00
0A20:85 24 A9 14 20 5B FB A9
0A28:D8 20 ED FD A5 FF 20 D3
0A30:FD A9 A0 20 ED FD A9 D9
0A38:20 ED FD A5 E2 20 D3 FD
0A40:A9 A0 20 ED FD A9 A4 20
0A48:ED FD A5 27 20 D3 FD A5
0A50:26 18 65 FF 20 DA FD A9
0A58:BA 20 ED FD A5 FC 20 DA
0A60:FD A9 A0 20 ED FD A2 08
0A68:A5 FC 85 FE 06 FE 6A CA
0A70:D0 FA 85 FE 48 A2 08 A5
0A78:FE 20 B6 0A 66 FE CA D0
0A80:F6 A9 FE 20 ED FD A2 08
0A88:A5 FC A8 20 B6 0A 98 4A
0A90:CA D0 F7 A9 A4 20 ED FD
0A98:68 20 DA FD A5 FA 48 4A
0AA0:4A 4A 4A 20 A7 0A 68 29
0AA8:0F 09 30 C9 3A 90 02 E9
0AB0:39 9D E1 06 E8 60 29 01
0AB8:F0 02 A9 81 49 B0 4C ED
0AC0:FD A4 FF B1 26 85 FC A4
0AC8:FF 91 26 60 1B 0D 08 15
0AD0:0B 0A 49 4A 4B 4C 09 31
0AD8:32 33 34 35 36 37 38 20
0AE0:39 30 60 7E 2C 3C 2E 3E
0AE8:5B 5D 3D 2D A6 2A 40 44
0AF0:4E 56 4E 40 56 44 60 CB
0AF8:CF D3 D7 DB DF E3 E7 3B
0B00:A7 AB AF AF C5 B3 C7 BC
0B08:B6 BE F0 F2
Here is the source assembly:
(Requires ca65 to assemble + link)
; HGR Byte Inspector
; Michael Pohoreski
; Version 12
;
; Keys:
;
; ESC Quit
; CR Toggle fullscreen
;
; <- Move cursor left
; -> Move cursor right
; Up Move cursor up
; Down Move cursor down
;
; I Move cursor up
; J Move cursor left
; K Move cursor right
; L Move cursor down
; TAB Center cursor
;
; 1 Toggle bit 0
; 2 Toggle bit 1
; 3 Toggle bit 2
; 4 Toggle bit 3
; 5 Toggle bit 4
; 6 Toggle bit 5
; 7 Toggle bit 6
; 8 Toggle bit 7 (high bit)
; SPC Toggle high bit of byte (bit 7)
; 9 Set byte to $FF
; 0 Clear byte to $00
; ` 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
; - Restore saved byte
; Force APPLE 'text' to have high bit on
; Will display as NORMAL characters
.macro APPLE text
.repeat .strlen(text), I
.byte .strat(text, I) | $80
.endrep
.endmacro
; Force ASCII 'text' to be control chars: $00..$1F
; Will display as INVERSE characters
.macro CTRL text
.repeat .strlen(text), I
.byte .strat(text, I) & $1F
.endrep
.endmacro
; Force ASCII 'text' to be control chars: $00..$3F
; Will display as INVERSE characters
.macro INV text
.repeat .strlen(text), I
.byte .strat(text, I) & $3F
.endrep
.endmacro
GBASL = $26
GBASH = $27
CH = $24 ; text cursor column
CV = $25 ; text cursor row
ROW_20 = $0550 ; VTAB 21 TEXT address
ROW_21 = $06D0 ; VTAB 22 TEXT address
ROW_22 = $0750 ; VTAB 23 TEXT address
ROW_23 = $07D0 ; VTAB 24 TEXT address
HPOSN = $F411 ; A=row, Y,X=col update GBASL GBASH
TABV = $FB5B ; A=row, ALL STA $25, JMP $FC22
VTAB = $FC22 ; $25=row //e LDA $25, STA$28
HOME = $FC58
COUT = $FDED
PR_HEX = $FDD3
PRBYTE = $FDDA
KEYBOARD = $C000
KEYSTROBE = $C010
TXTCLR = $C050 ; Mode Graphics
MIXCLR = $C052 ; Full screen
MIXSET = $C053 ; Split screen
PAGE1 = $C054
HIRES = $C057 ; Mode HGR
cursor_row = $E2 ; used by Applesoft HGR.row
cursor_org = $FA ; When cursor is saved
cursor_tmp = $FB ; Flashing cursor byte
cursor_val = $FC ; Current byte under cursor
flags = $FD ;
temp = $FE
cursor_col = $FF
FLAG_FULL = $01 ; == $1 -> $C052 MIXCLR
; ; == $0 -> $C053 MIXSET
HGRPAGE = $E6 ; used by Applesoft HGR.page
__MAIN= $0900
.word __MAIN ; 2 byte BLOAD address
.word __END - __MAIN ; 2 byte BLOAD size
.org __MAIN ; .org must come after header else offsets are wrong
HgrByte:
LDA #12 ; Version
BIT PAGE1 ; Page 1
BIT TXTCLR ; not text, but graphics
BIT MIXSET ; Split screen text/graphics
BIT HIRES ; HGR, no GR
LDX #0 ; also used by PrintFooter
STX flags
STX cursor_col
STX cursor_row
STX cursor_org
STX GBASL
LDA #$20
STA GBASH
STA HGRPAGE
PrintFooter:
LDA TextFooter, X
BEQ _Center ; Default to center of screen
STA ROW_21,X ; 4 line text window, 2nd row
INX
BNE PrintFooter ; (almost) always
; Funcs that JMP to GetByte before GotKey()
; Funcs that JMP to PutByte after GotKey()
_Screen: ; Toggle mixed/full screen
LDA flags ; A = %????_????
AND #FLAG_FULL ; A = %0000_000f
TAX ; f=0 f=1
STA MIXCLR,X ; C052 C053
LDA flags ; FULL MIX
EOR #FLAG_FULL ; mode is based on old leading edge
STA flags ; not new trailing edge
CLC
BCC FlashByte ; always
_HighBit:
EOR #$80
CLC
BCC PutByte
_MoveL: DEC cursor_col
BPL GetByte
_MoveR: INC cursor_col
LDA cursor_col
CMP #40
BCS _MoveL
BCC GetByte ; always
_MoveU: DEC cursor_row
LDA cursor_row
CMP #$FF
BNE GetByte ; INTENTIONAL fall into if Y < 0
_MoveD: INC cursor_row
LDA cursor_row
CMP #192
BCS _MoveU
BCC GetByte ; always
_Center:
LDA #40/2
STA cursor_col
LDA #192/2
STA cursor_row ; intentional fall into GetByte
GetByte: ; Cursor position changed
LDY #0 ; Update pointer to screen
LDX #0
LDA cursor_row
JSR HPOSN ; A=row, Y,X=col X->E0 Y->E1
JSR GetCursorByte
PutByte:
STA cursor_val ; current value
STA cursor_tmp ; flashing cursor
JSR DrawStatus
FlashByte:
LDA cursor_tmp
EOR #$FF
STA cursor_tmp
JSR SetCursorByte
GetKey:
LDA KEYBOARD
BPL FlashByte
STA KEYSTROBE
AND #$7F ; Force ASCII
LDX #nKeys-1
FindKey:
CMP aKeys, X
BEQ GotKey
DEX
BPL FindKey
BadKey:
BMI FlashByte
GotKey:
; If code doesn't fit withing +/-127 bytes
; LDA aFuncHi, X
LDA #>HgrByte ; FuncAddressHi
PHA
LDA aFuncLo, X ; FuncAddressLo
PHA
LDA cursor_val ; Last displayed byte may be cursor_tmp
JSR SetCursorByte ; restore current val in case cursor moves
; Also pre-load for ROL/R SHL/R
_Exit: RTS ; And call function assigned to key
; To BRUN under DOS.3 change above RTS to
; RTS
;_Exit: JMP $3D0 ; DOS 3.3 Warmstart vector
; Functions starting with _ are invoked via keys
_ByteFF:
LDA #$FF
BNE PutByte ; always
_Byte00:
LDA #$00
BEQ PutByte ; always
_FlipByte:
LDX #$FF
BNE TogBit
_SHL1: SEC ; Force C=1 via ROL
BCS _Rol1
_Rol: CMP #$80 ; C=a A=%abcd_efgh
_Rol1: ROL ; C=b A=%bcde_fgha C<-bit7, bit0<-C
CLC ; force branch always
BCC PutByte
_SHR1: ORA #$01 ; Force C=1 via ROR (SHR, OR #$80)
; Intentional fall into _Ror
; Using LSR instead of ROR to save a byte
; 8 Byte version
; CLC
; ROR
; BCC PutByte
; ORA #$80
; BCS PutByte
_Ror: LSR ; C=h A=%0abc_defg 0->bit7, bit0->C
BCC PutByte
ORA #$80
BCS PutByte ; always
_ShiftL:ASL ; C=a A=%bcde_fgh0
.byte $A2 ; skip next LSR instruction; LDX dummy imm val
_ShiftR:LSR ; C=h A=%0abc_defg
CLC
BCC PutByte ; always
_Bit0: LDX #%00000001
BNE TogBit ; always
_Bit1: LDX #%00000010
BNE TogBit ; always
_Bit2: LDX #%00000100
BNE TogBit ; always
_Bit3: LDX #%00001000
BNE TogBit ; always
_Bit4: LDX #%00010000
BNE TogBit ; always
_Bit5: LDX #%00100000
BNE TogBit ; always
_Bit6: LDX #%01000000
BNE TogBit ; always
_Bit7: LDX #%10000000 ; intentional fall into
; common _Bit# code
TogBit: STX temp
EOR temp
GotoPutByte:
CLC ; code is too far to directly branch
BCC PutByte ; to PutByte, use as trampoline
_SaveByte:
STA cursor_org ; intentional fall into
_LoadByte:
LDA cursor_org
CLC
BCC GotoPutByte ; always
TextFooter:
; "X=## Y=## $=####:## %%%%%%%%~%%%%%%%%"
APPLE " SAVE:?? 76543210 "
INV "12345678" ;1-8 INVERSE
.byte $00
DrawStatus:
LDA #0 ; Cursor.X = 0
STA CH
LDA #20 ; Cursor.Y = Top of 4 line split TEXT/HGR window
JSR TABV ; update CV
PrintStatus:
LDA #'X'+$80 ; X=## Y=## $=####:##
JSR COUT
LDA cursor_col
JSR PR_HEX
LDA #' '+$80
JSR COUT
LDA #'Y'+$80
JSR COUT
LDA cursor_row
JSR PR_HEX
LDA #' '+$80
JSR COUT
LDA #'$'+$80
JSR COUT
LDA GBASH
JSR PR_HEX
LDA GBASL
CLC
ADC cursor_col
JSR PRBYTE
LDA #':'+$80
JSR COUT
LDA cursor_val
JSR PRBYTE
LDA #' '+$80
JSR COUT
ReverseByte:
LDX #8
LDA cursor_val
STA temp
ReverseBit:
ASL temp
ROR
DEX
BNE ReverseBit
STA temp
PHA ; save reverse byte
LDX #8
PrintBitsNormal:
LDA temp
JSR Bit2Asc
ROR temp
DEX
BNE PrintBitsNormal
LDA #'~'+$80
JSR COUT
LDX #8
LDA cursor_val
PrintBitsReverse:
TAY
JSR Bit2Asc
TYA
LSR
DEX
BNE PrintBitsReverse
LDA #'$'+$80
JSR COUT
PLA ; restore reverse byte
JSR PRBYTE
LDA cursor_org ; X=0
PHA
LSR
LSR
LSR
LSR
JSR NibToInvTxt
PLA
; Display nibble as inverse text
; 0 -> '0' $30
; 9 -> '9' $39
; A -> ^A $01
; F -> ^F $06
NibToInvTxt:
AND #$F
ORA #'0'+$00 ; ASCII: +$80
CMP #'9'+$01 ; ASCII: +$81
BCC PrintSave
SBC #$39 ; C=1, $3A ':' -> $01 'A', $3F '?' -> $06
PrintSave:
STA ROW_21+17,X
INX
RTS
Bit2Asc:
AND #$01 ; 0 -> B0
BEQ FlipBit
LDA #$81 ; 1 -> 31
FlipBit:
EOR #$B0
JMP COUT
; A = byte
GetCursorByte:
LDY cursor_col
LDA (GBASL),Y
STA cursor_val
SetCursorByte:
LDY cursor_col
STA (GBASL),Y
RTS
; Keys are searched in reverse order
; Sorted by least used to most used
aKeys:
CTRL "[" ; _Exit ESC Quit
CTRL "M" ; _Screen RET Toggle fullscreen
CTRL "H" ; _MoveL <- Ctrl-H $08
CTRL "U" ; _MoveR -> Ctrl-U $15
CTRL "K" ; _MoveU Up Ctrl-K $0B
CTRL "J" ; _MoveD Down Ctrl-J $0A
.byte "I" ; _MoveU Move cursor Up
.byte "J" ; _MoveL Move cursor Left
.byte "K" ; _MoveD Move cursor Down
.byte "L" ; _MoveR Move cursor Right
CTRL "I" ; _Center Center cursor
.byte "1" ; _Bit0 Toggle bit 0
.byte "2" ; _Bit1 Toggle bit 1
.byte "3" ; _Bit2 Toggle bit 2
.byte "4" ; _Bit3 Toggle bit 3
.byte "5" ; _Bit4 Toggle bit 4
.byte "6" ; _Bit5 Toggle bit 5
.byte "7" ; _Bit6 Toggle bit 6
.byte "8" ; _Bit7 Toggle bit 7
.byte " " ; _HighBit Toggle high bit of byte (bit 7)
.byte "9" ; _ByteFF Set byte to FF
.byte "0" ; _Byte00 Set byte to 00
.byte "`" ; _FlipByte Toggle all bits
.byte "~" ; _FlipByte
.byte "," ; _ShiftL (with zero)
.byte "<" ; _ShiftL (with one )
.byte "." ; _ShiftR (with zero)
.byte ">" ; _ShiftR (with one )
.byte "[" ; _Rol
.byte "]" ; _Ror
.byte "=" ; _SaveByte Save current byte to temporary
.byte "-" ; _LoadByte Load temporary to current byte
eKeys:
nKeys = eKeys - aKeys ;
; Table of function pointers
; *Note*: Must match aKeys order!
aFuncLo:
.byte <_Exit -1 ; ESC
.byte <_Screen -1 ; RET
.byte <_MoveL -1 ; <-
.byte <_MoveR -1 ; ->
.byte <_MoveU -1 ; UP
.byte <_MoveD -1 ; DN
.byte <_MoveU -1 ; 'I'
.byte <_MoveL -1 ; 'J'
.byte <_MoveD -1 ; 'K'
.byte <_MoveR -1 ; 'L'
.byte <_Center -1 ; Ctrl-I
.byte <_Bit0 -1 ; '1'
.byte <_Bit1 -1 ; '2'
.byte <_Bit2 -1 ; '3'
.byte <_Bit3 -1 ; '4'
.byte <_Bit4 -1 ; '5'
.byte <_Bit5 -1 ; '6'
.byte <_Bit6 -1 ; '7'
.byte <_Bit7 -1 ; '8'
.byte <_HighBit -1 ; SPC
.byte <_ByteFF -1 ; '9'
.byte <_Byte00 -1 ; '0'
.byte <_FlipByte-1 ; '`'
.byte <_FlipByte-1 ; '~' not a dup mistake
.byte <_ShiftL -1 ; `,`
.byte <_SHL1 -1 ; `<`
.byte <_ShiftR -1 ; `.`
.byte <_SHR1 -1 ; `>`
.byte <_Rol -1 ; '['
.byte <_Ror -1 ; ']
.byte <_SaveByte-1 ; '='
.byte <_LoadByte-1 ; '-'
__END:
[toc] | [prev] | [next] | [standalone]
| From | Mark Lemmert <mark.lemmert@gmail.com> |
|---|---|
| Date | 2016-02-16 12:00 -0800 |
| Message-ID | <da224d89-ac70-4adf-b8ad-f091405d37fa@googlegroups.com> |
| In reply to | #2242 |
On Tuesday, February 16, 2016 at 1:34:49 PM UTC-6, Michael Pohoreski wrote: > You'll be interested in my HGR Byte Inspector that lets you play with all the fun graphics bit twiddling. :-) > > I'll be throwing this up on GitHub soonish. > > 0900:A9 0C 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 F8 09 F0 3C 9D D0 06 > 0928:E8 D0 F5 A5 FD 29 01 AA > 0930:9D 52 C0 A5 FD 49 01 85 > 0938:FD 18 90 40 49 80 18 90 > 0940:34 C6 FF 10 24 E6 FF A5 > 0948:FF C9 28 B0 F4 90 1A C6 > 0950:E2 A5 E2 C9 FF D0 12 E6 > 0958:E2 A5 E2 C9 C0 B0 F0 90 > 0960:08 A9 14 85 FF A9 60 85 > 0968:E2 A0 00 A2 00 A5 E2 20 > 0970:11 F4 20 C1 0A 85 FC 85 > 0978:FB 20 1E 0A A5 FB 49 FF > 0980:85 FB 20 C7 0A AD 00 C0 > 0988:10 F2 8D 10 C0 29 7F A2 > 0990:1F DD CC 0A F0 05 CA 10 > 0998:F8 30 E1 A9 09 48 BD EC > 09A0:0A 48 A5 FC 20 C7 0A 60 > 09A8:A9 FF D0 C9 A9 00 F0 C5 > 09B0:A2 FF D0 36 38 B0 02 C9 > 09B8:80 2A 18 90 B8 09 01 4A > 09C0:90 B3 09 80 B0 AF 0A A2 > 09C8:4A 18 90 A9 A2 01 D0 1A > 09D0:A2 02 D0 16 A2 04 D0 12 > 09D8:A2 08 D0 0E A2 10 D0 0A > 09E0:A2 20 D0 06 A2 40 D0 02 > 09E8:A2 80 86 FE 45 FE 18 90 > 09F0:84 85 FA A5 FA 18 90 F6 > 09F8:A0 A0 A0 A0 A0 A0 A0 A0 > 0A00:A0 A0 A0 A0 D3 C1 D6 C5 > 0A08:BA BF BF A0 B7 B6 B5 B4 > 0A10:B3 B2 B1 B0 A0 31 32 33 > 0A18:34 35 36 37 38 00 A9 00 > 0A20:85 24 A9 14 20 5B FB A9 > 0A28:D8 20 ED FD A5 FF 20 D3 > 0A30:FD A9 A0 20 ED FD A9 D9 > 0A38:20 ED FD A5 E2 20 D3 FD > 0A40:A9 A0 20 ED FD A9 A4 20 > 0A48:ED FD A5 27 20 D3 FD A5 > 0A50:26 18 65 FF 20 DA FD A9 > 0A58:BA 20 ED FD A5 FC 20 DA > 0A60:FD A9 A0 20 ED FD A2 08 > 0A68:A5 FC 85 FE 06 FE 6A CA > 0A70:D0 FA 85 FE 48 A2 08 A5 > 0A78:FE 20 B6 0A 66 FE CA D0 > 0A80:F6 A9 FE 20 ED FD A2 08 > 0A88:A5 FC A8 20 B6 0A 98 4A > 0A90:CA D0 F7 A9 A4 20 ED FD > 0A98:68 20 DA FD A5 FA 48 4A > 0AA0:4A 4A 4A 20 A7 0A 68 29 > 0AA8:0F 09 30 C9 3A 90 02 E9 > 0AB0:39 9D E1 06 E8 60 29 01 > 0AB8:F0 02 A9 81 49 B0 4C ED > 0AC0:FD A4 FF B1 26 85 FC A4 > 0AC8:FF 91 26 60 1B 0D 08 15 > 0AD0:0B 0A 49 4A 4B 4C 09 31 > 0AD8:32 33 34 35 36 37 38 20 > 0AE0:39 30 60 7E 2C 3C 2E 3E > 0AE8:5B 5D 3D 2D A6 2A 40 44 > 0AF0:4E 56 4E 40 56 44 60 CB > 0AF8:CF D3 D7 DB DF E3 E7 3B > 0B00:A7 AB AF AF C5 B3 C7 BC > 0B08:B6 BE F0 F2 > > Here is the source assembly: > (Requires ca65 to assemble + link) > > > ; HGR Byte Inspector > ; Michael Pohoreski > ; Version 12 > ; > ; Keys: > ; > ; ESC Quit > ; CR Toggle fullscreen > ; > ; <- Move cursor left > ; -> Move cursor right > ; Up Move cursor up > ; Down Move cursor down > ; > ; I Move cursor up > ; J Move cursor left > ; K Move cursor right > ; L Move cursor down > ; TAB Center cursor > ; > ; 1 Toggle bit 0 > ; 2 Toggle bit 1 > ; 3 Toggle bit 2 > ; 4 Toggle bit 3 > ; 5 Toggle bit 4 > ; 6 Toggle bit 5 > ; 7 Toggle bit 6 > ; 8 Toggle bit 7 (high bit) > ; SPC Toggle high bit of byte (bit 7) > ; 9 Set byte to $FF > ; 0 Clear byte to $00 > ; ` 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 > ; - Restore saved byte > > > ; Force APPLE 'text' to have high bit on > ; Will display as NORMAL characters > .macro APPLE text > .repeat .strlen(text), I > .byte .strat(text, I) | $80 > .endrep > .endmacro > > > ; Force ASCII 'text' to be control chars: $00..$1F > ; Will display as INVERSE characters > .macro CTRL text > .repeat .strlen(text), I > .byte .strat(text, I) & $1F > .endrep > .endmacro > > > ; Force ASCII 'text' to be control chars: $00..$3F > ; Will display as INVERSE characters > .macro INV text > .repeat .strlen(text), I > .byte .strat(text, I) & $3F > .endrep > .endmacro > > GBASL = $26 > GBASH = $27 > CH = $24 ; text cursor column > CV = $25 ; text cursor row > ROW_20 = $0550 ; VTAB 21 TEXT address > ROW_21 = $06D0 ; VTAB 22 TEXT address > ROW_22 = $0750 ; VTAB 23 TEXT address > ROW_23 = $07D0 ; VTAB 24 TEXT address > > HPOSN = $F411 ; A=row, Y,X=col update GBASL GBASH > TABV = $FB5B ; A=row, ALL STA $25, JMP $FC22 > VTAB = $FC22 ; $25=row //e LDA $25, STA$28 > HOME = $FC58 > COUT = $FDED > PR_HEX = $FDD3 > PRBYTE = $FDDA > > KEYBOARD = $C000 > KEYSTROBE = $C010 > TXTCLR = $C050 ; Mode Graphics > MIXCLR = $C052 ; Full screen > MIXSET = $C053 ; Split screen > PAGE1 = $C054 > HIRES = $C057 ; Mode HGR > > cursor_row = $E2 ; used by Applesoft HGR.row > cursor_org = $FA ; When cursor is saved > cursor_tmp = $FB ; Flashing cursor byte > cursor_val = $FC ; Current byte under cursor > flags = $FD ; > temp = $FE > cursor_col = $FF > FLAG_FULL = $01 ; == $1 -> $C052 MIXCLR > ; ; == $0 -> $C053 MIXSET > HGRPAGE = $E6 ; used by Applesoft HGR.page > > __MAIN= $0900 > .word __MAIN ; 2 byte BLOAD address > .word __END - __MAIN ; 2 byte BLOAD size > .org __MAIN ; .org must come after header else offsets are wrong > > HgrByte: > LDA #12 ; Version > BIT PAGE1 ; Page 1 > BIT TXTCLR ; not text, but graphics > BIT MIXSET ; Split screen text/graphics > BIT HIRES ; HGR, no GR > > LDX #0 ; also used by PrintFooter > STX flags > STX cursor_col > STX cursor_row > STX cursor_org > STX GBASL > LDA #$20 > STA GBASH > STA HGRPAGE > PrintFooter: > LDA TextFooter, X > BEQ _Center ; Default to center of screen > STA ROW_21,X ; 4 line text window, 2nd row > INX > BNE PrintFooter ; (almost) always > > ; Funcs that JMP to GetByte before GotKey() > ; Funcs that JMP to PutByte after GotKey() > _Screen: ; Toggle mixed/full screen > LDA flags ; A = %????_???? > AND #FLAG_FULL ; A = %0000_000f > TAX ; f=0 f=1 > STA MIXCLR,X ; C052 C053 > LDA flags ; FULL MIX > EOR #FLAG_FULL ; mode is based on old leading edge > STA flags ; not new trailing edge > CLC > BCC FlashByte ; always > _HighBit: > EOR #$80 > CLC > BCC PutByte > _MoveL: DEC cursor_col > BPL GetByte > _MoveR: INC cursor_col > LDA cursor_col > CMP #40 > BCS _MoveL > BCC GetByte ; always > > _MoveU: DEC cursor_row > LDA cursor_row > CMP #$FF > BNE GetByte ; INTENTIONAL fall into if Y < 0 > _MoveD: INC cursor_row > LDA cursor_row > CMP #192 > BCS _MoveU > BCC GetByte ; always > _Center: > LDA #40/2 > STA cursor_col > LDA #192/2 > STA cursor_row ; intentional fall into GetByte > > GetByte: ; Cursor position changed > LDY #0 ; Update pointer to screen > LDX #0 > LDA cursor_row > JSR HPOSN ; A=row, Y,X=col X->E0 Y->E1 > JSR GetCursorByte > PutByte: > STA cursor_val ; current value > STA cursor_tmp ; flashing cursor > JSR DrawStatus > FlashByte: > LDA cursor_tmp > EOR #$FF > STA cursor_tmp > JSR SetCursorByte > GetKey: > LDA KEYBOARD > BPL FlashByte > STA KEYSTROBE > AND #$7F ; Force ASCII > LDX #nKeys-1 > FindKey: > CMP aKeys, X > BEQ GotKey > DEX > BPL FindKey > BadKey: > BMI FlashByte > > GotKey: > ; If code doesn't fit withing +/-127 bytes > ; LDA aFuncHi, X > LDA #>HgrByte ; FuncAddressHi > PHA > LDA aFuncLo, X ; FuncAddressLo > PHA > LDA cursor_val ; Last displayed byte may be cursor_tmp > JSR SetCursorByte ; restore current val in case cursor moves > ; Also pre-load for ROL/R SHL/R > _Exit: RTS ; And call function assigned to key > ; To BRUN under DOS.3 change above RTS to > ; RTS > ;_Exit: JMP $3D0 ; DOS 3.3 Warmstart vector > > ; Functions starting with _ are invoked via keys > _ByteFF: > LDA #$FF > BNE PutByte ; always > _Byte00: > LDA #$00 > BEQ PutByte ; always > _FlipByte: > LDX #$FF > BNE TogBit > _SHL1: SEC ; Force C=1 via ROL > BCS _Rol1 > _Rol: CMP #$80 ; C=a A=%abcd_efgh > _Rol1: ROL ; C=b A=%bcde_fgha C<-bit7, bit0<-C > CLC ; force branch always > BCC PutByte > > _SHR1: ORA #$01 ; Force C=1 via ROR (SHR, OR #$80) > ; Intentional fall into _Ror > ; Using LSR instead of ROR to save a byte > ; 8 Byte version > ; CLC > ; ROR > ; BCC PutByte > ; ORA #$80 > ; BCS PutByte > _Ror: LSR ; C=h A=%0abc_defg 0->bit7, bit0->C > BCC PutByte > ORA #$80 > BCS PutByte ; always > > _ShiftL:ASL ; C=a A=%bcde_fgh0 > .byte $A2 ; skip next LSR instruction; LDX dummy imm val > _ShiftR:LSR ; C=h A=%0abc_defg > CLC > BCC PutByte ; always > > _Bit0: LDX #%00000001 > BNE TogBit ; always > _Bit1: LDX #%00000010 > BNE TogBit ; always > _Bit2: LDX #%00000100 > BNE TogBit ; always > _Bit3: LDX #%00001000 > BNE TogBit ; always > _Bit4: LDX #%00010000 > BNE TogBit ; always > _Bit5: LDX #%00100000 > BNE TogBit ; always > _Bit6: LDX #%01000000 > BNE TogBit ; always > _Bit7: LDX #%10000000 ; intentional fall into > > ; common _Bit# code > TogBit: STX temp > EOR temp > GotoPutByte: > CLC ; code is too far to directly branch > BCC PutByte ; to PutByte, use as trampoline > _SaveByte: > STA cursor_org ; intentional fall into > _LoadByte: > LDA cursor_org > CLC > BCC GotoPutByte ; always > > TextFooter: > ; "X=## Y=## $=####:## %%%%%%%%~%%%%%%%%" > APPLE " SAVE:?? 76543210 " > INV "12345678" ;1-8 INVERSE > .byte $00 > > DrawStatus: > LDA #0 ; Cursor.X = 0 > STA CH > LDA #20 ; Cursor.Y = Top of 4 line split TEXT/HGR window > JSR TABV ; update CV > PrintStatus: > LDA #'X'+$80 ; X=## Y=## $=####:## > JSR COUT > LDA cursor_col > JSR PR_HEX > LDA #' '+$80 > JSR COUT > LDA #'Y'+$80 > JSR COUT > LDA cursor_row > JSR PR_HEX > LDA #' '+$80 > JSR COUT > LDA #'$'+$80 > JSR COUT > LDA GBASH > JSR PR_HEX > LDA GBASL > CLC > ADC cursor_col > JSR PRBYTE > LDA #':'+$80 > JSR COUT > LDA cursor_val > JSR PRBYTE > LDA #' '+$80 > JSR COUT > > ReverseByte: > LDX #8 > LDA cursor_val > STA temp > ReverseBit: > ASL temp > ROR > DEX > BNE ReverseBit > STA temp > > PHA ; save reverse byte > > LDX #8 > PrintBitsNormal: > LDA temp > JSR Bit2Asc > ROR temp > DEX > BNE PrintBitsNormal > > LDA #'~'+$80 > JSR COUT > > LDX #8 > LDA cursor_val > PrintBitsReverse: > TAY > JSR Bit2Asc > TYA > LSR > DEX > BNE PrintBitsReverse > > LDA #'$'+$80 > JSR COUT > PLA ; restore reverse byte > JSR PRBYTE > > LDA cursor_org ; X=0 > PHA > LSR > LSR > LSR > LSR > JSR NibToInvTxt > PLA > ; Display nibble as inverse text > ; 0 -> '0' $30 > ; 9 -> '9' $39 > ; A -> ^A $01 > ; F -> ^F $06 > NibToInvTxt: > AND #$F > ORA #'0'+$00 ; ASCII: +$80 > CMP #'9'+$01 ; ASCII: +$81 > BCC PrintSave > SBC #$39 ; C=1, $3A ':' -> $01 'A', $3F '?' -> $06 > PrintSave: > STA ROW_21+17,X > INX > RTS > > Bit2Asc: > AND #$01 ; 0 -> B0 > BEQ FlipBit > LDA #$81 ; 1 -> 31 > FlipBit: > EOR #$B0 > JMP COUT > > ; A = byte > GetCursorByte: > LDY cursor_col > LDA (GBASL),Y > STA cursor_val > SetCursorByte: > LDY cursor_col > STA (GBASL),Y > RTS > > ; Keys are searched in reverse order > ; Sorted by least used to most used > aKeys: > CTRL "[" ; _Exit ESC Quit > CTRL "M" ; _Screen RET Toggle fullscreen > > CTRL "H" ; _MoveL <- Ctrl-H $08 > CTRL "U" ; _MoveR -> Ctrl-U $15 > CTRL "K" ; _MoveU Up Ctrl-K $0B > CTRL "J" ; _MoveD Down Ctrl-J $0A > > .byte "I" ; _MoveU Move cursor Up > .byte "J" ; _MoveL Move cursor Left > .byte "K" ; _MoveD Move cursor Down > .byte "L" ; _MoveR Move cursor Right > CTRL "I" ; _Center Center cursor > > .byte "1" ; _Bit0 Toggle bit 0 > .byte "2" ; _Bit1 Toggle bit 1 > .byte "3" ; _Bit2 Toggle bit 2 > .byte "4" ; _Bit3 Toggle bit 3 > .byte "5" ; _Bit4 Toggle bit 4 > .byte "6" ; _Bit5 Toggle bit 5 > .byte "7" ; _Bit6 Toggle bit 6 > .byte "8" ; _Bit7 Toggle bit 7 > > .byte " " ; _HighBit Toggle high bit of byte (bit 7) > .byte "9" ; _ByteFF Set byte to FF > .byte "0" ; _Byte00 Set byte to 00 > .byte "`" ; _FlipByte Toggle all bits > .byte "~" ; _FlipByte > > .byte "," ; _ShiftL (with zero) > .byte "<" ; _ShiftL (with one ) > .byte "." ; _ShiftR (with zero) > .byte ">" ; _ShiftR (with one ) > .byte "[" ; _Rol > .byte "]" ; _Ror > > .byte "=" ; _SaveByte Save current byte to temporary > .byte "-" ; _LoadByte Load temporary to current byte > eKeys: > nKeys = eKeys - aKeys ; > > ; Table of function pointers > ; *Note*: Must match aKeys order! > aFuncLo: > .byte <_Exit -1 ; ESC > .byte <_Screen -1 ; RET > > .byte <_MoveL -1 ; <- > .byte <_MoveR -1 ; -> > .byte <_MoveU -1 ; UP > .byte <_MoveD -1 ; DN > > .byte <_MoveU -1 ; 'I' > .byte <_MoveL -1 ; 'J' > .byte <_MoveD -1 ; 'K' > .byte <_MoveR -1 ; 'L' > .byte <_Center -1 ; Ctrl-I > > .byte <_Bit0 -1 ; '1' > .byte <_Bit1 -1 ; '2' > .byte <_Bit2 -1 ; '3' > .byte <_Bit3 -1 ; '4' > .byte <_Bit4 -1 ; '5' > .byte <_Bit5 -1 ; '6' > .byte <_Bit6 -1 ; '7' > .byte <_Bit7 -1 ; '8' > > .byte <_HighBit -1 ; SPC > .byte <_ByteFF -1 ; '9' > .byte <_Byte00 -1 ; '0' > .byte <_FlipByte-1 ; '`' > .byte <_FlipByte-1 ; '~' not a dup mistake > > .byte <_ShiftL -1 ; `,` > .byte <_SHL1 -1 ; `<` > .byte <_ShiftR -1 ; `.` > .byte <_SHR1 -1 ; `>` > .byte <_Rol -1 ; '[' > .byte <_Ror -1 ; '] > > .byte <_SaveByte-1 ; '=' > .byte <_LoadByte-1 ; '-' > __END: Thanks Michael! Great program.
[toc] | [prev] | [next] | [standalone]
| From | Michael Pohoreski <michael.pohoreski@gmail.com> |
|---|---|
| Date | 2016-02-16 13:47 -0800 |
| Message-ID | <1b42fa19-86ac-4767-bb48-b011f1c1811f@googlegroups.com> |
| In reply to | #2243 |
On Tuesday, February 16, 2016 at 12:00:47 PM UTC-8, Mark Lemmert wrote: > Thanks Michael! Great program. Glad you enjoyed it! Happy bit-twiddling exploring the esoteric HGR bit patterns :-)
[toc] | [prev] | [next] | [standalone]
| From | Michael Pohoreski <michael.pohoreski@gmail.com> |
|---|---|
| Date | 2016-02-16 13:41 -0800 |
| Message-ID | <e29d1688-400f-4c88-b32b-2fecdd8a55bf@googlegroups.com> |
| In reply to | #2226 |
On Monday, February 15, 2016 at 11:40:12 AM UTC-8, Mark Lemmert wrote:
>The 3 blue guys in the central region of the screen.
Um, those are the Shadowlords: Astaroth, Faulinei, Nosfentor
http://ultima.wikia.com/wiki/Shadowlords
For anyone else wanting to debug this with AppleWin ...
1. Mount: u5boot.do
2. Wait for Shadowlords to appear
3. F7 to enter debugger
4. We're going to hijack the UpdateSound() route to wait for a keypress to manually advance the (graphics) frame :-)
9E41:AD 00 C0
9E44:10 FB
9E46:8D 10 C0
9E49:60
5. F7 to leave the debugger
6. Press a key (such as space) to manually advance the frame until the middle Shadowlord shoots
7. Immediately press F7 to re-enter the debugger
8. Save the HGR screen :-)
bsave "u5.shadowlord.hgr",2000:3FFF
I've thrown all the relevant files here:
* http://michael.peopleofhonoronly.com/dev/applewin/u5/
I've also put together a DSK image with automatically loads that U5 image and runs the HGRBYTE inspector.
I would recommend an emulator that doesn't have broken color support such as AppleWin Alpha.
* http://michael.peopleofhonoronly.com/dev/applewin/nightlybuild/ntsc/ApplewinNTSC_v17BmpPalette.exe
> Does anyone know how to get blue to display on the screen like this?
AppleWin is notorious for display "incorrect" graphics, but it gets the "half-pixel" correct in this case:
2000:C4 00
2400:C4 00
2800:C4 80
2C00:C4 80
The first 2 rows will show only half a blue pixel
The last 2 rows will show a full blue pixel even though *only* the high bit is set. :-)
The Apple HGR screen is famous for showing more colors then normally possible.
i.e. You can display yellow :-)
2000:BF 3F
2400:BF 3F
2800:BF 3F
2C00:BF 3F
3000:B8 07
3400:B8 07
3800:B8 07
3C00:B8 07
Aside, Ultima 5 only uses 1 page of animation :-(
i.e. HGR page 2 shows the "Warriors of Destiny" flame
If you want to see the "Warriors of Destiny" mask ...
4000<6000.7FFFM
Thanks for posting an interesting (graphics) question!
Happy spelunking!
[toc] | [prev] | [next] | [standalone]
| From | Mark Lemmert <mark.lemmert@gmail.com> |
|---|---|
| Date | 2016-02-16 19:02 -0800 |
| Message-ID | <c7208e8b-607f-42cf-8788-2cd3227e25b6@googlegroups.com> |
| In reply to | #2244 |
Hi Michael, Thanks for posting this troubleshooting technique. I'm totally new to AppleWIN (or any emulator) debug so this should be an adventure! On Tuesday, February 16, 2016 at 3:41:08 PM UTC-6, Michael Pohoreski wrote: > On Monday, February 15, 2016 at 11:40:12 AM UTC-8, Mark Lemmert wrote: > >The 3 blue guys in the central region of the screen. > > Um, those are the Shadowlords: Astaroth, Faulinei, Nosfentor > http://ultima.wikia.com/wiki/Shadowlords > I certainly meant no disrespect to the great Shadowlords :-) I love Ultima V, and the Ultima's in general. I was trying use non-game specific terminology for those who hand not played the game, as I read what I wrote I certainly could have done better than "the 3 blue guys" LOL >Thanks for posting an interesting (graphics) question! Glad to hear you share my curiosity in this. I really want to figure it out as the implications of being able to draw color in two adjacent columns are huge (IMO).
[toc] | [prev] | [next] | [standalone]
| From | Mark Lemmert <mark.lemmert@gmail.com> |
|---|---|
| Date | 2016-02-17 18:09 -0800 |
| Message-ID | <6bbc0c2b-ef4e-401d-810f-9ae308aa6ce3@googlegroups.com> |
| In reply to | #2244 |
On Tuesday, February 16, 2016 at 3:41:08 PM UTC-6, Michael Pohoreski wrote: > > I've thrown all the relevant files here: > > * http://michael.peopleofhonoronly.com/dev/applewin/u5/ > > I've also put together a DSK image with automatically loads that U5 image and runs the HGRBYTE inspector. > > I would recommend an emulator that doesn't have broken color support such as AppleWin Alpha. > > * http://michael.peopleofhonoronly.com/dev/applewin/nightlybuild/ntsc/ApplewinNTSC_v17BmpPalette.exe > Michael, Thanks again for deconstructing the raw data. Having the hex for the blue shadow lords helped a lot, made possible by your Bit Inspector program. It's truly an awesome tool! All: My observations/conclusions on the issue OP are as follows: 1) Virtual II (mac OS X) emulator displays blue, and probably other colors, double wide, which makes it appear adjacent. I ran some of my code in Virtual II and got the same result. 2) Other than the quirks Michael noted, AppleWIN displays blue only in even columns as expected from the "rules" in the graphics books. 3) My physical Apple IIe's display (a modern flatscreen TV), connects blue lines with a smudged, slightly dimmer diagonal line. Sometimes. Before making the OP, I tried some of my code on my IIe in a random location and observed an empty column between two blue lines. Using the hex extracted from Ultima V in my code, I see the blue lines connected diagonally on the shadow lords in some places but not connected in others. Hard to describe this one, here is a screen shot: https://www.dropbox.com/s/hqbul6pzb8cpup3/IMG_9300.JPG?dl=0 I think what's happening is that the IIe's display will connect diagonal lines in "some" locations on the screen and not in others. I suspect it's probably every other screen byte or something like. I also have to wonder if my IIe being hooked up to a modern TV instead of a more transitional display from the 1980s has something to do with seeing this effect. I'm not sure how useful this quirk is if it can't be reliably reproduced across displays and emulators. If I quantify this any further I'll be sure to post back here with the result. Thanks again everyone for your replies and ideas!
[toc] | [prev] | [next] | [standalone]
| From | marc.depeo@brbent.com |
|---|---|
| Date | 2016-02-18 00:43 -0800 |
| Message-ID | <b37e75ed-cb2e-4b4c-aa27-d63dee483734@googlegroups.com> |
| In reply to | #2259 |
> I think what's happening is that the IIe's display will connect diagonal lines in "some" locations on the screen and not in others. I suspect it's probably every other screen byte or something like. > > I also have to wonder if my IIe being hooked up to a modern TV instead of a more transitional display from the 1980s has something to do with seeing this effect. I'm not sure how useful this quirk is if it can't be reliably reproduced across displays and emulators. > Your TV probably has a built-in upscaler that's creating those diagonal lines. The Super Nintendo emulator Snes9x comes with several upscaling filters (such as 2xSal and hq2x) which produce artifacts very similar to what you're seeing. Also, I took a picture of Ultima V running on a traditional CRT television that I thought you might find helpful to have as a reference. As you can see, there's not really much of a visible gap between blue pixels even though they are technically separated by a black column. The second photo is a side-by-side comparison of the game running in AppleWin and on a CRT television. https://www.dropbox.com/s/wse7k1bonj9qywz/IMG_0859.JPG?dl=0 https://www.dropbox.com/s/7yolzp840vghx6f/comparison.jpg?dl=0
[toc] | [prev] | [next] | [standalone]
| From | wssimms@gmail.com |
|---|---|
| Date | 2016-02-18 01:48 -0800 |
| Message-ID | <e54542bb-946e-4181-b943-3f1477139379@googlegroups.com> |
| In reply to | #2260 |
Comparisons with standard Applewin aren't very helpful as it has poor emulation of the NTSC display. Here is NTSC Applewin, although unfortunately the "blue guys" aren't present in the screen shot. http://wsxyz.net/images/u5ct.png
[toc] | [prev] | [next] | [standalone]
| From | AppleIIGSMarc <appleiigsmarc@gmail.com> |
|---|---|
| Date | 2016-02-18 08:50 -0800 |
| Message-ID | <a480f040-ccb2-4ef1-a9dc-bef22d23bb49@googlegroups.com> |
| In reply to | #2261 |
On Thursday, February 18, 2016 at 1:48:05 AM UTC-8, wss...@gmail.com wrote: > Comparisons with standard Applewin aren't very helpful as it has poor emulation of the NTSC display. Here is NTSC Applewin, although unfortunately the "blue guys" aren't present in the screen shot. > > http://wsxyz.net/images/u5ct.png Sorry, when I posted that picture I wasn't really trying to show off the accuracy of AppleWin's display. Rather, I was including it because I thought it would provide a helpful base image (sort of a raw video output), that could be used to compare with the final outputted NTSC version. It clearly shows off some of the oddities in the way the apple II stores graphics in memory, such as blue only existing in even columns. The image on the right shows what happens once the video is sent out to an analog display (in this case a crt television). Single pixels of blue sort of smudge out into soft, wide pixels and the gaps between columns becomes less apparent. I'm assuming due to the analog nature of the NTSC signal and crt display.
[toc] | [prev] | [next] | [standalone]
| From | AppleIIGSMarc <appleiigsmarc@gmail.com> |
|---|---|
| Date | 2016-02-18 10:45 -0800 |
| Message-ID | <c5af9cb1-fe08-4afe-8151-e05dca002c43@googlegroups.com> |
| In reply to | #2263 |
On Thursday, February 18, 2016 at 8:50:57 AM UTC-8, AppleIIGSMarc wrote: > On Thursday, February 18, 2016 at 1:48:05 AM UTC-8, wss...@gmail.com wrote: > > Comparisons with standard Applewin aren't very helpful as it has poor emulation of the NTSC display. Here is NTSC Applewin, although unfortunately the "blue guys" aren't present in the screen shot. > > > > http://wsxyz.net/images/u5ct.png > > Sorry, when I posted that picture I wasn't really trying to show off the accuracy of AppleWin's display. Also, thanks for mentioning NTSC AppleWin...I didn't even know that version existed. It's not perfect, but it does a pretty good job simulating NTSC television output..pretty cool!
[toc] | [prev] | [next] | [standalone]
| From | Michael Pohoreski <michael.pohoreski@gmail.com> |
|---|---|
| Date | 2016-02-18 20:24 -0800 |
| Message-ID | <8f68e3d4-9c39-4c09-bea4-26c40851cd51@googlegroups.com> |
| In reply to | #2265 |
On Thursday, February 18, 2016 at 10:45:04 AM UTC-8, > Also, thanks for mentioning NTSC AppleWin...I didn't even know that version existed. It's not perfect, but it does a pretty good job simulating NTSC television output..pretty cool! Uh, if you mean "pretty good" as in: * bad white ringing * black ghosting * and white chroma ghosting: then OK. :-/ Not to knock Sheldon's excellent base, it just needs some TLC. :-) http://michael.peopleofhonoronly.com/dev/applewin/ntsc/
[toc] | [prev] | [next] | [standalone]
| From | wssimms@gmail.com |
|---|---|
| Date | 2016-02-18 20:32 -0800 |
| Message-ID | <95834179-9e29-4f93-899e-539738b88cbc@googlegroups.com> |
| In reply to | #2288 |
Am Freitag, 19. Februar 2016 13:24:16 UTC+9 schrieb Michael Pohoreski: > On Thursday, February 18, 2016 at 10:45:04 AM UTC-8, > Also, thanks for mentioning NTSC AppleWin...I didn't even know that version existed. It's not perfect, but it does a pretty good job simulating NTSC television output..pretty cool! > > Uh, if you mean "pretty good" as in: > > * bad white ringing > * black ghosting > * and white chroma ghosting: And not only that, the debugger doesn't work!
[toc] | [prev] | [next] | [standalone]
| From | AppleIIGSMarc <appleiigsmarc@gmail.com> |
|---|---|
| Date | 2016-02-18 21:05 -0800 |
| Message-ID | <8c454429-a8cb-4d12-a0c2-455d8f53c425@googlegroups.com> |
| In reply to | #2289 |
On Thursday, February 18, 2016 at 8:32:08 PM UTC-8, wss...@gmail.com wrote: > Am Freitag, 19. Februar 2016 13:24:16 UTC+9 schrieb Michael Pohoreski: > > On Thursday, February 18, 2016 at 10:45:04 AM UTC-8, > Also, thanks for mentioning NTSC AppleWin...I didn't even know that version existed. It's not perfect, but it does a pretty good job simulating NTSC television output..pretty cool! > > > > Uh, if you mean "pretty good" as in: > > > > * bad white ringing > > * black ghosting > > * and white chroma ghosting: > > And not only that, the debugger doesn't work! Well, I did say it wasn't perfect. I was just trying to be nice, but whatever. And yes, it's obviously a very old version of AppleWin, so it's not going to replace the version I normally use. But it's nice to see something that makes an attempt to simulate a television display, even if there is lots of room for improvement.
[toc] | [prev] | [next] | [standalone]
| From | gids.rs@sasktel.net |
|---|---|
| Date | 2016-02-18 15:08 -0800 |
| Message-ID | <ec534e29-7787-4f16-958b-599b757b01bb@googlegroups.com> |
| In reply to | #2263 |
> Sorry, when I posted that picture I wasn't really trying to show off the accuracy of AppleWin's display. Rather, I was including it because I thought it would provide a helpful base image (sort of a raw video output), that could be used to compare with the final outputted NTSC version. It clearly shows off some of the oddities in the way the apple II stores graphics in memory, such as blue only existing in even columns. The image on the right shows what happens once the video is sent out to an analog display (in this case a crt television). Single pixels of blue sort of smudge out into soft, wide pixels and the gaps between columns becomes less apparent. I'm assuming due to the analog nature of the NTSC signal and crt display. The confusion might be what you are calling a column. A column is not a byte. Enter this to see if I understand you correctly. ]CALL-151 *2000:94 8A *2400:94 8A *2800:94 8A *2C00:94 8A *3000:94 8A As you can see, blue pixels can be displayed in odd numbered bytes.
[toc] | [prev] | [next] | [standalone]
| From | Mark Lemmert <mark.lemmert@gmail.com> |
|---|---|
| Date | 2016-02-18 15:31 -0800 |
| Message-ID | <f30a9579-7983-4ff5-a7eb-2a8215ff6ccd@googlegroups.com> |
| In reply to | #2263 |
> Sorry, when I posted that picture I wasn't really trying to show off the accuracy of AppleWin's display. Rather, I was including it because I thought it would provide a helpful base image (sort of a raw video output), that could be used to compare with the final outputted NTSC version. It clearly shows off some of the oddities in the way the apple II stores graphics in memory, such as blue only existing in even columns. The image on the right shows what happens once the video is sent out to an analog display (in this case a crt television). Single pixels of blue sort of smudge out into soft, wide pixels and the gaps between columns becomes less apparent. I'm assuming due to the analog nature of the NTSC signal and crt display. Thanks for posting it, and your other comments. It was very interesting to see the rendering on a CRT TV.
[toc] | [prev] | [next] | [standalone]
| From | Michael Pohoreski <michael.pohoreski@gmail.com> |
|---|---|
| Date | 2016-02-18 13:18 -0800 |
| Message-ID | <07002184-9228-4585-b62f-1135ff469168@googlegroups.com> |
| In reply to | #2261 |
On Thursday, February 18, 2016 at 1:48:05 AM UTC-8, wss...@gmail.com wrote: > Comparisons with standard Applewin aren't very helpful as it has poor emulation of the NTSC display. Here is NTSC Applewin, although unfortunately the "blue guys" aren't present in the screen shot. > > http://wsxyz.net/images/u5ct.png You mean like this? http://michael.peopleofhonoronly.com/dev/applewin/u5/u5.ntsc.png That's why I put together this DSK image which has a screencap :-) http://michael.peopleofhonoronly.com/dev/applewin/u5/u5.shadowlords.dsk
[toc] | [prev] | [next] | [standalone]
| From | wssimms@gmail.com |
|---|---|
| Date | 2016-02-18 18:15 -0800 |
| Message-ID | <be52df43-beef-4b5d-a7f7-c38c08cd59cb@googlegroups.com> |
| In reply to | #2267 |
Am Freitag, 19. Februar 2016 06:18:38 UTC+9 schrieb Michael Pohoreski: > On Thursday, February 18, 2016 at 1:48:05 AM UTC-8, wss...@gmail.com wrote: > > Comparisons with standard Applewin aren't very helpful as it has poor emulation of the NTSC display. Here is NTSC Applewin, although unfortunately the "blue guys" aren't present in the screen shot. > > > > http://wsxyz.net/images/u5ct.png > > You mean like this? > http://michael.peopleofhonoronly.com/dev/applewin/u5/u5.ntsc.png Yes exactly. The only thing is that your screenshot is in high bandwidth (color monitor) mode, which mine is in TV emulation mode, which is more "CRT-like" for the lack of a better description. If I weren't really lazy I would have gotten a better screenshot, but I am really lazy and the shot I provided was already available online.
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.sys.apple2.programmer
csiph-web