2600 BERZERK more new mazes!

[neotokeo2001]

Wow, that Westworld Berzerk looks wicked! Did it ever got made?

 

 

I can't remember how many were made but it did get a small release.

 

[Out_of_Gas]

Wow, that Westworld Berzerk looks wicked! Did it ever got made?

 

 

I can't remember how many were made but it did get a small release.

 

 

 

I recieved one.

[cosmosiss]

*drools*

 

If you ever decide to make more, count me in.

[espire8]

I came up with "Outlaw Berzerk", and through Neo it became Westworld Berzerk. But I also was able to change the walls. I know it was a older post, but others DID care about changing the walls, granted not as elaborate as you.

Sorry if I sounded rather harsh in some of my last posts in this old thread. I'm not trying to knock any other hackers out there, I guess I was just disappointed at the time that my efforts to create "full spread" new maze didn't generate any entusiasm for a truely complete 2600 berzerk with voice, diagonal shots, and not just different maze designs but adding additional rooms to explore besides the 4 already there. At least to 8 rooms for better varity.

 

My gripe with other berzerk hacks is that the wall changes are designed for their particular hack and are not truely designed as rooms that you would normaly find in a berzerk game. What I meant by unique was the walls being changed throughout the entire playfield and not just "parts" of it. This is what I meant about caring enough to figure that out. It wasn't easy for myself. I thought would revive something when the forums finally see for the first time completely new berzerk style mazes. But even my efforts was greeted with low responce and not enough to warrant a coder's interest.

It seemed to me like "Where are all the berzerk fans?" ..though I still love the game, I forgot it and moved on. A complete and accurate 2600 berzerk is still what I want but looks not to happen because not enough people are wanting to speak out. There's just no demand.

[littleman jack]

Espire8,

 

I think there is a demand. If you make another version with new mazes and get it into production, I'm pretty sure that people will buy it.

 

Berzerk seems to be on a lot of Atari 2600 fans' top 10 lists.

[espire8]

Espire8,

 

I think there is a demand. If you make another version with new mazes and get it into production, I'm pretty sure that people will buy it.

 

Berzerk seems to be on a lot of Atari 2600 fans' top 10 lists.

I were planning on just producing a few of my own berzerk carts for myself when I started this thread awhile back.

 

Sadly, I would have loved Debro's diagnol shots and John Payton's sealed-off side exits in the same bin, but I don't have the coding skill to add them and I really don't want to bother them if it's not in their interest.

 

Not as a money making thing -but maybe if enough people were interested, I'd concider a small run of no more than a dozen copies with:1) Mike Mika's voice enhancement. 2) Four new arcade maze designs and smaller man/robot sprites. 3) Arcade style title screen.

 

Will maybe do that later this summer.

[littleman jack]

Thanks. I'll look later this summer for any new info. Your ideas sound really good.

[Nukey Shay]

By request:

Here's a 21-screen variation of Debro's diagonal shot hack. The program has been divided into 2 banks, with the first bank handling all of the GFX. The original game uses a single byte in ram as an offset to screen GFX for each of the 3 registers...meaning that each register has to have it's data on a given 256-byte stretch of rom (a single "page"). What I've done here is to reuse the score digit pointers as indirect vectors to the screen data...so that any of them can be located anywhere you want. This requires a bit of time to reset the pointers to the score variables later, so the "erase leading zeros" part of the routine has been removed for now (and the bottom wall is displayed a bit thicker than the original).

 

Note that while the program can support many more than just 21 screens, that is the most it will currently allow without data-sharing. With the latter method, you can reuse bytes (or entire sections) of screens for others...making the theoretical maximum @256 screens. There's also 2k of free space still left in the other bank to add a title screen or whatever you want. Ram clear routines have been seperated, so you can use any of the console's ram for a seperate display before continuing (tho the random seed and console detect variables should be left untouched by it).

 

I'm not good at designing screens, so it currently only has the data of the original 4 screens...all the rest are empty rooms (missile data is still being shared with PF0 data for the first 4 screens). But the code is in place for easy editing.

 

In addition to the time issue mentioned earlier, there's a couple of other glitches to work out. But here ya go:

Berzerk21.zip

[supercat]

I haven't downloaded yet, but I was wondering if it includes my left/right door hack? If not, that would probably be a good addition (I wonder why the original programmers never thought of it?)

[Nukey Shay]

No, it doesn't. Using (ind),y instead of screen,x burned 9 more cycles, so it may need extra legwork to add it (I never looked at your code).

[supercat]

