[Luigi301]

Alpha 0.3 will have paddles right?

[batari]

Jess Ragan, on Sun Jul 31, 2005 7:04 PM, said:

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

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]

Luigi301, on Sun Jul 31, 2005 9:45 PM, said:

Alpha 0.3 will have paddles right?

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.

This post has been edited by Luigi301: Sun Jul 31, 2005 9:33 PM

[Jess Ragan]

batari, on Mon Aug 1, 2005 3:07 AM, said:

Jess Ragan, on Sun Jul 31, 2005 7:04 PM, said:

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

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.

This is what he told me:

Quote

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]

supercat, on Sun Jul 31, 2005 11:34 PM, said:

attendo, on Sun Jul 31, 2005 3:59 PM, said:

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?

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]

potatohead, on Fri Aug 12, 2005 1:44 AM, said:

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?

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]

batari, on Fri Aug 12, 2005 3:52 AM, said:

potatohead, on Fri Aug 12, 2005 1:44 AM, said:

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?

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.

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]

vdub_bobby, on Tue Aug 23, 2005 1:58 PM, said:

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.

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]

Tork110, on Tue Aug 23, 2005 8:19 PM, said:

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.

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.

This post has been edited by s0c7: Tue Aug 23, 2005 9:22 PM

[batari]

s0c7, on Tue Aug 23, 2005 10:11 PM, said:

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.

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]

batari, on Tue Aug 23, 2005 10:52 PM, said:

s0c7, on Tue Aug 23, 2005 10:11 PM, said:

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.

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.

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]

kisrael, on Thu Jul 21, 2005 8:33 AM, said:

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.

"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]

SeaGtGruff, on Wed Aug 24, 2005 7:44 AM, said:

kisrael, on Thu Jul 21, 2005 8:33 AM, said:

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.

"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

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.

This post has been edited by vdub_bobby: Wed Aug 24, 2005 9:18 AM

[potatohead]

batari, on Wed Aug 24, 2005 12:22 AM, said:

batari, on Tue Aug 23, 2005 10:52 PM, said:

s0c7, on Tue Aug 23, 2005 10:11 PM, said:

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.

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.

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!

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]

batari, on Sun Jul 31, 2005 11:41 PM, said:

Luigi301, on Sun Jul 31, 2005 9:45 PM, said:

Alpha 0.3 will have paddles right?

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

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]

batari, on Wed Aug 24, 2005 9:09 AM, said:

SeaGtGruff, on Wed Aug 24, 2005 7:44 AM, said:

"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

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?

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]

SeaGtGruff, on Wed Aug 24, 2005 9:04 PM, said:

The problem seems to be with this command:

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

It returns "File not found" every time.

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]

SeaGtGruff, on Wed Aug 24, 2005 8:33 PM, said:

SeaGtGruff, on Wed Aug 24, 2005 9:04 PM, said:

The problem seems to be with this command:

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

It returns "File not found" every time.

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!"

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.