how many paramters?

[how many paramters?]

How many parameters can be passed to a Macro?

[Drawing playfields from data statements]

WritePFChunk
for current_row = 0 to 7
lo_pointer = current_row * 4
print_row = chunk_start + current_row
for current_col = 0 to 31
current_bit = current_col & 7
current_byte = current_col / 8 + lo_pointer

on maze_ref goto MazeData1 MazeData2 MazeData3 MazeData4
MazeData1
current_byte = Mazes1[current_byte] : goto Continue_WritePFChunk
MazeData2
current_byte = Mazes2[current_byte] : goto Continue_WritePFChunk
MazeData3
current_byte = Mazes3[current_byte] : goto Continue_WritePFChunk
MazeData4
current_byte = Mazes4[current_byte]

Continue_WritePFChunk

if current_byte & setbits[current_bit] then pfpixel current_col print_row on
next
next

 

Edit: removed the final goto (it's redundant)

[Drawing playfields from data statements]

I see no reason to even be limited to a single data statement to draw a semi-random "maze-style" playfield. You could always look up data segments in multiple arrays for your maze pieces, in whatever way you see fit. All this routine does is draw whatever binary image is fed into it.

 

How could you select amongst data statements with a parameter?

Only thing I can think of is a case statement. (or IF statements)

[Drawing playfields from data statements]

@bogax

 

Okay, I see the problem. The elements in your setbits array were just in reverse order. Changed it to this and it works fine now:

 

 data setbits
%10000000, %01000000, %00100000, %00010000,
%00001000, %00000100, %00000010, %00000001
end

 

Heck! Darn! Other obscenities as required!

 

And since the binary array thread is talking about

screen stuff and not bit variables they're backwards

there too.

 

Ha! Based on that other thread, I'm fairly sure you know what you're doing.

 

How sure are you now

.

[Drawing playfields from data statements]

Another thought.

 

Looks like you could pull the print_row

assignment out of the inner loop

 

for current_row = 0 to 7
lo_pointer = current_row * 4
print_row = chunk_start + current_row
for current_col = 0 to 31
current_byte = current_col / 8 + lo_pointer
current_bit = current_col & 7
if hellodata[current_byte] & setbits[current_bit] then pfpixel current_col print_row on
next
next

[Drawing playfields from data statements]

Okay, I think I see what you mean. If so, then yes you are right that it is the wrong number of iterations. I changed it to "for current_row 1 to 8." Thanks!

 

That might do it but then you need to intialize

lo_pointer

 

Your rows are going to be addressed as 0-7

 

Is there any chance you can help with converting this to a binary bitmap routine?

 

I can try but you probably want someone who knows what they're doing ;P

 

I'd imagine it something like this:

 

dim current_row = a
dim current_col = b
dim current_byte = c
dim current_bit = d
dim print_row = e
dim chunk_start = f

chunk_start = 20


PROGRAMLOOP
DF0FRACINC=128
DF1FRACINC=128
DF2FRACINC=128
DF3FRACINC=128
DF4FRACINC=255
DF6FRACINC=24
if joy0fire then z{0} = 1
if !joy0fire && z{0} then gosub WritePFChunk
drawscreen
goto PROGRAMLOOP


WritePFChunk
for current_row = 0 to 7
for current_col = 0 to 31
current_byte = current_col / 8 + lo_pointer[current_row]
current_bit = current_col & 7
print_row = chunk_start + current_row
if hellodata[current_byte] & setbits[current_bit] then pfpixel current_col print_row on
next
next

z{0} = 0

return thisbank


bank 3

bank 4

bank 5

bank 6

data lo_pointer
0, 4, 8, 12, 16, 20, 24, 28
end

data hellodata
%00000010,%01011101,%00010001,%11000000
%00000010,%01011101,%00010001,%01000000
%00000010,%01010001,%00010001,%01000000
%00000011,%11011101,%00010001,%01000000
%00000011,%11011101,%00010001,%01000000
%00000010,%01010001,%00010001,%01000000
%00000010,%01011101,%00010001,%01000000
%00000010,%01011101,%11011101,%11000000
end

data setbits
%10000000, %01000000, %00100000, %00010000,
%00001000, %00000100, %00000010, %00000001
end

 

I used a look up table for lo_pointer because it

only costs a couple bytes, doesn't use a variable

and is faster

 

edit: ack! wrong! it's significantly slower

(forgot that moves it into the inner loop)

 

so using a variable:

dim current_row = a
dim current_col = b
dim current_byte = c
dim current_bit = d
dim lo_pointer = e
dim print_row = f
dim chunk_start = g

chunk_start = 20


PROGRAMLOOP
DF0FRACINC=128
DF1FRACINC=128
DF2FRACINC=128
DF3FRACINC=128
DF4FRACINC=255
DF6FRACINC=24
if joy0fire then z{0} = 1
if !joy0fire && z{0} then gosub WritePFChunk
drawscreen
goto PROGRAMLOOP


WritePFChunk
for current_row = 0 to 7
lo_pointer = current_row * 4
for current_col = 0 to 31
current_byte = current_col / 8 + lo_pointer
current_bit = current_col & 7
print_row = chunk_start + current_row
if hellodata[current_byte] & setbits[current_bit] then pfpixel current_col print_row on
next
next

z{0} = 0

return thisbank


bank 3

bank 4

bank 5

bank 6


data hellodata
%00000010,%01011101,%00010001,%11000000
%00000010,%01011101,%00010001,%01000000
%00000010,%01010001,%00010001,%01000000
%00000011,%11011101,%00010001,%01000000
%00000011,%11011101,%00010001,%01000000
%00000010,%01010001,%00010001,%01000000
%00000010,%01011101,%00010001,%01000000
%00000010,%01011101,%11011101,%11000000
end

data setbits
%10000000, %01000000, %00100000, %00010000,
%00001000, %00000100, %00000010, %00000001
end

 

damn! more edits:

should be

current_byte = current_col / 8 + lo_pointer

 

even more editing: fixed the setbits (see below)

[Drawing playfields from data statements]

I phrased that poorly

 

Suppose you set lo_pointer = 15 (some arbitrary value)

then call WritePFChunk

 

then the first time you run the current_col

loop current_row = 0 and lo_pointer = 15

at the end of the first pass through the

current_row loop lo_pointer will get set to 0

ie 0 * 32 so your passes would go like this

 

current row = 0, lo_pointer = 15

current row = 1, lo_pointer = 0

current row = 2, lo_pointer = 32

current row = 3, lo_pointer = 64

current row = 4, lo_pointer = 96

current row = 5, lo_pointer = 128

current row = 6, lo_pointer = 160

current row = 7, lo_pointer = 192

current row = 8, lo_pointer = 224

 

9 iterations of the current row loop

the first one with what ever lo_pointer is

when you call WritePFChunk

[Drawing playfields from data statements]

possibly I misunderstand your intent.

 

On your first pass through the inner for loop

current_col will be 0 and lo_pointer will be whatever

you haven't set lo_pointer yet

At the end of the first pass through the loop

you'll set lo_pointer to current_col * 0

and lo_pointer will be 0 while current_col is 1

(second pass). etc

also you'll make 9 passes through the loop

(0-8 inclusive)

 

If you multiply by a power of two that's 8 or less

Bb will use shifts so * 8 * 4 compiles as shifts

* 32 calls the mutiplication routine

[joystick input in asm]

what i was hopeing to do was check for conditions of the other values by just repeating the code with the difrent value, it works fine on its own but when i try and stack the code it does not work anymore.

 

I could get the program to read diffrent values, but only when that was the only check in the code. Like if i wanted to do cpx #13.... cpx #14 it would not work.

 

I will look into the PORTA thanks!

Not sure I understand your intentions.

 

If what you mean is you want to do something

if the joy stick reads (for example) 14, 13 or 10

ie the same thing for a variety of values

you could do something like this

org $6000 ;Start of the code

start lda #100 ;loads to address
sta 1537 ;puts the value 1537 into address
loop ldx 632 ;Read joystick STICK0
cpx #14 ;is it n? 14, s is 13, w is 11, nw is 10,sw is 9,e is 7,ne is 6,se is 5
beq dosomething
cpx #13
beq dosomething
cpx #10
bne loop ;if not - go and read it again
dosomething lda 1537 ; reads 1537 - this memory is not used by the OS
sta 710 ;color screen with it COLOR2 (color reg 2, playfield 2)
cmp #0 ;compare value. is it zero?
beq loop ;if it is, loop
dec 1537 ;if not, decreases 1537
lda #$f ;resets joystick
sta 632 ;read joystick STICK0
jmp loop ;starts over again

run start ;begin program execute

Of course you could have it do different things

for different read values

 

Looks to me like that's going to zip through

the colors as long as you're reading one of your

chosen values. (but maybe I just don't understand

enough about how reading the joystick works)

Looks like a pass through the loop only takes

40 or 50 machine cycles at most.

 

You intialize 1537 to 100, but you don't reset it

to 100 when it gets to 0 so presumably it goes from

0 to 255

Is that supposed to be jmp start instead of jmp loop?

 

in the sequence:

lda 1537
sta 710
cmp #0
beq loop

the cmp#0 is redundant

Any instruction that could change a register sets the

N and Z flags (also the read-modify-write instructions

like inc, dec, lsr, ror, asl, rol, a memory location)

lda 1537 does cmp #0 implicitly and sta 710 doesn't change

the Z flag.

 

What the others said.

Presummably, the shadow register contains a debounced

value.

[Accessing DATA as binary array?]

.

.

edit some more:

I suppose you all know this already.

 

It's better to avoid the stack altogether

cell = mapx / 8
cell = mapy * 4 + mapy + cell

saves 2 bytes and 7 cycles

 

This part doesn't compile, claiming there are duplicate labels. So, do I need to dimension a new "cell"? I tried changing it to cellx, but that causes more problems.

 

I can't explain that.

 

All I can say is it worked for me.

 

This was the result:

.L08 ; cell = mapx / 8

LDA mapx
lsr
lsr
lsr
STA cell
.L09 ; cell = mapy * 4 + mapy + cell

; complex statement detected
LDA mapy
asl
asl
CLC
ADC mapy
CLC
ADC cell
STA cell
.
; 

[Random placement]

A little late replying here... (heh heh)

(came across this while Googling something)

 

Just for completeness, here's what I was talking about

 

in Bb

 

temp1=rand/2
temp1=(temp1/4/4+temp1)/4+temp1

 

which produces

 

.L00 ; temp1 = rand / 2

jsr randomize
lsr
STA temp1
.L01 ; temp1 = ( temp1 / 4 / 4 + temp1 ) / 4 + temp1

; complex statement detected
LDA temp1
lsr
lsr
lsr
lsr
CLC
ADC temp1
lsr
lsr
CLC
ADC temp1
STA temp1

 

in asm

 

jsr randomize
sta temp1
lsr
lsr
lsr
lsr
lsr
adc temp1
lsr
lsr
adc temp1
lsr
sta temp1

 

Well, not quite what I was talking about.

 

The Bb version mutiplies by .6328125

(1/2 + 1/8 + 1/128) and truncates the

partial products

 

The asm version multipies by .62890625

(1/2 + 1/8 + 1/256) and rounds the

partial products

 

 

 

In an ideal world, yes.

 

In a 6507 world, a multiplication (or a division) by a non-power-of-2 is horrendously costly in terms of time, and generally is avoided at all costs. Instead, 6507 coders use approximations, lookup tables, etc.

 

Hence all the gymnastics in this thread trying to find the ideal way to do it. (Though mostly the gymnastics are for fun. Any one of the posted methods would be good enough in most cases)

[Accessing DATA as binary array?]

Things will be easiest if you can keep one dimension

in powers of 2

 

Then you can use simple shifts and bitwise logical ops

for composing the cell and bit addresses, there by

avoiding expensive multiplys/divides

Bb will use shifts for multiplying and dividing by

low powers of two, much faster than full blown

mutiplications and divisions (I think a low power

of 2 means 8, 4, or 2)

 

 

Near as I can tell, Bb wants a constant for bit ops

so to use a variable you'll have to do it yourself

 

If you have 256 bytes that's 2048 bits

 

So say you have 128 (x coordinate) x 16 (y coordinate)

x will be 16 (bytes) * 8 (bits)

You can get the bit address (ie the bit you want in

the selected cell) by simply masking for the

lower 3 bits of x

dim mapx = a
dim mapy = b
dim cell = c
dim cellx = d

rem x mod 8
cellx = mapx & 7

rem ORing instead of addition saves a clc so it's slightly
rem faster and is possible since mapx / 8 is an integral
rem power of 2 bytes per row (ie per y)
rem mapy * 16 is done as mapy * 4 * 4 so that Bb will use
rem shifts rather than invoking a mutilplication subroutine
cell = mapy * 4 * 4 | mapx / 8

if map[cell] & setbits[cellx] then score = 1 else score = 0


rem use an adressable set of masks so you can point
rem to them with a variable
data setbits
%10000000, %01000000, %00100000, %00010000
%00001000, %00000100, %00000010, %00000001
end

data clearbits
%01111111, %10111111, %11011111, %11101111
%11110111, %11111011, %11111101, %11111110
end


data map
%11111101, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111
%10000001, %00000011, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001
%10000000, %00000000, %00000111, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001
%10000000, %00000000, %00000000, %00011000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001
%10000000, %00000000, %00000000, %00000001, %00000010, %00000011, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001
%10000000, %00000000, %00000000, %00000000, %00000000, %00011100, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001
%10000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001
%10000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001
%10000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001
%10000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001
%10000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001
%10000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001
%10000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001
%10000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001
%10000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001
%11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111
end

 

If you want your map to be something closer to square, say, 40 x 51

You could use a look up table for the mutiplication or hard code it

ie write a dedicated mutiply routine (or just use the built in

multiplication routine which would be slower).

I think I'd go with a look up table (if there's room), it'd only cost

