Bug Report Thread

[Luigi301]

Alpha 0.3 will have paddles right?

[+batari]

A friend of mine tested Solar Plexus on a real 2600, and had some difficulty loading the game on his Crocodile Cartridge.  Apparently, two bytes are missing from the end of the compiled program, a problem he solved by adding the two missing bytes with a hex program.  Don't know if that's worth mentioning, but I thought I'd bring it up just in case anyone else was interested in selling their games.

 

JR

902031[/snapback]

Strange - bB generates files that are 4096 bytes - no missing bytes. Have you been getting 4094 bytes? If so let me know, there may be something missing from the 2600basicfooter.asm file.

[+batari]

Alpha 0.3 will have paddles right?

902118[/snapback]

There may be an alternate kernel with paddle support. Actually, I already made one, but it didn't seem to work right in Stella... It worked in z26 though. Not sure why

[Luigi301]

So it'll have a ball-and-paddle kernel? That's really what I need for my game, ball support and paddle support. I haven't done any playtesting of it because I can't get missiles to work properly.

Edited August 1, 2005 by Luigi301

[Jess Ragan]

A friend of mine tested Solar Plexus on a real 2600, and had some difficulty loading the game on his Crocodile Cartridge.  Apparently, two bytes are missing from the end of the compiled program, a problem he solved by adding the two missing bytes with a hex program.  Don't know if that's worth mentioning, but I thought I'd bring it up just in case anyone else was interested in selling their games.

 

JR

902031[/snapback]

Strange - bB generates files that are 4096 bytes - no missing bytes. Have you been getting 4094 bytes? If so let me know, there may be something missing from the 2600basicfooter.asm file.

902139[/snapback]

 

This is what he told me:

 

Yep, works great.

 

Only problems I see are:

 

    * The TV picture rolls when going between the title screen and the game screen. This isn't really noticible going from game->game over, or game over->title, so maybe your game setup is taking too long? Not a _big_ deal, but it's definitely noticeable. Maybe you could do a drawscreen in the middle of your initialization? Turn on the scanline counter in Z26 and make sure it's stable.

    * The ROM is strangely two bytes short of a full 4kb. This is the BRK vector, I think, and so the contents of these two bytes are largely useless, but this gave me some problems with the serial downloading tool that I used for the CC2. (I ended up just adding an extra two bytes to the end. No problem.) Almost certainly a bug in Batari Basic itself, unless you had weird problems uploading it to your webspace.

 

The file seems to be a full 4096 bytes from what I can see, so I'm not sure what's going on here.

 

JR

[attendo]

Dont know for sure its a bug in bB or its just a 2600 thing, but I wonder why I cant align 2 sprites just right even using the same y number (40 in this)?

 

What happens if you set VDELP0 or VDELP1 to 1?

902001[/snapback]

 

Setting VDELP0 = 1 works for now, cant wait until alpha 0.3 is released

[potatohead]

Maybe we need a feature request thread too.

 

This isn't a bug, but would save quite a bit.

 

Can we get a bit toggle?

 

v(x) = 1, 0 or flip

 

Thinking about this a little more, can I use bit operations on just bits? Come to think about it, is there an eor operator. (Maybe I am thinking of xor)

 

Is it legal to do? d(1) = d(1) [whatever eor , xor is) d(1) to toggle?

[+batari]

Maybe we need a feature request thread too.

 

This isn't a bug, but would save quite a bit.

 

Can we get a bit toggle?

 

v(x) = 1, 0 or flip

 

Thinking about this a little more, can I use bit operations on just bits?  Come to think about it, is there an eor operator.  (Maybe I am thinking of xor)

 

Is it legal to do?  d(1) = d(1) [whatever eor , xor is) d(1) to toggle?

909769[/snapback]

The above isn't currently legal right now. But I can see the logic in being able to assign one bit to the value of another. So flipping a bit would have the following syntax when I implement it:

d(1)=!d(1)

 

I don't think this is too hard to do, so I'll see about slipping it in. You will only be able to do assignments, such as a(4)=c(3), for now. I will add operations (as and, or, xor) later.

[potatohead]

Maybe we need a feature request thread too.

 

