The Brew that is True

Are "spurious" writes to the TIA write addresses in the range $2d..3f safe on a physical 2600? I'm thinking of using c63f dec $3f as my default 2-byte 3mc/15cc delay macro.

It does not use DCP, this is plain vanilla 4K.

In my experimental WIP I'm using a single-scanline resolution kernel for the Player sprites (spliced with a 4LK for the PF and BL). Here's an excerpt: --------------------------------------------------------------- DK WORK 1/17 - 1LK TIA Updates - 1st of 4. Color Clocks: 27 x192/4 = 27 x48 = 1,296 ROM Bytes: 6 --------------------------------------------------------------- Update TIA Player Graphics registers. N.B. Assumes preloaded A register. 851c sta GRP1_ff (3)x3 @ dk.000*.000-008 *** a5d2 lda ORAM_GRP0 (3)x3 @ dk.000*.009-017 851b sta GRP0_ff (3)x3 @ dk.000*.018-026 *** --------------------------------------------------------------- DK WORK 2/17 - 4LK TIA Updates. Color Clocks: 63 x192/4 = 63 x48 = 3,024 ROM Bytes: 14 --------------------------------------------------------------- Update TIA PF Graphics and Ball Enable registers. TODO This is temporary test code. a5d3 lda ORAM_PF0_BL (3)x3 @ dk.000*.027-035 850d sta PF0_f0 (3)x3 @ dk.000*.036-044 *** 851f sta ENABL_02 (3)x3 @ dk.000*.045-053 *** a5d4 lda ORAM_PF1 (3)x3 @ dk.000*.054-062 850e sta PF1_ff (3)x3 @ dk.000*.063-071 *** a5d5 lda ORAM_PF2 (3)x3 @ dk.000*.072-080 850f sta PF2_ff (3)x3 @ dk.000*.081-089 *** --------------------------------------------------------------- DK WORK 3/17 - Preloads for 2nd of 4 1LK TIA Updates. Color Clocks: 138 x192/4 = 138 x48 = 6,624 ROM Bytes: 30 --------------------------------------------------------------- Preload Player Graphics. 98 tya (2)x3 @ dk.000*.090-095 N.B. clc rather than sec. 18 clc (2)x3 @ dk.000*.096-101 e587 sbc SRAM_P0_Y (3)x3 @ dk.000*.102-110 c5a7 cmp CRAM_P0_HEIGHT (3)x3 @ dk.000*.111-119 aa tax (2)x3 @ dk.000*.120-125 a900 lda #$00 (2)x3 @ dk.000*.126-131 e900 sbc #$00 (2)x3 @ dk.000*.132-137 35a9 and CRAM_GRP0_ROWS,X (4)x3 @ dk.000*.138-149 85d2 sta ORAM_GRP0 (3)x3 @ dk.000*.150-158 98 tya (2)x3 @ dk.000*.159-164 N.B. clc rather than sec. 18 clc (2)x3 @ dk.000*.165-170 e589 sbc SRAM_P1_Y (3)x3 @ dk.000*.171-179 c5b3 cmp CRAM_P1_HEIGHT (3)x3 @ dk.000*.180-188 aa tax (2)x3 @ dk.000*.189-194 a900 lda #$00 (2)x3 @ dk.000*.195-200 e900 sbc #$00 (2)x3 @ dk.000*.201-206 35b5 and CRAM_GRP1_ROWS,X (4)x3 @ dk.000*.207-218 a6d2 ldx ORAM_GRP0 (3)x3 @ dk.000*.219-227 The WIP source is attached to this post: https://forums.atariage.com/topic/336371-hello-2600-homebrewers/?do=findComment&comment=5103369

Since I probably won't get a chance to work on baby step #9 for at least another week, maybe two weeks. I thought I'd at least post the source as it stands at the moment (in a complete state of flux) for your entertainment and amusement. Match_Race_2600_baby_step_9.txt

