SpiceWare

seen 365 of Pac? https://twitter.com/365ofpac

Aha! I just noticed the "Net Metering Credit" in the first image used -503 instead of the expected -665, and the "Remaining Bank" in the second image never had a value before but is now 162. So it looks like I won't ever end up with $0 or negative bill, but did build up a credit.

Well that's a bummer. I sent back 162 kWh more to the grid than I took from it, but it wasn't enough to cover Centerpoint's Delivery Charges.

If you want to animate the Mad Bomber then search for this section of code: ; select which Mad Bomber Image will be shown ; no animation lda #0 ; end no animation ; slower animation ; lda frameCount ; and #%00100000 ; end slower animation ; faster animation ; lda frameCount ; and #%00010000 ; asl ; end faster animation Comment out the lda #0, and uncomment out one of the following sections of code, such as this: ; select which Mad Bomber Image will be shown ; no animation ; lda #0 ; end no animation ; slower animation lda frameCount and #%00100000 ; end slower animation ; faster animation ; lda frameCount ; and #%00010000 ; asl ; end faster animation After doing so the images will alternate between A and B versions. Frown: Smile: Surprise: ROM kaboom_deluxe_20200517_animated.bin

Done with the changes to use distinct Mad Bomber images and improve the city skyline. Also made a minor tweak to the buckets to add the missing water pixel. This reply contains my final set of changes for Kaboom! Deluxe!. While I'm not using it, it is set up to support animation - I'll explain how to enable that in the next reply. Summary of changes: Added sunset city skyline. Updated Activision logo to the rainbow variant. Added game variations 3-8, Pitch and Catch where the other player controls the Mad Bomber. Mad Bomber moves slowest in 3, fastest in 8. Game play for variations 1 and 2 is the same as in the original Kaboom! Paddle position indicator for Mad Bomber player. Paddle button to start new game. Skyline & Rainbow logo: In games 3+ a paddle position indicator will show up behind the score: NTSC kaboom_deluxe_20200517_NTSC.bin PAL kaboom_deluxe_20200517_PAL.bin PAL60 kaboom_deluxe_20200517_PAL60.bin Source kaboom_deluxe.asm

Made some progress - after removing that checkForLowerMouth logic to manipulate the Mad Bomber's face I was able to lower the building tops past the Mad Bomber's Mouth: I then cloned the Mad Bomber kernel 2 times and updated each one to draw one of the other images. Smile: Surprised: I have not yet added the extra scanline after the score, so to test the new Mad Bomber kernels I've been commenting/uncommenting JMP statements: ; jmp MadBomberFrowning jmp MadBomberSmiling ; jmp MadBomberSurprised That issue with the bombs shifting as they pass the water buckets returned, same as seen before in Reply 18. Possibly that'll clear up on its own once I add the extra scanline after the score and write the new logic to select which Mad Bomber image to draw.

@e1will - I know it's been a while since you interviewed her, but do you still have contact with Carla Meninsky? If so I think it'd be awesome if you could show her this. @Omegamatrix - was curious if my work on a warlords disassembly was helpful, or if you rolled your own.

Joystick? For Warlords?

Check the comments in Step 4 - 2 Line Kernel of my 2600 tutorial, one of my replies goes into detail in how the .byte $2c trick works.

Use a byte of RAM: outside of kernel: cpx #5 bcc .nomask lda #%11110000 .byte $2c ; skips over the next LDA instruction .nomask: lda #%11111111 sta mask Kernel: lda (objectptr),y and mask sta GRP1

Super impressive! Using the playfield for the grunts was a stroke of genius.

I suspect not, it would require 3 updates: lda #brick_color sta COLUPF lda brickpattern, y sta PF2 ... lda #black sta COLUPF because the playfield is used to hide the HMOVE bars: Crackpots doesn't have to read 2 paddles during the kernel, so had the time to do it. Adding the 2nd paddle reading already made it tight by the buckets, so bricks definitely couldn't be drawn in the area where the buckets and splashes get drawn.

Did some preliminary research last night. I was originally looking to reuse that variable bomberExpressionState to control which of the 3 images were shown, and have it populated before the screen starts to be drawn. Turned out tempCharHolder, used during the score display, is the exact same byte of RAM so the test values I was putting in bomberExpressionState were getting overwritten. All the other RAM is spoken for, but due to how the memory mapping for the cartridge ROM works in the 2600 I can use the upper 3 bits of a digit pointer for the score to hold it - I explain how that works here. Conveniently the BIT instruction makes it easy to check the uppermost 2 bits, allowing me to do this in the amount of time left that's left on the scanline just before the one that starts drawing the buildings and MadBomber: bit tempWhichMadBomber ; 3 63 bmi MadbomberSurprised ; 2 65 (3 66) bvs MadBomberSmiling ; 2 67 (3 68) jmp MadBomberFrowning ; 3 70 Hmm - there's not enough time to do that with how the screen is currently drawn, but I could insert an extra scanline between the score and skyline*. Doing so would allow me to use those 3 bits to select from 8 different images for the Mad Bomber. * would also need to remove one from after the Activision logo to keep the scanline count at 262.