This isn't a bug, but would save quite a bit.

 

Can we get a bit toggle?

 

v(x) = 1, 0 or flip

 

Thinking about this a little more, can I use bit operations on just bits?  Come to think about it, is there an eor operator.  (Maybe I am thinking of xor)

 

Is it legal to do?  d(1) = d(1) [whatever eor , xor is) d(1) to toggle?

909769[/snapback]

The above isn't currently legal right now. But I can see the logic in being able to assign one bit to the value of another. So flipping a bit would have the following syntax when I implement it:

d(1)=!d(1)

 

I don't think this is too hard to do, so I'll see about slipping it in. You will only be able to do assignments, such as a(4)=c(3), for now. I will add operations (as and, or, xor) later.

909800[/snapback]

 

 

That does a lot actually. Anything more messy can be handled in the usual way, IMHO with little penalty. (Or if there is one, inline assembly can mitigate that.)

[danwinslow]

Well, using parentheses, at least like that, isn't maybe a good idea; anybody used to coding in general will tend to be confused by that. I think bit operations are a good idea, but I would suggest using something other than parens. How about something like

 

d:1 = b:2 for assigning bit 1 of d from bit 2 of b

d:2 & b:3 for an and op

d:2 | b:3 for or

etc.

[vdub_bobby]

Alpha 0.3 bug:

 

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

  Temp = %11111111
 if Temp{3} = 1 then goto SomeOtherLine

That if...then conditional is evaluating as FALSE.

 

In fact, every if...then I have tried that uses bit operations has evaluated to FALSE no matter what it should evaluate to.

[+batari]

Alpha 0.3 bug:

 

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

  Temp = %11111111
 if Temp{3} = 1 then goto SomeOtherLine

That if...then conditional is evaluating as FALSE.

 

In fact, every if...then I have tried that uses bit operations has evaluated to FALSE no matter what it should evaluate to.

917063[/snapback]

Fixed. I inadvertantly deleted a line of code while I was trying to clean up memory leaks. But this one will break a lot of existing code, so please report all you can in the next couple of days, as I'll do a quick 0.35 maintenance release so you can actually use bB.

 

Until then, I'll test some things out myself... Some of the fixed point math, for instance, is almost totally untested.

[Tork110]

The sample file for bB 0.3 works on this computer, an XP, but it doesn't work on the Windows 98 computer. It gives me this complaint:

 

 

 

>2600bas sample.bas

 

 

C:\>preprocess <sample.bas|2600basic.exe>bB.asm

File not found

 

C:\>concatenate>sample.bas.asm

Cannot open bB.asm for reading

 

C:\>dasm sample.bas.asm -f3 -osample.bas.bin

DASM V2.20.10, Macro Assembler ©1988-2004

--- Unresolved Symbol List

NO_ILLEGAL_OPCODES 0000 ???? (R )

scoretable 0000 ???? (R )

--- 2 Unresolved Symbols

 

Fatal assembly error: Source is not resolvable.

[+batari]

The sample file for bB 0.3 works on this computer, an XP, but it doesn't work on the Windows 98 computer.  It gives me this complaint:

 

 

 

>2600bas sample.bas

 

 

C:\>preprocess <sample.bas|2600basic.exe>bB.asm

File not found

 

C:\>concatenate>sample.bas.asm

Cannot open bB.asm for reading

 

C:\>dasm sample.bas.asm -f3 -osample.bas.bin

DASM V2.20.10, Macro Assembler ©1988-2004

--- Unresolved Symbol List

NO_ILLEGAL_OPCODES      0000 ????        (R )

scoretable              0000 ????        (R )

--- 2 Unresolved Symbols

 

Fatal assembly error: Source is not resolvable.

917385[/snapback]

Check to see if one of the files is missing - either preprocess.exe, sample.bas, or 2600basic.exe. If not, maybe Win98 is confused by the long filenames. I'll try on a Win98 box myself later.

[s0c7]

I don't have time tonight to look into this, but I just d/l'd 0.3 and tried compiling F-4 & Pirate. I knew the bins wouldn't work right, but I thought they would probably compile. But they both return label mismatch errors, which is an odd problem to be having for something that was working.

