Jump to content
IGNORED

Sabre Wulf


Asmusr

Recommended Posts

I think your analysis may be spot on, and indeed there was a discrepancy between the y cooordinate that I checked when leaving the screen at the bottom (160) and the coordinate where I placed the man after going through the screen at the top (176). I fixed the same kind on issue the other day but in the horizontal direction. So when you feel like another go at reproducing the error please try this new version or the one in Js99'er, which has also been updated now (remember to reload the page).

OK, I'll do so, just one remark... at least the last few times I got that error (before you posted the new version), I tried to leave the screen at the top, but the man wouldn't leave it with the button depressed, it would only leave it after I released the button, and then there were the rapid succession of different screens... so when it happened, I left the screen at the top, not at the bottom. Thus, I don't know if this is affected by your fix. And as I said, this error didn't appear immediately, but only after playing a few games in the same session... typically (or at least the last few times) at the start screen of a newly started game. In the first 20-30 minutes of playing in a sessions, everything went normal.

 

I saw that you are keeping some constants in the CPU RAM, I suppose for more flexibility or shorter code. Could it be that those constants eventually get overwritten by something, so they don't work as expected anymore? That would be my first guess, actually, but I couldn't see the CPU RAM contents with JS99er. Maybe there is some sort of cleanup at the time a game ends, but too much is cleaned (i.e. the memory?). Or the music player for the title screen uses some of the "constants" locations and changes them?

Link to comment
Share on other sites

OK... I think I spotted some more errors:

If you press and hold the "3" or "4" key at the title screen, the title music speeds up greatly, and the screen image gets corrupted and stays that way when you start a game afterwards.

Then... the previously reported "screen flip crash" bug still persists with the new version. I tested it both in js99er and MESS 0.146. Actually, I meant to examine it with MESS's debugger, but the game behaves even more strangely with the debugger on... I normally start a game by going up, then right until I hit a dead end, then left as long as it's possible, then down. Well, with the debugger on, after only a few screen flips, the score display disappears and the entering animation of enemies becomes mostly invisible, and after one of the next screen flips, I get invalid screens, consisting only of a stretch of funny characters. The strange thing about it is that they only display this way, but they behave normally in respect to how the player can move in them... only the scenery doesn't match up. I made another snapshot under MESS 0.146 after the crash appeared again with the debugger off, but it seems to be the same unusable snapshot that's also produced by MESS 0.135.

Edited by Kurt_Woloch
Link to comment
Share on other sites

All I can say is WOW, just blown away by this RasmusM!!! You're an incredible developer, that game looks better than most Ti games that I've seen, can't wait to check it out when I figure out how to load it in Classic99 lol.days LOL

 

Thanks, you can just choose Cartridge > Open > User in Classic99 and open SabreWulf3.bin.

 

If you like this game you should try out two of my more successful games TI Scramble and Road Hunter.

Link to comment
Share on other sites

I made another snapshot under MESS 0.146 after the crash appeared again with the debugger off, but it seems to be the same unusable snapshot that's also produced by MESS 0.135.

 

No need to try ... as I said, as I never cared about the snapshot feature (admittedly, I did not need it), none of my works on MESS consider saving state, so you don't get a useful snapshot. Sorry for that - you are the first one I know about who actually makes use of it. :)

Link to comment
Share on other sites

OK... I think I spotted some more errors:

If you press and hold the "3" or "4" key at the title screen, the title music speeds up greatly, and the screen image gets corrupted and stays that way when you start a game afterwards.

Then... the previously reported "screen flip crash" bug still persists with the new version. I tested it both in js99er and MESS 0.146. Actually, I meant to examine it with MESS's debugger, but the game behaves even more strangely with the debugger on... I normally start a game by going up, then right until I hit a dead end, then left as long as it's possible, then down. Well, with the debugger on, after only a few screen flips, the score display disappears and the entering animation of enemies becomes mostly invisible, and after one of the next screen flips, I get invalid screens, consisting only of a stretch of funny characters. The strange thing about it is that they only display this way, but they behave normally in respect to how the player can move in them... only the scenery doesn't match up. I made another snapshot under MESS 0.146 after the crash appeared again with the debugger off, but it seems to be the same unusable snapshot that's also produced by MESS 0.135.

 

Well, that one's easy to fix. I just need to skip checking 3 and 4 if a F18A is not installed.

SabreWulf-cart-1.0.4.zip

Link to comment
Share on other sites

Now I tried to debug Sabre Wulf in MESS 0.146, but with mixed results. Several troubles occur when the debugger is active... in one occasion, letters were missing from the score display right on game start, and once even the title screen was corrupted. Here's a screenshot of MESS's debugger window... it seems like in the title screen, most of the time the PC is around memory location A170-A178. But there I see some very strange code which I can't find in the source code of bank 0 where this part is supposed to come from, if I'm right... and the code is intermingled with data statements, so it doesn't even seem to be valid code! I wonder how the game is able to work at all... maybe MESS is doing something wrong in this case, only with the debugger active?

 

