Thomas Jentzsch

That's the disabled SaveKey code.

Nice little project. Only the colors are too close. I would be much better playable with more identifiable color gradients.

Cool. Now I only need your GitHub name to invite you. BTW: I am looking for 15 bytes only.

Thanks for your kind offer. The code is heavily optimized already and partially not easy to understand even for me. I can give you read access, but I would prefer to review before you push anything. OK?

If have fixed this in the new RC7 version attached to the first post. 0 bytes free! Note: A PAL-60 version is now included too. But it may have slight timing problems. Please let me know if you notice any.

No, that was new to me. I only found a label on a Portuguese website, so I thought the game may have come from there. Thanks for sharing this information. Do you know who programmed this game? And any idea about that Portuguese label?

That's because the heli is drawn using a missile. And that doesn't allow for gaps between pixel. I haven't found any better solution yet.

I have added RC6 with the requested control modification to the first post (NTSC only). I am not 100% sure if that's what you were requesting, so please let me know. BTW: I am still struggling with the ROM space (that's why there is not PAL-60), so I am not 100% sure if I can get this into the final version.

Finally coming back to this. He two red texts seem to be contradictory. IMO that is the same case: the helicopter is stopped, the fire button is pressed and you then you move the joystick into a direction. But the results are requested different. Obviously this cannot work. Or am I missing something here?

The movie is also very good.

That would make your shows even more fun too watch.

And not even close to what is realistic on a real 2600.

You cannot be 100% sure that a $FF at the beginning of a block always indicates an empty block. E.g. if a game saves high scores per game variation and the first one hasn't been played, the first by will not be initialized. IMO it would be better to check the whole block. I suppose that's somewhere mentioned in the documentation. But since almost no one does mass reads or writes, probably no one ever cared.

I liked the show, even though I was not completely able to follow all moves. I suppose the problem is, that the screen went black immediately after Aerlan made his moves. So when the computer came back, it was almost like two moves had happened. That's not problem for the player as he knows what he just did, but for someone watching a game. Maybe a brief pause before the screen goes all black would help here. I wonder if there is any randomness in your calculations and decisions. E.g. if two moves are considered almost identical equal, will your engine always select the slightly better one. Or is there a chance for choosing the other one? This would make the game play a bit more human and less predictable. Also, wouldn't it make sense to vary the search depth, making it more time based? E.g. if there are less pieces on the board (or less possible moves), you could try going 1 or 2 (or even more in an endgame) plys deeper? A human player would effectively do the same too. BTW: Even if you improve the engine, there should be an option to come back to this one. Aerlan seems to have liked it.

I have just added a new scheme 3EX to the "refactor-cart" branch of Stella. This one supports 256K RAM, else it is identical to 3E. However the fixed bank at the 2nd 2K segment and the segment size itself are severe limitations, which Andrew and I found out when implementing Boulder Dash. After some experimenting I came up with 3E+, which is basically 3E with 1K segments. There are some other bells and whistles (e.g. last segment is not fixed), but these are no that important. The disadvantage of 3E+ is, that it only supports 64K ROM and 32K RAM. This seemed plenty back then, but today it may have become a bit too small. BTW: Bad Apple is the demo which relies on 3E wrapping around RAM at 32K.

Your code seems wrong. E.g. Where do you set the start address when reading from the SaveKey for the very first time? The code seems to jump this part when it first executes DoCopy. And where are the calls to the i2c_stopwrite and i2c_startwrite routines after setting up the start addresses? Also you are accessing left and right port in parallel. This won't work, both macros are writing to the same registers, interfering each other.

See above. Meanwhile I don't think your code is doing it right.

I just checked with different values in the file and the result is always $FE. So there is something fundamental wrong. Your code looks fine and the I2C L macros too. Maybe the bug is in Stella and the SaveKey emulation. I will have a look, but I am not very firm with that code. Edit: Checked your code again. Are you sure you are initializing the read addresses correctly? I cannot find stopwrite and startwrite. Also you should strictly separate access to left and right ports, the IC2 macros will corrupt the other port.

Here is a macro collection from me, which we used for Aardvark. It is not well documented, but maybe you it helps you. The free space macros count the free space created by ALIGN and (R)ORG and output the result. TJ_Macros.h

Just wait for the cart release.

Maybe @Albert can repair that page.

Can't we?

Look here: There are 3F and 3E versions. The latest one (BadApple1_0) is probably the best test ROM for you.

Alternatively you can use: TIA_BASE_READ_ADDRESS = $30 in the first line of your code (before include vcs.h) Originally vcs.h had the TIA read registers defined at $3x, but River Raid uses a mirror at $0x. So I had to add "-$30" to any TIA read access register. Today vcs.h. defaults to $0x, TIA_BASE_READ_ADDRESS = $30 changes that to the old behavior.

Sounds correct. Sorry, very busy today.