What's the appeal of bB programming?

[+thegoldenband]

I guess what I was originally asking with this thread was does a giant brick wall exist between bB homebrews and assembler homebrews in which case I'll opt out rather than chase down a heavy sixer. Since the answer is yes an impenetrable divide exists and there's no way to change the programming to include us FB2 users, at least now I have my answer.

 

Wait, I think something's been overlooked: are you asking if there's something about bB games which will keep them from working on your Flashback 2? As far as I know, there's no intrinsic limitation that keeps bB games from working on any hardware configuration.

 

I'm no expert, but I'm pretty sure that bB doesn't rely on any of the illegal opcodes and other things that freak out the Flashback 2. Assuming that's correct -- I can't imagine that the language's primary functions would depend on anything that doesn't work on the 7800 or certain Atari Jrs. -- then the "giant brick wall" doesn't exist, actually. You can use tons of assembly code in a bB program, or you can potentially hand-edit the assembly code that bB puts out before compilation.

 

More generally speaking, the nature of bB is that anything it puts out will be a subset of what's possible in ASM. So I'm guessing that ASM games are actually capable of making the FB2 fail in all kinds of interesting ways that bB doesn't (directly) implement!

[SeaGtGruff]

I'm no expert, but I'm pretty sure that bB doesn't rely on any of the illegal opcodes and other things that freak out the Flashback 2.

I think bB does use a few "illegal" opcodes, but as far as I know, they're "stable" opcodes like "LAX" that should work as expected on real hardware or in emulation.

[ComputerSpaceFan]

Wait, I think something's been overlooked: are you asking if there's something about bB games which will keep them from working on your Flashback 2? As far as I know, there's no intrinsic limitation that keeps bB games from working on any hardware configuration.

 

The links I gave above for Frantic and Seaweed Assualt have quotes from the developers telling me bB uses a different kernel and that's why I can't get those games to run on my FB2. Are those folks mistaken? i would love to hope so but if they are right and I am wrong, it's fine, I do have tons of excellent homebrews I can enjoy anyway.

[RevEng]

I think bB does use a few "illegal" opcodes, but as far as I know, they're "stable" opcodes like "LAX" that should work as expected on real hardware or in emulation.

 

"DCP" is another.

 

FB2 doesn't implement all (any?) of the illegal opcodes. Batari has confirmed this is the reason bB games don't run on FB2.

[SeaGtGruff]

I think bB does use a few "illegal" opcodes, but as far as I know, they're "stable" opcodes like "LAX" that should work as expected on real hardware or in emulation.

 

"DCP" is another.

 

FB2 doesn't implement all (any?) of the illegal opcodes. Batari has confirmed this is the reason bB games don't run on FB2.

In that case, it should be possible to create no-illegal-opcode bB programs by modifying the include files-- which might create timing issues that would necessitate eliminating a few things from the kernel. In other words, there's no reason bB programs can't be written so they'll work on a FB2.

[+batari]

The FB2 has many incompatibilites, but bB itself isn't necessarily incompatible. It's that some bB kernels exploit some of these incompatibilities, but not all do. For example, a game using the multisprite kernel might work.

 

bB's standard kernel uses the SBX instruction that FB2s don't like. In some cases, existing games using this kernel can be hacked to run on FB2 (not all can, just those that do not use kernel options.) I did this on request for one homebrew author.

 

DPC+ kernels don't work because of the same reason that actual SARA chip games don't work. There is no hope here, and this particular FB2 limitation is the most annoying IMO (doing this right would have been trivial and there is no technical reason that this should have been done the way it was.)

 

I am in agreement with others that we shouldn't limit our programming to support incompatible consoles. If we can make it work, great! But if we can't, we shouldn't lose sleep over it.

[trent]

I had a look at bB and decided to do my tinkering in assembly. I think I'd warm up to to bB a bit more if came with source code.

Well, depending on what you mean by "source code," it sort of does. That is, the include files are there for you to inspect and decipher the assembly code.

 

