Cybearg

Correct me if I'm wrong, but I was under the impression that the AtariVox came with some extra RAM included. Does this also apply to the SaveKey? If so, how can this additional RAM be accessed?

You're right. Bleh, silly me! Actually, the reversal of the playfield bits makes horizontally flipping the playfield super-easy: for temp1 = 0 to 47 step 4 temp2 = var2[temp1] temp3 = var3[temp1] var3[temp1] = var0[temp1] var2[temp1] = var1[temp1] var0[temp1] = temp3 var1[temp1] = temp2 next EDIT: So here are the two flips as I've figured them out. Not sure if there's a more efficient way to do it or not, but if there is, please let me know! flipvert for temp1 = 0 to 23 temp2 = temp1 / 4 temp3 = 11 - temp2 temp4 = temp1 & 3 temp5 = temp3 * 4 temp6 = temp5 + temp4 temp2 = var0[temp1] var0[temp1] = var0[temp6] var0[temp6] = temp2 next return thisbank fliphoriz for temp1 = 0 to 47 step 4 temp2 = var2[temp1] temp3 = var3[temp1] var3[temp1] = var0[temp1] var2[temp1] = var1[temp1] var0[temp1] = temp3 var1[temp1] = temp2 next return thisbank

This is for the standard kernel, obviously. Is there and efficient way to flip the playfield, both for horizontal flip and vertical flip? Any suggestions?

Ohh, right. Silly me. >.>

For some reason, this: data list %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %11101111, %10111011, %11111100, %11101110, %01111100, %01011100, %11010111, %01010111, %11101111, %00100111, %10110101, %11111111, %00111011, %01011100, %01011111, %11100111, %11101110, %11101111, %11010111, %11011011, %11110110, %11101111, %01011010, %01101010, %01011101, %11111111, %01111111, %10100010, %11101101, %10111101, %10111011, %10111111, %10111010, %11101101, %10010111, %10111010, %11010111, %11010110, %10110101, %01111101, %10111010, %11111101, %11011111, %10101010, %11001110, %11110101, %01110101, %10111101, %10111011, %01010101, %10111101, %10111101, %10101011, %10110101, %11110111, %11011111, %11110111, %10110101, %11010101, %11111111, %10110111. %11011011, %11101110, %11101001, %11010111, %10110111, %11111001, %01110111, %10110100, %10111011, %11101011, %11101011, %01101101, %01000110, %10101010, %00011100, %01111011, %00100111, %10101011, %11011011, %11010110, %11111110, %11011011, %11100111, %10111101, %11011011, %01011010, %10101101, %01001100, %11101111, %01111111, %11010011, %11011101. %01111110, %10111011, %01011111, %10111101, %11011101, %00101100, %11011001, %00001110, %11101010, %10111110, %10111110, %11001001, %11010101, %11111010, %10101010, %11001110, %11110101, %10111001, %10111101, %01101110, %01110001, %10111101, %10111101, %11010101, %10101101, %11101111, %11111011, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %01111111, %01111011, %00100111, %11111111, %00111011, %10011101, %11100111, %11100111, %11111011, %01111111, %11101011, %11011011, %01101111, %11110111, %01011010, %01010110 end gets me an error: Any idea why?

Is it a simple matter to display the score anywhere? That is, if we wanted the score at the top rather than the bottom? Great to hear it's simple, though it makes sense, really, since spreading them apart just means wasting some time between them getting drawn.

Just for reference, would you mind linking to those mini-kernels you mentioned?

If I was referencing a memory location of, say, $83, how would it know the difference between me loading the hex number of $83 versus the address of the memory location stored in $83?

Ahh, I see. So if I do LDA aa, it's the equivalent of deferencing the pointer, while LDA #aa maintains the memory address?

Hm... I've tried doing like so: dim aa = $93 dim ab = $94 ...etc. aa = 0 ab = %00101000 ac = %00111000 ...etc. asm LDX frame LDA aa STA player0pointerlo LDA #00 STA player0pointerhi LDA #13 STA player0height end ... And I didn't seem to have much luck with that. I'll try again later, but I'm probably doing something wrong, eh?

Amazing work!

Good suggestion, and it may be what I end up doing, though, at the time of me making the original post, I already had two 8-byte arrays out of the primary memory. Now that Omega has generously spent his time fixing all this together, I'm back to wondering about how one would go about reading a sprite from memory. Currently, hi and lo pointers are set, but I'm not clear on how that would translate to putting a sprite in memory. Could the pointers be set to the high and low points of the memory that contains the sprite data? For instance, player0pointerhi = $80 player0pointerlo = $87 player0height = 8 Would it then run through the 8 memory locations, loading each line of the sprite? I somehow doubt it'd be that simple.

