Just Jeff

I give you "Hey Taxi!".. No AtariVox though. See attached .bin. Additionally, the taxi is now fully functional, including landing gear with the very reasonable feature of disabling horizontal thrusters while deployed. I also rewrote the collision routine so that it can detect half-misses with one leg on and one leg off. It uses 3 frames to test the collision using 3 different images. If all three images collide/don't collide as expected, the landing is good. Two nice side effects of this was that I didn't have to write any code for attempting to land with the gear still up. Due to the fact that the gear up image is 8 bytes higher than the gear-down image, the frame that is supposed to have no collision, does have a collision- so its ruled a crash. The other side effect was that the taxi shows a little bounce due to the delay while checking all the frames. I was worried about it but I think it actually looks good. Also added the code for crashing due to coming in too fast vertically. In this bin, I changed the playfield priority so you can view the collision detection if you want to click through frame by frame. You will see: Initial collision detection which triggers the check routine. Should be a collision. If the taxi was off the left side a bit, its a crash. Should be a collision. If the taxi was off the right side a bit, its a crash. Should not be a collision. (Detects side impacts and roof impacts, etc) And here is the table. Its checked against the playfield/P0 collision register which sets D7 when there is a collision: CollisionTable: ;These match the frame on which collisions should or should not occure when checking. .byte $80 ;This one is never used because zero offset graphic frame is already known to collide. .byte #0 ;Both legs short- shouldn't be a collision .byte #$80 ;One leg short- should be collision .byte #$80 ;The other leg short- should be collision That's all for now- Jeff SpaceTaxi.asm.bin

Thanks! I got something done on all this. I increased the gravity and also the upward thrust and yeah I think its better. Also added some collision and landing routines as well and even some graphics and sounds. Most of it, I would call placeholder graphics and sound- more to come. Did this too.. Saving a few bytes and cycles. Thanks! New .bin attached. No fancy crash sequence yet- just a red flash on the screen and your taxi is reset on the top left of the screen. I debugged most of it, but there are a few left. You can escape the top left of the screen- basically because P0 isn't written yet where the collision should happen. Also, if you drive into the side of one of the landing pads, its correctly ruled a crash, but when you're reset on the top left, the taxi just hovers there until you push up. I have to add more to the landing checks- right now, you can have one leg on the pad and one off and its ruled a good landing. I think when I fix that, the weird hover will go away. I think what I'll be doing is cycling through different graphics when landing which will test each leg, one at a time. If one doesn't collide then its a crash. -Jeff SpaceTaxi.asm.bin

