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...

It's one of the most visually attractive 2600 games I've seen. Congrats on making such a good looking game! 🤩

I have to admit, it looks like a tank where the turret keeps disappearing, and comes across as kind of glitchy / weird. Not a fan of that particular animation...

To elaborate on this: the SetXPosition routine is not a panacea. Imagine, for example you have a score display that is always in the same position. It rarely makes sense to set it's X position and have the overhead (in bytes AND is used cycles) of calling the routine. Typically what is done is to DIRECTLY hit RESP0/1 and manually set HMP0/1. Same thing when having objects that don't move, like logo displays and such. At times like these, you will need to understand the positioning more deeply. Depending on the game and the display you are trying to achieve, sometimes you MUST find creative ways of positioning. More advanced stuff uses indirect jump tables and multiple kernels for given lines / sections.

X positions can be 0-159 (160 positions). In binary, anything 128 or above is considered negative. So you'd never be able to position anything right of 128 or above. It is, really. What's left is the remainder, essentially. COMBAT does do RESP0 only at the start of game, and uses HMP during play, just as you say. But some games may want to arbitrarily position something more than +/- 16 pixels each time. And in re-using sprite resources, often positioning is done mid-frame, often many times per frame. Imagine "flickering" a sprite every other frame to represent two objects, for example. Each would have it's own independent X position.

Back in the day, 2K carts were significantly cheaper, yeah. That changed later on. But this was almost 2K anyways, like I said. And I saw a lot of stuff like: LDA addr CMP #0 BNE label And that CMP #0 is unneeded, the LDA sets the flag already. I didn't use git at all, I just downloaded the source zip and worked on that way. And I only optimized as much as necessary to get it below 2K, more optimizations were / are possible. Just something I enjoy doing. I didn't really comment ANYTHING in the source, so I didn't want to post it...

I'm a programmer, and I can't help myself... I looked at your source code, and saw a whole bunch of possible optimizations, and a lot of free space already, so I optimized it and made it into a 2K game instead of 4K. I only had to free up around 256 bytes or so... Hope you don't mind... BookOfFiveRings.bin Hopefully, I didn't break anything. I did this mostly for my own amusement, I like optimizing 6502 code....

Looks good. My suggestions: It should be a series of islands. Sometimes you have to land and re-arm / re-fuel. Other times, you have to bomb and shoot enemy targets. You don't know if it's a friendly island or an enemy island at first. In the sky between islands, you fight planes and ships. This goes on as long as you can, getting progressively more difficult. Just some ideas. "Blue Max 2600" LOL....

Yes. Paging @Dionoid

This code (I didn't invent it) nybble swaps a byte cleverly. Maybe you can make use of it somehow: ASL ADC #$80 ROL ASL ADC #$80 ROL

LOTS of good ideas here!! 😃 I love stuff like this, I'd never have thought of the jumping between using ASL and ROL. And it preserves the X and Y registers, awesome. I'm actually using that one. These ideas are the sort of thing I'd like to have in a reference. I keep having to look up various things in various books and places online, etc, and always wish I had all of it in one handy location. Something I hope to work on, time permitting...