Awesome video Robin. I was not aware of this error in the English version. We (Opera Soft) as developers provided the binary to Aligata for UK distribution, but we didn't get any feedback and I was totally unaware that they patched (it seems incorrectly) the binary distribution. In any case, it has been very refreshing to watch this video and remember the times when we developed it in Opera. Just to point out the difficulty of the game (and in general of all Opera games): we thought that if a 15-year-old boy spends his money on a video game, he couldn't finish it in a few hours. We wanted him to enjoy it much longer and develop the skills necessary to finish the game. We know that sometimes it hasn't been very popular or very understood, but it was our intention. In summary, an excellent job and my most sincere congratulations. Pedro Ruiz, founder of Opera Soft.
Thank you Pedro, and congratulations on making this fantastic game that I have enjoyed for over 35 years now. It's too bad Alligata broke it, of course, but I see that some fixed versions of the game are now appearing online in the last week or two, so people can enjoy it in full. Of all the games you made for any platforms, which was your favourite? Do you remember if any had undiscovered secrets or bugs in them I should look into? :) Thanks!
@@8_Bit Hello Robin. Well, my most endearing game is The Last Mission, which was the first game I developed in Opera Soft. I also have very good memories of 'La abadía del crimen', which had very good reviews at the time. I think neither of the two games was distributed in the UK due to lack of a distributor. Neither were they developed for the C64, since the C64 market in Spain was not large enough to amortize the development of this version. Keep producing those amazing videos. Good luck!
Could have been "the abbey of crime" it is really a masterpiece, based on the Umberto Eco "name of the rose". As a Spanish user, I don't know if it was released in the UK - I suppose it was- and under which name. You could find it nowadays in abandonware to play it on emulators, but AFAIK in Spanish..
I don’t get the joke. Who is Dr. Livingston? (Spelled with no ‘e’). Now there could have been a great joke in just tweaking the title of the game by dropping the ‘p’ and saying “Livingstone, I resume” since Robin was able to “resume” this game after 40 years by fixing the bug. 😂
This is all part of the gameplay. To win the game, you're supposed to learn assembly and follow the stack trace. Everyone else just wasn't playing hardcore enough. ;) Great job!
I have investigated the original spanish Livinstone Supongo initialization. The wrong NOPs were there to delete a loop in which the game was waiting for the Space key to be pressed, as the spanish version included a loading screen that is not present in the english version, so as soon as the game ended loading, the game waits for it. The british version skips that routine in a wrong way, as you have discovered, it should have been two NOPs instead of three, provoking the nasty side-effects.
That reminds me of a C64 paint program, Amica Paint, which I bought on a German disk magazine (64'er) back in 1990. It was extremely buggy. Drawing lines caused random pixels to be scattered across the screen. It was essentially unusable. Years later I learned why: Someone had changed the copyright text for the rerelease and inadvertently screwed up a checksum which caused the program to misbehave as if it had been cracked.
Interesting. I spent hours translating it in English by replacing text with an hex editor (cramming English text and abbreviation on German text) and it still worked. I guess the checks were only on the copyright string.
@@bufordmaddogtannen it was a popular thing back then because cracks loved to swap the copyright (which was displayed on the title screen and thus very visible) with their scene names. Fun Fact: the Gameboy's nintendo logo bootscreen is actually a checksum as well. it reads the logo's bitmap from the cartridge (displayed on the screen) and compares it to a baked in one.
Sir, if you have the time and would like to investigate, there is something that has been bugging me since I was 11. (I am in my mid 40s now!) It is regarding a little known title called "Die! Alien Slime". A very tough game with a very big map which I drew out on taped together sheets of paper! Anyways, the game promised some sort of finale or secret at the end when you got into an elevator. Thing is, when you got into the elevator, the screen would just go black. As a kid I tried several times with the same result. I tried reaching out to the original developer over FB a few years ago, but he never got back to me :( I am just dead curious to have the mystery resolved. Does it crash at the end or is there simply no end and the dev (or at least the literature that came with the game) tell a porky-pie? NB-The themetune for the game rocks. Thanks and awesome channel!
You're in for a treat: the original programmer of that game wrote a huge article all about that bug and his eventually successful attempts to fix it many years later. Search online for "Die! Alien Slime - A Misunderstood Epic... with a bit of a problem" and have a good read.
This game is a true classic in Spain. And, as always, a VERY difficult game. In its day they coded it with a Phillips PMDS for the Amstrad initially, being later ported to Spectrum, MSX 2 (one of the few European MSX titles that is not a direct port from Spectrum), Commodore 64, PC, and even the Atari ST. The z80 version was made by themselves and the C64 version was outsourced to a specialized freenlace programmer. The c64 version probably does not share the original z80 code at all.
They probably facepalmed back then after the copies were printed and that's why the cheat code wasn't included in the manual, so people asked for it and they'd provide the cheat and the bugfix as well.
You are a certifiable GENIUS! I've done my share of searching for one missing byte (an RTS), and it is pains-takingly painful. Of course, the FEELING when you get it right is the whole reason for coding!
With regard to the insert, everything I saw in those days of printing presses meant that they would have to do front and back printing in separate passes. And since adjusting the machines is the expensive part of the print run, it could be that they ran the inside print for all the various platforms first in one huge batch and then flipped them and printed how many they needed for each platform individually in full-colour. Could save quite a bit of money that way.
Excellent detective work, Robin! I love when you dive into the ML behind these old games and identify how these things work (or do not work, in this case). Makes me nostalgic for the days I'd take Supemon to a Compute!'s Gazette program that wasn't working to figure out where me and my friends had screwed up our data entry. Awesome vid as always.
I was just checking out the C64 Scene releases and came across a couple of recent cracks of this game (I saw it on the site after I saw this originally) with your fixes in place (with thanks to you). Cool stuff.
I'm curious what the $414E subroutine does. Because the bug not only messes up the initial game state, but also prevents this one subroutine from running at start-up at all. Additionally, I think the accidentally executed LSR could discard the LSB. Is the original value really #$66, or perhaps #$67?
Wondered the same thing regarding the least-significant bit being discarded on a right shift, so I'm glad someone else mentioned it! Would be interesting to know what that area of memory actually does.
Thanks for explaining the load"":opera trick, must keep that one in mind. But very cool to see you fix the bug (and explaining it so well) to make this game finally work again. Interesting stuff.
I've seen root cause investigations of the Pac-Man kill screen (level 256). Toru Iwatami admitted that they never tested game play all the way up to level 256, because in their test groups, people quickly got bored of the game once they hit the point where the ghosts completely ignored the power pellets. The only people who ended up caring about the kill screen were the ones who were trying to set world records 😂
This is wonderful. That has got to be very satisfying as an adult to be able to understand what's going on under the hood. This was a really neat video, thank you for posting this. I love videos that dive into assembly and what's going on at the byte level.
Thanks, this was super interesting! I love how variable instruction length, which I always found a bit confusing actually led to real world problems. Makes me feel better about myself
The pole vault mechanic actually seems pretty interesting. I guess Mario's long jump would be an evolution of it, requiring split second aiming instead of manually adjusting your power and potentially overthinking it. Good job finding that bug, though!
I was born in zambia and moved to the uk in 1980, I got the game and t shirt "because" but i was so young i didnt understand the game, sadly no longer have any. thankyou for the memory
Excellent diagnosis. Kinda funny how it was found indirectly while hunting for a cheat code. I did a full disassembly of Super Mario Bros 3, so me and 6502 assembler are very good friends haha... 6502s are from that fun old age before all the memory protection and whatnot we take for granted now. Something goes wrong during 6502 execution and it just dutifully jumps off the cliff and keeps right on going.
Good job Inspector Robin! While I neither played this game nor had a C64, your diagnosis of this bug was suspenseful and exciting. Imagine all the '80s kids thinking they had done something wrong and messing about with the game for days on end as you did, looking for a way to continue to the next level. Whoever patched the game had no idea of the consequences their momentary lapse would have. It's one thing to forget the length of an instruction. It's quite another to not even look at your work. Bad! To be fair, the patching might have been done by someone else than the original programmers. It would be very interesting to see the disassembly of the game on the other platforms. It's amusing to think that more time has passed since those postings about the bug were written, than had then passed since the game was published. The postings about the game are more "retro" now than the game itself was then. As a kid I wanted to time-travel to the future. Knowing what I know now, I would happily go back and live in the '80s or the '90s if I could, sans internet and all. You don't know what you have until it's gone. Your videos bring me back to the glory days. For a few minutes we get to relive the Golden Age of computing, and of life itself. For that I am grateful. Thanks so much Robin!
For this, we'd need to know, how and why the subroutine at $677B sets the the zero-flag. An idea: "SUPONCO" in the Spanish original is 7 characters, while the English "IPRESUME" is 8. This may have been well counting down from 7 to zero to output "SUPONCO" by one letter on each call. With the English text, it would have failed on the last character, which may have been fixed by relocating the loop to the subroutine (e.g., because you're not the original developer and under some stress and you really don't want to fuzz with unknown zero-page addresses, which may have side effects or not - and there really isn't time to test this all), rendering the BNE branch useless. (Or, rather, it may have written "IPRESUME" multiple times.)
It was common practice during testing to leave the space there if any code was altered so that it could be altered back later if whatever alterations then caused a bug. Its also possible that there was something in the next levels that Commodore or the American legal team werent happy with so the programmers had to find a quick way to remove it, or make it only viewable if the user really wanted to see it, making the conscious choice by re-entering the missing code. Its also possible that all this happened before the publishers got paranoid and added the novaload.
@@noland65 I think you meant to refer to the subroutine at $68BB. That's the one that originally would be repeatedly called until it returned with the zero flag cleared. $677B is called only once in both versions of the code.
I never knew about this bug becasue I never got rhat far. Lol. As for the Turbo crack, I cannnot wait to see your next video. Back in the day I had a collection of anti-turbos (written by my cousin) in order to copy games from friends. I would load the anti-turbo very low in the memory (calling sys689 or sys849), then load the game which would give me ready prompt at the end. And then save it with another turbo preloaded high in the memory (52709). This was how I operated until I could afford a disk drive and a utility cartridge. 😊
This is amazing stuff! Now I feel like dabbling around in assembly again thanks to you! I wonder why BEQ $400E was removed from the English version in the first place, do you know why by any chance?
It looks like the game originally would repeatedly call the subroutine at $68BB and would only proceed when that subroutine returned with the Z flag cleared, but then the game was patched to proceed regardless of the status flag returned from that subroutine. Wild guess: maybe there was an additional title screen in the Spanish version of the game, perhaps crediting the Spanish publisher, and Alligata wanted to skip past that screen, so they eliminated the delay or input wait that was responsible for holding on that screen. It would be a really low effort way to cut out an unwanted title screen, but given the apparently careless hack job they did of it, it doesn't look like they were interested in spending any time on it to do it more cleanly.
@@LazloNQ Restoring the BEQ instruction would be a good place to start. I suspect that the screen was shown by the loader used in the Spanish version and isn't present in the Novaload version, but it would be nice to see that confirmed.
My brother's first job from school was at Just Micro on Carver Street round the corner from Alligata Software in Sheffield so he may well have sold original copies of this on tape when it first came out 😊
Opera Soft made awesome games back in the day. I remember having three DOS games by them: Livingston Supongo, Goody and The Last Mission. All three consisted of a single COM file (can't be larger than 64K) and all three packed a ton of content, amazing performance and an addictive gameplay. I think they were developing for Z80/8088 CPUs with 6502 ports coming later, and maybe that's why their games were more popular in Europe, where the home computer market was dominated by Spectrums and Amstrads.
Alligata made the excellent Blagger; this game, although themed differently, still manages to get that tight well animated and integrated environment (obstacles, characters, minimalistic but right on the spot sound fx).Great game and video!
Haha the "stayed in my heart for a very long time" comment on Lemon was actually mine from back in the day. I also recently played Livingstone Supongo on my Spanish streams and well, its sequel is actually way worse than the original. But good work on actually restoring this, I never even managed to get far enough to find the crashing bridge.
*Here's a challenge:* Alter a SNES-type controller to plug into both C64 joy ports, with one port controlling the d-pad and left shoulder trigger and the other port controlling the 4 action buttons and right shoulder trigger. Then modify some games like Elite, CREATURES or even Livingstone etc to use this new feature. _Imagine the games we could have had if someone thought of this back in the day..._
I'm still waiting for the Protopad. It is basically a SNES controller with all buttons readable. For now though, there is the GenAssister, and it already works with many existing games that have awkward controls, mapping "up" (to jump) to a fire button, and the spacebar to another. Similar to your suggestion, back in the day I imagined a simple Genesis type controller, where A is fire, and B and C were mapped to POT-X and POT-Y on a single joystick port. START would have been a simultaneous UDLR press.
That was fun, and boy I still remember the hex representation of a lot of those opcode from when I was a kid. Now I wonder what that loop you didn’t restore does. My favorite accomplishment as a kid was I had a bootleg mini golf game but track 18 sectors 2 onward were blank. Sector 1 had just a few files. The game would boot into a menu but your could not load any courses. But, one of those files had the filenames of the courses and the other tracks had data on them with no files point to them. What’s more, the sector links followed the usual pattern when you save a file. So, I was able to build the missing file entries in the directory. And it worked, I could play. I was a proud teenager that day. :) (Edited bad autocorrects and bad grammar, sorry.)
You should totally make a patched copy of the binary, preferably on diskette or SD card so you can load it more quickly. If you change the LSR back to a JSR in the file, you shouldn't need to touch the $33/$66 because it will never get shifted down. Of course, if it's on disk, the `,8` means that the check for OPERA still won't work, but you could adjust the addresses in that subroutine to account for that as well. :)
As someone who is just starting to learn about reverse engineering/decompiling this was extremely interesting and inspiring. Thank you for this excellent video of the process of working through the logic of both machine and human to find the error.
As usual, fantastic work and presentation Robin! This reminds me of the infamous bug in the retail version of Ocean's "Robocop", where you can't get past a certain level (5?) unless you trigger a glitch to walk through a wall (or something like that). If you were clever enough to figure this out, the next level is completely glitched (character-wise) and difficult to proceed through. I remember paying $40 for that game with my hard-earned 1989 paper-route money, only to be stymied by a development bug 🤬! I have a personal vendetta with a bug in Sharedata's "Jeopardy!" game, where P1 has an advantage over P2, who in turn has an advantage over P3. One of these days I'll get into the monitor and figure it out. Basically, P1 can hold down their buzzer key and prevent P2 and P3 from buzzing-in; similarly P2 can do the same to P3. If you don't know this and play normally, it produces an illusion that P1 is always faster at the buzzer than everyone else, especially when two people buzz-in simultaneously. Sometime in the 90s, I had amassed quite the high score in that game, and it all went to zero when I challenged a friend of mine but sat in the P2 position. My other friend who sat in the P3 spot was so angry because he was certain he was beating us to the buzzer but rarely got a chance to answer a clue!
Ha ha ha! That buzzer story is hilarious. It is sad, too, though. I wonder how to take a snap shot of all controllers at once. Maybe setting 3 variables, 1 after the other, is fast enough.
I seem to remember Jeopardy being unfair like that back when I used to play it with my girlfriend, and my sister would sometimes play along too. You probably know this, but because of the way the C64 keyboard matrix is laid out and scanned, special care has to be taken to choose keys that can be read independently of each other for games like this. I just learned about that Robocop bug yesterday in fact, as I was compiling a list of games that have those kind of "walk through wall" glitches for a possible future video.
@@8_Bit Oh, I did not know about the limitations of the C64 keyboard matrix scan -- I'll have to review that! For reference, the keys used in the game for P1/2/3 are C=, Space and F7 respectively.
@@SteveGuidi C= and Space are on the same row so they'd be more prone to problems. Maybe the best way to fix the game would be to just not proceed to the next question until all keys were released?
so i'm from the Sheffield area where the game was published from. Orange street is basically an alley that connects West St to Portabello St and the buidlings on it are now student accommodation for the local university
Truly an epic restoration (and resurrection) of an old game. I never saw this one back in the day, but I am intrigued to play it. And now I can. Thanks! You are inspiring, dude. Keep it up!!
When I first saw the title I thought that I knew what you meant, but I had a different bug with this game. It was long ago, but somewere in the caverns there was one screen that was messed up so you could not go further. The way I fixed that was pure luck, reset the game when it started and used a sys command to start it up again. After that the messed up screen worked. And I did complete the game(without trainers). It is a very hard game.
Leisure Suit Larry: Shape up or Slip Out has a similar error. Funnily enough, there was a part in the game where the girl you wanted to bang had strapped you into a machine that gave a high colonic. There was an error in the code right at that point where the code used a semicolon instead of a colon and caused the game to crash every time. It was too uncanny to be an accident, but the devs swore it was a mistake. They even included instructions on how to fix it in the instruction manual. I suppose this was an early way to fight piracy in the day, akin to requiring the 25th word of page 12 of the instruction manual to unlock a game. This rapidly became known as the "Colon Error".
Doctor Livingston, I presume, stepping out of the jungle gloom, into the midday sun. What did you find there? Did you stand awhile and stare? Did you meet anyone? I've seen butterflies galore, I've seen people big and small, I've still not found what I'm looking for!
I ended up becoming a game developer myself and I can relate - isn't the small kid in your head doubly amazed at what present day you glimpsed from the code? Finally an answer!
Great video! Informative, entertaining, and made it exciting for people like me who don't have much knowledge of machine code but are interested in how 8-bit machines were programmed. Keep up the good work!
this reminds me a bit of the game boy game "spider man 3". My copy had a bug where you could not leave the first level.. I looked it up on youtube almost 30 years later.. still frustrated.. and you could just go right into the next area... like I had tried for multiple sets of batteries and hours of my time..
I did something similar with a cracked copy of Ultima IV for the Apple ][. I had no instructions, and the WWW was still on the back of a napkin, so I had no idea how to mix reagents to make spells. I kept using up reagents in trial-and-error mode, and all it did was put the message "Failed!" on the screen. So, I searched the floppy for that string, disassembled the code near it, and NOPed a JSR right before the loop that printed it, assuming that was the code that did the checking. When I restarted the game, every spell mix succeeded, even without reagents.
Assembly language still wrecks my brain as much as it did when I was an Amiga owning nerd in high school. Making computers do stuff by loading values into memory addresses is such a weird type of logic
I have fond memories of this game. I used to play it on my MSX computer. Glad to see that it gets some love in this video! One question though: what was the purpose of the 'beq' in the original spanish version?
A similar game-breaking glitch I remember was in the original Body Blows on the Amiga. You'd get to the boss at the end called Max and if you could defeat him (which was nigh on impossible) he'd reveal his true form of a robot. If you managed to beat the robot the game would just freeze instead of going to the conrtulations screen. I bought an original copy of the game so it wasn't due to a crack and this is something I vaguely remember reading about in a magazine months later. It was incredibly frustrating to spend hours beating a game and then have it lock and I can't find anything about it online yet I remember it well.
I recall back in 1976, after I had thrown together the kit formed Poly 88 PolyMorphic computer, something made no sense at all. I had written a program to be basically the same as the good old Asteroids game, but it refused to work. But at the same time, I was convinced that my programming was correct. All RAM chips were plugged into IC sockets on the memory board. So I wiggled each memory chip back and forth in the socket to be sure that the electrical contacts are connecting properly. That fixed it.
I grew up here in the UK with a C64 and played this game a lot :D although I was one of the lucky few that had a disk drive almost all my games were on tape as you barely saw disks here. You didn't even see disk versions of tape magazines (in shops) until about 1992/1993 - roughly the Mayhem in Monsterland era.
@@8_Bit - If I ever did then I don't remember - probably not, I wasn't very good at games as a kid - took me years to finally complete "the blues brothers" lol It was this and "Treasure Island" that always beat me :D
It may have been well for QA testing: maybe there was a known issue, which was worked around by these NOPs as a last minute fix. Being last minute, there may not have been time for another complete play-through. (Apparently, there wasn't time for a re-assembly from source. and it may have well been that everybody involved was already tired and worn out.) This suggests that the issue was noticeable right at the start of the game, and this would have been obviously fixed. Time to ship, we're just half an hour late…
Man, that brought back memories... I remember typing in two listings for Novaload removers from an English magazine. One for the Plus/4 and one for the C64. These, when started, dumped the next loaded Novaload program to disk. And if there was no program line for the start (something like "10 SYS 4000"), they also displayed the required SYS command on the screen, at the end... In our country, the cassette games were often sold very cheaply and I bought weekly new games and successfully copied them all to disc.
Yay! Good Job! When I would remove copy protection for personal use, I would typically NOP out instructions as a easy fix. Sometimes they would have self modifying code, that would put pieces in place little by little, but typically it was all in one subroutine so that was easily bypassed. One title was changing data (code) in the stack or heap and then moving the instruction pointer to that spot, the return jump brought it back to the code section. That was very clever, and probably prevented the lazy programmers from bypassing it. It could possibly be a compiler bug or a cross platform conversion bug that was overlooked. Its pretty clear they only tested the first few levels, then decided good enough to ship. I'm sure you are going to enjoy finishing one of your favorite games!
