azure

I use this and don't get any warnings: IFCONST AFP_TARGET IF AFP_TARGET != 1 lda #%00000010 sta VBLANK ENDIF ENDIF Then tried adding a new reference I know doesn't exist: IFCONST TEST_0987654321 ECHO "defined" ENDIF Still no warnings. Are you sure it's not caused by something else? Dasm version: DASM 2.20.11 20171206

The motion physics on the dropping cubes is incredible.

Has anyone suggested using bankswitching as memory? If you had 8 banks, that would provide 3 bits of state. Each bank would have mostly duplicate code, but coded with an identifier between 0 and 7. Storing the value of 5 would be done by jumping to bank 5.

Making this game is going to be a lot of hard work.

Ahh, so it's accurate game play. Fine details like this really make this port even more impressive.

I was watching ZPH's latest video and noticed an enemy missile passed through the player ship while the ship was being captured. I attached an animated GIF of it. It's around the time code 1:05:06 on the Youtube video. Is that a bug or normal Galaga game play?

If I remember right, sometimes the thread gets bumped on the May anniversary as well.

My usage is already inside a subroutine. I was just posting a snippet. I should put the SUBROUTINE keyword inside the REPEAT? I have this structure: Sub SUBROUTINE REPEAT 5 .label ; some code REPEND rts So it should be? Sub SUBROUTINE REPEAT 5 SUBROUTINE .label ; some code REPEND rts Update: It looks like that last one is doing what I wanted.

Does anyone know if dasm supports a concatenation operator similar to C preprocessor's ## operator? I'd like to be able to do this: .IDX SET 1 REPEAT 5 .label ## .IDX ; <-------- ; code here .IDX SET .IDX + 1 REPEND I could declare a macro and do the same thing, but sometimes I prefer the code to be inline. MAC INSERT_CODE .label{1} ; code here ENDM ; -------------------- .IDX SET 1 REPEAT 5 INSERT_CODE .IDX .IDX SET .IDX + 1 REPEND Or do you think I should switch to a different assembler or use a C preprocessor?

What do you all think about numbering the cart CX26116 since the Atari version never got released?

Here's my wish list: better support for modern SD cards better Atari compatibility (i.e. using the Stella emulator) phospher delay option for games that flicker a lot a contrast or brightness control sensitivity control for paddles charging cable that's either micro USB B or USB C I had to insert some hacks to get my game working on the portable. It's also hard to see the ghosts in Ms Pac-Man and the hearts in Popeye, so contrast/brightness control would help. One last thing. I suppose it's an anti-wish list. I'd hope the button layout never changes, so that homebrew games can be coded to use the buttons like Gameboy buttons. Changing the button layout would mess that up. (Excluding the D-pad mentioned earlier. That one is a great idea.)

I'm betting it's Basketball. He mentioned once before.

Ahh. Thanks for letting me know.

The process is almost the same as drawing sprites using GRP0 or GRP1. The kernel steps through each line, determines if the sprite should display, fetches a row of sprite data, and writes the data to PF1. Using the playfield for a sprite means accepting a few sacrifices. No horizontal positioning. It can only move up and down (unless you come up with a scheme for moving it across PF0/PF1/PF2.) It's also going to have chunky resolution: 4 color pixel wide block. There are two tutorials I know of: Andrew Davie's tutorials http://atariage.com/forums/topic/33233-sorted-table-of-contents/ Nick Bensema and Random Terrain's tutorial on the playfield: http://www.randomterrain.com/atari-2600-memories-how-to-draw-a-playfield.html

I deleted your files I uploaded in my comment in order to respect your wish to delete your program. If you ever want them back, send me a PM. I'm just very puzzled by this thread. Development for the 2600 is hard. It requires an extraordinary level of patience and rework. In many ways it's very different from traditional game development, but in other ways it's identical. My game isn't complete, but it's getting close. The lessons I've learned from this unusual series of problems have made it a very satisfying intellectual challenge. I'm only just scratching the surface. I'm still working out how 2600 shoot'em ups manage to multiplex so many sprites. It's one giant puzzle of lots of smaller puzzles, which appeals to me a lot. It requires a level of stubbornness and resilience to frustration. I suggest you keep trying. There's no requirement that your final game design be the same as the initial design. You could end up with a completely different game, and nobody is going to judge you for it. If it's turning out not to be your cup of tea, that's fine too. There's plenty of other platforms you can code for.

I was replying right as you updated. What I meant by refactoring is the 3rd PosObject call just needed to happen after the digits were drawn. Also, there are a lot of 2600 games that are similar, because the nature of the hardware forces the same limits one every game. I wouldn't worry about it. I think a bunch of projects end up being something different from what they started out as, because you find out some designs either won't work or you think of better game elements that change the dynamic of the game.

