MayDay

Other than the house, no real responsibilities... no wife, no kids, etc. I'm sure my house has appreciated *some* in the last year, but there is no real way of telling without having an appraisal done. And if I sell it now, I have a feeling I may never get the chance to buy one again. Not only that, my roommate of three years is about to graduate with her masters degree and move back to Oklahoma in May. It would be a poor way of repaying her to say "yeah, thanks, but you're going to need somewhere to live your last two months here." Anyway, I don't have a lot of cash (Christmas and New Years) but do have enough to survive for a couple of months. Hopefully things will take care of themself and this could be a blessing in disguise. That just seems like a long ways off right now reading through job listings...

It sounded a lot better when I wrote it. In fact though, I've been so busy I haven't touched a single piece of code since that day. I'm hoping this will let up soon, and I can get back to my real passion of the last few months. Vdub, just wondering if you got the PM I sent you a few days back? -JD

Yes, this will allow you to draw 1-2 letters side by side (however many you can fit using 8 pixels). If you want more, you'll have to eventually learn the 48 pixel sprite techniques (not simple) or you can make the sprite text vertical (and take up to all 192 scanlines to do so). Another option to get much bigger, blockier text or numbers is to use the playfield instead of sprites to create your name. You should be able to do this once you've finished the "asymettrical playfields" section of Andrew's tutorials.

I hate to break this to you, but text is one of the hardest things to do with the 2600. You have to DRAW the text, and not just type it in. The black screen is easy, I'll post a working kernel here for you either tomorrow or Thursday. If you gave it a full steam ahead effort, you can probably create your own before then! Also, a quick note about disassembly. Distella currently supports only 2K and 4K games, and I know offhand Kangaroo is an 8K game. It is possible to disassemble 8K games however, it's just much more difficult because you have to split the binary up, disassemble both halves, and combine the two back together later on. If someone wants to give exact directions for this, it is something I'm very interested in as well! Thanks, JD

Here's some directions for you: 1. save DASM directly to the C: drive. Otherwise, every time you want to compile something, that's one more thing you will have to type out. Not absolutely necessary, but I would still advise it. The rest of my post will assume you are going to do this. 2. put your Assembly code file in the same exact spot as the DASM program is in. For me, that is C:\dasm\dasm22010\dasm\bin\dos\ 3. go to the command prompt instead of actually trying to double click to open the program. 4. my command prompt opens in the wrong spot. you must change to the correct directory by typing cd\dasm\dasm\22010\dasm\bin\dos\ and hit enter to change to the correct place. 5. this should leave you at C:\DASM\DASM22010\DASM\bin\DOS> 6. at the new prompt, type dasm source.asm -f3 -osource.bin and hit enter. 7. In number six, source.asm is the file you are trying to compile. So if you are trying to compile a file named Pong, you would change it to Pong.asm instead. Also, some people here use .s as the filename instead of .asm. There is no difference between the two, but you must use whichever file extension your code is actually saved as. The -osource.bin part creates a new binary named source.bin which will be saved to the same directory as dasm and your source file. -f3 is a switch you MUST have, but I'm too dumb to tell you what it actually does. I think DASM can generate a complete list of switches for you, but I can't remember how to do it, and it's not really important for getting started. 8. take your newly created binary file and drag it into your emulator to see what it looks like. Keep in mind, if you compile a new code and use -osource.bin, it will save over your old binary file. Two solutions, either rename your old binary to something more appropriate, or give your new binary a different name by typing something like -osource2.bin instead of the exact same command. Hope this helps. -JD PS- typing dasm as the command must give you the switches I talked about. Your post has a list of them and what they do! I know you already understand some of this, but with exact instructions, someone else can be pointed here later too.

