system to program a 7800 game?/How to go about

[Jinks]

Hello, I would like to program a 7800 game, I can get a working tested 600xl atari computer for 35 bucks, would that be a decent computer to use to program a 7800 game? The bigger question is that computer would work for programming can you list off what other components I would need to program and test a game and where they can be purchased?

 

Secondly, I am starting out at square one and know absoultely zero about programming an atari game and my goal is to make a decent game, would I be better to stop while I am ahead and let the pros do it and visit atari age store, or start with??

 

Help is appreciated, Keep in mind when answering question #2 I work full time am 33 years old work as a Truck Technician, common law wife, 2 kids, 3 cats and a Bunny+play in a band. Game experience, used to do basic on a trs-80(simple programs) been into atari playing/collecting for almost 30 years.(So yeah zero atari progamming experience but lots of interest..

[Rybags]

You'll have much more success doing dev-work on a PC. Then just test in an emulator.

 

Not sure about all the options for running your homebrew on a real 7800, but there is the Cuttlecart 2, which by all accounts is rare and probably >$200 to aquire.

Option 2 is to burn your own EPROMs and use an old cartridge board.

Option 3 would be to get one of the expansion boards that are coming out in the near future (thread here elsewhere). But I'd guess that to be another $100+ option.

 

If you're starting from Square 1, you're probably better off just getting an 8-bit computer - at least then you can start out with Basic then progress to 6502 Assembler. Once you've got Assembler skills, then you in theory could do stuff for 2600, 7800, Lynx, Atari 8-bit computer, not to mention the dozen or so other computers and consoles that use a 6502.

[+GroovyBee]

As Rybags stated, development on a PC and testing in an emulator is the way to go.

 

If you don't have any programming experience then diving into a constrained system like the 7800 using only 6502 assembler might kill your game ideas. I'd recommend learning a high level language like BASIC on the PC to try out your ideas first. You might also think about doing a course at night school (if funds and time permit) or buying books and teaching yourself. Either way you need to have time to sit down and code and the patience to complete the project. Being naturally inquisitive and willing to experiment to find solutions to your problems are also good skills to have.

[Harry_Dodgson]

Hi,

 

I did "Combat 1990" on a PC using an ST emulator to assemble the code with the recommmended 7800 dev system assembler (MADMAC). I used a couple of 7800 emulators to test the program (but I should have tested on real hardware). I used my favorite editor, SciTE, to edit the code though it doesn't syntax color 6502 assembly. There are text editors out there that can though.

 

For someone starting out, I'd recommend a higher level language as assembly language is a steep learning curve ( even 6502 ). Unfortunately, I haven't tested Quetzalcoatl C with the features that I added for 7800 games and I don't think any other languages support the 7800. The thing to remember is that the 7800, like the 2600, doesn't have a bitmap for background graphics or sprites. That makes getting anything simple on the screen NOT a simple process. There also isn't a BIOS to assist with common routines.

 

Harry

[+GroovyBee]

Unfortunately, I haven't tested Quetzalcoatl C with the features that I added for 7800 games and I don't think any other languages support the 7800.

 

I have adapted CC65 for the 7800 and written several games and a custom sprite, sound and joystick handling library. Finding time to document everything is the hard part . Its on my list of things to do.

 

The thing to remember is that the 7800, like the 2600, doesn't have a bitmap for background graphics or sprites. That makes getting anything simple on the screen NOT a simple process.

 

Not quite true. You can have a full screen video frame bitmap. See my BBC micro port of Tempest on the 7800 for an example of that.

[Bruce Tomlin]

It's really a good idea to have some way to test on real hardware, because emulators generally don't emulate the limitations of the Maria chip.

 

In my case, I used a CC2 with a serial downloader. That gave me minimum turnaround time because I could completely automate the process aside from pressing a few buttons to get the CC2 ready to receive. If I had to write to an MMC card and swap it between computer and CC2 every time, I would have gone nuts.

[+GroovyBee]

It's really a good idea to have some way to test on real hardware, because emulators generally don't emulate the limitations of the Maria chip.

 

