e1will

Thank you for posting these! I was seriously addicted to that game when it came out. I was so bummed that I never got a T-shirt! --Will

Nope, this is a sporadic thing. Only seems to happen about every 10th or 20th time. Open up Stella and Notepad, and Alt-Tab between them enough times and you'll see it too. From Notepad, Alt-tab to Stella, hit Enter to load whatever game is selected, exit the game, Alt-tab back to Notepad, and repeat. (And I long ago disabled Sticky Keys and some other "helpful" Windows features.) --Will

Awesome! Thanks! --Will

Also, could please consider adding a config option to disable fullscreen mode? Or at least the option to remap the Alt-Enter combination? Stella seems to occasionally "remember" the Alt key being pressed when you Alt-Tab to it from another application in Windows, and when you press Enter to start the highlighted game, it treats it as Alt-Enter instead, and instead of launching the game, does this: Obviously there's a problem with my OS in that it doesn't support full-screen mode, but it shouldn't have to, IMO. --Will

Would this be possible to enable this via a configuration setting? I remember having a joystick back in the early 80s that would stick to the left or right for a second or two after releasing it, and quickly moving between left and right would cause the VCS to do some pretty neat tricks. For example, in Combat, left + right would let you zoom the tank forward extremely quickly (it even gave you a "in a higher gear" sound.) Might be fun to see what other games have hidden behind "impossible" joystick combinations. Obviously not an essential emulator feature, but kind of a fun one and (probably) easy to add. --Will

I like it! Let me be the first to volunteer giving him a cameo in my upcoming homebrew... --Will

How about Rex the Rectangle? It's an interesting idea. I don't know how quick developers would be to center a game around the character, but he/she'd almost certainly get some cameo appearances, kind of like the way the Galaxian shows up in Pac-Man, Dig Dug, etc. --Will

I've got 1887 so far. If you can get the mushroom early, pick up the next cherry, strawberry and pineapple, avoid the mango(es) and go through most of the game with mangoes passing by, grab the "right" mango that offers a helicopter, grab the helicopter, get another mushroom, pick up the cherry and strawberry (but not the pineapple), you can get to the black abyss with pineapples whizzing by. Float down to about 1/5 the way up from the bottom and the points will really rack up. The black abyss (well, blue abyss if you have the mushroom) seems to give you points based on where you are vertically on the screen. At certain scanlines, it will actually deduct points! Yes, I'm clearly addicted. --Will

As best I can tell, the only two objects "missing" from the game which appear on the object table screen are the golden (flashing) pineapple and golden (flashing) mango. Or has anybody run across these two in the game as well? --Will

It looks doable to me with a couple minor tweaks, if I understand correctly how Harmony is going to work... Looks like the most color changes occur near the middle of the car, where you have: 1. Medium gray sidewalk 2. Light gray pole for street light 3. Dark gray road 4. Yellow line in road 5. Red for car 6. Orange for buildings You could set it up so that P0 is the car, M0 is the light pole and P1 is the yellow line. The sidewalks and buildings are PF objects, and that still leaves you with M1 and the ball unused. You'd start the scanline with P0/M0 set light gray for the pole, P1/M1 set yellow, PF set orange and BK set dark gray. During the scanline you'd need to: 1. Switch COLUPF from orange to medium gray once you're done drawing the buildings 2. Switch COLUP0 from light gray to red for the car once you're done drawing the light pole 3. Switch COLUPF back to orange once you're done drawing the sidewalks on the right Seems like there might be enough time to do that even with the changes to PF0,1,2 you'd need to do. You'd probably have to tweak a couple of pixels on the car design to get it as one double-wide sprite instead of two, and you may also wind up losing the left two PF columns if you're going to HMOVE each line. You'd probably need at least one HMOVE between the traffic lights (I assume you'd want P0 for the traffic lights at 2 copies) and the car, although you might be able to do that with RESP0 alone. As the traffic lights zoom towards you, you'd probably need to cut them off (make it appear that the car has passed them) before they hit the same scanline as the car. Having both the lights and the car on the same scanline is probably too much for the TIA to handle without flickering them. --Will

