Visual bB Committed Suicide

[Cybearg]

So I was experimenting with replacing some duplicate sprites with assembly that would set pointers en masse to save space. Visual bB didn't like it and crashed. It didn't like it so hard, it's continuing to crash and/or spit out errors about my code, even if I revert back to working, previous, tested versions of the code.

 

It even crashes when I try compiling other, completely unrelated projects that I know were working.

 

I've never heard of a programming error so bad it transcends space-time and affects clean code. Anyone know what's going on? Somehow, it must have bugged out by vbB installation or something, somehow. What can I do to fix it?

 

I typically get some bogus errors and then postprocess.exe fails and sometimes Stella opens a mess of a screen and sometimes it doesn't.

 

If you're wondering what I did, I tried replacing a few sprites with this:

 

asm
.setWingDown

LDX #<duckDown
STX player3pointerlo
STX player5pointerlo
LDA #>duckDown
STA player3pointerhi
STA player5pointerhi
LDA #9
STA player3height
STA player5height

LDX #<duckUp
STX player4pointerlo
LDA #>duckUp
STA player4pointerhi
LDA #9
STA player4height
.
end


asm
.setWingUp

LDX #<duckUp
STX player3pointerlo
STX player5pointerlo
LDA #>duckUp
STA player3pointerhi
STA player5pointerhi
LDA #9
STA player3height
STA player5height

LDX #<duckDown
STX player4pointerlo
LDA #>duckDown
STA player4pointerhi
LDA #9
STA player4height
.
end

 

... with this at the end of the bB file:

 

asm
duckUp
.byte  %00000000
.byte  %10000000
.byte  %01110000
.byte  %11111000
.byte  %00111111
.byte  %01110110
.byte  %01100000
.byte  %01000000

duckDown
.byte  %00000111
.byte  %10001110
.byte  %01111100
.byte  %11111000
.byte  %00111111
.byte  %00000110
.byte  %00000000
.byte  %00000000
end

 

The thing is, I've done something similar in the past and it worked just fine:

 

asm
.DotPlayer
LDX #<playerDot
STX player1pointerlo
STX player2pointerlo
STX player3pointerlo
STX player4pointerlo
STX player5pointerlo
LDA #>playerDot
STA player1pointerhi
STA player2pointerhi
STA player3pointerhi
STA player4pointerhi
STA player5pointerhi
LDA #2
STA player1height
STA player2height
STA player3height
STA player4height
STA player5height
.
end

 

... and at the end of the file:

 

asm

playerDot
.byte  %1

end

Edited March 13, 2013 by Cybearg

[+Random Terrain]

I don't see that one in the troubleshooting section. Once you get this fixed, I better add it.

[Cybearg]

I also get a rather large laundry list of errors (sometimes):

 

 

DASM V2.20.07, Macro Assembler ©1988-2003

--- Unresolved Symbol List

playerL0210_4 0000 ???? (R )

playerL0211_5 0000 ???? (R )

drawscreen 0000 ???? (R )

playerL0206_2 0000 ???? (R )

playerL0213_3 0000 ???? (R )

playerL0214_4 0000 ???? (R )

playerL0215_5 0000 ???? (R )

playerL0202_2 0000 ???? (R )

playerL0209_3 0000 ???? (R )

playerL0190_0 0000 ???? (R )

playerL0191_1 0000 ???? (R )

playerL0186_0 0000 ???? (R )

playerL0187_1 0000 ???? (R )

0.pie 0000 ???? (R )

playerL0194_2 0000 ???? (R )

playerL0182_0 0000 ???? (R )

playerL0196_2 0000 ???? (R )

playerL0183_1 0000 ???? (R )

playerL0199_2 0000 ???? (R )

0.resetgame 0000 ???? (R )

playerL0178_0 0000 ???? (R )

playerL0179_1 0000 ???? (R )

PF2_data0 0000 ???? (R )

PF1_data0 0000 ???? (R )

PF2_data1 0000 ???? (R )

PF1_data1 0000 ???? (R )

PF2_data2 0000 ???? (R )

PF1_data2 0000 ???? (R )

playerL0175_0 0000 ???? (R )

playerL0176_1 0000 ???? (R )

BS_return 0000 ???? (R )

0.skipL0225 0000 ???? (R )

BS_jsr 0000 ???? (R )

 

Fatal assembly error: Source is not resolvable.

Errors were encountered during assembly.

 

EDIT: I still don't know what's causing the assembling problems, but VisualbB seems to crash in part because of the periods after defining areas in Assembly. It will snap me to the highlighted periods and if I hit enter, VisualbB crashes.

 

As for the assembling problems, I seem to have fixed some of them by replacing my DASM.exe with another copy of the same thing (same version and everything), or maybe it was something else I did, but that's all I can think of. I'd already tried restarting and reconfiguring VisualbB multiple times with no change and only after I replaced DASM did things start working somewhat.

 

I hasted to say "somewhat" because any bankswitched games seem to still not work, getting errors like the one I posted above.

Edited March 13, 2013 by Cybearg

[Cybearg]

