RevEng

Here you go. I'm less watched at work.

Nice start dbks! I think you've got the scale just right, and the grasshopper physics are fine. I'd like to see the man smash his head when he hits pixels above him. Presently he kinda shoots through some and then embeds himself in the ceiling. Also, a little gore never hurt things - when you get hit the guy should be flattened, and we should see some blood ooze out.

Another bug, in addition to the one above - you can't call drawscreen from another bank when using the DPC kernel. Looking at the asm, the DPC setup uses a non-bankswitched jsr. I guess this limitation will go away when the setup is moved to ARM code? It's easy enough to work around for now, by just creating a drawscreen wrapper in bank 1 and gosub'ing to it, instead of calling drawscreen directly.

I'd also include Dungeon, L.E.M, Seaweed Patrol, and Circus Galacticus. If you load up a directory with all of the commercial games and throw stella at one at random, your odds of getting one that looks worse than any of these is quite good, and your odds of getting one that is less fun are even better. I'm sure it just came out wrong, Jess. "commercial" wasn't probably the best way to put it, as Activision and Imagic were atypically good commercial games. I hope you don't shut up for long. Everybody misspeaks now and then, and it would be really cool to see what you could do with the new DPC kernel vs the old pre-beta standard kernel used in Solar Plexus!

The beta release is already out: http://www.atariage.com/forums/blog/134/entry-7832-batari-basic-11-beta-with-dpc-kernel/ To be technically correct, the new DPC kernel has those awesome features, not bB itself. The beta contains the previous standard and multisprite kernels, as well as the snazzy DPC kernel. The DPC kernel is presently missing a score display (I think batari has more cool stuff planned there) and there's the odd bug being shaken out, but it's good enough to preview or start a project in.

Thanks batari! That fixed the jump issue, but there's another - it seems the X coordinates are offset 7 pixels to the left.

Thanks Uberkatzchen!

Minor bug uncovered... the positioning routine seems to be off in 2 places near the right hand side of the screen. I've attached a modified version of the sample program where its easy to see this... the sample program increments each object's x position, and zeros it when x>152. sample.bas.bin sample.bas

Very nice work! This went straight into my 2600 docs folder, and I'll be using it the next time I need to compose some music.

Nope. Presently its the usual 32 across. batari might surprise me here, but I'm expecting that's the way it will remain. There's just a heck of a lot going on here for a single line kernel.

Excellent - it's perfectly clean now!

That's fair enough. If any 2600 games were truly public domain, you'd have every right to use them. I'd even encourage you to exercise your right to do so. But no Atari 2600 games, original or homebrew, have fallen into the public domain. That takes 50+ years or never happens, depending on who's version of the situation you believe. No 2600 games have been prematurely placed in the public domain by their authors, to my knowledge. So that leaves you with the options that GroovyBee points out. Regarding combat - reverse engineering has generally held as a fair-use exemption to copyright restrictions, and in this case the reverse engineering is for educational non-profit purposes, so it's pretty clearly fair-use. But the game is definitely copyrighted.

Unless a homebrew author has explicitly granted you the right to redistribute his work, you can't do so. That's the "all rights reserved" part of copyright law. If an author has posted on AA, usenet, or whatever, it's only reasonable to assume you have the right to download a copy. It does NOT put the work into the public domain. Maybe you can develop a few 2600 games yourself, and put them in your package.

I took the sample and started working it into a game. It's amazing being able to use single-height players. I ran into a few issues, which I expect you're already aware of batari... It looks like player0colors has some glitching on some lines. I checked it on real hardware as well, with the same results. Its pretty obvious in the attached binary. The scanline counts are off. ...I'm very excited to see the DPC kernel in development! ghosttown.bas.bin

v0.02 added to first post. I've updated the keywords to include new ones from batari's v1.1 beta, and also fixed a bug where a rem statement was considered ended with a ':' character.

Wow! This is a game changer... literally and figuratively!

If you want to backup/restore the games then both Wii units need to be hacked. Your saves that wouldn't backup are likely locked. Nintendo does that to some games to stop people from using traded saves in online games, like Smash Bros. Those saves can be transferred using homebrew utilities, if both Wii's are hacked. If you're adept enough at opening things up, the Wii drive is relatively easy to replace, and you can get them for less than $50 shipped on ebay. Or you could hack the old one and play the games from it via a USB hard drive. You'd still need a way to get your game disc images onto the hard drive - either from a hacked Wii with a good drive, or downloaded the same games from the net.

Provided all of the backgrounds will be black, you could the row of pixels under her feet as %11111111 and set the color to black. That would guard against side-wall sticking, but wouldn't help on the top. (You don't want to do the same for her head, as that would show up when she's in front of another character.) You'd also want to give the playfield display priority over the players, so the black dots won't show up. There's a side-effect from this approach, though; any downward collisions would stop her one pixel short of the wall.

Looks good, Jarod! One nitpick - I'd prefer it if the character selection and level selection worked with the joystick too. This one's ripe for Vox support. Did you ever pick one up, like you planned?

Yeah, agreed. It's one of those animations you see and say "oooooh".

gosub+return commands is more complicated. It's pretty much impossible to determine one subroutine's return from another, since there's no real way to check where a subroutine ends. I can't even do gosub/return counts, since it's a valid technique to have multiple return points from a subroutine, and you could have multiple gosubs to the same sub. I think I've hit a lot of the obvious checks, but I have a few other ideas on what could be added... goto/gosub without real destination. dimming a variable name that's a reserved keyword setting up a constant that's a reserved keyword ...that said, I'm not rushing to update this right now, beyond bugfixes. I have too many projects right now as-is.

Excellent start batari... this is definitely a needed project!

Sounds perfect Jeff!

Thanks diogoandrei! It's not the most thrilling of utilities, but hopefully it will save people time bug-hunting.

I put together a small utility to double-check the syntax of a bB basic program. This version changes the bundled Linux binary to 32-bit for wider compatibility. If there are issues, bblint reports them along with the line numbers, if possible. If no problems are found, bblint just silently exits. bblint is a command-line utility, so you'll need to know how to run those, or call it from visual bB. If you run bB from a Batch or Make file, it would be a good idea to include this command there to double check your work. Win32 and Linux x86 versions are included, along with source. download from 8bitdev.org