Gemintronic

As a start I'd make music with the Music and Sound Editor and then use CREATE .BAS to make a template for my game. You can add your title screen to music.bas and the rest of your game. I personally merge the code from music.bas to my main program manually which can be a pain. I usually add a line in the title screen loop like: if joy0fire then goto main where main is the main routine of your game. The post for the VisualbB download also has these helpful links: http://www.randomterrain.com/atari-2600-memories-batari-basic-vbb.html http://www.tinkernut.com/archives/1396

I don't comment in code because I'm lazy/sloppy. Descriptive variable and constant names are a must though. Batari BASIC kernel features are pretty much what the 2600 can do. However, assembly lets you make sacrifices for better features in another aspects of your game. Disclaimer: Born and raised BASIC/4GL programmer. It's your programming background that determines whether BASIC first or assembly first is better. Most people I know were raised on farm fresh MS Basic and worked "down" to assembly routines.

You got yer kernel options rockin'? Something like: set kernel_options pfcolors Random Terrain has an awesome page that details the options http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#kerneloptions

Remember to set the Region to NTSC before editing yer sprite. Otherwise the colors will be off when you drag-and-drop the sprite into your code. Also remember to SAVE ALL before dragging and dropping your sprite as the changes aren't applied until then.

No prob. Actually, it's all eye candy. Your binary seems to have level/tile loading which is beyond me at the moment. I just wanted to show what the potential for side scrolling was. As RevEng noted there may be cycle issues and I couldn't get it to play on a 2600 emulator for PSP. I think how a side-scrolling engine would work is the level data is stored as strips of 8 vertical tiles. Each tile would be a 4x4 block of pixels (Assuming a 32x32 pixel playfield). When the player "moves" right the pfscroll left command would execute. Most of the screen looks to have scrolled but the last vertical line of pixels gets wrapped around and is now effectively garbage. We must draw over that wrapped line of pixels with a strip from our level data. We determine which strip to load and then further determine which line of pixels from the tiles to draw. Using pfpixel the routine should then draw that vertical line. As a side the rem'ed out lines are code I used to determine when I ran out of playfield data. The turtle like object between the pipes is actually just a leftmost pixel and rightmost pixel to demark the edges. The rem if !pfread(15,26) then pfscroll right and rem if !pfread(18, 26) then pfscroll left were commented out collision detection using playfield pixel reads instead of collision commands. Remember: the player is stationary but the playfield pixels move! sidescroll.bas

Sorry to post again but I think it's possible. This is a test without level data loading: While up-down scrolling is pixel perfect I think Batari BASIC can only do side scrolling a playfield pixel at time. Basically, pfscroll and then load each new tile column a vertical line of pixels at a time. sidescroll.bin

Hey, this pack looks good. I always liked the option in MAME to sort by different criteria. I think by company is a valid and useful organization. Gives me a better idea of how I'll arrange mine when I finally get a 2600 ROM dumping attachment for the Retrode. Nice work!

Spent a good amount of programming time going around in circles dinking with the psueodo random number generator code in my 256x256 screen 256 level test code. Helpful comments posted in this blog gave me ideas to shorten and/or better my code but everything backfired. All I got is less random output. Not a testament to the quality of advice but rather my own inexperience. Solved the infinite staircase up -> staircase down warping loop by - wait for it - repositioning the staircases. The downward staircase is now to the top right-hand side compared to upward staircases. This may turn into a game yet. I'm thinking of adding in 8 items to collect as a main goal. Side scrolling and platform physics are peaking my interest. I may spawn off another process and make a test program for them too.

I asked a similar question in the Harmony cart topic and my interpretation is we can go so far as 32kSC. Batari (at the time) indicated DPC features are in the works for bB. Another thought is Batari BASIC has inline assembly support. If the Assembly Gurus have posted examples it might be possible to access 400k on the Harmony cart.

I choose Ninja Princess but would have really liked to have seen Solomon's Key as an option

I hope you continue to challenge this, er, challenge! Side scrolling platforming would be awesome! I'm trying to scroll and clear the far side that's scrolling then add in the new blocks. Timing is a big deal and so far I've not got it right. UPDATE: Check out the code in this topic: http://www.atariage.com/forums/topic/148427-vertical-scrolling-through-a-playfield-that-wont-fit-the-screen/page__hl__defaultbasbin It's smooth scrolling vertically but maybe the code can be modified for side-scrolling..!

Thanks for the tips! Er, I'll have to get me some learnin' in order to understand what a LFSR PRNG is much less a typical one. Low fidelity serial register pseudo random number generator? So much to study The 16 bit number option sounds good. If the score can be broken down into 8 bit numbers maybe I can likewise split the results of the 16 bit random number. Trouble is I'm putting several 8 bit values into the melting pot. I can hardly cope with the score or back up it's values. 16 bit numbers and Batari are another subject to master!

By mixing the worldx, worldy and dungeonlvl variables through bit shifting passes and addition passes it seems to work well enough. I now have proven to myself that 256 level 256x256 screen dungeons can happen. With the bit shifting and addition passes screen to screen variation is enough. I'm starting to add in room objects such as stairs going up or down. The only glitch so far is some levels will have a stairway up which leads to a stairway down on the next level. You can get stuck in a loop that way. The nice thing is, now that I know such large levels can be generated, I can use the same code for any game including RPGs, platformers, etc.. Here be the amateur code for determining what type of room is at a particular worldx and worldy for a given dungeon level: calc_roomtype temp1{0} = worldx{7} temp1{1} = worldy{6} temp1{2} = worldx{5} temp1{3} = worldy{4} temp1{4} = worldx{3} temp1{5} = worldy{2} temp1{6} = worldx{1} temp1{7} = worldy{0} temp1 = temp1 + dungeonlvl temp2{0} = worldy{7} temp2{1} = worldx{6} temp2{2} = worldy{5} temp2{3} = worldx{4} temp2{4} = worldy{3} temp2{5} = worldx{2} temp2{6} = worldy{1} temp2{7} = worldx{0} temp2 = temp2 + worldy temp3{0} = dungeonlvl{1} temp3{1} = worldy{4} temp3{2} = temp1{6} temp3{3} = dungeonlvl{5} temp3{4} = worldx{1} temp3{5} = temp1{3} temp3{6} = temp2{2} temp3{7} = worldy{0} temp3 = temp3 + worldx temp1 = temp1 + temp2 + temp3 + dungeonlvl if temp1 = 0 then temp1 = 255 rand = temp1 room_type = rand return

