bAtari Basic Memory Map

[CurtisP]

Here is a Memory Map I created from the std_kernel.asm and multisprite_kernel.asm

 

Location Standard Kernel								  Multisprite Kernel
 $80	player0x										 missile0x
 $81	player1x										 missile1x
 $82	missile0x	  player0colorstore				 ballx
 $83	missile1x										missile0y		 objecty
 $84	ballx											missile1y
 $85	player0y	   objecty						   bally
 $86	player1y										 SpriteIndex
 $87	missile1height player1color					  player0x
 $88	missile1y										player1x		  NewSpriteX
 $89	bally											player2x
 $8A	player0pointer player0pointerlo				  player3x
 $8B				   player0pointerhi				  player4x
 $8C	player1pointer player1pointerlo				  player5x
 $8D				   player1pointerhi				  player0y
 $8E	player0height									player1y		  NewSpriteY
 $8F	player1height  player0color					  player2y
 $90	missile0height currentpaddle					 player3y
 $91	missile0y	  paddle							player4y
 $92	ballheight									   player5y
 $93	score											_NUSIZ1		   NewNUSIZ
 $94													 NUSIZ2
 $95													 NUSIZ3
 $96	scorepointers									NUSIZ4
 $97													 NUSIZ5
 $98													 _COLUP1		   NewCOLUP1
 $99													 COLUP2
 $9A													 COLUP3
 $9B													 COLUP4
 $9C	temp1											COLUP5
 $9D	temp2											SpriteGfxIndex	P1display
 $9E	temp3
 $9F	temp4											RepoLine
 $A0	temp5											P0Top
 $A1	temp6											unused?
 $A2	rand											 player0pointerlo  player0pointer
 $A3	scorecolor									   player0pointerhi
 $A4	playfieldbase  var0							  P0Bottom
 $A5				   var1							  P1Bottom
 $A6				   var2							  player1pointerlo
 $A7				   var3							  player2pointerlo
 $A8				   var4							  player3pointerlo
 $A9				   var5							  player4pointerlo
 $AA				   var6							  player5pointerlo
 $AB				   var7							  player1pointerhi
 $AC				   var8							  player2pointerhi
 $AD				   var9							  player3pointerhi
 $AE				   var10							 player4pointerhi
 $AF				   var11							 player5pointerhi
 $B0				   var12							 player0height
 $B1				   var13							 player1height	 spriteheight
 $B2				   var14							 player2height
 $B3				   var15							 player3height
 $B4				   var16							 player4height
 $B5				   var17							 player5height
 $B6				   var18							 PF1temp1
 $B7				   var19							 PF1temp2
 $B8				   var20							 PF2temp1
 $B9				   var21							 PF2temp2
 $BA				   var22							 pfpixelheight
 $BB				   var23							 PF1pointer		playfield
 $BC				   var24
 $BD				   var25							 PF2pointer
 $BE				   var26
 $BF				   var27							 aux3			  statusbarlength
 $C0				   var28							 aux4			  pfscorecolor	 lifecolor
 $C1				   var29							 aux5			  pfscore1		 lifepointer
 $C2				   var30							 aux6			  pfscore2		 lives
 $C3				   var31							 playfieldpos
 $C4				   var32							 scorepointers
 $C5				   var33
 $C6				   var34
 $C7				   var35
 $C8				   var36
 $C9				   var37
 $CA				   var38							 temp1
 $CB				   var39							 temp2
 $CC				   var40							 temp3
 $CD				   var41							 temp4
 $CE				   var42							 temp5
 $CF				   var43							 temp6
 $D0				   var44							 temp7
 $D1				   var45							 score
 $D2				   var46
 $D3				   var47
 $D4	temp7											pfheight
 $D5	playfieldpos									 scorecolor
 $D6	A			  a								 rand
 $D7	B			  b								 A				 a
 $D8	C			  c								 B				 b
 $D9	D			  d								 C				 c
 $DA	E			  e								 D				 d
 $DB	F			  f								 E				 e
 $DC	G			  g								 F				 f
 $DD	H			  h								 G				 g
 $DE	I			  i								 H				 h
 $DF	J			  j								 I				 i
 $E0	K			  k								 J				 j
 $E1	L			  l								 K				 k
 $E2	M			  m								 L				 l
 $E3	N			  n								 M				 m
 $E4	O			  o								 N				 n
 $E5	P			  p								 O				 o
 $E6	Q			  q								 P				 p
 $E7	R			  r								 Q				 q
 $E8	S			  s								 R				 r
 $E9	T			  t								 S				 s
 $EA	U			  u								 T				 t
 $EB	V			  v								 U				 u
 $EC	W			  w								 V				 v
 $ED	X			  x								 W				 w
 $EE	Y			  y								 X				 x
 $EF	Z			  z								 Y				 y
 $F0	aux1		   pfcolortable	  pfheighttable   Z				 z
 $F1	aux2											 spritesort
 $F2	aux3		   pfscore1		  lifepointer	 spritesort2
 $F3	aux4		   pfscore2		  lives		   spritesort3
 $F4	aux5		   pfscorecolor	  lifecolor	   spritesort4
 $F5	aux6							 statusbarlength spritesort5
 $F6	stack1										   stack1
 $F7	stack2										   stack2
 $F8	stack3										   stack3
 $F9	stack4										   stack4
 $FA	stack										   stack
 $FB
 $FC
 $FD
 $FE

[CurtisP]

