applesoft basic : how to poke hires screen

[andré lozano]

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.

for example in a graphic lcd screen you can modify the graphics by
loading bytes directly in the memory

friendly

andres lozano

[David Empson]

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
dem...@actrix.gen.nz

[andré lozano]

thanks you very much I will read your comments and try your advices

[mmphosis]

An example of how to make the HGR2 screen orange, in Applesoft using POKE:

1 FOR I=B TO E:POKE I,C:I=I+U:POKE I,D:NEXT:IF B THEN TEXT:END

20 B = 16384:REMstart of HGR2
30 E = 24567:REM end of HGR2
40 C = 170 :REMorange byte0
50 D = 213 :REMorange byte1
60 U = 1 :REMone
100 REMhi-resolution
110 POKE -16297,0
120 REMfull screen
130 POKE -16302,0
140 REMsecond page
150 POKE -16299,0
160 REMgraphics
170 POKE -16304,0
180 GOTO 1

A faster way to make the HGR2 screen orange, in Applesoft without using
POKE:

HGR2:HCOLOR=5:HPLOT 0,0:CALL-3082:TEXT

[Michael J. Mahon]

Or to actually *see* the orange screen, leave the TEXT off. ;-)

-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

[mmphosis]

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:

HGR:POKE49234,0:HCOLOR=6:HPLOT 0,0:CALL-3082:WAIT49152,128:POKE49168,0:TEXT

[Bill Garber]

" mmphosis" <mmph...@macgui.com> wrote in message news:mmphosis-...@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:
>
> HGR:POKE49234,0:HCOLOR=6:HPLOT 0,0:CALL-3082:WAIT49152,128:POKE49168,0:TEXT

Or just change the color number in this line:

HGR2:HCOLOR=6:HPLOT 0,0:CALL-3082

SEPA Electronics
http://www.sepa-electronics.com
Bill Garber

[mmphosis]

NEW

0 HIMEM: 5608

1DATA5532563300922139021390213932135045238263536503037252627503845615305817312092293902932835845478875645836575037148845550351083966132653706165276445377489621322135821322334213502130051520282036

2DATAQLNZQLNZQAQQDSAQRDSAQQDSAQVDSAQXCKDNAPFXANAQXXANANXNXNXQXNXCQXKXNZQXKXNZQCQODMAQODMAUUYQXCKATAUVQXCKMNXQXKANXUAUTCQXKENXUMUSQJHSAHFQZTXRDFQZTAOCQZTAOBQHDSAPDSAQADSANZNZKDSAQZDSAXZQZOZXZUAXZJ

3 READ L$: READ H$

4 FOR I = 1 TO LEN (L$)

5POKE767+I,10*(ASC(MID$(H$,I,1))-65)+VAL(MID$(L$,I,1))

6 NEXT

RUN

HGR : CALL 768: CALL 5608

[andré lozano]

et pour manipuler des pixels en mode GR low resolution ?

[aiia...@gmail.com]

*******************************
*
* HPLOT XLOC,YLOC FROM ASSEMBLY
*
* INPUT : XLOC X COORD
* YLOC Y COORD
*
* requires: lookup table at TLO, 192X2 byte table
*
* OUTPUT: OR'D WITH SCREEN
*
*****************************


XBIT DFB #00
XBYTE DFB #00


MASKTEMP DFB #00
;-----------------------------



HPLOT LDA #00
STA FOUNDLIT

LDY YLOC
LDA TLO,Y
STA SLO
LDA THI,Y
STA SHI


LDA XLOC
LDY #00
CLC
DLOOPSV CMP #7 ;DIVIDE X COORDINATE BY 7
BCC DDONESV
SEC
SBC #7
INY
CLC
JMP DLOOPSV


DDONESV


TAX ;Division done, now get the proper bit value
LDA MASK,X

STA MASKTEMP ;GETS DESTROYED IN ISLIT
AND (SHI),Y ;AND THE MASK WITH THE SCREEN, TO TEST IF BIT SET

BEQ NOTLIT

ISLIT NOP ;PIXEL IS LIT
INC FOUNDLIT

NOTLIT

LDA MODE
BEQ MODE0D
JMP MODE1D

MODE0D TYA
CLC
ADC #18 ;ADD 18 TO XBYTE
TAY

MODE1D LDA MASKTEMP ;GET MASK AGAIN
ORA (SHI),Y ;
STA (SHI),Y ;PUT ON SCREEN


JSR ADDPT ;ADD PT TO TABLE (IN SCANCONVERT)

RTS

MASK DFB #$01,#$02,#$04,#$08,#$10,#$20,#$40,#$80

[aiia...@gmail.com]

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.

http://rich12345.tripod.com/prog/hirescrn.html

theres how to read the state of a pixel

[Michael J. Mahon]

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.

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."