Saying it's hard for a non-programmer is almost an understatement... I've been learning Assembly since March, and there have been a couple of times I thought it would be impossible to understand. However, you can find some sample codes in Andrews tutorial sessions I linked to above, assemble them in DASM, and put them into z26. Even this simple task took me about a week to actually get done. It seems that low language people just expect anyone crazy enough to try this will already understand the basic idea of what they're trying to do and have some experience in doing so. For that reason, there isn't a lot of step by step instructions (especially with the most basic stuff), but to their credit, they are very helpful and patient with newbs. If you really want to make a game, this is absolutely the best place to do it at. -JD PS- also some quick advice... save your game idea(s) until you have some atari coding experience, and know the system's limitations. Many newbs have came through, announced their games, gave up, and begged people to make it for them. This approach is not advisable, and will probably get you made fun of. If you decide not to heed this advice, please at least check out this guide before you post your idea.

I've been thinking about this game from time to time. I was able to get a semi-passable kernel for a 7x7 square visual display, however as Bruce suggests the text is the real kicker here. My solution was to move it to the 7800 (which surely supports text?) and would also make the game look much better. The biggest problem with that is, I know nothing about 7800 programming, and there isn't nearly the supporting documentation as there is for the 2600. Plus, you would have to spend a lot longer on it to make it look better, nobody wants to buy a game that would not even be very 2600 graphically competitive to play on their 7800. On a whim, I also picked up the binary to play on an emulator (and by the way, the game does have a battery feature). This got me to thinking though, if you have the Nintendo code, how difficult would it be to change over to 7800 code? Would it be changing a few simple values, or would you basically need to re-write the entire game? Anyway, yes it is ambitious for the 2600, but not impossible. A lot will be lost graphically, but I think most of the gameplay could be salvaged. I'm still working on my original project, and will post something back here when I have more to tell you guys. If it ever does come to fruition, I will not sell any carts of it anyway, because of copyright issues (but I will likely take that same engine and make it into a similar game that could go on carts).

You really only REQUIRE three things... 1. text editor (I use Notepad) 2. emulator (I like z26, but there are a few others) 3. DASM (which you have) Once you create binaries, you can send them to the site administrators here, and they can burn them off for you. Of course there are lots of other tools which are helpful along the way too, here is a good place to start for your specific question (Lesson 1 talks about exactly this). It sounds like you may have some coding experience, so I'm not sure how useful the rest would be to use. Also, here is the information for AtariAge's homebrew services. -JD

I'm not sure exactly what to do with this, but I ran across a disassembly code for the arcade version of Tempest. I know it's 6502, but it looks nothing like what I'm learning for the 2600. I thought maybe some guys here would find it helpful and be able to use it. Tempest.ZIP I think there may be several versions of this, try googling The Tempest Code Project for further details. -JD

You guys should check out this thread... and please forgive my ignorance. And for the record, I was in TN yesterday... stopped at Graceland, it was a lot cooler than I thought it would be. If you don't want to read through it, I think the conclusion was pretty much that is possible, but you would need specially designed games in order to play online. -JD