I already found one mistake. If anyone wants to look it over and point out any mistakes, feel free to do so.

[SeaGtGruff]

Very cool! I was going to do something similar, but hadn't gotten around to it yet. I did make a chart of the includes files that get (or ought to get) automatically selected when a given kernel and romsize are used, along with the include files that are listed (or ought to be listed) in each of the includes files:

 

 

Row 1 = Which "canned" kernel is being used (standard or multisprite).

 

Row 2 = Which romsize is being used with the kernel (2k/4k, or 8k/16k/32k, or 8kSC/16kSC/32kSC).

 

Row 3 = Which includes file will be (or ought to be) selected for the given combination of kernel and romsize.

 

Note that these first three rows are divided into two different colors-- orange for the standard kernel, and blue (or cyan) for the multisprite kernel. These colors have no special meaning; they are simply to help better distinguish between the two kernels.

 

The combination of the two kernels and three romsize groupings create six columns:

 

Column 1 = Standard kernel, romsize 2k/4k. -- The default.inc includes file is automatically selected.

 

Column 2 = Standard kernel, romsize 8k/16k/32k. -- The bankswitch.inc includes file is automatically selected.

 

Column 3 = Standard kernel, romsize 8kSC/16kSC/32kSC. -- The superchip.inc includes file is automatically selected.

 

Column 4 = Multisprite kernel, romsize 2k/4k. -- The multisprite.inc includes file is automatically selected.

 

Column 5 = Multisprite kernel, romsize 8k/16k/32k. -- The multisprite_bankswitch.inc includes file *should* be automatically selected; but due to a bug in the batari Basic v1.0 compiler, the multisprite.inc includes file is selected instead, which causes compile errors. This can be corrected by adding the line "includesfile multisprite_bankswitch.inc" to the program.

 

Column 6 = Multisprite kernel, romsize 8kSC/16kSC/32kSC. -- If we follow the naming conventions used with the other combinations, the multisprite_superchip.inc includes file *should* be automatically selected; but due to a bug in the batari Basic v1.0 compiler, the multisprite.inc includes file is selected instead, which causes compile errors. Note that the batari Basic v1.0 installation package does *not* contain a multisprite_superchip.inc includes file, but we can easily create one. Then we could correct the compile errors by adding the line "includesfile multisprite_superchip.inc" to the program, which must be placed *before* the "set kernel multisprite" and "set romsize" statements.

 

The remainder of the chart is divided into twelve more rows, with each row corresponding to a particular include file, or *type* of include file. These rows are color-coded to indicate whether the specified include files can be omitted if desired:

 

Green = The specified include files may be safely omitted to reclaim some ROM space, as long as the program doesn't refer to the routines in those include files (or replaces those routines with alternate code that uses the same routine names).

 

Yellow = The specified include files may *not* be safely omitted, *unless* they are replaced with custom include files. In other words, exercise caution if you're thinking about omitting these include files and/or replacing them with custom include files.

 

Red = The specified include files are more or less essential, and must *not* be omitted, *unless* you replace them with custom include files and/or modify the compile batch.

 

Within each of these remaining rows, one or more include files are shown, but they aren't necessarily used in each includes file, and they may be used by more than one includes file. For example, the default.inc and bankswitch.inc files both use the 2600basicheader.asm file, but the superchip.inc file uses the superchipheader.asm file instead. Also, the default.inc file doesn't place the bB.asm file between the 2600basicheader.asm and std_kernel.asm files; instead, it places the bB.asm file much further down. On the other hand, the bankswitch.inc and superchip.inc files both place the bB.asm file just before the std_kernel.asm file, and place a bB2.asm file much further down, in the spot where the default.inc file places the bB.asm file.

 

Michael

[Robert M]

Good stuff. Thanks for sharing.

[+batari]

Looks great, and should be useful for things like debugging in the Stella debugger.

 

However, I see a few errors in the MSK:

$9D SpriteGfxIndex P1display

$9E

$9F RepoLine

$A0 P0Top

$A1 unused?

 

SpriteGfxIndex uses 5 bytes, so all of these are taken (no unused bytes, sorry.)

 

Also, P1Display is $CB, Repoline is $CD, and P0Top is $CE.

[CurtisP]

Looks great, and should be useful for things like debugging in the Stella debugger.

 

Thanks bAtari. I will get those changes in. My main purpose for doing this was so that I made sure my minikernel didn't have any conflicts. It;s how I discovered that it will crash the multisprite kernel. But now I know how to fix it.

[+batari]

Looks great, and should be useful for things like debugging in the Stella debugger.

 

Thanks bAtari. I will get those changes in. My main purpose for doing this was so that I made sure my minikernel didn't have any conflicts. It;s how I discovered that it will crash the multisprite kernel. But now I know how to fix it.

If all you need are reliable temp variables for a minikernel, there are lots you can use.

 

I think, but haven't confirmed that PF1temp1, PF1temp2, PF2temp1, PF2temp2, and possibly pfpixelheight, P0Bottom and P1Bottom are used only by the kernel but they don't need to remember values for the next frame. If true, these can be used as temp vars in regular bB code as well, but they will be overwritten in the next frame. If I can confirm this, I might create new labels for them, such as temp8-temp14.

 

In case anyone asks, I don't think the standard kernel has any "bonus" temp vars like this.

[CurtisP]

In case anyone asks, I don't think the standard kernel has any "bonus" temp vars like this.

 

I'm designing the minikernel to work with both kernels, so I will stick with the variables available in both.