Had to fight with a weird compiler error. Hopefully the last time I'll see "error: Value in 'cmp #256' must be <$100." Also discovered rand didn't change room types often enough. Seems to work better if I swap bits around in the result. Here's an example of what I'm talkin' about: changeworldx if worldx = 0 then worldx = 255 rand = worldx mytemp = rand room_type{0} = mytemp{4} room_type{1} = mytemp{1} room_type{2} = mytemp{3} room_type{3} = mytemp{5} room_type{4} = mytemp{7} room_type{5} = mytemp{6} room_type{6} = mytemp{2} room_type{7} = mytemp{0} gosub changeroom bank2 return

Wow. This topic is solid gold for anyone getting into homebrew. Thanks for the input! So far I've been able to avoid annoying people (too much) by posting %99.99 complete games. I think for longer games It'll be ramblings in my blog and builds with solid progress in a topic elsewhere.

I have a definite urge to collect homebrew ROMs as they allow me to enjoy classic gaming on the go via a Harmony cart, PSP, Dingoo, XBox, GBA, etc.. Physical copies are a different story. With small runs collecting homebrew is not a game everyone can play or enjoy.

Got a good deal from a local video game shop. 4 boxes full of common to rare 2600 carts. 2 more boxes of duplicate commons. I NEVER WANT TO SEE ANOTHER COMBAT CARTRIDGE AGAIN! Sorting out the duplicates was a messy, time consuming, er, mess. Plan on shipping the dupes to AtariAge but the store is closed and my wallet is empty. Shipping is gonna be killer. My programming for the day consisted of digesting Batari's answer to my multi-bank function question and experimenting with rand. I've tried to make levels using pseudo random numbers on the PC and failed. In Batari BASIC it's actually working. So far I've got a vertical dungeon that is 256 screen big. I figure I can alter the results of the pseudo random number generator to effectively have a 256 x 256 screen dungeon with zero storage footprint. It's 2am and I STILL have carts to clear off my bed.. not thinking so good.. hopefully will experiment more this weekend. Night everyone!

Not to invalidate the original posters opinions but I've had better luck using pre-paid credit cards using Google Checkout. I'm glad that payment option is available.

Thanks for the replies so far. I'd like to use functions multi-bank if possible. I noticed Batari's Platformer example seems to only call the functions from the same bank. So it still doesn't prove functions can work across banks. Workaround seems to be setting aside a variable or two as arguments and then calling a gosub that uses those variables.

So, I'm trying to convert Game Maker 5 constants, subroutines and functions over to Batari BASIC. I'm trying to keep my library of routines in the second bank. How do functions work with multi-banked games? Do they at all?

I see at least 6 sprites on screen. I see 2 6 digit scores and 1 timer in the middle. I see a horde of mini-me pac man icons to the bottom middle of the screen. Not to mention a nice maze with pellets and power pellets. How would you make a kernel that can handle these elements? Your experience with yer Castlevanina project obviously tell you this is a possible goal. As an exercise could you explain what you think such a kernel would be like. I would assume some of the challenges are the same as the people who attempted a Super Pac-Man port. Flicker was a big problem for them (in my opinion). If you and e1will see promise in this I'm sure it's possible. I'd like to hear about some of the sneaky super ninja techniques that would make this possible

While you're waiting for a proper response (from someone with real experience) I can think of one workaround: In my CandyBar game I adjusted the pfheight for the top rows to be small for the CANDYBAR title. For just the title it *seems* like the resolution is higher. In-game I could have adjusted the pfheights to be even once again.

As a continuation of SeaGtGruffs explanation on how multiple score mini kernels are posible I was wondering if the standard and multi-sprite kernels could be used in the same game. As my wildly inexperienced eyes would see it, you just create a main loop and call a gosub for each kernel. One would dig up the assembly for the kernels and just run them in-line. Am I making any sense at all? Is this just a pipe dream since you must specify one kernel at compile time?

Picked up an Alien Chase tabletop game for $12 bucks in box with manual. I see this thing for $70 - $120 on ebay. http://www.handheldmuseum.com/Tandy/AlienChase.htm Neato design as it doesn't have two screens. The second player just sees the other side of one screen As a side I saw some grey NES carts at a flea market. One said "650" and the other said "Arbian Nights 1100 in 1" Are they rare? Should I pick those up?

Coleco Well, when I was a kid the Smurfs game pretty much ruined it for me. Xbox Bought it for Morrowind and never saw another good title. If not for XBMC my XBox would be in the closet. GameCube Never did dig the N64 or GameCube controllers. Got Mario Sunshine and got tired of it. Used the GameCube for its GameBoy Advanced player. N64 Got sucked into the "Wowie Zowie it's 3D Mario ZOMG!!!!" phenomenon. Almost every game afterward was a Mario 64 clone to me. The utter betrayal of faith that was Castlevania 64 made me put a stake through it.