wallaby

I'm using the stack as extra variables but it depends on how you use it. I use the stack command to position the location manually and store information there sort of like RAM. This range is for this thing, this range is for this thing, and so on. Where it gets tricky is manipulating the stack. The key is you need to first pull the data out in a variable. So while you can store more information, you can't use it all at once. I go to the stack location and pull the data out using temp variables. Manipulate it as I need, then push it back. This is more cycle intensive than just changing a normal variable. Thinking about it now though, maybe you can just manipulate the stack memory locations directly. I mean, we have the "stack" command, but maybe you don't have to use it that way and can use it like any other memory location. Hmm. Maybe the whole stack interface is unnecessary?

Hey, I think this is neat, but I hate the music. It sounds like a PC speaker and it has this weird very quiet "thup" right before notes are played. Plus, it loops constantly. Maybe the music should only play sparsely? Maybe when you discover something particularly interesting?

I just migrated from Visual bB to Sublime Text and this highlighting is great. Thanks for making it.

Thanks! Works great now.

bblint doesn't like ASM in macros macro test asm <asm code> end end Gets an error: missing matching end to " test " The code compiles fine though.

Oh, I got it! Okay, first you define your sprite with data. data mysprite %01010101, %10101010, %10101010 end Then you can reference the data label using the same assembly that is normally used. lda #<(playerpointers+4) sta DF0LOW lda #(>(playerpointers+4)) & $0F sta DF0HI LDX #<mysprite STX DF0WRITE LDA #((>mysprite) & $0f) | (((>mysprite) / 2) & $70) STA DF0WRITE LDA #3 STA player3height I think this allows you to use other banks for graphics data too. You wouldn't be limited by 4k using DPC+. You could also save the sprites like normal, look in the ASM for the labels bB gave them, and use them interchangeably without having to redefine them. These would use the graphics bank. I think that adds a lot of flexibility!

Here is the code for setting the sprite data for player3. What I'm confused about is that it doesn't seem to matter what data I set, the assembly is always the same. I think the first 4 lines are for setting the correct address to the sprite data. But then LDX loads something which is written to the sprite data. Then LDX loads another something that is written. Then it writes how many lines the sprite uses. So it must be loading two addresses (the start and end?) of the sprite data. The start and end never seems to change, so it must load the maximum and then just set how many lines it actually uses? 7529 459f a9 e6 lda #<(playerpointers+4) 7530 45a1 8d 50 10 sta DF0LOW 7531 45a4 a9 01 lda #(>(playerpointers+4)) & $0F 7532 45a6 8d 68 10 sta DF0HI 7533 45a9 a2 ae LDX #<playerL0514_3 7534 45ab 8e 78 10 STX DF0WRITE 7535 45ae a9 67 LDA #((>playerL0514_3) & $0f) | (((>playerL0514_3) / 2) & $70) 7536 45b0 8d 78 10 STA DF0WRITE 7537 45b3 a9 0e LDA #14 7538 45b5 85 a8 STA player3height With that hypothesis, I made my own ASM. I put my own label and tried this, but it crashes. playerL9 .byte %11111111 .byte %01111100 .byte %01101000 .byte %01101000 .byte %00010100 .byte %00010100 .byte %01111110 .byte %01111110 .byte %01111110 .byte %01111110 .byte %01111110 .byte %01111110 .byte %01111110 .byte %01111110 lda #<(playerpointers+4) sta DF0LOW lda #(>(playerpointers+4)) & $0F sta DF0HI LDX #<playerL9 STX DF0WRITE LDA #((>playerL9) & $0f) | (((>playerL9) / 2) & $70) STA DF0WRITE LDA #14 STA player3height

I'm currently having a problem where I have a single sprite, but I want to use it on two players. I have to duplicate my sprite data for both players and use up more space in my graphics bank. I can do: player3: {sprite data} end But if I want to use that exact same sprite, I have to duplicate it in ROM. player4: {exact same sprite data} end Instead of re-using the existing sprite data, I have to define it twice. It becomes a problem when I want to have many different possible sprites for many players. Instead of having to duplicate the sprite 9 times in ROM, I'd rather have one sprite data, and re-use it for each player. I tried using data to define the sprite, but there is no syntax for assigning data to a player. If there was, you could define data for your sprites and colors and swap them between players. Data is ROM, so in theory, you shouldn't need any trickery to get it to work. Maybe I can do this with an ASM macro? If it's not possible to re-use existing data, I'll have to make it so only certain players can be certain sprites so there is no duplication in my graphics bank.

That's perfect, thanks!

Looks like they're called the same in bB. I tried it before and got an error, but I just made a few asm macros and it turns out they're directly accessible in bB using those names. That was excellent, thanks. I also found those comments in the .txt file that bB generates which was a big help too.

I'm trying to use the score display to show values of bytes, but I'm having trouble. Something like this: dec a = 0 + b score = b Fails with an error. dec a = 0 + b score = 0 score = score + a This compiles, but the value is incorrect. What I'm trying to do is display the value of 'b': 0-255 I think the score has special processing for it handle multiple digits though, so instead of all that messing around, is there an easier way to easily see the value of 'b'? Maybe in the Stella debugger?