Just in case someone skimmed the above post and assumed the issue was resolved, this is a bump to say that it's not. There are two separate problems going on:

 

1. VisualbB crashes when it notices the duplicate . used in the assembly code

 

2. bB no longer processes bankswitched games. If there is any bankswitching, postprocess.exe will crash and the compiling will fail. Non-bankswitched game code will still compile.

 

Any ideas, anyone? What file(s) could be modified by a VisualbB error/crash to result in continued compiling failures?

[jwierer]

What happens when you compile from the commandline outside of the IDE? Methinks it is bB and not vbB. Any chance you deleted/replaced one of the core bB files?

 

-Jeff

[Cybearg]

What happens when you compile from the commandline outside of the IDE? Methinks it is bB and not vbB. Any chance you deleted/replaced one of the core bB files?

 

-Jeff

Yes, you're right. Trying to compile via command line doesn't work for bankswitched games the same as it doesn't for VisualbB.

 

I'll try replacing the directory, though I didn't change or remove any files. Something must have been changed or deleted on its own, because I didn't touch it.

 

EDIT: I replaced all the bB DPC files with the ones that Atarius sent me (attached, for reference) and it still doesn't work, neither from the command line nor from VisualbB even though it worked perfectly before this whole mess.

 

What could possibly be wrong?

BB_dpc.zip

Edited March 14, 2013 by Cybearg

[Cybearg]

I've made a video to show what's going wrong, in case it's not clear from my descriptions above:

 

http://www.youtube.com/watch?v=-b_YnDEgdQ4

[+Random Terrain]

This may not be helpful, but have you restarted your computer?

[Cybearg]

This may not be helpful, but have you restarted your computer?

I was hopeful because I realized that I hadn't restarted in weeks, most likely, but no. Restarting didn't fix it, unfortunately.

 

And apparently it's not just bankswitched games that don't work. 2k games don't work, either.

 

EDIT: So anything that's not 4k won't compile, whether it's DPC+ or multisprite.

 

HOWEVER! Sometimes 2k or bankswitched games will work with the standard kernel. Sometimes. I can't find any pattern, because I have some standard kernel 2k games that compiled at 2k and 4k, but if I increase them to 8k, it won't compile. Then, there are standard kernel 4k games that I can increase to 8k and they seem to still compile. I really don't know.

 

And no, it's not a problem with my includes files because, as demonstrated in the above video, I replaced them all with the latest versions.

Edited March 14, 2013 by Cybearg

[+Gemintronic]

DASM is choking on whatever assembly you're throwing into your code is my guess. I assume you've tried a project that JUST has bB commands in it?

[Cybearg]

DASM is choking on whatever assembly you're throwing into your code is my guess. I assume you've tried a project that JUST has bB commands in it?

Yes. When bB crashed on me the first time I added the Assembly, I immediately took it out, but the crashes continued (this was working in the 8k version), so I put the Assembly back in, cut out anything else I could, and make it 4k and it worked again, but now [almost] nothing else does.

 

If there's a question about what does and doesn't work, I urge people to send me code to run so I can see what does and doesn't work. If I'm running my own stuff, I may know it should work, but no one else does, so maybe try suggesting some 2k, 4k, and bankswitched game code that's confirmed to work that I could try?

Edited March 14, 2013 by Cybearg

[+Gemintronic]

Yes. When bB crashed on me the first time I added the Assembly, I immediately took it out, but the crashes continued (this was working in the 8k version), so I put the Assembly back in, cut out anything else I could, and make it 4k and it worked again, but now [almost] nothing else does.

 

If there's a question about what does and doesn't work, I urge people to send me code to run so I can see what does and doesn't work. If I'm running my own stuff, I may know it should work, but no one else does, so maybe try suggesting some 2k, 4k, and bankswitched game code that's confirmed to work that I could try?

 

Sorry for being daft. I mean, NOT just taking out the assembly. Starting a completely new project and making a simple "game" that JUST has batari BASIC commands.

 

Perhaps something from the code snippet section:

http://www.atariage.com/forums/topic/109288-code-snippets-samples-for-bb-beginners/

[Cybearg]

I fiddled around some more. This is really quite frustrating.

 

Some of the problems with me checking different games with and without bankswitching may have been due to the includes files I was using, but that's clearly not the whole problem. DPC+ doesn't work for me at all. Again. Also, there are other games that don't work for unknown reasons. For instance, the attached game has been working fine and I made no modifications to change that, but now it doesn't compile correctly. I get errors, instead:

 

bytes of ROM space left

--> cycle74_HMCLR f07d

--> WaitForVblankEnd f08f

 

Does it work for anyone else?

 

And how about the Omega DPC+ game (also attached)? It worked perfectly for me until these problems.

 

I would be inclined to agree that it must be a code problem, except, as I've said, there are games that I've been working on that compiled perfectly fine and I hadn't touched them during this problem and now they suddenly won't compile, neither from the command line nor VisualbB. I really don't know what to think as, yes, evidence points to the code being the problem, but then why has it been compiling perfectly well up until the Assembly crash in VisualbB?

pixelbounce.bas

pb_multisprite.h.txt

pb_multisprite.inc

