Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
Newsgroups: comp.sys.ibm.pc.games.action
Subject: Re: 'People like to hate EA, I don't know why'
Date: Sun, 23 Mar 2025 15:40:04 -0000 (UTC)
Organization: the-candyden-of-code
Lines: 79
Message-ID: <slrnvu0al3.2o4dt.candycanearter07@candydeb.host.invalid>
References: <4m4mtjprurdepapddt23ul8kfdmu7cspjp@4ax.com>
 <evortj126tikck9b4fltg53nc968bugolg@4ax.com>
 <slrnvtv9k6.1qton.candycanearter07@candydeb.host.invalid>
 <ag70ujtp444vj7elkg7gn7i4qlu8ocarak@4ax.com>
Injection-Date: Sun, 23 Mar 2025 16:40:04 +0100 (CET)
Injection-Info: dont-email.me; posting-host="f93b1c05508c8a8dc1c72008084bccc1";
	logging-data="2828566"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+IIbOP2q4eLxZ9Yq8rbdQYdNP6pzFyCJih6eN62UwXIw=="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:SOBwNmrbIOwjgTPrE3JNBBoCiLs=
X-Face: b{dPmN&%4|lEo,wUO\"KLEOu5N_br(N2Yuc5/qcR5i>9-!^e\.Tw9?/m0}/~:UOM:Zf]%
 b+ V4R8q|QiU/R8\|G\WpC`-s?=)\fbtNc&=/a3a)r7xbRI]Vl)r<%PTriJ3pGpl_/B6!8pe\btzx
 `~R! r3.0#lHRE+^Gro0[cjsban'vZ#j7,?I/tHk{s=TFJ:H?~=]`O*~3ZX`qik`b:.gVIc-[$t/e
 ZrQsWJ >|l^I_[pbsIqwoz.WGA]<D
Bytes: 5397

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