This is an interesting concept. It's gravity + bumper cars + Bezerk's electric walls.

There are a few problems. The code is not writing to RAM, because there's no RAM segment, so the memory writes are being ignored. The 6 digit drawing code is inside the vertical blank, so it will never render on screen. NUSIZ needs to be set to 3 copies close. sta HMOVE should immediately follow sta WYSNC due to timing reasons. DrawDigits is incorrect, because you're using absolute indexing. It needs to be indirect indexed otherwise it messes up the timing. Example: lda (VAR),y DrawDigits is position sensitive, so you need to horizontally position sprite 0 to position 56 and sprite 1 to position 64. Timing must be exact. I uploaded a modified copy that shows the score working. I had to comment out the player movement section, because the PosObject interfered with the 6 digit score. Some refactoring is going to be needed to keep the multiplexed sprites within their own horizontal sections. If you had intended for the score to be non-centered on the screen, you'll have to fiddle with the routine and positioning to make the timing work.

I think the investor's mistake is believing antique video games are a safe investment. For any given collectible game, there might be a forgotten warehouse full of pristine copies. When those copies are discovered and released to the market, it can reduce the value of the game. Nobody owes the collector a return on investment. If the value of a rare game depends on the ROM never getting released, then I think it's a flawed investment strategy. Collectors should not be assume there's no risk, because all investments have risks. Most of the time it pays off for video game collectors. Sometimes it doesn't. If the investment relies on possessing a copy of someone else's copyrighted material, then maybe it was never a good investment.

I've uploaded the latest version and moved the prior versions to a zip file. This update includes card animations on dealing cards and code refactoring. It's not a big change, but it was the most difficult, because I spent most the time trying to make the animations work with 12 bytes of RAM, which realistically wasn't going to work. I went with a compromise by re-using temporary variables and the bottom of the stack. The cards are constructed as a composite of sprites divided into top and bottom halves. The prior implementation using 12 bytes of RAM relied on doing pointer setup in the middle of the render. This worked fine, because the graphics for those scan lines were solid white, but it doesn't work when the cards are animated. Edit: It looks like there's some screen bounce on real hardware that didn't show up on emulation. I'll fix those soon.

I think a text editor and a task list works. That's not an exciting answer, but a fancy editor might make task tracking more exciting. When solo projects use project management software, they tend to use it to communicate current progress with clients, document features in the contract, and provide justification for billable hours. When team projects use it, they're using it to organize, allocate, and coordinate tasks between teammates in addition to those other reasons. Is it worth it for a solo 2600 project in which there's no client? I'm unsure, because there's so much R&D and re-work involved. Any progress reports and burndown charts are going to be unreliable or misleading, because they will be documenting tasks that go in and out of completed status as they're reopened and redone multiple times. I think the information produced will be of mostly of informational value as opposed to something you can make decisions on. And there's also the creative aspect. How do you plan creativity? Hmm.

I was watching ZPH's video and I had a thought. Would you consider adding a mode such that pressing the button can make the player hop over the snake? It would only hop 1 block and be limited to 1 or 2 uses. It might add another dimension to the game play. It could also be a power up.

When I get a chance to, I'll make a vector drawing so it'll be easier to see.

When it starts up in bank 0, I get a black screen. The code zeros out memory and then calls brk. Your brk handler ($10fe - $10ff) is pointing to $1000, which runs your initialization again, so it enters an infinite loop. When the code starts up in bank 1, it seems to work correctly. You have to assume the bank you start in will be random or indeterminate, so if you want your game to always start in bank 1, you need to make bank 0's initialization switch to bank 1.

I had a macro reversed. I fixed and uploaded. Delete any prior 0.7 downloads. It's been an issue I've been concerned with since the beginning. I was worried about giving impression the UI is buggy. I had settled on playing an error sound for now, but I was planning on having the bottom row of chips indicate the player's current chips, so that might help. Hiding the options when there aren't enough chips is doable though. It'd be fairly trivial with my current codebase, because they're implemented as flags. It's hard for me to know what's best for the player since I'm a bit close to the code right now. Having this sort of feedback has been quite helpful I think. I'm planning on that one for the next version. Oh, and for the random number generator, that will be getting an overhaul. I don't like my current version. It continously cycles, so if you wait a moment of time before hitting, you will be dealt a different card. If you wait a little longer, it'll again be a different card. I'm going to change it so that it works more like a real deck. Once the shuffle of a real deck is done, the card order is fixed. I'm going to make the RNG work the same way.