RevEng

I think that a real name looks better. From a legal standpoint it doesn't make a whole lot of difference, since the game is copyrighted even if there's no notice. If someone else claims they wrote the game then a notice with an alias may make proving ownership tougher.

Not as cool as a voice-over, but you could use the bitmap minikernel to display a changing line or two of text to display that info, just like the attract mode on many arcade games.

It's cool - I like the shading you've done on the title letters!

thanks guys! I can't wait to see what people make with it!

The bB Titlescreen Kernel can be used to create high-quality titlescreens for your bB games. Enjoy! titlescreen_kernel_1.8.zip Jeff Wierer's most excellent vbb project now has an integrated Titlescreen Wizard! Here are some screenshots from 3 of the examples in the zip. And here are the bins from the examples. ex1-basic_color.bas.bin ex2-scroller.bas.bin ex3-animation.bas.bin ex4-color_by_flicker.bas.bin ex5-player_and_playfield.bas.bin Please report any bugs in this thread. Go forth and make titlescreens!

It looks like both stella and the z26 emulator initialize the timer in the 1024 cycle mode. I looked through the datasheet for the 6532 to no avail, but I'm thinking that the interval on powerup isn't the 1 cycle mode.

It's a typo... luckily your dyslexia cancelled out mine.

Brilliant - confirmed working perfectly! Thanks for the speedy turnaround!

I'd like to submit a feature request for the Img2Code utility. Right now if you load a picture with 256 lines and hit the "Create Image" button, the number of lines gets changed to 192, and indeed only 192 lines of data are generated per slice. The soon-to-be released version of the titlescreen kernel uses images up to 265 lines tall for scrolled pictures or animation frames. It would be cool if Img2Code could work with these larger images!

Here's a minimal program that triggers the "less than 312 scanlines" problem... set tv pal set kernel_options player1colors dim frame=a scorecolor=$0f gameloop frame=frame+1 frame=frame&31 rem ** burn a variable amount of time for t=0 to frame z=z next drawscreen goto gameloop ...the player1colors kernel option is key. Without it, the scanlines are stable.

Thanks - Feel free to convert away!

Thanks for the comments on my contribution, guys! Unfortunately I don't use vbb, so I can't generate a .spr. I've attached sprite sheets, which hopefully should help with any import. The standing guy front view is less interesting than the walking side view, but the same thing applies in real life. Click on the images to see the gif animation... ...the neck could be filled in for a more realistic (less representational) look, but if the animation stays on that frame for a while your brain starts to see it like the blob of pixels it is. The sprite sheets...

Can anyone play? An 8x12 walking sprite... An 8x8 walking sprite... (click on the picture for the animated gif to play)

I've used Plasti Dip for the same purpose, and it worked quite well. Most hardware stores should have it.

In most cases you can consider the time between "drawscreen" commands to be 1/60th of a second in NTSC. Its actually slightly less than 1/60 and I'm assuming you didn't overun the allotted cycles in bB, but assuming that each tick of your timer is 1/60th of a second will work unless you're implementing a "clock program" that needs to accurately display the time for months. You should be aware that your frame counter will reach 255 and start over at zero again. If you need more time you'll need another variable for minutes. (or 256*seconds) Yes, this is the best method. The 2600 has a hardware timer, but its only useful for shorter intervals, and its already used by bB.

There will never be such a clarifying statement; copyright law starts off by saying that you have no right at all to copy someone else's work, and then adds exemptions. Anything not stated is forbidden. (aka "all rights reserved") Judges don't usually ignore case law when making rulings, in favour of weighing the intent of the law. And maybe the judge will decide that the intent of copyright law is to protect the copyright holder, and you should license a rom from them instead. There are 2 cases I cited in which the final rulings said: 1) ROM backups aren't legal. 2) The source of the copy must be from the user's copy on their own equipment; Otherwise the copy is illegal, even if the end-user's use is non-infringing. Like it or not, software is handled differently in copyright law. That's why it gets its own set of exemptions. Applying a format shifting precedent on audio files to rom files is tenuous, though I'd love to see it tested.

Yeah, no disagreements there. My original comment was in the context of end-users downloading 2600 roms.

Format shifting has never been applied to software in a copyright court case, so Nukey is right that it's a grey area. The closest judgement for software that I know of would be in Micro-Sparc, Inc. v. Amtype Corp., and the court ruled that third party copies were illegitimate since they weren't made from the user's purchased media and equipment. And to head off someone bringing up the software backup exemptions, software backups of cartridge games is not an exemption according to Atari v. JS&A, due to the longevity of cartridges. But its all academic, since nobody is going to go to court over Atari 2600 roms.

I took a quick look, and I think atari2600land is missing the part that actually displays the high score. One way to do that is to set the score variables to the saved high score while displaying the titlepage. Or you can get more fancy and swap the saved high score with the current high score every few seconds.

Not useless, just niche. It's a great place to store your sound fx or music routines, as they will be called every 60th of a second, no matter how many drawscreen commands you've scattered throughout your code. There are other similar uses - if you're cycling a color, doing an animation to a sprite that should happen every 60th, etc. That said, if the routines should only happen in certain phases of the game then you'll need a variable to track that and skip the routines if the game is in a phase they shouldn't run in.

One site... http://batchpcb.com/index.php/Products And the article where I originally read about it. Seems that BatchPCB is owned by SparkFun... http://hackaday.com/2010/03/01/batchpcb-pays-you/

Confirming that it's a known issue. The first pixel in the 6th digit is a repeat of the first pixel in the 4th.

They've hooked it up to an LCD TV using composite video. Its not a computer monitor. The Sega Genesis pads work on the Atari 2600 pretty much the same as a CX-40. I'm pretty sure he's just using them because he prefers them or they're all he has on hand.

Sure!

I think you're talking about this one: http://www.atariage.com/forums/topic/122024-64k-bb-games/page__view__findpost__p__1483436