What is the best system for programming games?

[Atari Scorpio]

What is the best system for programming games? Should I go with an 800, Xl, or XE? Is the XE game system any different or better than the computer conterparts? I'm looking to program some ports for personal use of arcade classics. Thanks for any info.

[Allas]

What is the best system for programming games? Should I go with an 800, Xl, or XE? Is the XE game system any different or better than the computer conterparts? I'm looking to program some ports for personal use of arcade classics. Thanks for any info.

 

 

The better system is a PC with windows tools and Atari emulator. At the last when emulator works fine, you can test in a 130XE or 800XL.

[cas]

What is the best system for programming games? Should I go with an 800, Xl, or XE? Is the XE game system any different or better than the computer conterparts? I'm looking to program some ports for personal use of arcade classics. Thanks for any info.

 

I prefer real hardware for programming. The two games I had programmed using an Emulator had problems on real hardware (timing problems with DLI and SIO during IO). For game programming 800XL and 130XE are very similar, it depends which keyboard you like most (the soft XE or hard XL type keyboard). For game programming, I recommend a hardware monitor build-in or attached to the machine, like the new Turbo Freezer XL/XE. Such device allows you to stop execution of your programm, inspect the memory, stack and state of the system and continue execution later.

 

Carsten

[Beetle]

Is the XE game system any different or better than the computer counterparts?

 

From the programmers view the XE game system is like a 800 XL with XE Keyboard. The 130XE just has an extra 64k for the use of Ramdisk or so. There are many ways to get an 800XL an extended memory, too.

 

But, as Carsten mentioned, a freezer or monitor is very helpful in programming. The drawback of the XEGS is that it has no PBI to attach a freezer. You`ll have to be a real hardware-freak to wire a PBI device into a XEGS, although its possible.

 

Regards,

Beetle

Edited September 28, 2006 by Beetle

[Atari Scorpio]

Has anyone used the Atari S.W.E.A.T. program to make games and is it easy to use?

[cas]

Has anyone used the Atari S.W.E.A.T. program to make games and is it easy to use?

 

I took a short look.

 

I think S.W.E.A.T. is only good for historical refernce, not for real work.

 

There are much better tools out there, like Envision ( http://www.cs.utah.edu/~schmelze/atari/envision/index.html ), Block-Pixel-Font (ABBUC PD), MultiPlayer Animator (Peter Finzel, also ABBUC PD) and much more.

 

However, before using the tools, you should understand the topics of Atari Graphics, Player Missile, Sound and Fonts the manual way (by programming). Else you will be lost when the tools do not behave like you want them. Only if you understand the background of Atari Hardware the tools will be helpful in the long run.

 

Carsten

Edited September 28, 2006 by cas

[Plastron]

I would go with 130XE and a MAC 65

You can put DOS into ramdisk so you do not need to keep loading it

MAC 65 has a very good debug tool so you can single step your code to find any errors

 

This is the set up i used for writting way back

 

Andy

[MEtalGuy66]

I would go with 130XE and a MAC 65

You can put DOS into ramdisk so you do not need to keep loading it

MAC 65 has a very good debug tool so you can single step your code to find any errors

 

This is the set up i used for writting way back

 

Andy

 

YEah, Im inclined to agree with that. However. I also see the point of the people who would use a PC based cross assembler. I would not, however depend on the emulator for testing.. A PC based cross assembler will literally compile code in seconds, that takes hours on the real ATARI. With the cheap availability of SIO2PC, its no problem whatsoever to mount a directory of your PC as a diskdrive on the 130xe (or other real atari) and test your executables, using ADDT, etc. This way, you get the best of both worlds.. And I think this is probably what most "serious" atari programmers do nowadayze..

[Plastron]

I would go with 130XE and a MAC 65

You can put DOS into ramdisk so you do not need to keep loading it

MAC 65 has a very good debug tool so you can single step your code to find any errors

 

This is the set up i used for writting way back

 

Andy

 

YEah, Im inclined to agree with that. However. I also see the point of the people who would use a PC based cross assembler. I would not, however depend on the emulator for testing.. A PC based cross assembler will literally compile code in seconds, that takes hours on the real ATARI. With the cheap availability of SIO2PC, its no problem whatsoever to mount a directory of your PC as a diskdrive on the 130xe (or other real atari) and test your executables, using ADDT, etc. This way, you get the best of both worlds.. And I think this is probably what most "serious" atari programmers do nowadayze..

 

 

No

The MAC65 will complie very quick few minutes at most not hours. Plastron was written on the MAC and the whole game takes very little time to complie even with loading files of other parts of the code. Not not however try with the Atari ASM this would take hours if not days. You could not usr that to write anything.

[ijor]

I agree that combined/mixed emulation and real hardware development is the most useful approach.

 

But I would add however that debugging under emulation is also useful. You can do a lot of things that you can't under real hardware, even if you would use a freezer or even a 6502 ICE.

 

Using a freezer and an ICE you could get hardware non-intrusive breakpoints. You can even get CPU hardware single stepping. But you can't single step ANTIC or the rest of the hardware, something that you do can under emulation. Of course that the final test should be performed under real hardware.

[Plastron]

I agree that combined/mixed emulation and real hardware development is the most useful approach.

 

But I would add however that debugging under emulation is also useful. You can do a lot of things that you can't under real hardware, even if you would use a freezer or even a 6502 ICE.

 

Using a freezer and an ICE you could get hardware non-intrusive breakpoints. You can even get CPU hardware single stepping. But you can't single step ANTIC or the rest of the hardware, something that you do can under emulation. Of course that the final test should be performed under real hardware.

 

 

Use DDT on a MAC 65 you can single step follow all flags and registers and flip to the game screen.

[ijor]

Use DDT on a MAC 65 you can single step follow all flags and registers and flip to the game screen.

 

That's only CPU single stepping. And that's only software, intrusive, single stepping.

 

You can't do that if you happens to use locations that conflict with DDT. And you can't do that on real time. If you are debugging, say a low level SIO interrupt routine, you can't use normal breakpoint because Pokey and the external peripheral won't wait for you. Same if you are using custom Antic/Gtia effects.

 

I agree that normally you don't need that. I was just mentioning that you could so some type of debugging under emulation that you can't otherwise.