Subject: CPU RAM PAD

From: Owen Brand <[email-masked]>
Date: Wed, 27 Jan 2010 18:58:47 -0500

I am looking for a list of useful addresses to PEEK into between >8300  
and >83FF that I can PEEK into from my XB game.... I am finding that  
PEEKing into -31880 is a FAR more efficient way to generate random  
numbers.... Far more than RND.... This has proven to speed up my game  
up substantially and this is just one little line in my code!!!  Also,  
-31879 is the VDP interrupt timer.... This is useful to me to set up a  
"clock" so to speak.... It seems to reset every 4.5 seconds or so and  
gives a solid timer---
Other than these, I'm in the dark... Anyone have a more complete list?

Owen Brand
**Oprysoft**
Opry99er.com

---

From: "hexbus" <[email-masked]>
Date: Thu, 28 Jan 2010 00:49:36 -0000

I remember CALL LOAD (-31931,0) that unprotected XB programs, and that's about it.  There was also another one that I used to use to do a FTCN= as well, but don't remember that one offhand. 

A nice little CALL LOAD list (compiled) would be nice, though :)

Jon

---

From: Owen Brand <[email-masked]>
Date: Wed, 27 Jan 2010 20:00:43 -0500

I am really looking to get a similar list, Jon.... For the addresses  
that are useful in XB programming.... I thought that CALL LOAD was  
used to LOAD a subroutine from disk into low memory to be called up  
later with "LINK".  Perhaps there are pre-set routines in low memory  
that can be used in XB via CALL LOAD that I am not familiar with. :).  
Can't wait to learn more.

Owen Brand
**Oprysoft**
Opry99er.com

On Jan 27, 2010, at 7:49 PM, "hexbus" <[email-masked]> wrote:

>
> I remember CALL LOAD (-31931,0) that unprotected XB programs, and  
> that's about it. There was also another one that I used to use to do  
> a FTCN= as well, but don't remember that one offhand.
>
> > I am looking for a list of useful addresses to PEEK into between  
> >8300

---

From: Insane Multitasker <[email-masked]>
Date: Wed, 27 Jan 2010 19:04:38 -0600

Check WHT and start reading the newsletter scans --you're bound to find a list there.  They used to get printed all the time.  

To: [email-masked]
From: [email-masked]
Date: Wed, 27 Jan 2010 20:00:43 -0500
Subject: Re: [TI994A] Re: CPU RAM PAD

I am really looking to get a similar list, Jon.... For the addresses that are useful in XB programming.... I thought that CALL LOAD was used to LOAD a subroutine from disk into low memory to be called up later with "LINK".  Perhaps there are pre-set routines in low memory that can be used in XB via CALL LOAD that I am not familiar with. :). Can't wait to learn more.

Owen Brand
**Oprysoft**
Opry99er.com

  

Jon

> Other than these, I'm in the dark... Anyone have a more complete list?

_________________________________________________________________
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
http://clk.atdmt.com/GBL/go/196390709/direct/01/

---

From: tursi <[email-masked]>
Date: Wed, 27 Jan 2010 17:11:48 -0800 (PST)

> Other than these, I'm in the dark... Anyone have a more complete list?

The E/A manual has a relatively decent list, although it is for the 
assembly environment and does not cover XB's usage.

Some of the standard ones would be:
>8370 (2 bytes) - highest free VDP RAM address
>8372 - GPL data stack pointer
>8373 - GPL subroutine stack pointer
>8374 - Keyboard number for KSCAN
>8375 - Keyboard ASCII return after KSCAN
>8376 - Joystick Y (after KSCAN)
>8377 - Joystick X (after KSCAN)
>8378 - random number
>8379 - VDP interrupt timer (updated every frame)
>837A - number of sprites to move
>837B - VDP status byte (updated every frame)
  -- bit 0 (value 128) is the interrupt - always 0
  -- bit 1 (value 64) is the 5 sprites on a line flag
  -- bit 2 (value 32) is the sprite collision flag
  -- bit 3-7 has the number of the 5th sprite on a line