post-8393-0-23126200-1414609623_thumb.png

 

I then tried Classic99. I have Classic99 QI342, and sadly, the method you describe for opening the cartridge doesn't work with that version of Classic99... or would the cartridge have to be in a specific folder for this to work? Or do I need a newer version of Classic99? With my version, it acts if there's still no cartridge inserted, although I did insert it.

 

Oh, and the usual "Screen flip crash" still occurs. I got it in the usual place... from the starting screen, couldn't leave it with the fire button depressed, then when releasing it and leaving the screen, the usual sequence of multiple screens with the last one (same one as usual) crashing. In addition to that, on the starting screen there were strange occurences like animals jumping all over the place (moving 30-40 pixels per frame), and the player not turning around, but instead going backwards when facing left.

 

I still suspect that on Game Over, something gets overwritten which goes on to cause the crash on the next game. Maybe there's a subroutine stack which keeps growing or something like that... I think the moment where it gets overwritten is at the start of the delay where you can still see the sprites before the "Game over" screen appears.

Link to comment
Share on other sites

Well, I don't know. I played through the entire game yesterday in Classic99 without any crashes. And I have just played 6 consecutive games in MESS without problems. You must be doing something special that I cannot replicate.

 

attachicon.gifguardian2.png

 

I've been playing this more than any other game since release on real hardware and have yet to experience a problem.

Link to comment
Share on other sites

Now I tried to debug Sabre Wulf in MESS 0.146, but with mixed results. [...].. maybe MESS is doing something wrong in this case, only with the debugger active?

 

yes, I fixed some stuff in the later releases. The debugger did not always care about the memory-mapped devices (e.g. when VDP or GROM ports were in the memory dump area, it spoiled the address counter). As I said, please try to upgrade to 0.155, just to make sure that this is not bug that has already been fixed.

 

http://www.mamedev.org/release.html

Link to comment
Share on other sites

Well... I now played the game for at least another hour in the current version of Classic99 and got the crash again. I managed to finish the game this time... or died in the last screen because of hitting the keeper. Anyway, after that, the crash didn't appear, but then I purposely died again by hitting the enemies multiple times, and THEN, after starting the next game, the strange behavior as already described above appeared.

 

I tried hard to debug it, and I think I know what's happening...

 

I've taken some dumps in Classic99 and compared them to each other. For the sake of completeness, I also added some screenshots. I've attached two ZIP files to this post...SabreWulf_Crash_Dumps.zip

SabreWulf_Crash_1 contains the screenshots and the files created from the "Save Memory As Program" option in Classic99, while SabreWulf_Crash_Dumps contains the dumps in various stages...

 

The dumps have the following meaning:

MEMDUMP1 and VDPDUMP1 were taken during the title screen before finishing the game.

MEMDUMP2 and VDPDUMP2 were taken during the running game with everything still as normal.

MEMDUMP_BROKEN and VDPDUMP_BROKEN were taken while in the first room with the anomalies already underway (enemies jumping around, player unable to turn around etc.)

MEMDUMP_CRASHED and VDPDUMP_CRASHED were taken in the "crashed" state while the last screen got displayed.

In the other ZIP file, SABREDUMP through SABREDUMV are the memory dump saved as program by Classic99.

Strange_Code_Title is the screenshot I posted above from MESS, Screen_broken1 is the screenshot at the time the "broken" dumps were taken (note the exploding enemy in the bushes at the bottom of the screen!), and Screen_crashed is the screenshot showing the last screen that is shown by the program. Finally, Classic99_Debugger_Crashed is a shot of the debugger window itself showing some (maybe) useful information... the disassembly window, the registers and such.

 

If you look at the last "BROKEN" dump, you can see that the first constants starting at address 8330 have been overwritten... as far as I can see, they should normally be 00, 01, FF and FE, but in the broken state, they have turned to C4, 60, FF and FE. In the crashed state, even more constants has been corrupted, so 02 becomes 03. I noticed that in the subsequent dumps, the stack contains A11E multiple times, so I looked there more closely... A11E would be the instruction after the UPDSPR routine returns. However, sometimes it doesn't return, but the return address gets dropped... or it doesn't. Anyway, here's how to reproduce the error:

 