The source code for the *compiler* is another matter-- the source code for the earlier versions of bB was available, but I'm not sure if Fred has posted the source code for the later versions.

 

Yeah, the compiler. Mainly because recent versions don't seem to include a Linux version.

[RevEng]

Yeah, the compiler. Mainly because recent versions don't seem to include a Linux version.

 

If you have gcc installed, just type "make" in the bB directory (or the "source" directory for older versions) and you're set.

 

I use Ubuntu, and have been able to run all of the recent versions.

[RevEng]

The links I gave above for Frantic and Seaweed Assualt have quotes from the developers telling me bB uses a different kernel and that's why I can't get those games to run on my FB2.

 

It's worth mentioning that Frantic isn't bB, it's asm. But it does use DPC+ hardware, which is why it's not working on FB2.

 

I believe we'll start to see more and more homebrews that use DPC+. (or plain old DPC, like the upcoming Chetiry.)

[+stephena]

This bugs me. The whole notion of "changing programming" to include FB2 users.

Should we also change our programming so our games run on that other imperfect '2600 emulation (the multiple computer thing)?

IMHO it's the FB2 which should be fixed so that it's truly compatible, not the other way around.

 

I agree. If a game looks/sounds good in Stella but fails on real hardware, then that is a failing of Stella, not the programming of the ROM. The original console is always the baseline; everything else must cater to it, warts and all.

[Pioneer4x4]

To the, the appeal of bB is I can now put my ideas on carts and putz and play without spending tons of time that I am not willing to invest to do it via asm. I believe I could do it, but I just don't want to. And now, there is no need to (for me) and with the ability to use pure asm code and let bB handle screen updates and everything, it is a dream come true. I had to deliberately cause problems in my code to have it fail on real hardware, that was nice!

[PFL]

I'm glad that bB exists. Anything that lowers the entry level barriers into coding for the 2600 is a boon in my opinion. If space is an issue the OP could get a Jr and do an AV mod or simply grab a cheap AV cable for the SNES. That seems far easier than to hope (vainly) that coders are going to spend tons more time learning and developing ASM just so that games can run on a glorified toy. The fact the FB2 can be hacked is cool but it shouldn't be seen as a full 2600 replacement... I hope this doesn't sound to ranty or patronising - that's not my intention. I'm just not sure why the OP is so stuck on a FB2...

[ComputerSpaceFan]

I hope this doesn't sound to ranty or patronising - that's not my intention. I'm just not sure why the OP is so stuck on a FB2...

 

No worries there, and I totally understand now, thanks to this thread, why so many homebrewers are going the bB route. I can well imagine it must be a heck of a lot easier to program using bB than old school assembler coding. It's just unfortunate that FB2 gets left in the dust when home brews come out this way, not blaming anyone here, I just see now why it is the reality.

 

