Jump to content

Recommended Posts

Alpha 0.3 bug:

 

Bit operations inside an if...then statement do not appear to work:

[...]

917063[/snapback]

Fixed. I inadvertantly deleted a line of code while I was trying to clean up [...]

917295[/snapback]

 

I can't get *any* bit operations to work; they just won't compile. Hopefully this is all caused by the deleted line of code; I can't wait for 0.35! :-)

 

Also, I was getting compile errors, so I remarked out huge sections of my code to try to get at least part of it working, but sometimes the remarked-out code was being compiled anyway! It seems like the text after the "rem" keyword isn't being fully ignored?

 

I wonder if it might be a good idea to divide the updates into two alternating categories-- a release with bug fixes, then later a release with new features? I'm in the software business myself, so I know how it is-- one wants to fix bugs *and* add new features at the same time. But unless you've got a team of programmers (even if there are only two on the team), it can be difficult to fix bugs, add new features, and test the new features all at once. Personally, I'd rather wait a little longer for new features if it means that bug fixes can get released a little quicker.

 

Anyway, I said I would post my adventure game, so I'll go ahead and post what I did in version 0.2a, as soon as I restore the older code and recompile it.

 

Michael Rideout

Alpha 0.3 bug:

 

Bit operations inside an if...then statement do not appear to work:

[...]

917063[/snapback]

Fixed. I inadvertantly deleted a line of code while I was trying to clean up [...]

917295[/snapback]

 

I can't get *any* bit operations to work; they just won't compile. Hopefully this is all caused by the deleted line of code; I can't wait for 0.35! :-)

Yeah, there is also an issue with the preprocessor - I had it handle { and } wrong. Been fixed on this end, but that doesn't help you a whole lot.

Also, I was getting compile errors, so I remarked out huge sections of my code to try to get at least part of it working, but sometimes the remarked-out code was being compiled anyway! It seems like the text after the "rem" keyword isn't being fully ignored?

It should ignore the code, unless the rem isn't indented, in which case it will assume rem is a label and it will go ahead and compile the code anyway.

I wonder if it might be a good idea to divide the updates into two alternating categories-- a release with bug fixes, then later a release with new features? I'm in the software business myself, so I know how it is-- one wants to fix bugs *and* add new features at the same time. But unless you've got a team of programmers (even if there are only two on the team), it can be difficult to fix bugs, add new features, and test the new features all at once. Personally, I'd rather wait a little longer for new features if it means that bug fixes can get released a little quicker.

918203[/snapback]

Makes sense. I'll do a minor release or two with bugfixes before a major release with features. Will do 0.35 soon with most of these obvious issues fixed. I think I've also got the problems I'd been having with 4.4 math ironed out, and hope to better evaluate multiplication/division as I haven't tested this much at all. Especially 16-bit div/mul, which has seen very little testing.

 

I also think I need to slightly expand the use of fixed point numbers in if-thens, as right now the support for 4.4 types is pretty weak. e.g. 4.4's can only compare with other 4.4's - if compared with something else, 4.4's are multiplied by 16. I think you should be able to compare a 4.4 with an immediate real number.

Hey, I got it to work!  :-)  I just kept tinkering with the batch file, and finally made the following change:

 

preprocess<%1 | 2600basic.exe>bB.asm

 

I guess it was the lack of a space in front of the pipe that was the issue.

 

Now that I got it working, I'll do some more programming on my adventure game and post it.

Thanks! It wasn't working on my WindowsME box at home either, until I made the same change. :)

Hey, I got it to work!  :-)  I just kept tinkering with the batch file, and finally made the following change:

 

preprocess<%1 | 2600basic.exe>bB.asm

 

I guess it was the lack of a space in front of the pipe that was the issue.

 

Now that I got it working, I'll do some more programming on my adventure game and post it.

Thanks! It wasn't working on my WindowsME box at home either, until I made the same change. :)

918218[/snapback]

 

I'm glad I helped you! I actually figured it out by looking at the source, because I saw that the spacing for that line was different in the source files, so I tried making the change to see if it worked-- and it did! :-)

 

Michael Rideout

Batari,