The RAM's used up so using a Graphic Pointer would be tricky, but the ROM's now 4K with plenty of room left. As such the Mad Bomber kernel could be set up to use 3 different routines that are hard coded to using one of these for the graphics: lda MadBomberFrown,x lda MadBomberSurprise,x lda MadBomberSmile,x I'll take a look at making that change later this week as that should let me make the buildings look better. They're a bit squished compared to CrackPot because I couldn't update the building graphics on the scanline with the Mad Bomber frown/surprise/smile logic.

Usually we'd use a couple bytes of RAM for a graphic pointer, which requires using Y for the loop, and have 3 separate graphic images. lda (MadBomberGfxPtr),y sta GRP1 RAM usage is tight, as was the 2K ROM, so Larry Kaplan hard coded the routine to use a single graphic image (lda MadBomber,x) and changed the graphics on the fly when X = 22. DrawMadBomber lda MadBomberColors,x ; 4 eor colorEOR ; 3 and hueMask ; 3 sta WSYNC ; 3 ;-------------------------------------- sta COLUP1 ; 3 = @03 lda MadBomber,x ; 4 cpx #22 ; 2 are we drawing Bomber's upper mouth bne .checkForLowerMouth ; 2� if not check lower mouth lda #%01101100 ; 2 Mad Bomber frown graphic .checkForLowerMouth bcs .drawMadBomber ; 2� lda #%01101100 ; 2 Mad Bomber surprise graphic bit bomberExpressionState ; 3 bmi .drawMadBomber ; 2� lda #%01010100 ; 2 Mad Bomber smile graphic .drawMadBomber sta GRP1 ; 3 dey ; 2 dex ; 2 cpx #21 ; 2 bcs DrawMadBomber ; 2� .colorMadBomberLoop lda MadBomberColors,x ; 4 eor colorEOR ; 3 and hueMask ; 3 cpx #3 ; 2 bne .colorMadBomber ; 2�+1 lda backgroundColor ; 3 sta WSYNC ; 3

I don't recall what direction is holding, but if you save the value of SCHWA from one frame you can easily compare it using EOR. lda SWCHA eor SAVED_SWCHA beq no_change ; handle change here, any bit in the accumulator that's a 1 is a joystick direction that's not the same as the prior frame no_change: lda SWCHA sta SAVED_SWCHA

To get 120 Hz you would have to cut the total scanlines in half to 131. I doubt any display will handle that very well. You can do some experiments using Jitter.bin from this blog entry, which should also answer your Jittery Recover question. Jitter's default screen size is 262 with 128 rainbow lines being drawn. Use joystick to change rainbow line count, then hold fire for it to take affect. My C=1084S can handle a variety of screen sizes, I frequently use it for PAL games. It can handle down to 51 just fine (185 scanlines @ 85.0 Hz): At 50 and 49 the 1084S becomes unstable. From 48 down to 1 it draws the screen twice.

Don't change the Hz, the further you get from spec the more likely the picture will become unstable on a real display. Do some research on fractional or subpixel movement which lets you move an object 0.7, 1, 1.2, etc. pixels per frame. Example would be this topic:

Awesome! I encountered this with Medieval Mayhem about a year after it was released! I forgot that @batari wrote a tool that analyzes the list generated by dasm to locate code that appears to be missing a #. However, the link to the source is broken. Hopefully he still has it utility and can fix the blog entry. Might make sense to add it to Club DASM as well.

Correct.

most likely you left out a # on an immediate mode instruction, it's a very common bug that causes problems like you're seeing. Check the following topics for examples of this, as well as how to make those problems show up in Stella. from reply 10 onward http://atariage.com/forums/topic/258401-trex-aka-first-attempt-at-6507 from 34 onward http://atariage.com/forums/topic/269701-nyan-cat-game-work-in-progress/

By default the current directory is NOT part of the search path in Linux for executables. To tell it to run something in the current directory you need to use ./ before the program, as in: ./dasm

Confirmed with an original cartridge, Stampede just freezes when the last stray gets past you.

Maybe this will work for you - hit TAB to bring up Options: Click Snapshots...: Check Ignore Scaling (1x mode). That results in 320x snapshots (height depends on game, NTSC will be shorter than PAL): If you need a larger image then use a graphic program to resize it to 640x or 960x, just be sure to do so without interpolation: If you resize using interpolation you end up with those fuzzy pixels: Closeup without interpolation: Closeup with interpolation: