Extracting Scrolltexts for Atari Legend

Introduction

What is this tutorial about?

This is a turotial on how to extract the majority of the scrolling messages that were included in the menu compilations of yesteryear. This is an on-going process and happens as and when I’ve got nothing else better to do :)

Once they are extracted and I’ve uploaded them into the Atari Legend database, they can all be downloaded from each group’s main page on Atari Legend as an ePub file.

Why am I doing this?

I’m a big fan of digital preservation – in all forms. ZX Spectrum tapes, C64 disks and Atari ST disks and menu compilations.

Atari Legend has one of the biggest collections of menu compilation disks out there, and there are fans / old members of each group that want to read what was written all those decades ago.

My system

Most of the time, it’s a three part system I’m using that works on 90% of the menu scrolltexts I’ve extracted so far.

Initial Steps – pick the right group

Originally, I was going to use the menus by Evil Force. They did 79 menus and the turotial would have shown you the different methods I used to extract their scrolltexts. Until I looked at their scrolltexts and found that they were using an extended multi-colour bitmap font which didn’t support numericals as you would expect. Turned out that a ‘1’ in the scrolltext would be used to display the corresponding ‘1’ graphic from the font. Instead it used a few lower case letters for digits 9 through to 5, then numbers 9 to 5 were used to cover 4 through to 0. It made the scrolltext a mess to read and work out.

Evil Force - Scrolltext replacements

h = 9
g = 8
f = 7
e = 6
d = 5
9 = 4
8 = 3
7 = 2
6 = 1
5 = 0
4 = ?
3 = ,
2 = !
1 = .

For example, in Menu 18, it showed up as “Menu 056” in the text. In other scrolltexts you will see a lot of 11111 and 333 inside. These are the characters used for punctuation marks and numerical digits. Which, whilst a pain for me to use Notepad++ to convert the wrong characters to the right ones, it would have turned into a “paint drying simulator” for everyone else.

So, let’s pick another group!

Do I censor anything before releasing it?

Yes. But very little. BBS & Phone numbers and addresses are altered. slightly. Even though these details are over 30-35 years old, it’s still not the done thing to have them out in the open. The people who lived at those addresses will have more than likely moved on, or maybe inherited it from their parents!

I leave in all of the bad language, slagging off of group x, y or z and such like. The average Atari ST menu creator (back then) ranged from teenagers through to 30 year olds (at a rough guess).

Some scroll writers were very professional, but the majority weren’t. All their blarney has been left in the text extracts. Even the stuff that would probably make the much older version of the same person be a tad embarrased. There’s a helluva lot of bragging about which girl in their school class he’d like to “meet up with”, or slagging off people that they’re now friends with decades later!

As a technical author by trade, I have to make sure I keep the texts as original as they were. Occasionally, I might insert a missing space or full stop, but it’s only to make the text legible.

Stage 0 – Get the tools ready

The following are the tools that I use. The Atari ST tools are (at least) 30 years or older, whereas WinHex is a commercial application for Windows (and hence, no download for it).

Atari ST Tools

If you’ve got a hard-drive, whether it’s a real one connected to an Atari ST/E or an emulated one under STEem or Hatari, then create a temp folder and copy the following into it.

Atari ST Tool	Used for
Naughty Depacker	Can only depack executable programs (.PRG/.TOS/.TTP)
New Depack by Mike Watson	The ultimate depacking tool for data and executable files. However, a few executable files will need some help from Naughty Depacker above.
Antic Disk Doctor	The original (and to me, the best) hex editor for the Atari ST
MonST2 (*)	Part of the HiSoft Devpac 2. I know a v3 exists, but I prefer this one.
Dec0de by Orion of The Replicants	For those executables (inc. retail games) that were packed using a protection envelope, Dec0de is the tool to get at the original program.
Hex Edit v1.1	Not a tool I’ve used, but others seem to swear by it.

Click here to download the above Atari ST Tools – Note: the files are not in a disk image, but in a single folder for use on a real, or emulated, hard-drive. I’ve not included the full version of Devpac 2, but I suggest you look over here .. ahem .. whistles innocently.

Windows Tools

The only Windows tool I use in this process is WinHex. I use it for extracting the text from unpacked .PRG files. I’ve always used WinHex – which is a commercial title, and therefore I can’t include it as a download here. There is a 30 day demo available of it on their website.

There are plenty of other hex-editors out there for mutliple versions of operating systems. Find the one you like and use it. So long as it can extract chunks out of a program, you can use it to get at the scrolltexts.

