Shamus fixed for XL/XEs with title music?

[+slx]

As mentioned in one of the ANTIC podcast interviews, Shamus, like most of the earlier Synapse titles had a "bug" in the title screen music player that would lock them up on XLs unless you hold the START key while booting, thus bypassing the title.

 

There are lots of fixed versions for XL/XEs around but all those I have found so far seem to just bypass the title screen.

 

Is anyone aware of a version of Shamus that works on XL/XEs AND has the title screen and music?

 

 

[+CharlieChaplin]

Homesoft fixed most (if not all) of the 400/800 only games to work correct on XL/XE computers, including Shamus (and its title + title music)...

 

http://www.mushca.com/f/atari/index.php?dl=014|SHAMAMUS

Edited July 21, 2017 by CharlieChaplin

[Wrathchild]

Gosh, it was back in 2003 that we had a spate of patching up some titles for the XL

[+slx]

Thanks!

 

 

Gesendet von iPhone mit Tapatalk

[+slx]

Again, thanks to both of you for pointing me the right way and thanks to Wrathchild for fixing this. Apparently I did not look that far back when searching AA for "Shamus".

 

Both versions work perfectly.

 

I think I have located all the map data for the Atari version and will now dig into the C64 version to locate it there with the goal to port the additional C64 levels to the Atari. The C64 seems to store map data in a different way because simply searching for the Atari map data does not yield any hits.

 

I have some hope that the map system is at least compatible because the "new" C64 mazes don't seem to use any features that the Atari does not have.

[+slx]

Now if someone tells me that has also been done 15 years ago already, I'll stop

[Wrathchild]

... with the goal to port the additional C64 levels to the Atari.

 

A worthy cause Good luck!

[+slx]

 

A worthy cause Good luck!

 

And a formidable task given the rather limited C64 knowledge I have so far....

[+slx]

After a bit of fiddling around with various Mac C64 emulators combined usage of VICE and C64 Debugger have led me to the discovery of all five maps (Classic + 4 new maps) in the C64 code. All map data for the map selected on the menu screen is copied into a fixed location ($7000 to $717F) when a new game is started.

 

As suspected the C64 maps seem to be of equal length (384 bytes) with each room in the game defined by three bytes 128 bytes apart but they are coded differently. Partly it's just shifted and reversed bits but so far I've only covered about 6 bits out of 24....

[kiwilove]

I don't know what the story is - if anyone has completed Shamus and published maps for it? I only know that I do have maps drawn out by someone who had completed it - way back in the early/mid 80s' - and still have them - stored somewhere.

 

It is not an easy game to go through - and I was not hooked on it enough to survive past the second level. You had to be one excellent joystick jockey to reach the end of the game - plus have a lot of patience to do so. Witnessing someone complete the game - convinced me it was possible to do so - but I'll take a guess - maybe no one has? Who did not cheat?

 

Harvey

[Rybags]

Mapi.a8.info doesn't have it, but I'm just about sure I've seen a Shamus map set. It wouldn't be hard to compile.

 

I used to play through multiple times fairly easily, once you have the technique it can be an easy game. The overall map layout isn't all that complex.

I've not looked at the C64 code but really, reverse engineering the map layout shouldn't need machine specific knowledge.

 

Have to say though, it would be great to have those extra maps - even better might be a level editor.

[+slx]

I don't know what the story is - if anyone has completed Shamus and published maps for it? I only know that I do have maps drawn out by someone who had completed it - way back in the early/mid 80s' - and still have them - stored somewhere.

 

It is not an easy game to go through - and I was not hooked on it enough to survive past the second level. You had to be one excellent joystick jockey to reach the end of the game - plus have a lot of patience to do so. Witnessing someone complete the game - convinced me it was possible to do so - but I'll take a guess - maybe no one has? Who did not cheat?

 

 

Simple Shamus maps for the Original Maze are available here. The maze was not that hard to learn, especially as you needed numerous runs to dodge all the bullets and kill the baddies. At the height of my prowess I managed to complete the game two times in a row and then lasted to the second (blue) level. As for technique IMHO it's best to shoot while standing still by holding the button and then moving the stick. For me a "twitch reaction" joystick with minimal throw was essential. I could not imagine coming this far with even a Competition Pro, let alone a Wico. My stick of choice for Shamus was and is the Suncom TAC-2.

 

I would not have known how to cheat as i did not have any freezer/monitor hardware that would have allowed me to look for live counters or collision detection.

[+slx]

I used to play through multiple times fairly easily, once you have the technique it can be an easy game. The overall map layout isn't all that complex.

I've not looked at the C64 code but really, reverse engineering the map layout shouldn't need machine specific knowledge.

 

Have to say though, it would be great to have those extra maps - even better might be a level editor.

A level editor for the Atari should be doable, the Atari coding I have deciphered so far is not that complicated. As for the C64 I am now systematically changing bits in the map section and then check for effects. As long as these are direct I will eventually come up with a map "translation" but if interpretation of one byte is influenced by another it will get complicated with 18 bits still unaccounted for.

[Rybags]

Fairly sure the delay until appearance of the Shadow is variable... so it might be part of the definition. Or maybe just based on default # of enemies in the room.

[+slx]

Fairly sure the delay until appearance of the Shadow is variable... so it might be part of the definition. Or maybe just based on default # of enemies in the room.

