wallaby Posted September 5, 2016 Share Posted September 5, 2016 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted September 5, 2016 Share Posted September 5, 2016 Speaking of temporary variables, have you looked at this: randomterrain.com/atari-2600-memories-batari-basic-commands.html#temp_variables And about the DPC+ stack, are you using push and pull: randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_stack Quote Link to comment Share on other sites More sharing options...
wallaby Posted September 5, 2016 Author Share Posted September 5, 2016 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted September 5, 2016 Share Posted September 5, 2016 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. You were using temp1 and temp2 in your post and they are the first temporary variables to be used by bB for other things, so you can't trust them to hold a value for very long. Less trustworthy than temp5 and temp6. For any new bB users reading this, temporary variables are obliterated when drawscreen is called, so they can only be used for quick, temporary jobs. As it says on the bB page, temp variables are generally safest to use in reverse order. That means temp6 is safer than temp5, and temp5 is safer than temp4, etc. Quote Link to comment Share on other sites More sharing options...
wallaby Posted September 5, 2016 Author Share Posted September 5, 2016 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. Quote Link to comment Share on other sites More sharing options...
wallaby Posted September 5, 2016 Author Share Posted September 5, 2016 (edited) 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" Edited September 5, 2016 by wallaby Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted September 5, 2016 Share Posted September 5, 2016 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" I haven't used the DPC+ stack, but it should look something like this if you want to save and retrieve the value in the variable a: stack 200 push a stack 199 pull a Quote Link to comment Share on other sites More sharing options...
wallaby Posted September 5, 2016 Author Share Posted September 5, 2016 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 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted September 5, 2016 Share Posted September 5, 2016 Oh, now I get it. Yeah, you have to use a number according to whoever typed up the stack info. And about bit operations, yeah, that also requires a number from what I've seen on the bB page. Quote Link to comment Share on other sites More sharing options...
bogax Posted September 5, 2016 Share Posted September 5, 2016 (edited) I don't know about the stack This compiles and (at least in this case) seems to produce the correct code def testbit = callmacro tb data bits %00000001, %00000010, %00000100, %00001000, %00010000, %00100000, %01000000, %10000000 end macro tb temp1 = bits[{2}] & {1} end testbit f v : if temp1 then b=0 v selects the bit in f not that you need to use def and a macro they might make it easier to revamp existing code (I just think it makes prettier code ) Edited September 5, 2016 by bogax Quote Link to comment Share on other sites More sharing options...
bogax Posted September 5, 2016 Share Posted September 5, 2016 (edited) as to the stack it looks like this might work def stackv = callmacro _stk macro _stk asm clc lda {1} adc #<STACKbegin sta DF7LOW lda #$00 adc #>STACKbegin and #$0F sta DF7HI end end stackv a edit: oops goofed it hopefully fixed now Edited September 5, 2016 by bogax Quote Link to comment Share on other sites More sharing options...
wallaby Posted September 5, 2016 Author Share Posted September 5, 2016 (edited) 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! Edited September 5, 2016 by wallaby Quote Link to comment Share on other sites More sharing options...
bogax Posted September 6, 2016 Share Posted September 6, 2016 just for completeness here I've included macros to set and clear bits def testbit = callmacro tb def setbit = callmacro sb def clearbit = callmacro cb macro tb temp1 = bits[{2}] & {1} end macro cb {1} = (bits[{2}] ^ $FF) & {1} end macro sb {1} = bits[{2}] | {1} end Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted September 6, 2016 Share Posted September 6, 2016 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! Since you have it working, if you get a chance, can you make a small example program using that so I can adapt it for the bB page? You could use the template on the bB page to save some time: randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_harmony Quote Link to comment Share on other sites More sharing options...
wallaby Posted September 7, 2016 Author Share Posted September 7, 2016 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. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted September 7, 2016 Share Posted September 7, 2016 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. Maybe a DPC+ master will have something to say about it. Quote Link to comment Share on other sites More sharing options...
Papa Posted September 16, 2016 Share Posted September 16, 2016 And the answer is... I like my BASIC like I like my women! FLAT!! (not STACKED..get it?) HA, HAAAAA.. Don't use stacks unless you really, really mean it. Quote Link to comment Share on other sites More sharing options...
freshbrood Posted April 19, 2020 Share Posted April 19, 2020 Would someone please explain to me in laymen's terms, as a noob, what "stack" means? I am just now starting to play with the DPC+. So confused. Sometimes I think you programmer guys don't realize your level 1 is a noob's level 3 when you explain things. I have no idea how to use stacks, data tables, or make a playfield scroll continuously scroll in either direction while drawing new blocks. Quote Link to comment Share on other sites More sharing options...
KevKelley Posted April 19, 2020 Share Posted April 19, 2020 My noob understanding is that the stack is a part of the the memory where you can store a variable's value and then retrieve it later on. 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted April 19, 2020 Share Posted April 19, 2020 43 minutes ago, KevKelley said: My noob understanding is that the stack is a part of the the memory where you can store a variable's value and then retrieve it later on. My noob understanding of using variables is you say that a=5, and a equal's 5. I don't even know what it means to "store" and retrieve" later on. If I use DPC+ can I not simply use variable like I do in the standard kernel? I feel like I'm just starting to have a novice/intermediate understanding of the standard kernel and DPC+ is almost like learning a new version of batari. Quote Link to comment Share on other sites More sharing options...
KevKelley Posted April 19, 2020 Share Posted April 19, 2020 I thought if you have a=5. Then you push it to part of the stack. When you want that back you pull it I believe you can use that variable anyway you want in between. I have yet to use it so I this is probably a really simplified take. Quote Link to comment Share on other sites More sharing options...
freshbrood Posted April 19, 2020 Share Posted April 19, 2020 (edited) I'm sorry, thank you for trying but I am still so lost! If I need an ammo count or life, I literally just write "a=100" for 100 bullets or "b=100" for 100 health. I have no idea if its in front or back, pushed or pulled lol. I only understand that a through z can each have up to a 255 number assigned to it, or be broken down into 8 "on of off" bits in the form of [0] through [7]. That's how I've used them so far and they seem to work for me. This front/back/push/pull/stack stuff is totally Greek to me. And in the standard kernel it doesn't seem to matter when or where you create the variables, they are globally read regardless of which bank the program currently reads from. Edited April 19, 2020 by freshbrood Quote Link to comment Share on other sites More sharing options...
+Karl G Posted April 19, 2020 Share Posted April 19, 2020 The DPC+ kernel is definitely more complex than the standard kernel, and has its own learning curve. Using variables in the DPC+ kernel is the same as the standard kernel. You still have a-z, and have a few extra ones with var0 - var8 as well. I don't know of many people who have said they used the stack feature, and it can easily be ignored if you don't have a specific use for it. So, why does it exist? The standard kernel just makes use of the Atari's 6507 CPU. The DPC+ kernel also makes use of an ARM CPU to assist with rendering graphics, etc. Your program is still running on the Atari's CPU, and has the same limited memory, but the stack is a way to send variable values from your program to the ARM CPU which has it's own memory, and retrieve it from there again when you need it. You can't assign directly to and from this extra memory since it resides on a separate CPU. 2 Quote Link to comment Share on other sites More sharing options...
KevKelley Posted April 19, 2020 Share Posted April 19, 2020 In the DPC+ games I was working on, the only thing I was thinking I could use the stack for is if I wanted to save a value and check the difference later on. I thought it was neat reading about it but since I had no immediate use for it I haven't really experimented with it yet. My recommendation is to make a short little program testing it out. See the basics of how it works. That is what I have been doing since I started. I have found practice helps 1 Quote Link to comment Share on other sites More sharing options...
bogax Posted April 19, 2020 Share Posted April 19, 2020 (edited) This is all pretty basic Go read some stuff Memory is like a bunch of little boxes or slots with coins in them The coins can be heads or tails If it's heads it's a 1 if it's tails it's a 0 The boxes are numbered (the number is its address) and you refer to a particular box by its number Being restricted to values of 0, 1 isn't very convenient so the boxes hold groups of coins (call them bits) In the 2600 processor the groups are 8 bits each bit has two possible values 0,1 so the total possibilities for the group are 2**8 or 256 or 0..255 (that's where the 0..255 for a variable comes from) Go read about binary numbers The groups are ordered and individual bits are refered to by a number. You could call it the bit address The bits correspond between groups, bit 0 in this group corresponds to bit 0 in that group, b1 to b1, b2 to b2 etc Each bit can have (will usually have) a particular meaning/signifigance depending on its "position" (number, bit address, whatever) We generally refer to the group of eight bits as a byte. If I say a = b the processor looks at bit 0 in b and sets bit 0 in a to be the same. If it's coins, if coin 0 in b is tails then coin 0 in a gets set to tails if b0 is heads a0 gets set to heads Likewise for the other bits in the group/byte So in effect b is copied to a Actually, the processor has a special box in it, the accumulator, that it uses for temporary stuff and what actually happens is b gets copied to the accumulator and then the accumulator is copied to a a and b are just names for the box numbers (the addresses) It happens that a, b, c have a sequence, an order (alphabetical) and the addresses have an order (numerical order) bB is set up so they correspond if you index a variable a = a[3] it takes a as corresponding to index 0 and adds 3 (a is an address, a name for a location where a number is stored) so a[0] is a and a[3] and d are two different ways of refering to the same location I could impliment a stack in bB as dim stack_pointer = s ; makes stack_pointer another name for location s dim stack = a s = 0 push_z stack_pointer = stack_pointer + 1 : stack[stack_pointer] = z pull_z z = stack[stack_pointer] : stack_pointer = stack_pointer - 1 of course you don't want a dedicated routine for each variable, you'd have a macro or a function that took z as a parameter so it might be push z pull z The stack is a way of squeezing access to a bunch of locations into a single location Go read about stacks I'm not very familiar with DPC+ but I think it's something like this the ARM processor has it's own memory and the 2600 doesn't have much And the 2600 doesn't have much of it's address space exposed and not much to share The stack is a way of using the same address for a bunch of different locations so the 2600 can use some of the ARM memory without using much of the 2600's space The ARM does something similar to the above code with its memory and the 2600 just sees/uses a single location, the stack (which is virtual, it's really the ARM running the routines, although there maybe an actuall location associated with the stack, like I said I'm not that familiar with it) Edited April 19, 2020 by bogax typos 1 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.