SpiceWare

Yep, I cover that in the Random Numbers entry of my Collect tutorial.

Yep, which is why I seldom play it on hardware.

Yep, here's a test of clocking (a newer) CPU at the same speed as TIA, resulting in 228 cycles of processing time per scanline.

Yep, flicker is noticeable and different people have a different tolerance level. For me: small objects at 30 Hz (and even at 20 Hz) is OK large objects (like the boss in Stay Frosty 2) at 30 Hz is annoying, if kept to a minimum I'll play the game full screen at 30 Hz is revolting, resulting in me not playing the game. The use of flicker blinds, as seen in the 32 character text display, can help. That takes full screen objects from revolting to just annoying. Flicker blind (line-by-line player shifting) for even frames: 1_2_3_4_5_6_ _1_2_3_4_5_6 1_2_3_4_5_6_ _1_2_3_4_5_6 ... 1_2_3_4_5_6_ _1_2_3_4_5_6 for odd frames: _1_2_3_4_5_6 1_2_3_4_5_6_ _1_2_3_4_5_6 1_2_3_4_5_6_ ... _1_2_3_4_5_6 1_2_3_4_5_6_ In contrast the use of flicker columns does not help, if the 32 character text display was done using this method I wouldn't play the game that used it. Flicker columns (no player shifting) for even frames: 1_2_3_4_5_6_ 1_2_3_4_5_6_ 1_2_3_4_5_6_ 1_2_3_4_5_6_ ... 1_2_3_4_5_6_ 1_2_3_4_5_6_ for odd frames: _1_2_3_4_5_6 _1_2_3_4_5_6 _1_2_3_4_5_6 _1_2_3_4_5_6 ... _1_2_3_4_5_6 _1_2_3_4_5_6

A minor comment on the use of masking. You don't have to use masking, a typical sprite drawing routine like DoDraw will work just as well: DoDraw0: lda #HUMAN_HEIGHT-1 ; 2 2 - height of the humanoid graphics, subtract 1 due to starting with 0 dcp HumanDraw ; 5 7 - Decrement HumanDraw and compare with height bcs DoDrawGrp0 ; 2 9 - (3 10) if Carry is Set, then humanoid is on current scanline lda #0 ; 2 11 - otherwise use 0 to turn off player0 .byte $2C ; 4 15 - $2C = BIT with absolute addressing, trick that ; causes the lda (HumanPtr),y to be skipped DoDrawGrp0: ; 10 - from bcs DoDrawGrp0 lda (HumanPtr),y ; 5 15 - load the shape for player0 sta GRP0 ; 3 18 - update player0 to draw Human lda (HumanColorPtr),y ; 5 23 - load color for player0 sta COLUP0 ; 3 26 - update color for player 0 The reason I used masking was because it saved 5 cycles in the time critical kernel (at the expense of using more RAM for the MaskPtr, as well as ROM to hold the mask itself): Mask0: lda (FrostyImagePtr+.SEC*2),y ; 5 5 and (FrostyMaskPtr+.SEC*2),y ; 5 10 sta GRP0 ; 3 13 lda (FrostyColorPtr+.SEC*2),y ; 5 18 sta COLUP0 ; 3 21 I cover that in Stay Frosty, Part 3, where I also mention:

Awesome, nice to see DPC+ being used without bB Minor issue - you're only outputting 254 scanlines, should bump that up to 262 for best compatibility. To see this info in Stella hit the Developer Key COMMAND-L on a Mac, or ALT-L on Linux & Windows.

Doh! Don't know how I missed that.

other - put the missing signals out through the cartridge port. That would allow for adding RAM without having to repurpose an address line as the read/write line, and make implementing things like DPC+, CDF, and BUS much easier as you could look for the correct signals instead of trying to recreate them by monitoring changes in the address lines.

Your welcome! Do note that Stay Frosty was developed under a tight schedule, so is not well documented and thus is not the best starting point for learning - I only pointed it out to vidak as he was asking how to implement bands/sections/zones for reusing players. As such, you'll be better off looking at my tutorial Collect, which covers writing a 2K game from scratch. Because it's a tutorial, I put way more comments in the source than I normally do, so be sure to download and read the source for each step. If you have an questions just post them as a comments for step you're on.

That works, though the sound's broken again on iOS. Sound still works in Safari on the Mac.

The 2 analog sticks, fire buttons, and shoulder buttons all match the Standard Gamepad image, though on the analog sticks up is positive and down is negative. The D-Pad shows up as axis 4 (left=negative, right=positive) and axis 5(down=negative, up=postive) instead of buttons 12-15. The Nimbus' sole Menu button isn't detected.

