Easy way to identify ROMs made with bB?

[+Gemintronic]

I already gave a link that you can go to. It has no batari BASIC detector though. You must download and play the games to see if it's worthy of your archive. http://www.atari2600homebrew.com/

 

There's also the homebrew section here:

http://atariage.com/forums/forum/29-homebrew-discussion/

 

Also, just search this section for homebrew marked as done. Make your own judgements based on your own personal review. My favorite might be your worst.

 

 

UPDATE: A topic started to gather links for bB games

http://atariage.com/forums/topic/230005-batari-basic-game-listing/

[davidbrit2]

I already gave a link that you can go to. It has no batari BASIC detector though. You must download and play the games to see if it's worthy of your archive. http://www.atari2600homebrew.com/

 

There's also the homebrew section here:

http://atariage.com/forums/forum/29-homebrew-discussion/

 

Also, just search this section for homebrew marked as done. Make your own judgements based on your own personal review. My favorite might be your worst.

 

Well, part of the problem is that I've already got them pretty much all downloaded (I think there was a homebrew ROM set somewhere on AA that I grabbed shortly after getting the Harmony). Rather than trash and redownload everything individually, I can speed up the process by moving the bB ROMs to a dedicated bB or WIP subdirectory, then moving the good stuff back as appropriate, and outright deleting the stuff that's nothing more than a blocky title screen, and a crudely-drawn player sprite you can move the with the joystick (with the occasional grating sound effect if it collides with the playfield or some other bouncing object).

 

Another good one I forgot: Gingerbread Man. Gets hard as hell pretty quickly, though.

 

Lowering the barrier to entry is quite a double-edged sword. Think of all the awful VB6 and MS Access "applications" out there. But if you know what you're doing, you can use them to produce decent solutions in a lot less time than lower-level alternatives. Kind of the same "issue" with bB.

[+KaeruYojimbo]

I think the issue is that you've singled out bB games as a source of crap. Everyone seems to be focusing on the "junk" part of the original post rather than the "unfinished." I'm curious why the archive you downloaded contained so many unfinished games (the ratio of finished to unfinished games on the bB forum is probably even worse than the good to bad ratio).

 

That said, definitely check out L.E.M., Ms. Snake, Alien Greed II, Heartbreak, Questforge and JumpVCS. All well done games that show what you can do with bB if you put a little effort into it.

Edited October 27, 2014 by KaeruYojimbo

[Albert]

Lowering the barrier to entry is quite a double-edged sword. Think of all the awful VB6 and MS Access "applications" out there. But if you know what you're doing, you can use them to produce decent solutions in a lot less time than lower-level alternatives. Kind of the same "issue" with bB.

I think this is the key thing to remember, and I agree with you wholeheartedly. If it comes down to having bB versus not having bB, I'd much rather have it. Although the ratio of good to bad games may be lower with bB than it would be for someone building games with straight assembly, it's already been demonstrated several times that you can build rather high quality games with bB.

 

I'm on the side of encouraging people to program using batari Basic, which is more approachable than Assembly (obviously). You'll get some good games and some bad games. Some people may graduate to pure assembly-based games down the road, or perhaps some combination of the two. Some people may build a game or two and abandon their efforts to make 2600 games. The important thing is that people are having fun, they are learning how to program (if they never have before), they are learning more much more about the 2600 than just playing games in an emulator, and they are being creative.

 

I have this fancy "Downloads" module for the forum I've been paying for that I need to put into use. It would allow us to easily organize all the homebrew games for each system, and allow individual authors to update files as new versions are completed, while maintaining a history of previous versions. Complete with screenshots, a description of the title, and a linked thread for discussion. And ratings as well. Would make it much easier to track homebrew games, game binaries and their relevant development threads down.

 

..Al

[Albert]

That said, definitely check out L.E.M., Ms. Snake, Alien Greed II, Heartbreak, Questforge and JumpVCS. All well done games that show what you can do with bB if you put a little effort into it.

Two of these will be available in the store soon, L.E.M. and Heartbreak. Heartbreak as part of a collection of five games titled Piñata. I need to look at the others. Well, besides Alien Greed II, which I've produced carts for in the past for Neotokeo.

 

..Al

[Byte Knight]

My ROM set has a homebrew subdirectory which currently contains a ton of unfinished junk made in batari Basic. Is there any easy way I can identify ROMs made with bB so I can move them all to a separate batari Basic and/or WIP subdirectory? Any sort of consistent fingerprint within the ROMs that I could look for?

 