I'm not even sure about the number of baddies coding. It seems to be based on one nybble of the third map byte and only define a range of enemies as there are always some even if it is zeroed. I remember that there was maybe one corridor room in the game that never had an enemy. Need to find that and check the coding. I will try timing the Shadow.

 

Got a bit further on the Commodore which indeed uses trickier coding than the Atari, combining bits from two map bytes to determine whether a room has a key or a keyhole...

[Rybags]

It's been a while but # of enemies default will increase if you leave then re-enter the room, also will be higher if the difficulty setting is higher and if you've looped through the game - I think that looping the game just increases to the next difficulty, likely that the highest difficulty will be the same on all runs through.

[+slx]

I believe I got all the C64 bits covered, but didn't find anything but maze walls, maze structure, objects and object coloring. No hint of number of enemies. Have to re-check the Atari coding if I imagined something there.... but now it's time to go to bed here.

[+slx]

I have both Atari and C64 maze structures and objects decoded and will try to write a conversion utility next.

 

On the C64 it's pretty clear what data is specific to each map as only 384 bytes are changed when the map is changed.

 

Maybe the number of enemies is somehow hard-coded as I could not find any variation in the map data between rooms with otherwise identical layout that could be enemy data.

 

The Atari seems to use 640 bytes for the map with 'lazier' coding that uses an extra byte each for objects and their colour.

 

The same is true for the level boundaries (i.e. black to blue to green to red) which might be hard-coded as well.

 

With successful conversion of a C64 map it should be possible to compare maps screen by screen in cheat mode to see if they look the same.

 

(I have tried a bit of digging through the actual game code to find out where the number of enemies comes from but disassembly analysis at that level is beyond my abilities and spare time... There's lots of strange stuff going on like code being copied somewhere else and 'arrays' being filled and emptied with no apparent further use.

 

 

Gesendet von iPhone mit Tapatalk

[Rybags]

Possibly # of enemies is calculated algorithmically depending on complexity of the room, what level, how many objects, how many times you've re-entered etc.

[+slx]

Didn't get to do much during holiday evenings (there are better things to do when on vacation ) but at least started clobbering together an Action! program to convert the mazes. In the process of doing that I found that I didn't yet know how the Atari coded "pod rooms" (the ones with the moving vertical barriers) but after some sleuthing found that out as well (it's a fixed length list that is checked whenever a new room is entered).

 

(I should have used Python as - just like in BASIC - it's much easier to find out what's going on by dumping a variable when results differ from expectations but then I wanted to do it 80's Atari style, didn't I?)

 

I am now debugging that program so don't hold your breath.

[+slx]

When checking for a pod room missing on the C64 map I found that some parts of the C64 "original" green level and a bit of the red level seem to differ from the Atari version. As this is the case with all the C64 versions I could find, the "Original" map on the C64 doesn't seem to be all original and I will need to include it as a variant.

 

Now off to debugging my Action! utility. First results are not as expected

[+slx]

Started patching Shamus to include the new levels. WUDSN is great! I can simply INS the original binary and then start patching it everywhere I need by using new ORG statements and it assembles to a running version.

 

Added a flourish to the title screen and a new display list and scrolling line for the menu to make space for displaying the map/maze in use. Rusty system knowledge is my worst obstacle and costs me hours of debugging. Wondered for hours what trickery kept changing the display list in use back to the original one until I realized that I had simply copied the last line from the original DL instead of making it point to the start of my new one :bang:

 

Now off to CONSOL code with its inverted bits to actually change the map.

[+slx]

C64 levels running successfully on Atari and I finally clobbered together a working menu to select different mazes. General maze layout seems to transfer OK but key/keyhole colours seem to need a little more tweaking. I stell need to check the mazes room by room and test whether the number of enemies feels right.

 

While testing I found that I don't yet know how the placement of the "door" in keyhole rooms works. Both the Atari and the C64 have keyhole rooms with either the left or the right exit closed until you come with the correct key and I have yet to find out where this right or left info is stored

 

 

Asked Cathryn Mataga for her blessing for a release.

 

 

[+slx]

Door bits found, back to Action! to let the converter utility know about them. Remember not to mix up logical AND/OR with bitwise &/%, otherwise spurious errors that are hard to track down will haunt you

 

Got around this but gave up finishing the converter way after midnight. I'm too old for all-night coding sessions.

 

 

Gesendet von iPhone mit Tapatalk

[+slx]

Messed around with the converter code for several hours. Checking it with during converting it found all the rooms with the door bits but the final map data just didn't look like it should and had mostly zeroes in it. Took some time until I realized that I had added the necessary bits to the C64 color value which I used as an index to a lookup table listing an Atari color value for every C64 color. Which of course means that Action! which doesn't care about array sizes happily looked up arbitrary data behind my 16-element array when I fed it $1x indices....

 

While cleaning this up I somehow managed to delete a line with an ELSEIF that didn't break the compile but killed all corridor rooms. Somehow you don't expect code you didn't edit consciously to somehow change behavior, so another hour lost to find the reason. I envy those guys who just need two afternoons to code a complete game from scratch while I need >1 month for a patch...

 

Now comparing to the C64 room by room. First result: my color table was good for NTSC but doesn't look like C64 on a PAL system.