Correct, all 32 datastreams use x.y increments. Having all datastreams work the same way makes for smaller code, as a single function in the driver handles all 32 of them. Yep, that's the only way to get digital audio(samples or 3 voice music) out of the 2600. Sometime next year. I'm mostly taking a break from 2600 development after spending a lot of time this year working on CDF and finishing Draconian. I'm working on converting the music driver from Stay Frosty 2 though, so John can use it in Mappy (and even that's going slower than I expected due to RL). In the mean time these 2 Draconian blog entries give a rundown of the features in CDF: reboot is underway reboot delayed - new FastJump feature

I have a Nimbus SteelSeries paired with my iPad Pro. It's recognized, but none of the buttons nor direction controls do anything. I confirmed it works with DuckTales.

Worked OK on my Mac using DASM 2.20.11. ------- FILE test.asm LEVEL 1 PASS 1 1 0000 processor 6502 2 f000 org $F000 3 f000 Start 4 f000 repeat 2 5 f000 85 02 STA $02 4 f000 repend 5 f002 85 02 STA $02 6 f004 repend 7 f004 a9 00 LDA #0 8 f006 ; STA $02 9 f006 4c 00 f0 jmp Start 10 f009 11 f009 12 fffc org $FFFC 13 fffc 00 f0 .word.w Start 14 fffe 00 f0 .word.w Start

You're welcome. Exactly, because the pointers are 2 bytes.

Bad part for me is I have to run them at 1080 for work as Windows doesn't handle higher DPIs very well. Main problem is I have to remote from my Win10 machine (which does HiDPI fairly well, though not as well as the Mac) to a Win7 machine. If the Win10 set for 4K with 200%, the Win7 using 4K at 100% resulting in extremely tiny text.

FYI - Celery's one of the sprites featured in the Atari 2600 Homebrew Games' group photo.

Yeah, 4K is quite nice - I'm running 2 of them

Yeah, looks OK fullscreen at 4K

Next up - Preparing the Graphics Pointers for Sections 1 to 4 The data being used is this: Heights ds 1*SECTIONS ; heights of the levels ... FrostyImagePtr ds 2*SECTIONS Which you can also think of as being: Height0 ds 1 Height1 ds 1 Height2 ds 1 Height3 ds 1 Height4 ds 1 ... FrostyImagePtr0 ds 2 FrostyImagePtr1 ds 2 FrostyImagePtr2 ds 2 FrostyImagePtr3 ds 2 FrostyImagePtr4 ds 2 the bit of code starting at line 1975 sets FrostyImagePtr0 Then the bit of code starting at line 2006 sets the rest like this: FrostyImagePtr1 = FrostyImagePtr0 + Height0 FrostyImagePtr2 = FrostyImagePtr1 + Height1 FrostyImagePtr3 = FrostyImagePtr2 + Height2 FrostyImagePtr4 = FrostyImagePtr3 + Height3 As far as how it was implemented I'm sure there's better way to do it than all those INY and DEY instructions, but due to the time constraint we were under once I got a routine that worked I went on to the next. The heights are all 1 byte values. The way to add a 1 byte value to a 2 byte value is this: add ds 1 value ds 2 ; value = value + add clc lda value adc add ; if (low byte of value) + add > $ff then the carry flag gets set sta value lda value+1 adc #0 ; ADC = ADD with Carry, if the carry flag is set this will add 1 to the high byte sta value+1 so that ADC #0 instruction is taking care of the higher byte. ADC handles a carry, which is why you should always clear the carry before the initial ADC for the low byte. For the typical kernel loop you'll set Y to something like 180 at the top, then count down to 0 after which you'll have a separate kernel to draw the score. For Stay Frosty this count down is done 5 times, once for each section. This is kind of hard to see because I used a macro, found at line 123: MAC SECTION .SEC SET {1} ldy Heights+.SEC ; load Y with height of current section lda #ICE_TOP_COLOR sta COLUPF lda (FrostyImagePtr+.SEC*2),y and (FrostyMaskPtr+.SEC*2),y ... ENDM Within the game logic you'll find this at line 577: SECTION 4 SECTION 3 SECTION 2 SECTION 1 SECTION 0 Those are replaced by the macro and anything with .SEC is replaced with the value specified above: ldy Heights+4 ; load Y with height of current section lda #ICE_TOP_COLOR sta COLUPF lda (FrostyImagePtr+4*2),y and (FrostyMaskPtr+4*2),y ... ldy Heights+3 ; load Y with height of current section lda #ICE_TOP_COLOR sta COLUPF lda (FrostyImagePtr+3*2),y and (FrostyMaskPtr+3*2),y ... ldy Heights+2 ; load Y with height of current section lda #ICE_TOP_COLOR sta COLUPF lda (FrostyImagePtr+2*2),y and (FrostyMaskPtr+2*2),y ... ldy Heights+1 ; load Y with height of current section lda #ICE_TOP_COLOR sta COLUPF lda (FrostyImagePtr+1*2),y and (FrostyMaskPtr+1*2),y ... ldy Heights+0 ; load Y with height of current section lda #ICE_TOP_COLOR sta COLUPF lda (FrostyImagePtr+0*2),y and (FrostyMaskPtr+0*2),y ... Having a separate kernel loop for each section is we have all those Frosty Pointers.

