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.
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!
*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.
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.
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.
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.
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 😂
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 😊
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.
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!
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.
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
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 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.
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!
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 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.
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
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!
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.
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.
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. :)
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!!
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 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.
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!
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?
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. 😊
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!
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.
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".
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!
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
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.
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!
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.
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
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).
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.
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…
Load the accumulator do some logical shifts left and right and off you go finding Dr Livingstone. Erasing one line that looks like a 3 byte code but actually is only 2. Amazing!
![BOWKYLION - วิงวอน (ex-change) [Official MV]](http://i.ytimg.com/vi/cLdnZWDaO-w/mqdefault.jpg)
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...)
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.
Dude, that was excellent retro archeology!
"I'm not leaving without the (Living)stone(s)!"
hehehe
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.
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!
*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.
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.
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
This was very interesting to watch. Thanks for explaining it all so simply.
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.
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.
That’s miles more sophisticated than most C64 games. Surprised I’ve never heard of it.
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 😂
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 😊
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.
Bravo Robin! Fantastic detective work.
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.
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!
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.
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
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 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.
This game looked really fun. The bug must have been really annoying though. I loved watching you play it.
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!
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.
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 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.
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
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.
Hello. I tried you fix and it works, I was able to beat the game without crashing and did a full playthrough. Thanks.
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.
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 could never play a stick and key game, but they did some pretty ahead of it’s time stuff with that!
Great video! i like that you showed the real loading time of the game from casette and read from the manual in the meanwhile.
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.
Wow! I still have no idea exactly what the issue was, but what fun going down that 🐇 🕳️ with you. Another game saved.
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.)
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. :)
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...
This was an amazing video! Such cool information to see.
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!!
Great work !! Not only find the bug but solve it and patch the game so it can be finished. Amazing.
The subtle TRON reference was my favorite part.
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
Great video! It's always fun watching your troubleshooting old software.
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.
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.
Released: 1987
Publisher: Alligata Software
Developer: OperaSoft
Coder: Jose Antonio
Graphics: Jose Antonio
Musician: Jose Antonio
Outstanding content. I really appreciate all you do for the c64 retro community!
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!
Absolutely fascinating and great detective work, loved the video :)
Great episode, Robin! I'm looking forward to the next episode.
Hello Robin!
I guess, you are our Lt. Columbo, who always find a solution.
("Just one more thing.... 😀")
Thank you for this video too!
It wasn't until the bird hauled you off that I then recalled having long ago played the game.
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?
Great work figuring this out!
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. 😊
I love these videos. Great job finding the bug,keep it up!
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!
I've never been so fascinated and so clueless as to what is being said at the same time.
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.
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".
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!
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
We pronounced it the same as 'alligator' and I never heard anyone say it differently.
Amazing video Robin :) And an absolutely great bug fix! ...after all these years we can see the rest of the game :) Cheers!
Man, your code detective skills never stop amazing me. Great instructional video.
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!
"you cant drive it hooome , with one bad byte." 😆
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.
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!
Amazing autopsy, great explained! Thank you. 😊
I had an 8 bit computer in the 80s. I love how easy to learn 6502 machine code is
I liked your little Easter egg/reference when you said "bit" and briefly showed Bit from Tron on screen. 😊
Always enjoy your breakdown of these things. :)
Fascinating. Like a nerdy detective story.
I like the way you present this. Great video!
Excellent video, thank you! Haven't seen that stuff in a lifetime, going to subscribe and go through your other videos!
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.
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
Wow I can't believe I missed this game growing up. I've played some obscure games but I would have LOVED this!
Haha excellent stuff. I understood everything since I've been programming in Assembler, and that language hasn't changed much at all over the years.
This game looks pretty good, honestly.
Also, great video. Excellent quality. +1
well done! must be very satisfying to fix a bug in a 1980s game. congrats. Hope you get it patched back onto a tape.
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).
Can’t wait to see the cracking video. :) So weird to use that word when I know you’re actually trying to correct their mistake!
Great video, as always. It makes you wonder what they sent to people when they requested the cheat code.
I am so grateful I randomly got the suggestion to watch this video.
This is fantastic!!
Did you try to get in touch with the original developers?
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.
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…
very impressive, and fun to watch! thanks for sharing!
Load the accumulator do some logical shifts left and right and off you go finding Dr Livingstone.
Erasing one line that looks like a 3 byte code but actually is only 2. Amazing!