EricBall

I know that in the past emulators didn't track how many cycles MARIA used, I don't know whether current emulators track CPU cycles versus MARIA cycles. The only way MARIA could corrupt registers is via a DLI which doesn't properly preserve them.

I remember in SpaceWar! 7800 I had a DLI in the first inactive zone which would just set a flag then RTI. The main code would loop on that flag instead of MSTAT. I guess you could do away with that and pop the SR & PC off the stack and make the ISR the start of the routine. Wouldn't be a bad idea to have the ISR check a flag to see if the previous frame had completed first.

https://sites.google.../atari7800wiki/ has some info on cycle counts and DLIs.

One immediate suggestion would be to try to eliminate the JSR OBJECTCOLL. Yes, it means you can use RTS to get back to the DOCLOOP, but it's costly in CPU cycles. You may have to use Branch+JMP sequences, but that's still faster than JSR+RTS. You can then also pull back the BEQ DOCNEXT into the OBJECTCOLL logic.

How big are your objects & velocities? Is bounding box good enough or do you need pixel perfect? Can shots collide? You may want to have one set of routines for shots and another for other objects. Test the shots versus the other objects and the objects only against each other.

EricBall, on Tue Jun 7, 2011 11:49 AM, said:

GroovyBee, on Tue Jun 7, 2011 12:19 PM, said:

Let me correct that. There is no publicly available HLL for the 7800. Not to say that you have any obligation to make your toolchain available to others, but your personal toolchain doesn't help the OP achieve his programming dreams. Thus, if he wants to program the 7800 in anything other than ASM, he will need to develop the necessary tools.

toptenmaterial, on Fri Jun 3, 2011 9:46 PM, said:

In my personal experience, yes; for the following reasons:

• I don't believe there is a high level language for the 7800 like bB for the 2600.
  
• The TIA is fundamentally easier to understand that MARIA. (Playfield + sprite registers versus display list.)
  
• It takes more code on the 7800 than the 2600 to get something other than a black screen.
  
• Stella has a built-in debugger, I don't believe any of the 7800 emulators have any significant debugging capabilities.
  
• More 2600 sample code available.

When you say "zero experience in programming", do you mean:

• You have no programming experience whatsoever. If so, there are far, far better places to start than the 7800. (Maybe batari Basic if you want to work on a console rather than a PC.)
  
• You have programming experience, but only with high level languages. Again, you might want to start somewhere else. IMHO the 7800 is tough to use because you have to write a lot of code to get things happening on screen.
  
• You've programmed in assembly, but not in 6502. See #2, although if you have experience in more than one ISA then picking up the 6502 isn't too bad. (Until you discover the index registers are only 8 bit.)
  
• You have 6502 experience, but have never programmed any games. I'd advise reading through the documentation linked to in the first thread before setting your heart on making a game for the 7800.

I know this may sound discouraging, but the only way a game gets done is if you want to do it and are willing to put in the time and effort and work through a lot of challenges.

Finally, my thoughts on your game ideas:

• WWI dogfighter
  The 7800 GPU is sprite based with some tile abilities. There is no bitmap mode like the Apple ][ or C64. So anything on-screen has to be pre-rendered, not drawn with lines (ala vector graphics). Thus stuff which has to be at multiple angles is going to use up a lot of memory.
  
• Super Mario Bros port
  Ahh.. the desire of many a 7800 fan. Although it might be possible to create a SMB style game on the 7800 (and even possibly re-use some NES assets), there's just too many differences between the systems to make a port feasible. See my comparison of the 7800 and the NES.