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
1
