ZackAttack

That's pretty much what I was getting at. Regarding the line spacing I was thinking you'd just skip ever 2nd line, then 2/3 lines, then 3/4 lines etc. Which is why having 3 pixel resolution, aka more lines, would potentially be helpful. Drawing the lines with COLUBK also makes it cheaper to fade the color as the lines go further away since either way you're setting COLUBK.

It would look more 3D if you space the lines more as they get closer to you. That may be easier to accomplish if you draw the lines with COLUBK instead of PF since you can get a 3 pixel resolution instead of 4.

The paddle has much less area than the ball. It might make the collision detection easier and faster if you draw the pong-ball with P0 and the paddle with P1

Do you have time to enable/disable m0 on each line? If you don't draw it then it won't cover p1.

If you're going to pad it you might as well go for a full 2K. That way you can be sure it will run on harmony, uno, and any other programmable carts. I tested yours and mine with uno and 7800 on a crt tv. Both of the demos appeared as they do in Stella. Maybe use DIP switches instead so it can be reprogrammed. As amusing and tempting as this is, it might be more practical to take everyone's demos and combine them with a menu program into a single cart. It could be a collection of demos and games that can be played with the cartridge removed since these will all fit in RIOT RAM.

This is the best I could come up with in one sitting. It's more of a 2 step process since the TIA is initialized each frame. Zack's 32 byte demo - padded.bin Zack's 32 byte demo.bin

I really like how you made this game take up the full screen width despite the DPC+ playfield being limited in width. It would cool if you could choose between kayak or bike and support 2 player VS mode.

Three colors without flicker shouldn't be an issue if you preload A, X, and Y with the colors and then STA/X/Y COLUBK repeatedly. This would require self modifying assembly code or using the Strong-ARM framework. I put together a quick POC to see what it would look like and it seems like it would work well for what you're trying to do. This is a template for what the kernel looks like. st? are replaced with sta, stx, or sty depending on which value needs to be written at that time. lda #p0 sta GRP0 lda #p1 sta.w GRP1 lda #WHITE jmp st? COLUBK st? COLUBK st? COLUBK st? COLUBK st? COLUBK st? COLUBK st? COLUBK st? COLUBK st? COLUBK st? COLUBK st? COLUBK st? COLUBK st? COLUBK st? COLUBK st? COLUBK st? COLUBK st? COLUBK st? ENABL st? ENAM0 st? ENAM1

My biggest concern was with thumb 2 and FPU. Not sure if Thumbulator handles those. I wasn't planning on limiting things to just thumb, but I suppose we could if it's the difference between stella support or not.

There is certainly desire to have it running in Stella. For development purposes I hacked together a modified version of stella which builds the game as part of stella.exe and runs it that way. This is actually great for development purposes because you get all the visual studio tools like conditional breakpoints and the ability to modify variables during runtime. Obviously that's not going to work for a general solution since there would be massive security implications with shipping Atari games as windows/Linux executables. The Uno cart uses a STM32f4 MCU. If there's an open source emulator for the Cortex-M4 it would certainly be possible to add support to stella.

Isn't that exactly what your code is designed to do? ;------------------------------------- ; Skip player movement if attacking (preserving player attacking animation) ; if joy0fire || _Bit0_P0_Attacking{0} then goto __Skip_Player_Movement

I was actually referring to the 128 pixel gapless aspect. Had I posted to the topic I meant to reply to that would have been more obvious. There was just enough room to add support for changing the color each line. The plan is to use this for 128pixel title screens. If text is the only thing you need there's a 36 char kernel. That one's not gapless so it's only good for text. Eventually they will both find their way into the Strong-ARM framework.

A common problem is page boundary crossing. If you have a branch statement that gets moved because some code is inserted before it you could end up losing a cycle if the branch target is in a different page because of the routine being relocated. Stepping through in stella debugger should let you easily see if this is the case or not.

That's exactly what I was looking for. Thanks! Now I just need to port the kernel over to C.

I thought I remember finding a post with a 112 or 128 pixel wide interlaced kernel, but now I can't seem to find it. Did anyone ever succeed at going wider than 96? I found some text kernels which exceeded 24 characters, but they all have gaps in them.

The Collect 2 source probably has an example of how assembly does bank switching in DPC+. Did you look here?

Yeah, I'm not very happy with how badly I implemented my algorithm. I thought the algorithm itself was pretty neat, but after seeing how much better the 6502 wiki solution is I didn't bother trying to fix mine up. Though, fully understanding and commenting that solution might be its own challenge What emulator where you using to test with? I was thinking that we should build a 2600 program to serve as a test harness for future challenges. I.E. for this challenge it could use the RIOT timer to track how long it takes a provided algorithm to perform all 65k possible divisions and then display a total in hex once it's done.

Not at this time. Good idea though.

Possible, yes. Practical, no. The two carts use completely different microcontrollers with completely different capabilities.

For those of you who would like to write 2600 games in C++ there is now a project template you can use to get started. The following are required to build and run: UnoCart-2600 with latest firmware that supports ACE file format Atollic TrueSTUDIO for STM32 Source code The template produces a simple bin which draws some skulls and lets you move around P0 with the joystick. You can create games up to 448KB in size and use as much of the 192KB of RAM as you'd like. Currently there is no support for this file format in any emulators. You must test on actual hardware with the UnoCart-2600.

This was a really cool challenge. I think my solution is doing something similar to what Crispy's solution does. It uses one less byte of ZP ram and only the A and X registers. I didn't test it to verify that it actually works and I have no idea if it's faster with regards to worst case and average.

Looks like you're making really good progress now.

You're missing indentation on lines 43,44 and 95. I'd recommend indenting more than a single space so it's easier to spot the difference between labels and code.

If you click more reply options there will be an option to attach files. Uploading your .bas file will make it easier for us to help you with the errors.

Sounds like you are looking for this? http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpcplus