Hack of Coleco's Venture: Level 3 implememted!

[+batari]

I've been visiting Atariage for four years now so it's about time I contributed something. Eventually I want to make my own 2600 game from scratch, but for now I'm trying my hand at making a worthwhile functional hack.

 

Going with the recent improvement of 4k games by making them 8k, I thought I'd do this myself. I chose Venture because it really irked me in the day when I bought the game and found level 3 missing entirely. Now, 20 years later, I'm doing something about it. Anyhoo, the missing level 3 is implemented now! Amazing how much you can improve a 4k game with 8k (via F8 backswitching, in this case.)

 

It's playable but it has a few bugs I'm still ironing out. I am posting the current .bin so people can try it out and tell me what they think, and to tell me if there are any more bugs. Hopefully someone has a Cuttle Cart or something to let me know if it works on real hardware instead of just emulators.

 

Known bugs (** means I know the source but it's hard to fix!):

 

Demon room:

- sometimes demons get stuck in walls

- sometimes one demon turns into other objects and you can't shoot him **

- other weird graphical quirks related to the above **

 

Genie room

- small dot in playfield flickers **

 

I have a few ideas on how to improve gameplay but I'm not sure if they would be possible. Namely, the mosters are really stupid and seem to move randomly while in the arcade game they actually try to avoid your shots. There is a good deal of free space now, maybe 1k or so in bank 2, where such improvements could be done. I might also try to improve the sounds.

 

Oh yeah, although I don't know these guys, thanks to Manuel Polik and Robert Mundschau for producing the disassembly that I found on the Dig. There's no freakin' way I could have done this without their work.

venture3.zip

[Vic George 2K3]

Not bad for a hack. Although in the topmost room when you try to enter through the top door, one of the monsters ends up right on top of you.

[Thomas Jentzsch]

Oh yeah, although I don't know these guys, thanks to Manuel Polik and Robert Mundschau for producing the disassembly that I found on the Dig.

Both are active members of AA (Cybergoth, Robert M).

[+batari]

I fixed the bugs in the demon room, and moved the demon that appeared on top of you when you enter the room from the top. Now the only bug I know of is the flickering dot in the genie room, which I may not bother fixing.

 

I'll post the updated .bin file. Any other comments welcomed. Anyone tried this on a cuttle cart?

venture3.zip

[Nukey Shay]

That's an excellent hack you've got there

And you are right...that flickering pixel is not really distracting.

 

Have you thought about just setting up an adjacent page of memory with alternate character GFX to animate them? Then a bit can be AND'ed from the frame counter, pulled to bit 0's position, and adding the page # of the first table when saving the pointer. Since you still have a bunch of free memory, one page is easy to part with

 

 

Thought of a name?

[SS]

Nice work so far.

 

Any way to have the rooms fill in on the map as you've completed them? I always wished that the 2600 version had that feature.

[SS]

Anyone tried this on a cuttle cart?

 

I tried it on my CC2. Everything looks/plays fine.

[+batari]

Have you thought about just setting up an adjacent page of memory with alternate character GFX to animate them? Then a bit can be AND'ed from the frame counter, pulled to bit 0's position, and adding the page # of the first table when saving the pointer. Since you still have a bunch of free memory, one page is easy to part with

 

The problem I see with animating the monsters that way is that bank 1 is totally full and that's where the display kernel for levels 1 and 2 expect to find the graphics.

 

In level 3, however, I could do it the way to suggest because this level is in bank 2 and there's enough space here.

 

A painfully easy way to animate the level 1-2 monsters would be to simply make the game 16k. That way bank 3 could hold an alternate copy of bank 1 with a different set of monster graphics and all I would need to do is switch to bank 3 and back. So do you think I could do as you suggest with the frame counter but instead pull it to bit one's position, transfer it into the X register, then pull a LDA 1FF6, X to switch to the proper bank (1 or 3). Would this work? It seems like it would, but I don't know enough to know for sure.

 

Thought of a name?

 

Venture 3 sticks in my mind because there's already a Venture 2 (even though it's just a graphics hack) and the "3" suggests that level 3 is here at long last.

 

Any way to have the rooms fill in on the map as you've completed them? I always wished that the 2600 version had that feature.

 