Yep! Testing on real hardware as soon as possible is a good thing to do. My version of the ProSystem emulator will visually flag up MARIA zones that are problematic so its easy to see them while your game is playing. If you create a ProSystem save state file my a78psd utility (available in this programmer section) will decode the Display List List and Display Lists in each zone so you can see what your code created.

[EricBall]

As everyone else has indicated, to start programming any PC and an emulator will get you going. Start simple and add complexity over time which should avoid the problem of the emulator doing more than the console is capable of, at least at the beginning. (Starting small and incremental enhancements is also good to keep up your enthusiasm & drive.) And once you have something working, reach out to the community. You may not have a RAM cart, but others do and many will help at least sanity test your work in progress.

 

However, I have to ask - if you have no assembly experience, why start with the 7800? You are probably better off starting with something which can be programmed at a higher level and with better documentation and a larger homebrew community. batari Basic for the 2600 comes to mind. The problem with the 7800 is it requires a lot of code to get something to appear onscreen. The 2600 is a little easier in that respect (although some code is required to make a stable screen).

Edited September 2, 2010 by EricBall

[Jinks]

Answer to why the 7800 = I got a 7800 a couple of years ago and bought 30-40 games for it(forget how many) and am interested in what the system can do, there is lots of new development such as the h2 cart and expansion module(which both I will be purchasing as soon as they are avaible) I would like to make a racing game, or just go over all the games that have crappy sound, and redo the sounds on them and give out the roms so people can have a upgraded game to play, as I think the sounds are 30-40% of the game play. Which the TIA is mostly annoying and off sounding on most all of atari games.

Thanks for the many responses so far. I have 5 days off from work and will look into some of your ideas on how to learn programming. I see most of you are quite experienced at programming and there is not too many people like myself totally clueless on here.

I don't like the idea of going through and learning everything about basic and programming there if it would not directly get me to making a 7800 game. The way I see it, making a 7800 game will take time and practise, I dont have tons of free time so may as well put all efforts on the product.

I dont get 6502 "assembler" Is there defintions of commands and lines that are used to do different things in the program like basic?

[gdement]

I dont get 6502 "assembler" Is there defintions of commands and lines that are used to do different things in the program like basic?

Assembly language has a direct 1-1 mapping to binary machine language - it doesn't add any capabilities that aren't built in to the chip. This gives the programmer maximum control, but there's no abstractions to make things easier, as there would be in other languages like BASIC.

 

 

If you want to look into 6502 assembly, then visit www.6502.org

They have a ton of documentation for the 6502 processor, but I don't know if they have anything that's good for a beginner to learn from. They do have some books in the Documents->Books section, so maybe something in there would be worth a look.

 

It would be a steep learning curve to jump straight into assembly, but some people have done it. Personally, I started with BASIC when I was a kid, then C, and didn't learn assembly until later.

 

The Atari 8-bit computer won't be useful for programming the 7800, *but* it's a convenient way to learn BASIC, and BASIC is the easiest way to learn the fundamentals of programming.

[+GroovyBee]

I would like to make a racing game, or just go over all the games that have crappy sound, and redo the sounds on them and give out the roms so people can have a upgraded game to play, as I think the sounds are 30-40% of the game play. Which the TIA is mostly annoying and off sounding on most all of atari games.

 

To change the sounds you have to reverse engineer the game from the raw binary image into 6502 opcodes and data that can be assembled back into an exact copy of the binary again. This isn't too hard using tools like DIS6502. However, if you need to move code around to make space for your new sound handler or to add more data or you need RAM it becomes much more difficult because you need to understand much more of how the game works. In my opinion you'll need to have a few games under your belt before you attempt something like this.

 

Thanks for the many responses so far. I have 5 days off from work and will look into some of your ideas on how to learn programming. I see most of you are quite experienced at programming and there is not too many people like myself totally clueless on here.

 

There are plenty of people well on the way to making their own games.

 

I don't like the idea of going through and learning everything about basic and programming there if it would not directly get me to making a 7800 game. The way I see it, making a 7800 game will take time and practise, I dont have tons of free time so may as well put all efforts on the product.

 

