EnderDude

Yeah, so I can make all kinds of mock-ups, and maybe they might become reality, like I can have a mock-up of Speed King looking better (I think it's worth it because the road has smooth animation, even compared to Pole Position!):

Say, can COLBK be a "fifth" color of the playfield at a resolution of 160x192?

Because it can short-circuit the internal board of some systems is my best guess...

What I'm saying is that it isn't necessary for the enemies to overlap the mountains because they're smaller, giving the illusion that they have more freedom of movement.

Also, when the sprites are smaller, it makes everything less crowded. Hopefully, this whole thing isn't a pipe dream that it would be easy to accomplish.

In fact, if you look at the space that the ships fly in, that empty space is a lot, and the peak of the jump of the buggy also keeps the wheels well within the 16 scan line area.

I checked, and the wheels at their peak DON'T overlap into the parallax area, and the aliens overlap the mountains only a tiny bit, so we can shorten their flying area a bit to compensate for that.

To show this idea visually, I've outlined the pm's in green, and the software sprites in yellow.

Okay. Looking at the area that the enemies fly in, they are also in these scan lines not using parallax scrolling, so they can still be software. The enemy missiles can be hardware pm's, just not so large. Player missiles going vertically can also be hardware, but the horizontal ones can be software, because of it being in that 16 scan line area on the bottom that doesn't use parallax scrolling. Can the wheels of the buggy still be software sprites, being in that non-changing area of 16 scan lines? For the uphill parts, that buggy has to use hardware pm's. Maybe the boulders can be software, since they're going down with the slope.

No, and I don't have the time to learn how to because... school.

No, I've never done software for the Atari. Is it difficult to program software sprites? I've seen many games use interrupts of the 9 color registers to get several colors by changing the registers per scan line.

I thought using the original code with software sprites would be harder to implement than starting from scratch, with the intention of also using software sprites.

Should we remake the game from scratch, or should we use most of the original code to do this?

So, why didn't they use software sprites?

The "tank tracks" to me look more like 5-toothed gears. I've made this palette that would be used if we go the soft sprite route :

The sprites on the arcade are smaller, when comparing them to the area of the screen. So, double sized sprites are the ticket. Quad sprites are a little overboard.

So, why did they make the PM's so large in the first place?

Thanks, but v4 doesn't have anything different from v1, but v2 just has the 3rd channel clocked by the cpu's clock (1.79 mhz).

If Moon Patrol would be simple enough to start from scratch, then probably that would be the better way to go. If it's not, you can look at the map of the ROM, then you can disassemble only those parts of the game that can potentially code to give you less of a headache while writing the code for the soft sprites.

Anyway, I think someone else can replace the music. If anyone is interested, here is the RMT file in a zip file (it's just a converted mod file) So, let's focus on the enemy ships now. If you DON'T use the 5th hardware sprite, there would be 4 colors available, excluding black, in the area of the ships. That area is ripe for soft sprite opportunity, with 4 registers free! The 5th color is devoted to enemy missiles globally. Vertical player missiles would be hardware missiles, while the horizontal missiles are software sprites. I have a mock-up of this idea as a photo below (even the arcade version of the enemy sprites had a maximum of 3 colors that are all shared!). I'm pretty sure that we can make Moon Patrol a lot better on the Atari 8-bit series. moon patrol.zip

When I do paste random blocks of data from the SAP file (which is a remade version of the song), it doesn't give the intended result. As in, it's a bunch of random notes. So, what do you mean by replacing the original routine with a translation that RMT expects? Is RMT embedded in the SAP file itself?

So, other than graphics, how would I change the music data to something that's from, for example, rmt? Do I copy a certain part of the sap file into the area for the music or...?

I've never realized that graphics take up a bunch of space before I've made this rough map of the 16k ROM (not to scale):

Well, the maximum resolution of any hardware sprite is 8 pixels wide. So you have 8 pixels of resolution to work with. However, you can double or quadruple the pixels to cover more space. I've made another mock-up that should look a lot more like the sprites used in the arcade (including the rock). Can pixels of a color register in the playfield go over pm sprites?

If you look at the peak of the y position of the wheels in the original version, they DON'T overlap. Also, looking at the uphill sections, I don't think you can jump, and it looks like there are a lot of blank scan lines.