andré lozano <n...@provsoire.com> wrote:
> hello from France
> I'm coding some basic code.
> I want to know, if it's possible, how to change the state of a pixel in
> hires screen with a poke instruction.
Sure it is possible, just difficult to implement in Applesoft BASIC. It
is far easier to use the HPLOT command, and probably much faster.
Here is some background to explain the problem.
Assuming a monochrome monitor, each byte contains seven pixels. The high
order bit in the byte is used to select the colour set, which in
monochrome mode results in a half dot shift in position for all seven
pixels in the byte.
If you are working in colour, then each pair of monochrome pixels forms
a colour pixel, which may be black, green, violet or white if the high
order bit of the byte is zero. If the high order bit is one, then the
green and violet pixels become orange and blue. Two adjacent bytes form
seven colour pixels, and the middle pixel in the group of seven
straddles a byte boundary. (If you change colour sets, you get unusually
coloured pixels at the byte boundaries.)
You can't change a single pixel with a poke. You would have to do a
peek, modify the value and then poke the result back (unless you knew in
advance what state the other pixels were in). This requires bitwise
manipulation operators (logical OR, XOR and AND), which Applesoft BASIC
doesn't directly support. In colour, you have to peek and poke two bytes
for some pixels.
The tricky part is calculating the memory address of the row. The screen
memory is arranged in an interleaved pattern.
Each horizontal row is forty adjacent bytes. Row 0 is at memory offset 0
from the start of the screen. The byte at offset 40 is the start of row
64, and the byte at offset 80 is the start of row 128. The bytes at
offsets 120 through 127 are not visible. This pattern (top, middle or
bottom third of screen) repeats for each subsequent group of 128 bytes.
Each subsequent group of 128 bytes is 8 rows below the previous group,
until you get to an offset of 1024.
Each subsequent group of 1024 bytes is one row below the previous group.
Doing this calculation in Applesoft BASIC is painfully slow because it
doesn't have integer DIV and MOD operators, or AND-mask and bit-shift
operators. It is easier to use a lookup table, generation of which is
left as an exercise for the reader.
The horizontal address requires calculating INT (X / 7), the remainder
of which is used as a bit number (0 to 6) within the byte, which needs
to be converted to a bitmask. You then need to use that bitmask to
manipulate the contents of the byte via PEEK and POKE.
The hi-res graphics screen memory starts at $2000 (8192) for page 1,
which is the one you would normally see if you used the HGR command to
get into graphics mode. Page 2 (HGR2) starts at $4000 (16384).
(For reference, I wrote a hi-res graphics drawing program back in about
1982-1984; the first iteration was in BASIC but I rewrote the whole
thing in assembly language because BASIC was way too slow to get any
reasonable graphics performance.)
-- David Empson
demp...@actrix.gen.nz
>> I want to know, if it's possible, how to change the state of a pixel in
>> hires screen with a poke instruction.
> Sure it is possible, just difficult to implement in Applesoft BASIC. It
> is far easier to use the HPLOT command, and probably much faster.
> Here is some background to explain the problem.
> Assuming a monochrome monitor, each byte contains seven pixels. The high
> order bit in the byte is used to select the colour set, which in
> monochrome mode results in a half dot shift in position for all seven
> pixels in the byte.
> If you are working in colour, then each pair of monochrome pixels forms
> a colour pixel, which may be black, green, violet or white if the high
> order bit of the byte is zero. If the high order bit is one, then the
> green and violet pixels become orange and blue. Two adjacent bytes form
> seven colour pixels, and the middle pixel in the group of seven
> straddles a byte boundary. (If you change colour sets, you get unusually
> coloured pixels at the byte boundaries.)
> You can't change a single pixel with a poke. You would have to do a
> peek, modify the value and then poke the result back (unless you knew in
> advance what state the other pixels were in). This requires bitwise
> manipulation operators (logical OR, XOR and AND), which Applesoft BASIC
> doesn't directly support. In colour, you have to peek and poke two bytes
> for some pixels.
> The tricky part is calculating the memory address of the row. The screen
> memory is arranged in an interleaved pattern.
> Each horizontal row is forty adjacent bytes. Row 0 is at memory offset 0
> from the start of the screen. The byte at offset 40 is the start of row
> 64, and the byte at offset 80 is the start of row 128. The bytes at
> offsets 120 through 127 are not visible. This pattern (top, middle or
> bottom third of screen) repeats for each subsequent group of 128 bytes.
> Each subsequent group of 128 bytes is 8 rows below the previous group,
> until you get to an offset of 1024.
> Each subsequent group of 1024 bytes is one row below the previous group.
> Doing this calculation in Applesoft BASIC is painfully slow because it
> doesn't have integer DIV and MOD operators, or AND-mask and bit-shift
> operators. It is easier to use a lookup table, generation of which is
> left as an exercise for the reader.
> The horizontal address requires calculating INT (X / 7), the remainder
> of which is used as a bit number (0 to 6) within the byte, which needs
> to be converted to a bitmask. You then need to use that bitmask to
> manipulate the contents of the byte via PEEK and POKE.
> The hi-res graphics screen memory starts at $2000 (8192) for page 1,
> which is the one you would normally see if you used the HGR command to
> get into graphics mode. Page 2 (HGR2) starts at $4000 (16384).
> (For reference, I wrote a hi-res graphics drawing program back in about
> 1982-1984; the first iteration was in BASIC but I rewrote the whole
> thing in assembly language because BASIC was way too slow to get any
> reasonable graphics performance.)
" mmphosis" <mmpho...@macgui.com> wrote in message news:mmphosis-1335663325@macgui.com...
> Un exemple de comment faire l'écran bleu HGR, en utilisant Applesoft POKE:
> 1 FOR I=B TO E:POKE I,C:I=I+U:POKE I,D:NEXT:IF B THEN RETURN
> 20 B = 8192 :REMau debut de HGR
> 30 E = 24567:REMfin de HGR
> 40 C = 213 :REMbyte0 bleu
> 50 D = 170 :REMbyte1 bleu
> 60 U = 1 :REMun
> 100 REMhaute resolution
> 110 POKE 49293,0
> 120 REMen plein ecran
> 130 POKE 49234,0
> 140 REMla premiere page
> 150 POKE 49236,0
> 160 REMgraphique
> 170 POKE 49232,0
> 180 GOSUB 1
> 190 GET K$:TEXT
> Une façon plus rapide de faire le bleu écran HGR, dans Applesoft sans
> utiliser POKE:
On Saturday, May 26, 2012 9:21:00 AM UTC-7, aiia...@gmail.com wrote:
> On Tuesday, April 24, 2012 2:11:11 AM UTC-7, andré lozano wrote:
> > hello from France
> > I'm coding some basic code.
> > I want to know, if it's possible, how to change the state of a pixel in > > hires screen with a poke instruction.
Or you can XPLOT a 1-dot shape, PEEK the collision counter,
and XPLOT it again (to restore it to its original value).
If the bit was set, the collision counter will register a collision.
This has the advantage of being entirely in BASIC.