Although I can think of a few ways to do this, they all involve rewriting the display kernel (which is painful, I'm told.) If I can think of an easier way, though, I'll do it.

[Nukey Shay]

That's easily solved...just transfer the score display routine (which was right at the top of the main loop) over to bank 2 just before it jumps to bankswitch that flips to bank 1. You'll have to move the character set for the digits along with it. Boom...1 page free

[Nukey Shay]

BTW if cycle time becomes an issue, you could even transfer everything up to where scanline 14 is WSYNC'ed (since 67 cycles are being wasted there). To do that, you'd have to have a duplicate routine for PosObject in both banks. That should be plenty of space not only to fit in the alternate character set, but also to perform the flip between sets AND the bankswitch instruction More space could probably be reclaimed by finding data tables that can have bytes shared between them.

[+batari]

Great idea! There is just enough space in the score table (80 bytes) to fit in 8 monsters @ 9 bytes apiece, plus maybe the small hall monsters (5 bytes.)

 

I've also already found tables that can be shared - I had to because there was a table that ran from $1FF0-1FF9, which interferes with bankswitching. I found that moving this table right on top of the monster color table worked after hacking a bit of code because one of the values was $00 (I added to each value in the table and subtracted when accessed.) The colors are different now but they all seem reasonable, none are too dark or anything. I will similarly use the treasure color table if I need extra space, maybe even to put some code in there...

[NE146]

Verrry Interesting. I have yet to try this out even on an emulator.... but I definitely plan to at least play it on a CC1 on a 2600 when I get the chance.

 

With the extra memory, I wonder if future iterations or contributions from others could offer a chance for other elements from the arcade game to make an entrance (i.e. the treasure count.. or even music)?

[Nukey Shay]

More memory saving...

 

(PFshapechanges)

; If we change the kernal logic so all rooms use the same height wall sections,

; then most if not all of this ROM code be reclaimed for other uses.

 

Was this done? Seems like a good way of picking up a sizable amount of space

[Goochman]

 

Very cool - Really enjoyed the extra level and was very bummed when I bought the original

[Robert M]

Hi,

 

 

I am glas to sse someone benfitiing from my disassembly. I suspect I can diagnose the blinking pixel problem if I saw it in action, but I can not uncompress the file you have attached. Which compression tool ddid you use?

 

The blinking is most likely due to the P1 repositioning within the frame. You must design the room to be symetrical for the 2 kernel line pairs where P1 is being repositioned.

 

Cheers!

[Nukey Shay]

Huh? WinZip opens it right up. So does WinRar

[Robert M]

Huh?  WinZip opens it right up.  So does WinRar

 

Ah yes. There it goes.

 

Very nice. Yes, I am afraid the blinking block is caused by the P1 repositioning routine because the room shape must be symetrical on the 2 kernel lines used to reposition P1.

 

Nice work!

[+batari]

Very nice. Yes, I am afraid the blinking block is caused by the P1 repositioning routine because the room shape must be symetrical on the 2 kernel lines used to reposition P1.

 

I saw the comment in your source about that, so I figured that was the problem. To fix it requires that I add a bytes to both the room graphics table and the room wall height table and adjust the repositioning table if needed. I had to do just this to get the demon room (the big key) to work right since the entire playfield for this room took up just 40 bytes and this simply wasn't enough to make the key look right. I guess it's lazy not to fix it but it's just a little dot...

 

More memory saving...  

 

(PFshapechanges)  

 

; If we change the kernal logic so all rooms use the same height wall sections,  

; then most if not all of this ROM code be reclaimed for other uses.

 

 

Was this done? Seems like a good way of picking up a sizable amount of space

 

No, because the wall height would need to be increased to 8 pixels each in order to start saving space, and currently there are several walls use 4 pixels.

 

The wall height table does initially seem wasteful because it uses 145 bytes, but if we must have 4-pixel high walls it actually saves space overall. The reason is that most of the playfields have redundant shapes so there's no need to copy the same byte over and over again in memory.

 

Here's my estimate of the savings:

 

Of the 9 mazes, five are asymmetrical and four symmetrical, therefore 5 mazes take 4 bytes per line and 4 take 2, for a total of 28 bytes per line, and there appears to be 38 lines, so the all the mazes together would require 1064 bytes to encode this way.

 

The current game does it all in 478 bytes for the playfields+145 for the table=623 bytes.

 

Of course making them 8 lines each would bring us below that, but the rooms look blockier. The mosters could also walk out of the doors (they are also 8 high and I think they're only checked for playfield collisions) so you'd have to put in additional code to prevent this.

 

You did suggest looking for tables to share, and I think there are more that I didn't think of before. The sound table and the joystick values table can be shared between banks, as can the code that uses these tables. Possibly also the some of the collision checks could be shared. When I get a chance to work on this again in a few days I'll see what I can do.

[+KaeruYojimbo]

This is very cool. Venture has alaways been one of my favorite games. I can't wait to see what the finished version looks like.

[Fellow Atari Man]

This is very cool. Venture has alaways been one of my favorite games. I can't wait to see what the finished version looks like.

 

Can't really get much in the way of photos, due to the flicker, since not much would be appearing onscreen at once, but here's what the map for level 3 looks like, at least...

[+johnnywc]

Wow - great hack!! The 3rd level really adds a lot to this game. This may sound picky, but is there a way to change the color of the walls on the 3rd level so they don't look like the 1st level? I believe they were yellow/gold on the Coleco/arcade version, but I may be wrong.

 

Either way - congrats on a great hack!!

 

Thanks,

[+batari]

is there a way to change the color of the walls on the 3rd level so they don't look like the 1st level? I believe they were yellow/gold

 

Yes! This one is easy, just a single byte. I'll do this in the next version I post here, hopefully in a few days.

[Nukey Shay]

BTW regarding a treasure display...the game needs to intercept the regular game. Instead of jumping to the in-game display kernal, it can be side-tracked and sent to a totally different display kernal (which uses any ram location(s) as counters, etc.) When whatever you are using as a frame counter rolls over, restore the values to those ram locations, set up the normal display kernal, and jump to it. The custom display kernal could use a 4-digit routine to display the treasures collected on 3 seperate lines...or maybe use a 6-digit routine so that 2 of the sprites could include the caption "level 1" etc (you'd need to squash that a bit to be able to fit into 2 8-bit sprites). Then all that would remain would be to find a way to keep track of the treasures collected between levels (any free ram to be found in Venture?)

[Vic George 2K3]

Just a suggestion, but can you try making the 3rd level rooms be orange/tan-colored like the arcade version?

[Nukey Shay]

 

Yes!  This one is easy, just a single byte.  I'll do this in the next version I post here, hopefully in a few days.