an extra 40 bytes or so and be a lot faster.

 

Here's hard coded for 40 ie rows of 5 bytes of 8 bits

Each row is 5 bytes so you need to mutiply y by 5

(still uses the same map data, but I'm sure it doesn't make

sense here)

 

dim mapx = a
dim mapy = b
dim cell = c
dim cellx = d

rem x mod 8
cellx = mapx & 7

rem have to use addition this time
rem 5 = 1 + 4
cell = mapy + mapy * 4 + mapx / 8

if map[cell] & setbits[cellx] then score = 1 else score = 0


rem use an adressable set of masks so you can point
rem to them with a variable
data setbits
%10000000, %01000000, %00100000, %00010000
%00001000, %00000100, %00000010, %00000001
end

data clearbits
%01111111, %10111111, %11011111, %11101111
%11110111, %11111011, %11111101, %11111110
end


data map
%11111101, %11111111, %11111111, %11111111, %11111111
%11111111, %11111111, %11111111, %11111111, %11111111
%11111111, %11111111, %11111111, %11111111, %11111111
%11111111, %10000001, %00000011, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000001, %10000000, %00000000, %00000111
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000001, %10000000, %00000000
%00000000, %00011000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000001, %10000000
%00000000, %00000000, %00000001, %00000010, %00000011
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000001
%10000000, %00000000, %00000000, %00000000, %00000000
%00011100, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000001, %10000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000001, %10000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000001, %10000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000001, %10000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000001
%10000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000001, %10000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000001, %10000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000001, %10000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000001, %10000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000000
%00000000, %00000000, %00000000, %00000000, %00000001
%11111111, %11111111, %11111111, %11111111, %11111111
%11111111, %11111111, %11111111, %11111111, %11111111
%11111111, %11111111, %11111111, %11111111, %11111111
end

 

