Why can't the Atari 2600 display better graphics?

[Thomas Jentzsch]

Reactor control is the same as Centipede or Missile Command.

It just moves like a mouse pointer. No momentum in moving.

The particles you push and that bump into you slide your ship around.

So (unlike the joystick in the 2600 version), the trackball puts no momentum to the ship, just the particles do, right?

 

So that would mean, that if you bump into a particle while moving your ship and then shortly after that stop moving, the remains of the particle momentum are still there?

[iesposta]

Right. The joystick momentum is to simulate the rolling and slowing down of the ball spin.

 

If you bump into a particle and stop moving, both ship and particle repel in the opposite direction (a small opposite direction) the cumulative movement of all those other particles bumping into your ship will push your ship into the outer wall.

[Thomas Jentzsch]

OK, I got the code working. You can move around as you wish. But the possible resulting speed is so high, that the old game code gets problems.

 

E.g. you can now move through the solid core easily.

 

What's the maximum speed of the ship in the arcade version (e.g. compared to the 2600 version)?

[iesposta]

Here is Arcade Reactor. Maybe this will answer your questions?

 

Really not so much movement speed as player precision placement.

Also it is important to be able to hug the center of the core in the beginning levels.

 

http://youtu.be/ZYSlrFffWFs

 

Here is 2600 Reactor:

 

http://youtu.be/OuIPqxkIO1M

[Thomas Jentzsch]

Here is Arcade Reactor. Maybe this will answer your questions?

 

Really not so much movement speed as player precision placement.

Also it is important to be able to hug the center of the core in the beginning levels.

Unfortunately I have no broadband access at the moment. I will be able to check in a few days.

 

Anyway, I got frustrated by two other projects, so I spend a little time with Reactor again. The attached versions are preliminary, most likely the controls have to be tweaked.

 

I see two potential changes:

1. the sensitivity might be too high as this game requires pretty precise input
2. the momentum of the player is stopped on an axis, if the trackball is moved on that axis. Not sure if that makes the game too easy, since I can only test via Stella and mouse.

Feedback is welcome.

Reactor CX-22 Hack v0.9 (NTSC).bin

Reactor CX-80 Hack v0.9 (NTSC).bin

Reactor Amiga Mouse Hack v0.9 (NTSC).bin

[iesposta]

I would say Reactor TB plays perfect!

I have a PM to someone who really likes the arcade version, and surprisingly likes the 2600 version.

Waiting to see when he can play this and give me his thoughts.

[Lynxpro]

Yes, ROM was no problem for Centipede. There are quite some unused areas and I found traces of Galaxian code/data. Probably the same EPROM was used for both games during development.

 

Also I found some (unused) data which also shows in Dig Dug and Millipede, but at completely different addresses. No clue what that means,

 

BTW: Reactor is THAT close!

 

Since that's basically the equivalent of junk DNA, I wonder what would happen if you eliminated it...

[Thomas Jentzsch]

Nothing, at least not in Centipede, since it is not accessed anywhere.

[Thomas Jentzsch]

Thomas, whatever you do I hope you expand the rom and put in a screen at the beginning for the user to spin the trackball, and auto-detect which one it is. IMHO that adds a nice touch and would be more user-friendly then multiple versions.

Missed this one before...

 

I have the code for this ready and it works quite well.

[Thomas Jentzsch]

Ha! Well I didn't really have anything to do with Thomas's hack,...

Actually you did.

[Omegamatrix]

I've managed to finally get the cycles for the sample routines built into Millipede. Without the Millipede on screen I get 19 samples a frame (both X and Y), and with the Millipede on screen I get 17 or 18. I think that will be good enough, though I haven't tried it.

 

Next I need to acquire 4 zeropage ram locations to actually store the data. Then I need some more ram, either Superchip or zero page, to complete the routine. Here is the current rom and source:

 

 

Millipede(Expanded_No_Trackball).zip

 

 

Remember this does not have trackball support. It should play exactly like the original Millipede, except the rom is a lot different. The importance right now is that nothing is broken. However, I don't expect it to be compatible with a Flashback 2. It should work with Harmony and Harmony Encore though. If it does not appear to work on the Harmony, then try changing the extension from ".BIN" to ".F4S" to tell the Harmony what type of bankswitching to use.

 

If anyone wants to test the rom for any fatal bugs, please do. If anyone wants to help freeing up some zero page ram, please do. I won't be that quick on this for the next week and half, though I will try.

 

 

[iesposta]

I'll test it. I love this game.

I wish I could help with the programming.

Why did Thomas only need 2 1/2 bytes of RAM and this needs so much more?

[Omegamatrix]

I'll test it. I love this game.

I wish I could help with the programming.

Why did Thomas only need 2 1/2 bytes of RAM and this needs so much more?

 

Simply put, this game requires a very quick routine because there is a severe lack of cycles available. I was barely able to squeeze 24 cycles out of every 9 lines as it is... I'm using the 24 cycle routine I created from post 134. It reads both axis in 24 cycles total, which is pretty good for an assembly routine.

 

I don't know if this routine will work for Amiga Mouse and CX-80 trackball. I haven't looked at any source code for those yet. For the CX-22 this should work no problem.

[iesposta]

Both file extensions work on original Harmony.

The game plays just like it should.

I get higher scores when using a CX-40 joystick. Around 70,000.

Played through a few games that way.

Lastly I played some games with the trak-ball in JS (joystick) mode. Got to 14,500!

[Thomas Jentzsch]

If anyone wants to help freeing up some zero page ram, please do. I won't be that quick on this for the next week and half, though I will try.