Good Morning, I re-familiarized myself with what I had going on and then did the taxi thrust, momentum, gravity, and drag routine. Take a test drive and let me know how it feels. Let me know what it would take for me to put you in this car today. A .bin that jumps right to it is attached below, but I also posted it on the first post of this thread and intend to update that one regularly so it's easy to find. I feel like I re-invented wheel here so maybe there is some more efficient way to implement it. I used 4 bytes of RAM which are currently at $81 - $84: VMoveIncrement ds 1 ;Accumulates the the vertical speed on every frame. When the sign changes, the taxi moves up or down a line VerticalSpeed ds 1 ;Changed by the joystick and then decays with gravity HMoveIncrement ds 1 ;Accumulates the the horizontal speed on every frame. When the sign changes, the taxi moves left or right a clock HorizontalSpeed ds 1 ;Changed by the joystick and then decays with drag And here's the movement routine I came up with. Basically, the joystick controls the rate (Speed) at which the byte (Increment) is incremented. When the increment byte changes sign, the taxi moves up or down a line, or over a clock. Then the sign is flipped back. This allows for 128 speeds in each direction. -Jeff: CabMovement: SUBROUTINE .processHSpeed ;Check to see if its time for a horizontal 1 clock move lda HorizontalSpeed beq .doneHMove ;? Can I somehow reduce this to one branch check? bmi .goingLeft ;Positive numbers move the cab right, negative is left adc HMoveIncrement sta HMoveIncrement bpl .doneHMove ;If we have accumulated more then 128 bits inc ObjectX ;then there is a 1 clock move clc adc #128 ;Flip the byte back over to positive while preserving the accumulated bits ;ora #$ff :? This seems to halve the speed for some reason sta HMoveIncrement ;Roll it over 180 degrees to positive jmp .doneHMove .goingLeft adc HMoveIncrement sta HMoveIncrement bmi .doneHMove ;If we have accumulated more then 128 bits dec ObjectX ;then there is a 1 clock move sec adc #128 ;Flip the byte back over to negative while preserving the accumulated bits ;ora #$ff :?This seems to halve the speed for some reason sta HMoveIncrement jmp .doneHMove .doneHMove .processVSpeed ;Check to see if its time for a horizontal 1 line move lda VerticalSpeed bmi .goingDown ;Positive numbers move the cab up, negative is left adc VMoveIncrement sta VMoveIncrement bpl .doneVMove ;If we have accumulated more then 128 bits inc ObjectY ;then there is a 1 line move clc adc #128 ;Flip the byte back over to positive while preserving the accumulated bits sta VMoveIncrement ;Roll it over 180 degrees to positive jmp .doneVMove .goingDown adc VMoveIncrement sta VMoveIncrement bmi .doneVMove ;If we have accumulated more then 128 bits dec ObjectY ;Then there is a 1 line move sec adc #128 ;Flip the byte back over to negative while preserving the accumulated bits sta VMoveIncrement jmp .doneVMove .doneVMove .checkBounds ;? Temporary code to roll the cab over to the other side of the screen ldx ObjectX cpx #152 bne .notRight ldy #1 sty ObjectX .notRight cpx #0 bne .notLeft ldy #151 sty ObjectX .notLeft ldx ObjectY cpx #190 bne .notTop ldy #9 sty ObjectY .notTop cpx #0 bne .notBottom ldy #189 sty ObjectY .notBottom .gravity ;? Probably move this code to Overscan ldx VerticalSpeed cpx #128 ;Downward speed maxes out at 128. 127 would be up beq .noGravityInc lda FrameCounter ;Governs the rate of gravity and #%00000011 ;Change VerticalSpeed speed every 4 frames bne .noGravityInc ;If not 0, then skip the gravity increase dec VerticalSpeed ;Increase downward speed (or decrease upward speed) .noGravityInc .drag ;Reduce horizontal speed if moving to create drag lda FrameCounter and #%00000111 ;Apply drag every 8th frame bne .nodragInc lda HorizontalSpeed beq .nodragInc ;If stopped, then no drag bmi .goingLeft2 ;If cab if moving left, then reduce Horizontal speed by 1 dec HorizontalSpeed ;Therfore cab is moving right, so decrease HorizontalSpeed by 1 dec HorizontalSpeed ;Counteract the inc HorizontalSpeed below that always happens when moving. .goingLeft2 inc HorizontalSpeed .nodragInc rts SpaceTaxi.asm.bin

Alright I think I'll dig this one back out of the heap again.. Maybe this is the year!

Ah yes.. I missed that. Did you forget to mention VS Code or is there something I don't know?

Another option is to get Microsoft VS Code and then install Atari Development Studio. All free. Compiling and running is just clicking one button after that.

The Stella Programmer's Guide is actually an interesting read. I read it without knowing any assembly at the time. It's not 100 pages- more like 35 pages of actual reading. I recommend reading it for understanding- No need to commit all of it to memory. https://atarihq.com/danb/files/stella.pdf

How poor are your assembly skills? I've never done a PAL conversion, but this doesn't seem like it would be too difficult in many cases, having such a limited scope with a known goal. Perhaps you could do this yourself.

This is a really great game! I like the light show.. Needs easier levels for me though.

I use this Excel spreadsheet that I made for 48 bit displays (attached). Just put ones where you want them and the conditional formatting turns it blue. Also, it writes the code (upside down) for you on line 22 that you copy/paste into your editor. I also made an attempt at ring girl for you. _graphics.xlsx

Good Morning.. Looking for a designer again. See details here: BBlocks (Completed!) - Page 5 - Atari 2600 Programming - AtariAge Forums

Here's is the last draft that our designer sent us before he had to give up due to other obligations. Its supposed to evoke the classic 2K style of the launch titles, which was our goal when writing the game as well. We thought it would be fun to be on the box but that seemed to be the toughest element- It still needs more if its going to work. Any comments, suggestions on the design? Still looking for a new designer btw..

Does anyone have any interesting design ideas for the packaging? Amateur mockups accepted! Here's another art theme that never occurred to me before for some reason.. I misspelled BBlocks though- that's a little embarrassing. Does anyone know a designer that might want to work with us?