Its just a stepping stone into understanding the concepts of how a game is put together. You'll learn everything from getting a reading from the joystick/keyboard, moving sprites, collision detection, maybe some simple physics, some simple AI to make the enemies more interesting, sounds, music, changing colours and loads more. From the language itself you'll learn about variables, loops, handling memory with arrays, logic and conditional statements and all the things that go on in behind the scenes to make the game happen.

 

I dont get 6502 "assembler" Is there defintions of commands and lines that are used to do different things in the program like basic?

 

There aren't really "commands" in assembly language. Have a look at the sticky links in the various programmers forums on AA for good information to get you started.

[EricBall]

Assembler is the human readable version of the processor's native language. A good 6502 example is:

 STA ($7B,Y)

Which translates to:

1. read the two bytes stored at hexadecimal memory addresses $7B and $7C as a 16 bit value (LSB first)

2. Add the current value of the Y register to the 16 bit value

3. Store the current value of the A register using the 16 bit value as an address

 

Assembler is termed a "low level language" - each instruction is a very small & simple step in the program. An Atari 7800 game will contain thousands of instructions. And each instruction (i.e. STA) can be used for multiple functions. In the above example the instruction may be creating or updating a 7800 Display List or changing which character is displayed onscreen, or ... Without comments to provide context determining what each instruction does (on the macro level) is extremely difficult. (Which is the main challenge of disassembling a game.)

 

The power of assembly language is there is nothing between you and the hardware. You are in complete control of the CPU. But that also means you need to create code for everything. The Atari 2600, 5200 & 7800 don't have bitmap displays. To display something onscreen you have to feed the graphics processor (the TIA, GTIA & MARIA respectively) the required data (and, in the case of the 2600, at the correct time). There's no plot(x,y) command, just a lot of STA instructions.

 

I understand your disappointment with the sound capabilities of the 7800. For compatibility GCS (the creators of the 7800) included the TIA from the 2600 (which provides graphics, sound & paddle inputs on the 2600). For cost reasons Atari didn't include the POKEY from the 5200 (which provides sound & paddle inputs). Thus the 7800's sound is the same as the 2600: 5 bit frequency divisor (32 "pitches") and 4 bit LFSR selector (10 "waveforms") which produce around 200 usable "notes". But the notes aren't like a piano, nor is there a lot of ability to generate sound effects.

 

I also wouldn't expect to accomplish anything, other than learning some basic assembly, in 5 days. But if you're up to the challenge, I'd recommend starting with the 7800 Software Guide. It gives all the details of the 7800 hardware and Display Lists.

[+GroovyBee]

Assembler is the human readable version of the processor's native language. A good 6502 example is:

 STA ($7B,Y)

 

There's a type in there Eric, because that's an invalid addressing mode. To match the description you need to use "STA ($7B),Y".

[EricBall]

There's a type in there Eric, because that's an invalid addressing mode. To match the description you need to use "STA ($7B),Y".

Quite correct. What I gave is not a valid NMOS 6502 addressing mode. STA ($7B,X) is a valid mode but does the add before the address fetch.

[Jinks]

To say the least, I got lots of reading to do... I think step one understand the system with the link you just gave me, which has some examples of the language, next which will be in a couple of months would be study game programs to see if I can understand what is going on, then after maybe 6 months or so, think about tring to write something very basic.

These might be unrealistic goals, but time will tell.

Will keep yall posted.

[+GroovyBee]

To say the least, I got lots of reading to do... I think step one understand the system with the link you just gave me, which has some examples of the language, next which will be in a couple of months would be study game programs to see if I can understand what is going on, then after maybe 6 months or so, think about tring to write something very basic.

 

Personally I'd skip the "trying to understand other peoples code" part. You need to have a good grasp of variables, loops, user input/output, logic, if..then..else and a load of other stuff before you get to that stage. Start with something simple like working out how to add 5 numbers together. Then move on to printing the numbers you entered in ascending/descending order things like that. Then a guess the number game or hangman. Some of the old 8 bit era books on learning BASIC are ideal tutorials for this sort of stuff.

[Jinks]

Yeah it would probably(for sure) be to complex to understand the code of a completed game, will skip as suggested, I have read books 20 years ago on the basic language and remember things like

10 cls

20 print "Atari 7800"

30 goto 20

 