I've read that the clock speeds of the PAL 6507 and NTSC 6507 are about 1% different... is that the only difference? Are the CPU functions identical other than that? Specifically I'm wondering if any of the illegal opcodes that encounter race conditions when executing produce different results on the different console types. (Probably not since the CPU would just be racing against itself...) And yeah, this is sort of a back-door way of re-opening the question whether it would be possible to write code to test whether a PAL or NTSC console is running. From what I've read in the archives there doesn't seem to be much hope, but you never know... (And at any rate, if there was a way to programmatically check this, you'd probably still want an option to override the default TV type in case the code guessed wrong. I like the way "Man Goes Down" handles it: the Select switch changes the type, and the game then "remembers" the preferred setting via the AtariVox if one is present.) --Will

You're right, of course... To be honest I was just looking for an excuse to play with code that would detect the different environments, and the pause vs "emulator palette" thing seemed like a decent use of that (possibly nonexistent) feature/bug. Speaking of 7800 console detection, I was reading the thread you started about code to handle the 7800 pause vs 2600 TV type switch, and was wondering you could re-post the code for that (if you're willing to share it). (The link you'd posted no longer works.) --Will EDIT: Never mind, I see you just posted it!

I seem to recall a similar feature with an Apple ][ emulator I was using a few years back... I know there are plenty of unused read-only locations, but that doesn't mean that existing cartridges aren't depending on a certain behavior when reading them (either by design or by accident) that using them for "what environment am I running on" info might break. It's an interesting question what sort of locations COULD theoretically be used for that purpose without breaking anything... any address returning an indeterminate value might already be used by existing programs as a quasi-random number, and any address that always returned the same value might be relied on as well (again, either by design or accidentally). (Then I guess there's the third category of hardware-dependent values... I was reading elsewhere that LDA $07 would return "$x7" on a 2600 but "$x0" on a 7800.) --Will

Nah, I'm not interested in copy protection... I was mainly thinking of it in terms of the "pause" vs "color/BW" switch functionality. Since emulators generally include a pause function already, I thought I could use that switch as a "pause function" on a real 2600 and use it to display an alternate color palette in the emulator. --Will

Is there a way for the code to detect whether it's being run under an emulator vs. on an actual 2600? I realize this may be either a desirable development feature or an undesirable emulator bug to be squashed depending on how you look at it, but I'm just curious if there is currently a way to tell. --Will

OK. Yeah, that could be helpful inside of a kernel, although I suppose you'd need to either "refresh" it every 13 scanlines or do some addition at the end of the kernel to compensate. (As a side note, when you mentioned using T1024T, I thought, hmm, maybe I could use that instead of a RAM slot to cache the stack pointer in the game I'm working on now, since I use the stack pointer for other things inside my graphics kernel. But then I realized that since the graphics kernel is only called one way, I don't really need to store the stack pointer at all.. it's always going to be F9 once it gets to the kernel. So that's one byte of RAM saved.) --Will

I'm intrigued... where are these bits? --Will

Well done! I like the separate dot / maze colors. --Will

There are two issues I've noticed with the "disable playfield" function in Stella (Alt-N). (They're not new to 2.8.4, the behavior appears to be the same under 2.8 and 2.7.7). First, Alt-N doesn't seem to disable all of the playfield. In the attached bin, the light blue area of the initial screen is the playfield, but only the top 2/3 is hidden when I toggle Alt-N. The lower playfield still displays. If it helps, the top and bottom playfield sections are drawn using different kernels in different banks (bank 5 for the top part, banks 2 (playfield) and 4 (P0/P1) for the bottom part.) I don't know why this would affect it but I thought I would mention it. Second, Alt-N (as well as the other sprite enable/disable toggles) does not work when the game is paused. Would it be possible to change this? It would be really helpful to be able to examine individual sprites in "freeze frame" when they're not moving around the screen. Thanks, --Will DUCK.BIN

