RevEng

In the case of the "RevEng Presents" text I drew the 0's and 1's. One of the design goals of the minikernels was to keep the data in a easy to edit format, and its pretty easy to manually bang out letters in a 3x5 monospaced font once you get used to it. For more complex stuff like images, I used Gimp and a different (more complicated) export process. But since then, I've exported images through ImgToCode with great success. I used a thin Gimp font for the scrolling Knight Rider text demo, and it didn't turn out too badly. I started off with the image at the 48x256 resolution I needed, bumped down the font size and played with the hinting settings. Is there an image or some text you want to display? I can post the steps I'd take, and you can give them a shot, and we'll see where things are going wrong.

I hacked in genesis controller support to z26... z26_20040523_genesis.zip ...You only need to use the z26_20040523_genesis.exe binary, but I included the source as it was the easiest way to comply with the GPL. Use the CLI switch "-)GC" for the genesis controller. Left ctrl is the Genesis-B/INPT4 button, and right shift is the Genesis-C/INPT1 button.

A quick definition to make the language easier. The two number representations we're talking about are usually referred to as "signed" (for a byte, -128 to 127) or "unsigned" (for a byte, 0 to 255). The slightly shorter answer to your question... The 6502 doesn't really know about numbers being signed or unsigned. The numbers are laid out in such a way that the math will work out the same from a binary perspective. If you're not doing anything in the context of signed numbers, you should consider the numbers as being unsigned. So your loop from 1 to 255 is just a loop from 1 to 255. If you do something like "if mynum<0 then goto someroutine", then you are treating mynum like a signed number, and you should probably consider stuff like 255 is the same as -1, and that a signed number rolls after 127 instead of 255. The longer answer to your question... The 2 number representations, signed and unsigned, are mapped out in such a way that the arithmetic works out the same whether you think of the number as signed or unsigned, with the exception of the limits where the numbers roll-over. (i.e. from 0<->255 or -128->127) This mapping system is called two's complement. Here's a quick summary of how unsigned and signed values are mapped out in two's complement... Signed Unsigned Binary 0 0 00000000 1 1 00000001 ... 127 127 01111111 -128 128 10000000 -127 129 10000001 ... -2 254 11111110 -1 255 11111111 The CPU actually doesn't actually know or care if your program is expecting to use a number as signed or unsigned. It just adds up everything in binary, and leaves the signed/unsigned context up to you. Consider the signed expression "-2 + 1 = -1" and the unsigned version of the same expression "254 + 1 = 255". The binary math works out fine whether you treat the numbers as signed or unsigned. So for your loop from 1 to 255... The CPU just counts from 00000001 to 11111111. From an unsigned context, the loop looks like it goes from 1 to 255. From a signed context, the loop looks like it goes from 1 to 127, then rolls over, and goes from -128 to -1. But remember that the actual context comes from the way your code treats the number. It's a bit weird to loop from 1 to 255 and do tests for negativity and other stuff that would imply signed values, so you really wouldn't be thinking in terms of signed values as you coded this loop. Hopefully this has helped, and we haven't had more worms escaping from the can!

The interesting thing about your arrow analogy, is it can be modified to be analogous to the way 6502 byte arithmetic works. If the universe was only 256 feet long, and you shot your arrow 255 feet, it would wind up 1 foot behind you. (assuming space curves back on itself.) You'd also be wise not to shoot the arrow 257 feet. Similar to the arrow in our 256 foot universe, when you keep adding one to a byte and it reaches the 255 limit, it starts over again at 0 and continues up. In this kind of system, you can treat bytes as if they were from 0<->255 *or* from -128<->127, depending on which suits your needs. Mainly this is handy in assembly code - one example is when you want to check if a number has become less than zero. To answer your question about counting down from 255, the number stops being negative when the you reach 127. (but "stops having the same representation as negative numbers" is probably a more accurate way to describe it.)

