Bug Report Thread

[freshbrood]

Duplicate post

Edited June 11, 2018 by freshbrood

[iesposta]

You can't use "pull" as a Label.

It's a bB code word.

push, pull commands transfer and get bytes off a 256 byte stack.

 

My DK Arcade 2600 uses it to change the score to the countdown timer and back to the score by pushing those three bytes and then pulling the back.

 

I'm having problems trying to test a tweaked DPC+ kernel.

It just as weird. Seems the generated assembly contains the word "game" used wrong.

[iesposta]

There are 2 "duplicate label definition"

 

Two Label named: up.

And two Label named: up.1

 

I'm not sure if you can use punctuation in a Label or not.

Having 2 places with the same Label is like having two lines numbered with "100" in the older basic that used line numbers.

[iesposta]

Three last things I saw are:

 

Remove the bank and the temp1 stuff at the beginning.

 

I don't think you can put a REM inside a sprite define.

I think it tries to make anything after "data" part of the data.

Example:

 

data frame30 rem (PUNCH)

%10001000

%10010000

 

The removed white space after a colon separator ":" I believe is causing problems.

Just do a find/replace of ":" and replace with " : "

 

Then do another find/replace of " : " and replace with ": " to tidy things up.

Even the IDE doesn't color the code words unless there is a space after the colon separator.

[freshbrood]

The pull command used to work just fine- but I will change it.

 

Are you sure there are duplicates of up. and up.1? I could not find duplicate labels anywhere.

 

I will review and make all the changes you suggest- but the odd thing is it has worked fine that way for the better part of a year, until recently.

 

Did you actually play the included .bas file with the COLUBK=14 included?

 

 

 

Thank you for your help!

Edited June 11, 2018 by freshbrood

[RevEng]

bB inherits limits for it's labels from dasm symbols. You can't use a period/dot in a bB label name.

 

From RT's bB doc: A label can have any combination of letters, numbers, or underscores, even as the first character.

 

It looks like parts of dasm are interpreting 'up.1' as 'up', and other parts are interpreting 'up.1' as 'up.1'.

 

Your "COLUBK=14" (or any other extra code) happens to cause extra space between a smart-branching location and destination, forcing a jump instead of a branch. When you remove the code and dasm tries to do smart-branching, it seems to be alternating between jumps and branches between passes, which causes the assembly to never be resolvable.

 

If I'm ever in the dasm source again, I'll take a look at better enforcing the symbol-name restriction. But the take-away is, don't use periods in bB labels or variables.

[iesposta]

You are’t using the batari Basic “pull” command, but trying to use the word pull as a code Label.

“pull” is like “goto” as in they are bBasic commands that can’t also be used for Labels.

“pull” is used to move data off of the stack.

You can’t “goto data” or “goto pull”.

 

 

Didn’t play - It did not compile.

I’m using a hacked version of V.34 so I didn’t expect it so compile.

Plus going up to the new version and back means the settings like $Path and the build environment change.

[freshbrood]

Darn. Well so far I've renamed the labels to not include . or other symbols, got rid of pull, put spaces between all :, and removed every rem statement that was next to/on the same line of code. It is still failing to compile, but I will keep trying.

 

I still have a lot of "then label"s I can change to "then goto labels".

 

Also, is if 8>6 or if 8=6 acceptable? or should I also change those to if 8 > 6 or if 8 = 6 with the spaces?

 

I have a lot to clean up.

[iesposta]

Darn. Well so far I've renamed the labels to not include . or other symbols, got rid of pull, put spaces between all :, and removed every rem statement that was next to/on the same line of code. It is still failing to compile, but I will keep trying.

 

I still have a lot of "then label"s I can change to "then goto labels".

 

Also, is if 8>6 or if 8=6 acceptable? or should I also change those to if 8 > 6 or if 8 = 6 with the spaces?

 

I have a lot to clean up.

 

The goto can be dropped if the Label is nearby. Also never dropped in “if then goto else”

Really the only way to know is to start with a program that compiles, and one at a time remove one goto, then see if it compiles or if it compiles and there isn’t any savings.

