Atari VCS 2600 demo coding
category: code [glöplog]
Hi,
I'm into Atari VCS 2600 demo coding for some time now because after reading "Racing the beam" and hearing SvOlli's talks, I just had to try out this really weird architecture. So far, I'll love it! However, I've run into some questions I hope somebody here can help me out with.
1) Is there a list of known compatibility issues with emulators (Stella in particular) versus the real thing? I don't have a Harmony cartridge (yet), and I'd hate to invent some new effect only to learn later that it won't work on the real thing...
2) How much RAM should I reserve for music? So far, I've concentrated on visual effects first to get started, making nice progress. I hope to find someone later on who might be willing to contribute music (or torment the audience with self-made music in case I won't be able to find someone...), but I have no idea how many bytes of RAM a solid player might need. RAM is really tight for most of my effects...
3) I guess "proper" demos just use the standard 128 bytes of RAM and no extra RAM on the cartridge, correct? To me at least it would feel like cheating otherwise. Or are some of the demos here on Pouet using extra RAM?
Thanks in advance! Back to counting cycles and abusing the stack pointer again...
I'm into Atari VCS 2600 demo coding for some time now because after reading "Racing the beam" and hearing SvOlli's talks, I just had to try out this really weird architecture. So far, I'll love it! However, I've run into some questions I hope somebody here can help me out with.
1) Is there a list of known compatibility issues with emulators (Stella in particular) versus the real thing? I don't have a Harmony cartridge (yet), and I'd hate to invent some new effect only to learn later that it won't work on the real thing...
2) How much RAM should I reserve for music? So far, I've concentrated on visual effects first to get started, making nice progress. I hope to find someone later on who might be willing to contribute music (or torment the audience with self-made music in case I won't be able to find someone...), but I have no idea how many bytes of RAM a solid player might need. RAM is really tight for most of my effects...
3) I guess "proper" demos just use the standard 128 bytes of RAM and no extra RAM on the cartridge, correct? To me at least it would feel like cheating otherwise. Or are some of the demos here on Pouet using extra RAM?
Thanks in advance! Back to counting cycles and abusing the stack pointer again...
Yay, new blood! First of all, pop by #vcsdev on IRCNet if you want faster answers to questions. There are lots of helpful people on the AtariAge forums as well.
1) The only issues I've found with Stella relate to unusual tricks that few people are aware of, like repeatedly strobing RESBL with an 8-pixel ball. IIRC changing NUSIZx in the middle of drawing the corresponding also has subtle bugs. Until you get a flash cartridge there's always the option of sending test ROMs to people on IRC
2) How much RAM you need obviously depends on how complicated a player you need. Paul Slocum's player (music kit 2) uses 3 bytes of state, 4 bytes of temp storage and 4 bytes of stack. You can hack it to use zero bytes stack. My current rule of thumb when writing effects is to leave 16 bytes for music/timeline state and temp storage (incl. stack)
3) Yep, none of the demos on pouet use extra RAM - only extra ROM. This discussion comes up on IRC from time to time - personally I don't care
1) The only issues I've found with Stella relate to unusual tricks that few people are aware of, like repeatedly strobing RESBL with an 8-pixel ball. IIRC changing NUSIZx in the middle of drawing the corresponding also has subtle bugs. Until you get a flash cartridge there's always the option of sending test ROMs to people on IRC
2) How much RAM you need obviously depends on how complicated a player you need. Paul Slocum's player (music kit 2) uses 3 bytes of state, 4 bytes of temp storage and 4 bytes of stack. You can hack it to use zero bytes stack. My current rule of thumb when writing effects is to leave 16 bytes for music/timeline state and temp storage (incl. stack)
3) Yep, none of the demos on pouet use extra RAM - only extra ROM. This discussion comes up on IRC from time to time - personally I don't care
3. It's not cheating if you manage to do something that impresses people, however it was made.
Welcome.
ad 1) There is a number of things that will go unnoticed in the EMU (switching VBLANK at the wrong time) and sometimes even may work on once TV set but not on another (had to learn that the hard way). But once you have a proper sync kernel, nothing can really go wrong. Make sure you keep the number of scalines per frame (262 NTSC, 312 PAL), otherwise a real TV will start rolling (the emu will not show this).
ad 3) By now the rules at most VCS compos were intentionally set to "no extra RAM". At SV for example we started with 4K ROM limit and increased it step by step to 32K ROM now, which we will kepp for a while. And believe me, you will learn a lot about VCS and real size coding if you stick to 128B of RAM. That machine can really teach you a lot.
ad 1) There is a number of things that will go unnoticed in the EMU (switching VBLANK at the wrong time) and sometimes even may work on once TV set but not on another (had to learn that the hard way). But once you have a proper sync kernel, nothing can really go wrong. Make sure you keep the number of scalines per frame (262 NTSC, 312 PAL), otherwise a real TV will start rolling (the emu will not show this).
ad 3) By now the rules at most VCS compos were intentionally set to "no extra RAM". At SV for example we started with 4K ROM limit and increased it step by step to 32K ROM now, which we will kepp for a while. And believe me, you will learn a lot about VCS and real size coding if you stick to 128B of RAM. That machine can really teach you a lot.
Thanks, all! I wasn't aware of Paul Slocum's player, looks like a nice thing to start from.
And I take the "But once you have a proper sync kernel, nothing can really go wrong" as a challenge. ;-P
I will pop by at #vcsdev next week, when I'll have time to code again.
And I take the "But once you have a proper sync kernel, nothing can really go wrong" as a challenge. ;-P
I will pop by at #vcsdev next week, when I'll have time to code again.