No, it doesn't. Using (ind),y instead of screen,x burned 9 more cycles, so it may need extra legwork to add it (I never looked at your code).

 

The left/right door hack doesn't need any more cycles in the main part of the kernel. It just positions the Ball at the left or right as appropriate, and then (if necessary) enables it when it starts drawing the maze and disables it at the end. The ball is set two pixels wide, so it 'nestles' nicely in the doorways.

[Nukey Shay]

No, it doesn't. Using (ind),y instead of screen,x burned 9 more cycles, so it may need extra legwork to add it (I never looked at your code).

 

The left/right door hack doesn't need any more cycles in the main part of the kernel. It just positions the Ball at the left or right as appropriate, and then (if necessary) enables it when it starts drawing the maze and disables it at the end. The ball is set two pixels wide, so it 'nestles' nicely in the doorways.

 

Good call...I'm looking at it now. Maybe reset the ball size so that it matches the pixel width as well (adjusting HMBL). That would make a better candidate for something to place into the B&W toggle (which is broken in the above disassembly, BTW).

[supercat]

Good call...I'm looking at it now. Maybe reset the ball size so that it matches the pixel width as well (adjusting HMBL). That would make a better candidate for something to place into the B&W toggle (which is broken in the above disassembly, BTW).

 

What do you mean 'pixel width'? I think having the Ball nestled in with the wall so the door is visible but blocked looks very nice. BTW, if you add the Ball, two other tweaks are needed, iirc:

 

-1- Adjust the collision-check code so that a player/ball collision is fatal.

 

-2- Make the code not solidify the side walls when the player enters via the left or right (since the Ball will perform that function).

[Nukey Shay]

Good call...I'm looking at it now. Maybe reset the ball size so that it matches the pixel width as well (adjusting HMBL). That would make a better candidate for something to place into the B&W toggle (which is broken in the above disassembly, BTW).

 

What do you mean 'pixel width'? I think having the Ball nestled in with the wall so the door is visible but blocked looks very nice. BTW, if you add the Ball, two other tweaks are needed, iirc:

 

-1- Adjust the collision-check code so that a player/ball collision is fatal.

 

-2- Make the code not solidify the side walls when the player enters via the left or right (since the Ball will perform that function).

 

Yeah...you are probably right. Quick tests show it to be conveluted trying to match the playfield pixels. But I think that having it selectable is also a good addition (altering the value given to mazePF0Value by SetupForNewScreen accordingly).

[Nukey Shay]

Bugfixed version...

I implemented the above...the doors can be removed by toggling the B&W switch (in which case, it would go back to having both sides blocked). I also corrected the small artifact left at the top of the screen when enabling the ball.

 

Also,

The PAL option is working again, and the "leading zero" routine is back in place. To save the time I needed, I just reset the vectors manually when initializing them (no loop). The screen data remains where it was just in case anybody was adding screens already The joystick-fudged screen selection (used for testing) has been removed.

Berzerk21.zip

[espire8]

Thanks John and Nukey.

 

I have 30+ mazes to hack in there now for this summer!

 

All That's needed is the voice and arcade title to be complete!

[ComputerSpaceFan]

I don't seem to be able to open Nukey's Berzerk21.asm file in the Stella emulator. Is this some kind of compiler file and not an actual ROM? I'd sure like to try out what he's done so far.

And is Evil Otto going to appear in the final product as well?

[Nukey Shay]

It's a reverse-engineered disassembly, not a binary. To be played, it must be run through an assembler first (such as Dasm). The reason I didn't post a binary along with it is because as-is, it's an incomplete game. All of the added screens have zeroed data (so you would basically be running around in a lot of empty boards). Besides the problem that such "test" binaries always seem to wind up in the Good2600 list But here is what you are looking for.

 

Equate table for the Dasm-impaired (to use a bithacker):

 

MazePF0Data_0            dc02
MazePF1Data_0            dbac
MazePF2Data_0            dd58

MazePF0Data_1            dc2c
MazePF1Data_1            dbd6
MazePF2Data_1            dd82

MazePF0Data_2            dc56
MazePF1Data_2            dd04
MazePF2Data_2            ddac

MazePF0Data_3            dc80
MazePF1Data_3            dd2e
MazePF2Data_3            ddd6

MazePF0Data_4            db2e
MazePF1Data_4            db58
MazePF2Data_4            db82

MazePF0Data_5            daac
MazePF1Data_5            dad6
MazePF2Data_5            db04

MazePF0Data_6            da2e
MazePF1Data_6            da58
MazePF2Data_6            da82