Stage 1 – Extract the PRG file

First, we need to get the file from the disk. Menu disks are 95% file-based and therefore there will be an intro / menu in the AUTO folder of the disk (or disk image) and this is where the scrolltext (if one is used) will be stored.

Some menus have a small AUTO program that, depending on a value in a low memory location, will load a particular file instead of the menu. This was done, for example, in a lot of the older POV menus. This ensured that there wasn’t any corruption created by the menu for the game it was trying to load.

However, a lot of the time, either the files are hidden on the disk (easy to recover using a simple disk editor) and more than likely, every menu is packed by one of the many, many packers that existed on the Atari ST.

If the file is hidden from viewing via GEM desktop

If you know a file is on the disk, but you can’t see it, then it was purposely hidden from view. But you can reveal it easily enough.

I use the rather ancient Disk Doctor by Antic to unhide files. There are other tools out there, but this is my preferred way of getting it done.

Load up Disk Doctor and access the disk (or disk image, if you’re using an emulator) into drive A: or B:.

The first sector displayed will be the bootsector and then, depending on how many sides/sectors in use, the next few sectors will be the FAT table and its backup.

The bit we’re most interested in is the root of the disk directory as that’s where the filenames are stored. If you know a file that is on the disk, then use the Search function to find it. You will see a display similar to the following:

Hidden files have their status set by a single byte which is stored next to the filename in the directory area.

You can see that right after the filename is a single byte. Files that are visible on disk have a value of 00, whereas hidden files have 02. By altering this byte and saving the changes, the file(s) will become visible once you have exited Disk Doctor and refreshed the disk’s display via the ESCAPE key.

You can now copy the file(s) across to your depack working area and continue with this guide.

The alternative is to copy the folder across to another disk and it should (!) also unhide the files.

Hidden file elsewhere on the disk

If you are searching for hidden files which aren’t in the root directory, you will have to find a filename that does exist and search for it. The same rules apply re: changing the byte from a 02 to a 00 and saving off the changes.

Stage 2 – Unpack the file (if necessary)

I generally use a mix of New Depack by Mike Watson and the Naughty Unpacker as a backup.

In the other situations where neither of these can handle the target .PRG file, I delve into MonST and try (badly) to find out how to unpack the file enough to get the text out :)

Here’s approximately 20 xxxx menu PRGs in their packed state:

And after I’ve ran them all (successfully) through New Depack v1.1. All of the files have been unpacked and we can now start nosying around inside them.

After completing a bulk depack of multiple files via New Depack, a REPORT.TXT file is created afterwards and this tells you which packer was used in every program/data file, and/or if it was unable to depack that particular file. These non-depacked files *that are executable* need to be fed into the Naughty Depacker one at a time.

For those executable files that Naughty Depacker can’t unpack, try running them through Dec0de. If Dec0de tells you that they aren’t using a protection envelope, then it’s a case of rolling up your sleeves and delving into MonST to unpack them. Good luck tracing through them.

Remember: Not all menu disks will contain an intro or a menu. When disk space was short, simple text intros were used instead. No graphics (or maybe a logo, at the most), probably no music and no colour changes either.

Stage 3 – Extract the text

PC Method – via WinHex

In this example I use WinHex. For years and years, I’ve always used WinHex as I do most of my work using a Windows PC and STEem. See below for an Atari ST method of extracting the text.

In this example, xxx Menu y, the scrolltext was found in the unpacked .PRG at a location within the file at an offset of $xxxx (in Hex), which is xxxx in Decimal.

I right-click on the start of the message and select ‘Beginning of block’, then right-click at the end of the text, and select ‘End of Block’. This highlights all the text. as per the screenshot below.

There’s a function under the Edit menu where you can Copy Block and a further sub-menu offers an option to put the text into a new file. I use this and save off the scrolltext as a text file.

Anyways, this simple job is now done. Move onto the next menu if there are multiple ones in your “To Do” list.

Atari ST Method – via MonST

If someone can suggest a similar Atari ST hex editor that will let you save off blocks of text, let me know.

Load the .PRG into MonST and search for the text (ALT & Z to get full-screen text). Use the cursor keys to scroll through the memory, looking for the start and end of the scrolltext.

