+Random Terrain Posted December 8, 2010 Share Posted December 8, 2010 The bB page has a Standard Kernel Memory Map and a Multisprite Kernel Memory Map, so does it also need a Superchip Memory Map? If it does, has anyone made one that I can put on the page? Thanks. Quote Link to comment Share on other sites More sharing options...
jrok Posted December 8, 2010 Share Posted December 8, 2010 The bB page has a Standard Kernel Memory Map and a Multisprite Kernel Memory Map, so does it also need a Superchip Memory Map? If it does, has anyone made one that I can put on the page? Thanks. write_RAM = $F000 wRAM = $F000 w000 = $F000 w001 = $F001 w002 = $F002 w003 = $F003 w004 = $F004 w005 = $F005 w006 = $F006 w007 = $F007 w008 = $F008 w009 = $F009 w010 = $F00A w011 = $F00B w012 = $F00C w013 = $F00D w014 = $F00E w015 = $F00F w016 = $F010 w017 = $F011 w018 = $F012 w019 = $F013 w020 = $F014 w021 = $F015 w022 = $F016 w023 = $F017 w024 = $F018 w025 = $F019 w026 = $F01A w027 = $F01B w028 = $F01C w029 = $F01D w030 = $F01E w031 = $F01F w032 = $F020 w033 = $F021 w034 = $F022 w035 = $F023 w036 = $F024 w037 = $F025 w038 = $F026 w039 = $F027 w040 = $F028 w041 = $F029 w042 = $F02A w043 = $F02B w044 = $F02C w045 = $F02D w046 = $F02E w047 = $F02F w048 = $F030 w049 = $F031 w050 = $F032 w051 = $F033 w052 = $F034 w053 = $F035 w054 = $F036 w055 = $F037 w056 = $F038 w057 = $F039 w058 = $F03A w059 = $F03B w060 = $F03C w061 = $F03D w062 = $F03E w063 = $F03F w064 = $F040 w065 = $F041 w066 = $F042 w067 = $F043 w068 = $F044 w069 = $F045 w070 = $F046 w071 = $F047 w072 = $F048 w073 = $F049 w074 = $F04A w075 = $F04B w076 = $F04C w077 = $F04D w078 = $F04E w079 = $F04F w080 = $F050 w081 = $F051 w082 = $F052 w083 = $F053 w084 = $F054 w085 = $F055 w086 = $F056 w087 = $F057 w088 = $F058 w089 = $F059 w090 = $F05A w091 = $F05B w092 = $F05C w093 = $F05D w094 = $F05E w095 = $F05F w096 = $F060 w097 = $F061 w098 = $F062 w099 = $F063 w100 = $F064 w101 = $F065 w102 = $F066 w103 = $F067 w104 = $F068 w105 = $F069 w106 = $F06A w107 = $F06B w108 = $F06C w109 = $F06D w110 = $F06E w111 = $F06F w112 = $F070 w113 = $F071 w114 = $F072 w115 = $F073 w116 = $F074 w117 = $F075 w118 = $F076 w119 = $F077 w120 = $F078 w121 = $F079 w122 = $F07A w123 = $F07B w124 = $F07C w125 = $F07D w126 = $F07E w127 = $F07F read_RAM = $F080 rRAM = $F080 r000 = $F080 r001 = $F081 r002 = $F082 r003 = $F083 r004 = $F084 r005 = $F085 r006 = $F086 r007 = $F087 r008 = $F088 r009 = $F089 r010 = $F08A r011 = $F08B r012 = $F08C r013 = $F08D r014 = $F08E r015 = $F08F r016 = $F090 r017 = $F091 r018 = $F092 r019 = $F093 r020 = $F094 r021 = $F095 r022 = $F096 r023 = $F097 r024 = $F098 r025 = $F099 r026 = $F09A r027 = $F09B r028 = $F09C r029 = $F09D r030 = $F09E r031 = $F09F r032 = $F0A0 r033 = $F0A1 r034 = $F0A2 r035 = $F0A3 r036 = $F0A4 r037 = $F0A5 r038 = $F0A6 r039 = $F0A7 r040 = $F0A8 r041 = $F0A9 r042 = $F0AA r043 = $F0AB r044 = $F0AC r045 = $F0AD r046 = $F0AE r047 = $F0AF r048 = $F0B0 r049 = $F0B1 r050 = $F0B2 r051 = $F0B3 r052 = $F0B4 r053 = $F0B5 r054 = $F0B6 r055 = $F0B7 r056 = $F0B8 r057 = $F0B9 r058 = $F0BA r059 = $F0BB r060 = $F0BC r061 = $F0BD r062 = $F0BE r063 = $F0BF r064 = $F0C0 r065 = $F0C1 r066 = $F0C2 r067 = $F0C3 r068 = $F0C4 r069 = $F0C5 r070 = $F0C6 r071 = $F0C7 r072 = $F0C8 r073 = $F0C9 r074 = $F0CA r075 = $F0CB r076 = $F0CC r077 = $F0CD r078 = $F0CE r079 = $F0CF r080 = $F0D0 r081 = $F0D1 r082 = $F0D2 r083 = $F0D3 r084 = $F0D4 r085 = $F0D5 r086 = $F0D6 r087 = $F0D7 r088 = $F0D8 r089 = $F0D9 r090 = $F0DA r091 = $F0DB r092 = $F0DC r093 = $F0DD r094 = $F0DE r095 = $F0DF r096 = $F0E0 r097 = $F0E1 r098 = $F0E2 r099 = $F0E3 r100 = $F0E4 r101 = $F0E5 r102 = $F0E6 r103 = $F0E7 r104 = $F0E8 r105 = $F0E9 r106 = $F0EA r107 = $F0EB r108 = $F0EC r109 = $F0ED r110 = $F0EE r111 = $F0EF r112 = $F0F0 r113 = $F0F1 r114 = $F0F2 r115 = $F0F3 r116 = $F0F4 r117 = $F0F5 r118 = $F0F6 r119 = $F0F7 r120 = $F0F8 r121 = $F0F9 r122 = $F0FA r123 = $F0FB r124 = $F0FC r125 = $F0FD r126 = $F0FE r127 = $F0FF Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted December 8, 2010 Share Posted December 8, 2010 The bB page has a Standard Kernel Memory Map and a Multisprite Kernel Memory Map, so does it also need a Superchip Memory Map? If it does, has anyone made one that I can put on the page? I'm not sure whether you mean the memory inside the Superchip, or the zero-page addresses that are used when the playfield gets moved to the Superchip, or both. If both, I would include the playfield RAM addresses that are inside the Superchip. Michael Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 8, 2010 Author Share Posted December 8, 2010 I'm not sure whether you mean the memory inside the Superchip, or the zero-page addresses that are used when the playfield gets moved to the Superchip, or both. If both, I would include the playfield RAM addresses that are inside the Superchip. I mean something that looks like the following, except with the Superchip changes: Standard Kernel Memory Map $80 player0x $81 player1x $82 player0colorstore missile0x $83 missile1x $84 ballx $85 player0y objecty $86 player1y $87 player1color missile1height $88 missile1y $89 bally $8a player0pointer player0pointerlo $8b player0pointerhi $8c player1pointer player1pointerlo $8d player1pointerhi $8e player0height $8f player1height $90 player0color currentpaddle missile0height $91 paddle missile0y $92 ballheight $93 score $94 $95 $96 scorepointers $97 $98 $99 $9a $9b $9c temp1 $9d temp2 $9e temp3 $9f temp4 $a0 temp5 $a1 temp6 $a2 rand $a3 scorecolor $a4 var0 Playfield Variables $a5 var1 $a6 var2 There are 4 variables for each row. $a7 var3 (8 bits x 4 = 32) $a8 var4 $a9 var5 $aa var6 $ab var7 $ac var8 $ad var9 $ae var10 $af var11 $b0 var12 $b1 var13 $b2 var14 $b3 var15 $b4 var16 $b5 var17 $b6 var18 $b7 var19 $b8 var20 $b9 var21 $ba var22 $bb var23 $bc var24 $bd var25 $be var26 $bf var27 $c0 var28 $c1 var29 $c2 var30 $c3 var31 $c4 var32 $c5 var33 $c6 var34 $c7 var35 $c8 var36 $c9 var37 $ca var38 $cb var39 $cc var40 $cd var41 $ce var42 $cf var43 $d0 var44 $d1 var45 $d2 var46 $d3 var47 $d4 temp7 $d5 playfieldpos $d6 A a $d7 B b $d8 C c $d9 d D $da E e $db F f $dc G g $dd H h $de I i $df J j $e0 K k $e1 L l $e2 M m $e3 N n $e4 O o $e5 P p $e6 Q q $e7 R r $e8 S s $e9 T t $ea U u $eb V v $ec W w $ed X x $ee Y y $ef Z z $f0 pfheighttable pfcolortable aux1 $f1 aux2 $f2 lifepointer aux3 pfscore1 $f3 aux4 pfscore2 lives $f4 aux5 pfscorecolor lifecolor $f5 statusbarlength aux6 $f6 stack1 $f7 stack2 $f8 stack3 $f9 stack4 $fa [reserved for the stack] $fb [reserved for the stack] $fc [reserved for the stack] $fd [reserved for the stack] $fe [reserved for the stack] $ff [reserved for the stack] Doesn't some of that change when we use SC? Quote Link to comment Share on other sites More sharing options...
jrok Posted December 8, 2010 Share Posted December 8, 2010 (edited) I'm not sure whether you mean the memory inside the Superchip, or the zero-page addresses that are used when the playfield gets moved to the Superchip, or both. If both, I would include the playfield RAM addresses that are inside the Superchip. I mean something that looks like the following, except with the Superchip changes: Standard Kernel Memory Map $80 player0x $81 player1x $82 player0colorstore missile0x $83 missile1x $84 ballx $85 player0y objecty $86 player1y $87 player1color missile1height $88 missile1y $89 bally $8a player0pointer player0pointerlo $8b player0pointerhi $8c player1pointer player1pointerlo $8d player1pointerhi $8e player0height $8f player1height $90 player0color currentpaddle missile0height $91 paddle missile0y $92 ballheight $93 score $94 $95 $96 scorepointers $97 $98 $99 $9a $9b $9c temp1 $9d temp2 $9e temp3 $9f temp4 $a0 temp5 $a1 temp6 $a2 rand $a3 scorecolor $a4 var0 Playfield Variables $a5 var1 $a6 var2 There are 4 variables for each row. $a7 var3 (8 bits x 4 = 32) $a8 var4 $a9 var5 $aa var6 $ab var7 $ac var8 $ad var9 $ae var10 $af var11 $b0 var12 $b1 var13 $b2 var14 $b3 var15 $b4 var16 $b5 var17 $b6 var18 $b7 var19 $b8 var20 $b9 var21 $ba var22 $bb var23 $bc var24 $bd var25 $be var26 $bf var27 $c0 var28 $c1 var29 $c2 var30 $c3 var31 $c4 var32 $c5 var33 $c6 var34 $c7 var35 $c8 var36 $c9 var37 $ca var38 $cb var39 $cc var40 $cd var41 $ce var42 $cf var43 $d0 var44 $d1 var45 $d2 var46 $d3 var47 $d4 temp7 $d5 playfieldpos $d6 A a $d7 B b $d8 C c $d9 d D $da E e $db F f $dc G g $dd H h $de I i $df J j $e0 K k $e1 L l $e2 M m $e3 N n $e4 O o $e5 P p $e6 Q q $e7 R r $e8 S s $e9 T t $ea U u $eb V v $ec W w $ed X x $ee Y y $ef Z z $f0 pfheighttable pfcolortable aux1 $f1 aux2 $f2 lifepointer aux3 pfscore1 $f3 aux4 pfscore2 lives $f4 aux5 pfscorecolor lifecolor $f5 statusbarlength aux6 $f6 stack1 $f7 stack2 $f8 stack3 $f9 stack4 $fa [reserved for the stack] $fb [reserved for the stack] $fc [reserved for the stack] $fd [reserved for the stack] $fe [reserved for the stack] $ff [reserved for the stack] Doesn't some of that change when we use SC? I believe all of the addresses are the same as in the standard kernel, with the added r/w addresses I gave you above (from superchip.h). You also might want to note that var0-var47 are not being used to store the playfield when the superchip option is enabled, since this is now stored in superchip RAM. Those variables are free for general use, as are any of the additional w/r addresses that aren't being used to store the playfield. The amount of free r/w RAM available is dependent on your playfield resolution. For instance, a 32 pfres will use all SC variables w/r000 - w/r127 whereas a 24 pfres will only use w/r033- w/r127, etc. Edited December 8, 2010 by jrok Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 9, 2010 Author Share Posted December 9, 2010 I believe all of the addresses are the same as in the standard kernel, with the added r/w addresses I gave you above (from superchip.h). Thanks. Since nothing much changes, I probably won't have to make a full SC memory map. I can just put one or more charts in the Superchip RAM section, similar to what I have here under the Playfield section: http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#playfield You also might want to note that var0-var47 are not being used to store the playfield when the superchip option is enabled, since this is now stored in superchip RAM. Those variables are free for general use, as are any of the additional w/r addresses that aren't being used to store the playfield. The amount of free r/w RAM available is dependent on your playfield resolution. For instance, a 32 pfres will use all SC variables w/r000 - w/r127 whereas a 24 pfres will only use w/r033- w/r127, etc. Thanks. I see that if we leave the screen at the default resolution, the visible screen is r/w080 through r/w123 and the hidden row is r/w124 through r/w127. If users want to use pfres to have a higher resolution screen, is there a simple way for them to calculate how far back from r/w080 they'll be going? I'm not sure I have the numbers right. For example, the normal resolution is 12 * 4 = 48 and 128 - 48 = 80. That tells you that r/w080 through r/w127 are being used. I tested it out using "w080=rand : w123=rand" and it's correct. Problem is this: 24 * 4 = 96 and 128 - 96 = 32. That would be w/r032 through w/r127, not the w/r033 that you posted. Is your w/r033 incorrect? I'd test it myself, but when I made a simple test program using "const pfres=24" I get this error: --- Unresolved Symbol List kernelmacrodef 0000 ???? (R ) pfwidth 0000 ???? (R ) Can you tell if anything is wrong with my test code: set romsize 16kSC const pfres=24 playfield: X..............XX..............X X....X.XX......................X X...............XXXXXX.X..X..... X..............................X X..............................X X..............................X X..............................X XXX.XX.X.......XXXXXXXXXXXXXXX.. X..............................X X..............................X X...........X...XXXX...........X ...............................X ...............................X X............................... ...............................X X....................XX.XXXX...X X..............................X X......X...XX..................X X....XX.XXXX.X......XX.........X X..............................X X..............................X X..............................X X..............................X X.........X.X.XX.X...XX........X end Main_Loop COLUPF = $CE : COLUBK = $80 drawscreen goto Main_Loop bank 2 bank 3 bank 4 Thanks. Quote Link to comment Share on other sites More sharing options...
jrok Posted December 9, 2010 Share Posted December 9, 2010 (edited) Thanks. I see that if we leave the screen at the default resolution, the visible screen is r/w080 through r/w123 and the hidden row is r/w124 through r/w127. Yep. The last four are the hidden row, and so can be used freely with no trouble. Problem is this: 24 * 4 = 96 and 128 - 96 = 32. That would be w/r032 through w/r127, not the w/r033 that you posted. Is your w/r033 incorrect? Sorry, that was a typo on my part. It would be r032-r127. I'd test it myself, but when I made a simple test program using "const pfres=24" I get this error: --- Unresolved Symbol List kernelmacrodef 0000 ???? (R ) pfwidth 0000 ???? (R ) Can you tell if anything is wrong with my test code: set romsize 16kSC const pfres=24 ... I didn't have any trouble compiling it, so I'm not sure what the problem could be. Edited December 9, 2010 by jrok Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 9, 2010 Author Share Posted December 9, 2010 I didn't have any trouble compiling it, so I'm not sure what the problem could be. Thanks. I guess that means batari's latest version of bB is messed up: http://www.atariage.com/forums/topic/168036-new-build-improved-if-then/ Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted December 9, 2010 Share Posted December 9, 2010 I didn't have any trouble compiling it, so I'm not sure what the problem could be. Thanks. I guess that means batari's latest version of bB is messed up: http://www.atariage....proved-if-then/ There's a reference to pfwidth that suddenly appeared in that build. If you define pfwidth as a constant, and set it to 4, everything works hunky-dory. I assume Fred was toying around with something. This was driving me crazy for a while, until I saw a thread a while back in which someone suggested this solution: const pfwidth=4 As I recall, there used to be a 4 in the spot where pfwidth suddenly appeared, I think where it's calculating the amount of RAM taken up by the playfield. It would appear that pfwidth is/was intended to allow defining a narrower playfield, or maybe even a wider playfield, but I really don't know. Michael Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 9, 2010 Author Share Posted December 9, 2010 There's a reference to pfwidth that suddenly appeared in that build. If you define pfwidth as a constant, and set it to 4, everything works hunky-dory. I assume Fred was toying around with something. This was driving me crazy for a while, until I saw a thread a while back in which someone suggested this solution: const pfwidth=4 As I recall, there used to be a 4 in the spot where pfwidth suddenly appeared, I think where it's calculating the amount of RAM taken up by the playfield. It would appear that pfwidth is/was intended to allow defining a narrower playfield, or maybe even a wider playfield, but I really don't know. Thanks. You can ignore my wondering about it in the other thread. Quote Link to comment Share on other sites More sharing options...
+batari Posted December 11, 2010 Share Posted December 11, 2010 I didn't have any trouble compiling it, so I'm not sure what the problem could be. Thanks. I guess that means batari's latest version of bB is messed up: http://www.atariage....proved-if-then/ There's a reference to pfwidth that suddenly appeared in that build. If you define pfwidth as a constant, and set it to 4, everything works hunky-dory. I assume Fred was toying around with something. This was driving me crazy for a while, until I saw a thread a while back in which someone suggested this solution: const pfwidth=4 As I recall, there used to be a 4 in the spot where pfwidth suddenly appeared, I think where it's calculating the amount of RAM taken up by the playfield. It would appear that pfwidth is/was intended to allow defining a narrower playfield, or maybe even a wider playfield, but I really don't know. Michael pfwidth is supposed to be defined in 2600basic.h. It seems that I really need to get a coherent version of bB on the website to eliminate all of these dependencies. That said, the bBWin7_64bit.zip file on the Visual bB main post is the most current collection of bB files available. It's not just for 64-bit Windows, the files here should work fine in any 32-bit versions of Windows as well. Post is here: http://www.atariage.com/forums/topic/123849-visual-bb-1-0-a-new-ide-for-batari-basic/ Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 11, 2010 Author Share Posted December 11, 2010 That said, the bBWin7_64bit.zip file on the Visual bB main post is the most current collection of bB files available. It's not just for 64-bit Windows, the files here should work fine in any 32-bit versions of Windows as well. Post is here: http://www.atariage.com/forums/topic/123849-visual-bb-1-0-a-new-ide-for-batari-basic/ Thanks. That fixed it. Now I don't have to use const pfwidth=4 for it to work. When you get the time, it would be nice for the version on the main web site to be the most current. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.