A highly innovative first-person RPG. You've been abducted and placed in the alien sandbox known as Xebec's Demise, where you have GTA-like freedom of action. How insanely detailed was this game? One player reported that after several years, his character unexpectedly developed scurvy from never having eaten fruit products.

Shipped on two 400K disks. Runs on the 512K, Plus, and probably little else. "It did not use the Mac GUI toolbox [...] This is the only commercial program of any kind that I know of, which actually took that route."

Compatibility
Architecture: 68k

Comments

Yoyomacs hack does indeed let you get into the city, unfortunately it remains unplayable because you are immediately attacked over and over again until you die. You cannot do anything other than maybe trick the first few enemies, but they just keep coming. You can't even move. So if anyone has an idea for that, that'd be great.

A hacked image as described below works partially in MESS (512ke driver). It's possibly to play with a temporary character. Trying to start a proper new one requires a character disk, which I'm unable to format within the emulator.

Here's the idea. Based on my post from Nov 14 I wanted to find the location on disk of the loop I identified in RAM that checks against the floppy being an original. Skipping this loop during execution in RAM allows to start the game. Sounded easy in principle...
First thing was to create a resource fork of type CODE in ResEdit so I could copy from an hex editor the content of the file named Data on Disk 1 and visualize whatever straight assembly code is in there with Code Editor.
No chance identifying the RAM loop in Code Editor as apparently the code self-modified after loading. I managed to find in RAM the sequence where this happened. Fortunately the operation is done in place by applying an XOR filter on the hex data loaded from the disk. Checking the code before and after the filter allowed me to locate the loop on disk. Now the filter was not too hard to defeat since XOR * XOR = identity. That is, the changes in the assembly code in order to skip the loop just needed to be XOR'ed by the same filter to get the hex data that should go on disk. I thought I was done.
Upon loading, now the disk would eject after the musical intro with a message saying "Insert Alternate Reality Disk 1" that I didn't get before. Apparently my hack disturbed a checksum being performed on the disk. Next was to find where the test on the checksum was being done. Thanks to CodeEditor this time I could find fairly easily where this took place, as the assembly sequence was not self-modifying and so appeared 'in clear' as loaded from the disk. It was just a question of slipping a NOP instruction at the right place. I thought I was done.
The game now would start fine, I could create my characters and start roaming the City. Except that any Inn I'd walk in would tell me "We don't serve your kind here" and would kick me out instead of showing the regular menu of options. Somehow the game "knew" that I got there with a hack?!
I had to think a bit about how to handle this one. I feared I was going ahead of a chain of self-checking checksum tests so that if I modify one single byte upstream and bypass the first checksum I'd have to track it all over the memory. Then I could confirm that the unwelcome message didn't come from my mods to skip the initial loop but from the mod bypassing the checksum on the former. Also the loop is executed between the first checksum (spitting the disk as a result) and the second checksum. The solution was then to introduce in the loop code to restore in memory the original instruction testing the first checksum, in a way cleaning up after myself so the next checksum won't notice anything. Also since I was skipping a whole loop I had enough room to add new code. Last thing was to reapply the XOR filter to get the right hex data to disk. And it worked... so far at least.

In doing so I had to hardcode a memory location so I hope the hack will work on Macs with different RAM/ROM configurations.

Alright, thanks to a long and rainy Thanksgiving weekend I had time to find a permanent crack. The game now plays fine straight off of the floppies on a physical Mac Plus. First make copies of the disk images from this website to physical floppies. Next, you'll need some utility software to edit the sectors of the floppy such as FEdit and edit Disk 1 as follows.

Another useful tool is either Resedit 2.3.1 with the CODE editor, or Resorcerer. Resorcerer is quite powerful in itself (but don't look for it here, as it's still sold). These allow code analysis when the software is not running.

Glad to see there's some interest. Here're some details. Let me give a few extra info to make sure the process can be repeated independently. I'm using a Mac Plus with 4MB RAM. You want to make a copy of the disk images from this site to a physical floppy, DiskCopy 4.2 works great as it'll copy the invisible files as well. Next, install MacsBug 6.2.2 ('MacsBug for the 68000 family' on macgui.com) on the floppy disk called 'Alternate Reality' (i.e. the first disk). Boot up with the disk. Wait for the title screen, wait for the musical animation to start, press escape/tilde (just to skip this part), right then when you hear the floppy activity press the programmer key and you'll land into the debugger. I'm assuming the reader has some familiarity with MacsBug, if not I can give more details. At this point you'll likely be some place in ROM around addr $401xxx. Check that addr $D130 is a return instruction: il $d130 should show RTS, this is the end of the routine managing disk access throughout the game. Insert a breakpoint at this addr: br $d130 and resume execution:g. Next you'll fall back in the debugger at $D130. At this point the latest code will have been loaded in memory. Check that the dialog strings are in memory: dm $1FC20 should return the fragment 'Please use', you're on the right track. Next, insert a breakpoint at: br $1F098 and resume execution:g. At this point thee screen should get cleared (blacked out). My understanding is the section between $1F098 and $1F0BC determines whether the disk is an original. The trick is to bypass this section entirely. When you are at $1F098, set the program counter (pc, addr of next instruction to execute) to: pc=$1F0BE and resume execution:g. You should now see a menu offering to create a character. That's it, you're in the game from there on.

Hello yoyomac,
I am very interested that you explain your hack details in another post, because I had some progress in cracking the game with my skills. Maybe we could together come to a full crack ! Gaël.

For anyone interested I managed to hack my way through and get a game started. This is quite tricky. You'll need a physical Mac and a copy of MacsBug on the same (physical) floppy you boot and start the game with. Here's the twist. The code on the disk is 'scrambled', the game loads segments of data on the go and applies bit masks that turn the data into executable code in memory. So there's no resource that can be read off the disk and produce sensible code in ResEdit with CodeEditor. The code has to be hacked as it appears live in memory. I found a way to interrupt the game, fall into MacsBug at the right time and bypass the execution of the loop that tests for the original disk. Next thing you know, you can create a character and start walking the City! I haven't played very long so far and so can't tell if the game is fully functional, I suspect the might be several layers of protection. However my process is repeatable, it just takes a couple minutes to get started. I can provide the details (addresses in memory, etc) in another post if interested.

The game is incompatible with all versions of Mini-vMac, but I was able to 'burn' the disk images to floppies and launch the game on a physical Mac. Unfortunately, after the opening cutscene and theme song it asked for an authentic master disk. This one is going to take some hacking - and given the unusual programming it employed, I'm not optimistic.

I don't know more than you about these things, Carl, but I think it's an incompatibility problem. Back when this game was released, Mac OS was called simply Mac System Software and was yet to reach version 1.0. I don't think System 6 is backwards compatible with it. I also don't think Mini vMac can emulate such an old system, and I don't know if there's another emulator that can.

Still, I'm impressed with your finding. Alternative Reality is a milestone in gaming history. I know there was an Apple II version, which I've never seen, but not a Mac version. Wow...

☃Disclaimer: Macintosh Garden does not claim rights to any software on the site. To the best of our knowledge, these titles have been discontinued by their publishers. If you know otherwise, please contact us and we will remove them accordingly. Thank you for your attention.