johnnystarr

Off Topic: Andrew, your avatar scared the crap out of my wife the other night! I was checking atariage and she saw it out of the corner of her eye and went "Ahhh!".

Great job buddy! I really like what you've done with it. It also helps out newcommers to see the success of a fellow newbie!

So, here is a copy of my UDL file for Notepad++ 6502-VCS.xml I've currently added psuedo-ops for DASM, but you can go in and add any assembler specific data you want. I should note that the TIA and RIOT registers are taken from "vcs.h" and "macro.h". So, you may need to tweak them as well. Here's a peak at what my current theme looks like. Its not 100% perfect, but it should give you an idea of how this works:

What are you trying to accomplish? Are you trying to offset a table within your routine, or are you trying to offset program memory itself?

Has anyone here used these carts for their homebrew projects? I'm wondering if any of them could be swapped with an EPROM.

Totally late coming in here, but I wanted to see if I am right or wrong about the following: Your 9 byte solution is as follows: ldx #0 lda #0 Clear sta 0,x inx bne Clear Wouldn't the following be 8 bytes total? ldx #0 txa ; 1 byte operation vs. 2 for lda #0 - as they are both zero Clear sta 0,x inx bne Clear The following is from the 6502 reference: TXA Transfer Index X to Accumulator addressing: implied assembler: TXA opc: 8A bytes: 1 cycles: 2

Dude, that rocks! That will make debugging MUCH easier One of the things I didn't like about NES emulators is that there weren't any solid debuggers. I've added the command to my batch file.

I've created my own notepad++ 6502 highlighting XML file if you want one. You can make one yourself by just entering all the instructions and directives. Its pretty helpful.

I tried googling the -d flag for DASM. According to the documentation it states: "-d debug mode (for developers)" I have tried running this along with my file and all I get is: "Debug trace OFF" I was hoping that DASM would work in this mode somewhat like debug.exe in DOS for x86 assembly. I'm starting to think that this is perhaps a feature that is no longer supported? Is there something I'm doing wrong here?

I think I'm starting to get the idea now. I am probably getting ahead of myself anyway. I'm going to follow along with the newbie guide and do all the exercises.

Ok, So you're saying: VBLANK: Game Logic HBLANK: Draw Screen Overscan: Game Logic I'm glad to see where this is going. But I would like to understand HBLANK a bit more. Should I view it like, during VBLANK decide what will be drawn at HBLANK, fill some RAM with the details and then halt the system and let HBLANK draw what was determined in Overscan or VBLANK? Or are you saying that I need to write the changes to the TIA druing HBLANK? Or, am I overthinking this? Is it that during HBLANK, we just need to waste some cycles in order for it to draw so I have the choice of running some gamelogic during HBLANK and count all the machine cycles and calculate the exact time that the screen needs to be drawn so that I can kill 2 birds with one stone?

Ok, that sort of makes sense to me. I am about halfway through Andrew's '2600 for newbies now. Here is what I don't understand yet: All the build up about the TIA sort of makes it sounds horrible to use. I still can't figure out what is my responsibility as the programmer. Do I need to try to cram stuff into WSYNC and HBLANK or not? Maybe I can explain how I would handle things in NES dev and maybe you guys can help me understand better from that perspective. During VBLANK, I wouldn't handle any logic other than controller latches and of course DRAWING. However, I would determine what needed to be drawn during non VBLANK time. I created a buffer that I would write certain op codes, so to speak. These would be reviewed by the drawing handler that was triggered during NMI only if something needed to be drawn in the first place. Granted, I had plenty of zero-page registers and other RAM to work with. But it made TV protocol a sinch. I never had to fret over coliding with the PPU (the NES's graphics chip). Now that I'm in Atari territory, I'm just not sure yet when to handle game logic because it seems that the majority of my working time is in VBLANK, as where it was the opposite in NES dev. VBLANK was a sacred time slot that you didn't want to fool around with. I think I understand all the 76 cycles and calculating color cycles vs. machine cycles. And I'm fluent in 6502 assembly. I've even written my own javascript assembler. I just don't quite grasp the TIA yet.

I have used ca65, but I prefer asm6. Of course, I was doing NES development with it. I have been doing '2600 stuff with DASM but only because the tuts out there use it.

Oh, I see Stargunner's workshop goes into great detail on these points. Nevermind

Hello there, I'm new here and new to Atari dev, but not new to 6502 assembly. That being the case, I am focusing a lot on the architecture of the TIA and the complexities of writing a decent kernel. After reviewing this site's 2600 101 tutorial, I am a bit confused on the "dos and dont's" of when exactly to perform certain functions. The examples given define what the TIA is doing, but I am hoping for a more comprehensive workflow so that I can visualize when it is best to perform game logic. In the NES world, you are a bit more shileded from TV protocol. For instance, when the TV hits VBLANK, you automatically go into an NMI. I use this time to handle all of my drawing and the main game loop for my logic. I'm happy to not use interrupts for a change, but I don't fully grasp WSYNC or HBLANK and what have you. I guess what I'm asking for is a better kernel example with documentation that provides best practices. Later down the line, I will develop my own tricks, but I would rather not reinvent the 30 year old wheel

Not to mention the fact that BASIC would take up much of the 4K of ROM that was actually available. Leaving very little space for the actual game. Also, its very important for the author / programmer to have access to bitwise operations. Most 6502 implementations of BASIC shielded the programmer from this ability, causing bloat and overhead that you just can't afford when 'racing the beam'. If you take the time to learn 6502 assembly, it will open up a world of platforms. You could go straight into NES or SNES dev. After learning one assembly language, learning another is trivial. For instance, if you wanted to write a gameboy game, you would need to learn assembly for the z80 / intel 8080.