As to why I'm stuck on a FB2 compared to getting an original console, it was a gift and it's so much more convenient (it's so light it's easy to pull out of the storage shelf and it's nice and compact in size it can be stored very conveniently). And although someone asked above why I would insist on a heavy sixer because I clearly already own "something else", I guess my best explanation is the FB2 acts as a great reminder of those glorious 2600 days and if I wanted to really take the nostalgia plunge and get an original console, I would want to go fully old school and insist I get a heavy sixer.

It probably still doesn't make any sense.

 

Still, as I say, there are still a great collection of home brew games that do run on my FB2 and I will continue to enjoy those rather than go for any of these bB titles.

[+thegoldenband]

Thanks to all who clarified the question about bB and illegal opcodes. Interesting that they're a core part of several kernels.

 

Are there any "standard" bB configurations -- i.e. default kernels using standard commands without inline ASM, DPC+, or anything beyond the usual -- that don't work on the 7800 or the Atari Jr. models known to cause problems?

 

Or: if a bB programmer wanted to set things up so that a program would work with everything, even borderline cases like the FB2, what should he/she do? Is there a compiler flag that might throw a "this won't work on certain Atari Jrs." or "this won't work on the FB2" warning?

[RevEng]

Are there any "standard" bB configurations -- i.e. default kernels using standard commands without inline ASM, DPC+, or anything beyond the usual -- that don't work on the 7800 or the Atari Jr. models known to cause problems?

 

I've never heard of bB having any compatibility trouble on original hardware, and I run bB code regularly on my 7800.

 

Personally I think adding code to bB to implement a "this won't work on FB2 warning" gives it more importance than it's due... we don't do that for other emulator bugs.

 

If someone is intent on making their bB or assembly homebrew work with FB2, they just need to avoid avoid using SC RAM, DPC, DPC+, SBX and possibly other illegal-opcodes, and the standard bB kernel.

 

Still, as I say, there are still a great collection of home brew games that do run on my FB2 and I will continue to enjoy those rather than go for any of these bB titles.

 

For sure, except to be correct it's also certain assembly homebrews (and commercial games) you'll have to forgo.

[Byte Knight]

I emailed Curt Vendel a while back to see if there was any present or future hardware fix for this problem and this was his response:

 

Yeah, that was something I realized later on, my screw up, I misread a few things in the TIA schematics and unfortunately Atari is now using a 3rd party company for a new FB console which is running emulation, so not only wouldn't you be able to get it onto their system for release, but I don't think their system will even be hackable to try and get outside ROM's to work on it.

 

I think the way to go is an Atari 2600 with an AV mod, since and the picture is just as good as the FB2 and you can play all homebrews plus Pitfall II!

 

Otherwise, we'll just have to hope for Curt to be asked again to design the next FB model...

[+Random Terrain]

Otherwise, we'll just have to hope for Curt to be asked again to design the next FB model...

 

But hopefully with some input from other knowledgeable AtariAge members so it will be as perfect as possible and nothing will be screwed up or forgotten.

[SeaGtGruff]

With regard to the FB, FB2, FB2+, etc., let's keep in mind that they weren't intended (designed) to play plug-in carts, but only the games that came "preinstalled" in them, so they really aren't "consoles" in the sense of machines designed to play plug-in games. It's cool that they can be hacked to add a cartridge port, but since that wasn't part of their original design parameters, it's perfectly understandable that they can't handle plug-in games with SARA chips, illegal opcodes, etc.

[+Gemintronic]

With regard to the FB, FB2, FB2+, etc., let's keep in mind that they weren't intended (designed) to play plug-in carts, but only the games that came "preinstalled" in them, so they really aren't "consoles" in the sense of machines designed to play plug-in games. It's cool that they can be hacked to add a cartridge port, but since that wasn't part of their original design parameters, it's perfectly understandable that they can't handle plug-in games with SARA chips, illegal opcodes, etc.

 

Who do we bug first regarding new hardware? Poke at the maker of the MCC for better emulation or pester Mike from FPGA Arcade

[PFL]

Well, Curt put up a poll recently regarding a new console too. So maybe there'll be a third way...

[Keatah]

Why don't you buy an original 2600 for playing homebrews? You can get one for just a few bucks so why stick to a modded FB2 ?

 

Well a few reasons.

 

First of all, 35 year old components have a risk of dying, whereas the FB2 is modern tech.

 

Secondly, although I have seen some original consoles dirt cheap in flea markets, my original console back in the day was a heavy sixer and my fondness for it was such that I would only get a heavy sixer, nothing else. From what I gather, they are harder to find.

 

Thirdly, used 2600's are generally missing power supplies and RF modulators, tricky things to locate nowadays.

 

Finally, my wife's SNES is currently hooked up to the RF connection on the back on the CRT TV I use for retro gaming, it is a heck of a lot more convenient to use the composite connections that came with the FB2 in comparison.

 

I guess I'll just have to live with it then.

 

These are all simple problems that can be worked around with the drop of a hat..

[Jess Ragan]

To put it simply, it's easier... MUCH easier. The Atari 2600 is a really quirky system and it takes a lot of hard work and ingenuity to get the most out of the machine. Batari BASIC deals with the tricky stuff, letting users develop games with relative ease. I know I would never have made a 2600 game without it.