Serious problems after upgrade Batari Basic to 1.6

[Evilarinho]

After I upgraded to Batari Basic 1.6, I started having problems in all my DPC+ projects (I don't know if this happens in other kernels)

 

1) most don't compile anymore, they show a lack of memory in bank 1

 

2) the ones that compile, are having serious problems in the playfield colors. The lines are all misaligned.
 

Downgrading to version 1.5, everything goes back to normal!

Edited June 29, 2022 by Evilarinho

[+splendidnut]

Taking a guess here, but you most likely have been affected by these changes:

 

Quote

• add QT multiplexer support to standard, multisprite and DPC+ kernels. (thx kdgarris!)
• DPC+ priming reads (thx Lillapojkenpåön!)

 

It appears that the following fix has been folded into the kernel itself, so you shouldn't need to do any DPC+ priming reads anymore:

 

 

[+Karl G]

I tested the only DPC+ bB program I had handy, and didn't notice any issues. The QuadTari support in the kernel is only used if defined, and is only a couple of bytes even so. Do you have any sample code that can demonstrate this issue?

[Evilarinho]

Sure.

 

 

 

Now an example of the playfield colors problem in my game Escape from the Castle (final build)

Now an example of the playfield colors problem in my game Escape from the Castle (final build):

 

[Fort Apocalypse]

Bugs happen, and I'm really happy that bB continues to evolve and get better!

 

On a tangent:

 

I'm wondering, whether it might be confusing to release a minor version that has changes that could add to the assembly code, putting it over the limit. Even though I'm an amateur at 2600 dev, I know that bB programmers can tend to put as much as they can possibly fit into their game, and something like this could cause people to have to remove a part of their game, just because it was fixing something that might not matter in their game. (I'm aware of the fix mentioned above, and some may argue that that code should always be in a DPC+ game, but I don't think it has to, necessarily, and not in the place that it may be being done automatically now in 1.6?)

 

I don't think that this should prohibit those sorts of changes from going in, but I wonder if targeting such changes for a major version would be more compatible with semantic versioning, which a large portion of developers have been using for the past decade (though maybe not in their bB games). There is some leeway for interpretation in semantic versioning, but in the case of bB, I'd say anything that may prevent a game to compile that previously would've compiled in a previous stable minor version of that major version should have to be turned on via a flag of some sort, if it's being fixed/added in a minor version. However, such a change could be immediately turned on and targeted as a default in the next major version?

 

That said, though- this is a minor concern. Double entendre for the win. Thanks for all the fixes!

Edited June 29, 2022 by Fort Apocalypse

[+splendidnut]

TLDR;  Always be wary of updates... The evil internet has trained you to always update, which is not necessarily a good thing.

 

----

 

Part of the problem here is that bBasic is really a combination of a compiler and 2600-game oriented framework code.  So there's always going to be potential for the ROM space available to the user to change due to that.

 

The best way to mitigate upgrade issues is to always track what compiler version your code currently uses and assume a new compiler (and/or library) version may break things.  Always be prepared for that.  The best case scenario for a compiler update is that everything works as expected and you don't need to update/change anything.  The worst case is that you either have to change some code, or you just continue to stick with the compiler version that the code compiles with.

 