Works perfectly aside from one little typo: player1pointerlo = $98 player2pointerlo = player2pointerlo+1 ; $99 ; player3pointerlo = player2pointerlo+2 ; player4pointerlo = player2pointerlo+3 ; player5pointerlo = player2pointerlo+4 should be: player1pointerlo = $98 player2pointerlo = player1pointerlo+1 ; $99 ; player3pointerlo = player1pointerlo+2 ; player4pointerlo = player1pointerlo+3 ; player5pointerlo = player1pointerlo+4 Thanks so much! And, with minimal tweaking, this should be able to be adjusted for any number of players, right? Just do some counting and set the memory values appropriately and uncomment the necessary number of memory locations? Now, any idea about a memory-based sprite?

I'd like to have player 0's sprite be held in memory so it can be modified easily on the fly without many variations necessary. I'm using the multisprite kernel, and it just so happens that I only need 3 out of the 6 possible sprites, so I went through the memory map and commented out any memory assignments that weren't being used and instead just gave all those variables a constant value of 0. This seems to work fine as I've not noticed any problems since making these modifications. By my estimations, this frees up approximately 27 bytes for my use, which is great because the player 0 sprite is only 12 pixels high. Additionally, it would leave me another 15 bytes to use for whatever beyond the memory sprite. However, I need help with two things: In order to use the free memory in array-form, as I presume would be necessary for a memory-based sprite like I described, the memory locations would have to be in line, not random memory locations separated by chunks of used memory. I've tried reconfiguring the Multisprite memory map by moving all memory locations down in the memory. For instance, I'm not using missile0x or missile1x, which have memory locations of $80 and $81 respectively. The next used memory location is ballx, at $82, which IS being used. So I'd move ballx up to $80 and shift all other memory locations up three as well, etc. The problem is, especially when dealing with the memory locations for sprite pointers, it doesn't seem to like them being shifted around. I keep the same number of bytes free (for instance, PF1pointer and PF2pointer are actually 2 bytes large, so the map skips two memory locations to make sure that they have enough space allocated), but it still results in problems. I'm not sure if this is because the kernel is pointing directly to a memory location instead of using the definitions, because there's something special about certain memory locations, or what, but it's definitely a problem. Does anyone have any idea what could be the matter? I've attached my current Multisprite memory map, which DOES presently work, but it needs to have all the values shifted up. Maybe someone else will have more luck with it than I've been having. For reference, the memory I recovered should be in these locations: rem borrowed memory dim aa = $80 dim ab = $81 dim ac = $87 dim ad = $88 dim ae = $89 dim af = $8A dim ag = $8B dim ah = $90 dim ai = $91 dim aj = $91 dim ak = $93 dim al = $94 dim am = $95 dim an = $96 dim ao = $97 dim ap = $9A dim aq = $9B dim ar = $9C dim as = $A8 dim at = $A9 dim au = $AA dim av = $AD dim aw = $AE dim ax = $AF dim ay = $B3 dim az = $B4 dim ba = $B5 How do I modify the kernel to look at the memory for sprite definitions, rather than to the ROM? multisprite.h.txt

Complimentary colors are colors that reside on opposite sides of the color wheel: This is so named because these colors tend to stand out well from each other, yet they often look good together. You see it often in older games, such as Castlevania: The warmer orange stands out as the clear foreground while the cooler blue recedes into the background.

Do you have the latest .NET installed on that system? vBb needs it.

You may be asking in the wrong place. You're asking the bB developers only, many of whom focus on their own projects. Maybe you should be asking in the 2600 general forum or somewhere where the fans and not just the busy developers hang out?

Maybe it's just me, but when I put a value higher than 31 in for a sound frequency, I just get a low hissing sound--not total silence.

Just a random Tumblr thing. Zippy should totally have a butt-attack, though.

I've had varied responses to parenthesis as well... It's inconsistent between versions.

How about: if a && !(a & 7) then c = 0 That may not work perfectly as is, but basically: if a > 0 and a % 8 = 0 then c = 0 If a is greater than zero and the remainder of a / 8 is zero (which means that a is evenly divisible by 8 ), then c equals 0

Woah-woah-woah... The Genesis has a Homebrew community that programs in BASIC? And the NES homebrew community still goes on just assembly? Sega does what Nintendorequiresyoutoknowassembly.

Sonic the Hedgehog, Had a blue-spiked cactus-head. He was three-foot-three, and he said to me, "I like golden rings!"

I know I've expressed my utter frustration with the way that bB and vbB are split off into obscure little fixes and files here and there across multiple buried threads.