mirror of
https://github.com/tilleul/apple2.git
synced 2024-12-12 10:29:28 +00:00
45 lines
1.8 KiB
Markdown
45 lines
1.8 KiB
Markdown
# Apple ]\[ hires
|
|
## Structure of the hires screen in RAM
|
|
The Apple ]\[ has 2 hires pages. One in $2000-$3FFF. The second one in $4000-$5FFF. Each page is thus 8192 bytes long.
|
|
|
|
The dimensions of one hires page is 40 bytes wide and 192 lines high. 40x192 = 7680 bytes. 512 bytes are "missing" and in fact not used/displayed.
|
|
|
|
The hires screen is divided in 3 sections of 64 lines. Each section is then divided in 8 sub-sections of 8 lines, each itself divided in 8 sub-sub-sections representing the lines themselves.
|
|
|
|
To better understand this division, it's easier to POKE bytes into RAM and see what happens.
|
|
|
|
A `POKE 8192,255`will plot 7 pixels on the top left corner of the hires screen (page 1). Poking the next memory address (8193), will plot 7 more pixels on line 0 of the hires screen.
|
|
|
|
So to draw the entire line 0 we could `RUN` this code
|
|
|
|
10 HGR
|
|
20 FOR I = 0 TO 39: POKE 8192+I, 255: NEXT
|
|
|
|
|
|
|
|
8192 + 40 = 8232 ($2028) is the next byte in memory. But
|
|
|
|
POKE 8232,255
|
|
|
|
will not plot 7 pixels on line 1 but on line 64 !
|
|
If we slightly modify the above code to POKE the first 3 lines as stored in memory, we have
|
|
|
|
10 HGR
|
|
20 A = 8192: REM $2000
|
|
30 FOR J = 0 TO 2
|
|
40 FOR I = 0 TO 39
|
|
50 POKE A, 255
|
|
60 A = A+ 1
|
|
70 NEXT I,J
|
|
80 PRINT A
|
|
|
|
The result is this
|
|
|
|
|
|
|
|
We have drawn line 0, line 64 and line 128 !
|
|
Now the next address to `POKE` seems to be 8312 ($2078 in hex -- the resulting value in our variable `A`).
|
|
|
|
But if we do `POKE 8312, 255` we don't see any change on the screen ! This is because we have reached one the hires screen holes !
|
|
In fact, all lines between 128 and 191 in RAM have 8 unused bytes at their end. Those 8x64 lines represent 512 bytes. Those are the missing bytes in first computation.
|