One Bad Byte Broke This Game: Commodore 64's "Livingstone, I Presume?"
Вставка
- Опубліковано 7 чер 2024
- "Livingstone, I Presume?" is a puzzle platform adventure that had me entranced as a kid. Unfortunately, the Commodore 64 version I played always crashed at a particular point well into the game. I thought it was a bug in my pirated copy, but later I've learned even the original store-bought version had the bug. Today we take a look at the game and the cause of the crash, and see if we can fix it and get further into the game.
To support 8-Bit Show And Tell:
Become a patron: / 8bitshowandtell
One-time donation: paypal.me/8BitShowAndTell
2nd channel: / @8-bitshowandtell247
Index:
0:00 Intro
1:48 Loading & reading the manual
4:57 Playing the game
9:00 Intermission: infinite lives patch
10:12 More gameplay
14:02 The crash & Lemon64 game reviews
17:35 Clue: No C64 Infinite lives?
19:53 Hunting for OPERA
24:06 The bad patch
27:02 Comparing with "Livingstone Supongo?"
30:05 Fixing one bad byte
32:38 Finally beyond the crashing bridge
35:57 Summary and future improvements
38:38 Thanks! - Наука та технологія
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!
@@user-tf9rm4gk7rThis 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.
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?
Dude, that was excellent retro archeology!
"I'm not leaving without the (Living)stone(s)!"
hehehe
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.
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.
I've seen root cause investigations of the Pac-Man kill screen (level 256). Toru Iwatami admitted that they never tested game play all the way up to level 256, because in their test groups, people quickly got bored of the game once they hit the point where the ghosts completely ignored the power pellets. The only people who ended up caring about the kill screen were the ones who were trying to set world records 😂
This was very interesting to watch. Thanks for explaining it all so simply.
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.
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!
That’s miles more sophisticated than most C64 games. Surprised I’ve never heard of it.
I love these videos. Great job finding the bug,keep it up!
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.
Super cool video! Enjoyed every minute.
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.
Bravo Robin! Fantastic detective work.
Great video! It's always fun watching your troubleshooting old software.
Great video! i like that you showed the real loading time of the game from casette and read from the manual in the meanwhile.
Absolutely fascinating and great detective work, loved the video :)
This was an amazing video! Such cool information to see.
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!
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!
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.
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.
Great episode, Robin! I'm looking forward to the next episode.
Excellent video, thank you! Haven't seen that stuff in a lifetime, going to subscribe and go through your other videos!
Always enjoy your breakdown of these things. :)
I like the way you present this. Great video!
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...
Amazing video Robin :) And an absolutely great bug fix! ...after all these years we can see the rest of the game :) Cheers!
Great work figuring this out!
This game looked really fun. The bug must have been really annoying though. I loved watching you play it.
Outstanding content. I really appreciate all you do for the c64 retro community!
Awesome video. Congrats on your finding. Amazing.
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 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.
Man, your code detective skills never stop amazing me. Great instructional video.
I hope you continue to make videos like this. Best genre ever.
A rather impressive breadcrumb hunt. Also, thanks you for breathing life into my memory of that time again.
Amazing autopsy, great explained! Thank you. 😊
Fantastic video!!! This game looks pretty interesting to play! I will apply your fix and have a go at this next time I focus on the C64!
very impressive, and fun to watch! thanks for sharing!
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!
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.
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!!
love all your content! thanks heaps!! :)
Great work !! Not only find the bug but solve it and patch the game so it can be finished. Amazing.
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!
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.
Great investigation, Sherlock! 👏👏
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.
Haha great, thanks for sharing & well done on that fix.
Love this Robin. Its like my day to day as a games programmer. It's amazing how deep you have to go in to work out some bugs - exhausting 😂
Yes, I've worked as a games programmer too, and know exactly what you mean :)
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. 😊
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 😊
Cool explanation and bit of history, thanks.
Wow! I still have no idea exactly what the issue was, but what fun going down that 🐇 🕳️ with you. Another game saved.
This was such a cool video! :)
Love this stuff. Thanks Robin.
This game looks pretty good, honestly.
Also, great video. Excellent quality. +1
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. :)
Superb work!
Hello. I tried you fix and it works, I was able to beat the game without crashing and did a full playthrough. Thanks.
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.
Great stuff, Robin.
Very interesting video, thanks for sharing!
Now I'm wondering what was patched out, especially the "lost" JSR. What happens when it's added back in?
Also looking forward to part 2, where you show how you were able to un-bug the cassette version :)
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
I've learned so much from your videos!
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!
The subtle TRON reference was my favorite part.
Haha the "stayed in my heart for a very long time" comment on Lemon was actually mine from back in the day.
I also recently played Livingstone Supongo on my Spanish streams and well, its sequel is actually way worse than the original. But good work on actually restoring this, I never even managed to get far enough to find the crashing bridge.
*Here's a challenge:* Alter a SNES-type controller to plug into both C64 joy ports, with one port controlling the d-pad and left shoulder trigger and the other port controlling the 4 action buttons and right shoulder trigger. Then modify some games like Elite, CREATURES or even Livingstone etc to use this new feature.
_Imagine the games we could have had if someone thought of this back in the day..._
I 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.
We pronounced it the same as 'alligator' and I never heard anyone say it differently.
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
Great video, as always. It makes you wonder what they sent to people when they requested the cheat code.
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.
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?
Great detective work! Do you know what routine they patched out from the Spanish version?
Some amazing detective work!
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
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!
Very nice detective work :)
I liked your little Easter egg/reference when you said "bit" and briefly showed Bit from Tron on screen. 😊
Nice work!
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.
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 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.
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
I could never play a stick and key game, but they did some pretty ahead of it’s time stuff with that!
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.
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".