Yes, I'll make a small one. Does the stack consume processor cycles? I wonder how practical it is to use for active variables. Moving the stack location, and push and pulling often, for example.

A 32 bit random number generator is perfect, but how do you access the registers like RWRITE from bB? Or is it more practical to use assembly and make a macro or something? Finally, a bit off topic - I'd love to use C to program the Atari but one thing that makes bB so attractive is the multitude of examples and help the community provides. Also, Random Terrain's website with just about everything you need all on one page. Are there any resources for C that can kick start Atari development? What are the pros and cons to using C and does programming directly on the arm chip grant you a huge computing resource?

OKay, I've read you can seed rand by setting it to a value. Like rand = 30. That will then give you a repeatable pattern of random numbers. This is a powerful feature of random number generators. But, there is an interesting problem with the Atari 2600. Can you only seed the rand function with a byte? So there can only be 256 sequences? Most of the time, a seed with be the number of seconds since 1970 or whatever, so the seed is always different. But you have the option of setting the seed to potentially millions of possible sequences. Is there a way to set the DPC+ seed to a larger number?

I'll try it out! I want to use the stack to store as much information as I can, but not being able to change the stack location dynamically was making it impossible. If I can use the stack location variable as a pointer I can use them effectively like 256 more variables. EDIT: Looks like it's working! I'm going to put it through its paces right now. This greatly improves the utility of the stack in bB, thanks!

Right, what I'm talking about is setting the stack location with a variable. To use your example: stack my_variable push a stack my_variable - 1 pull a

EDIT: Actually, no. That doesn't work either. You can't assign a stack location with a variable. And you can't assign a bit location with a variable either. Sometimes it looks like it works, but it doesn't. Maybe the bit order is different or something? I'm testing this in the middle of my main application, so it's a bit a of a bear to test it. I can make a simple test program to demonstrate if this is a bug and not the intended functionality. I don't know how bB works under the hood to understand what is happening between "stack 255" and "stack my_variable"

Yes, I don't think it's a temporary variable problem. I never use them for longer than a few lines and never persist them across a frame.

Yep, the stack works fine if you set it to a specific value like 255, or 0, or whatever. But if you set it to a variable, it compiles, but doesn't work. I'll double check that the next problem wasn't masking the stack working. If you check the bit at, for example, a{0} it will work. But if you set the second part to a variable a{b} it compiles but doesn't appear to work.

Is there any trick to setting the stack location to a variable? stack 255 <- works a = 255 stack a <- compiles but doesn't work Same problem with setting bits. if temp1{0} then goto __Somewhere <-- works temp2 = 0 if temp1{temp2} then goto __Somewhere <-- compiles but doesn't work The compiling but not working situation is throwing every time it happens. It seems logical, especially the stack where there are no byte size differences. If I have to do them implicitly, I have to write a ton more code, not to mention use more variables.

Why not use temp1 - temp4 for those variables since you don't need them to persist across frames? I haven't tried this, but could you bit-shift PF_DATA0, etc? It would be great to be able to manipulate the playfield without having to define it. For example, use a few frames "LOADING..." to create the playfield on the fly. Then you could procedurally generate it, or whatever, and save that precious graphics bank in DPC+

I'll give it a shot. Shouldn't flicker just using the playfield. I've always wanted to try making a game like that.

Or Escape from the Mind Bender (or is it Mender?) I think with the power of DPC+ it should be possible to get that cool little movement animation that Escape has but not the smooth lines due to not being able to change the missile and ball graphics. That said, the playfield can be a higher resolution, so maybe you don't even need them?

Ah, what a great resource! That is some serious code voodoo. I've got it working now but I don't really understand it. Not that I'm complaining! I use your website all time trying to learn my way around the Atari. Thanks for creating it!

Hello! I'm trying to make a projectile fire at a x / y location on the screen. Obviously, this is easy with a modern system and I'd normally use (pseudo code): ProjectileVector = OriginXY - TargetXY ProjectileVector.Normalize MissileSpeed = ProjectileVector * MaximumSpeed Normalizing the vector allows you to multiply it by your maximum missile speed and get set the proper X / Y velocity to strike the target. What I'm doing now is: target_distance_x = (player3x - target_x) / 4 target_distance_y = (player3y - target_y) / 4 I'm using / 4 to get the projectile to follow a path based on my playfield resolution. player3 is my missile sprite. (Using DPC+) This leaves me with, for example, target_distance_x = 5, target_distance_y = 3 Which is correct, but I can't just make those numbers my missile velocity because they're way too fast. I don't how if it's possible to normalize target x and y (would need fixed point numbers and division) and if it is, you'd still need to multiply those by another number to get the right velocity. If I divide the target_distance by 2 or 4 or whatever, the missile goes slower, but not to the right location. Rounding errors. How did Missile Command aim missiles?