MazePF0Data_7            d9ac
MazePF1Data_7            d9d6
MazePF2Data_7            da04

MazePF0Data_8            d92e
MazePF1Data_8            d958
MazePF2Data_8            d982

MazePF0Data_9            d8ac
MazePF1Data_9            d8d6
MazePF2Data_9            d904

MazePF0Data_10           d82e
MazePF1Data_10           d858
MazePF2Data_10           d882

MazePF0Data_11           d7ac
MazePF1Data_11           d7d6
MazePF2Data_11           d804

MazePF0Data_12           d72e
MazePF1Data_12           d758
MazePF2Data_12           d782

MazePF0Data_13           d6ac
MazePF1Data_13           d6d6
MazePF2Data_13           d704

MazePF0Data_14           d62e
MazePF1Data_14           d658
MazePF2Data_14           d682

MazePF0Data_15           d5ac
MazePF1Data_15           d5d6
MazePF2Data_15           d604

MazePF0Data_16           d52e
MazePF1Data_16           d558
MazePF2Data_16           d582

MazePF0Data_17           d4ac
MazePF1Data_17           d4d6
MazePF2Data_17           d504

MazePF0Data_18           d42e
MazePF1Data_18           d458
MazePF2Data_18           d482

MazePF0Data_19           d3ac
MazePF1Data_19           d3d6
MazePF2Data_19           d404

MazePF0Data_20           de72
MazePF1Data_20           d358
MazePF2Data_20           d382

RobotColorTableBank0     dfee (8 values)
RobotColorTable          ffa7 (values should match the above)

 

Note that as mentioned before, the leftmost 4 bits of PF0 data for the first 4 mazes (screens 0-3) must remain unaltered, because it's shared for missile enable/disable data. Besides the 2 color tables, Each of the tables uses a 42-byte unshared stretch of rom that begin at the addresses shown above, so they can easily be edited.

 

BTW Otto is in the game, but not in certian game variations (described in the game's instruction manual).

 

 

Surprisingly, that robot color table is the only redundancy needed in this 8k hack

Binaries.zip

[DEBRO]

Hi there,

 

It's nice to see this being taken further.

 

Since you are hacking it you might want to remove the "bug" that ends the game as soon as the player gains 128 lives.

[Nukey Shay]

Actually, I wasn't taking it anywhere Berzerk was never my game of choice, at the arcade or home. But now that you mention it, 2p support would be relatively easy to add...since there is nothing in the game that needs preserving between them (aside from level#, score, and lives). I would just need to track down additional variables that can be shared.

 

Good catch about the lives tho...I never knew that. A CMP/branch above life increase (score routine) would cure that. Then again, it's a good "revenge" bug from the robots for playing too well

[Nukey Shay]

A 2-player variation is complete

 

Maybe I will spend a little time with this

[ComputerSpaceFan]

We Berzerk fans are forever in your debt, Nukey

[Nukey Shay]

7 bytes of ram were saved from the game:

I found that 4 other variables are easily shared with the printing array (since they don't need to be preserved from frame-to-frame). Berzerk already has 2 bytes unused, and the console type variable has been shared with the flip bit, B&W switch status, and the outer walls (automatically enabled when doors are deactivated). 6 bytes of ram was enough to hold the 2nd player score, lives, level, and starting position...with a bit in the remaining byte controlling whose turn it is. When a player is killed, the game swaps the variables (when on a 2-player game). If one player doesn't have lives, a swap doesn't happen.

 

The 2nd player score could function as a highscore in single-player mode, I suppose. But here's a test file I've been working with to check if other glitches crop up.

 

Game selections are doubled (game 3 = game 2 in the manual, game 5 = game 3 in the manual, etc). Even-numbered game selections are 2-player modes of the earlier selection.

 

Does player 2 have a problem shooting diagonally down/right?

2player_Berzerk_test_.zip

Edited June 6, 2008 by Nukey Shay

[Nukey Shay]

NOTE: the game variations are messed up too. I forgot that they were stored as BCD

 

Also, since the other mazes were incomplete anyway, the AND value in the random maze generation will always pick one of the first 4 mazes.

[Nukey Shay]

Current tweaks:

The bottom wall area has been reduced to match the top (although the GFX shows a slight skew when the bottom door is visible). The player's lives have been changed to BCD. This allows the life counter to display a number when reserves > 6. Negative values would still end the game, tho...so I made 79 reserves the maximum. Game variations have been fixed. Game selections will show up in the appropriate color for 1p/2p.

2player_Berzerk_test_.zip