Been a long time since I wrote this. Was under major time constraint, as I was invited to join the project on October 29th, so comments aren't the best. Let's see what I can figure out... I'll do this as 2 separate replies. First up - How the Variable "Heights" Works in Stay Frosty here's the level 1 data that'll be copied into RAM Level1 .byte 35,35,34,34,10 ; section heights add up to 148 .byte 80, 0 ; section 0 fireballs .byte 80, 100 ; section 1 fireballs .byte 0, 0 ; section 2 fireballs .byte 0, 90 ; section 3 fireballs .byte 0, 0 ; section 4 fireballs .byte %00000000, %00011111; fireball size ; no section 0 platform - bottom of screen is fully on .byte 0,zzX_______,zzXXXXXXXX,zz_______X ; Section 1 platform .byte 0,0,zz______XX,zzXXXXXXXX ; Section 2 platform .byte 0,zzXXX_____,zzXXXXXXX_,0 ; Section 3 platform .byte 0,0,0,0 ; Section 4 platform .byte 0, 0,0,zzXX_XX_XX ; Section 0 ice .byte 0,0,zzXX_XX_XX,0 ; Section 1 ice .byte 0,0,zz_______X,zz_XX_XX_X ; Section 2 ice .byte 0,zzXX______,zz_XX_XX__,0 ; Section 3 ice .byte 0,0,0,0 ; Section 4 ice .byte 0,0 ; level control I count 55 values in there, not 53, so a miscount could be contributing to some of your confusion. As a side note - the zz constants are in graphics.h, I used to use those for graphic data so I could more easily see the graphics within the code. I now let jEdit colorize binary for me, which is even more legible than using the zz constants: The bit of code starting at line 2196 is what copies level data from ROM into the following RAM: SECTIONS = 5 ; sections 0-4, 0 is bottom area just above score DATA_BYTES_PER_SECTION = 11 Heights ds 1*SECTIONS ; heights of the levels FireBallX ds 2*SECTIONS ; fireball positions, 2 per section ; x=0 means no fireball FireBallSize ds 2 ; 1=large, 0=small Platforms ds 4*SECTIONS-4 ; platforms IceData ds 4*SECTIONS ; ice blocks LevelControl ds 2 ; level specific data-moving platform state, etc) The first part of the data is Heights, which is why the loop uses that label, but it's copying all of this data not just the Heights. There's (1*5) + (2*5) + 2 + (4*5 - 4) + 4*5 + 2 bytes there, 55 bytes. SECTIONS*DATA_BYTES_PER_SECTION-4-1+2+2 = 54. Looks off, but it's not because 55 bytes will be copied when Y decrements from 54 as the use of BPL means that Y will have a value of 0 the last time through the loop. If BNE had been used then only 54 bytes would have been copied. DATA_BYTES_PER_SECTION refers to the 4 with SECTIONS: Heights ds 1*SECTIONS ; heights of the levels FireBallX ds 2*SECTIONS ; fireball positions, 2 per section Platforms ds 4*SECTIONS-4 ; platforms IceData ds 4*SECTIONS ; ice blocks 1 + 2 + 4 + 4 = 11 so SECTIONS*DATA_BYTES_PER_SECTION-4 refers to that amount of data for Heights, FireBallX, Platforms, IceData. The bottom-most platform is always fully on, so no data is needed hence the -4. The +2+2 refer to what's left: FireBallSize ds 2 ; 1=large, 0=small LevelControl ds 2 ; level specific data-moving platform state, etc) while the -1 is due to using 54 to 0 for the copy loop instead of 55 to 1.

I don't like the blurry look, so I turn smooth scaling off. After doing that things like the stars will change thicknesses as you fly up/down, which looks odd.

A great way to say thanks is to add your reviews. Same goes for other games

Slick. Think CDF's fastjump would free up enough time for line-by-line shifting?

What type of TV are you using? My 7800 displays in B&W on my HDTV, works just fine on an older set.