List of ST/STE demos that can't be imaged (=protected demos)

[Brume]

Well, I'm trying to sort out the demos that are protected or "strangely" formated. They are the original demos that can't be MSAed and need to be imaged with Pasti / SuperCard Pro / Kryoflux. Most of them have been cracked of course, but I wanted to find the original versions.

Here are the titles known:

- Union Demo by The Union
dump of the original disk is OK

- The Overscan Demos by Paulo Simoes
dump of the original disk is OK

- Delirious Demo 2 by Overlanders
dump of the original disk is OK

- Thalion Sound Demo by Thalion
dump of the original disk is needed
Dual format disk: Atari ST + Amiga floppy. It was cracked by Lord Hackbear, see below the post by alexh for more details. Need the original disk.

- The Opening Demo by Poltergeist
dump of the original disk is needed
Have found an original disk, but one sector is definitively damaged and can't be repaired. have tried to dump this disks more than 20 times with all tools possible. The demo starts, displays the loader, but doesn't go further. I'm really after this demo, any help is welcome.

If you have more titles or want to do some corrections, please do. Also if someone has the original version of The Opening demo or Thalion Sound Demo (not the hacked versions, so you'll need to image them in .STX, .SCP or RAW/CTR formats), please help

Thanks.

[Dal]

I'm intrigued to know what the point was in applying copy protection to demos?

[troed]

I'm intrigued to know what the point was in applying copy protection to demos?

Not copy protection - in the cases where the special format (not using FAT allows you to gain extra space) couldn't be copied with system or common copiers the demos themselves included a copying screen.

It also "helped", at least somewhat, in making it more difficult for others to steal demo routines (which apparently was slightly more common than I ever thought).

[alexh]

Thalion Sound Demo. It's a protected dual format Amiga/ST disk. It was cracked for the Atari ST "side" by OSE, TORBJØRN (aka Lord Hackbear) and I had a friend Mr.Larmer (RIP) create a WHDload for Amiga

[AtariZoll]

There is contradiction. What can be imaged as MSA or ST is not considered copy-protected. There is a lot of SW what can put them in image, and write onto floppy, reproducing 100% working copy. No FAT, no visible files ? It will not prevent hackers to steal code.
Extra space may be the reason, but you can make 880K in regular format. More than it is possible, but only little - and using read track. I really would like to see some demo with it
Since Ijor has Union demo on his Pasti site, it must have some real copy protection.

[Dio]

you can make 880K in regular format. More than it is possible, but only little - and using read track.

Based on the numbers in the FDC manual, I can't see a way to legally build an 11-sector regular format disk that can be written to by the FDC. The ST nominally gets 6250 bytes per disk but there's a 1% speed error built into the standard so the actual limit is 6190 raw bytes. With 11 sectors making up 5632 bytes just for data, there's just not enough space to fit the gaps in (the default overhead is 86 bytes per sector plus some at start and end; although it can easily be shrunk just under 80, it's impossible to shrink it much under 60 bytes if you actually want to write data to it - even assuming the full 6250 is available, that's only 51 bytes per sector overhead).

Maybe if you had a slow-spinning drive that could squeeze on 6300+ bytes it was just possible. I certainly never had any success when I tried 11-sector formatters on my machines.

However, you can build a completely legal 880K disk that can be read and written on the ST using 5 large and one normal sector per track (even with only 6190 raw bytes there's still more than 80 bytes per sector available). I'm surprised more commercial games didn't do this.

More might be possible at a duplication plant - the gaps might be shrunk a little smaller if doing a 1-pass write where overwriting the next sector header isn't an issue, and combined with exploiting variable data rate it might just be possible to get to 6 1k sectors, which would need about 6450 raw bytes with a 50-byte overhead. It could be written 3-4% slow, still within the lock-on capabilities of the data separator PLL, I suspect, since some of the protected formats change the duplicator clock by about the same amount.

But definitely outside the disk spec, FDC spec... just about every spec .

[AtariZoll]

Dio, I really don't get why you write this. Many people used Hyperformat with success, and even some commercial games have such, 11 sect/track format.

It is possible to decrease gaps, and put 11 sectors - the result is slower read, as gaps are too small for sequential read of sectors in 1 pass. It is little less reliable, but not that bad.

Yes, there is number of SW distributed with larger sectors, and 5 large + 1 regular. And some much more: 6048 data bytes in Space Ace serial, what is about 11.8 sectors/track . Similar is with Wrath of Demon . There is 6 x large sector, and last one on track is truncated. Not possible to write with regular equipment, they use little higher data rate for sure.
I never saw full 6x 1K - instead it is better to go on read track - Vroom, Maupiti Island and some others. But needs some tricks to work.

There are menu disks with 11 sect/track - usable . And what never worked for me is crack of Maupiti Island, and 12 sec/track. There is option to format and write it to another one, but as said never worked. I guess that coder had some pretty slow floppy drive

[Brume]

Thalion Sound Demo. It's a protected dual format Amiga/ST disk. It was cracked for the Atari ST "side" by OSE, TORBJØRN (aka Lord Hackbear) and I had a friend Mr.Larmer (RIP) create a WHDload for Amiga

Thanks a lot for the info alexh. I didn't know the original was protected. I've updated my first post with your information.

[Dio]

Dio, I really don't get why you write this. Many people used Hyperformat with success, and even some commercial games have such, 11 sect/track format.

I wrote it because I've looked at the spec.

The timing for write sector (after the index has been recognised) is fixed and very tight: 23-byte delay before it starts writing, then 12 $00, 3 sync, DAM, sector bytes, CRC and a $FF. That's 42 bytes of overhead. The index field is 4 bytes plus 2 CRC, IAM, 3 sync and 12 0s - that's 22 more bytes, so we're at 64. The post-sector gap has to be at least one byte, so the limit is 65 bytes. (512+65)*11 = 6347, which is simply 1.5% too long for nominal rotation rate.

The only place to spare more bytes is losing 00s off the index PLL lock-up time. If you leave just 3 bytes then you do get (just) under 6250 - but that's taking a huge bet on how long the PLL takes to lock on and where the last write splice landed. If it was pretty near the centre of the timing window, then 3 00s is enough to lock back up again, but if it's not, then it's not.

I can believe it just about worked, if you had A. a drive spinning a touch slow, and B. only ever wrote the disk once. It never did for me.

The tolerances involved mean trying to get a reliable write on a different drive would be impossible. Maybe even on the same drive, on a different day with different temperatures and tension in the drive belt.

Anything done at the duplicators I can certainly believe because read sector timing is more flexible than write, and since it's track-at-once written there aren't any write splices. Given that the PLLs should stay locked for the entire track, it's not out of the question you might even be able to eliminate all the 0s on the index PLL lockup and save a full 12 bytes there (although that might again require interleaving, and the CAPS FDC claims the FDC won't respond to a DAM closer than 28 bytes to the end of the index header so there's nothing to be saved on the data side).

[Brume]

I'm intrigued to know what the point was in applying copy protection to demos?

Not copy protection - in the cases where the special format (not using FAT allows you to gain extra space) couldn't be copied with system or common copiers the demos themselves included a copying screen

That's the case of The Union Demos, I agree. But that's not the case for The Constellations Demo (and probably some other demos mentioned here). You need ACopy in order to copy the full disk, since just a few tracks aren't formated regulary, but others use 80/10.

[AtariZoll]

...
I wrote it because I've looked at the spec.
...
Anything done at the duplicators I can certainly believe because read sector timing is more flexible than write, and since it's track-at-once written there aren't any write splices. Given that the PLLs should stay locked for the entire track, it's not out of the question you might even be able to eliminate all the 0s on the index PLL lockup and save a full 12 bytes there (although that might again require interleaving, and the CAPS FDC claims the FDC won't respond to a DAM closer than 28 bytes to the end of the index header so there's nothing to be saved on the data side).

I think that this is one of those things, when users, coders were able to do something probably disrecommended from chip, machine manufacturers, designers.
Here is short part from my floppy format/copy SW:

Code: Select all

hyfil dc.b 11
  dc.b 1,7,2,8,3,9,4,10,5,11,6 *sec No-s, interl. 6
*GAP-s for hyperformat
  even
trleadh  dc.w 3   
  dc.w 4
  dc.w 5
  dc.w 9
  dc.w 5
  dc.w 34

It worked on any drive I tried. Certainly worked on drives with exact 300 rpm. If not use interleave, then it reads much slower, because FDC can not catch following sector, due to short gaps.

There is no interleaving in case of Space Ace serial. Loading speed is crucial, so there is proper skew to make it as fast as possible.
Of course that reading is more tolerant. Write is determined by FDC clock and drive rotation speed.

[alexh]

I didn't know the original was protected.

http://www.st-news.com/rex.htm#lhb

Apparently the Thalion Sound Demo disk (with it's Amiga side) cannot be written on an Atari ST(e) and they were written using an Amiga. I find this quite feasible as Jochen Hippel was Thalion's Amiga coder for the first year

We would need an analysis but I suspect it might have been an earlier version of the Dragonflight protection which was created about the same time. Ijor speculates something similar here in a letter to Udo on the Thalion Webshrine eGroup.

http://groups.yahoo.com/neo/groups/thal ... topics/395

However, you can build a completely legal 880K disk that can be read and written on the ST using 5 large and one normal sector per track (even with only 6190 raw bytes there's still more than 80 bytes per sector available). I'm surprised more commercial games didn't do this.

Dragonflight and probably the Thalion Sound Demo did. I've cut the post out for those without Yahoo group access.

Hi Udo,

Thanks for answering. I guess you forgot after all this time, but no,
there are no single 6k sectors on Dragon Flight.

Track 0 is indeed standard and the rest are not. Tracks 1-79 have six
sectors, five 1k sectors plus one 512 bytes sectors. This gives you
5.5 Kb per track, exactly the same capacity as "standard" 11 sectors
per track, but your track layout is much more reliable. All 3 disks
have exactly the same format/layout except that the last one is
single sided.

As a matter of fact, there is no such thing as a 6k sector on the ST.
The FDC doesn't support sectors bigger than 1k. It is possible to not
use sectors at all, and use a raw track with a capacity approx. of
6k. Some ST games use this format. But this is not very reliable, and
this is not the case on Dragon Flight anyway.

If you don't have original disks anymore, I can send you a Dragon
Flight's disk image with the copy protection and custom format
intact. It runs under the latest version of Steem perfectly well
exactly the same as the original (as with the original, you have to
create and use backup disks). You can use disk analysis tools to see
the track layout or you can even log and trace the disk reading and
copy protection. But you have the source, so I guess you should be
able to verify that you are reading 6 sectors per track.

Also, this custom format has no relation to the disk copy protection.
I mean, there is a disk copy protection on Dragon Flight that is
separated for the custom format. The custom track layout is not
actually a protection because most ST software copiers would handle
it without troubles. The protection is not in the sectors, is outside
the sectors. I'm not sure how much you want to talk about this, so
I'd prefer to avoid giving details without your authorization.

However, I consider that the most interesting aspect in Dragon's
Flight protection, is the one present in the "Backup disks". It is
exactly the same as in … some famous ST copy protected demo. It is
a "seudo" protection because, obviously, the protection can be
created and copied in the ST itself. But the concept is quite unique
and brilliant. Hats off to you (or to Michael, or to whoever came
with the idea). Again, I'm intentionally avoiding being more specific.

Jorge

[Dio]

Here is short part from my floppy format/copy SW:

Thanks for that, very interesting. Can you tell me what each of the GAP sizes is used for?

[AtariZoll]

Here is short part from my floppy format/copy SW:

Thanks for that, very interesting. Can you tell me what each of the GAP sizes is used for?

I try to describe in short: values are for dbf loops, some for wordwise write, some for bytewise. So, exact counts for gaps are:

Track lead: 8x $4E , Sector lead, prerecord: 10x 0 , Interrecord: 6x $4E , Interrecord 2: 10x 0 , Postrecord: 12x $4E , - later 4 repeats for all sectors
Track end: 70x $4E - of course, will be written how much fits until index pulse.

[Dio]

OK, so that's cutting it down to 54 bytes overhead per sector. That's small enough to physically fit as long as the drive runs at or below nominal speed.

But the particular structures aren't remotely preserved after you write the sectors - the sector write will spill over and start overwriting the 0s on the next index PLL lockup zone. Indeed, with the values you specify there, I think it's possible you overwrite all of it (or maybe there's still one byte left), unless the Write Sector description in the manual is out. I'd love to see a Read Track after actually writing some sectors to it. A disk made with that is not going to be writable on a different drive to the one it was formatted on unless the PLL mechanism is really much smarter than it claims to be .

Proves that the full run of 0s isn't needed though, and maybe that no PLL lock time is needed after a write-splice at all in some cases, which is very useful info. Thanks.

[AtariZoll]

11 s/t is likely good mostly for read-only usage. I remember that it was not much reliable - after some time data went corrupted - year 1-2. And it happened with floppies formatted with diverse SW. Don't remember how much I wrote on those floppies, if wrote at all. Actually, I started to avoid it Surely would be interesting to look some track dumps. And you have a lot of it in STX images - all public SW/HW made ones have dump of all tracks, so you can find some with 11 s/t. TwinWorld for instance. And may try Hyperformat SW too.

[Dio]

And I can also get off my backside and make some myself .

[DrCoolZic]

Does anybody has STC of KF images of these games so we can have a look at them?

[npomarede]

Hello

I have KF image of The Union Demo that MugUk sent me, as he was kind enough to dump it one year ago when I was working on IPF support for Hatari.

I can upload the KF dump wherever you like.

As for the Union Demo, I think one of the reason for the disk protection was to avoid some copies of the Union Demo were made on single sided drive ; the demo would work on single sided drive, but you lost the sample sound in TCB1 screen. I think the Union wanted to ensure all copies of the demo were always double sided (at that time, some 520 STF had single sided drive, but some newer 520 STF also appeared with double sided drive). I remember I cracked it more than 20 years ago when it was released, and I was able to copy it with any disk copy program (but I don't remember where the special track was located). The protection also included some kind of "crypted" code in the loader to make things harder and prevent people from ripping code (as the Union Demo included some pretty impressive never-seen-before effect, such as Level 16 fullscreen)

Nicolas

[Mug UK]

Hello

I have KF image of The Union Demo that MugUk sent me, as he was kind enough to dump it one year ago when I was working on IPF support for Hatari.

Glad you remember me doing it .. I had to read that sentence twice before realising that yes, I had imaged up the Union Demo. My grey cells are fading quicker than looping through the palette to 0

[npomarede]

Here's the url of the 15 MB stream dump made by Mug UK that he sent me some times ago :
http://www.mediafire.com/download.php?s4m8kwqcgysoso6

The link is still working.

Nicolas

[Steven Seagal]

- The Overscan Demos by Paulo Simoes. If i remember correctly, it was hacked by Paulo Simoes in order to make a .ST/.MSA file

I'm looking for a STX/CTR image of this (original format) too.

[STEdawg]

Dio: I had at least 2 demo's for years that used an 11 Sector & 82 Track(0-81) format and always worked fine. When I formatted disks using Fcopy to the same format half of them would format fine and write/read fine. Half the time it failed, but that did depend on the quality of disks I purchased at the time. That was on a 1991 Tos 1.62 STE.

[DrCoolZic]

I would like to comment some of the information presented here.

First about Union demo.

I have three version of Union Demo image

• One from Brume (KF and SCP format): very good condition
• One from Mug (KF format published in this thread): Relatively good quality apart from T72.1 sector 5 not very clean but still good enough to be recovered.
• One from Jeff (KF and SCP): Special has it has been generated with HxC from an STX file (so timing are artificially perfect).

When analyzed with Aufit (0.4) no protection are found but conversion to stx format only worked with Jeff image. When analyzed with latest Aufit (0.9) still no protection found (24 tested) but conversion seems to work ok for all images.

The above implies that some tests are done to check original disk.

When I say works don’t works I am not sure - as I do not know how to play this game. Just that at load time it either starts the game or it gives the message: “This is an illegal copy ….”

In Steem I have noticed that the program after loading reads track 41 (as you may know T41 is a “magic track”) so I looked at it and found that there are probably hidden data in this track. At beginning we have a C2 sync mark followed by some data that are probably tested (would be interesting if someone could verify that). “Old Aufit” had a bug in decoding raw track data after C2 sync mark that is now fixed using a modified version of the decoder from SPS and this is probably why it works now.

union-track.PNG

For the format as mentioned 5x1024 + 1x512 is definitively much much more reliable than 11x512 for the same amount of data but I will get back to this later.

[DrCoolZic]

There is contradiction. What can be imaged as MSA or ST is not considered copy-protected. There is a lot of SW what can put them in image, and write onto floppy, reproducing 100% working copy. No FAT, no visible files ? It will not prevent hackers to steal code.
Extra space may be the reason, but you can make 880K in regular format. More than it is possible, but only little - and using read track. I really would like to see some demo with it
Since Ijor has Union demo on his Pasti site, it must have some real copy protection.

From my investigation it seems that "read track" data is mandatory and this is probably why ST/MSA ... fails