Jump to content
IGNORED

Please walk me through pfres using Superchip ram


freshbrood

Recommended Posts

I was able to play with the Standard Kernel. I'm not an expert (or maybe way off target), but I think this is what you are looking for. I used "The Cabin" by Odourman as an example. Attached is the code in text and .bas for an Emulator. Maybe someone else will chime in as well. If you change 10 to other numbers the screen will shrink. I also attached the MulstiSprite Version as well of "The Quest". If change the pf height it will adjust the screen, but I'm not sure on "Variables Freed". Hope this helps, thanks.

 

;***************************************************************
;
; Also, note that reducing the number of rows may or may not shrink the
; size of your screen since bB tries to fill as much of the screen as possible
; by varying the height of the pixel rows. The default row heights and free variables
; corresponding to the overall playfield height (pfres) is:
;
; pfres Row Height Variables Freed
; 12 8 none
; 11 8 var0-var3
; 10 9 var0-var7
; 9 10 var0-var11
; 8 12 var0-var15
; 7 13 var0-var19
; 6 16 var0-var23
; 5 19 var0-var27
; 4 24 var0-var31
; 3 32 var0-var35
;***************************************************************
;
; Change the below number to corespond with the above to free the variables
const pfres=10

20180721 - pfrowheight_SD Kernel.txt

20180721 - pfrowheight_SD Kernel.bas.bin

20180721 - pfrowheight_MS Kernel.bas.bin

20180721 - pfrowheight_MS Kernel.txt

  • Like 1
Link to comment
Share on other sites

The bB page has a Pac-Man-like maze example program that uses Superchip RAM:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#maze_32x23

 

It uses "set romsize 16kSC" and "const pfres=23" and this is used before the main loop:


   playfield:
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   X..............XX..............X
   X..............XX..............X
   X..XXX..XXXXX..XX..XXXXX..XXX..X
   X..............................X
   X..............................X
   X..XXX..X..XXXXXXXXXX..X..XXX..X
   X.......X......XX......X.......X
   X.......X......XX......X.......X
   XXXXXX..XXXXX..XX..XXXXX..XXXXXX
   X..............................X
   X..............................X
   X..XXX..XXXXXXX..XXXXXXX..XXX..X
   X....X....................X....X
   X....X....................X....X
   XXX..X..X..XXXXXXXXXX..X..X..XXX
   X.......X......XX......X.......X
   X.......X......XX......X.......X
   X..XXXXXXXXXX..XX..XXXXXXXXXX..X
   X..............................X
   X..............................X
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end
  • Like 2
Link to comment
Share on other sites

  • 4 years later...
14 minutes ago, freshbrood said:

Is it possible to get more than 11+1 vertical pfblocks WITHOUT using Superchip ram?

No. The playfield is stored in RAM, and uses up 48 bytes of RAM. Allowing more rows would require more bytes/variables that the standard kernel really doesn't have to spare. 

  • Like 2
Link to comment
Share on other sites

19 hours ago, Karl G said:

No. The playfield is stored in RAM, and uses up 48 bytes of RAM. Allowing more rows would require more bytes/variables that the standard kernel really doesn't have to spare. 

Sorry. I know I've asked this before but it's been a while since I chipped away at this. Severely broke my ankle. I feel like if it weren't for bad luck I'd have none at all. Thanks.

 

Well.. what if using the standard kernel I didn't need many variables? Like I wasn't making a game but a simple screensaver or retro storefront ad and only needed about 10 variables for the program itself. Is there a way to hack some more vertical resolution using the remaining variables then?

Edited by freshbrood
Link to comment
Share on other sites

5 hours ago, freshbrood said:

Well.. what if using the standard kernel I didn't need many variables? Like I wasn't making a game but a simple screensaver or retro storefront ad and only needed about 10 variables for the program itself. Is there a way to hack some more vertical resolution using the remaining variables then?

Probably yes, but it would be more trouble than I would want to deal with, at least. At minimum, it would require altering the memory map to have the extra variables be contiguous with the existing playfield variables. It would probably require more hackery than that as well.

  • Like 1
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...