To access "score" as a variable, you just need to access the 3 component bytes with different variable names... dim sc0=score dim sc1=score+1 dim sc2=score+2 rem to check score is 1000... if sc0=$00 && sc1=$10 && sc2=$00 then ... The dollar signs are important, as the score is held as binary coded decimal.

That's excellent news! I believe I'll neuter some pads and mark them specifically for the Atari somehow. I've updated the FAQ in the first post to include the pin 5 info. Thanks nems! I've also added 2 button versions of Mouse Trap and Sea Hawk to the first post as well. During hardware-testing I noticed that I accidentally enabled the fire button during the Sea Hawk attract mode. I think I'm just going to rename it the "auto-pilot trainer mode", and call it a day.

Find the gun first!

I'm working on something that might open up some additional possibilities for that... titledemo.bas.bin ...the "advanced" 48x1 minikernel can scroll anywhere in an image that can be up to 256 lines high. Used creatively you could move the index between 2 images, changing the color for each frame, to get Michael's suggested 2 color flicker bitmap. Or you could move the index between more images as an ad-hoc menu, to get atari2600land's NBA team selection. Or you can just skip the index and just have a full screen image of ~190 lines. There's also no reason why it couldn't be adapted to a regular bB minikernel (the kind that sits above the score display) for displaying pre-rendered text.

No worries!

The titlescreen kernel wasn't the culprit; there just a small bug in your basic. When your game_setup routine is called, eventually you reach the "player1y=player1y+y" statement in the joystick loop. But y isn't initialized before that loop, so whatever it was before is added to the player1y position. Your previous code worked because you didn't happen to use y until then game_setup. But when you added the titlescreen code, you also added a "y=198" in the titlepage loop. If you add a "y=0" at the beginning of your game_setup routine then everything works the same as before.

I took a quick look. The interesting thing is I rem'ed out the gosub and added a goto to your game setup the same thing happenened, even though the kernel wasn't called. I'll dig a bit deeper later today.

The reverse-origin thing is due to there being more than 256 image bytes. If you reduce the number of lines you should get it to assemble correctly. For a 48-wide bitmap (6 bytes wide) you can use 42 (or less) lines. (256/6=42.6) For a 96-wide bitmap (12 bytes wide) you can use 21 (or less) lines. (256/12=21.3)

That's pretty much what's already done to call my kernel, only I've hidden the assembly away in external files. The issue presently is the 48 wide minikernel is hardcoded to the rom location of the image. I made the decision to do that for 2 reasons - it uses less cycles that way, and I figured it was easier UI for you guys to have a 1:1 mapping of the kernel to the data. The downside is, to have additional images with the present code you'd need to have additional near-identical minikernels. 32 routines and padded just isn't going to fit. Instead I'm thinking about a minikernel that has a predefined height, and more data lines than that height. Then you tell the minikernel which line to start the display with by setting a variable or two. This would allow you to scroll smoothly or skip images, whichever you please.

There's no way presently. I believe I can combine this and yuppicide's idea for a scrolling minikernel together... I just have to think out how I want to tackle it.

Just stick some 2600 roms on your SD card and try it without loading the firmware. It comes preloaded. If it works, its most likely a driver thing.

There's a height restriction on the minikernels - I thought I had put a comment for this in the asm files themselves, but it looks like I missed it. I'll add this to the docs for next time. Basically the code maxes out at 256 bytes. So for a 48-wide, that means 42 lines. I trimmed a few lines from your image and it compiled, though it made the screen larger than 262 lines. To fix that you'd need to rework the layout, possibly removing blank space and/or the minikernels displayed. I was planning to look at working around the 256 byte restriction in some of the minikernels, though the 48 wide 2 line wasn't high on the list, since it can take up half the screen at its maximum height. @jwierer: Thanks for the tool update - that makes it much easier!

