RevEng

Aw sweet! I had no clue about the def command (it's not documented at Random Terrain's guide as far as I can see) but that's a *way* better way to do it! Now I can forget about the bit positions entirely. So basically def is a bB-level definition, and const is a dasm-level one... Excellent! Thanks for the clue, and for the excellent tools sir! (most excitedly awaiting Harmony!)

I was squeezing down some variables I was using like booleans into bitfields. To make my bit setting/reading a bit more meaningful, I was trying something along the lines of... dim gameflags=a const PLAYERDIED=0 ... gameflags{PLAYERDIED}=1 ...which unfortunately doesn't work. bB doesn't like variables in the bitfields, and rejects constants for the same reason. Understandable, as the constants get expanded in dasm, not the bB compiler. However I did discover that you could do something halfway there. bB will use the rightmost character as the bit position and ignore anything on the left, so you can make your source more readable with something like... dim gameflags=a ... gameflags{PLAYERDIED_0}=1 ... if gameflags{PLAYERDIED_0} then... ...this is totally undocumented and unintended behaviour from bB, so if you use it it could vanish in a future version of bB. Still, I like having my bits obvious, so I'm going to use it. I thought someone else here might care to use it too.

Look at the "Code Snippets & Samples for bB Beginners" thread. The last example shows how to point sprites using data statements. http://www.atariage.com/forums/index.php?s...t&p=1761970

It's missile1, and when it's passing one of the virtual sprites (the last one drawn on the scanline, I think) it's sometimes taking on that virtual sprite's NUSIZ#, which is zero. If you change your NUSIZ settings after "main" to... NUSIZ0=$20 NUSIZ1=$20 _NUSIZ1=$20 NUSIZ2=$20 NUSIZ3=$20 NUSIZ4=$20 NUSIZ5=$20 ...your shape-shifting missile1 goes away.

I thought about cement, but at a minimum you'd need some kind of anchors in it. Otherwise if it fell off a table you'd have a brick smashing around the insides of the case. I also think the edges might crumble when the case flexes. The lead is an idea, but same thing on the anchors. Maybe if I epoxied them down it would work.

I recently bought a light sixer, and have some mods planned for it (the usual video+stereo stuff) and was also considering how I could go about adding heft. The added weight on a heavy makes it easier to swap carts, change selection, etc., using one hand. (At least from what I recall) Anybody have any thoughts? Some kind of casting resin poured in the bottom shell? Ideally the weight would be be bonded to the case. And does anybody with a heavy sixer and a scale want to let me know what I'm aiming for?

My 2 cents - I like the Evil Dead theme, but I think adding in Freddy and Jason actually takes away from it. If you're looking for enemy to focus on besides the posessed, maybe you could use a Sumerian Priest? As far as mazes and pits, couldn't the woods around the cabin, and graves like the one Ash dug serve? In the movie, the trees themselves impeded movement. Either way, sounds more interesting than yet another D&D themed game. Get coding!

Let the heresy begin. I too prefer a gamepad for my 2600 emulated gaming. If someone produced a 2600 gamepad I'd pick at least a couple up. I've even considered trying to manufacture one, though I suspect us gamepad'ing 2600'ers are in a minority. I'm an Atari 2600 child, but I believe this is one thing that Nintendo got right with the next generation.

I'm 39, and don't feel embarassed by being a gamer. But occasionally I'll get treated in a patronizing manner when I go to a game store, like I'm some clueless dad buying games for his kids. The irony is I usually know far more about the subject matter than the person trying to lend me a clue. It doesn't really help the situation that I'm usually buying Nintendo titles, though I consider their stuff less immature than "Super-Bloody 3rd person Murderer".

I totally agree with M.U.L.E on the Atari 8-bit. Reactor was rocking too. But the first one I thought of was Preppie on Atari 8-bit. Well executed, and it perfectly matched the game.

Thanks for the kind words guys! Hopefully they'll find their way into somebody's project. I was thinking it would be handy to have them all in one score_graphics.asm file along with the stock font, and the active font could be determined by what value the "fontstyle" constant was set to.

The SPI bus definitely opens up possibilities, like connecting it to another microcontroller or an SPI module. Its awesome that you're providing hooks to access the microcontroller. It definitely will open up a new avenue of 2600 hardware experimentation to the scene.

Will the firmware for harmony be upgradeable, and if so, will there be source code available? It would be neat if you could use harmony to proto new cart extensions, via spare gpios or what have you. Not a deal breaker either way, just dreaming.

The 6x8 thing is just a preference. Easy enough to fatten some of them up if you prefer to use the extra real-estate. Glad you liked them! I'm a sucker for the 5th one (the 70s "computer" one) but I do recognize it's an acquired taste!

I started coming up with a few different number-font designs for a game I'm working on, and found myself caught up in seeing what different fonts I could come up with. The result is this font pack... reveng_batari_Basic_fontpack_1.zip I'm placing them in the public domain. Feel free to take them and use them as your own, however you see fit! Just unzip the pack to your project's directory, and rename the font you want to use to "score_graphics.asm".

Very unique idea - the i shooting it's dot is funny. Instead of shooting the vowels, how about shooting the other letters in "atari", with the fuji as a boss.

I might well get shot down for this, but how about taking pre-orders to help cover manufacturing costs, say $20 or $30? That way people who are really interested are sure to get their carts from the first run, and you'll have a better idea for the size of that first manufacturing run. I'm definitely in for at least one. If the price is ~$50, I'll probably get two.

A well encrypted file is indistinguishable from random bits, and this one pretty much fits the bill... 1. all 256 ascii chars are represented in roughly uniform quantity 2. the unix file command doen't identify it, or any of the contents. I wrote a quick script which strips off one byte at a time and reruns "file" on the result. Nada. 3. the file isn't compressable. If I had to guess, I'd guess it's plaintext xor'ed with random data, but it should be easy enough to check. If you modify one of the parameters in the game, compared to the original player.txt, does the resulting player.txt file... 1. ...change one or two bytes in the middle of the file. 2. ...change a byte and all following bytes in the file. 3. ...completely change the whole file. #1 would imply a simple xor with random data. #2 would imply a chain block cipher (or less likely, a stream cipher). #3 would imply a large-sized block cipher, or something akin. Either way, the game itself needs to decrypt the file to read it. Given the right tools you'd be able to figure out what's going on.

One more example for the pot - how to use shared sprite data for player0 and player1. 13_SharedSpriteData.bas 13_SharedSpriteData.bas.bin (edit - fixed up the comments a bit) 13_SharedSpriteData.bas

How about adding in C++ style comments? It's nice to be able to put a small comment right next to a command. I added the following to source/preprocessor.lex... [ \t^]*"//".* {printf("\n rem %s",yytext);} It works for the following kinds of comments: //case1: completely left-aligned comment //case2: comment with 1 or more spaces or tabs first dim foo=c //case2: comment beside a command My lexfoo isn't all that strong, so I'm sure there's a better way to do it. The code to do it adds an extra blank line to the assembly, to ensure the rem it generates is correctly aligned. I also want to thank batari for this awesome tool!