I've been putting it off for a while now, but I've reached the point where I need to go back to my initial attempt at a display kernel to restructure and optimize it. I'll need to squeeze in at least a race/lap progress bar per player (presumably using the Mx). I've been working on these experiments a little too much in a vacuum, learning from the Stella mailing list and AA archives, but most discussion is centered around styles of games other than racing. I'll be on the lookout for commented disassemblies of any 2600 racing games to gain insights on how they handled various aspects. I'm not sure if I'm using the terminology correctly, I guess you'd call my current display kernel a Four-Line Kernel (4LK) that's been intertwined with a Single-Line Kernel (1LK). Right now the 4LK handles the refresh of the playfield and the wind vane, while the 1LK handles the boats. Here for example is the first of four scanlines worth of display kernel code: --------------------------------------------------------------- DK WORK 1/18 - 1LK TIA Updates for 1st scanline of 4. Color Clocks: 27 x192/4 = 27 x48 = 1,296 ROM Bytes: 6 --------------------------------------------------------------- N.B. Assumes preloaded A register. 851c sta GRP1_ff (3)x3 @ dk.000*.000-008 *** a5d2 lda ORAM_GRP0 (3)x3 @ dk.000*.009-017 851b sta GRP0_ff (3)x3 @ dk.000*.018-026 *** --------------------------------------------------------------- DK WORK 2/18 - 4LK TIA Updates. Color Clocks: 72 x192/4 = 72 x48 = 3,456 ROM Bytes: 16 --------------------------------------------------------------- a5d7 lda ORAM_ENABL (3)x3 @ dk.000*.027-035 851f sta ENABL_02 (3)x3 @ dk.000*.036-044 *** a5d3 lda ORAM_PF0 (3)x3 @ dk.000*.045-053 850d sta PF0_f0 (3)x3 @ dk.000*.054-062 *** a5d4 lda ORAM_PF1 (3)x3 @ dk.000*.063-071 850e sta PF1_ff (3)x3 @ dk.000*.072-080 *** a5d5 lda ORAM_PF2 (3)x3 @ dk.000*.081-089 850f sta PF2_ff (3)x3 @ dk.000*.090-098 *** --------------------------------------------------------------- DK WORK 3/18 - 1LK Preloads for 2nd scanline of 4. Color Clocks: 129 x192/4 = 129 x48 = 6,192 ROM Bytes: 28 --------------------------------------------------------------- 98 tya (2)x3 @ dk.000*.099-104 N.B. clc rather than sec. 18 clc (2)x3 @ dk.000*.105-110 e587 sbc SRAM_P0_Y (3)x3 @ dk.000*.111-119 c5a7 cmp CRAM_P0_HEIGHT (3)x3 @ dk.000*.120-128 aa tax (2)x3 @ dk.000*.129-134 a900 lda #$00 (2)x3 @ dk.000*.135-140 e900 sbc #$00 (2)x3 @ dk.000*.141-146 35a9 and CRAM_GRP0_ROWS,X (4)x3 @ dk.000*.147-158 85d2 sta ORAM_GRP0 (3)x3 @ dk.000*.159-167 98 tya (2)x3 @ dk.000*.168-173 N.B. clc rather than sec. 18 clc (2)x3 @ dk.000*.174-179 e589 sbc SRAM_P1_Y (3)x3 @ dk.000*.180-188 c5b3 cmp CRAM_P1_HEIGHT (3)x3 @ dk.000*.189-197 aa tax (2)x3 @ dk.000*.198-203 a900 lda #$00 (2)x3 @ dk.000*.204-209 e900 sbc #$00 (2)x3 @ dk.000*.210-215 35b5 and CRAM_GRP1_ROWS,X (4)x3 @ dk.000*.216-227

No More Secrets v0.96 (NMOS 6510 Unintended Opcodes) Heady stuff. Hopefully my display kernel can benefit.

My latest experiments have all resulted in flicker fests. I'm fine with flicker when used for in-game effects (e.g. zapping things, explosions, lightning, tractor beams), but otherwise it is a bane. Oh well, back to the drawing board.

Thanks, I'll look for disassemblies of "Combat" and "Air-Sea Battle" to study how they keep the frame rate stable during a reset.

Thank you for the explanation. Wouldn't a reset switch press typically be handled by a jump back to the reset code, cutting short the current frame, and possibly cause rolling all over again? Are there games that just pause a short but "safe" amount of time after a soft or hard reset before automatically letting play begin? Sorry if my questions seem naïve, the last time I played a video game was Pong at the Exploratorium sometime early 70s.

Bol d'Or used to be held at the Le Mans track. https://en.wikipedia.org/wiki/Bol_d'Or

Kudos SpiceWare, and thank you. I will study those blog entries. My hope is to code a game that resets/powers-up straight into live play so to speak. As far as I can tell, once past the reset code and the first Vertical Synch Interval, my frames are consistently 262 scanlines at 60fps. What remains, it seems, is to come up with a dependable way of getting through reset without causing screen roll. If it turns out screen roll at reset is unavoidable, I at least want to wait out its passing before starting the game.

Thank you! Much appreciated. So if Stella is emulating something that could physically happen on a CRT (kudos to the Stella developers), I guess I need to think about coding around the physical phenomenon.

When I startup a bin on the Stella Emulator, the screen slowly drops down, not unlike when a theater stage curtain comes down, or when the projection of a film begins while the movie screen is still being lowered. I do not yet own a real 2600 so I am unable to test if this is emulating a physical 2600 phenomenon. And if so how does one code to prevent it. Any insights appreciated. I attached an example. Match_Race_2600_baby_step_1.bin

I haven't worked on this for over a week. I've been spending my morning coffees reading through the treasure trove that is Stella mailing list archive. It seems the 2600 coding + emulation + disassembly + discussion scene was very vibrant 20+ years ago. Revisiting the Stella archive is producing many more aha moments of insight compared to my first skim-through. I think I'll focus next on how to add a lap/score display without compromising the current 192x160 playing surface. Plenty of head scratching and hand wringing awaits me I'm sure.

I really appreciate the feedback and encouragement, you've given me much to mull over.