Hacking Little Computer People on the Amiga
The LCP house. Isn't that 1980s décor just great?
This post is about how I semi-reversed engineered the Little Computer People data files to enable configuration options that the original game didn't offer. I've written and released a tool that works with LCP on the Amiga, which you can download at the end of this post. If you want to see how I got there, then read on…
Little Computer What?
In 1985 a 'game' called 'Little Computer People' was released for the main 8-bit home computer systems (and the Atari ST), and two years later, a version was also released for the Amiga. The premise of the game is that there is a small person living inside your computer, and this software allows you to monitor his activities and interact with him in limited ways. Wikipedia has a good article that is worth reading if you are unfamiliar with LCP.
Will Wright (Designer of The Sims) has said that playing LCP and talking to one of the LCPs creators (Rich Gold) helped him develop concepts for The Sims, so on that basis alone, LCP is notable in software history.
For many people at the time, LCP was a boring game. The opinion was that no one wants to watch characters live their lives on a screen for hours on end. I think it's fair to say, based on the success of The Sims franchise and the endless Reality TV that's now pumped out, that opinion was clearly wrong. Maybe LCP was just ahead of its time?
One of These Disks is Not Like the Others
On the Commodore 64 version disk version of LCP, each disk was manually (at the duplication house) updated to have a secret serial number written to a spare unused sector. This serial number was used to control aspects of that particular copy of LCP. The idea was that everyone's LCP would be different. You'd boot the game for the first time, watch your own unique LCP move into the house, and he would look and act differently to your friend's copy. As we'll find out, on the Amiga, this mostly didn't happen.
On the Amiga version (which I focus on in this post), the same idea was applied, but this time using a dedicated file in the filesystem. This file is called SN and is found in the Misc folder.
As you can guess, SN stands for 'serial number', and each copy of this file should contain a different serial number than any other copy, and this was done, like the Commodore 64 version, during the duplication process - It wasn't done on the first boot as most people thought at the time. Today, if you could find a sealed, unused copy of LCP for the Amiga and take a disk image of that floppy disk, you'd see the SN file and its unique contents. This was impressive for the era, and had it been a success, we would have seen more efforts like it. However, this is the Commodore and Amiga scene we are discussing, which had a major problem: Rampant Software Piracy.
Due to the massive Amiga piracy scene, most kids never bought any games or software; they just copied the copies that their friends had. Like software piracy today, somewhere up the chain, a cracker crew had removed the original anti-copy protection and released the cracked version of the game into the wild. Without the internet, this was mostly done via dial-up BBSs and in-person swap meets.
Thor and Elliott
The Old School Emulation Center, or TOSEC to its friends, is an ongoing project to catalogue every known published pieces of computer software for retro computers and old arcade machines. TOSEC itself is totally legal as it does not collect or publish the actual software, but there are other legally-grey initiatives that exist where you can access a TOSEC-named library of all the actual software images.
In the Amiga TOSEC index, there are these entries for LCP:
- Little Computer People (1987)(Activision)
- Little Computer People (1987)(Activision)[a2]
- Little Computer People (1987)(Activision)[a]
- Little Computer People (1987)(Activision)[b checksum error]
- Little Computer People (1987)(Activision)[cr ECA]
- Little Computer People (1987)(Activision)[f AGA HF]
- Little Computer People (1987)(Activision)[h Drifter]
Which we can assume are the copies that were in circulation during the late 1980s and early 1990s.
Each of these is (in theory) a slightly different version of LCP. I booted up copies of each and noted down the differences. I will refer to each version via its suffix letter in the square brackets or 'NoSuffix' for the copy without one.
It's useful to know, at this point, that there were two versions of LCP published – the original copy-protected release and the later 'budget' release that had no copy protection. The budget release also forgoes the random value in the SN file, settling for a single value, thus removing any chance of a unique LCP for the player.
Let's look at a table of the differences in each copy:
Disk Image of Unused Copy
LCP has already moved in.
LCP has already moved in.
Same as [a2]. TOSEC naming convention uses suffix 'b' as 'bad copy'.
Same as [a]. TOSEC naming convention uses suffix 'cr' as 'cracked copy'.
Same as [a2].
LCP has already moved in.
What's critical here is that only the 'NoSuffix' is a copy of an unused disk. So, if you got this copy during an X-Copy swap meet, you would have been in luck. Even though your LCP (called Tucker) would not have been unique, at least you got to see him move in. If you want to play LCP in its untouched form, go for this copy.
For all the other variants, though, the LCP had already moved in, and there was NO documented way to either kick him out or reset the game. Anecdotally, via internet searches, it seems that most people with a copy of LCP back in the day had 'Thor', which means variant [a]/[cr] was probably the most common copy in circulation.
Who is The Cool Dude?
So how does the value in the SN file affect what your LCP looks like and what name he gets? Using a complex system of analysis (which means I fiddled with the value many, many times and booted the game repeatedly), I have determined how the value is used.
Although it looks like the value can be up to 8 random numbers (see the above table), my findings are that only the first three are important:
The first digit controls the type of LCP (and his dog) that you get:
- 0 or 5 - Older Balding Man
- 1 or 6 - The Cool Dude
- 2 or 7 - Middle Aged Man with a Moustache
- 3 or 8 - Young Guy
- 4 or 9 - Baseball Cap Guy
- 0 to 2 - Dark Brown Dog
- 3 to 5 - Light Brown Dog
- 6 to 9 - Grey Dog
(So, a first digit of '3' gave you a Young Guy, with a Light Brown Dog)
The second digit controls his hair colour:
- 0 or 5 - Dark Brown
- 1 or 6 - Blonde
- 2 or 7 - Light Brown
- 3 or 8 - Mid-Brown
- 4 or 9 - Redhead
The third digit, along with the 1st and 2nd digits, are used to select his name:
- There is a Names file in the Misc folder, which contains 256 male names. The modulo of the first three digits in the SN value divided by 256, plus 1, is used as a lookup number in the Names file, and the name on that line is picked. For example, in variant [a2], the first three digits are 321. So (321 MOD 256) +1 = 66 = Elliott.
Of all the LCP types, The Cool Dude was new to me. I'm guessing most people haven't seen him, either.
Some of the LCPs and their dogs
Welcome to your New House
Now that we know how to control what our LCP looks like and what his name is. Let's move on to how we reset the game so that he performs the 'move-in routine' as described in the LCP Manual. As we've established, this happens only once, during the first boot of the game, and is written to the disk somewhere. After that, whenever you start the game, he's already moved in and living there quite happily.
On every copy of LCP, there is the Brain file (also in the Misc folder), a blob of 200 bytes of binary information that changes every time the LCP does a specific action that triggers a 'save-point'.
As the 'NoSuffix' LCP has yet to move into the house, his Brain file must have a flag set or unset different from the other Brain files on the other copies. However, a cursory look at these brain files showed many different values across most of the 200 bytes.
The first method I tried was to zero all the bytes in the Brain file. I tried this method based on a quote from David Crane (one of LCPs creators). However, I think he was just guessing, as this caused the LCP to be already moved in but very sick (the LCP had turned green and quickly just went to bed). So this attempt was abandoned.
The next method I attempted was to use an existing Brian file and slowly change each non-zero byte to 0x00 or 0xFF (depending on if the original value was lesser or greater than 0x80) and then boot the game to see what had changed. Obviously doing this on a floppy disk, or even an ADF image, would be very slow.
To speed things up a bit, I used WinUAE set up as an Amiga 500 with a fake SCSI hard disk. I used WinUAE's ability to map an Amiga hard disk to a Windows folder structure. This gave me the option of monitoring the Brain file changes in real-time. It also allowed me to easily change the byte values and reboot back into the game quickly. As LCP doesn't like Fast RAM or being run from Workbench, I modified the Startup-Sequence to mimic exactly what the original LCP floppy disk does on boot, which is kill any Fast RAM by running NOFASTMEM and then booting the main LCP program, which is called 'pet'.
The Amiga is technically a 32-bit machine, so it's fair to assume that the values in the Brain file are long integers, which is borne out by the data layout in the first half of the file. I nonetheless just focused on changing bytes unless the byte was on an odd offset.
After a lot of reboots, I'd mapped several areas of the Brain file:
Health – Food? 0x00 = Sick, 0xFE = Fully Healthy
Illness Flag: 0x00 = Sick, 0x14 = Healthy
Health – Water? 0x00 = Sick, 0xFF = Fully Healthy
Move-In Flag: 0x7A, then after move-in sequence, 0x00.
Water Bottle Level: 0x00 = Empty, 0x0F = Full
Cupboard Food: 0x00 = none, 0x15 = all
Trigger 'door save' on restart: 0x00=do door save, 0x01 = door save complete.
Unknown, never changes: 0x3E
Unknown, never changes: 0x30
Unknown, always resets back to 0x2C11
Zeroing doesn't affect a load but seems to trigger a 'toilet save'
Zeroing doesn't affect a load.
A lot of Unknowns there, but we've found out some key things:
- How to restock the food and water – Although you can do this in the game by pressing Ctrl+F and Ctrl-W, respectively - so limited use.
- How to make a sick LCP feel healthy again – Very useful as it can be difficult (almost impossible actually) to cure a sick LCP 'in the game'.
- How to trigger the move-in sequence – This is what we were looking for! This, plus the knowledge we gained from looking at the SN file, means anyone can now enjoy LCP as if they bought their own personal copy.
Also, the range x58 to xC8 changes quite a lot on every save event, there is a pattern to the data layout, but my assumption was that this data is a set of personality indicators, including how happy the LCP is and how he behaves, plus his preferred activities. Zeroing all the bytes in this range seems to have no adverse effects, and the first save event (after the move in sequence) overwrites the values with a set of standard 'starting' values. So, this seems to be a good way to reset an LCPs personality. Although, without decompiling the game back to the original source code, I can't see how we would know for sure, though.
The Little Computer People Management Tool
Knowing this information is all well and good, but who can be bothered to edit these files if they want to try out a new LCP or fix their current one? I'm guessing hardly anyone (other than me, of course!). So, the obvious next thing to do is to write a tool to do it for you.
I've never written C code for the Amiga before, and I'm not very good at C code in general, but I thought that this would be a good way to improve my C skills and also give back to the retro community in my own small way.
Using Lattice C v5.0, plus the Lattice Screen Editor, and Workbench 1.3, I wrote The Little Computer People Management Tool, which you can download below (I will also put it on Aminet). Although I used WinUAE instead of a real Amiga (mainly for logistical reasons), all the development was done within AmigaOS 1.3, as if it was nineteen-eighty-something and not the year 2023 – I know, I'm nuts, but at least I can now say I've done it.
Little Computer People Management Tool for the Amiga
The tool offers three options you can apply to your copy of LCP (see picture). I also managed to squeeze a copy of the original LCP manual onto the disk as well – as that's worth reading too. The disk image below is based on the TOSEC [a2] variant, which means the version of the 'pet' executable has no copy protection applied and was not cracked in any way. I had to remove a few non-game related files (redundant .info files mainly) to make room for the tool and the manual, but beyond that, all the original game files are there, untouched. The tool loads when you boot the disk, and you can then just load LCP as normal or apply one of the modification options first.
You download my modified ADF of Little Computer People for the Amiga or just the tool on its own (which includes my awful source code as well).
- NewLCPv1.ADF - The ADF image of Little Computer People with my Management Tool added.
- NewLCPv1.zip - The ADF image of Little Computer People with my Management Tool added but as a Zip file.
- ModifyLCPToolSrc.zip - The Tool on its own, along with the source code.
If you found this interesting or have any comments you'd like to share, I'd love to hear about it either via Twitter, or via email (you can see my email address in the screenshot above).