However, if you know any particular words, use the Search function before entering the full-screen text mode to look for it. This saves going through the whole program’s contents.
Make a note of the start and end addresses of the scrolltext. These will be in hexadecimal.
Press ESCAPE to return to the main MonST2 screen.
Press TAB key to move to the M1 window.
Hold down ALT & A and enter the start address.
Press TAB key to move to the M2 window.
Hold down ALT & A and enter the end address.
Now press S to save the block into a text file. Use M1 and M2 as the parameters for the “from” and “to” range.

Job done. Move onto the next menu if there are multiple ones in your “To Do” list.

There are other tools out there to help you extract the text on an Atari ST. I’ve included MonST only (for now) as that’s what I would use. As and when I find additional tools, I’ll update this section.

And then there’s the non-standard ones …

Due to use of a demo / intro maker tool

H C Stamm’s Title Designer

This tool was one of the very early “demo construction kits” that were released for the Atari ST. Coded by an early member/cracker of The Bladerunners. The tool creates an encrypted program once it’s designed and nothing can unpack it.

However, it can be unpacked to a point using MonST so you can extract the text. I don’t find them often, but if want to see some examples, look at menus 25 & 26 from G-Force.

Demo Construction Kit

The Demo Construction Kit was created by Jinx / Superior and it was a big hit with menu compilation teams who couldn’t code and/or were sick of using the same source code that every other group was using.

If you’re not sure if the file was created using DCK, type in the letters J, I, N & X and it will pause the menu/demo if it was a DCK creation.

All DCK files are .ICE packed (v2.2, not v2.0), so the Ice packed data file needs to be extracted from the .PRG, then unpacked.

The “Ice!” header starts at an offset of $1BA (442 decimal) into the program. Save from this byte to the very end of the .PRG and then depack using Naughty Depacker. Remember to select Ice v2.2 option when asked. All the scrolltext inside is unencrypted.

There is also a DCK unpacker tool which I never knew existed. I found it purely by accident when I was searching the menus database on Atari Legend for another packer. It can be found on the EuroSwap Tools Disk 2.

DIY Demo Creator (WIP)

This is one I came across when grabbing the scrolltexts from one group’s menus … I think it was the Scouse Aggro Crew. The utility was coded purely to make menus for compilation disks and it included it’s own packer (from memory).

I need to grab some of these old menus and go through them again to update this section of my tutorial.

When they’ve used “odd” packers

MSR Packer – I’ve never successfully unpacked any file that’s been packed with any version of the MSR Packer. I’ve even tried the MSR depack functions within the packer – still no joy.

I have to unpack these manually using MonST, then do a memory dump when I think the original menu code is unpacked and save off the scrolltext afterwards.

An Cool’s Packer – No unpacker has been created to unpack these files. And then, with no real surprise considering who the coder is, the scrolltext inside is usually encrypted.

LSD Packer – The original packer from the pre-Automation packer days. No headers to look for and used on multiple menus (inc. BBC as well as LSD and others). You need to use MonST to work out where the packed data starts, then rip it out of the program.

MSD/POV coded me a simple 68K frontend to include the packed data and it saves out the original unpacked data afterwards.

Due to the text changing of packer headers/text titles

This fools some of the usual depackers out there as they are looking for a certain few bytes – usually the packer’s header, such as ICE! or ATM5, was expected to be at a certain location in the packed file. I know because this is how I recognised the packed files for my Multi Depacker tool in v1.0. I improved the detection methods a bit more in the upgraded versions (v1.5 and v2.0) of my program.

If it’s not there due to text changes, then the depacker doesn’t recognise the packed file and won’t unpack it. The only way to fix these is either depack it yourself using MonST or compare it against other packed programs (without altered text or headers). You’ll soon spot which packer was used and therefore which bytes you need to alter so you can unpack it.

Due to use of protection engines/envelopes

These can almost all be handled by Dec0de by Orion/Replicants. There’s an ST and a PC (command line) version of the tool in that Git repository.

Supported protections are:

NTM/Cameo Toxic Packer v1.0
R.AL Little Protection v01 & Megaprot v0.02
Orion Sly Packer v2.0
Cameo Cooper v0.5 & v0.6
Illegal Anti-bitos v1.0, v1.4, v1.6 & v1.61
Zippy Little Protection v2.05 & v2.06
Yoda Lock-o-matic v1.3
CID Encrypter v1.0bp
Rob Northen Copylock Protection System series 1 (1988) & series 2 (1989)

Interesting finds by others using De0de include the fact that Head Over Heels (Ocean) was released with all the labels left in. I’ve met Colin Porch (the coder of Head Over Heels) when he was writing Head Over Heels II and I’ve seen the source code for that version – good luck in understanding any of it :)