If there is no ROM savings then bB has essentially put it back in the code which is what “smartbranching on” is for.

This saves bytes, but the label has to be within 128 bytes.

 

I tried dropping a goto around some collision checks.

Even though the goto Label was only 5 lines down, the collision check generated code must have used more than 128 bytes so not only did the compile fail, “smartbranching on” also fails to add the goto branch back in.

 

Also, is 8>6 or 8=6 acceptable?

- Yes

[+Random Terrain]

I put one underscore in front of variable aliases and two underscores in front of labels. Then I don't have to worry if I'm using a keyword by mistake and I don't have to worry if a label has the same name as a variable alias. I'll add a comment on the bB page about not using a period in label and variable names.

 

Can somebody explain things like "const frame10lo = #<frame10" to me? Is that valid? What does the pound sign and less than sign do?

[iesposta]

...

 

Can somebody explain things like "const frame10lo = #<frame10" to me? Is that valid? What does the pound sign and less than sign do?

That is code for moving around directly into "parts of the defined data" for the Player0 or Player1 sprites.

You can't do that in DPC+ games because the 4K graphic ROM data for Players, etc., is copied into Harmony RAM, and the DPC+ chip gives the data from that RAM back to the 6502.

[freshbrood]

I got it to work! Thank you so much! Yeah for my purposes the DPC+ kernel was actually too limiting when it came to multiplying sprites (for my Mortal Kombat clone) using the const. I wish you guys could see it- I think you'd be rather impressed if I do say so myself. I have made every effort to make it as "pixel perfect" as possible using vbb.

[+Random Terrain]

Since I was already in the middle of it, I'm doing my own fix up of your program and I've come across more than one place where you use OR twice in the same if-then. That is not allowed according to the bB page in the Did You Know box. You are allowed only one OR for each if…then statement.

[freshbrood]

Since I was already in the middle of it, I'm doing my own fix up of your program and I've come across more than one place where you use OR twice in the same if-then. That is not allowed according to the bB page in the Did You Know box. You are allowed only one OR for each if…then statement.

Wow thank you RT! My cleaned up version seems to be running and allowing me to edit it just fine so far, so I will take your version and make a hybrid when you're done.

 

Yes I was aware of that, but for some reason it was working so I just ran with it. I've also noticed that you can string a lot of "IFs" together if they all continue to be true, they will just keep on going on to the next one- up until about 12 or so commands I think.. Then it gets to be too much. I am a total noob, so everything I've done has been trial and error. This is the first program I've ever written outside of Megazeux. (an ASCI basic language)

 

But I hope you will appreciate my ingenuity with the graphics and what I've done so far. I think it's going rather well- provided I don't spaghetti up the code to the point of confusion. I also don't like using DEF's.

 

The way my mind works I just find it more confusing trying to attribute multiple words to the same variable.

[+Random Terrain]

I think I fixed everything:

 

freshbroods_ninja_kombat_2018y_06m_11d_0157t.bas [removed by request]

 

freshbroods_ninja_kombat_2018y_06m_11d_0157t.bin [removed by request]

 

You might want to compare it with your your fixed version or just use mine if you think I fixed more things.

 

 

I see that the screen flashes to a different color when the fire button is pressed. I posted this in another thread about that subject:

 

Modern consoles have warnings which say that exposure to certain patterns or backgrounds on a television screen may trigger epileptic seizures or blackouts in some people and these conditions may trigger previously undetected epileptic symptoms or seizures in persons who have no history of prior seizures or epilepsy. When in doubt, don't quickly change the color of large sections of the screen.

 

Besides that, it can be irritating for people who just have sensitive eyes:

 

randomterrain.com/atari-2600-memories-game-design-guidelines.html#no_flashing

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#ex_pulsation_examples

[+Random Terrain]

Yes I was aware of that, but for some reason it was working so I just ran with it.