Edited August 24, 2005 by s0c7

[+batari]

I don't have time tonight to look into this, but I just d/l'd 0.3 and tried compiling F-4 & Pirate.  I knew the bins wouldn't work right, but I thought they would probably compile.  But they both return label mismatch errors, which is an odd problem to be having for something that was working.

917486[/snapback]

I investigated and found the source of the bug - it crept up because I changed the way I handle || (logical OR) in if-thens. It was an easy fix. Unfortunately, until I post the fix, you can only use || once per program or more mismatches will occur.

 

Come to think of it, I think a good way for me to find bugs is to try existing programs in 0.3a, so I'll go ahead and try F-4 and Ooze tonight.

[+batari]

I don't have time tonight to look into this, but I just d/l'd 0.3 and tried compiling F-4 & Pirate.  I knew the bins wouldn't work right, but I thought they would probably compile.  But they both return label mismatch errors, which is an odd problem to be having for something that was working.

917486[/snapback]

I investigated and found the source of the bug - it crept up because I changed the way I handle || (logical OR) in if-thens. It was an easy fix. Unfortunately, until I post the fix, you can only use || once per program or more mismatches will occur.

 

Come to think of it, I think a good way for me to find bugs is to try existing programs in 0.3a, so I'll go ahead and try F-4 and Ooze tonight.

917512[/snapback]

No new bugs found from compiling F-4 and Ooze... They both compiled after changing bit accesses to use {braces}. I also changed all of the > in F4 to >= and inverted the accesses to bits 0-5 and it seems to play fine under 0.3a as well. Ooze had hundreds of bit accesses so I didn't invert the bits, but it does compile nonetheless.

 

A good sign, I hope - that the new features didn't totally break the old stuff. Please keep bug reports coming!

[SeaGtGruff]

This thread is for reporting bugs in the Batari BASIC language itself.

 

Please include a description of the problem, any error messages that come up, and ideally a minimal amount of code that would make the problem occur.

895630[/snapback]

 

"Cannot open includes.bB"

 

I've installed 0.3a in its own directory, but I can't compile anything with it-- not even the sample program. I get the following:

 

File not found

Cannot open includes.bB for reading

DASM V2.20.10, Macro Assembler ©1988-2004

Complete.

 

There is no "includes.bB" in the zipped install file for 0.3a. Am I supposed to create it myself? It isn't mentioned in the help file.

 

Michael Rideout

[+batari]

This thread is for reporting bugs in the Batari BASIC language itself.

 

Please include a description of the problem, any error messages that come up, and ideally a minimal amount of code that would make the problem occur.

895630[/snapback]

 

"Cannot open includes.bB"

 

I've installed 0.3a in its own directory, but I can't compile anything with it-- not even the sample program. I get the following:

 

File not found

Cannot open includes.bB for reading

DASM V2.20.10, Macro Assembler ©1988-2004

Complete.

 

There is no "includes.bB" in the zipped install file for 0.3a. Am I supposed to create it myself? It isn't mentioned in the help file.

 

Michael Rideout

917656[/snapback]

This file is created by bB itself - no need to create one. The problem is likely the "file not found" above... Maybe bB isn't running at all, so no file is being created.

 

What's your OS?

[vdub_bobby]

I am unable to include div_mul16.asm.

 

Specifically, when I try to include it my program compiles fine and runs but I get nothing but a blank screen.

 

When I don't include it ('rem'arking out the include line) it compiles and runs as I expect.

 

I'm not using any of the div_mul16 functions in my code. Is that the problem?

 

EDIT: Just saw that this was addressed already. So, uh...nevermind.

Edited August 24, 2005 by vdub_bobby

[potatohead]

I don't have time tonight to look into this, but I just d/l'd 0.3 and tried compiling F-4 & Pirate.  I knew the bins wouldn't work right, but I thought they would probably compile.  But they both return label mismatch errors, which is an odd problem to be having for something that was working.

917486[/snapback]

I investigated and found the source of the bug - it crept up because I changed the way I handle || (logical OR) in if-thens. It was an easy fix. Unfortunately, until I post the fix, you can only use || once per program or more mismatches will occur.

 