That's just how these things work.  This is what the badly named term "code rot" is actually referring to... not that the code has necessarily gone bad... but that it's limited to the environment in which it originally compiled (example: ID's Wolf3D compiles almost without issue in Borland C++ v3.0/3.1, but would need code changes to compile in anything else).  If you ever look at most C code, it's usually littered with #ifdef's to handle different C compilers/versions.

 

In the end, you have to do what works for you.  @Evilarinho stuff compiles in bBasic v1.5... he can stick with that for now if he doesn't want to be blocked by trying to figure out how to get his code to compile in bBasic v1.6.  It's good that this issue has come to light, because this could very well be a bug in the compiler.  Or it could be that some of his code needs to change due to the framework changes with DPC+ priming reads and/or the QT multiplexer.

 

---

 

It's okay to not use the latest and greatest... I'm currently using Windows 7 PC here. 

 

[Fort Apocalypse]

15 minutes ago, splendidnut said:

TLDR;  Always be wary of updates... The evil internet has trained you to always update, which is not necessarily a good thing.

For sure! But in the past, Fred added code into bB that allowed 1.0 to be backwards-compatible with pre-1.0 by adding some code in to target the previous version (just as a historical example).

 

I can see a lot fit into 1.6. Good changes are all good! But, making changes that add asm code optional would allow things to keep working without hitting a wall and having to backrev, so that people can use 1.6 for newer stuff with the newer features and fixes as well as with the older stuff and older bB code. It's more work, so if there isn't time, that's fine, but if there's time, it'd be good; then those sorts of things could be made default in the next major version to clean-up and remove the options.

 

The most important thing to get from what I'm trying to say is that adding asm code and putting it into places it wasn't before is not free. Timing and size are important.

Edited June 29, 2022 by Fort Apocalypse

[+splendidnut]

Sure, that ultimately requires more effort which can be done.  BUT:

10 minutes ago, Fort Apocalypse said:

the next major version to clean-up and remove the options.

You're back in the same boat again with compiler update suddenly breaking code.

[+splendidnut]

13 minutes ago, Fort Apocalypse said:

The most important thing to get from what I'm trying to say is that adding asm code and putting it into places it wasn't before is not free. Timing and size are important.

That is Atari 2600 programming in a nut shell.  Timing and size are very important.  If you're not prepared to handle that, it might not be good to target a system in which that is very important.  Blunt but true.

[+splendidnut]

29 minutes ago, splendidnut said:

@Evilarinho stuff compiles in bBasic v1.5... he can stick with that for now if he doesn't want to be blocked by trying to figure out how to get his code to compile in bBasic v1.6.

This is my main point.  There are two options here.  The programmer's most important person to serve is themselves.  They need to decide what to do to accomplish what they want to get done.

 

ADDENDUM:  It's been a rough week and I'm a bit spicy right now.  Please take that into consideration before you take offense.

[Fort Apocalypse]

Just now, splendidnut said:

This is my main point.  There are two options here.  The programmer's most important person to serve is themselves.  They need to decide what to do to accomplish what they want to get done.

I get that I need to toughen up and be ready for breaking changes in each bB release, but if people are told not to upgrade, you'll have users in all different versions of the language, which is worse.

 

It's fine. I get it. I was trying to speak up for the users of the language, though. I was a lead/mentor for a few dev teams in my past, and I know that people, whether they are developing games in bB or merging patches and writing fixes and features for bB itself both need to do their thing, make mistakes, and learn.

[+splendidnut]

Yeah.  I totally get that. I come from the other side of the fence where at work I'm having to support severally outdated things because the middle-man users don't understand what the word 'deprecated' means (more likely it's just not high enough of a priority for them).

 

There are many things that bBasic could be better at (obscure errors... I'm looking at you)... but as I understand it, that would require a lot of effort to do.  And at the end of the day, it's spare-time open source.  You kinda get what you get.

 

As I said:  Always be wary of updates.  Don't be afraid to update, but also don't be surprised if there are issues.... Try and be prepared. 

 

[RevEng]

I updated the bug report thread with the priming read issue, and have reverted that code in the github master. New release to follow this weekend'ish.

 

In terms of tight programs not compiling... historically the bB kernel has always fluctuated in size due to fixes, and this has always been something to watch for when you upgrade.

 

2 hours ago, Fort Apocalypse said:

The most important thing to get from what I'm trying to say is that adding asm code and putting it into places it wasn't before is not free. Timing and size are important.

When adding new features? absolutely agree. When fixing bugs? nope. I'm not hanging on to old bugs and adding options to use that old buggy code. There's a much easier way for the user to deal with it - keep the old compiler with the bugs, or scrounge a few bytes to accommodate the updated kernel/library. I don't think that's unreasonable.

 

[Fort Apocalypse]

6 hours ago, RevEng said:

I updated the bug report thread with the priming read issue, and have reverted that code in the github master. New release to follow this weekend'ish.

 

In terms of tight programs not compiling... historically the bB kernel has always fluctuated in size due to fixes, and this has always been something to watch for when you upgrade.

 

When adding new features? absolutely agree. When fixing bugs? nope. I'm not hanging on to old bugs and adding options to use that old buggy code. There's a much easier way for the user to deal with it - keep the old compiler with the bugs, or scrounge a few bytes to accommodate the updated kernel/library. I don't think that's unreasonable.

 

Let's say there was a bug that really adversely affected very few people, but the asm required to be included in each game compiled by the new version of bB caused most games already in development with the previous version to break, and caused some bB developers to have to remove features/functionality from the game just because of that fix.

 

The OP said "After I upgraded to Batari Basic 1.6, I started having problems in all my DPC+ projects".

 

I wanted to make the point that fixing bugs is good, but, if you want to fix bugs, maybe fixing them in a way that causes code to fail to compile in a way that causes most bB developers to have to rework their code into different banks and perhaps lose functionality due to timing issues or lack of space is something that should be fixed in a major version rather than a minor version, since minor versions, to many, don't indicate a backwards-incompatible breaking change. I'm not trying to high-horse, though; this is all you guys' effort, and I appreciate all of the effort you've put into it.

 

I just know now to not upgrade for anything I'm working on currently that I'd like to finish without planning on a good possibility breaking changes. I'm only an amateur with a lot of irons sitting by the fire, so that means I probably won't upgrade to 1.6 anytime soon. Just to note: in all other languages I've worked in, minor version changes were never breaking changes, and I've worked in a number of them.

 

Edited June 30, 2022 by Fort Apocalypse

[RevEng]

Modern software practises are great on the 6502, until they're not. semantic versioning, for bB at least, is one for "not" category. I don't have a nice abstracted API or ABI that I can promise not to change - yes, the language interface can stay the same, and did stay the same for this same release that broke all of OP's games. Practically speaking, the API is also the rom footprint, and cycle availability. Since bB also has to live in that rom footprint and use cycles, I can't promise that any trivial bB change won't break some game. So each release would be a major version bump anyway.

 

[+Gemintronic]

Might sound like a raging fanboy but I've never encountered the problem with newer versions suddenly taking up too much space at compile time.  Most of the time I just brazenly overwrite the files in the bB directory with newer versions mid project.

 

For special cases like this one could dump the 1.5 includes into the project folder so it compiles with the working versions?

 

 

[RevEng]

6 hours ago, Gemintronic said:

Might sound like a raging fanboy but I've never encountered the problem with newer versions suddenly taking up too much space at compile time.  Most of the time I just brazenly overwrite the files in the bB directory with newer versions mid project.

 

For special cases like this one could dump the 1.5 includes into the project folder so it compiles with the working versions?

The DPC update introduced 6 extra bytes, but that can turn into more depending on the placement of certain statements in your code. Kernel-specific data like player graphics, playfield graphics, etc. all have requirements to not cross a memory page during access, so those 6 bytes probably cost OP more than 6 bytes. When you're close to stuffed these things happen - I'm sure you've run into the situation in a tight rom where you add one line of code in just the right place, and all of a sudden an alignment avalanche steals a hundred bytes of space and breaks the compile. Jenga!

 

Replacing the DPC+ include file would have worked as a downgrade here, but I can't recommend doing this generally, without asking first anyway. Some updates require changes to both the compiler and one or more includes files.