Visual bB Committed Suicide

[+Gemintronic]

Probably my bad. If he's got proper GOSUBs leading to proper RETURNs he should be okay. Otherwise it's just like C: it'll let you do screwy things and it will seem OK until it isn't.

 

Assuming his bB is correct that leaves only the inline assembly. Stuff like:

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

 

pop: goto badmove

asm

playerDot
.byte %1

end

[Cybearg]

The cycle74_HMCLR is a result of code changing during dasm passes, causing the code labels to shift and be different between passes. (which dasm can't handle)

 

The cause of this shifting is the changes you made to multisprite.h when you made pb_multisprite.h. You made some labels equate to other labels. e.g. P0Top = temp5

 

Use actual values, and your problem will go away.

Huh, odd. I didn't make those changes.

 

Here's what I did:

 

missile0x = $80
missile1x = $81
ballx = $82

; multisprite stuff below - 5 bytes each starting with spritex

SpriteIndex = $83

player0x = $84
NewSpriteX = $85 ; X position
player1x = $85
player2x = $86
player3x = $87
player4x = $88
player5x = $89

objecty = $8A
missile0y = $8A
missile1y = $8B
bally = $8C

player0y = $8D
NewSpriteY = $8E ; Y position
player1y = $8E
player2y = $8F
player3y = $90
player4y = $91
player5y = $92

 

to

 

; multisprite stuff below - 5 bytes each starting with spritex

SpriteIndex = $80

player0x = $81
NewSpriteX = $82 ; X position
player1x = $82
player2x = $83
player3x = $84
player4x = $85
player5x = $86
missile1x = $87
ballx = $88
missile0x = $89

player0y = $8A
objecty = $8A
NewSpriteY = $8B ; Y position
player1y = $8B
player2y = $8C
player3y = $8D
player4y = $8E
player5y = $8F
missile1y = $90
bally = $91
missile0y = $92

 

As you can see, I realigned the missiles and ball so that I could reference player1y[0] - player1y[7] using a for loop.

 

I never changed P0Top to point to a variable rather than a memory address, because I never modified that far down, so I wonder how that happened?

 

You're absolutely right, though. Once I copied those values over from multisprite.h, it compiles again without an error. Weird.

 

That just leaves the problems with DPC+...

[+Gemintronic]

After I dumped the files from BB_dpc.zip into my bB folder omega.bas compiled just fine.

 

[3/14/2013 4:00:47 PM] bblint found the following errors in omega.bas

warning(): Found 33 commands that use end, and 30 "end" commands.

 

That bit of output is probably bblint not understanding something about the DPC+ stuff. The actual ROM runs fine.

[Cybearg]

I get those lack of "end" command errors all the time. Kind of annoying, but not problematic, so far as I can see.

 

I wish I was having as much luck with it as you are, loon. I get the following error when I compile (and this is using the latest version of bB, both if I use the nice package Atarius gave me or if I use the fresh install I showed in the video on the first page of this thread):

 

 

[3/14/2013 3:02:51 PM] bblint found the following errors in omega.bas

warning(): Found 33 commands that use end, and 30 "end" commands.

2600 Basic compilation completed.

free ram: 9

DPC free RAM=

bytes of ROM space left in bank 1

bytes of ROM space left in bank 2

bytes of ROM space left in bank 3

bytes of ROM space left in bank 4

bytes of ROM space left in bank 5

bytes of ROM space left in bank 6

bytes of ROM space left in graphics bank

free ram: 9

DPC free RAM= 603

--> repo 1ab2

[Cybearg]

It looks like someone else had a similar problem, though I'm not clear on what he did to resolve it. If anyone has any ideas, I'm still stumped on this one. And I still have no idea what caused whatever-it-was to break in the first place. :s

Edited March 14, 2013 by Cybearg

[Cybearg]

I tried sharing the drive with my batariBasic stuff on it and seeing if things would compile on a different computer.

 

Since the computer hadn't run VisualbB before, I had to set up Stella's location, bB's location, and the project's location. I used the same relative paths as I used on my main computer (except that I copied Stella over to VbB's main directory to use it from there instead).

 

The result: the DPC+ Omega game DOES compile, albeit with the same warning listed above (repo 1ab2) and without any of the remaining ROM sizes being reported--they're all blank. The game compiles and runs, though. This other computer is a 64-bit Windows 7 machine, just like the one I normally work on.

 

So are there some kind of registry-based values for bB or VisualbB which could have become corrupted, preventing me from compiling DPC+ on one computer while the same files work fine on a different computer?

 

And what is this mysterious -> rep 1ab2 and how can I get the remaining ROM space to be reported again?

[jwierer]

The vbB settings are in HLKM\Software\VisualbB, but the only thing that would have an effect is the compiler path.

[+Atarius Maximus]

This isn't going to be helpful to you at all, but I generally don't see the remaining ROM space reported when I compile with DPC. It says "<blank> bytes free" for each bank. I assumed it was a bug that would be worked out in the future...

[Cybearg]

This isn't going to be helpful to you at all, but I generally don't see the remaining ROM space reported when I compile with DPC. It says "<blank> bytes free" for each bank. I assumed it was a bug that would be worked out in the future...

Oh... Well then how can you tell where you are?

 

Are there any registry options that bB sets that could be mucking with this computer?

[+Atarius Maximus]

Oh... Well then how can you tell where you are?

 

Are there any registry options that bB sets that could be mucking with this computer?

Since I haven't made an actual game with DPC yet I didn't really worry about it. My demos have all been very small. bB doesn't make any registry changes at all, but Visual bB likely does. I know I mentioned it before, but I don't use Visual bB and I don't know what changes it might make. It's a great tool and works very well, it's just not something I'm interested in.

[+Atarius Maximus]

A quick note to jwierer since I'm sure you're reading this thread, I mean no disrespect to your efforts. Visual batari basic is a really cool tool and it's helped lots of people break in to bB. I'm just an old school "must use a text editor" kind of guy.

[Cybearg]

VisualbB is basically just a text editor except it has nice tools included for making playfields and sprites quickly and intuitively, as opposed to trying to type out an upside-down sprite with your keyboard.

[+Atarius Maximus]

VisualbB is basically just a text editor except it has nice tools included for making playfields and sprites quickly and intuitively, as opposed to trying to type out an upside-down sprite with your keyboard.

Yeah, I know. I've installed it and played around with it, just never used it for a project. I've been in IT for a few decades now, and I'd really rather use vi on my UNIX servers than windows notepad, but I'm stuck with windows laptops at work and at home so notepad is my 2nd favorite choice. I'm so used to a simple text editor that I feel more productive using one. That's why all my source code posts are in .txt format. I'm a masochistic programmer.

[Cybearg]

But, getting back to the problem, if I've replaced bB and VisualbB and I can confirm that both work on a different system, what can I do to fix their DPC+ compatibility for this system?

[+Random Terrain]

A quick note to jwierer since I'm sure you're reading this thread, I mean no disrespect to your efforts. Visual batari basic is a really cool tool and it's helped lots of people break in to bB. I'm just an old school "must use a text editor" kind of guy.

 

You can disable syntax checking and color coding if you want to use VbB like a plain old text editor. Unlike with a plain text editor, you can do some cool stuff from the right-click menu. For example, you can highlight a label name used with a goto or gosub and instantly jump to where the actual label is. You can't do that with a plain text editor and it can save you a lot of time when working on a large program or working on a program made by somebody else. Click anywhere in a program and select Identify Current Bank and VbB will tell you which bank you're in (another thing a plain text editor can't do). You can also highlight lines of code and make them all REM statements or un-REM them. Highlight lines of data and instantly reverse their order. You can also force minimum spacing that you've previously set up on the settings page (I use 3 spaces).

 

When you use VbB, you can also access the various other tools that VbB has like the Sprite Editor, Playfield Editor, Music and Sound Editor, Score Editor, Title Screen Editor, Graphics Converter and so on.

[jwierer]

A quick note to jwierer since I'm sure you're reading this thread, I mean no disrespect to your efforts. Visual batari basic is a really cool tool and it's helped lots of people break in to bB. I'm just an old school "must use a text editor" kind of guy.

No offense taken

 

-Jeff

[+Gemintronic]

No offense taken

 

-Jeff

 

I fully blame VisualbB for allowing me to use batari BASIC. Without a proper, robust IDE I would have never made a game signed by Freddy Krueger or spoken at an Arcade Expo or get my games published by an indie comic book artist.

 

This is not to dispute Atarius Maximus's viewpoint. I fully believe NOTEPAD.EXE is the best web page editor ever.

[Cybearg]

Still no suggestions?

 

I tried deleting every VisualbB registry file I could find, then re-ran and re-configured VbB. I've attached zips which include my bB folder/assember and my VbB folder/Stella, along with a registry file for my main VbB registry. Perhaps someone can find something amiss here somewhere.

 

Keep in mind: The problem is that I am unable to compile ANY DPC+ game. I've tried Food Fight, an example Atarius posted in his "Getting Started with DPC+" thread, and my own game, posted earlier here (which Atarius and others have confirmed DOES compile correctly on their systems).

 

The complication is that, using the exact same files, I AM able to compile DPC+ on another machine, but I want to be able to compile it on THIS machine because THIS is my work station. Also keep in mind that DPC+ WAS able to compile on this machine, up until the crash I described in the original post of this thread.

 

Does anyone have any idea what could be wrong? Does anyone see something wrong with my registry or files? Please, please help!

bbDPC.zip

vbB.zip

[+Gemintronic]

After I dumped the BB_dpc.zip into my BatariBASIC folder and then RevEngs new bblint executable omega.bas had ZERO errors.

[Cybearg]

After I dumped the BB_dpc.zip into my BatariBASIC folder and then RevEngs new bblint executable omega.bas had ZERO errors.

Did it ever not work for you?

 

For me, DPC+ games DO compile, but they don't report the size, I get the notice of:

 

--> repo 1ab2

 

... And Stella opens a ROM that's just noise and garbled colors on the screen.

Edited March 15, 2013 by Cybearg

[+Gemintronic]

Deez errors

http://www.atariage.com/forums/topic/209985-visual-bb-committed-suicide/page__st__50#entry2715826

 

RevEng was Ninja quick and updated bblint, though.

[iesposta]

 

 

 

 

I get those lack of "end" command errors all the time. Kind of annoying, but not problematic, so far as I can see.

 

I wish I was having as much luck with it as you are, loon. I get the following error when I compile (and this is using the latest version of bB, both if I use the nice package Atarius gave me or if I use the fresh install I showed in the video on the first page of this thread):

 

 

[3/14/2013 3:02:51 PM] bblint found the following errors in omega.bas

warning(): Found 33 commands that use end, and 30 "end" commands.

2600 Basic compilation completed.

free ram: 9

DPC free RAM=

bytes of ROM space left in bank 1

bytes of ROM space left in bank 2

bytes of ROM space left in bank 3

bytes of ROM space left in bank 4

bytes of ROM space left in bank 5

bytes of ROM space left in bank 6

bytes of ROM space left in graphics bank

free ram: 9

DPC free RAM= 603

--> repo 1ab2

 

I have run into that blankness before. It was from something out of order or missing in Bank 1.

I said before that I can define one variable too many with space left in Bank 1 and get this.

I can leave out set optimisation inlinerand or something and I get this.

It does compile and run fine - I don't have your corruption problem - but shows blank.

This must be some kind of bug.

Example:

 rem batari Basic Program

 rem created 12/22/2011 9:06:04 PM by Visual bB Version 1.0.0.565

 rem *****************************************************

 

 bank 1

 

 temp1 = temp1

 

 

 set tv ntsc

 set kernel DPC+

 set smartbranching on

 set optimization inlinerand

 set kernel_options collision(playfield,player1) 

 const font=alarmclock

 

 

 dim xp= a.b

 xp=30.0

 

 dim yp=c.d

 yp=37.0

 

 scorecolors:

 $98

 $96

 $98

 $96

 $98

 $96

 $98

 $96

end

 

 score = 123456

 

 goto MAIN bank2

 

Add another variable and blank.

Add another variable and blank.

[jwierer]

Still no suggestions?

 

I tried deleting every VisualbB registry file I could find, then re-ran and re-configured VbB. I've attached zips which include my bB folder/assember and my VbB folder/Stella, along with a registry file for my main VbB registry. Perhaps someone can find something amiss here somewhere.

 

Keep in mind: The problem is that I am unable to compile ANY DPC+ game. I've tried Food Fight, an example Atarius posted in his "Getting Started with DPC+" thread, and my own game, posted earlier here (which Atarius and others have confirmed DOES compile correctly on their systems).

 

The complication is that, using the exact same files, I AM able to compile DPC+ on another machine, but I want to be able to compile it on THIS machine because THIS is my work station. Also keep in mind that DPC+ WAS able to compile on this machine, up until the crash I described in the original post of this thread.

 

Does anyone have any idea what could be wrong? Does anyone see something wrong with my registry or files? Please, please help!

Still sounds like it's actually not executing the right compiler. Have you tried deleting, moving, or archiving any other version of the compiler on your workstation? That would at least eliminate the case that a different compiler running. The vbB settings won't have any effect on running the compiler from the commandline so don't kill yourself messing with those.

 

-Jeff

[Cybearg]

Still sounds like it's actually not executing the right compiler. Have you tried deleting, moving, or archiving any other version of the compiler on your workstation? That would at least eliminate the case that a different compiler running. The vbB settings won't have any effect on running the compiler from the commandline so don't kill yourself messing with those.

 

-Jeff

As per your suggestion, I deleted all but the single version of bB that I want to use. Sadly, I get the same issue.

[+Gemintronic]

You sound technically savvy, Cybearg. Back up our stuff and install a fresh copy of Windows. Pending that you can fudge it by running bB in XP compatibility mode which is really a virtual machine. Either way guarantees zero software corruption from the previous install. This could be the first telltale sign your OS is going south.