I've been thinking back to when I posted this originally lately, and thought I would weigh in on this subject again. I've told about my experience before in other places here, but will write it again for people who haven't seen it. I took two semesters of C++ and one of Visual Basic, all about 4-5 years ago. This just covered the basics and with the single exception of loops, has really not helped me. In other words, there is no way I could today (or then, for that matter) program a playable game in either language. I looked up my last test in C++, and it was to make a program that would act as a store inventory and track the amount of x item left for 10 different items. The clerk would type something like "sold joystick" and it would have to track that there was one less, and tell the clerk what if any were there upon command. Very basic, and for all intents and purposes I think it is safe to say "I have no previous programming experience". I have spent the last few months really studying all the code, books, tutorials, and old threads posted here to try and learn Assembly. While my efforts have for the most part paid off (at least in the sense of my 2600 coding abilities ) I really don't think most people have the combination of time, motivation, and maybe in some cases the ability to do this if they have never programmed before. So the real question is whether or not this is possible. It was interesting to see how different people responded, and I think in some sense almost everyone who did is correct. The short answer is yes, it can be done... to an extent. The reason a lot of games that exist look similar is because the limitations of the machine forces them to be. So when a new idea came out, other people instantly jumped on that idea and created similar games. You could take a few of these different "genres" (for lack of a better term) and implement them into a code generator. For example, if "multi_sprite_side_scroller" was an option, it could follow games like frogger or freeway. While you couldn't create Go Fish! with this, you could maybe make a game where you are a baby turtle, and have to make it to the ocean (at top of screen) while animals go across the screen looking to "eat" them. Three lives, and you are done. Each time you make one, the game speeds up. Ok, it's lame, but it's still an idea for a similar game. Other "style" games it could recreate: 1. Combat (was mentioned earlier) could become say "ninja" and flip ninja stars instead of 50 mms rounds (even though they look exactly the same). Or, change the sprites to cowboys and change your joystick to a different controller setting and play a western shootout. 2. Space Invaders... into something. 3. Multi-Sprite scroller as mentioned above 4. Side scrolling game where player is at edge of screen. It could be in space, in the air, in water, in a cave, etc. Once this option was picked, those could be further options. Think Chopper command or Armegaddon! where you have to dodge incoming asteroids in order to land on the main body to blow it up... only you never get there 5. maze games (pacman) 6. room based games (adventure) I had came up with a few other generic ideas, but these are the ones that stuck. It would not be possible to really create an "ending" to these games without actually coding one in, so the program would need to keep score and or maybe reset itself if a playfield is "finished" or player is killed. Speaking of Pacman clones, probably forget the dots or the ghosts... probably something two player only. With such limitations, it would be impossible to create anything cart-worthy. I think this tool would have two main uses: 1. create a very simple 1 player only with no real AI or 1 vs. 1 game that someone couldn't otherwise create by actually coding it. They could play it on their own computer or burn it off on a cart for themselves. Since these games are really basic (and would be easilly known to have developed from the tool) they shouldn't really be sold to anyone. Or take your new game and post it as a game pitch. If it's already visible, then you know it is possible and you won't be wasting the time of other programmers with something like this. 2. a development tool for programmers. This would be a super quick way to see what a game might look like and if it is worthy of your further efforts. I think it's possible and wouldn't be terribly difficult to create, especially if several people worked on it together. One person could create something like the player movement subroutines and this could all be brought together using include files from a javascript creator. It can be done, and I think it would be semi-useful. I'm off to Alabama for up to a week, I'm interested to see what comments will await me upon my return home. I think this would reach a bigger audience than batari's program, but would also not be quite as useful in creating games either. Like everything else, it's always a trade off. -JD

A friend sent me this link, which I thought you guys may (or maybe not) find interesting. Rap of video game history. WARNING! While this isn't a porn site or anything, it does have like adult website ads or something all around where the video plays. So it probably isn't safe for work or around kids in other words. The video itself is of a trio of teenagers rapping about being the 1337 (LEET) of the video game world from the Atari through today. -JD

I got tired of looking at my Dodgeball code yesterday, and started playing around with sprites for this instead. Right now everything except the drakee sprites are limited to 8 pixels, and they are 16. Some I'm kind of proud of (scorpions), and others I just hope people will be able to recognize (ghosts). Anyway, here is an idea of what enemies could look like in a 2600 version. The dungeon creatures are a little weird, and I put them against black to better show what they might look like. Anyway, feel free to improve my designs or finish the enemies I didn't get around to creating. And since it is just a color change, don't worry about the magidrakee, unless it is a new design. I also have something special in mind for the Dragonlord, so while you are free to play around, keep in mind that if I ever get to this game, I will probably not use your idea for him. Thanks for looking! -JD Edit- I should have included my ideas for the hero sprite as well. Also, the dragons are going to require 16 pixels as well, I was trying with 8 and decided that there is pretty much no way to do them. If you are unfamiliar with DW, here is a link to the enemies in the game