are there going to be any bugfix releases? (or have there been already and I missed 'em?)

 

Also, maybe it would make sense to go to a "truer" Alpha/Beta mode...I mean, right now you're calling everything "Alpha", probably out of a sense of humbleness and future ambition, but the fact is people have gotten some neat stuff done with .2 and even .1....maybe it would make sense if .1 and .2 were consideres "beta", and then when you release something like .3 where you know there are probably a number of fairly easy to fix but nasty bugs, that can be alpha 'til those get resolved, then it becomes beta?

Batari,

are there going to be any bugfix releases? (or have there been already and I missed 'em?)

 

Also, maybe it would make sense to go to a "truer" Alpha/Beta mode...I mean, right now you're calling everything "Alpha", probably out of a sense of humbleness and future ambition, but the fact is people have gotten some neat stuff done with .2 and even .1....maybe it would make sense if .1 and .2 were consideres "beta", and then when you release something like .3 where you know there are probably a number of fairly easy to fix but nasty bugs, that can be alpha 'til those get resolved, then it becomes beta?

918400[/snapback]

Yes, I was waiting to see if any more nasty bugs popped up, but I none have been reported today, so I'll do a build late this evening and release 0.35.

 

I guess I'm calling it alpha because I think that these releases are not up to the quality I expect from a beta release - I expect beta releases to work properly almost all the time but maybe have a few small bugs. Maybe soon bB will be working well enough so I am comfortable calling it beta. When it has matured and is working well, I think I'll call it 1.0, then release "bleeding edge" beta versions with new features that might be buggy, before releasing non-betas. Either way, I think I'm a ways away from removing any alpha/beta designation.

  • 2 weeks later...

bB 0.35a bug - rem lines that compile.

 

rem  if mons_x < 55 || mons_x > 131 then get_monster_x
rem  if mons_y < 16 || mons_y > 80 then get_monster_y

 

I made a test.bas file with just those two lines in it. When I compile it, I get the following:

 

2600 Basic compilation complete.

DASM V2.20.10, Macro Assembler ©1988-2004

      bytes of ROM space left

      2947 bytes of ROM space left

      2947 bytes of ROM space left

--- Unresolved Symbol List

ROM2k                    0000 ????        (R )

NO_ILLEGAL_OPCODES      0000 ????        (R )

mons_x                  0000 ????        (R )

mons_y                  0000 ????        (R )

0.get_monster_x          0000 ????        (R )

0.get_monster_y          0000 ????        (R )

--- 6 Unresolved Symbols

 

Fatal assembly error: Source is not resolvable.

Press any key to continue . . .

 

When I look at the test.bas.asm file, I see the following:

 

game

.L00 ;  rem  if mons_x < 55 || mons_x > 131 then get_monster_x

 

LDA mons_x

CMP #131

bcs .get_monster_x

.L01 ;  rem  if mons_y < 16 || mons_y > 80 then get_monster_y

 

LDA mons_y

CMP #80

bcs .get_monster_y

      echo "    ",[(scoretable - *)]d , "bytes of ROM space left")

ifconst ROM2k

ORG $F7AC

else

ORG $FFAC

endif

 

So it isn't the entire rem lines that compile, just the parts after the || operator.

 

Michael Rideout

bB 0.35a bug - rem lines that compile.

 

...

 

So it isn't the entire rem lines that compile, just the parts after the || operator.

924134[/snapback]

Now that you point out the exact circumstances, I know exactly why this is happening. && should not cause problems but "else" probably will. I think it's an easy fix, fortunately, all I have to do check for "rem" before anything else.

bB 0.35a bug - pfvline bug.

 

After experimenting with pfvline, I have a better understanding of its bug. It isn't specific to using on, off, or flip; it happens with all three. It is related to which row the vertical line starts on, as follows:

 

Given "pfvline a b c on," bB should draw a vertical line in column a, beginning on row b and ending on row c, but it actually ends on row b+c. And if b+c exceeds 11, it can cause strange results, as shown in the following example:

 

COLUPF = $44
rem draw some vertical lines 1 pixel high
pfvline 0 0 0 on
pfvline 2 1 1 on
pfvline 4 2 2 on
pfvline 6 3 3 on
pfvline 8 4 4 on
pfvline 10 5 5 on
pfvline 12 6 6 on
pfvline 14 7 7 on
pfvline 16 8 8 on
pfvline 18 9 9 on
pfvline 20 10 10 on
loop
drawscreen
goto loop

 

post-7456-1125724659_thumb.jpg

 

I know it doesn't make sense to use pfvline or pfhline to draw a 1-pixel line, but I chose 1-pixel lines to help show the pattern. The same thing happens with vertical lines of other lengths. Here's another example, along with the compiled code and subroutines:

 

COLUPF = $44
rem try to draw a vertical line 2 pixels high
pfvline 2 3 4 on
loop
drawscreen
goto loop

 

.L02 ;  pfvline 2 3 4 on

 

LDA #4

STA temp3

LDA #2

LDY #3

LDX #0

jsr pfvline

 

Okay, so temp3 gets the ending_row value (4), the Accumulator gets the column value (2), the Y register gets the starting_row value (3), and the X register gets the on/off/flip value. That doesn't seem to jive with the comment at the beginning of the pfvline routine:

 

pfvline

;x=xvalue, y=yvalue, a=0,1,2, temp3=endx

jsr setuppointers

sty temp1 ; store memory location offset

inc temp3 ; increase final x by 1

lda temp3

asl

asl ; multiply by 4

clc

adc temp1 ; add to original memory offset to get final offset

sta temp3 ; store it

; right now, temp1=y=starting memory location, temp3=final

; x should equal original x value

keepgoingy

jsr plotpoint

iny

iny

iny

iny

cpy temp3

bmi keepgoingy

rts

 

However, looking at the setuppointers routines, the values in A and X are getting swapped before the pfvline routine uses them:

 

setuppointers

stx temp2 ; store on.off.flip value

tax ; put x-value in x

lsr

lsr

lsr ; divide x pos by 8

sta temp1

tya

asl

asl ; multiply y pos by 4

clc

adc temp1 ; add them together to get actual memory location offset

tay ; put the value in y

lda temp2 ; restore on.off.flip value

rts

 

plotpoint

lda temp2 ; load on.off.flip value (0,1, or 2)

beq pixelon  ; if "on" go to on

lsr

bcs pixeloff ; value is 1 if true

lda playfield,y ; if here, it's "flip"

eor setbyte,x

sta playfield,y

rts

pixelon

lda playfield,y

ora setbyte,x

sta playfield,y

rts

pixeloff

lda setbyte,x

eor #$ff

and playfield,y

sta playfield,y

rts

 

I did a dry run on paper, and temp3 ends up being too large. The corrected code should look as follows (I've commented out the erroneous lines):

 

pfvline

;x=xvalue, y=yvalue, a=0,1,2, temp3=endx

jsr setuppointers

sty temp1 ; store memory location offset

inc temp3 ; increase final x by 1

lda temp3

asl

asl ; multiply by 4

;;; clc <--- no, we shouldn't be adding temp1 to it

;;; adc temp1 ; add to original memory offset to get final offset <--- no

sta temp3 ; store it

; right now, temp1=y=starting memory location, temp3=final

; x should equal original x value

keepgoingy

jsr plotpoint

iny

iny

iny

iny

cpy temp3

bmi keepgoingy

rts

 

I copied pf_drawing.asm (to save the original version), edited pf_drawing.asm to remove the two lines indicated, recompiled the first test program that draws all the 1-pixel vertical lines, and it worked correctly.

 

The revised pf_drawing.asm file is attached to this post.

 

Michael Rideout

pf_drawing.zip

That doesn't seem to jive with the comment at the beginning of the pfvline routine:

 

;x=xvalue, y=yvalue, a=0,1,2, temp3=endx

Yeah, the comment is wrong - I changed the code from 0.2-0.3 and switched around regs but didn't change the comment.

I did a dry run on paper, and temp3 ends up being too large. The corrected code should look as follows (I've commented out the erroneous lines):

;;; clc <--- no, we shouldn't be adding temp1 to it

;;; adc temp1 ; add to original memory offset to get final offset <--- no

You're right, and I can't really say what I was thinking when I added the start and end values in the code. Also thanks for fixing it for me - I'll add a comment in the source that credits you unless you added one yourself.

That doesn't seem to jive with the comment at the beginning of the pfvline routine:

 

;x=xvalue, y=yvalue, a=0,1,2, temp3=endx

Yeah, the comment is wrong - I changed the code from 0.2-0.3 and switched around regs but didn't change the comment.

924240[/snapback]

No, I think the comment is correct-- if it describes what's in X, Y, A, and temp3 *after* performing the setuppointers subroutine. It would be easier to understand if what is *sent* to pfvline is the same as what's actually used in it, without having to swap X and A around, but that's only an issue for anyone trying to unravel the code. I didn't look too closely, but I wonder if you could save a few bytes by not having to swap X and A around like that, although of course you need to use A for the ASLs and LSRs anyway, so that might have been the best way to do it.

 

I did a dry run on paper, and temp3 ends up being too large. The corrected code should look as follows (I've commented out the erroneous lines):

;;; clc <--- no, we shouldn't be adding temp1 to it

;;; adc temp1 ; add to original memory offset to get final offset <--- no

You're right, and I can't really say what I was thinking when I added the start and end values in the code. Also thanks for fixing it for me - I'll add a comment in the source that credits you unless you added one yourself.

924240[/snapback]

No, I didn't add a comment to credit myself, I just removed the two lines (rather than commenting them out as I'd done in the post).

 

I'm glad I took the time to look at the code, because I'd been thinking of trying to access the playfield bytes directly using an array (i.e., "z[something] = value," where "something" would be the array index needed to set a particular byte of the playfield as desired). I figure I might be able to save memory in my program if I do that, especially since the playfield for the rooms in Reventure follow a specific type of pattern-- so it should be easy to change the room-drawing routine to set the necessary bytes of the playfield array, rather than using the pf draw routines.

 

The other error that I'd mentioned-- variables not allowed in bit operations, or whatever it said-- appears to be very difficult to recreate, since the code was actually correct, but the error occurred when I had several windows open and was repeatedly minimizing and restoring the 2600IDE window. If I can ever manage to recreate it, I'll copy the compiler message and see if I can give more exact details on what I was doing just before the error occurred, as well as including a copy of the line that the error reputedly occurred on.

 

Michael Rideout

More info on bugs:

 

Comparisons don't always compile correctly with a logical "or" ("||"). The one case I know of for sure is when ">" follows the "||," as in this example:

 

 if a < 10 || a > 20 then COLUBK = $44

 

What happens is the accumulator gets loaded with the wrong value on the second comparison (i.e., instead of "LDA this" and then "CMP that," it should be "LDA that" and then "CMP this"; if that change is made then it works as it should).

 

On the other hand, this next example compiles correctly, so the bug seems to be limited to the ">" when it follows the "||":

 

 if a > 20 || a < 10 then COLUBK = $44

 

However, the "or" could also be rewritten to save bytes, because it ends up with repeated code (i.e., the "then" portion appears twice, which could be waste a lot of unnecessary bytes if the "then" portion consists of several statements).

 

I'm no 6502 assembly expert, and I practically had a brain meltdown while I was trying to figure out how to shorten the compiled code to remove the duplicated statements. But when I have more time I'll try to do a thorough set of tests with different comarisons (<. <=, =, >=, >, <>) in different combinations with the "or" to see if I can identify which ones have problems, and also try to come up with a more compacted general-purpose logic that avoids unnecessary duplicated code.

 

Also, the problem I had reported earlier, about the bogus compile errors that go away if you compile the code again once or twice without changing it, *appears* to be a possible problem with temporary work files or something (does that make sense?). I don't know how to describe it better, but if you load a program into 2600IDE and compile it, then load another program into 2600IDE and compile it-- or maybe just make a change in the first program and recompile it-- sometimes all sorts of weird errors appear, yet they go away by simply recompiling the code again (sometimes it takes two recompiles). So I'm guessing that the problem may be with temporary work files that don't get blown away and recreated between compiles. I haven't tried to duplicate the problem by compiling from the command prompt rather than through 2600IDE, but I've been wondering if maybe it's some kind of strange problem with 2600IDE, rather than with batari BASIC.

 

And speaking of 2600IDE, I have a serious issue with it! :) If you've been working on a program, and then you start a new program, but forget to do "save as" and give it a new name, it will overwrite the previous program. If I remember right, it even happens if you close 2600IDE, then restart it. It seems that even though the title on the window says "untitled.26b" for the program name, if you click "save" instead of "save as," it uses the name of the last program you were working on, instead of saving the new program as "untitled.26b"! I overwrote my "Reventure" game that way-- twice now!-- and even though I had another copy of it in another directory, I had made some changes in it. So I had to load the last ".asm" file for it and edit the compiled code to remove all the assembly and leave just the original bB lines. It would be super-duper if Attendo could fix that, maybe by setting a flag in 2600IDE whenever a new program is started, or when 2600IDE is restarted, so that any unnamed new program gets saved as "untitled.26b" instead of being saved under the name of the "most recently-used file."

 

On another note, I hope to launch my tutorial series soon (this coming weekend, hopefully). My main problem is that I keep trying to say too much, or I keep going over what I've already written in an effort to improve it. Once I get it launched, I should be able to just write it and post it without agonizing too much over it.

 

Also, I've put together a "2600bB" package that includes the bB files, plus DASM, plus 2600IDE, plus Stella, plus z26-- an "all-in-one" package, with all of the files separated into different subdirectories, like a "Docs" subdirectory for the readmes and help, an "Includes" subdirectory for the include files, a "Projects" subdirectory for programming projects, a "Stella" subdirectory for Stella, a "z26" subdirectory for z26, and a "Tutorial" subdirectory where the tutorial HTML pages will go. As long as the ".bat" files are modified slightly to compensate, it works great! Since I know a lot of people already have bB and an emulator installed, I'll explain what changes would need to be made to get an existing install to work, also since other people might want to use different subdirectory names to organize things.

 

And you *can* use z26 or some other emulator with 2600IDE, you simply point to the "z26.exe" program when it says "locate stella," and 2600IDE doesn't care or know any different! :)

 

I really think batari BASIC is *so* cool, and I want to see more people, especially beginners, start using it, which is why I'm trying to make "the perfect tutorial" for it. But be warned-- the pace will probably be too slow for most intermediate and advanced programmers.

 

While I'm thinking about it, I'd like to request, or suggest, that the score routines be modified to work with non-BCD values in variables, such as "score = score + x" where the "x" variable is a non-BCD value. I'll even contribute toward making that happen, because it can already be done by using a "for-next" loop (e.g., "for t = 1 to x : score = score + 1 : next," or something like that). This request comes about because as soon as I started playing with batari BASIC (in v0.2), I tried to use the score to display the x,y position of the player while I moved the player around the screen, so I could see what x and y values were safe to use, or which values corresponded to the four edges of the screen (e.g., "score = 1000 * x + y" so the first three digits show the "x" position, and the last three digits show "y"). I soon learned that complex math statements like that don't work, and that the values must be in BCD format, so the equivalent would be as follows:

 

 player0x = x
 player0y = y
 score = 0
 for t = 1 to x : score = score + 1000 : next
 for t = 1 to y : score = score + 1 : next

 

Well, if you can do it with a "for-next," then you could do the same thing using assembly. The only "trick" would be determining when to use BCD and when to use the "for-next" sort of solution for non-BCD values, but this might could be handled by selecting between two different includes-- one for BCD math with the score, and another for non-BCD math with the score. Or maybe with a new "set" command, like "set nonbcdscore on" or something like that?

 

Michael Rideout

More info on bugs:

 

Comparisons don't always compile correctly with a logical "or" ("||"). The one case I know of for sure is when ">" follows the "||," as in this example:

 

 if a < 10 || a > 20 then COLUBK = $44

 

What happens is the accumulator gets loaded with the wrong value on the second comparison (i.e., instead of "LDA this" and then "CMP that," it should be "LDA that" and then "CMP this"; if that change is made then it works as it should).

 

On the other hand, this next example compiles correctly, so the bug seems to be limited to the ">" when it follows the "||":

 

 if a > 20 || a < 10 then COLUBK = $44

 

I tried out the code above and have confirmed this bug - I'll add it to the todo list.

Also, the problem I had reported earlier, about the bogus compile errors that go away if you compile the code again once or twice without changing it, *appears* to be a possible problem with temporary work files or something (does that make sense?).

Very possible - maybe the files aren't being properly closed when bB exits. I'll try to improve the parts that handle temp work files.

On another note, I hope to launch my tutorial series soon (this coming weekend, hopefully). My main problem is that I keep trying to say too much, or I keep going over what I've already written in an effort to improve it. Once I get it launched, I should be able to just write it and post it without agonizing too much over it.

...

I really think batari BASIC is *so* cool, and I want to see more people, especially beginners, start using it, which is why I'm trying to make "the perfect tutorial" for it. But be warned-- the pace will probably be too slow for most intermediate and advanced programmers.

It's OK if the pace is a little slow. I mean, there have been numerous people in the past who had little programming experience, but they wanted to program for the 2600. Unfortunately, the learning curve was so steep that they were politely (or sometimes not politely) turned away. With a good tutorial, maybe some of these people can write a real game.

While I'm thinking about it, I'd like to request, or suggest, that the score routines be modified to work with non-BCD values in variables, such as "score = score + x" where the "x" variable is a non-BCD value. I'll even contribute toward making that happen, because it can already be done by using a "for-next" loop (e.g., "for t = 1 to x : score = score + 1 : next," or something like that).

927311[/snapback]

Perhaps I'll write an asm function that will convert to-from BCD, and the function can be included as a module. An asm function should be speedy and wouldn't need to be hard-coded into the compiler.

Invalid Operator

 

a=-a or a = -a gives that error message. Seems you can't flip between -1 and 1 like that.

927401[/snapback]

 

I see! However, "a = 0 - a" does compile, so you can use that method to flip the sign of a variable.

 

Michael Rideout

 

And speaking of 2600IDE, I have a serious issue with it! :) If you've been working on a program, and then you start a new program, but forget to do "save as" and give it a new name, it will overwrite the previous program. If I remember right, it even happens if you close 2600IDE, then restart it. It seems that even though the title on the window says "untitled.26b" for the program name, if you click "save" instead of "save as," it uses the name of the last program you were working on, instead of saving the new program as "untitled.26b"! I overwrote my "Reventure" game that way-- twice now!-- and even though I had another copy of it in another directory, I had made some changes in it. So I had to load the last ".asm" file for it and edit the compiled code to remove all the assembly and leave just the original bB lines. It would be super-duper if Attendo could fix that, maybe by setting a flag in 2600IDE whenever a new program is started, or when 2600IDE is restarted, so that any unnamed new program gets saved as "untitled.26b" instead of being saved under the name of the "most recently-used file."

 

Hi, thanks you like the IDE. I tried recreating the problem but I cant find it. I just released a new version of the IDE with an updated sprite editor and a new playfield editor. Also if you want to start a new file you can choose 'file' and the 'new' from the menu which probally solves the overwriting thing.

 

And you *can* use z26 or some other emulator with 2600IDE, you simply point to the "z26.exe" program when it says "locate stella," and 2600IDE doesn't care or know any different! :)

 

I replaced references to Stella with just Emulator since, as you pointed out, it doesn't care which Atari emulator you use with it.

 

I really think batari BASIC is *so* cool

927311[/snapback]

 

me to :)

 