Come to think of it, I think a good way for me to find bugs is to try existing programs in 0.3a, so I'll go ahead and try F-4 and Ooze tonight.

917512[/snapback]

No new bugs found from compiling F-4 and Ooze... They both compiled after changing bit accesses to use {braces}. I also changed all of the > in F4 to >= and inverted the accesses to bits 0-5 and it seems to play fine under 0.3a as well. Ooze had hundreds of bit accesses so I didn't invert the bits, but it does compile nonetheless.

 

A good sign, I hope - that the new features didn't totally break the old stuff. Please keep bug reports coming!

917567[/snapback]

 

I'll be sorting through all of those this coming weekend... Every bit counts! Thanks for your hard work. It will be nice to get the core language issues worked out. I kept a log of the bit operations and which would need to flip when the comparisons got fixed. Should not be too big of a deal.

[+stephena]

Alpha 0.3 will have paddles right?

902118[/snapback]

There may be an alternate kernel with paddle support. Actually, I already made one, but it didn't seem to work right in Stella... It worked in z26 though. Not sure why

902143[/snapback]

No doubt because Stella defaults to using joysticks, and the ROM must have a properties file specifying to use paddles. In the absense of that file, paddles aren't supported.

 

In the next release of Stella, you'll be able to specify 'use paddles' on the commandline, so the creation of a properties file will be unnecessary.

[SeaGtGruff]

"Cannot open includes.bB"

 

I've installed 0.3a in its own directory, but I can't compile anything with it-- not even the sample program. I get the following:

 

File not found

Cannot open includes.bB for reading

DASM V2.20.10, Macro Assembler ©1988-2004

Complete.

 

There is no "includes.bB" in the zipped install file for 0.3a. Am I supposed to create it myself? It isn't mentioned in the help file.

 

Michael Rideout

917656[/snapback]

This file is created by bB itself - no need to create one. The problem is likely the "file not found" above... Maybe bB isn't running at all, so no file is being created.

 

What's your OS?

917665[/snapback]

 

Don't laugh... I'm using Windows 95 on this computer.

 

The problem seems to be with this command:

 

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

 

It returns "File not found" every time. The %1 parameter is working fine, and it isn't a problem with long filenames or funky directory names. For the record, the directory path I'm using is

 

C:\Atari\2600\batari BASIC\0.3 Alpha

 

so the above command (when used with the sample.bas program) is coming out as

 

preprocess <"C:\Atari\2600\batari BASIC\0.3 Alpha\sample.bas"|2600basic.exe>bB.asm

 

I also have "0.1 Alpha" and "0.2 Alpha" subdirectories under "batari BASIC," and they have no trouble compiling. It's something to do with preprocess.

 

I edited the batch file, to replace all "%1"s with just "sample.bas" (which is in the same directory as everything else, so preprocess shouldn't have any trouble finding it), but got the same results.

 

I wasn't sure about the "|" in the command line, so I looked it up and saw that it writes to the temp directory(?). So I verified that the TEMP environment variable is set, that the directory being pointed to exists, and I even appended that directory name to the end of the search PATH-- but nothing works. And the temp directory (C:\Windows\temp) doesn't seem to be getting written to.

 

What exactly is that line supposed to be doing? I'm familiar with using "|more", so is "|2600basic.exe" supposed to be processing the results of "preprocess <%1", and then redirecting its output to bB.asm?

 

I see that a similar error is occurring in Windows 98, so I guess preprocess doesn't like Windows 95 and Windows 98. :-(

 

Michael Rideout

[SeaGtGruff]

The problem seems to be with this command:

 

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

 

It returns "File not found" every time.

918051[/snapback]

 

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.

 

Michael Rideout

 

"Persistence of vision is okay, but persistence of effort is even better!"

[+batari]

The problem seems to be with this command:

 

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

 

It returns "File not found" every time.

918051[/snapback]

 

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.

 

Michael Rideout

 

"Persistence of vision is okay, but persistence of effort is even better!"

918070[/snapback]

Thanks! This saves me from digging up an old win95 box out of the garage... I'll fix the batch file for the next release.