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.
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.
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.
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!
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.
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.
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'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 😂
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 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.
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.
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.
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
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.
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.
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. 😊
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!
*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.
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 😊
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!
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.
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!
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
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.
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..
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 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?
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.)
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".
thinking about other "broken games" from the era... I had a game called "Karateka" by Broderbund on cassette (not disk!) for the C64 and could never get past a door after defeating the last "boss". I also saw many game reviewers in the UK had the same issue at the time. I always wondered if there was some issue with the cassette version of that game as I see many videos online (presumably with the disk version) of that same section and see no issues. Can anyone confirm either way.
Yes, Karateka has brutal multi-layer copy protection built into it, and I think it was so nefarious that it even tripped up and ruined the official cassette version! I know it was only the most talented C64 pirates that managed to create a completely de-protected version of Karateka; way beyond my abilities, I think.
@@8_Bit wow thanks Robin! I have thought about that from time to time ever since 1985... it had bothered me so much! I remember spending hours trying to thnk of every possible way to open that door yet there was nothing I could do... wonder how many other cassette versions of other games were crippled and sold unknowingly?
@@neilloughran4437 If you're interested, go to CSDb dot dk and download "Karateka +3D" by Remember in 1999. Jack Alien, one of the best cracker/fixers of all time, managed it ~14 years after the game was released. If you run the game and read to the end of the "KARATEKA DOCUMENTS" that are after the crack intro, he goes into a bit of detail about the protection, saying all told there were nine (!) ingame protections that he removed. I think there probably are many more poor cassette versions made of games; UK companies seemed to license the disk games from US companies for cassette release, but the fees didn't include the help of the original US programmers it seems!
@@8_Bit again many thanks! It had driven me bonkers! I know what you mean about US releases in UK... I know USA was mostly disk based but us folk in UK only could afford a cassette deck (and even that took me over 1 year to get - £40 is £120 today!)... the disk drive was more than the C64 itself.... I had loads of releases on US Gold that I suspect were "converted" from disk and probably had bugs... I know back in 1984 when I had no cassette deck I would either just play terrible cartridge games like Lazarian, type program listings or borrow a cassette deck for a day, then load a game and keep my C64 on for days... when I got the cassette deck for my birthday it was such a relief.. I remember taking Nightmare Park from a PET and converting it for C64 by changing all the POKE/PEEK values... felt pretty good about it :D
I live in Canada and I never seen cassette here! I had the same bug in karateka and got another diskcopy version(no crack) and I could finally see the ending screen. I love that game! Still play it once or two a year!
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.
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.
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.
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.
19:33 Probably they didn't include the pokes for C64 because they knew about the bug and did this just so people didn't actually get to the bugged part because the difficulty to get there without infinite lives, and instead asked them for the "cheat codes" so they would have responded with not only the cheat code but also a patch for the game or some pokes that fixed the bug, which they weren't able to come up with at the date of printing because of time constraints. This is just speculation on my part, but it's what I think probably happened.
I guess (or rather, I presume), the routine at $677B is outputting "SUPONCO" in the Spanish original, one character at a time, counting down from 7 to zero. The English "IPRESUME" is one character more, 8 in total, and the loop would have failed to output the last "E". So, instead of modifying the otherwise unknown contents of the counter (does this have any side effects, where is it even set? - you're not from the original developer team), they may have moved the loop to the subroutine, which was now to be called just once. Now the BNE-branch wasn't only useless, but prone to cause an infinte loop…
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!!
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.
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…
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
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
Funnily enough, when you got to the part about disassembling to track down the bug, it finally occurred to me to wonder what would happen if you started disassembling at an arbitrary byte that's not an opcode but one of its parameters. If the monitor has some way of telling them apart, or if it comes down to trial and error and you've been skipping over the error parts. And no sooner do I start to think about this than you do indeed encounter a bug that causes the monitor to get opcodes and parameters mixed up, and it's the very bug that breaks the game! So I'm guessing it's the trial and error thing.
yes, you will see very strange code if disassembled at the wrong spot. Just move the disassembly a byte or two and you should see something resembling code that actually looks like it does something.
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!
11:00 Did anybody notice that the witchdoctor's weapon sprite has a corrupted frame of animation? The cheat mode is certainly one of the more unusual examples. It reminds me of the one from Retrograde by Apex/Thalamus, which uses a similar screen buffer check.
3:25 Had to look up some stats on Novaload. '0' bits are represented by a pulse 288 clock cycles long and '1', 688 clock cycles. This gives a bit rate between 3551 and 1487 on North-American machines, coming in at 2725 bps = 340 byes/sec if we assume 60% of the bits are '0'. 9:20 Seems like they could just DEC … BPL. 9:55 Trontastic! 32:13 It could also have been $67.
Novaload is a little complicated and has some interesting stuff to prevent messing with it and pulling out files. It's easy to circumvent though when you figure out how it works. I don't expect Robin to do a video on how to do that, but it's interesting to take these things apart for some. Bleepload is probably the most challenging, more so than Cyberload is although that one is fun too.
@@ScottyBrockway Old copy protection schemes from back in the day were pretty clever. Fun to analyze what they're doing (way easier using modern tools than it was years ago).
This is one of my favourite games that I played in an Amstrad CPC as a kid. My father bought it directly from the developer's office in Madrid in Opera Square (that's why they called themselves Opera Soft) back in the 80s. Another masterpiece they developed was The Abbey of Crime (check it out if you don't know about it; try the CPC version, which is the best and originally developed version). They also made other nice games such as The Last Mission and Goody (which plays very similarly to Livingstone Supongo). This company sadly disappeared during the 90s.
I also found a byte in "Gato" that crashed it. It caused a "file not found" error on the disk drive. Digging into it I found that the capital "D" of a filename had the wrong ASCII code. C64's have two sets of ascii codes for capitals. Simply changing the byte to the other ASCII code on the disk fixed the problem. It involved finding in the 1541 RAM exactly what the filename was for the last file access. To this day I still can't remember how I was able to read the ASCII codes of that filename.
Well done. Not confusing! If you make music, 1 note can be wrong and it's still almost perfect music, and it doesn't stop. If you make graphics and put 1 pixel wrong, it's still an almost perfect picture, not a blank screen. And you still get appreciation. After all, it's almost perfect! If you code however, 1 byte or 1 character is all it takes to crash the software - and you are now faced with the wrath of all gamers and how certain they are that you are a lazy dev, or worse, incompetent - even though you delivered an almost perfect piece of software.
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!
@@pedroluisruizlopezThis is so cool! ¿Qué es "La abadía" en el inglés, por favor? Also, what platform was it made for, if not the C64?
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..
@@vlg_bcn2812 Yet another reason for me to dedicate more time to my attempts to learn español. I am intrigued at the idea of an Umberto Eco video game
If the patch goes live, you should call it "Dr. Livingston, I Resume."
Presume :)
@@SzymekCRX
I, uh, think you missed the joke...
@@Chad_Thundercock yeah, right, feeling dumb now ;)
@@SzymekCRX
Hey, that's okay. Now you can be part of the expanded lore, so everyone wins.
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 agree. Spanish games were kown for their insane difficulty.
Imagine if modern games shipped unfinished, and had to be patched just to work properly after their launch dates. Outrageous!
IKR? I'm.. SO GLAD.. we live in a more.. modern age.. where developers would _never_ do that to us. **Eyeroll**
Aliens: Colonial Marines
Yeah. Imagine that.....
On the other hand, imagine if opening a debugger and patching games yourself was still so easy today.
Truly outrageous!!
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.
Interesting. I was wondering why the two NOPs are there in the first place.
Thank you! You answered my question before I asked it. 🙂
What's surprising to me is this is a total hacker technique. I wonder why they couldn't just delete the line from the source code and reassemble.
So that explains what the code at 4011and 4012 does. Thanks
@@warmCabin source code??? What's that? (I imagine it was programmed in raw asm, sooo...)
Dude, that was excellent retro archeology!
"I'm not leaving without the (Living)stone(s)!"
hehehe
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.
So, changing it back fixed it?
@@eugenetswong Yes, they released an erratum in a later issue that described how to restore the original string.
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.
Final Fantasy 1 does that. I don't think it has any other protections, but if you change the programmer's name on the story screen, it freezes up.
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.
@@8_Bit Un-freakin-believable! You are amazing! Thank you so very much! I am now about half-way through the article. So cool
Awesome and fascinating sleuthing!
This would be an interesting episode.
@@themanontheinside So cool to find out after all these years! Are you going to re-play it now that there's a bug fix?
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.
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.
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.
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!
Amazing work. Well found. I hope the original programmer who applied the "NOP" solution gets to see this and facepalm.
and gets sacked
@@mattsan70 Well I suppose you stopped short of a public flogging. Very kind of you.
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.
This was very interesting to watch. Thanks for explaining it all so simply.
That’s miles more sophisticated than most C64 games. Surprised I’ve never heard of it.
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.
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!
Bravo Robin! Fantastic detective work.
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 😂
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 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.
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.
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.
This game looked really fun. The bug must have been really annoying though. I loved watching you play it.
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
So now I'm curious why Alligata added those NOPs in the first place!
Agreed. I wonder if there is something obvious (to Robin maybe) they were trying to do???
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 It's "Dr. Livingstone, supongo" in spanish. A spanish classic from Opera Soft.
@@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.
We pronounced it the same as 'alligator' and I never heard anyone say it differently.
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.
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. 😊
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!
*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 added a second button onto my joystick that wired to the other port and it acted like spacebar was pressed, so two buttons in1984 🤪
@@rachaelwhite4292 That's actually pretty badass, perfect for games such as _Midnight Resistance, Turrican etc._
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.
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 😊
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!
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.
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.
Nice! Pretty awesome detective work there! I have to admit I don't think this game was ever on my radar back then. I will check it out now.
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!
Unlike Blagger, in this case, the game was just published by Alligata, but not developed by them, but Opera Soft.
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
35:30 I really like that when you beat the game but still need crystals it takes you right back to where one of the remaining crystals is
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.
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..
A rather impressive breadcrumb hunt. Also, thanks you for breathing life into my memory of that time again.
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. :)
The subtle TRON reference was my favorite part.
Released: 1987
Publisher: Alligata Software
Developer: OperaSoft
Coder: Jose Antonio
Graphics: Jose Antonio
Musician: Jose Antonio
Lol, at 17:01 there's RAMI mentioned in Lemon64 comments. That's me :D My comment is from 2002, nearly 21 years ago! :O
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?
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.)
It wasn't until the bird hauled you off that I then recalled having long ago played the 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".
Hello Robin!
I guess, you are our Lt. Columbo, who always find a solution.
("Just one more thing.... 😀")
Thank you for this video too!
Fascinating. Like a nerdy detective story.
thinking about other "broken games" from the era... I had a game called "Karateka" by Broderbund on cassette (not disk!) for the C64 and could never get past a door after defeating the last "boss". I also saw many game reviewers in the UK had the same issue at the time.
I always wondered if there was some issue with the cassette version of that game as I see many videos online (presumably with the disk version) of that same section and see no issues. Can anyone confirm either way.
Yes, Karateka has brutal multi-layer copy protection built into it, and I think it was so nefarious that it even tripped up and ruined the official cassette version! I know it was only the most talented C64 pirates that managed to create a completely de-protected version of Karateka; way beyond my abilities, I think.
@@8_Bit wow thanks Robin! I have thought about that from time to time ever since 1985... it had bothered me so much! I remember spending hours trying to thnk of every possible way to open that door yet there was nothing I could do... wonder how many other cassette versions of other games were crippled and sold unknowingly?
@@neilloughran4437 If you're interested, go to CSDb dot dk and download "Karateka +3D" by Remember in 1999. Jack Alien, one of the best cracker/fixers of all time, managed it ~14 years after the game was released. If you run the game and read to the end of the "KARATEKA DOCUMENTS" that are after the crack intro, he goes into a bit of detail about the protection, saying all told there were nine (!) ingame protections that he removed.
I think there probably are many more poor cassette versions made of games; UK companies seemed to license the disk games from US companies for cassette release, but the fees didn't include the help of the original US programmers it seems!
@@8_Bit again many thanks! It had driven me bonkers! I know what you mean about US releases in UK... I know USA was mostly disk based but us folk in UK only could afford a cassette deck (and even that took me over 1 year to get - £40 is £120 today!)... the disk drive was more than the C64 itself.... I had loads of releases on US Gold that I suspect were "converted" from disk and probably had bugs...
I know back in 1984 when I had no cassette deck I would either just play terrible cartridge games like Lazarian, type program listings or borrow a cassette deck for a day, then load a game and keep my C64 on for days... when I got the cassette deck for my birthday it was such a relief.. I remember taking Nightmare Park from a PET and converting it for C64 by changing all the POKE/PEEK values... felt pretty good about it :D
I live in Canada and I never seen cassette here! I had the same bug in karateka and got another diskcopy version(no crack) and I could finally see the ending screen. I love that game! Still play it once or two a year!
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.
13:40 I love the fish's big dumb animation.
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.
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.
Kudos to Robin the Ever Searching!
Thanks Mike, much appreciated!
Super cool video! Enjoyed every minute.
Your videos are like finding a gem! Thank you very much!
Those were the days when we fiddled with a machine monitor in SpeedDOS or such like...
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?
This was an amazing video! Such cool information to see.
I wonder if this game has any relation to the similarly titled NES game "Stanley: The Search for Dr Livingston", beyond just the similar premise.
Hello. I tried you fix and it works, I was able to beat the game without crashing and did a full playthrough. Thanks.
I had an 8 bit computer in the 80s. I love how easy to learn 6502 machine code is
I could never play a stick and key game, but they did some pretty ahead of it’s time stuff with that!
Wow! I still have no idea exactly what the issue was, but what fun going down that 🐇 🕳️ with you. Another game saved.
Great video! i like that you showed the real loading time of the game from casette and read from the manual in the meanwhile.
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.
19:33 Probably they didn't include the pokes for C64 because they knew about the bug and did this just so people didn't actually get to the bugged part because the difficulty to get there without infinite lives, and instead asked them for the "cheat codes" so they would have responded with not only the cheat code but also a patch for the game or some pokes that fixed the bug, which they weren't able to come up with at the date of printing because of time constraints. This is just speculation on my part, but it's what I think probably happened.
Why were the original instructions changed into NOPs in the first place? What were they trying to patch out?
I guess (or rather, I presume), the routine at $677B is outputting "SUPONCO" in the Spanish original, one character at a time, counting down from 7 to zero. The English "IPRESUME" is one character more, 8 in total, and the loop would have failed to output the last "E". So, instead of modifying the otherwise unknown contents of the counter (does this have any side effects, where is it even set? - you're not from the original developer team), they may have moved the loop to the subroutine, which was now to be called just once. Now the BNE-branch wasn't only useless, but prone to cause an infinte loop…
And this is how I learned that I can still reverse engineer 6502 code in my head. I loved this video. Thank you for making it!
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!!
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.
Great video! It's always fun watching your troubleshooting old software.
How is that for QA testing… not one person finished the game on the english version before shipping! Great video.
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…
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.
Did you manage to get to that bridge level that crashes?
@@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
Outstanding content. I really appreciate all you do for the c64 retro community!
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
Great work figuring this out!
Great work !! Not only find the bug but solve it and patch the game so it can be finished. Amazing.
"you cant drive it hooome , with one bad byte." 😆
I hope you continue to make videos like this. Best genre ever.
I liked your little Easter egg/reference when you said "bit" and briefly showed Bit from Tron on screen. 😊
Funnily enough, when you got to the part about disassembling to track down the bug, it finally occurred to me to wonder what would happen if you started disassembling at an arbitrary byte that's not an opcode but one of its parameters. If the monitor has some way of telling them apart, or if it comes down to trial and error and you've been skipping over the error parts. And no sooner do I start to think about this than you do indeed encounter a bug that causes the monitor to get opcodes and parameters mixed up, and it's the very bug that breaks the game!
So I'm guessing it's the trial and error thing.
yes, you will see very strange code if disassembled at the wrong spot. Just move the disassembly a byte or two and you should see something resembling code that actually looks like it does something.
I've never been so fascinated and so clueless as to what is being said at the same time.
Always enjoy your breakdown of these things. :)
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!
11:00 Did anybody notice that the witchdoctor's weapon sprite has a corrupted frame of animation?
The cheat mode is certainly one of the more unusual examples. It reminds me of the one from Retrograde by Apex/Thalamus, which uses a similar screen buffer check.
I wonder if adding NovaLoad is what originally broke the C64 cheat mode, it might affect the BASIC line buffer?
3:25 Had to look up some stats on Novaload. '0' bits are represented by a pulse 288 clock cycles long and '1', 688 clock cycles. This gives a bit rate between 3551 and 1487 on North-American machines, coming in at 2725 bps = 340 byes/sec if we assume 60% of the bits are '0'.
9:20 Seems like they could just DEC … BPL.
9:55 Trontastic!
32:13 It could also have been $67.
Yes, I should have mentioned I confirmed with VICE and breakpoints from a .tap I found of the game that location $2041 is initially $66.
Novaload is a little complicated and has some interesting stuff to prevent messing with it and pulling out files. It's easy to circumvent though when you figure out how it works. I don't expect Robin to do a video on how to do that, but it's interesting to take these things apart for some. Bleepload is probably the most challenging, more so than Cyberload is although that one is fun too.
@@ScottyBrockway Old copy protection schemes from back in the day were pretty clever. Fun to analyze what they're doing (way easier using modern tools than it was years ago).
This is one of my favourite games that I played in an Amstrad CPC as a kid. My father bought it directly from the developer's office in Madrid in Opera Square (that's why they called themselves Opera Soft) back in the 80s.
Another masterpiece they developed was The Abbey of Crime (check it out if you don't know about it; try the CPC version, which is the best and originally developed version). They also made other nice games such as The Last Mission and Goody (which plays very similarly to Livingstone Supongo). This company sadly disappeared during the 90s.
Man, your code detective skills never stop amazing me. Great instructional video.
Great episode, Robin! I'm looking forward to the next episode.
Wow I can't believe I missed this game growing up. I've played some obscure games but I would have LOVED this!
I love these videos. Great job finding the bug,keep it up!
I also found a byte in "Gato" that crashed it. It caused a "file not found" error on the disk drive. Digging into it I found that the capital "D" of a filename had the wrong ASCII code. C64's have two sets of ascii codes for capitals. Simply changing the byte to the other ASCII code on the disk fixed the problem. It involved finding in the 1541 RAM exactly what the filename was for the last file access. To this day I still can't remember how I was able to read the ASCII codes of that filename.
Absolutely fascinating and great detective work, loved the video :)
Well done. Not confusing! If you make music, 1 note can be wrong and it's still almost perfect music, and it doesn't stop. If you make graphics and put 1 pixel wrong, it's still an almost perfect picture, not a blank screen. And you still get appreciation. After all, it's almost perfect!
If you code however, 1 byte or 1 character is all it takes to crash the software - and you are now faced with the wrath of all gamers and how certain they are that you are a lazy dev, or worse, incompetent - even though you delivered an almost perfect piece of software.