Hey coders- Torpedo my Sea Wolf fantasy!

Pretty or ugly, having labeled code that you can make a change to and reassemble with rom location references adjusting automatically is a huge leap forward for people being able to make long desired hacks to the game.
 
Just considering the game itself that such a simple straightforward uncomplicated game can be so entertaining. I think a lot of the charm of the game is complimented by the use of the periscope. I keep thinking of the movies run silent run deep and das boot.
 
Pretty or ugly, having labeled code that you can make a change to and reassemble with rom location references adjusting automatically is a huge leap forward for people being able to make long desired hacks to the game.

I normally do hacks by inserting patches rather than a clean reassembly, but there's not many free bytes in the ROMs so fresh code makes more sense for this.

I still need to do a bunch of cleanup and make some of the data in tables point to labels instead of hard-coded addresses, but at this point, I have a code base that reassembles and matches the original:

1730298639727.png
 
Has anyone built MAME on Windows 7 (w/ cygwin, preferably) recently?
I need to mode the driver to add an extra ROM, and (after installing python) make silently fails without doing anything.

I've compiled it on linux dozens of times, but windows is more convenient at this point.
 
Starting making some changes resulting in some code relocation, and that promptly broke gameplay.

I found an typo in one of my regexps that prevented some of the addresses from being converted to labels and fixed that...

Now I've got issues with some of the motion objects, due to some single byte constants being part of addresses, so I'm tracking those down now.

I started a repo on github, but that's not something I used on a regular basis, but I'll try to push to it intermittently as things get fixed up.
 
During that disaster of a Bruins game last night, I found the spots where it used single bytes for hard-coded address and fixed them so the code appears to be fully relocatable now.
Some care has to be taken in hacking to make sure the sprites don't cross a page boundary, as when ships sink or the missile changes size, only the low byte of the address gets updated, but that's easy.

So far, I've removed coinage, added free play, and restored the PRESS BUTTON display instead of having it auto-start on a coin.
For shits and giggles, I added OOF and POW to ZAP and WAM on mine explosions, but the "random number" it's using to select isn't very good.

Going to add a 3rd digit to the scores next, but I want to get the disassembly of the original code cleaned up and checked in before I start mangling it too much.
 
During that disaster of a Bruins game last night, I found the spots where it used single bytes for hard-coded address and fixed them so the code appears to be fully relocatable now.
Some care has to be taken in hacking to make sure the sprites don't cross a page boundary, as when ships sink or the missile changes size, only the low byte of the address gets updated, but that's easy.

So far, I've removed coinage, added free play, and restored the PRESS BUTTON display instead of having it auto-start on a coin.
For shits and giggles, I added OOF and POW to ZAP and WAM on mine explosions, but the "random number" it's using to select isn't very good.

Going to add a 3rd digit to the scores next, but I want to get the disassembly of the original code cleaned up and checked in before I start mangling it too much.
Amazing!

Thanks for doing this!
 
Rewrote some of the original code to make it smaller.
Moved some variables around.
Simplified coinage to add free play.
Modified self-test to do checksums in $400 blocks instead of $200 since the code didn't actually handle 2708s
Added a 3rd digit to player score and high scores, along with all of the necessary changes to extended time / score compare / mine count routines.

...and it fits in the original 4k with 57 bytes to spare.

1730748634865.png
 
Rewrote some of the original code to make it smaller.
Moved some variables around.
Simplified coinage to add free play.
Modified self-test to do checksums in $400 blocks instead of $200 since the code didn't actually handle 2708s
Added a 3rd digit to player score and high scores, along with all of the necessary changes to extended time / score compare / mine count routines.

...and it fits in the original 4k with 57 bytes to spare.

Awesome!
 
First hack at the miss count version of the code works, but the attract mode loop gets wonky after a game is played.

I know the original code re-uses the game time timer during the end of game sequence but I didn't really look into what it was doing, so that's probably the issue.
 
Last edited:
While I'm hacking on the game, I'm going to look into changing the mine behavior as well.

I don't like how the mines get drawn in all new locations when your torpedoes reload -- would make more sense to leave the existing ones in their original locations and only draw some new mines.
I'll also look into making different rows of mines move at different speeds or in different directions to add more of a challenge.
 
While I'm hacking on the game, I'm going to look into changing the mine behavior as well.