edit: actually

cell = mapy * 4 + mapy + mapx / 8

is faster because Bb doesn't stash mapy

on the stack while it computes mapy * 4

 

edit some more:

I suppose you all know this already.

 

It's better to avoid the stack altogether

cell = mapx / 8
cell = mapy * 4 + mapy + cell

saves 2 bytes and 7 cycles

 

yet more edit: fixed setbits and clearbits

which were good for bit variables but not screen

stuff

[on ... gosub issue]

I think my own routine can still be more optimized.

You could probably get by with fewer partial products in the reciprocal

multiplication.

[on ... gosub issue]

When you have rand/2 like so:

 

a=rand/2

a=(a/2 + a)/4/4/2+1

 

you get:

 

 

6 => 0

5 => 0

4 => 0

3 => 86

2 => 84

1 => 85

 

That's odd

Are you sure you didn't divide by 64?

ie /4/4/4 instead of /4/4/2 ?

 

I reckon it thusly

 

suppose rand returns 255

 

then:

 

rand/2 = 127
a/2 = 63
+ a = 190
/4 = 47
/4 = 11
/2 = 5
+1 = 6

[on ... gosub issue]

a=rand/2
a=(a/2 + a)/4/4/2+1

 

produces

 

.L00 ;  a = rand / 2
jsr randomize
lsr
STA a
.L01 ;  a =  ( a / 2  +  a )  / 4 / 4 / 2 + 1
; complex statement detected
LDA a
lsr
CLC
ADC a
lsr
lsr
lsr
lsr
lsr
CLC
ADC #1
STA a
.
;

 

 