>837C - GPL status (maybe not useful to XB!)
  -- bit 0 is "high"
  -- bit 1 is "greater than"
  -- bit 2 is "condition"
  -- bit 3 is "carry"
  -- bit 4 is "overflow"
>837D - VDP character buffer (I never figured what this was)
>837E - VDP current row
>837F - VDP current column (works with >837D)
...
>83C0 (2 bytes) - random number seed
>83C2 - Interrupt routine control
  -- bit 0 (value 128) - master interrupt disable (set to disable all)
  -- bit 1 (value 64) - disable sprite movement (set to disable)
  -- bit 2 (value 32) - disable sound lists (set to disable)
  -- bit 3 (value 16) - disable quit key (set to disable)
>83C4 (2 bytes) User-defined interrupt address
>83CA (2 bytes) keyboard debounce temporary
>83CC (2 bytes) sound list pointer
>83CE - sound byte countdown
>83D0 (4 bytes) GROM/ROM search temporary
>83D4 - copy of VDP register 1 (stored in VDP on keypress)
>83D6 (2 bytes) screen blank timer (blanks at 0, set to '2')
>83D8 (4 bytes) temporary data used by SCAN
>83FA (2 bytes) GROM write address
>83FC (2 bytes) System flags (not sure what is in there)
>83FE (2 bytes) VDP write address

To convert these values to the necessary values for CALL PEEK and CALL 
LOAD, you need to convert the hex to decimal, then to signed. You can use 
Windows Calculator to do this... set the 'View' option to "Scientific" and 
you get a Hex mode available to you. Switch to hex and enter the value, 
then switch back to decimal to see the result. To make it the signed value 
you need, subtract 65536. For instance, >83C2 is 33730 in decimal. 
Subtract 65536, and you get -31806.

It should be safe to read any of these values -- it may not be safe to 
change them all! Always save your work frequently before experimenting.

Some of these values might be fun to play with, though. The sound lists I 
promised to help you with are documented there, somewhat. The interrupt 
management can be fun - especially controlling sprites and QUIT. Note that 
if you disable sound lists, and play multiple sounds with CALL SOUND, XB 
may hang waiting for the sound to end. ;)

Here's a sample that fiddles with the sprite control and disables quit. 
Just for fun, it also monitors the VDP status for collision and flicker 
information. Note that the CALL PEEK collision differs from CALL 
COINC(ALL)... COINC hits the VDP directly, which has the side effect of 
losing the status for the interrupt routine. CALL PEEK uses the cached 
value from the last interrupt.

1 REM DISABLES QUIT!
2 REM STARTS AND STOPS SPRITES
3 REM DISPLAYS COLLISION AND FLICKER STATS
4 REM NOTE - UNLIKE CALL COINC, THE CALL PEEK DOES NOT READ THE VDP 
DIRECTLY
5 CALL INIT
10 CALL CLEAR
20 CALL MAGNIFY(4)
30 FOR A=1 TO 10
40 CALL SPRITE(#A,42,RND*16+1,100,100,RND*40-20,RND*40-20)
50 NEXT A
60 REM VALUE 64 DISABLES SPRITES
70 REM VALUE 16 DISABLES QUIT
80 SPROFF=64+16
90 SPRON=16
100 MODE=1 :: REM ON
110 PRINT "PRESS SPACE TO TOGGLE MODE"
120 IF MODE THEN 160
130 PRINT "SPRITES OFF"
140 CALL LOAD(-31806,SPROFF)
150 GOTO 180
160 PRINT "SPRITES ON"
170 CALL LOAD(-31806,SPRON)
180 REM LOOP READING STATUS REG
190 CALL PEEK(-31877,STAT)
200 IF STAT AND 64 THEN DISPLAY AT(1,1):"FLICKER: ";(STAT AND 31)ELSE 
DISPLAY AT(1,1):" "
210 IF STAT AND 32 THEN DISPLAY AT(2,1):"COLLISION" ELSE DISPLAY AT(2,1):" 
"
220 CALL KEY(0,K,S)
230 IF K<>32 THEN 190
240 IF MODE THEN MODE=0 ELSE MODE=1
250 GOTO 120