glurk

Yes, that ocean liner looks good, but if you do try to scroll it horizontally, it can only go one blocky PF pixel at a time, and it will of course be super jumpy and not look very good. And because of the way the PF is stored and rendered, it is extremely computationally expensive to even draw it asymmetrically, much less SCROLL it. That's kind of the reason you never really saw this done BITD. I wish you luck, but I think you will run into issues with the approach...

Could not be done by playfield color. Could oossibly be done by drawing / notdrawing playfield in selected areas. Maze would necessarily be based purely on coordinates. This would require extra RAM and bankswitching at least, and possibly DPC+ or some ARM scheme. I think its possible but extremenly difficult, probably best for a very experienced 2600 programmer.

He said earlier that he overwrote some of the binary, unsure of what he was modifying, and I really didn't want to try to decipher a corrupted disassembly. Hopefully once the sprite data areas are identified, swapping them would be trivial. I don't want to sound like I'm promising anything, either... Especially since he doesn't seem to want to even do the most basic thing to give a programmer something to look at.

You should do what I said earlier. I was trying to help... First, load up the ORIGINAL GAME - NOT THE HACK. And play it extensively. This allows the built in disassembler in Stella to work better. Then go into the commandline and type 'savedis' this will create a disassembly file.

It probably could be done in some limited way, but look at the existing card games I mentioned before, like Bridge, or Blackjack. The graphics are just "good enough" but not really great. The 2600's graphics capabilities (and lack of...) are quite well known, even to non-programmers. 2 sprites, 2 missiles, one ball, and a 40 pixel playfield. There just really isn't enough there to do 7 rows of cards in full color, wvith suits and all. Even with DPC type enhancements it would be difficult, and orobably use much flicker. But I'm sure some clever programmer could pull off some limited version in some way. But it would involve compromise...

ROMs for the 2600 are not encrypted at all. But they are the pure binary representation of the 6507 code run by the machine's processor. These are created by writing source code, and then compiling/assembling that. To get source code BACK FROM the binary ROM is a laborius task, and labels and variable names, and comments have to be added, essentially "guessed at" but in an intelligent way... This has already been done for many games, and a member here has helpfully done these: https://github.com/DNSDEBRO/Disassemblies/tree/main/Atari2600

I'd say the problem with that would be less about RAM (which can be added in carts) and more about any adequate way to display all of the cards properly. Very few card games have been made for the 2600, and those that have are a bit lacking in the display department. Although I'm sure some people enjoy Bridge and Blackjack...

I really do not understand this coding style at all, LOL. But I gave it a go, and this kinda works. Sort of... bert35.asm

This is excellent! Just my opinion, but I think it's really good, especially for a 2600 game. I didn't read the instructions, just figured it out as I went, which I believe you should be able to do. Played it till it ended. There is a lot going on!! Looks good, plays good, and is fun. No real suggestions, but I like it...

What you need is a full source code disassembly of the ROM to work with. I myself have done a number of them, as have a few others. In my case, I was porting 2600 games to the 8-bit computer line. Stella itself will do most of the heavy lifing. I'll help you begin. First, load up the ORIGINAL GAME - NOT THE HACK. And play it extensively. This allows the built in disassembler in Stella to work better. Then go into the commandline and type 'savedis' this will create a disassembly file. Probably you will also want to do a 'diff' between the originsl ROM and the hack to isolate the differences. A skilled programmer would need to go over the results and clean it all up and label routines and branches, code and data, etc. I know how to do all this, but I'm not particularly interested. Its a lot of tedious work. There are many others hete also capable of doing the work, but you'll have to find someone with enogh interest to take it on. Offering money is probably not much motivation for the type of programmer you need. You have to find someone who WANTS to do it... Godd luck.

Is not this correct? $0040 - $007F = mirror of $0000 - $003F So $70 would be mirror of $30 ?

Minor suggestion - You are using a 6-digit score, but your scoring is very low, so the top 3 digits are unlikely to ever see use. Maybe yo should use 10, 20, 30 points, or possibly even larger. So that 999,999 becomes maybe possible...

The side-to-side movement ability seems pointless. Looks like the best strategy is to just sit mid-screen. Now, maybe if there were obstacles to dodge around or something.... I think it needs more to it... Meant only as helpful suggestion, ofc.

@l12n I suspect you intended to post a .bin file? You didn't...

I don't know anything about bBASIC, (I'm a hardcore ASM guy) but I will say that it looks like you are wasting a large amount of ROM space with your animation frames. All of the static stuff in the top part of the image frames should not be there, the animation frames should consist of only the areas that change (spider at bottom) to save space. I saw in your other thread that it has a height of 56? Looks like that could be reduced by half, at least...