I don't like how the mines get drawn in all new locations when your torpedoes reload -- would make more sense to leave the existing ones in their original locations and only draw some new mines.
I'll also look into making different rows of mines move at different speeds or in different directions to add more of a challenge.
That is a great idea!
 
Heh -- found one reason why they rewrite the sprite locations from scratch every reload.

It's not really noticeable during gameplay, but when the mines scroll off the right side of the screen and reappear on the left, they naturally move down one row since that's how the addressing works.
If I just let the mine positions keep updating whether they're visible or not, and just make them visible again on reload (original code only updates visible mines, hence the need to redraw), they slowly but surely fall off the bottom of the screen and mess up the text.

It'd be easy enough to check for the carry from +$1F to +$20 and subtract the line back off to keep everything in its original row, but that'd only work for the existing left-to-right scrolling mines and other speeds and/or directions would need to be special cased as well.

I'll have to play around and see what the best (and most code-efficient) way to do this is.
 
Heh -- found one reason why they rewrite the sprite locations from scratch every reload.

It's not really noticeable during gameplay, but when the mines scroll off the right side of the screen and reappear on the left, they naturally move down one row since that's how the addressing works.
If I just let the mine positions keep updating whether they're visible or not, and just make them visible again on reload (original code only updates visible mines, hence the need to redraw), they slowly but surely fall off the bottom of the screen and mess up the text.

It'd be easy enough to check for the carry from +$1F to +$20 and subtract the line back off to keep everything in its original row, but that'd only work for the existing left-to-right scrolling mines and other speeds and/or directions would need to be special cased as well.

I'll have to play around and see what the best (and most code-efficient) way to do this is.
Fascinating stuff!
 
The way that you describe the process of what you are doing is interesting since at face value it sounded quite a simple thing. I t makes you wonder what the original program was like that was developed and then the compromises that occurred to be able to shoehorn it into the limited rom space and the odd compromises in coding that occurred because of it that made it more locked down and rigid. The thing is the technology looks cheap and common now but at the time was state of the art at the time and the costs were significant to the profitability to the company and the constraints of the hardware. Just think that at the time this program was written a cassette tape recorder was the commonly used to store computer programs unless you had some money to buy an expensive mini disk that stored 128k of program and data.
 
The way that you describe the process of what you are doing is interesting since at face value it sounded quite a simple thing. I t makes you wonder what the original program was like that was developed and then the compromises that occurred to be able to shoehorn it into the limited rom space and the odd compromises in coding that occurred because of it that made it more locked down and rigid. The thing is the technology looks cheap and common now but at the time was state of the art at the time and the costs were significant to the profitability to the company and the constraints of the hardware. Just think that at the time this program was written a cassette tape recorder was the commonly used to store computer programs unless you had some money to buy an expensive mini disk that stored 128k of program and data.

Interesting, some of the code appears to have been done in somewhat of a interpreted language. All of the low level stuff is done in 8080 assembly, but on top of that there's a program stack to control the actual gameplay. A lot of these changes are possible only because one of the functions (command $05) is never actually used, so I could cut out the code.

This hardware just spits out the $2400-$3FFF memory area as a bitmap, and other than the hardware shifter, there's no dedicated video hardware, so all the pixels need to be manually erased and redrawn. There's an interrupt for the middle of the screen and another for the end of the screen so to prevent tearing, objects on the top half (ships and the wave) are updated after the mid-screen interrupt, and objects (mines and torpedos) on the bottom are updated after the end of the screen.

The CPU is pretty slow and some of the graphics blocks are large, so the code only updates 1 mine per interrupt (if you use the MAME debugger and step interrupt to interrupt you can see this), so the mines actually move slower as your score goes up and the number of mines increases. They apparently intended to have a max of 10 mines, but ran out of memory so there's only 8.

Some of the code appears to have been written to be generic, as neither the ships nor the mines have a delta Y, so there's no reason to waste that byte in memory (x3 ship + 8 mines) nor spend the time updating Y when the sprites move, but the code is (somewhat) shared with the torpedo control which has no delta X, so they had to decided whether to use more memory or to have 2 versions of the code that burn more ROM space.
 
Looks like if I'm going to use mine speeds other than +/- 1, I'm going to need to change the mine graphic -- otherwise it leaves trails since the next draw doesn't fully erase the previous one.

I was planning on have the 4 rows of mines go +1, -1, +2, -2 to make things more interesting -- assuming it'll fit.

I"m quickly running out of code space.

+2:
1730988462068.png

-2:
1730988754132.png
 
Back
Top Bottom