I am busy for the next ~two weeks. Afterwards I can help.

 

 

How often are you sampling the values for X and Y? Maybe you could save some RAM if you read them alternating with a lower frequency?

[Omegamatrix]

I am busy for the next ~two weeks. Afterwards I can help.

 

 

How often are you sampling the values for X and Y? Maybe you could save some RAM if you read them alternating with a lower frequency?

 

Without the Millipede on screen I get 19 samples a frame for X, and 19 samples for Y. With the Millipede on screen I get 17 or 18 (for each axis). I don't want to go any lower.

 

 

There might an opportunity with ram from $E3-$E6. I need to look more in depth at the routine which is writing to there. First though I'm trying to go through the ram and sort it into groups with a general idea of what it is being used for.

[Thomas Jentzsch]

I think if anything else fails, 8 or 9 samples per frame would work quite well too. You can move 160 pixel within 20 frames, that sounds sufficient. But I have only tested with Stella.

 

Good luck with finding the RAM you need.

[Omegamatrix]

I have freed 1 zero page ram permanently, and a couple of more temporarily during the kernel. Here's what I did:

 

 

1) Transferred 1 ram location to stack pointer during kernel, and transferred it back after the kernel.

 

2) Took 1 ram location that never used bit7, added 15 to it, and stored it to T1024T. After the kernel it has decremented to the original value and I restore it.

 

3) Merged 1 ram location that only used a couple of bits with a high byte of an indirect pointer. With a high byte of a rom pointer $1x,$3x,$5x,$7x,$9x,$Bx,$Dx, and $Fx are all the same. So:

;;;;; Normal use for "AudioRoutines"
L963A:
    jmp.ind (AudioRoutines)      ;5  @11   $9Dxx



;;;;; AudioRoutines+1 now merged with ram_81
    lda    #0                    ; 2
    sta    ram_B4                ; 3
;     sta    ram_81                ; 3 clear

    LDA    #(>L9D00 & $1F)       ;2  $1D
    STA    AudioRoutines+1       ;3 clear bits 7, 6, and keep pointer...



;;;;; Updating bits previously held by ram_81
;     inc    ram_81               ; only ever reads bits 1 and 0 though
    LAX    AudioRoutines+1
    SBX    #-$40                  ; now using bits 7 and 6...
    STX    AudioRoutines+1

If you're following what I'm doing here, The high pointer for "AudioRoutines" will now either be $1D, $5D $9D, or $DD. All will work for the indirect jump, and also holds the two bit from ram_81 previously. It can hold up to 3 bits, but I combined it with ram_81 as it was available.

[Omegamatrix]

Here are my current thoughts on implementation. My routine captures the number of changes of states for each axis. I want to keep the samples as high as I can so I'd like to use it as is. Right now it doesn't record the direction. I was planning on finding the direction before or after the kernel.

 

If the trackball is moving very fast then hopefully you should be able to see changes in 9-18 scanlines. Also you will be traveling in the same direction as the previous frame because you have accelerate for a few frames to reach top speed, and de-accelerate before changing directions. If the trackball is just starting movement, then hoping to see a change in changes in 9-18 scanlines fails because it takes longer to see a change.

 

To fix this I think I'll use a couple of bits to lock in the direction. The direction bits will be unlocked if there is no change in the diff count for that axis, or if the diff count is low, i.e. 1-2 (I pulled those numbers out of a hat). If the direction bits are locked, continue with current direction.

 

Next I'll have to take a sample (without a diff count) right before the kernel. When the score display routine starts I will take a final sample (with a diff count). If the direction locks are unlocked, then after the kernel use a look up table indexed by the counts to see what direction you are traveling by comparing the final sample with the beginning. If inconclusive, throw the counts away and try again next frame.

[Omegamatrix]

Is there a list of the sequence of states you go through, for each direction, for each type of trackball? I can't seem to find this information. Can someone post it?

[Thomas Jentzsch]

CX-22; 00, 01 and 10, 11 (first bit indicates direction) (bits: x:0 & 1, y:2 & 3)

CX-80: 00, 01, 11, 10 (bits: x:0 & 1, y:2 & 3)

Amiga Mouse: 00, 10, 11, 01 (bits: x:3 & 1, y:2 & 0) (same as CX-80, but in reverse and bits are interleaved)

[iesposta]

Thomas,

In arcade Reactor, when you stop moving the trak-ball, your ship stops.

No momentum.

I think you got it right the first time.

Do you have ideas to change 2600 Reactor more?

As it said before it plays perfect to me and it is very challenging to get past a score of 35,000.

[Omegamatrix]

Thomas, does Amiga and cx80 use a direction bit too? It sounds like it does from your post. Cx80 uses same direction bit as cx22, and so does amiga except bits for amiga have been flipped so that it would be bit6 for the direction bit instead of bit7, fo example.

 

For direction bits is a '0' for left and down, and '1' for right and Up? Is that the same for all 3 controllers?

[Thomas Jentzsch]

Nope. Amiga and CX-80 use Gray Code, there is no direction bit. You have to determine the direction from the bit changes. I know this makes it much more complicated.

 

You can determine the direction outside the kernel by counting the changes and match them to the current bits. If the number of changes is odd, then this works. In case of an even number, you cannot determine the direction like that. You can only assume the previous direction then (if there is no change, I would reset the direction to undetermined).

 

That's why I finally used change and direction polling inside the kernel for my hacks.

[Thomas Jentzsch]

Do you have ideas to change 2600 Reactor more?

No plans here, unless the controls need tweaking.