or in assembly

 

a=rand

asm
lda a
lsr
adc a
and #$C0
rol
rol
rol
adc #$01
sta a
end

[Passing Parameters in subroutine]

What I did different is that the subroutine/function's part that copies parameter values from main code into the library's parameter working area was a subroutine itself, so every library function started with a JSR to get the parameters.

 

Compared to explicitly loading values and pushing them on the stack and pulling them off, this method results in less memory/less redundant code (especially when there are a lot of routines doing this.) But this method means everything in the library has the overhead of copying the parameters and recalculating the correct address for the RTS.

 

Having thought about it only slightly, maybe the code

could be simpler and perhaps shorter if the target

of the JSR is one of the parameters.

 

And if you resolve to never let the JSR and paramters

straddle a page boundary you could simplify things

by not having to calculate the return address

 

It would cost another couple of zero page bytes for

the subroutine target.

 

; parameter_pointer is a zero page location
; initialized to zero
pla
tay
pla					
sta parameter_pointer+1
; high byte of the return address doesn't
; change so just put it back
pha
iny
lda parameter_pointer,y
sta target
iny
lda parameter_pointer,y
sta target+1
iny
lda parameter_pointer,y
sta parameter1
iny
lda parameter_pointer,y
sta parameter2
; etc

; assuming no page crossings so just
; push the low byte of the return address
; back on the stack
tya
pha					
jmp (target)