More importantly, is there a program to weed out davidbrit2's posts?

[davidbrit2]

I think this is the key thing to remember, and I agree with you wholeheartedly. If it comes down to having bB versus not having bB, I'd much rather have it.

 

I completely agree.

 

That said, definitely check out L.E.M., Ms. Snake, Alien Greed II, Heartbreak, Questforge and JumpVCS. All well done games that show what you can do with bB if you put a little effort into it.

 

Thanks, I'll check those out. None of those names rings a bell.

 

I did a search using the fingerprint RevEng suggested (78 D8 A0 00 A5 D0) and I'm getting 123 matches out of the 409 files in my homebrew directory. All but a couple of them are dated 2007 or later, so that's a good sign I'm not getting too many false positives. Not sure if it's missing any, but this ought to give me a good start at organizing things at least.

[RevEng]

If you do hit false positives or false negatives, I'd love to hear which ROMs are involved, just out of intellectual curiosity. Some may be using a non-standard kernel but still be bB, others may do a similar startup check. (though I'd be surprised.)

[davidbrit2]

Found one definite false negative: Aborigines' Revenge. That one's dated 2005 in my set, so maybe bB wasn't doing 7800 detection at that point, thus those bytes don't show up in the resulting ROM.

 

Of the bB games it was able to identify, I was able to test and move over half of them to a sort of "unfinished" directory. (No, I'm not going to name any. Any programmer has to start somewhere; it's more the sloppily curated ROM set that was the problem.)

 

Some of the more interesting ones I stumbled across in the process:

 

Arctic Landtran

Ature

Cold War

Evil Magician Returns

Go Fish

Lander

Money Man

Shield Shifter

Tron

 

EDIT: May have found another usable bB fingerprint, though I couldn't tell you what it is. A9 00 85 0E 85 0F 8A

Edited October 29, 2014 by davidbrit2

[+Gemintronic]

Here's another place with completed games (incomplete clearly marked WIP):

http://www.atari2600land.com/basic/

[davidbrit2]

Here's another place with completed games (incomplete clearly marked WIP):

http://www.atari2600land.com/basic/

 

Nice! Jumpman looks promising from the screenshot. I'll have to give that one a try. And Because It's There is pretty cool, sort of like a mix of Ice Climber and Spelunker.

[+Random Terrain]

Here's another place with completed games (incomplete clearly marked WIP):

http://www.atari2600land.com/basic/

 

Ruins never really was finished.

[+KaeruYojimbo]

More current, but still far from complete, list here: http://batarigames.statotronic.com/

[RevEng]

Found one definite false negative: Aborigines' Revenge. That one's dated 2005 in my set, so maybe bB wasn't doing 7800 detection at that point, thus those bytes don't show up in the resulting ROM.

Yeah, likely so. Its a bit of a tough nut to find unique code that shows up in all historic versions, across all kernels.

 

Thanks for the info on the false negative. Interesting stuff!

 

 

EDIT: May have found another usable bB fingerprint, though I couldn't tell you what it is. A9 00 85 0E 85 0F 8A

Its part of the standard bB kernel. It clears out the playfield registers between playfield blocks, if no_blank_lines hasn't been used.

 

This won't be present in bB games using alternate kernels, like DPC+, multisprite, or custom-built kernels.

[davidbrit2]

Its part of the standard bB kernel. It clears out the playfield registers between playfield blocks, if no_blank_lines hasn't been used.

 

This won't be present in bB games using alternate kernels, like DPC+, multisprite, or custom-built kernels.

 

I kind of suspected it was part of the standard kernel or some other init routine. I'm not quite as concerned about the ones with more complex kernels, as those are far less likely to require sectioning off in my "unfinished" directory.

 

More current, but still far from complete, list here: http://batarigames.statotronic.com/

 

Thanks, some of those look rather interesting.

 

On a related note, what bB DPC+ games are out there already? I'd love to see what can be done with a blatant disregard for the 2600's hardware limitations. Princess Rescue doesn't use DPC+, does it? Just 32K bank-switching?

[Albert]

Princess Rescue doesn't use DPC+, does it? Just 32K bank-switching?

Correct.

[+Random Terrain]

More current, but still far from complete, list here: http://batarigames.statotronic.com/

 

I see they have the Seaweed Assault .bin on the site instead of linking here:

 

atariage.com/forums/topic/173190-seaweed-assault/

 

 

Does anyone know how to contact the person? Their contact page doesn't work.