The new 2600IDE can be downloaded from Atari 2600 BASIC IDE thread.

 

greets

Do you want IDE bug reports here too? About one out of every three compiles, the little window comes up and it will not let me hit Run Compile or Done or the Close button. I have to kill the whole program the hard way and try again.

 

Oh yeah, one more thing. I noticed that with all versions of the IDE I have used that sometimes copy and paste doesn't work. I'll have to close the program and load it again (sometimes more than once).

 

 

Windows XP

256MB

Edited by Random Terrain

The bit testing is a bit buggy. I expected "if a{0} then its_true" to be true if a{0} is equal to 1 (0 = false, 1 = true), but it doesn't always work that way, as shown in the following example:

  if a{0} then its_true
  if a{0} then goto its_true
its_false
  a = 0
its_true
  a = 1

The two ifs should do the same thing (i.e., go to the same place), even if they do compile a little differently because one branches and the other jumps. But this is how they compile:

.L00;  if a{0} then its_true

LDA a
LSR
bcc .its_true
.L01;  if a{0} then goto its_true

LDA a
LSR
BCC .skipL01
JMP .its_true

.skipL01

The first if goes to the its_true line if a{0} = 0, which I think is backwards if 0 is false and anything nonzero is true; whereas the second if goes to the its_true line if a{0} = 1, which I think is correct.

 

