programmers: anyone interested?

[bomberpunk]

i'll make this short. i have programmed in Qbasic for years and have attempted on several occasions to try to understand how to code Atari 2600 games. i'm just too dense to get it, i guess.

 

i was just wondering if any of your programmer's would like to take a stab at porting one of my Qbasic games to the 2600. that would be a dream come true for me.

 

http://bomberpunk.com/qbasic/antivirus.html

 

it's an original, simple strategy game for one player called Antivirus. the website above includes a screenshot, detailed instructions/rules, a copy of qbasic (windows doesn't come with it anymore), as well as the most recent game (bas) file.

 

any takers? i'd LOVE to see this end up in the AtariAge store!!

 

thanks for looking,

Mike

Edited January 10, 2006 by bomberpunk

[Pixelboy]

Perhaps you can code a 2600 version of your game using Batari... I've never tried coding with Batari myself, but it's worth investigating at least...

[bomberpunk]

well i guess i could try that.

 

i'm guessing this is the offical site: http://alienbill.com/2600/basic/

[Zach]

I took a quick look at your screenshot. It looks like this kernel (graphics program) by supercat would be perfect for what you are doing.

 

http://www.atariage.com/forums/index.php?showtopic=79626

 

I haven't looked into it myself, but I've read that Batari Basic can be combined with any kernel.

[supercat]

I took a quick look at your screenshot. It looks like this kernel (graphics program) by supercat would be perfect for what you are doing.

997824[/snapback]

 

Probably overkill. I think the standard BB kernel would be limited to 6 characters wide without flicker, but I'd still suggest using it, at least to start with.

 

Set NUSIZ0 and NUSIZ1 to 3, COLUP0 and COLUP1 to 15 (or your favorite color), COLUPF and COLUBK both to black, and CTRLPF to 5.

 

Set the X coordinates of player 0 to 33, player 1 to 81, missile 0 to 62, and missile 1 to 86. Set the missiles to be visible for the entire screen height, and set the players to start at the top of the screen with the following repeating pattern:

...XXXXX
X..X...X
XX.X...X
XXXX...X
XX.X...X
X..X...X
...XXXXX
........

Then turn on all the playfield pixels and you're ready to go.

 

There will be 11 rows of 6 digits each. Each digit will be controlled by 3 playfield pixels (out of a group of four). The first pixel (X coordinates 4, 8, 12, etc.) will control an arrow to the left of the digit (ON=hide the arrow). The next pixel (5, 9, 13, etc.) will control the left part of the digit (OFF=zero; ON=one or blank), and the third (6, 10, 14, etc.) will control the right part of the digit (OFF=non-blank; ON=blank).

 

If you set things up this way, I think the game should be pretty straightforward.

[Zach]

Supercat's proposal looks good. I went ahead and drew a mockup of how it would look:

[+batari]

I took a quick look at your screenshot. It looks like this kernel (graphics program) by supercat would be perfect for what you are doing.

 

http://www.atariage.com/forums/index.php?showtopic=79626

 

I haven't looked into it myself, but I've read that Batari Basic can be combined with any kernel.

997824[/snapback]

While true, the difficulty in doing so can range from trivial to damn near impossible depending on the level of functionality and automation you wish to have. I'd say there are 3 levels:

 

Level 1: A kernel can simply be pasted in as inline asm. But this is the least efficient way to do it, and I only recommend it for simple kernels like title screens.

 

Level 2: More complex kernels (but those only capable of a limited number of games) should be modularized. That is add a few hooks so the bB code can access it directly, and make an includes file so you can simply specify to use the kernel as a line in bB and call it with drawscreen. Most likely you will need to specify equates for some fundamental bB variables (temp vars, a-z, maybe others I can't remember.) I should make a "kernel adapting guide" so others can do this without pulling out their hair.

 

Level 3: Full native support by modifying bB source code itself. It gives the highest level of functionality but is by far the hardest to do. Most likely, you'll have to wait for me to do this. And I'm unlikely to do it unless the kernel is capable of a wide variety of games.

 

You could do a "level 2" implementation of Supercat's kernel in an evening if you knew what you were doing.

[+batari]

Supercat's proposal looks good. I went ahead and drew a mockup of how it would look:

998119[/snapback]

That would work too... I didn't realize that the numbers were just 0 and 1.

[supercat]

You could do a "level 2" implementation of Supercat's kernel in an evening if you knew what you were doing.

998120[/snapback]

 

My 16-digit kernel is a bit of a memory hog. Not sure it would really be practical for use with bB. I wrote it intending to use it for an EPROM viewer (which would still probably be a good use). Each EPROM page is 64 bytes, so eight rows of 16 digits each is perfect.

[bomberpunk]

just so i won't leave everyone hanging, i'd just like to say i've tried messing around in BatariBasic and... i just don't get it. so i gues i'll just stick to what i know; the big ugly Q. but thanks for your interest.

[supercat]

just so i won't leave everyone hanging, i'd just like to say i've tried messing around in BatariBasic and... i just don't get it. so i gues i'll just stick to what i know; the big ugly Q. but thanks for your interest.

1002333[/snapback]

 

What don't you get? Have you looked at some example programs?

 

I think the biggest thing that may take getting used to is that if you want to keep a stable screen display you must invoke the kernel periodically. Beyond that, bB is a very limitted dialect of BASIC, but shouldn't be too horrible to work with.