ZackAttack

That's exactly what I was thinking. Of course you should be able to cross the bounding box when you get to the edge of the maze and can no longer scroll. That or allow it to scroll the edge of the maze far enough that it is in the bounding box. One idea for game play could be to have some moveable walls. A dynamic maze/puzzle game. One way passages might be useful too.

We were actually just discussing this in the assembly forum. I proposed an algorithm which could be used in bB too. Maybe that helps you?

Can you try version 3? If that doesn't work can you try this test program too? strong-arm-optimized.bin

The weird jitter you see is because you're writing to GRP1 at that time. You use too many cycles at the beginning of the scan line. Move some of that logic into vblank. If you want to hide the alien you should put its Y position outside the visible screen or set it's graphics pointer to a block of 0's

Rather than having to manually move the maze I'd prefer it just scroll for me automatically. Personally I think it feels like difficulty via bad controls. The maze and scrolling looks good though. I think this could definitely lead to a fun game.

It's not possible to bus stuff every cycle due to the fact that the cartridge has no access to the CPU control signals. The best you can achieve is one TIA write every 3 CPU cycles. This can be achieved in a 2K game too, the big differences is that you can do it more often. None of this extra cart hardware removes the limitations set by the TIA. It just allows for more opportunities to be creative with how the TIA is used to draw each frame. If the end result is a normal looking cartridge that you can plug into any 2600 and it looks good and is fun to play, why wouldn't you want that?

I think what happened is that the position alien routine has been broken, but since you only used it for the initial position in version 3 it went unnoticed. Now that you're using it every frame it's noticeable. The problem is that you can't write to any of the HMxx registers immediately after you strobe HMOVE. You must wait at least 24 cycles or it will interfere with the HMOVE process. (See stella programmer guide pg9) This may also explain the problems you're having with detecting which copy was hit. That's not going to work so well if the objects are not positioned where you think they are. You're routine is also a few cycles off for other reasons. Why don't you just use the code from the collect tutorial? No need to make your own unless you're trying to do something advanced like positioning objects while also drawing a playfield. sta WSYNC sta HMOVE lda #0 sta HMP1 ;TOO SOON!!!

Your hit detection algorithm appears to be correct. You probably just have a bug in the implementation of it. Don't forget to post asm and bin files for problems like this. We can't help with debugging without them. Regarding the tables. Here's some more details. Variables: enemyHitIndex - Should be 0 for the left copy, 1 for the middle copy and 2 for the right copy enemyX - X position of enemy stored as distance between left side of screen and left side of left copy in pixels. This should always apply to the left copy regardless of it being active to keep hit detection simple. enemyXOffset - offset to be added to the enemyX position when calling the PostionObject routine. enemyState - 3 bit value indicating the state of the enemy. Spawn with state 7 for 3 active copies, and don't draw for state 0 because there are no copies left. Each bit corresponds to a single copy. 1 indicates the copy is active(visible), and 0 indicates it is inactive(hidden) I.E. %00000101 = X _ X and %00000110 = X X _ Lookup Tables: EnemyXOffsetLooup - Use the same index as the EnemyStateTransitionLookup to determine what value to add to the current enemyX value. This compensates for deactivating the leftmost active copy of the enemy by moving it right to where the next copy starts. EnemyStateTransitionLookup - Index into this table with the hit detection result and enemyState to determine what the next state should be. Index is the concatenation of the 2 Hit bits (H) and 3 State bits (S) in the format %000HHSSS EnemyNusizLookup - Index into this table with the enemyState value to determine the correct NUSIZ1 value. Here's some sample code. It's untested, but should be close to what you need. ; Calculate state transition index enemyHitIndex asl asl asl ora enemyState tax ; update X offset ; assumes C flag is cleared by code above. If something else comes between this two sections add a CLC instruction here lda EnemyXOffsetLooup,x adc enemyXOffset sta enemyXOffset ; update current state ; x still has transition index lda EnemyStateTransitionLookup,x sta enemyState ; Set NUSIZ1. ; assumes A contains enemyState. If this is done late you must replace tax with ldx enemyState tax lda EnemyNusizLookup,x sta NUSIZ1 The tables shouldn't be difficult to generate manually. The states are 3 bits, just visualize which copies are still active after a hit occurs. The offsets will be 0 except for a few cases where the left copy is hit, in those cases the value will be 16. The NUSIZ lookup is just mapping the state to the right count and spacing for the remaining active copies. EnemyXOffsetLooup 00000 - 0 ; ... 00100 - 0 ; Left copy hit, but already inactive. No action required. 00101 - 16 ; Left copy hit and middle is already gone So move over 32 because right copy is all that's left 00111 - 16 ; Left copy hit which means the middle copy will be the new location. So move over 16 ... 01011 - 16 ; middle copy hit leaving only the right copy. So move over 16 ... EnemyStateTransitionLookup​: 00011 - 011 ; State unchanged because inactive enemy was hit, normal execution will never go here ... 00111 - 011 ; Left copy hit and deactivated ... 01111 - 101 ; Middle copy hit and deactivated ... 10111 - 110 ; Right copy hit and deactivated EnemyNusizLookup: 000 - 7 ; make it quad cause we should never draw this 001 - 0 ; single copy for the right copy 010 - 0 ; single copy for the middle copy 011 - 1 ; 2 copies close for middle and right copies 100 - 0 ; single copy for the left copy 101 - 2 ; 2 copies med for left and right copies 110 - 1 ; 2 copies close for left and middle 111 - 3 ; 3 copies close for left, middle, right

