Re: DRAW & XDRAW... How to use

[dalloff@gcfn.org (Dave Althoff Jr)]

jh82 (webmasterNOweSPAM@jh82.i-p.com.invalid) wrote:
: Dave,

: I know you said it doesn't matter where you put the shape table, but
: what address would be the best place to start?  I know that if I just
: start poking numbers, I 'm going to crash my apple. (I've done it
: before).

: James

Someone else already mentioned it, but...

There is some space starting at $300 (768) but not a whole lot.  If you're
not using hi-res page 2 ($4000-$6000 (16384-24576) that is fairly safe because
it is out in the middle of nowhere...and you know your Applesoft program isn't
going to go up that far because it will crash into hi-res page #1 first
(Applesoft program lines build up from $800, typically.  And I have had a
few that overran the first hi-res page).  Almost as safe is up around
$6000 (24576) again, because Applesoft doesn't usually use much space up
there.  In fact, my assembler (Big Mac or Merlin) defaults to $8000
(32768) as an object code start point, and so far I have managed not to
clobber that stuff either.  Under DOS 3.3 (I believe ProDOS/BASIC.SYSTEM
is similar) on a 48k or bigger machine (are there any other kinds these
days?) your variable storage starts at $9600 (38400) and works backward
from there.  Every time you use or change a string, it gets written up
there, but I think the space is taken up on demand...that is, each string
does not automatically take 256 bytes...so the usage of that space is
somewhat optimized.  If you're worried about it, at least under DOS 3.3,
you can put your shape table just below the DOS buffers (ending at $9600)
and set HIMEM: below the table so that the variables get stored *below*
your shape data.

I should warn you that first of all, I have not done a whole lot with
shape tables (I just happened to have my copy of the Apple ][ User's Guide
within arms reach of the computer!).

As someone else...Phoenyx, I believe...mentioned, shape tables do tend to
be slow, and block shapes are much faster...and you can even XOR them onto
the screen to do XDRAWs.  But for block shapes you can't use those nifty
Applesoft commands, and with the goofy memory map of the hi-res screen,
plus the limitations to doing color (consecutive bytes have reversed color
maps) it isn't real easy unless someone has a set of routines already
built as a series of assembly language calls.  

To see just how goofy the Apple ][ hi-res screen memory map is, try this
little Applesoft BASIC gem...

5 PRINT CHR$(21) : HOME : REM Make sure 80-column card is OFF
10 HGR:POKE -16302,0 :REM We don't need no steenking text window!
20 FOR L = 8192 TO 16383 : POKE L,255 :NEXT L
30 GET A$ : TEXT

Notice that the memory locations are being filled in sequential order...

--Dave Althoff, ][.
-- 
    /^\        _       _               _*** Closed for the season ***
   /XXX\      /X\     /X\_      _     /X\__      _     _        _____  
  /XXXXX\    /XXX\  _/XXXX\_   /X\   /XXXXX\    /X\   /X\      /XXXXX
_/XXXXXXX\__/XXXXX\/XXXXXXXX\_/XXX\_/XXXXXXX\__/XXX\_/XXX\_/\_/XXXXXX