yep, it's a scam... best "hidden" of all I've seen so far. As for whether or not the information is real or not, that's another question. As for the retailers selling them "at price", it isn't going to happen. A "very small" markup is still a relative figure. They take up a large amount of shelf space, so despite their high turnover rate (right now, not in six months), I would say they are making no less than 25-50 per system. The $275 figure this scam quotes is probably a fairly accurate estimation. Most items retailers sell have about 60% of the final price as markup (ie- a 20 dollar item costs them 8 bucks). The biggest single exception to this is Wal-Mart who sells their 1 or 2 lowest priced items in a product (lets say TVs) at or below cost. As you probably are aware, this is just a ploy to draw people there, who rarely purchase this product anyway and will buy a tv somewhere in the middle range that is equal to other retailers, if not being marked up $10 or $20 more than competitors. Thus, most of the time they are selling the same items for a higher price, and the customer thinks they are getting a deal because of the "always low prices". And to think the FTC made them change it from "always the lowest price" because that statement was misleading. Okay, my Wal-Mart rant is done, it belongs somewhere else. However, I'm pretty sure neither them or their competitors are "taking one for the team" with this console or any other. And if they are, it is in terms of making a smaller percentage of profit. Having a large overhead and low profit percentage (as this system being sold at cost would contribute to) is the biggest sin in retail, and the big retailers are way too smart (even the dumb ones like KMart) to allow this to happen for any product. -JD

and one ended in BIN... $390. doh! Hope they used PayPal

That is pretty sweet... I thought they were umm.... lip sync playing? As it goes on though, it's pretty clear that it actually is them.

Yeah, I don't have much empathy for the people who buys these either though. I mean, who jacks out several hundred dollars without reading what they are going to get? The real losers here are the kids, half of whom probably won't get anything (since the parent's aren't getting their money back). How would you like to call your friends over Christmas break... "hey Billy, wanna come over and check out the pictures of games on the box we could have been playing if my parents could read??" As for the offenders, they should have their ebay accounts revoked for intentionally misleading buyers. This is exactly why I don't use ebay much, but that's another subject. However, when I do, I'm also careful to read exactly what is being sold because you see this kind of thing way too often. Yet with REAL items like prototypes, they seem to crack down immediately if they aren't listed "correctly".

As far as I'm aware, none of the bit hacking programs are able to change colors. In order to change colors, you need to change the actual colors in the code. If you have Distella, you can use the rom to create a .asm file. Once in the .asm file, you would search for the colors and try changing them. Once you are done changing them, you would need to use DASM to recompile the code back into a binary file (the rom) so it would play in an emulator. You can get DASM here. You can get Distella here. Tips for changing the colors in the code: A hexidecimal color chart can be found here so you have an idea what color you are going from and going to. The top chart is for NTSC (USA) and you would use the number going across first. Once into the code you want to look for things such as this: lda #$00 sta COLUPF lda #$28 sta COLUP0 lda #$0E sta COLUP1 lda #$CE sta COLUBK lda is loading the color and sta is storing it. #$00 is the way black is written before it is stored to COLUPF (playfield). To change the playfield color from black to say, yellow simply type #$1E instead of #$00. COLUP0 = player 1, COLUP1 = player 2, and COLUBK is the background color. Missile 0 is the same color as Player 1 (ie- player 0), and Missile 1 is the same color as player 2 (player 1). The ball will be the same color as the playfield. Usually this code will be near the top of the source code, but more complex games will have it in the middle if sprites are repeated or colors change a lot for some reason. I know it is a lot of work for simple color changes, but as far as I know it is really the only way to do it. If you're willing to go to that much work for colors, I suggest you check out Andrew Davie's programming tutorial here. This is a quick and dirty help guide, and far from being complete but I hope this helps you accomplish your task. -JD

There are tutorials for programming in Assembly here and here. The first is more complete, but the second has an example of moving a sprite around with a joystick. -JD