Here's a little doodle that I thought might be interesting for box art...

Just a little more on this.. TIA is always running, so even though you are in VBLANK, all of the colors and horizontal positions are still "there". How does it remember? It remembers everything you told it and holds it until you change it. This is why you see stripes when you pull a cartridge out. Its showing the last things you told it, on every scan line, forever. So if you think of Pong, for example. It's only necessary to set the paddles once when the game is turned on, then TIA remembers. Only the ball needs to be updated every frame.

Nice job! Are you interested in refining this program? You have some more learning opportunities here if so. I see 8 or 9 things ranging from inefficient to incorrect here. Here are two that are actually affecting this program negatively: As spendidnut mentioned earlier, hit alt-L to see if you are displaying the proper number of lines (262). This program is running only 259 which brings us to issue #2- you're using the carry flag incorrectly. The carry flag should be set for subtraction, not cleared. If you step through the code in Stella (hit the ~ key), you will see that you are actually subtracting 2 on your first time through your loops, even though you have sbc #1. If you clear that up, you'll be running at 262 lines. There are other things too.. Let me know if you are interested in reworking them..

The easiest way to help is to see your code.. So you may want to post it. Short of that.. Did you set CTRLPF to reflect? After that, you will be writing your data to registers PF0, PF1, and PF2 to draw the top and bottom of your design, and need only PF0 for the middle of it (though you could just repeatedly write 0s to the PF1 and PF2 registers there). Are you aware of the fact that you have to put your PF0 and PF2 data in backwards? (For the left half of the screen) This is all on page 39 of the programming guide if you need to read up on it.

Little tip: Stella shows extra flicker with odd frame rates. Get your scanline count to 262 and the prominent flicker you see will go away. I think it might be fine after that.

I feel a 1 clock object with similar luminosity is undetectable. On the other end on of the scale- an 8 clock object flickering black and white is. What colors and clocks are you using?

I still can't figure out how to jump or pick up the gun. Also, do we post high scores here? I got 0!

OK I' think I'll give it a shot. Yours is the first suggestion I've gotten that comes with a understandable explanation of what's happening and why. So maybe this would be a good place for a varistor/potentiometer. What do you think?

I've tried it on both. The first CRT was noticeably dark, same with one of my LCDs. I was able to do a decent adjustment another CRT, but I'd definitely like to improve the performance of the mod if possible so it works better overall. I wish could find suggestions that also mentioned what the components (for removal) are for. Are you sure about removing that resistor? That is yet another different solution.

Thanks I completed the mod and its got a clear picture but... Its too dark. And I think the sound is a little weird sometimes. Apparently that's very common. I've seen many variations on how to correct it. Yours is the first I've seen that shows that specific combination of resistors. Not sure which to do.

Yeah... Re-watching the video, it looks like his yellow is connected to his Audio In on the new board which is counterintuitive I think. He also had me snap off the RF board. I would have much rather unsoldered the whole assembly with the shield which I saw someone do in another. Outstanding questions: Is it OK that transistors 3 and 4 are connected with solder? I don't want to unsolder any of it if I can help it. New questions: Should I have removed any resistors? In another video, I saw someone remove two but I didn't do any. I did remove the one transistor behind the tall red thing in picture 3 (unseen) My right side difficulty switch is sheared off. Can I remove the channel selector switch and use it for a difficulty switch? They look identical.

Good Afternoon, I completed a composite mod on one of my 2600s and have some questions that I was hoping someone experienced with it could help me out with.. When it arrived the instructions were literally "watch one of the many videos online" so I did that. I have not turned it on yet, mostly because I do not think it is correct. Tracing things out on the 2600 board, I believe the yellow and blue wires are reversed. Are they? (The blue looks almost white in the pics.) Here is a picture of the board that came with it: And here is where I connected everything from the bundle of 4 wires on the left side of the picture above which appears to be the input. I feel like yellow and blue may be reversed. Pins 1, 3, and 4 were used. Pin 4 is connected to the wire labelled "Audio In" on the new board. I feel like this should probably be video. Should it?: Additionally, I put this wire on the 4th resistor from the right but my solder is bleeding onto the 3rd resistor. Is this OK? They look like the traces might connect them anyway. Do they? I think these are correct: Yellow is on the yellow jack, and blue is connected to the red and white jacks. These wires came out of the right side of the new board.