Please walk me through pfres using Superchip ram

[freshbrood]

I can't find any instructions or tutorials on how to implement this and draw a playfield.

 

Also, how do we draw using the pfrowheights kernel, and what is the difference?

[Lewis2907]

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#pfrowheight

 

Is at RT site, thanks.

[freshbrood]

This doesn't tell me anything at all. I've seen it, and it is not helpful to amateur programmers. How do I draw a playfield using this? Using const pfres with many diffetent numbers only gives me giant blocks or random, unordered blocks.

[Lewis2907]

Oh okay got it. When I get off work today. I will post one my programs. It's should work for you.

[Lewis2907]

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

[+Random Terrain]

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

[freshbrood]

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

[+Karl G]

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. 

[freshbrood]

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 July 22 by freshbrood

[+Karl G]

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.