AkashicRecord

Those are good ideas, and almost in line with what I was tinkering with. For a single player well, it would make sense to draw the borders using the second player and associated missile...it would look nice. Also writing #%00000001 to CTRLPF fixes the playfield and it fits very nicely, I had certainly overlooked that. I only need about 16 pixels at most for a piece, so I was imagining that most pieces could be drawn by just modifying NUSIZx (and a color) a couple of times. Some pieces might be able to reuse the existing data from other previous pieces since they are so simple...4, 8, 12 or 16 pixels changing every four scanlines at most is the general case. I would certainly have a competitive mode which has the associated players playfield in the color of their current "level" (100 lines cleared.) I was aiming for a 2-player coop within a shared well of at least 12x20, as well as some other modes like alternating 1P/2P or modes where one player rotates the piece, while the other moves it...possibly with the paddle, for instance.

Thanks a lot for the information and suggestions. I didn't have any plans to retain the piece colors once they are placed. I didn't think there was much capacity (even with external hardware) for that kind of bookkeeping. I don't even hardly want to change the playfield color (with a constant black background) except maybe a few times. The above tests with colored bars are just to measure screen real estate and to get a visual overview. The idea of a cart with an ARM processor is tempting though...ARM and Thumb assembly was my all-time favorite, especially the barrel shifter... I'm still working out the logistics and to see what is actually possible with 76 clock cycles and preloading as much state change as possible before the target scanlines, because if this game was easy to write while still looking good, it would have already been done many times. Abusing the processor status flags will probably go a long way. In my testing late last night, I can change 11 values in RAM across a single scanline...but it was sometimes dropping Stella's FPS on my netbook from 60 to 15fps!

/salute Sounds like a good idea, and it wouldn't impede the game logic in any way.

My next step is to flesh out the game pieces into some code. I'm envisioning judicious use of the sprite sizing register and the missile objects, if my understanding of the mechanisms are sound. Color changes might be hardcoded into each kernel, but I may investigate using the DCP/DCM illegal opcode to decrement the value in RAM.

Dr... Atario? That idea crossed my mind around the same time as a Tetris clone, but I feel there will be a LOT more wizardry required for a Dr. Mario game if it isn't going to be a flickery mess...

A few days ago, I threw together a simple kernel that cycled the background colors and writes the line counter to two playfield registers. (We've all seen that one before...) I used that to put together a mockup image of the game field (with a few pieces in unrealistic fashion) to help envision the playfield with respect to the to playfield registers: (NOT real) It didn't take long to notice that the best route is just probably just use 5 bits of each playfield register. Shaving a few lines from the top gives space for two 10x20 "wells" for a 2-player layout: (Real)

Thanks!

Certainly worth a watch for anyone interested.

Thanks for that one, I overlooked that section of the forum and missed it.

Ah, that's the one that I was looking for. The cartridge type seems a bit ...hefty. My target is only the "standard" 4K, but I wouldn't rule out any of the more 'advanced' types if the need arises.

UPDATES: 11/16/2018 - New 1P kernel design is almost complete. Playable prototypes coming soon. 11/07/2018 - The SRS (Super Rotation System) is in place, and piece rotations are almost finished. 11/02/2018 - An unfinished 2-player joystick prototype is now available. (See page 6.) Here's the original post: