Re: 'People like to hate EA, I don't know why'

Spalls Hurgenson <spallshurgenson@gmail.com> wrote at 15:20 this Sunday (GMT):

On Sun, 23 Mar 2025 06:20:05 -0000 (UTC), candycanearter07
<candycanearter07@candycanearter07.nomail.afraid> wrote:
>

Zaghadka <zaghadka@hotmail.com> wrote at 22:13 this Friday (GMT):

On Wed, 19 Mar 2025 15:15:05 -0400, in comp.sys.ibm.pc.games.action,
Spalls Hurgenson wrote:
>

The sad thing is, I still think EA is one of the _better_ triple-A
publishers... because the rest of them are even worse!
>

I remember back in the C=64 days when I would buy anything published by
EA, because they were *that* good. Of course I would immediately crack
their stupid 10 minute long half-track loader (their proprietary DRM) and
have the game load up in 3 seconds with FastLoad.
>
And for people who didn't crack the endless EA logo loading screen? I
made a fortune realigning 1541 hard drives so it would work. I always
offered the pirate tool though.
>
But still, Archon, Seven Cities of Gold, MULE. They were amazing.

>
>
Wait, why did the DRM take so long?

>
>
Not having heard of half-tracks, I did some quick googling and
realized that they were the same thing as Fat Tracks, which is what I
knew them as. The trick was that the copy protection wrote three
tracks data on the floppy disk onto two tracks, something home systems
couldn't easily do (it basically fucked around with the formatting and
overwrote half of a track.)
>
     [Think of tracks like concentric rings around a disk. Each ring
      has a start/end point that is synchronized with the ones below
      it. The publisher would write to one track, then before writing
      the next, stop writing for half a revolution, then overwrite
      that same track from the halfway mark (with a new marker for a
      'start' point), then wait half a revolution (so the drive synced
      up with the normal formatting again. Essentially, you get one
      track with two start points this way. It doesn't allow you to
      get more data on the disk, it's just fucking with the
      synchronization points on the floppy]
>
This made it harder for home users to 'copy that floppy' for their
friends, since the program would check for this 'half track' of data
stuck between the two regular tracks, and -not finding it- would halt
the game or application.
>
I don't know if it was actually slower but I can imagine it was.
Reading that half track was probably almost as tricky as writing it;
you can't just use regular disk routines but had to add the extra
overhead of using your own disk-read software... which was probably an
even bigger hit on the C64, since you then had to rely on the
computer's main CPU instead of offloading it to the floppy-drive
electronics.
>
     [The C64 floppy drive was basically its own separate computer,
      which is why it cost almost as much as the C64 itself. This
      usually meant a program could just offload read/write duties to
      the floppy drive and then get back to doing its own thing on
      the C64's main processor, but if you were fucking around with
      oddball copy-protection methods that may not have been an option
>
It wasn't a very successful copy protection method. Apparently users
could, if they made enough attempts, accidentally get their copy
programs to duplicate the half-track, and even if they couldn't, the
routine that checked for the 'half track' it was easily patched out by
crackers.
>
      [Written from memory and half-scanned articles on the web.
       Errors likely abound. Feel free to offer corrections ;-)]

Interesting. I've never looked too deep into the internals of storage
mediums, but using a quirk of the medium does seem like an alright
TEMPORARY solution..
--
user <candycane> is generated from /dev/urandom