JeffJetton

Fun! Having never playing the 32K version, I don't really have anything to compare it to. Not sure what the floaty dash thing is, but I've learned to not let it hit me. :-)

I don't totally know how to make a home-brew game either... yet. I'm learning. That how life is I guess. There are lots of things I didn't know how to do at one point--then I learned how, and now I do. Like anything else, it's all about having an interest and passion for something. If you want to do something, you allocate the time to do it. Everyone has the same 24 hours in a day. It's just a matter of what you decide to spend the time on. Anyway, it's possible to program 2600 games on a Mac just fine, in either BASIC or assembly. I use a Mac myself. (Remember, Windows didn't even exist when they wrote the first Atari games, and that didn't stop anyone.) P.S. I also make music. Personally, I've always been able to find a challenge in it somewhere. If you found it too easy to learn then you might've stopped too early. Go listen to harder music! :-)

Really wonderful work here, SplendidNut!

Ha! Me too. I used to check David Ahl's book of BASIC games out from the library constantly. It was a great era to learn programming in.

Woo-hoo!

Oh, you're using bB? Not sure there. I don't imagine that it would, inherently. Then again, now that I think about it, adding more WSYNCs to your frame would probably only make Stella more certain that it's PAL over NTSC (because each frame would have more lines, not fewer). So that's not it either. :-(

I always kinda assumed that the autodetect just counts the number of (simulated) TIA HSYNCs that occur between VSYNC signals. Close to 262, consider it NTSC. Much more than that, call it PAL. But if adding waste cycles gets Stella to undetect PAL in favor of NTSC, my theory must not be right, eh? (Unless those cycles were WSYNCs, I guess?) Edited to add: Hmmm... looking at the Stella source--although my C++ is a bit rusty--I think it does in fact count lines between VSYNCs.

I believe a few versions have been posted in the "Book?" thread.

Good to know. I didn't want to accidentally, like, break the internet or something.

I figured. But since I'm doing absolutely nothing after setting them, there wasn't really anywhere else I could think of to jump to. Not sure if this sort of thing is kosher (a jmp jumping to itself): InfLoop jmp InfLoop Is it?

Well specifically, I'm working with very basic programs that either don't display anything (other than the background), like this: MyLoop lda #$CE sta COLUBK jmp MyLoop Or that display the same thing on every scanline, like this: SetCols lda #$06 sta COLUBK lda #$46 sta COLUPF lda #%10110111 sta PF1 jmp SetCols I'm assuming that, if these rolled, it wouldn't really make much of a difference, eh?

Very cool. I'll check it out!

Welcome Pixel Toad! I think it's great that you want to learn programming. You didn't choose the easiest thing to program, but don't let that stop you. :-) What is the error message that you're getting?

Ah! I didn't know that analog TVs had a natural limit. Good to know, thanks!

Hello all, Newbie 2600 programmer here. I've been playing around with creating very simple code examples as a way of helping me to figure out how all this stuff works and fits together. I've found that, if I don't do any sort of VSYNC or other typical kernel responsibilities (VBLANKs, etc.), I can get a "bare bones" program (similar to Tjoppen's minimal demo but not as tricky) to run in Stella just fine. I can get it to run in Javatari (on 8bitworkshop) too, with a bit of resetting/fiddling. Auto-recognition of NTSC/PAL fails, of course. That's to be expected, I guess. But, out of curiosity, what if I were to try to run it on a real VCS? I know the TIA will take care of the horizontal beam movement without any help from me. But what about the vertical movement? Will the TV just keep scanning downward until it blows up or something? :-P Thanks, - Jeff