The a{6} and a{7} evaluations seem to be correct, but they use a different kind of logic (they use BIT to test bits 6 and 7).

 

By the way, according to the documentation I thought I could do "if a{0} = 0 then whatever," or "if a{0} = 1 then whatever," but they produce errors. They don't generate bB compile errors, but they do generate DASM compile errors. Changing them to "if a{0} = 0 then goto whatever" does generate a bB compile error. It actually makes more sense to say just "if a{0} then whatever," since a bit will either be on (true) or off (false), so adding "= 0" or "= 1" is kind of redundant, but I would think that it should still be okay-- and the documentation even gives some examples like that, which implies that it's supposed to be okay.

 

I also noticed that some of the additions and subtractions can be better optimized for specific values. For example, "a = a + 1" compiles as "INC a," which is nice :), but "a = a + 2" compiles as "LDA a : CLC : ADC #2 : STA a," which could be shortened into just "INC a : INC a," which takes the same number of cycles but requires fewer bytes. The same is true for "a = a - 2"; it could be optimized into "DEC a : DEC a."

 

And if the math is limited to unsigned bytes, then "a = a + 255" will be equivalent to "a = a - 1," so it could be optimized into "DEC a." Similarly, "a = a - 255" could be optimized into "INC a." Also, "a = a + 254" and "a = a - 254" could be optimized into "DEC a : DEC a" and "INC a : INC a," respectively. The bB compiler is already handling "a = a + 1" and "a = a - 1" as special cases, so it should be easy to add "+ 2," "- 2," "+ 255," "- 255," "+ 254," and "- 254" to the special cases that are being handled differently for optimization purposes.

 

