e1will

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

Hi all, I've been wracking my brain trying to figure out if I can shave a cycle off of this piece of code in a timing-critical section... it seems like it SHOULD be possible to squeeze an extra cycle out, but I can't figure out how. I know there are some neat tricks with the BIT opcode that can hop over a byte or two, but I haven't found a way to use BIT in a way that cuts the cycles. BNE LeaveAccumulatorAlone LDA.w $0080 DoNextThing ... LeaveAccumulatorAlone JMP DoNextThing Before the BNE I'm at cycle 0; at "DoNextThing" I'm at 6 cycles regardless of whether I've taken the branch. Is there any way to wind up at "DoNextThing" at 5 cycles by changing the addressing mode of the LDA to zero-page and presumably doing something other than JMPing back to it for the taken branch? I'm starting to think it's not possible and 6 is the best I can get, but I thought maybe there might be a way I don't know about. --Will

Ah, that would be better. Thanks! And now that you mention it, there are probably a couple more places in my kernel where a BCC would be more appropriate than a BMI. --Will

Hi all, I need to shave 2 cycles off my game kernel and I'm curious if I could drop the CLC before the ADC in this section of code: LDA ROW_COUNT CMP (BK_PTR),Y BMI SomeplaceElse INY LDA ADJUSTED_LEVEL CLC ADC (BK_PTR),Y Will the carry flag always be set if the code gets to the INY? In other words, are there any cases I should worry about the branch not being taken but the carry flag being cleared nonetheless? If it will always be set, then I can make sure ADJUSTED_LEVEL is one less than it would otherwise be before entering the kernel, and just let the carry get added in. Both ROW_COUNT and the first (BK_PTR),Y are guaranteed to be within the range $00-$7F, if that helps. --Will

Thanks (on both counts). I agree, there is definitely a problem with my video drivers (HP laptop running Windows XP) because other apps that try to full-screen also generate a blue screen. However, I've also noticed this sporadic full-screening of Stella on my other PC (a Dell running Vista). It doesn't particularly bother me on the Dell since the Dell does support full screen mode and it's simple enough to turn the full-screen back off after it enables itself. --Will

One other thing: occasionally (somewhere between every 10th and 20th time), Stella will spontaneously go into "Full-screen" mode when a game is selected. Unfortunately for me my video drivers do not support full-screen mode so I get a blue screen of death whenever it does this. It would be nice to either track down and fix the cause of the occasional switch to full-screen mode or provide some configuration option of disabling Full-screen mode entirely for those of us with crappy video drivers. --Will

Sent you a PM with the new assembly. (For the benefit of anyone else reading: If I move the balloon location to zero page, the balloon does not disappear when I toggle the debugger; it only disappears when it's stored in extended RAM.) --Will

Thanks. I'll PM you the source... I noticed another artifact that may shed some light on it. I have a "collapsing walls" room that works beautifully... unless you toggle the debugger: 1. Start on the blue screen. Go down three screens (past the duck, past the balloon) to a purple room with a shield in it. 2. Go left. The walls will collapse on you unless you escape to the left or right... 3. But if you toggle the debugger in the trap room, the playfield gets messed up until you leave and return. Both the trap room playfield and the balloon location are stored in expanded memory (I'm trying to use the CBS RAM Plus 256-byte method... maybe it's not supported 100%?) and that memory seems to be zeroed out when entering the debugger. The player location (room X/Y) is stored in normal memory and is not affected. --Will

I don't know if this is a Stella bug or my bug (I'm trying to write a homebrew), but I notice that going into debug mode and then returning to gameplay mode "eats" the sprite that was being displayed. Since I'm new at this it's entirely possible (likely) I'm doing something wrong in the code, but it still seems odd that simply toggling debug mode on and off would change which objects are being displayed. It's almost as if entering debug mode is clearing my variables. Here's how to reproduce this: 1. Run duck.bin (attached). 2. Player starts on a blue screen. Go down two screens (past a flashing duck on a red screen) to a yellow "Y" shaped screen. 3. There's a blue and white balloon sprite on the yellow screen. If you do nothing, the balloon remains on the screen indefinitely. 4. If you press the ` key to toggle debug mode, then press it again, the balloon disappears. Any ideas what could be happening? --Will DUCK.BIN

That's one book I would definitely buy.

That works perfectly! Thank you very much. --Will

Can any kind-hearted assembly expert tell me what I'm doing wrong here? I want to put the number five into the A register. This seems to work fine: LDA #$05 It generates the (immediate mode) opcodes A9 05. However, when I use a symbolic name for readability: MAX_LIVES = #$05 LDA MAX_LIVES ...DASM generates the wrong opcodes: A5 05, which result in it trying to read from memory location 05 rather than store the number $05 in the A register. Any ideas what I'm doing wrong here? Replacing the = with EQU or EQM does not seem to help. (I apologize if this is not the right place to post this.) --Will

Very interesting interview! Having looked at the Adventure disassembly, though, I think he's understating the amount of code that went into getting that Easter Egg in there... a lot more going on in there than "just add[ing] a few fields to the data structure." Still, it was fun to see what he's up to now. The memristor project sounds pretty interesting. --Will

I've lurked here for years but this is my first post... I was compelled to register an account today just so I could say what an awesome port this is. I still play the "real" Jr. Pac-Man on MAME a few times a month, and this is probably the best emulation of an arcade game I've ever seen. This is just really high-quality work, and I wanted to say how much I appreciate the effort. --Will