Umm, the way that reads is that I didn't really learn anything, but just thought I did Which likely is very near the truth... they are just "favorite" threads and the academic value was not really considered when I posted them. I will however attempt to entertain your question with a few brief lessons that can be learned from each thread. 1. Atari Landfill Adventures- some people surely must believe that gravity doesn't exist because they can't see it or hold it in their hands. Several media outlets of the 15th century got together to create this massive conspiracy for no logical reason. The lesson here is the old...err... proverb saying never argue with an idiot, they will drag you down to their level and then beat you with experience. 2. Knight Rider 2600 Project- how not to approach a game project. This guy announced his game and did everything backwards. There is a process to producing a homebrew, and he was chastised for not going about it in the right way. His reaction to this was not uncommon to the internet- saying he was a bigshot and blowing up, then promptly disappearing. I'm sure the forum is eagerly awaiting his game, as 2006 is almost here. 3. AtariAge Photo Thread- be a sport and introduce yourself. Find out who everyone in the forum is, it will make it more fun in the long run to know your Atari brethern. 4. Tempest's Meltdown Prototype- umm, wow. This will sound negative, but doing the right thing isn't always rewarded. The villain seemed to get the best of our hero in this tale. My heart goes out to the man. 5. Tronman Hack- be really, really sure that the actors are not wearing underwear if your exact replica requires the use of spandex. However, if you do make this mistake, having a sense of humor and the ability to laugh at yourself will bring good things to you in the end. If and when you get your fame, be able to handle it with grace like our friend Jay Maynard has. Talk to the people you should and get permission to do things. Doing it the right way led to a new friend of AtariAge. 6. Krokodile Cartridge- pay attention to the entire forum and not just the parts you are interested in. As homebrew authors know, emulation will only take you so far, and had I paid attention when I first got here, I wouldn't be in search of one of these. Any different thoughts? -JD

Nevermind, Mr. Kroko is back to work on these and I am just going to wait for the second wave to come out. Thanks to everyone who looked. -JD

I don't think there will be a "final word" on the prototype, since he claims he doesn't even know whom it was sold to now. I agree the guy is a little off-center, but you have to remember he's young. At first I didn't believe it either (and I'm still not convinced), but you need to be careful about calling him a liar too. The part where I started to take interest was when I found the website of another guy claiming he has the same proto. You know the saying, where there is smoke there is fire... Anyway, just to clarify, I didn't post them as "proof", but rather found them interesting and decided to pass them along. I for one hold hope that it is real and will be made available in some form, but also know that Vancouver is an odd place for it to show up... -JD

Looking forward to progressing on my projects! My next entry will be two-fold; 1. my favorite threads every newbie should read and 2. a summary of my projects. Look for it sometime next week. -JD

So this feature is already implemented in the next version of batari Basic? Does that mean we have 74 cycles instead of 76 to start with? Or will it be even less than that due to other things in the programming?

Well, since this topic has gotten no response so far, I thought I would try to start things off by sharing what I know about missiles (which is not all that much). First there are two missiles (three if you count the ball) and each missile is associated with with one of the players. The player 0 missile will share a color with the player 0 sprite, as will missile 1 with player 1. The missiles start out at one pixel wide but can be expanded into 2 pixels, 4 pixels, or 8 pixels. The width of the missile can be changed on each scanline. The missile’s height can be a single pixel, or can run the entire screen (192 pixels). From Alien Bill’s tutorial: “the Atari can tell if any 2 of its 6 items (players (P), missiles (M), ball (BL), and playfield (PF)) have collided. There are 15 1-bit latches. (Do the math...the playfield could've hit any of the other 5 object, the ball could've hit any of the other 4 objects (we've already counted the playfield/ball collision) etc.... 5+4+3+2+1 = 15.) [table inserted here with values] What this says is if, say, Missile 1 has hit Player 0, then D7 of CXM1P will be 1. If the two missiles collide, then D6 of CXPPMM will be 1. There's one final trick which seems confusing at first but is secretly useful: when two things collide, that latch stays set with a 1 even if they then move apart. Latches stay set until you hit the register CXCLR, which resets all the latches to zero. So that way, you don't have to check for collisions every time if you don't want to. In practice, most games will read all the collisions they care about and then hit CXCLR every time screen frame, but it's nice to have the option.” If you are a beginner and have not already done so, please check out the following code, which as I said in the first post can be found at Kirk Israel’s website. missile.ZIP And if you aren't a beginner, please correct all the mistakes I made and add to this!