Of course, if the math is working with floating-point variables, or for that matter with the score, then the addition and subtraction would have to be handled differently, so the suggested optimizations are strictly for unsigned byte variables.

 

Michael Rideout

  • 2 weeks later...

I used the search for this thread and it can't find pfread, so I guess that means no one has mentioned this. Unless I am misunderstanding how pfread works, I think it is flipped.

 

This one checks to see if a pixel is there when I think it's supposed to do the opposite:

 

if !pfread(x,y) then . . .

 

 

This one checks to see if a pixel is gone when I think it's supposed to do the opposite:

 

if pfread(x,y) then . . .

 

 

Is that a bug or am I misunderstanding?

I used the search for this thread and it can't find pfread, so I guess that means no one has mentioned this. Unless I am misunderstanding how pfread works, I think it is flipped.

 

This one checks to see if a pixel is there when I think it's supposed to do the opposite:

 

if !pfread(x,y) then . . .

 

 

This one checks to see if a pixel is gone when I think it's supposed to do the opposite:

 

if pfread(x,y) then . . .

 

 

Is that a bug or am I misunderstanding?

938860[/snapback]

I may be wrong, but I think it's a bug, similar to the bit-test bug I mentioned. To my way of think, in a generic statement like IF THIS THEN THAT, the THIS condition should be false if it's equal to zero, and true if it's anything non-zero.

 