Thanks, Philsan! The titlescreen ternel is pretty much ready for an alpha release folks, so here it is... titlescreen_kernel_alpha_20100726.zip ...along with the obligatory screenshot and bin file... titledemo.bas.bin Be sure to checkout the README and the demo basic program before you try to add a titlescreen to your own game. The demo has a 6 minikernels in it, each one with page alignments for critical code, so it's a bit bloated. If you're looking to use just a portion of a bank, try using fewer minikernels with larger graphics. I've purposefully left out instructions on how to prepare the graphics files, mostly because I'm not sure what the best process is. I know there was a tool that was used for Michael's bitmap kernel... not sure if that will work well here or not. Any suggestions on that, or anything else, would be appreciated!

Not having to hold down the button for Harmony 2-button support is pure awesome!

Excellent. Thanks RT! Michael, I took your suggestion on moving the score over. I think the jump during the screen transition will be less obvious when there's an actual game screen to look at.

Yeah, that's what I had in mind when I mentioned there wasn't much to be done...the transition to the game screen would be a bit jarring. I might just do it anyway, as the off-centeredness is really starting to bug me now, and you guess right that I don't want to shift all my stuff to the right at this stage. I also considered writing a mini-text score kernel, to use up less screen real estate, be centered, and have a less jarring transition. But if I do that at all, it will be much later. Thanks for the tip on the logo! I'll dig for it.

I've copied the bB score routine into a titlescreen minikernel, and put the code in place for easy repositioning/reordering of each minikernel, and killed a few small bugs. The bB score is off-center (as it is in games) but there's not much to do about that. titledemo.bas.bin I still need to work on the game-select minikernel, trim some of the bloaty parts (lots of page alignments), and write some docs, but its taking shape. I'd like to have a bB logo to include as a bitmap or animated bitmap or something... Any ideas or would-be designs?

The 2600 runs on magic smoke, so I won't disagree. But the gory details are... The entire screen is made up of player 0 and player 1 sprites, just using different techniques. The sprites can be made to display a 48 wide picture by setting the sprites to the x3 copy mode and positioning them so they alternate, like... [P0][P1][P0][P1][P0][P1] ...to get the copies to display unique data (instead of repeating the first one) you change the data after each sprite is drawn. This is how the horse is drawn, and it's how the bB score is drawn too. The "knight rider" title area is a variation on the technique which uses flicker to turn our 48 wide display into a 96 wide display. To make the flicker less objectionable, I employed a technique called flicker-blinds, which alternates the drawn area every line, rather than every frame. This is also the technique SeaGtGruff used in his bitmap kernel. To see it in slow motion, you can load up my demo in stella, enter the debugger, and hit the "frame+" button a bunch of times. Anyway, the nice part about the titlescreen kernel is that you won't need to know any of this. You just replace the existing data with your own and add a few simple lines to your bB program to call it.

Thanks for the encouragement guys. Rest assured, I'll keep at it. @theloon: I think the reason the flicker appears less is your eye now has a more stable area to focus on. (The 48 wide bitmaps) As side-effects go, its not a bad one.

You're welcome! Its actually been a lot of fun figuring out how some of these classic routines are done, though I'm not ashamed to say that getting the 48-wide routines working for every pixel kicked my ass for a while.

I didn't see that in the old thread, Michael, but flickering 48 is definitely on the list. The Colony 7 homebrew that grafixbmp mentioned uses that technique quite nicely in its title page. I worked a bit more on this, and refined my approach. I'm splitting everything up into minikernels, that the programmer will be able to choose and position on the titlepage. So far I've written the 96-wide flickerblinds minikernel, a 48-wide 2-line minikernel, and a 48-wide 1-line minikernel... titledemo.bas.bin ...if you press the fire button in the bin it brings you to a very boring blank bB drawscreen. Pressing left on the joystick will bring you back to the titlescreen. There's still a lot of work to go (integrating the bB score kernel, writing a game select kernel, putting together the positioning glue, etc.) but I figured you guys would be interested in the progress.