SANGUINEHEARTS

Hi, it has been a long time since my last update.
TeenAgent has been implemented into the main trunk of ScummVM, however it is not based upon my engine, instead Vladimir approached the ScummVM team a few months back with a rather complete engine, the engine itself is very tidy and the game is in a completable state.
Congratulations are in order to Vladimir for his incredible work on the game, surpassing any progress I would have been able to make with my poor reversing and coding skills.
The project was great fun and an incredible learning experience while working on it. I would like to thank _sev, Buddha, salty_horse and jvprat for their patience with me while I was learning.
I would also like to thank john_doe for his commits for the music support, as TeenAgent used a strange and new module format for music. I have great respect for everyone who helped me learn. It will not be my last attempt.

I have recently been looking into the code used for Maniac Mansion sound effects on the Apple II.

A little history on the Apple II:
When Maniac Mansion was ported to the Apple II(around the same time as the C64 port) it was seen as a very ugly version, in comparison to the C64 version. It had some graphical issues and didnt include scrolling. Unfortunately the port also suffered in a worse way. While the C64 had the SID chip, an incredible sound chip allowing for some really interesting sound effects, the Apple II port had to make do with a REALLY basic speaker. The Apple II port used the speaker to generate some sound effects such as the character selection ‘click’. Unfortunately the speaker could only output a square wave ‘click’ when the port was addressed(using a ‘bit $C030 command) The speaker itself had not options for changing the output or frequency of the output.
This of course left games programmers with very little to play with, many of them came up with intelligent code that would call the speaker multiple times using various loops to ‘click’ their way into something vaguely audible. Maniac Mansion was no different. Lucasarts created a resource format which consisted of a collection of various bytes which told the code how it should ‘click’ the speaker.

The resource format is incredibly simple and the resource is simply read in by the code which judges how often and when it should click the speaker.

I am currently about half way through reversing the code(6502 ASM), I have converted about half of it to c++ and am planning on finishing the rest within the next few months(there isnt much, I just do not have much time with university commitments, as it is my final year any external work has to sit on the backburner until I get stuck with my university work :p)

I would like to thank Tobias for his patience with me, he has been especially helpful as he has not ever given me the answer, rather he provides ways for me to find the answer and makes sure I understand it. He has been so helpful in explaining some of the 6502 opcodes and explaining how they were used. I am greatful for his friendship and advice.

Though this code is not very complicated, I am still struggling to understand completely what it does. I am sure this will come to me.

EDIT:
I have documented all I know about the resource format on the ScummVM wiki here : http://wiki.scummvm.org/index.php/SCUMM/V0/Maniac_Mansion_Apple_II

Though this information is pretty irrelevant, since the code is what actually makes sense. The resource is simply a loop controller.

You may know of Personal Nightmare, a game by HorrorSoft released a while back in 1979.
This game was released for three systems
Dos,Amiga and Atari ST

The Amiga and Atari ST versions were released in VGA
however the DOS version never saw a VGA release and users had to make do with EGA graphics.

HorrorSoft released the game in England, USA and Germany(in English)
however nearly all the DOS releases shipped with a corrupted file namely ’72.out’
which made it impossible to complete the DOS game due to a nasty crash.

Lately Kirben from ScummVM began working on support for this game within the AGOS
engine in ScummVM. While the original source code was available parts of it were
written in assembly and needed re-writing. A couple of months ago PN support made it into the SVN trunk
and since then the game is supported fully.

ScummVM was unable to fix the crash in the DOS version of the game since the decompression code
could not handle the corrupt file. However after a long search for the fabled HorrorSoft patch
it became evident that this was lost in time. Kirben managed to make contact with Alan Bridgman
who was able to provide details of the original uncorrupted ’72.out’ file, which impressively differed by only
one byte and later that day ScummVM was fitted with a nice workaround for the crash. patching the data before decompression
but not affecting the original file.

This is great for users who want to use ScummVM to play the game( who wouldnt :p )
but I thought it might be nice for people who did not wish to use ScummVM and still ran DOS machines or DOSBox.

Kirben kindly provided me with the details allowing me to create a patch for the file.

I created a patch using the IPS patching format as it seems there are clients around for most common OS’s
this can be found here http://robertmegone.com/misc/pn/72patch.ips

This needs to be applied over the ’72.out’ file, and only if your vicarage section crashes.
Although the patched file will still work with ScummVM, I state here that the patch is ONLY designed so that
users can play through the game under DOS/DOSBox.

However if you do not wish to patch the file using this method you can follow the following instructions, using a hex editor
to manually change the single byte.

Change the byte at position 53714(D1D2) from 0x20 to 0x40.

A while ago I found my old copy of Are You Afraid of the Dark: The Tale of Orpheo’s Curse.
and found some notes I made on it last year.

It turned out that this game had fmv(stored in umv) files, and after contacting Multimedia Mike,
I was lucky enough to have him post a blog post about it over at http://multimedia.cx/eggs/orpheos-umv-format/

and even created a wiki page for the format
http://wiki.multimedia.cx/index.php?title=UMV

Now I was reading the comments and noticed that someone had actually taken a look at it, but wanted to know what the videos looked like originally
so I captured one, the actual video(umv) starts at 0:20

So this is a little thank you to the person who started looking at the format, and Mike for making the effort to post the article in the first place.

Today Kirben committed a fix for Personal Nightmare PC. This works by patching the compressed 72.out file.
Support was dropped for the uncompressed version, since it should never be needed.