I don't know how existing games have chosen to implement this, but if I were to do it I'd view the three enemies as a single enemy. This aggregate enemy would have 8 states corresponding to which of the three copies is active. (3 copies, 2 states, 2^3=8 states total) The collision flag can tell you that the enemy was hit somewhere, then you have to compare missile position with enemy position and transition to a different state based on which copy was hit and which state you're currently in. Since there's only 8 states and 3 copies you could have a table to track which state to transition to. That should only be 24 bytes of ROM. Simply take copyHit, shift left 3, bitwise OR with currentState and you have the index into the table to update currentState with. You'll probably want some tables to lookup the NUSIZ1 value for each state (8 ROM bytes), and the horizontal offset for each transition (24 ROM bytes). Still it's only taking up 56 bytes of ROM total for the state management lookup tables. I wouldn't use hmoves to adjust the position when the left copy is removed. Instead I'd just add 16 to the variable which stores P1's horizontal position. You're going to have to keep track of it's position for the collision detection anyway so I'd use the PositionObject() routine each frame instead of using hmove to move around the enemies. Hope that helps.

NUSIZ1 can remove the correct one if you also adjust the position to compensate. I.e. change 3 med to 2 med and move right 16 to remove the left enemy

Until then it would be nice if stella at least handled variables that are larger than a single byte. Rather than ram_85 it should display the closest symbol prior to that location and an offset, Game_JumpInd+1.

It's hard to say without the full source, but it looks like dasm is working fine. I think what you're seeing is stella loading symbols from another bank. Essentially each location may have more than one name which is dependent on the current bank and I believe stella will display them all in the debugger regardless of which bank is currently selected.

Looks good. You may want to enable RESMP0 when the missile goes off the screen and then disable it when the fire button is pressed. I think that would prevent the missile from restarting from the bottom when the button is pressed mid flight.

The problem is that you never clear RESMP0. Per the stella programming guide, the missile will be hidden while D1 of RESMP0 is set.

It would be good to include the bin file too so we don't have to build it to see what's happening.

You're using RESMP0 correctly. In fact everything looks correct except this line: cpx #Missileheight ; check if scanline is missile line You've included # so it's comparing X with the immediate value which is the location of the Missileheight variable instead of the value of the variable.

ok, thanks for trying. I'll see if I can improve the timing further.

That's very surprising since the change from version 1 is so small. I don't really see anything that could have changed the timing enough to cause a crash. Sometimes I pull the SD card out of the computer too quickly without ejecting it and it corrupts the bin file and produces the same results. Could that have happened?

I've been working on a new driver for the Harmony/Melody hardware that makes it possible to offload some of the processing in between servicing the 6507 bus. This extra processing power makes it possible to compensate for the systems that were not compatible with the BUS driver. It's still in the early phase of development, but eventually should make it easy to program the Atari in C/C++. The entire game including the display kernels can be written in C/C++. Currently I have a working prototype of the dev environment which enables source level debugging via visual studio. Then when it's working you simply build it for the Harmony hardware and copy it to an SD card for testing on real hardware. Once it's stable enough I'll be releasing the entire suite of dev tools including all the source code. I recently posted a working example of it using bus stuffing to scroll a PF and another example where JSR is misused to display 10 colored sprites while also playing an audio sample.

I know there have been some systems that did not work with the earlier attempts at bus stuffing, but this is the first I've heard of "CPUs were frying...". What exactly do you mean by this?

The tree is MayDay's masterpiece. It actually looked better before I mutilated it to fit with the graphics engine. I'm sure once I give him the final engine specs he'll come up with something even better.

Yeah, that's just bad image editing on my part.

Thanks for testing. Sorry there's not really anything visible to indicate the power of bus stuffing here. This is going to be an engine for a fighting game so fine scrolling wouldn't really benefit it much. The next step will be to add in the sprites, that's when we'll get to see something that's only possible with bus stuffing. What's really cool about this demo is how little resources are consumed to achieve the scrolling playfield. I use less than one scanline worth of vblank to precalculate a few offsets and the rest of the calculations are done while the screen is being drawn. The ARM is hard at work shifting bits around in between servicing the 6507 bus. All that remaining vblank and overscan time should make it possible to have more expensive audio, physics, and AI. Funny story. After looking into this some I realized that the collision registers won't be set if vblank is enabled. So enabling vblank to hide the detection phase ended up completely breaking it. I disabled vblank and set the color of everything to black instead. Please give version 2 a try, it should work much better. Thanks!

I think I've achieved horizontal playfield scrolling with via bus stuffing and the Strong-ARM driver. If you have a harmony cartridge please try it out. Current Version: Cherry-Tree-Scroll3.bin - 1/25/18 Optimized driver with lookup table and self modifying ARM code, fixed graphic data glitch Past Failures: Cherry-Tree-Scroll2.bin - 1/6/18 disables VBLANK during stuff detection because collision registers won't be set if VBLANK is enabled. Cherry-Tree-Scroll.bin Not supported in emulators yet. Here's what it looks like for those who don't have a harmony cart.

There, I fixed it for you.