Well, you're opening up a big can o' worms there ;)

IIRC first 50 menus were packed with the LSD packer - there ain't anything that can unpack those because it's a very special packer - as in "it's not a .prg pacler" special. Lots of early LSD/WNW games were done like this: a) Let the game load in memory (most of those games laoded all data in a single go), b) Dump the chunk of memory that contains game code/data, c) Remove any references regarding the protection (if neccesary), d) Pack the data with LSD packer, e) Make a program that displays the header text, unpacks the data into a specific mem area, then run the game (or ask for trainers etc). But: these games have a high percentage of working on a simple (m)ste with a hard drive with small disk caches (can't vouch for TOS 2.06 though). You just copy the (usually) single parted file, rename it to .TOS, and run it. So that leaves us with the tricky part of removing the flashing.

Later games required more data than memory could hold, so they were forced to load data from disk. Can't say for sure that Automation pioneered this, but the solution was simple: Firstly, the main .prg was packed with the automation packer as a .prg (this can be unpacked with naughty depacker or new depack for example). As for the rest of the files, a stub loader was written that intercepts any file that's being loaded, and if it detects that it's packed, it then proceeds with unpacking the file and then passing control over the main program.




Anyone awake? :)



So, to (finally!) get to the second question: flashing. With fairly basic assembler knowledge and a bit of hex editing, it's possible to kill all flashing in a game. If there's interest in that I might write some hints on how to perform this (it's not exactly rocket science!). Maybe when someone did this 2-3 times, he/she could write a small program that does that automatically! (Not me though, I quite like the flashing of the unpackers ;))