jaybird3rd Posted January 1, 2004 Share Posted January 1, 2004 Happy New Year Everyone! I decided to FINALLY follow through on my longtime ambition to develop games for the Atari 8-bits, after I discovered AtariAge last year. I've read elsewhere on these forums about the desire to attract new A8 developers, and I'm prepared to answer the call as best I can. Based on recommendations I've seen here and elsewhere, I've already started by putting together a collection of hardware, software, and books, which includes: - Several computers (two 800s, two 800XLs, a 600XL, a 130XE, and an XEGS) - Three 1050s and the APE / ProSystem software (running on a dedicated machine) - XEP-80 with monochrome composite monitor and AtariWriter 80 (useful as a source editor?) - Atari's Macro Assembler (the disk-based version) - Rodnay Zaks' Programming the 6502 and Advanced 6502 Programming - Lance Leventhal's 6502 Assembly Language Programming and 6502 Assembly Language Subroutines - De Re Atari and Atari's Technical Reference Notes (OS User's Manual and Source Listing and the Hardware Manual) I started this topic because I'm looking for advice from more experienced A8 developers on where to start (I'm currently a Computer Science student but I've never attempted 6502 Assembly before). Is there anything I'll need that I don't already have? Would you recommend starting on a platform other than the Atari 8-bits? Should I begin with BASIC and move on to Assembly later, or is it better to just start out with Assembly? I've looked over the books on www.atariarchives.org, but most of them seem to be written for assemblers I don't have (the Assembler/Editor cartridge, MAC/65, etc.) Can I still use them? Thanks in advance for your advice, and my apologies if this sort of thing has been posted before (I'm a n00b). Quote Link to comment Share on other sites More sharing options...
Bryan Posted January 1, 2004 Share Posted January 1, 2004 Welcome! I'd recommend 6502 assembly all the way. In the end, you'll need to know it to do most things anyway. Some people here use TurboBasic for whipping up rapid demos, however. Read Rodnay Zaks 6502 book. Make a printout of all the instructions, and keep it handy. Download the Atari Technical Reference notes, Mapping the Atari, and De Re Atari. Use a PC-based assembler (DASM, ATASM, XASM, TASM) and an emulator like Atari800Win+ for rapid development. This way you can edit, assemble, and test very rapidly. Use the SIO2PC cable when you need to check things on a real A8. There's no point messing with trying to do it all on the original machine. It'll just slow you down, and keep you from using some very good tools. You can ask questions here or you can also join the Yahoo A8 development mailing list: http://groups.yahoo.com/group/atari8bitdev/ -Bry Quote Link to comment Share on other sites More sharing options...
Randy California Posted January 1, 2004 Share Posted January 1, 2004 Welcome! I'd also suggest machine language all the way, it's far more gratifying. BASIC is too slow and shouldn't be considered for developing games on the A8, especially in 2004. Good luck and let us know if you need more info! ++ RC ++ Quote Link to comment Share on other sites More sharing options...
andy_bernstein Posted January 1, 2004 Share Posted January 1, 2004 Yep, Go for Assembly directly -> Do not waste your time on Basic, it's not worth it. I remember developing ports (back in 1986-89) of Top Gun (from Ocean Software), Back To The Future (from Activision), Starglider (Rainbird) and it was just too limitative. I tried again in 1996 for an original game based on Star Wars and......... no. For the moment being, I would suggest you do everything on a PC or MAC and only upload your work in progress on a real machine when needed. Also, you'll need beta testers in case you don't want the project to be open source. Good Luck ! I'm happy you're joining us for the party ! AB. Quote Link to comment Share on other sites More sharing options...
Bryan Posted January 1, 2004 Share Posted January 1, 2004 I've looked over the books on www.atariarchives.org, but most of them seem to be written for assemblers I don't have (the Assembler/Editor cartridge, MAC/65, etc.) Can I still use them? Assembly code is pretty easy to get working in any environment. Languages like BASIC often differ quite a bit from one vendor to the next, but the 6502 opcodes never change. Only the assembler directives are likely to need some tweaking. -Bry Quote Link to comment Share on other sites More sharing options...
TMR Posted January 1, 2004 Share Posted January 1, 2004 What that lot said. =-) Quote Link to comment Share on other sites More sharing options...
+Sauron Posted January 1, 2004 Share Posted January 1, 2004 Yet another vote for sticking with 6502 assembly. It's surprisingly easy to learn, and far more powerful than BASIC. Plus you're far less likely to run into memory issues should you decide to do your development on a real A8 instead of via the PC tools and emulator. Quote Link to comment Share on other sites More sharing options...
bjk7382 Posted January 1, 2004 Share Posted January 1, 2004 I have read a lot of stuff from the "Machine language for beginners" book from atariarchives.org I also read all of Andrew davie's tutorials up to the Playfield ones. I got totally lost on the second playfield session. I have assembled stuff with dasm and made some modifications to it, but still couldn't come up with my own kernal with my own playfield picture. I will get the hang of it some day. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 1, 2004 Share Posted January 1, 2004 6502 risc power rules... get xasm at http://xasm.atari.org... and get a nice text editor like codegenie to work nicely with xasm... turbobasic xl + combination of atari800win4.0 is nice to prepare lookup tables, convert gfx via own tools... i like to test stuff in turbo basicxl... your 1st assembler code should be... the atari rainbow colors... org $4000 loop lda $d40a clc adc $14 sta $d40b sta $d018 sta $d01a jmp loop Quote Link to comment Share on other sites More sharing options...
TMR Posted January 2, 2004 Share Posted January 2, 2004 I have assembled stuff with dasm and made some modifications to it, but still couldn't come up with my own kernal with my own playfield picture. The best advice i could give here is learn the other Atari machines first, the 2600 is probably the nastiest place to start from because it needs so much work just to do what is fairly simple for an XL/XE. Of course, the down side is you have to "unlearn" a few things when you move to the 2600 but for most people that seems to be the easier route... (Says the guy who spent a week over chrimble getting his first 2600 game working... =-) Quote Link to comment Share on other sites More sharing options...
classics Posted January 2, 2004 Share Posted January 2, 2004 If youre going to write a game my advice would be to go assembler only. If you dont mind developing on the PC I highly recommend a combination of the TASM assembler and Atari800WinPlus for testing. If you assemble your code to an EXE file you can also load it on the real Atari instantly (when you need to test on real metal) by assigning Drive 1 to a PC-Mirror drive. Then just turn on the Atari and press the letter of your EXE to test loading it. Learn to use the monitor in Atari800Win. Its bare bones but will save you hours of time once you really get good with it. A more specific tip would be to depend on no OS services other than catching interrupts. Dont even let it process them. In the first few instructions immediatly hook the immediate IRQ and NMI vectors, then write your game against the hardware, or your own shadow-register system if you really need them. Quote Link to comment Share on other sites More sharing options...
Bryan Posted January 2, 2004 Share Posted January 2, 2004 If youre going to write a game my advice would be to go assembler only. If you dont mind developing on the PC I highly recommend a combination of the TASM assembler and Atari800WinPlus for testing. If you assemble your code to an EXE file you can also load it on the real Atari instantly (when you need to test on real metal) by assigning Drive 1 to a PC-Mirror drive. Then just turn on the Atari and press the letter of your EXE to test loading it. Learn to use the monitor in Atari800Win. Its bare bones but will save you hours of time once you really get good with it. A more specific tip would be to depend on no OS services other than catching interrupts. Dont even let it process them. In the first few instructions immediatly hook the immediate IRQ and NMI vectors, then write your game against the hardware, or your own shadow-register system if you really need them. Castle Crisis is written in TASM, was tested with Atari800Win+ and a PC Mirror/APE and it allows no OS services to run... Great Minds think alike, I guess (although I wouldn't mind looking into other assemblers) I really wish Atari800Win+ had a single-step and breakpoint feature. I made my own breakpoints by assembling ".db 02" into the code. -Bry Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted January 2, 2004 Share Posted January 2, 2004 ... Great Minds think alike, I guess (although I wouldn't mind looking into other assemblers) I really wish Atari800Win+ had a single-step and breakpoint feature. I made my own breakpoints by assembling ".db 02" into the code. The latest version of the CC65 assembler (CA65) now supports structures within the assembler, I really like using this assembler -> object file approach (although I can't say that I've tried the [D|T|X]ASMs to any great extent), the powerful linker (LD65) makes such things as relocating code, cartridge work etc very simple via segments As for breakpoints - the emulator you have just hasn't been compiled with the right flags set. Download the sources (if you have Visual C++) or I can post an updated exe if required. Regards, Mark Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 2, 2004 Share Posted January 2, 2004 i am highly interested in a debug version of atari800win... if you could compile such a version you would be a star... i am sure many of us developing with atari800win would like to have such a version... very much appreciated. Quote Link to comment Share on other sites More sharing options...
jaybird3rd Posted January 2, 2004 Author Share Posted January 2, 2004 Wow, a debug version would be great! I'd appreciate an updated executable also! Big thanks to everyone for the feedback and the encouragement. Just to clarify, though: I'd never attempt a whole game in Atari BASIC; I only planned on using it for testing and to get better-acquainted with the hardware in the beginning without dealing with assembly. That might not be necessary, though, since I've been reading through the tech docs I have and am getting a better feel for the hardware. Between learning 6502 assembly and the A8 hardware I've still got LOTS of questions, but you've all got me started in the right direction. One more question (and I hope I'm not breaking any forum rules here): would you recommend using a disassembler to attempt to learn from the source code of working games, or is that more trouble than it's worth? Most of the source I've gotten from the disassemblers I've tried branches all over the place and is a little hard to follow. Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted January 2, 2004 Share Posted January 2, 2004 I can't get to the Polish site for the most latest sources (from work - I can at home) - but this one's fairly recent (e.g. flash cart support) only one breakpoint is supported, e.g. break . this can be cleared with "break off". But a simple missing debug option is "run until address". We should start a wish list :wink: My long term todos are: Trace to file (already done but just to a fixed filename - needs to be parameterized) break on address access/content change break on address content = value run until PC = address import of (CC65) label file to override internal labels (for better disassembly) Regards, Mark atari800win.zip Quote Link to comment Share on other sites More sharing options...
TMR Posted January 2, 2004 Share Posted January 2, 2004 One more question (and I hope I'm not breaking any forum rules here): would you recommend using a disassembler to attempt to learn from the source code of working games, or is that more trouble than it's worth? If you can read it and there's something interesting to be learnt, it's certainly worth the effort. i can't personally, i've never been very good at reading other peoples' source code... Quote Link to comment Share on other sites More sharing options...
Bryan Posted January 2, 2004 Share Posted January 2, 2004 One more question (and I hope I'm not breaking any forum rules here): would you recommend using a disassembler to attempt to learn from the source code of working games, or is that more trouble than it's worth? Most of the source I've gotten from the disassemblers I've tried branches all over the place and is a little hard to follow. Disassembling and weeding through undocumented code is probably more trouble than it's worth. I've done it, and for a game-sized program it can take a very long time to figure out. It would be better to start with some documented example code and go from there. Atari published the source to a checkers game in the hardware manual, and you can now download the book Atari Graphics and Arcade Game Design which should be helpful. @Mark Why do you suppose these features aren't normally enabled in Atari800Win+? I don't understand why a stripped down dubugger would be the default option. The size difference can't be that great. -Bry Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted January 2, 2004 Share Posted January 2, 2004 Disassembling and weeding through undocumented code is probably more trouble than it's worth. I agree, I do a lot of disassembling from C64 games - and working out what address does what and then what this or that routine does is a long process. Sometimes things fall into place but this normally depends on the coding 'style' of the implementor. (Of course a great tool like IDAPro helps) Why do you suppose these features aren't normally enabled in Atari800Win+? I don't understand why a stripped down dubugger would be the default option. The size difference can't be that great Yep, this is odd! It used to be that A880Win didn't have the debug (F8 ) option enabled at all - which is fine - but why enable only half of it is just the choice of the maintainers (# of users vs # of developers/hackers I guess)? Maybe a polite email will cause it to be included by default in future releases Mark Quote Link to comment Share on other sites More sharing options...
Bryan Posted January 2, 2004 Share Posted January 2, 2004 Yep, this is odd! It used to be that A880Win didn't have the debug (F8 ) option enabled at all - which is fine - but why enable only half of it is just the choice of the maintainers (# of users vs # of developers/hackers I guess)? Maybe a polite email will cause it to be included by default in future releases Mark Heck, every other Windows program I use has dozens of features no one will ever use, so INCLUDE THE WHOLE DEBUGGER GUYS! -Bry Quote Link to comment Share on other sites More sharing options...
classics Posted January 2, 2004 Share Posted January 2, 2004 I believe the version I compiled for testing flash cartridge images has the break feature enabled in the debugger. Its based on Plus v3.1 though, so the emulation is not as accurate as 4.0. You can get a binary or source at http://www.atarimax.com/flashcart/documentation/ Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.