Yeah, I was curious if there was any way to do a conditional zero-page LDA in 5 cycles instead of 6. As I just learned from supercat, there indeed is, if the zero-page location you need to read can be relocated to an address that corresponds to the opcode for a 2-cycle NOP. --Will

Ah, clever! I like that technique quite a bit. I'll have to remember that. --Will

Here's the full kernel. I do have a workaround in the form of duplicating code to save the cycle required for the BNE-JMP, and the code does run fine. (I've attached a .bin of the project I'm working on... it's called Duck Attack and is in a VERY early state, but the duck sprite should give you an idea of why I have separate indexed pointers for HMPx/NUSIZx, GRPx and COLUPx. I'm sacrificing some vertical resolution to try to get big, detailed multicolor sprites.) first_row_past_obj_2 ; +3 = 59 LDA #LAST_ROW ; +2 = 61 STA OBJ0_TOP ; +3 = 64 first_row_clear LDX #$00 ; +2 = 66 LDY #$00 ; +2 = 68 LDA (OBJ0_COLOR_PTR),Y ; +5 = 73 BNE first_row_wall_color ;+2 = 75 STA HMOVE ; +3 = 78 (=2) LDA OBJ0_DEF_COLOR ; +3 = 5 LDY #V_WALL_SIZE ; +2 = 7 JMP second_row ; +3 = 10 ;------------end of branch-------------------- first_row_wall_color ; +3 = 76 (=0) STA HMOVE ; +3 = 3 NOP ; +2 = 5 LDY #V_WALL_SIZE ; +2 = 7 JMP second_row ; +3 = 10 ;------------end of branch-------------------- first_row_no_obj_2 ; +3 = 50 NOP3 ; +3 = 53 NOP ; +2 = 55 NOP ; +2 = 57 NOP ; +2 = 59 NOP ; +2 = 61 JMP first_row_clear ; +3 = 64 ;------------end of branch-------------------- second_row_past_obj_2 ; +3 = 60 LDA #LAST_ROW ; +2 = 62 STA OBJ1_TOP ; +3 = 65 second_row_clear NOP ; +2 = 67 NOP ; +2 = 69 NOP ; +2 = 71 NOP3 ; +3 = 74 LDA MISSILE_COLOR ; +3 = 77 (=1) STA HMOVE ; +3 = 4 STA COLUP1 ; +3 = 7 LDA #$00 ; +2 = 9 JMP third_row_set_gr ; +3 = 12 ;------------end of branch-------------------- second_row_no_obj_2 ; +3 = 51 NOP ; +2 = 53 NOP ; +2 = 55 NOP ; +2 = 57 NOP ; +2 = 59 NOP3 ; +3 = 62 JMP second_row_clear ; +3 = 65 ;------------end of branch-------------------- ;----------------- ORG $90CE ; push this as high as possible to RORG $F0CE ; ensure it follows without BRK to $9100 ;----------------- ;****this code must be in called banks******** MAC PF_CODE_F0CE SwitchToEnd ; +3 = 75 NOP ; +2 = 77 (=1) STA HMOVE ; +3 = 4 LDA SWITCH_TO_BANK_1 ; +4 = 8 JMP BlankOnAndExit ; +3 = 11 ;============end of branch==================== draw_bk_change ; +3 = 67 LDA ROW_COUNT ; +3 = 70 CMP #LAST_ROW ; +2 = 72 BCS SwitchToEnd ; +2 = 74 LDX BK_LOOKUP ; +3 = 77 (=1) STA HMOVE ; +3 = 4 LDA BkTable,X ; +4 = 8 STA COLUBK ; +3 = 11 SEC ; +2 = 13 JMP LoadBallAndMissile ; +3 = 16 ;------------end of branch-------------------- no_pf_change ; +4 = 56 (from next page) LDY BK_INDEX ; +3 = 59 CMP (BK_PTR),Y ; +5 = 64 BCC draw_bk_change ; +2 = 66 INY ; +2 = 68 LDA ADJUSTED_LEVEL ; +3 = 71 (no time for a CLC here) ADC (BK_PTR),Y ; +5 = 76 (= 0) STA HMOVE ; +3 = 3 STA BK_LOOKUP ; +3 = 6 INY ; +2 = 8 STY BK_INDEX ; +3 = 11 SEC ; +2 = 13 JMP LoadBallAndMissile ; +3 = 16 ;------------end of branch-------------------- ENDM PF_CODE_F0CE ;----------------- ORG $9100 RORG $F100 ;----------------- MAC PF_CODE_F100 PF_bank_switch ; = 29 LDY SWITCH_TO_BANK_0,X ; +4 = 33 STA HMCLR ; +3 = 36 INC ROW_COUNT ; +5 = 41 LDA ROW_COUNT ; +3 = 44 LDY PF_INDEX ; +3 = 47 CMP (PF_PTR),Y ; +5 = 52 BCC no_pf_change ; +2 = 54 INY ; +2 = 56 LAX_Y PF_PTR ; +5 = 61 (illegal opcode) INY ; +2 = 63 LDA (PF_PTR),Y ; +5 = 68 INY ; +2 = 70 STX PF1 ; +3 = 73 STA PF0 ; +3 = 76 (=0) STA HMOVE ; +3 = 3 LDA (PF_PTR),Y ; +5 = 8 STA PF2 ; +3 = 11 INY ; +2 = 13 STY PF_INDEX ; +3 = 16 LoadBallAndMissile ; 16 LDY ROW_COUNT ; +3 = 19 LDA (ENABL_PTR),Y ; +5 = 24 STA ENABL ; +3 = 27 (two cycles too late... LDA (MISSILE_GR_PTR),Y ; +5 = 32 nothing we can do, though) STA CACHE_MISSILE ; +3 = 35 LDA SWITCH_TO_BANK_1 ; +4 = 39 ;**********end shared-bank code*************** ENDM PF_CODE_F100 first_row ; 39 TYA ; +2 = 41 SBC OBJ0_TOP ; +3 = 44 BMI first_row_no_obj ; +2 = 46 TAY ; +2 = 48 (row count) LDA (OBJ0_MOVE_PTR),Y ; +5 = 53 BEQ first_row_past_obj ; +2 = 55 STA HMP0 ; +3 = 58 AND #$07 ; +2 = 60 ORA #V_WALL_SIZE ; +2 = 62 STA CACHE_NUSIZ ; +3 = 65 LAX_Y OBJ0_GR_PTR ; +5 = 70 (illegal opcode) LDA (OBJ0_COLOR_PTR),Y ; +5 = 75 STA HMOVE ; +3 = 78 (=2) BNE first_row_no_flash ; +2 = 4 LDA OBJ0_DEF_COLOR ; +3 = 7 LDY CACHE_NUSIZ ; +3 = 10 second_row MAC SECOND_ROW_LOGIC STA COLUP0 ; +3 = 13 STX GRP0 ; +3 = 16 STY NUSIZ0 ; +3 = 19 LAX CACHE_MISSILE ; +3 = 22 (illegal opcode) ASL ; +2 = 24 ASL ; +2 = 26 AND #$30 ; +2 = 28 STA CACHE_NUSIZ ; +3 = 31 STA HMCLR ; +3 = 34 LDA ROW_COUNT ; +3 = 37 STX HMM1 ; +3 = 40 SEC ; +2 = 42 SBC OBJ1_TOP ; +3 = 45 BMI second_row_no_obj ; +2 = 47 TAY ; +2 = 49 LDA (OBJ1_MOVE_PTR),Y ; +5 = 54 BEQ second_row_past_obj ; +2 = 56 STA HMP1 ; +3 = 59 AND #$07 ; +2 = 61 ORA CACHE_NUSIZ ; +3 = 64 STA CACHE_NUSIZ ; +3 = 67 LDA (OBJ1_COLOR_PTR),Y ; +5 = 72 BNE second_row_no_flash ; +2 = 74 LDA OBJ1_DEF_COLOR ; +3 = 77 (=1) STA HMOVE ; +3 = 4 STA COLUP1 ; +3 = 7 LDA (OBJ1_GR_PTR),Y ; +5 = 12 ENDM SECOND_ROW_LOGIC third_row_set_gr ; 12 STA GRP1 ; +3 = 15 LDA CACHE_NUSIZ ; +3 = 18 STA NUSIZ1 ; +3 = 21 STX ENAM1 ; +3 = 24 TSX ; +2 = 26 JMP PF_bank_switch ; +3 = 29 ;------------end of kernel loop--------------- first_row_no_obj JMP first_row_no_obj_2 first_row_past_obj JMP first_row_past_obj_2 second_row_no_obj JMP second_row_no_obj_2 second_row_past_obj JMP second_row_past_obj_2 ;------------end of jumps--------------------- second_row_no_flash ; 75 NOP ; +2 = 77 (=1) STA HMOVE ; +3 = 4 STA COLUP1 ; +3 = 7 LDA (OBJ1_GR_PTR),Y ; +5 = 12 STA GRP1 ; +3 = 15 LDA CACHE_NUSIZ ; +3 = 18 STA NUSIZ1 ; +3 = 21 STX ENAM1 ; +3 = 24 TSX ; +2 = 26 JMP PF_bank_switch ; +3 = 29 ;------------end of branch-------------------- first_row_no_flash ; +3 = 5 NOP ; +2 = 7 LDY CACHE_NUSIZ ; +3 = 10 SECOND_ROW_LOGIC ; 29 STA GRP1 ; +3 = 15 LDA CACHE_NUSIZ ; +3 = 18 STA NUSIZ1 ; +3 = 21 STX ENAM1 ; +3 = 24 TSX ; +2 = 26 JMP PF_bank_switch ; +3 = 29 ;------------end of branch-------------------- The starting point for the code is a JMP to first_row, which is somewhere in the middle of the code block. If the kernel has to draw P0, P1, M0, M1 and a new playfield line, there are exactly 0 cycles free as best I can tell. The playfield, missile sprites and ball graphics are stored in a separate bank, so I have to spend 8 cycles jumping to and back from that bank (since the player sprites are in bank 1, where the kernel is.) I use the stack pointer to index which bank is needed, since there will be about 3 full banks of PF & missile data once the game is through. (And just under 1 full bank's worth of player sprites, so I won't be able to put those in the same bank as the PF data.) I may have reached the limits of my cycle-squeezing abilities, although you guys will probably be able to find something I missed. I've already dropped the WSYNCs and am using all the registers (including the stack pointer, which I cache beforehand.) The good news is that I don't need any extra cycles at this point. I can live with the duplicated code, since I was able to arrange it in such a way that none of the branches are out of range. The main problem I have with it now is that STA ENABL is getting called 2 cycles too late, and I can't figure out a way to call it earlier without forcing STA PF0 to be written 2 cycles too early. The ball sprite is "hidden" behind the P0 sprite most of the time so it's not too noticeable visually, but it does create some glitches moving from room to room (he gets "caught" on certain edges.) Thanks, --Will DUCK.BIN

You know, that's a very good suggestion. I hadn't thought of that, I may end up doing that if I wind up with any spare RAM. Thanks! --Will

Unfortunately there aren't any immediate-mode LDAs in there to merge; they're all of the form LDA (PF_PTR),Y STA PF1 INY LDA (PF_PTR),Y STA PF0 etc. That's not to say there aren't other places in the code I might be able to save a cycle, I was just curious if the BNE/JMP logic was a candidate for trimming too. Thanks, --Will

The LeaveAccumulatorAlone branch is actually very far away from the LDA, about 100 bytes below it. Unfortunately there's no way to move it closer. Here's what I have as a workaround, but of course this is not ideal: StartOfLine ; some code here BNE LeaveAccumulatorAlone ; 2 LDA $80 ; 5 ; about 100 bytes of STAs and LDAs JMP StartOfLine LeaveAccumulatorAlone ; 3 NOP ; 5 ; a second copy of the 100 bytes of STAs and LDAs above JMP StartOfLine --Will