[Can it be done, byte transform using only logic and maths]

Won't the XOR pass give you $FF in the destination for source=0? So you'd basically get $FF for the entire range, including the 0? I have a headache mind you, so I'm probably wrong.

 

oops yes I think you are correct.

I thought it was writing a 0 if the source is 0.

On a closer reading it looks like it doesn't write at all if the source is 0

 

But it looks like it can be done in one pass.

By making the source the destination and using a collision detection mask of FF

and an XOR and AND mask of FF and either arithmetic sum mode

or OR mode

 

the description of OR mode, mode 3:

 

"The written out data dest’ is a result of a bitwise OR of source” and dest.

 

source = ReadSource();

source' = source & blt_and_mask;

source'' = source' ^ blt_xor_mask;

if (source'' != 0)

dest = ReadDest();

if (dest & blt_collision_mask) BLT_COLLISION_CODE = dest;

dest' = dest | source'';

WriteDest(dest');"

 

 

So eg in OR mode if the source is 0 it will stay 0

If the source is not 0 then it will get ANDed with the AND mask ie FF (source')

That will be XORed with the XOR mask ie FF producing the compliment (source")

And that will be ORed with the source producing FF (dest')

Then written to the destination ie written back if the destination is the same

as the source.

[Can it be done, byte transform using only logic and maths]

Not sure I understand the problem (or the blitter) so maybe this

will be whacked.

 

The problem is to write 0 if the source byte is 0 and write FF if the

source byte is non 0.

The source just happens to be restricted to powers of 2. (including

0)

 

So do an XOR pass with FF filled destination. to get either 0

or the compliment of the source.

Then do an OR pass between the source and the (now compliment

destination) to get either 0 or the source OR the compliment (ie FF)

 

Am I missing something?

[comparing switches]

Similar thread

 

http://www.atariage....-are-different/

[How do we check if two bits are different?]

if a/2 ^ a & 1 then goto __pause_game

__pause_game

 

.L00 ; if a / 2 ^ a & 1 then goto __pause_game

; complex condition detected
; complex statement detected
LDA a
lsr
EOR a
AND #1
 BEQ .skipL00
.condpart0
jmp .__pause_game

.skipL00
.
;

.__pause_game
; __pause_game

[How do we check if two bits are different?]

Not sure I remember the conventions rightly, but assuming bit 0 is the

least significant bit ...

 

If you add a 1 to a bit you can, in effect, propagate it to a more significant

position via carry

 

If you add two bits together the sum is the XORing of the two

 

You can do both at once in this case by adding 1 to a

 

Then use & to isolate bit 1 to test it (ie a bitwise AND with 2)

 

if (a + 1)& 2 then goto __pause_game

__pause_game

 

produces

 

.L00 ; if ( a + 1 ) & 2 then goto __pause_game

; complex statement detected
LDA a
CLC
ADC #1
AND #2
BEQ .skipL00
.condpart0
jmp .__pause_game

.skipL00
.
;

.__pause_game
; __pause_game

 

That ought to be something like what you want

[Which is faster?]

Even after seeing where you guys were hiding the rabbit, it still looks like magic. Very weird, but cool. Thanks.

 

Not sure how to answer that.

 

My gut reaction is to say there's no magic to it.

 

But it is sort of magical or wonderous or at least fascintaing,

maybe that's the key to interest.

 

What it is is pretty mundane 7th grade algebra.

 

you wouldn't have any trouble learning it.

 

Boolean algebra has similar rules/properties

[Which is faster?]

I don't know what you mean. For example, if it was temp6 = ((player0y-3)/4)-1 instead, you couldn't do what jwierer did. He lucked out because the number I was subtracting turned out to be 4, but at one time, the number was something else.

 

temp6 = (player0y-7)/4

[Is there any way to use a bit as 255 or 1?]

I'm trying to figure out how to do the following with fewer steps:

 

  temp5 = 255 : if B_Direction_x{5} then temp5 = 1

  ballx = ballx + temp5

 

This works (ie bB doesn't choke on it and it assembles)

 

dim ballx_dir = a
dim ballx_pos = b

macro incv
asm
inc {1}
end
end

macro decv
asm
dec {1}
end
end

if ballx_dir & 32 then callmacro incv ballx_pos else callmacro decv ballx_pos

 

used my own names, sorry if that's confusing

[Session 24: Some nice code]

I'm putting adapted versions of these sessions on my web site. Does the information in the first post need to be updated with anything that has been posted in this thread? I know almost nothing about assembly language, so I can't tell.

 

 

Thanks.

 

There's a typo

 

       ldx #0 

       txa 

Clear   dex 

       txs 

       pha 

       bne Clear

 

...

 

since the tsx and pha don't affect the flags,

 

I believe that should be

 

'since the txs and pha don't affect the flags,'