[iesposta]

...

 

On a related note, what bB DPC+ games are out there already? I'd love to see what can be done with a blatant disregard for the 2600's hardware limitations. Princess Rescue doesn't use DPC+, does it? Just 32K bank-switching?

DPC+ doesn't disregard the hardware limitations. The limitations are still there.

It just enables a few instructions to be run using less cycles.

Even the Pitfall II music can be done without a DPC chip, just in code.

Anyway, the 2 links in my signature are 2 games I've done.

One is batari Basic with the multi-sprite kernel, and the other is batari Basic with the DPC+ kernel.

[davidbrit2]

DPC+ doesn't disregard the hardware limitations. The limitations are still there.

It just enables a few instructions to be run using less cycles.

Even the Pitfall II music can be done without a DPC chip, just in code.

Anyway, the 2 links in my signature are 2 games I've done.

One is batari Basic with the multi-sprite kernel, and the other is batari Basic with the DPC+ kernel.

 

Ah, I thought the ARM coprocessor on the Harmony was part of the DPC+ spec. That's entirely independent, then?

[iesposta]

 

Ah, I thought the ARM coprocessor on the Harmony was part of the DPC+ spec. That's entirely independent, then?

The Harmony is a cartridge emulator powered by an ARM processor. It spends most of its time emulating a cartridge and can also emulate a DPC chip, a DPC+ chip, and more . That leaves around 10% left for assembly programmers to use it as a co-processor to run game logic. Everything still must be passed back to the 2600 as a cart in 4K ROM spaces.

 

It is really hard to grasp that there is no physical DPC+ chip. And that it is an altered emulation (by the ARM computer) of the Pitfall II chip.

 

In conclusion, using DPC+ functions is using the ARM because the ARM is emulating the DPC+. I guess if you had enough money, a physical DPC+ chip could be manufactured and you could build a cartridge with a ROM chip, a RAM chip, and a DPC+ chip. No ARM required.

batari Basic DPC+ games are 24K 6507 Atari code by the programmer, the other 8K used by batari Basic language framework .

[Cybearg]

One is batari Basic with the multi-sprite kernel...

I made a Flappy clone as well back in March of this year, just to try it, except I went with the standard kernel and focused on trying to be visually accurate to the original with the sprites.

 

Interesting how there's more than one way to do things.

Edited October 30, 2014 by Cybearg

[davidbrit2]

The Harmony is a cartridge emulator powered by an ARM processor. It spends most of its time emulating a cartridge and can also emulate a DPC chip, a DPC+ chip, and more . That leaves around 10% left for assembly programmers to use it as a co-processor to run game logic. Everything still must be passed back to the 2600 as a cart in 4K ROM spaces.

 

It is really hard to grasp that there is no physical DPC+ chip. And that it is an altered emulation (by the ARM computer) of the Pitfall II chip.

 

In conclusion, using DPC+ functions is using the ARM because the ARM is emulating the DPC+. I guess if you had enough money, a physical DPC+ chip could be manufactured and you could build a cartridge with a ROM chip, a RAM chip, and a DPC+ chip. No ARM required.

batari Basic DPC+ games are 24K 6507 Atari code by the programmer, the other 8K used by batari Basic language framework .

 

Right, I knew the ARM in the Harmony was handling all the DPC/DPC+ simulation. I could have sworn I had heard that Space Rocks (for example) was offloading some arbitrary snippets of ARM code to the cartridge to handle some of the calculations. I may have read it wrong, though.

[iesposta]

Right, I knew the ARM in the Harmony was handling all the DPC/DPC+ simulation. I could have sworn I had heard that Space Rocks (for example) was offloading some arbitrary snippets of ARM code to the cartridge to handle some of the calculations. I may have read it wrong, though.

You are correct. Although you said "check out bB DPC+ games".

Sace Rocks, Frantic, Stay Frosty 2 and Draconian are not bB DPC+ games, but are assembly language and C language DPC+ games, and they have ALL of the game logic done in C on the ARM processor.

[Albert]

You are correct. Although you said "check out bB DPC+ games".

Sace Rocks, Frantic, Stay Frosty 2 and Draconian are not bB DPC+ games, but are assembly language and C language DPC+ games, and they have ALL of the game logic done in C on the ARM processor.

You can add Chetiry to that list as well.

 

..Al

[iesposta]

Games using DPC+ (either batari Basic or assembly/C) have 44 50 43 2B 03 in them, which translates to DPC+