omega.bas

pb_multispriteheader.asm

Edited March 14, 2013 by Cybearg

[jwierer]

Do you have multiple versions of bB installed? I wonder if the path is pointing to the wrong directory.

 

-Jeff

[Cybearg]

Do you have multiple versions of bB installed? I wonder if the path is pointing to the wrong directory.

 

-Jeff

I have multiple bB directories, yes, including one that is in the same folder as VisualbB but isn't actually being used as THE bB folder.

 

But, as you see in the video, I point to the directory that I want to point to, plus this has been the case all along, so why am I only having problems now after VbB went on its Assembly crashing spree?

 

Did those files I posted work for anyone else?

Edited March 14, 2013 by Cybearg

[jwierer]

I see a couple of things.

 

1. It doesn't look like vbB is approporiately handling the inline asm keyword which is something I can look into.

 

2. When you have the bB compiler in the same folder I think that overrides any windows environment variable. If I recall it's going to look to the local folder first and if it can't find the executable it is looking for it will then use the windows environment variables.

 

I would try cleaning bB out of your vbB folder. I would also just keep testing solely from the commandline because it looks like the bB compiler failing is causing all your issues.

 

-Jeff

[Cybearg]

I see a couple of things.

 

1. It doesn't look like vbB is approporiately handling the inline asm keyword which is something I can look into.

 

2. When you have the bB compiler in the same folder I think that overrides any windows environment variable. If I recall it's going to look to the local folder first and if it can't find the executable it is looking for it will then use the windows environment variables.

 

I would try cleaning bB out of your vbB folder. I would also just keep testing solely from the commandline because it looks like the bB compiler failing is causing all your issues.

 

-Jeff

It WOULD be nice if VbB would just ignore everything between asm ... end rather than complain about all the incorrect syntax.

 

I tried cleaning out the folder (or rather, I made a new folder, installed build 566 in it, moved my projects over to the new folder, then deleted the old folder) and it doesn't seem to have solved any problems. Clearly bB is part of the problem, but I don't understand why these projects I was working on compiled perfectly before-hand but now won't compile, even with fresh bB installs and everything. This includes DPC+ as well as certain other kernel set-ups (see the attached game files in the above post(s)).

[Cybearg]

Well, one of the games (the pixel bounce one) spits out this error when compiling, even when I set the romsize to 4k (so space isn't an issue):

 

 

--> cycle74_HMCLR f07d

--> WaitForVblankEnd f08f

 

Any ideas why?

[jwierer]

I can look into the vbB inline ASM bug later. For now, I would drop to a command line and make sure the bB and path environment variables are actually pointing to the right location. open cmd and type echo %Path% and then echo %BB% and make sure those are pointing to where you believe they are.

[Cybearg]

It seems correct. Plus, I get the same errors when I compile directly from the command-line as the bB readme instructs, so that issue is separate from VisualbB. The confusing thing, though, is that it worked before.

 

And now DPC+ doesn't compile when it should be able to.

 

Again, can anyone else compile the games I posted? We could confirm whether the issue is my bB or the games I'm compiling if someone else could confirm or deny that they can be compiled using bB 1.1d

Edited March 14, 2013 by Cybearg

[+Gemintronic]

pixelbounce.bas spooged all over itself. Couldn't try omega.bas as I don't have DPC+ going on.

 

What is pb_multisprite.inc? How is it different from the normal multi sprite kernel?

[Cybearg]

pixelbounce.bas spooged all over itself. Couldn't try omega.bas as I don't have DPC+ going on.

I assume that means that it didn't compile. What error(s) did you get?

[+Atarius Maximus]

Omega.bas compiles and runs fine for me. I've never used Visual bB before, I always use windows notepad.

[Cybearg]

Oh, one of the reasons pixel bounce didn't compile for you may be because I forgot one of the necessary files you'll need. Attached.

 

Omega.bas compiles and runs fine for me. I've never used Visual bB before, I always use windows notepad.

I'm not sure if that's a relief or not. I'm glad that it works, but that means that it's some other problem beyond my understanding and control.

 

pixelbounce.bas spooged all over itself. Couldn't try omega.bas as I don't have DPC+ going on.

 

What is pb_multisprite.inc? How is it different from the normal multi sprite kernel?

pb_multisprite.inc defines a different multispriteheader.asm (specifically, pb_multispriteheader.asm) which in turn defines a different multisprite.h (specifically, pb_multisprite.h), which simply remaps a few memory locations so that the missiles and ball are located immediately following the player memory locations. This was necessary in order to set up a loop that would use the missiles, ball, and players all as pixels in a single go. This relates to a thread that I recently made.

pb_multispriteheader.asm

Edited March 14, 2013 by Cybearg

[+Atarius Maximus]

I'm not sure if that's a relief or not. I'm glad that it works, but that means that it's some other problem beyond my understanding and control.

 

I'd suggest testing in a clean folder. Attached is a copy of the DPC folder I'm using (I know I've given it to you before, but I thought it'd be easier to repost it). Run 2600bas game.bas from the command prompt and don't forget to type set bb=c:\folder first.

BB_dpc.zip