Start a game and die purposely, until you have lost all your men. This may even be in the starting screen. While doing this, watch the stack (I've done this in Classic99). When the delay before the "Game over" message appears starts, you'll notice the first word in the stack becomes A11E, and this value never goes away. As you start the next game and die the same way, you'll see the next word turning to A11E as well when the delay before the Game Over message starts. And so on... for each game ending, an element gets added to the stack. However, after a few games, the stack has grown so large that it starts overwriting the constants, and when those are wrong, the game ceases to work normally.

 

I've just seen what I think may be the error... when you've lost all your lives, the return address gets dropped after the label UPDPA8 and then NEWGME gets branched to. However, one return address to drop is not enough since the death sequence is actually part of UPDPAR which has been called by UPDSPR. So one return address gets dropped, but the other stays in the stack. If you beat the game, the label ENDGME is executed, and there, NEWGME is branched to without first dropping the return address, so you also lose at least one return address to the stack.

SabreWulf_Crash_1.zip

Edited by Kurt_Woloch
  • Like 2
Link to comment
Share on other sites

Shoot me if I'm wrong, but SabreWulf on the 4a has to have the most repeat play appeal of any game on the system, I can usually play a couple of games of Alpiner, TI invaders, Parsec etc-but I find myself having 5 or 6 games of SabreWulf at one sitting.

Just imagine how much of your life you'd lose if Rasmus converted JetPac?

 

There was a conversion for the Atari 8-bit computers in 2007 called JetBoy and it's fantastic.

 

JetPac is my all-time favourite ZX Spectrum game.

 

Here's a video of JetBoy being "played badly, so you can see what it looks like"!

https://www.youtube.com/watch?v=hialiBVI-8s

Edited by UKRetrogamer
  • Like 2
Link to comment
Share on other sites

I've just seen what I think may be the error... when you've lost all your lives, the return address gets dropped after the label UPDPA8 and then NEWGME gets branched to. However, one return address to drop is not enough since the death sequence is actually part of UPDPAR which has been called by UPDSPR. So one return address gets dropped, but the other stays in the stack. If you beat the game, the label ENDGME is executed, and there, NEWGME is branched to without first dropping the return address, so you also lose at least one return address to the stack.

 

Whoa, thanks. I will look at it tonight.

Link to comment
Share on other sites

Jetpac! Now, you just stop it! Just stop it, okay! If I get jetpac on the TI then I won't be able to go to work, and I won't be able to earn money and I won't be able to feed my family and I won't be able to pay the mortgage and my wife will leave me.

 

AND IT WILL ALL BE YOUR FAULT! !!!!

 

JUST STOP IT. SOME THINGS ARE BEST LEFT ALONE ;-)

  • Like 2
Link to comment
Share on other sites

Just imagine how much of your life you'd lose if Rasmus converted JetPac?

 

There was a conversion for the Atari 8-bit computers in 2007 called JetBoy and it's fantastic.

 

JetPac is my all-time favourite ZX Spectrum game.

 

Here's a video of JetBoy being "played badly, so you can see what it looks like"!

https://www.youtube.com/watch?v=hialiBVI-8s

 

I was just playing Jetpac on the original rubber keyed monster last weekend, it seems funny that a version for the atari machine (with 256 colours) looks less colourful than the Spectrum version, still a great game though. Another one that I was playing on the Spectrum and would love to see on the 4a is Bugaboo the flea, it's got that one more go twitch play vibe going on.

Edited by am1933
  • Like 1
Link to comment
Share on other sites

Jetpac! Now, you just stop it! Just stop it, okay! If I get jetpac on the TI then I won't be able to go to work, and I won't be able to earn money and I won't be able to feed my family and I won't be able to pay the mortgage and my wife will leave me.

 

AND IT WILL ALL BE YOUR FAULT! !!!!

 

JUST STOP IT. SOME THINGS ARE BEST LEFT ALONE ;-)

 

Hehe. Rasmus? Please consider making JetPac your next game.

 

I love JetPac so much, I even bought the Sinclair ROM pack back in the day, THEN paid nearly £50 to pick it up from eBay after I purchased a Sinclair Interface 2 a few years ago.

 

My original ROM interface [bitD] was a RAM Turbo as I wanted compatibility with other joystick protocols.

Edited by UKRetrogamer
  • Like 1
Link to comment
Share on other sites

I was just playing Jetpac on the original rubber keyed monster last weekend, it seems funny that a version for the atari machine (with 256 colours) looks less colourful than the Spectrum version

 

I think they were trying to keep the game as close to the original as possible though the addition of limited ammunition came as a surprise. I'm still undecided on whether I like this addition or not.

 

I still prefer the ZX Spectrum version. The Vic-20 version is a close second and the BBC Micro version just seems clunky by comparison.

Edited by UKRetrogamer
Link to comment
Share on other sites

 

I think they were trying to keep the game as close to the original as possible though the addition of limited ammunition came as a surprise. I'm still undecided on whether I like this addition or not.

 

I still prefer the ZX Spectrum version. The Vic-20 version is a close second and the BBC Micro version just seems clunky by comparison.

VIC20 version is surprisingly good, I bought a VIC20 starter pack with C2N, all manuals and a load of games(Jetpac was amongst them), the whole lot cost me £5 from an old market.

Link to comment
Share on other sites

 

Hehe. Rasmus? Please consider making JetPac your next game.

 

 

 

 

Just imagine how much of your life you'd lose if Rasmus converted JetPac?

 

Here's a video of JetBoy being "played badly, so you can see what it looks like"!

https://www.youtube.com/watch?v=hialiBVI-8s

 

 

 

I've never seen that game before, but it does look like one I'd spend too much of my life playing! ;)

It looks like a lot of fun!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...