NaOH

After @ZeroPage Homebrew's feedback during their stream, I've made the game pause before resetting so you can see what level you're on. I've also added a numeral at the top of the screen to show the current level. Finally, the difficulty has been tweaked a bit; hopefully it is a tad easier at the start, as requested. With just $C1 bytes remaining of free space, and fewer and fewer options to shrink the existing code and data, I'm getting a little nervous about music, heeeh... Edit: I was able to shrink the input routine a whole ton. Turns out it was very inefficient before. Now there are $106 bytes left for music. I think that should be possible, right? vcspon.CV

Okay, I've added levels, difficulties, and basic sound effects (very temporary). I also trimmed down a bunch of code and so despite adding all that in, there are still $100 bytes left of free space for music, TBD. Set both difficulty switches to B for normal mode; set both to A for the hardest mode. The goal is to reach the highest level possible. You level up after clearing a certain threshold of blocks. (One of the difficulty switches currently lowers this threshold, and I will probably change this behaviour. One of the difficulty switches makes the game faster.) Attached are two slightly different versions. One is the normal version and one uses flicker to smooth out the blocks. I imagine that flicker will only look good on certain screens -- let me know if anyone has any good or bad experiences with the flicker enabled. Edit: Updated the grace timer period mechanic a bit, should be a little more intuitive now. vcspon.CV vcspon-flicker.CV

Okay, I've got all the basic features of the gameplay loop in, and nothing seems to be terribly glitchy. What remains is basically just polish. Out of the $800 bytes of ROM, I'm using about $700 now, there isn't a lot of polish I can do. Basically the choice now is between whether I want to add score or add sound. I'm leaning toward sound. Perhaps there will be room for both. And now it's got buttery-smooth scrolling. Demo attached. vcspon.CV

Well it's not going to win any awards for breathtaking graphics... Not to mention it's a bit glitchy. Hmm, will have to workshop this.

.CV should run in Stella at least.

Thank to @alex_29's advice, I was able to solve the bugs! I wrote a python script to evaluate various inline-defined python assertions in order to ensure that nothing would cross a page boundary. As a simple example, I can add `; [py] 5 + 3 == 8` and python will evaluate it and confirm it's true. (Of course, the real value of this comes from being able to read symbol addresses and verify properties about them.) I've also now implemented gravity and block removal: Next thing to do will be to implement a nice "explosion" effect. I wonder how I'll represent that visually -- maybe color-cycle? vcspon.CV

Can Atari give an official position on whether it condones the creation of homebrew roms and (non-infringing) romhack patches?

Fantastic! I had no idea about this feature. This will be very helpful should I continue development. :)

I started on a homebrew Panel de Pon port. It uses the 4-colour technique similar to what is laid out here. The game rewrites its own code in real-time by writing 6502 opcodes to the 1kb cartridge ram included in a CV cart. This allows it to hammer the COLUBK register to change colours. Only 4 colours per scanline are effectively possible with this technique, as three of the colours are stored in X,Y, and A and a fourth colour (black) is possible by using the undocumented SAX opcode to write A&X, which is black, to COLUBK (we choose colour A and colour X such that they have no bits in common, thus A&X = 0). Here's the cartridge RAM in Stella, marked up to show the instructions: Unfortunately, it's a bit buggy. I am pretty convinced this is due to some unusual behaviour in the cartridge ram. I notice in the source code for Stella that the sta ($abcd),y opcode (which I use to rewrite the code in the ram cart) will "poke" memory at address $ab+(cd+y & 0xFF) before "writing" to memory $(abcd+y). I don't know what "poke" means in this context, as it clearly doesn't mean "write," but evidently it is corrupting memory sometimes. However, write-breakpoints in stella don't seem to detect this form of memory manipulation, so it's hard to debug. I tried adjusting the code so that y is always 0 during this sta ($abcd),y operation, which ought to avoid this corner case, but oddly it didn't seem to help. I probably won't work on this for a while until, as I mostly just wanted to make a proof-of-concept. Source code on Github. ROM attached. vcspon-wip.CV

Wouldn't you know it -- the thread right before this one is using the same RAM kernal technique as I am. Clever use of SAX too -- I think I will steal that trick to get a fourth colour. Edit: and so does the thread right after! Also using the SAX trick, even! Is there something in the air, or is this just a very common technique?

The other day I talked to someone who had an Atari, and I got interested in doing homebrew, which I've never done before. Attached are gifs of my first demo (purple), and a 3-pixel scrolling example which could be interesting to some. Normally, the playfield only allows scrolling in 4-pixel increments, so this is interesting perhaps. In the horizontal scrolling example, the playfield isn't used at all. Instead, the cpu rapidly writes different colours to the background color register (COLUBK). This allows image data to be written with 3-pixel precision, because there are 3 pixels per cpu cycle. This means that while drawing to the screen, every single instruction must write to COLUBK, and there is no time for any logic to read image data from the ROM. So, how can dynamic image data -- such as a scrolling marquee -- be produced? Well, during VBLANK, the image data is read from the ROM and is dynamically compiled on the fly into a sequence of bytecode instructions that can produce the image shown, and then that routine is executed directly from RAM. (As an aside, the squishing effect shown below is produced by running subsections of this dynamically-compiled routine a different number of times -- at its thinnest, each section of the routine is run only once. Each section comprises exactly one scanline, so if the section is run multiple times in succession, then it will be stretched vertically.) Are there any other games which are known to execute instructions from RAM? Or is this unusual? Demo 1: Demo 2 (3-pixel horizontal scrolling)