CurtisP Posted September 14, 2007 Share Posted September 14, 2007 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 Quote Link to comment Share on other sites More sharing options...
CurtisP Posted September 14, 2007 Author Share Posted September 14, 2007 I already found one mistake. If anyone wants to look it over and point out any mistakes, feel free to do so. Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted September 14, 2007 Share Posted September 14, 2007 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 Quote Link to comment Share on other sites More sharing options...
Robert M Posted September 14, 2007 Share Posted September 14, 2007 Good stuff. Thanks for sharing. Quote Link to comment Share on other sites More sharing options...
+batari Posted September 14, 2007 Share Posted September 14, 2007 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. Quote Link to comment Share on other sites More sharing options...
CurtisP Posted September 14, 2007 Author Share Posted September 14, 2007 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. Quote Link to comment Share on other sites More sharing options...
+batari Posted September 15, 2007 Share Posted September 15, 2007 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. Quote Link to comment Share on other sites More sharing options...
CurtisP Posted September 15, 2007 Author Share Posted September 15, 2007 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.