The odd thing is, some of these (bit test anyway, not sure about pfread) work correctly if you follow the then with a goto. I think Fred's aware of this now, and is going to fix it when he gets a breather, but it's good you specifically mentioned pfread, as I saw the same thing in my braid maze generator, but not sure if I mentioned it specifically.

 

Michael Rideout

The odd thing is, some of these (bit test anyway, not sure about pfread) work correctly if you follow the then with a goto. I think Fred's aware of this now, and is going to fix it when he gets a breather, but it's good you specifically mentioned pfread, as I saw the same thing in my braid maze generator, but not sure if I mentioned it specifically.

938888[/snapback]

Holy French fried monkey feet! You're not kidding. Using pfread with a goto after then flips it back to normal.

Is it just me or is pfvline still not working like pfhline? It seems that instead of indicating an exact position to end, endypos is really adding the number to ypos.

 

Is that going to be the official way it will work from now on or will it eventually work like pfhline?

 

 

Thanks.

Is it just me or is pfvline still not working like pfhline? It seems that instead of indicating an exact position to end, endypos is really adding the number to ypos.

 

Is that going to be the official way it will work from now on or will it eventually work like pfhline?

 

 

Thanks.

941274[/snapback]

This is a bug - pfvline was intended to work like pfhline. SeaGtGruff fixed the bug for me a little while ago and it will be put in the next release.

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.

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...