Interestingly enough a couple of the sprites still seem a little weird, namely the kitchen(bottles) and the lounge(fruit bowl).

But this is how the game was released.

It was fun to play around with this game but thankfully I dont need to any longer 😀

Many thanks to Alan Bridgman and Kirben for ‘fixing’ personal nightmare for the masses 😀

It seems that the fix for personal nightmare stopped the game crashing,
however there appear to be a number of sprites which still seem corrupted.

This can be seen in the following shots:

(Editor’s note: unfortunately, the images that were included here is lost and not available on archive.org)

If no patch turns up then I’ll see about looking at each sprite in the file, but that wont be until after my exams.

Hello Scummers!
I apologise if this post is of no interest to you, but It pleased me and I thought I should tell you all about it :p

A while ago I was made aware the Personal Nightmare (DOS) was shipped out with a corrupted ’71.out’ file, sadly this corrupted file made the game difficult to complete under DOS, and impossible under ScummVM at least without the development of an ugly hack to work around the Vicarage section.
After a couple of hours of searching it became clear that the patch Horrorsoft was rumoured to have developed didnt exist in any form on the internet.
After speaking with Kirben I learned that he was in contact with the developers of the game and was awaiting responses from Alan Bridgman to see whether he had an uncorrupted version of the game.
Contact was also attempted with LurkerScum from the ScummVM forums who seemed to know a little bit about the patch that was released for the game. unfortunately it turned out he was using a BugMeNot login.
Later I found out that he had a real forum account(Potent1), but still didnt recieve a response.
As a side project I spent a while looking at the files, trying to compare the atari and amiga 71.IN
files with the PC 71.out file. while it was clear there was a large similarity this was a fruitless task, they just were not similar enough.
I briefly spoke with Kirben again who informed me that the reason for the lack of similarity in the files was due to the compression and graphical differences between the games(PC is EGA, others are VGA)

I decided that it would be a good idea to look at the files again. this time I started by loading up the PC version but replacing the 71.out file with a renamed 71.in file from the Atari ST version.

sadly this didnt work, and I was soon to find out why!
I was using DosBox with the debugger enabled, this allows you to see which files are opened from the hdd, The game was choking on ’72.out’!!

after another brief search for a patch I decided to replace the PC 72.out file with a renamed 72.IN file from the ST version again.

To my delight this was quite successful, DosBox started the Vicarage section!

(Editor’s note: unfortunately, the image that was included here is lost and not available on archive.org)

This gave me some hope, but was not an ideal solution, because the PC game differs quite a bit graphically from the Amiga and ST versions, Kirben informed me that the palettes were not calculated in the same way too. I ditched this idea and sat with my fingers crossed for an official patch from the guys at AdventureSoft.

I got bored today and noticed that Kirben had just committed a patch for the uncompressed PC files. Im still yet to understand why HorrorSoft packaged the PC game with a data file decompressor, especially when the uncompressed files dont work with the interpreter.
But Im sure glad they did.

I decided to try and compare the uncompressed files, so I had to trick the unpacking tool into uncompressing the Atari ST versions ’72.IN’ file, just with a simple rename :p
I also uncompressed the PC version.

upon opening the two files in a hex editor I was able to see that the two files headers looked very similar, but that the PC version was missing a few bytes that were present in the Amiga and ST versions. I didnt think much of this but figured that I would try to patch the PC version myself.
The file header differs by 4 bytes, namely : 00 00 01 A8. I inserted those bytes into the beginning of the PC file and fired up ScummVM, being hopeful I crossed my fingers as I clicked Load

Heres an image of the result, Its the best current solution as it uses the original data, although an official patch would be better!

(Editor’s note: unfortunately, the image that was included here is lost and not available on archive.org)

It was an amazing feeling to know that I was one of the few people to see the PC DOS vicarage screen for quite a few years 😀

This sadly only works with the uncompressed version, but its the best option we have so far.
Since its only 4 bytes then it should be possible to simply patch this on the fly without bloating the code too much. It might even be possible to patch the compressed version on the fly after uncompressing.. :s
Failing that it might require someone to write code to re-compress the file.

who knows…
this is all just speculation and Im still really waiting for a patch, since this method is not completely tested!

For anybody who is interested in the Teen engine
It seems that Ive been swamped by work at university, and wont have much time to work on it until the summer, Things have become a lot easier though.
so the chances of it ever being finished have gone up significantly 🙂

Recently I made the decision to ask jvprat to join the TeenAgent engine team

due to this progress has hit full speed !

We now have full support for the game animations(jvprat) 😀

partial inventory support(jvprat) 😀

and VERY shoddy walking code(provided by me) 🙁

The code has also been refactored thanks to jvprat, things are in a much neater state.

The current state can be seen in the following video.

Overall things are looking good for Teen Agent.

Well I figured out how to implement the static sprites in TeenAgent, and it turns out that these contain many other images that are used for animations,

It allows me to now implement the Union Logic logo fully,
this can be seen here with a comparison of the original/ScummVM

This now also allows me to view all the static sprites held in ONS.RES
which appear to be used in loads of places 😀

Well, Ive located the font data.

Ive got a few thanks to make, Id like to thank salty-horse for sitting with me tirelessly working through the asm explaining things to me that I didnt understand, you’ve been a great help.
I’d also like to thank jvprat, He seemed to understand that I was getting very frustrated trying to figure out how to draw the font data, and stepped in at just the right time to save me, by both explaining ScummVM internals and possible approaches, He also finished the font code and tidied up the rest of my code.

🙂

I now present to you the first words from the Teen Agent.

Enjoy!