Jump to content
wallaby

Arguments not working for stack or bit assignment

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by wallaby

Share this post


Link to post
Share on other sites

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


Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by bogax

Share this post


Link to post
Share on other sites

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 by bogax

Share this post


Link to post
Share on other sites

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 by wallaby

Share this post


Link to post
Share on other sites

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
 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. 
 

Share this post


Link to post
Share on other sites

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. 

  • Like 1

Share this post


Link to post
Share on other sites
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.
 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Posted (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 by freshbrood

Share this post


Link to post
Share on other sites

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. 

  • Like 2

Share this post


Link to post
Share on other sites

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 

  • Like 1

Share this post


Link to post
Share on other sites
Posted (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 by bogax
typos
  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...