From 97eb35184be79d120d597a3ceed41ec9020df2c2 Mon Sep 17 00:00:00 2001 From: Michaelangel007 Date: Sun, 10 Jan 2016 10:16:24 -0800 Subject: [PATCH] Fix spelling --- README.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index e5ffb6a..d30e843 100644 --- a/README.md +++ b/README.md @@ -108,7 +108,7 @@ Magic? :-) Nah, just Computer Science. :-) -The first question you probalby have is "How did I know what bytes to use?" We'll get to that in a second. +The first question you probably have is "How did I know what bytes to use?" We'll get to that in a second. ## Quirks of the Apple HGR screen @@ -181,7 +181,7 @@ Third, the video scanner for HGR mode scans bits in reverse. :-/ This means that We would only get: - * 3 scanlines intead of the expected 4 (see the next point), and + * 3 scanlines instead of the expected 4 (see the next point), and * the image would be flipped along the left-right (X axis) like this: `/` On the Apple we need to flip each byte: @@ -673,7 +673,7 @@ A naive glyph/32 calculation would be to use 5 shift right bit-shifts: 4A LSR ; c / 32 = %00000PQR ``` -However we can save one instruction (and 2 cycles) if we optimize `c/32` to use the counter-intutive 6502's `ROL` instruction -- which only requires 4 instructions instead: +However we can save one instruction (and 2 cycles) if we optimize `c/32` to use the counterintuitive 6502's `ROL` instruction -- which only requires 4 instructions instead: ```assembly 68 PLA ; pop c = %PQRSTUVW to draw @@ -776,12 +776,12 @@ Let's verify this by writing a character inspector. We'll use the arrow keys to 1021:A5 FE .3 LDA $FE ; c &= 0x7F 1023:29 7F AND #7F 1025:85 FE STA $FE - 1027:10 DB BPL .1 ; allways branch, draw prev char + 1027:10 DB BPL .1 ; always branch, draw prev char 1029:C9 95 .4 CMP #95 ; key == --> ? 102B:D0 05 BNE .5 ; 102D:E6 FE INC $FE ; yes, ++c 102F:18 CLC - 1030:90 EF BCC .3 ; allways branch, draw prev char + 1030:90 EF BCC .3 ; always branch, draw prev char 1032:C9 9B .5 CMP #9B ; key == ESC ? 1034:D0 DD BNE .2 ; 1036:60 RTS ; yes, exit @@ -1041,7 +1041,7 @@ Enter: 379:20 28 03 18 98 65 F5 85 F5 60 -Or are? Since we're using a function to calculate the destinatin address let's fix the order. +Or are? Since we're using a function to calculate the destination address let's fix the order. We'll need to change the `X` offset in CursorRow() to `Y`; @@ -1227,7 +1227,7 @@ The text screen, like the HGR screen, is also non-linear, and also broken up int While the Apple's memory layout seems esoteric it has beautiful symmetry. For any given text row notice that: * the low byte of the text address is the same low byte of the HGR address -* the high byte of the text addres is 0x1C less then the high byte of the HGR address +* the high byte of the text address is 0x1C less then the high byte of the HGR address Since we already have a HGR 16-bit address table we can re-use it. @@ -1280,7 +1280,7 @@ And here is the assembly: 1328:C0 28 CPY #$28 ; 40 is #$18 132A:90 F7 BCC .2 ; Y < 40 132C:E6 F3 INC row - 133E:D0 DA BNE .1 ; allways + 133E:D0 DA BNE .1 ; always 1330:60 .3 RTS ``` @@ -1817,7 +1817,7 @@ The bulk of the ScrollHgrUpPixel() was generated with this Javascript program [s And who said Javascript was a useless language? :-) -That's all folks! No go write some cool font blitter code. +That's all folks! Now go write some cool font blitter code. ## References