Mord's Blog

You might want to look at Nukey Shay's adventure hacks. They include a very nice way by which playfield "zones" may vary in size, even within a room. From top to bottom, label each scan lines pair as follows:

DABACABAEABACABA (repeating every 16 line-pairs). If the leat-significant nybble of a zone's PF0 data is $0F, the zone will extend until the next "E" line pair. If $07, until the next "D" or "E" pair. If $03, "C", "D", or "E". If $01, the next line pair that isn't "A". If $00, to the next line pair.

 

This makes it possible to include rather fine details in the rooms without expanding memory requirements in places such ability is not exploited.

BTW, if you're trying to save a few cycles in the kernel, you might want to have separate kernel loops for the following cases:

• Above both sprites, both of which start on the same scan line
  
• Above both sprites, with P0 starting first
  
• Between the tops of P0 and P1
  
• Below the tops of both sprites
  

Requiring P0 to start above P1 should not pose any particular problem, though if you didn't want to impose that requirement you could add two more cases. Some further time savings could be achieved if you separated out the cases that were completely below sprites (WR's game design just keeps showing the last blank row of a sprite over and over again) but that might add some extra complexity.

BTW, if you're trying to save a few cycles in the kernel, you might want to have separate kernel loops for the following cases:

• Above both sprites, both of which start on the same scan line
  
• Above both sprites, with P0 starting first
  
• Between the tops of P0 and P1
  
• Below the tops of both sprites
  

Requiring P0 to start above P1 should not pose any particular problem, though if you didn't want to impose that requirement you could add two more cases. Some further time savings could be achieved if you separated out the cases that were completely below sprites (WR's game design just keeps showing the last blank row of a sprite over and over again) but that might add some extra complexity.

 

 

Thanks for the tips. I haven't added sprites into the kernal yet as I build this thing up little by little, but things like that have been on the corner of my mind for a while already.

 

Looking at the other note about the playfield zones, I have a vague idea what you're talking about, but something's not clicking somewhere. Probably a good thing that I'm going to look at collision detection next for a bit so I can hopefully figure out exactly how nukey's technique works.

Looking at the other note about the playfield zones, I have a vague idea what you're talking about, but something's not clicking somewhere. Probably a good thing that I'm going to look at collision detection next for a bit so I can hopefully figure out exactly how nukey's technique works.

 

Nukey's technique is a bit tricky, but worth considering. Because the kernel uses three bytes of ROM for each playfield zone, but the TIA ignores four bits of one of them, those bits are free for other purposes.

 

Warren Robinett's original kernel did something like:

 lda ScanLineCnt
 and #$0F
 bne no_new_row
; Now handle new playfield row
 ldy RoomDefIndex
 lda (RoomLo),y
 sta pf0
 iny
 lda (RoomLo),y
 sta pf1
 iny
 lda (RoomLo),y
 sta pf2
 iny
 sty RoomDefIndex

Nukey managed to squeeze in enough cycles to change it to something like:

 lda ScanLineCnt
 and $FA
 bne no_new_row
; Now handle new playfield row
 ldy RoomDefIndex
 lda (RoomLo),y
 sta pf0
 iny
 lda (RoomLo),y
 sta pf1
 iny
 lda (RoomLo),y
 sta pf2
 iny
 sty RoomDefIndex
...
no_new_row:
 ldy RoomDefIndex; Note we can afford to spend a little extra time here since we're not updating playfield
 lda (RoomLo),y
 and #$0F
 sta $FA

A bit tricky, but nonetheless elegant in its own way.