which would of course flll the screen with "Atari 7800" over and over again. but in grade 5 no other kids knew how to do that in school on the old tandys in monochrome sitting on the multi-purpose room..

 

Yeah I know this is gonna be much more difficult.

 

and commands like if, then and else, end and so on all made sense to me.

 

and remember typing page after page of programming on a trs-80 and saving it onto a cassette tape. It was a two player game that you could control two + like things and control with both joysticks and shoot each other. i think it was called space gun or something like that, it seemed like a simple language that almost a idoit could make sense of each line and guess what each line would function as. I took some computer courses about pascal in high school that I forgot everything about, It seemed nothing like basic. but it made more sense than 6502.

 

This assembler language to me has no real plain and simple function to each line(although it must or why would it be there) also the task of figuring out what commands you need to do to activate and call upon the particular chips such as maria tia and so on, also worry about memory and hunderds of other things. What order does the assembler language start? The first thing does it need to know is the opening screen and sound, with the cpu ready for all the inputs and so on. Do not todays games have graphics engines and stuff that make it easier to make games? Stupid question of the day why then not a atari 7800 have a grapics engine, or the code is the engine and thats why game designers would take bits from other games such as sounds and graphics and use them on there games because they are proven.

[+GroovyBee]

Do not todays games have graphics engines and stuff that make it easier to make games? Stupid question of the day why then not a atari 7800 have a grapics engine, or the code is the engine and thats why game designers would take bits from other games such as sounds and graphics and use them on there games because they are proven.

 

Such a thing exists. I have created a game development library in 6502 for use with the "C" language using the CC65 compiler. My games Wasp! and Worm! were written using it. I just need to knuckle down and document all of it.

[EricBall]

This assembler language to me has no real plain and simple function to each line

 

No, each opcode is well defined and performs a very distinct operation. However, because each opcode is very simple, you need many of them to accomplish each task. So k = i + j would break down into at least three instructions in 6502 assembly:

 LDA i  ' load the byte in RAM with the label i into the accumulator
 ADD j  ' add the byte in RAM labeled j to the accumulator
 STA k  ' store the accumulator to the RAM address lableled k

(Labels are handled by the assembler and would need to be defined elsewhere.) Now imagine what a more complicated operation would be. Writing in assembler requires you to think in small steps.

 

what commands you need to do to activate and call upon the particular chips such as maria tia and so on, also worry about memory and hunderds of other things.

 

All of the chips are controlled via specific memory addresses. So STA WSYNC writes a byte to a memory address used by MARIA which causes it to halt the 6502 until the start of the next line. And yes, although the assembler will do a certain amount of work for you (turning labels in to addresses, instructions into binary values, etc) you, as the programmer, are responsible for most of the work.

 

What order does the assembler language start?

 

I'm not sure what you are asking. On startup the 6502 reads the address stored at the reset vector (I can't remember the specific address offhand) and starts executing at that address. On the 7800 that's the BIOS ROM which displays the Atari logo then tries to determine whether the cartridge is a 2600 or 7800 cart then executing the cart. But to start learning 6502, you might want to try Assembly In One Step.

 

why then not a atari 7800 have a grapics engine, or the code is the engine

 

You need to remember the 7800 was first released in 1984 and it contains only 4K of RAM and the CPU runs at 1.79MHz, i.e. a thousand times slower than today's computers and a million times less RAM. The 7800 does have a graphics engine - the MARIA chip, which is capable of displaying hundreds of sprites onscreen and can create a display without the processor having to update it every line like the 2600. What the 7800 doesn't have is a graphics library (other than the one Groovy Bee created for his use). But that's a good thing because you can write your code optimized for your game rather than dragging in functions and features which you aren't using.

[+GroovyBee]

What the 7800 doesn't have is a graphics library (other than the one Groovy Bee created for his use). But that's a good thing because you can write your code optimized for your game rather than dragging in functions and features which you aren't using.

 

All the functions in my game development library are one per file. That way the CC65 linker removes any functions that aren't referenced.

[doppel]

The one thing that actually helped me wrap my head around assembly language was figuring out that the only thing assembly language really does is manipulate bits of memory, then figuring out *how* each instruction affected the memory and registers. The only real way to figure that part out is to read, study, and most importantly of all, experiment.