Some things can seem to work, but then we'll end up getting some weird unrelated error down the line because we added one more questionable thing that was too much for bB to take. Since the weird error is caused by a couple of unrelated, almost undetectable things, it can cause us to want to rip out our hair or punch ourselves in the face. To avoid self-induced bruises and loss of hair, it's better to do what the bB page says.

[freshbrood]

Thank you. The flash on fire is just for debugging purposes- that tells me when actual damage is being caused, not just the animation time (which if you'll notice is a bit longer than the flash) That will be long gone before the final release. It helps me know if the non graphical code (like counters and such) are actually being activated in those seconds. As a noob I still don't really grasp all the features of the f1 in Stella, so I just insert a simple COLUBK= in the part of the code I'm trying to understand. Definitely not part of the game.

Edited June 11, 2018 by freshbrood

[+Random Terrain]

Thank you for your response. I'm not sure how to disable Syntax Checking- it seems enabled by default and I can't figure out how to turn it off.

I missed that post before. It's basically in the center of the Settings page:

 

randomterrain.com/atari-2600-memories-batari-basic-vbb.html#settings

 

[+Karl G]

The multisprite kernel seems to have a problem with the "noscore" option - the timing seems to be off when the score is disabled. I confirmed this with a simple program that just does a drawscreen loop as well as the 9 objects example on RT's site.

 

multi.bas

 

multi.bas.bin

 

[+Karl G]

The DPC+ kernel goes over the 262 scanline count if the score is disabled, and a minikernel is enabled. It seems to go over by the number of scanlines used by the minikernel in question. Here is an example with the 6lives minikernel.

 

dpcmini.bas

 

dpcmini.bas.bin

 

[freshbrood]

I have transfered certain .bas files from a Windows 7 pc to a Windows 10 tablet with SD memory, not a physical hard drive, using VBB.

 

The same .bas files will play perfectly on the Windows 10 tablet, but when I re-save them through VBB, some files will simply fail to compile. It seems that SAVING them causes some error. Others will allow me to edit and save them, others will not. But all will play fine via Stella BEFORE I save them on my Win 10 machine.

 

Is anyone familiar with this issue, or why this might be happening? Again- I can transfer them from Win 7 to Win 10, open them up in VBB on the Win 10 machine, play them on the Win 10 machine, but once I SAVE it via VBB on the Win 10 machine (even if no edits were made) they somehow get corrupted during the save process.

 

Sometimes they claim duplicate labels or misplaced "end" as well, but they are not. I have disabled bblint.

Edited September 6, 2018 by freshbrood

[+Random Terrain]

I have transfered certain .bas files from a Windows 7 pc to a Windows 10 tablet with SD memory, not a physical hard drive, using VBB.

 

The same .bas files will play perfectly on the Windows 10 tablet, but when I re-save them, some files will simply fail to compile. It seems that SAVING them causes some error. Others will allow me to edit and save them, others will not. But all will play fine via Stella BEFORE I save them on my Win 10 machine.

 

Is anyone familiar with this issue, or why this might be happening? Again- I can transfer them from Win 7 to Win 10, open them up in VBB on the Win 10 machine, play them on the Win 10 machine, but once I SAVE it via VBB on the Win 10 machine (even if no edits were made) they somehow get corrupted during the save process.

 

Sometimes they claim duplicate labels or misplaced "end" as well, but they are not. I have disabled bblint.

 

Do you have the latest version of bblint? And Does Windows 10 let you run a program as if you are using an older version of Windows?

[freshbrood]

I have the latest bblint and I've checked Win 7 compatibility mode. For some reason it just gets corrupted when saved on my Win 10 computer.

[+Random Terrain]

I have the latest bblint and I've checked Win 7 compatibility mode. For some reason it just gets corrupted when saved on my Win 10 computer.

 

I wonder if any of these posts would be helpful:

 

openoffice.org/en/forum/viewtopic.php?f=5&t=91252#p432272

[Coolcrab]

Not sure if this is a bug, but you can't combine pfread with anything else in an if. It would be really nice if you could say 'if pfread(x,y) && pfread(z,w) then bla' or combine it with anything else.

 

It can be solved by adding more if statements but that eats ROM.