Hi Fans -
you might wonder why I'm interested in the topic of Apple I copyprotections at all - we nowadays use floppy emus using WOZ images, and don't need to "copy" copyprotected floppy disks anymore. But some people still might be interested in this topic. I am, and for very good reasons.
THE MOTIVATION TO LEARN ABOUT APPLE II COPY PROTECTIONS
As you might know, I've been obsessed with the inner workings of the DISK II controller since it came out. This work over 46 years (with long periods of being on the backburner) has born some interesting "fruit", like my Apple-1 floppy disk controller here:
https://www.applefritter.com/content/uncle-bernies-woz-machine-based-apple-1-floppy-disk-controller
... or this one which is a GAL based DISK II controller substitute for my Replica 2e project:
https://www.applefritter.com/content/uncle-bernies-replica-2e-ww-prototype-apple-iie-replica
... the photo of a DISK II substitute is on post #65. It uses the same GAL as in my Apple-1 floppy disk controller.
Or my recent work on reverse-engineering the IWM (to make a PLD based IWM substitute) here:
https://www.applefritter.com/content/iwm-reverse-engineering
... which got stuck for a few weeks now as I could not get my hands on a Rev B IWM (it is still stuck).
So although I know everything about how the DISK II controller works (I think), my knowledge of Apple II copy protections is lacking. And this has been a big concern for my work on these substitutes. For instance, I do see significant differences between the read state machines in the DISK II and in the IWM. How might these differences affect copy protections ? Will they still work ?
ENTER THE "TOME OF COPY PROTECTION" BOOK
While searching the web for answers I ran across this fantastic book on Apple II copy protections:
I ordered it from Amazon (which I normally boycott, unless I can't get the wanted item elsewhere) and with slow shipping it's a tad below $50. Got it yesterday high noon and spent most of the day and the night on the living room couch reading its 376 pages, I read and absorbed all the text, but skipped the source code listings. The dsk images of the source code listings in the book can be downloaded here:
https://www.callapple.org/apps/
MY OPINION ON THE BOOK
My take on this book is that it fills all the unknowns about Apple II copy protections I was worried about. And the source code provided will be helpful to actually check my substitution hardware. From a pure scientific standpoint, the "state machine equivalence" test my GAL implementation of the Disk II controller did pass should be proof that it will have the same behaviour like the real DISK II controller under any circumstances, for any copy protection, but this "science" is based on an abstract model and not on the real world, so there always is the chance that something which happens in the real world was not modelled properly. Hence, additional tests using real world hardware and software are prudent.
I think it's an excellent book on the topic I can recommend for anyone interested in the inner workings of the DISK II controller in the world of Apple II copy protections. The examples and descriptions given in the book (how the read impulse stream from the floppy disk interacts with the DISK II controller state machine and how the software checks for the results of the various copy protections) are very well done. They also explain how the copy protections are generated, and their basic ideas, in a very clear and concise way. I liked that ... I think this night I understood them all.
The book only has a few minor flaws, IMHO, where they speculate about alleged features of floppy disk mastering machines to make certain types of copy protections (i.e. wide tracks) such as the mythical "extra wide" write heads. To the best of my knowledge, these most likely are a myth, at least I never encountered such a thing in any of the disk mastering machines I have encountered when I still was designing copy protections (not for the Apple II, though). So I think it is highly unlikely that any of their manufacturers made their own write heads - these involve high tech manufacturing processes that are not financially viable for manufacturers of disk mastering machines. So these "wide tracks" most likely were produced by turning off the tunnel erase coil. But again, this is a conjecture of mine, but I'm willing to take that back if somebody produces physical evidence for the mythical "extra wide" write head. There are some other minor flaws, such as their explanation of how and why the MC3470 reports unstable bits for flux changes spaced too far apart, which I found lacking, but probably fair enough for most readers not being analog IC designers. Yet another copy protection technique I did not find in the book (yet ?) - is what the "Formaster" floppy disk mastering machine advertised as "density frequency modulation" (IIRC, has been 40 years ago). I don't know if that ever was used on any Apple II floppy disk, though, but it's an alternate way to make "unstable bits" on a floppy disk, which does not rely on quirks of a particular read amplifier, so it will work regardless of the type of floppy disk drive being used (micro computer manufacturers often switched floppy disk drive vendors). These minor flaws / omissions of the book will not be relevant for most readers, and can't distract from its tremendous value for Apple II copy protection aficionados.
Recommended ! (Get it before it sells out !)
- Uncle Bernie
My experiments several years ago to create a fat track by switching off the tunnel erasure of a disk II drive led to no significant increase of the track thickness. It led to higher incompatibility of a written diskette when read by a different floppy drive. I have a theory the thickness of a track may be sufficiently increased to cover two or more tracks' width by rotating of the (writing drive's) head around its vertical axis by just a few degrees.
In post #2, 'retro_devices' wrote:
" My experiments several years ago to create a fat track by switching off the tunnel erasure of a disk II drive led to no significant increase of the track thickness. "
Uncle Bernie comments:
This may have been drive specific, depending on the exact nature / design of the write head. Outside of the Apple II world, not much is known about the "wide tracks" because almost everybody else used floppy disk drives which used the industry standard DIRECTION / STEP inputs and did not allow direct access to the stepper motor phases. On these machines, "wide track" protection would not work anyways.
Floppy disk heads are constructed differently among manufacturers. There is "straddle erase" and "tunnel erase". Older Shugart drives used the former. Not sure if the Apple II drives had that.
The idea of "tunnel erase" is to first write a wider track using the read/write coil (and its gap, which can be wider than the specified track width) and then immediately erase the outer fringes of the wider track using the "tunnel erase" coil, to arrived at the specified track width. All the coils are mounted on the same ceramic disk head, so the erase of the fringes happens immediately after a flux change / magnetic domain was written.
If you turn off the tunnel erase head, you will get a wider track, guaranteed. But there are lots of things to consider. Such as the interaction of a "wide track" with adjacent "normal" tracks. There will be crosstalk: the read head, when on the "normal" track, will pick up a signal from the wide track, unless the gap between the "wide tracks" and the "narrow tracks" is wide enough. Any residual magnetization in the gaps also will interfere with proper reading. I think the best way would be to start with a completely erased floppy disk - no magnetization left, and then strategically write the tracks in a certain order, depending on where the "wide" and the "narrow" tracks are.
I did not experiment with this on the Apple II / Disk II, so I can't say why your experiment failed.
All I can say for sure is that none of the floppy disk mastering machines I ever worked with had a special head to write "wide tracks". And the idea with turning off the tunnel erase coil is the only trick that comes into mind which could produce "wide tracks". Which outside of the Apple II world have not much use, if any. Another reason for mastering machine manufacturers not making special heads. The costs would have been prohibitive. The digital electronics inside of these late 1970s /early 1980s machines were huge TTL "graveyards" and could produce very fine grained write pulse timings, to make a plethora of copy protection formats. We can do that much cheaper using 21st century electronics. But back in the heydays of floppy disk copy protections, none of the "copy kids" aka "evil" "software pirates" could afford such elaborate hardware. It also shall be mentioned that although some mastering machines would read a master disk and copy it verbatim, the more sophisticated copy protection methods were generated from a description in a proprietary language specific to the brand and maker of the machine, because they could not be analyzed with enough accuracy once they were put on a floppy disk. There are many effects which cause shifts of the boundaries of the magnetic domains (what you read is not what you wrote). The consequence from this is that modern floppy disk flux engines (including the mine) are quite successful in reading copy protections and turning them into formats which then can be fed into floppy disk emulators but if you try to actually reproduce a floppy disk from that file (i.e. "WOZ" file) all bets are off. Because the WOZ file accurately describes what the time distance between the RDDATA pulses was when the original disk was read, but this is NOT what needs to be written to a real floppy disk to get the same time distances when read back. But I'm sure that such data in a WOZ file could be "massaged" prior writing to get close enough to the wanted effect. However, this will depend on the type of floppy disk drive being used, and the magnetic media being used, and hence, has too many variables to be "easy".
For those interested, try to find out which college or university in your vicinity has the 1970s and 1980s "IEEE Transactions on Magnetics", or become a IEEE member to be able to download these papers online. I was IEEE member for 30+ years and subscribed to the "Red Rag" (IEEE Journal of Solid-State circuits) all the time (and have all those in print) but when I retired, I cancelled the membership. Which may have been a mistake.
- Uncle Bernie
Of course, the diskette was erased in my experiment prior writing. There are copy protections which wide track was thick over three normal tracks therefore lack of the tunnel erasure definitely wouldn't help to create such wide track.
In post #4, retro_devices wrote:
" There are copy protections which wide track was thick over three normal tracks therefore lack of the tunnel erasure definitely wouldn't help to create such wide track."
Uncle Bernie comments:
This is an important hint / piece of information I'd like to investigate further. Do you remember which software title had the 3 track "wide track" ?
Note that it could have been a wide track made by turning off the tunnel erase (which would be approx. 2 tracks wide, 1 + 2 x 0.5 "normal" width) and the ability to read it over 3 track positions might come from the read head picking up fringe fields from that track. Take this numbers and this hypothesis with a grain of salt, it's just my conjecture, from knowing that reasonable added margins over the "ideal", narrow track width must be provided for all read, write, and erase processes to allow for slight head positioning misalignment between different floppy disk drives. Otherwise a floppy disk written on on drive could not be read on another one.
So my "tunnel erase turn off" hypothesis is not yet off the table. But it stand on weaker feet.
To really find out the truth, the floppy disk in question (the one with 3 tracks wide tracks) must be examined with a fluid that shows magnetic field lines. There once were many sources for such fluids but with the CFC bans they disappeared. Maybe the fluid for the Magnaflux test process could be a substitute. I didn't try that yet. There is always a concern it would damage the plastic. The CFC based versions disappeared without a trace and without damaging plastic. This is what you get when "green" idiots are allowed to make laws.
Uncle Bernie
P.S.: For anyone interested in the CFC scam, I've seen opinions from scientists that state that the "ozone hole" actually came from surface and airburst nuclear tests in the 1940-1960s and once the "hole" was discovered, it was exploited by some chemical conglomerates to get a ban of certain of their o w n CFC products which just had recently expired patents. So the competition could finally make them and sell them much, much cheaper. The monopoly was gone. But they had newer, patented CFCs which - who would expect that - were NOT banned. So these corporations got their monopolies back and could further rip off the buyers of these products with moon prices only possible with a patented product. The same type of scam is played out with pharmaceuticals. Once the patent expires, it is "suddenly discovered" that the old, now patent free drug has surprising but dire side effects and is not fit for human consumption. But see, there is this new and improved, patented drug which does not have these side effects and can substitute it. It's $100 per pill but the old one was 10 cents a pill from generic manufactures which made it once the patent expired. Ooops. You pay up or die, because the newly discovered side effects led to a ban of the old product. Side effects which always have been there or just have been exaggerated. It's all lies, folks. Beware of these scammers ! Most of the "science" today is fraudulent and has been bought and paid for by greedy, dishonest, and sometimes mass murderous corporations. They always can find "scientists" who will fake a "study" and then write a "paper" with the "results" wanted (and paid for) by the corporation.
The fluids in the general category of "magnetic developers" were sold under various names. The really old cans using CFCs (which were in very wide general use for all kinds of applications) were labeled "MagnaSee". A more recent brand is called KyRead, which I'm sure is formulated with compliant solvents, which are not hard to find or particularly expensive in the small volumes required. Searching just now also produced another brand called "Q-View".
One of the problems with these magnetic developers is that although the solvent evaporates without damaging the tape, the ferrite nanoparticles themselves may act as an abrasive or contaminant. An alternative system for viewing magnetic patterns is encapsulated inside a plastic film or disc and won't create any contamination issues. One was sold as the "3M Magnetic viewer", which later was spun off under the Plastiform brand, and currently made by Arnold Magnetics. Something to keep in mind about this device is that it will stop working unless the moisture content inside is maintained, so it is packaged in its own "cigar humidor" padded case. Of course, there is a downside in that the plastic film separating the ferrofluid from the tape reduces the resolution, but for identifying track width that won't matter.
For actual data recovery (when no drive exists to read the tape/disk) you would want some kind of polarized light detector based on the Kerr effect. These evidently do exist, but far out of my price range.
The game is Accolade Comics. I've been told all games by Accolade had the same protection. I've never had the diskette. Was trying to recreate/write a physical diskette media for a friend from a WOZ file publicly available (with the AS hardware). Actually the fat track is expected by software to span from all 20.75 to 22.25 quarter tracks but still cannot be written by simply switching off the tunnel erasure.
Another great source of information about Apple II copy prorection is Hardcore Computist magazine in its various incarnations. I think you can find the full run on Archive.org:
https://archive.org/details/computist-scan-01
That's the first issue. It may also be out there on Asimov.
In post #7, 'retro_devices' wrote:
" The game is Accolade Comics. . . . Actually the fat track is expected by software to span from all 20.75 to 22.25 quarter tracks but still cannot be written by simply switching off the tunnel erasure. "
'Uncle Bernie comments:
Thanks for the info, I can now look into it. Are you sure your numbers are correct ? In my world of math, 22.25 - 20.75 = 1.50 which does not 3 tracks make.
I would never use the words "cannot be written" in the context of floppy disk copy protections. There are only few which would qualify for that "seal of security" but not in the strict sense, because even these can be written with the proper mastering hardware, using a normal floppy disk drive. But once they have been analyzed with a flux engine (like AS or my own "Ratweasel") they cannot be reproduced by writing the flux changes to magnetic media.
They can be reproduced to run the game on an emulator if the emulator is really smart and knows how to handle this protection. I think the current WOZ file format 2.0 is unable to specify the required information for that flavor of copy protection. I never found a spec for the Woz 3.0 file format, though. And it may be moot to try implement this because we don't know if this protection ever was used on the Apple II. It's the one which analyzes certain properties of the RDDATA pulse stream after it was written and tunes parameters in the software to make it able to detect the copy protection. Each floppy disk may be different. This protection relies on properties of the write channel and properties of the magnetic media, how the magnetic domains shift after having been written.
Just sayin' that there are really weird copy protections out there, across all kinds of computer systems. Studying the relevant patent literature also is enlightening. But from patents alone we can't tell which ones did work and which ones did not. Back in the 1980s I've witnessed some severe blunders where games were bought to be re-published by another software publisher and they could not reproduce the copy protection accurately enough to make the product work. Using a different mastering machine may have contributed. In one case I remember the game became unplayable because it had a two phase copy protection check, the first phase would crash the loader, and the 2nd phase would change the game logic such that the player never could get into the next level (after a few levels which worked). The first phase check passed. Lots of angry buyers. That was a game for the Atari 8 bit but alas, I don't remember the title.
I also found some copy protections which work with WDC floppy disk controllers having an analog PLL, but do not work with WDC floppy disk controllers having the digital PLL-"ish" data seperator (WD2793 vs. WD1770). This data separator has been described in the relevant patent but it's not exactly what is in the WD1770. Made several attempts to get to the bottom of that mystery but so far no success. And when I get too frustrated I just put such projects on the back burner and it my be years before I look at them again.
- Uncle Bernie
The integer numbers of the tracks are hex. In decimal these are 32.75 to 34.25. These consecutive 7 tracks must contain and are checked by protection for identical contents: 32.75, 33, 33.25,33.5,33.75,34,34.25. The woz file represents exactly this. While it is simple for reading it is impossible on my opinion for writing on standard 5.25" drive, be it 48 or 96 TPI.
In post #10, 'retro_devices' wrote:
" The integer numbers of the tracks are hex. "
Uncle Bernie comments:
Ouch, what a trap ! People using hexadecimal numbers and write them as decimal numbers should make clear that these are hex by adding a prefix (such as '$' or 'Ox').
Not that I am immune to this. When I wrote the RWTS for my Apple-1 floppy disk controller card it could not format floppy disks for a long time. Until I found that the number of sectors per track constant, which should have been decimal, had been typed in as hex in the source code (habit).
But this is not as bad as that Mars probe which was lost due to mixing up metric and imperial units.
As for the wide track, maybe the interpretation of the WOZ file, although it yields a running program on an emulator, is based on the fringe field effects I mentioned, so it might not be necessary to have such an excessively wide track. But if that track really was that wide in the real media, I concur that probably something else was used than turning off the tunnel erase current. But a homegrown extra wide write head for a mastering machine still looks improbable to me. This is the same unicorn thing as with the guy who made an integrated circuit in his garage, just using a slab of silicon and a file. Not gonna happen. Read/Write heads for floppy disk drives were the most difficult component to make, and required huge investment in high tech equipment. But here is a bone I can throw you: what if the track was even wider on the original disk ? And then they erased its fringes to narrow it down ? This could have been done by using a read/write head from a mainframe tape drive (the "spools"), properly mounted in the floppy disk drive mechanics of the mastering machine. It would be interesting to know if the wide track of all the Accolade games always was on the same track position. If so, this would mean that the extra head was installed in a fixed position and was not moveable by the head positioning mechanism. Which would simplify the task to a point that it could be done by a man in a garage, using a file ;-)
Would be nice to find a few originals of these floppy disks to inspect them with a magnetic viewer, such as the one from Arnold Magnetics mentioned by 'robespierre' in post #6. I looked for the price and although its not cheap, if I had a specimen of those Accolade disks, I'd buy one of these viewers.
- Uncle Bernie
Probably pretty much impossible for writing in single pass. Perhaps possible to do if you have code that will keep writing the tracks over and over until it gets "lucky".
It may also matter if the data has to be something specific and if it has to be aligned a certain way. If the amount of data doesn't matter it might be possible to write short tracks offset enough that over-write doesn't natter.
@Uncle Bernie Well, you haven't started working on that protection and the number representation is irrelevant. I made clarification soon enough I think. By debugging the software you would have found the exact track numbers yourself. For the protection way of operation the number represenatation is irrelevant. For an old apple2 user tracks above 20h usually mean the end of the diskette and that's the usual plcae for such fat tracks. The original diskette is neither available to me nor it is justified to be bought these days.
@Softwarejanitor no matter how many writing passes one would use each one will erase or will overwrite (part of) adjacent tracks. On my opinion it is impossible to synchronize written data on adjacent tracks to an extent at which resulatant magnetic field of two adjacent tracks when both read together (by the overlapping head's position) would yield equal and useful data reads.
... off Ebay so I can investigate the real deal.
In post #13, retro_devices wrote:
" The original diskette is neither available to me nor it is justified to be bought these days. "
Uncle Bernie disagrees with this statement. For your point of view it may be not justifiable to buy these diskettes today (as you have the WOZ file) but I am a collector of copy protections for all sorts of computers, and the weirder these copyprotections are, the more I get interested in having them.
You have done me the great favor to point me to a reasonablly priced specimen of these "fat tracks", Accolade Comics. Got the set of 3 disks for below $50, at about the price of the "Tome" book.
Can't wait to get them in my hands to investigate, being new to the Apple II copy protection world. But I spent the 1980s with copy protections for the Atari 8-bit (on both sides, developing copy protections and also producing an infamous copy chip). This changing of sides came about because regardless for which side I was making these tools for, my IP always was stolen / pirated / rejected. So in my wrath I changed sides several times to wreak maximum havoc upon these pirates, copycats, IP thieves and hostiles (some software companies sicced their lawers on me after I offered them my great copy protection --- WTF ??? I try to help them and they threaten me ? How dumb / psychopathic can these "managers" be ? ). I was just neutralizing my prior accomplishments to level the playing field again:
"I giveth it, and I taketh it away". Fair enough, I think.
So far on my background in floppy disk copy protections. Was a very exciting field, back in the 1980s. But with a lot of bad / rogue / evil players on both sides, and a lot of disappointments for me. Think about the tale of the Frog and the Scorpion, where the latter asks the former to bring him over a river. A bit off topic, but here is my advice for innovators, based on my experience with innovative copy protections, regardless if it's in the field of copy protections or any other field of human endavor:
Uncle Bernie's advice for innovators
Later, I saw the same behaviour patterns with many of my innovations in integrated circuits. I offer a great innovation which would blow their competition out of the water. CTO asks his local "czar" for the type of product for his opinion. "czar" thinks I'm after his job and says my stuff is not worth even looking at - because he also fears that in a technical discussion he may look like an idiot, having an inferior solution despite having 10 x the people and budget (or more). So, no deal. Stupid is as stupid does. See the 2008 movie "Flash of Genius" which is based on the true story of Robert Kearns, who invented the interval windshield wiper.
Every field of human endavor is pervaded by this type of idiots who worship the "not invented here" principle. Only the parasites / IP thieves are worse. They would invite you for a presentation and then turn around and file a patent with what they think is close enough so they can use your invention without paying royalties. But lacking the deeper understanding, they never can produce a working example. But their trash patent then is used to block your further improvements from being patented.
A really foul game. The only way to win is not to play. Keep your innovations for yourself. Never talk to anyone about how they work. If you can't produce and sell them yourself, take them with you into your grave (when brain is dead, they disappear). If your job description requires innovation, throw them a bone from time to time, juuust enough to check the box in the performance review. But never, ever, show them really innovative ideas of yours. Go Galt. Don't feed the parasites / leeches. They get rich on your back and then kick you in the curb.
- Uncle Bernie
Without the elaborate copy protections, a lot of the companies would not have had the sufficient income to keep the lights on and subsequently create the large amount of great retro software. And without the crackers, we would not be able to enjoy most of this great retro software now.
They are both integral to the wonderful world we live in today, where we can download and run any retro software without really hurting the authors. I believe we should be grateful that both existed back in the day.
In post #15, CVT wrote:
" Without the elaborate copy protections, a lot of the companies would not have had the sufficient income to keep the lights on and subsequently create the large amount of great retro software. And without the crackers, we would not be able to enjoy most of this great retro software now. "
Uncle Bernie has mixed feelings:
I think that with a flimsy and easily damaged storage medium like floppy disks, copy protections which hinder making backups are a terrible idea. IMHO, the only acceptable copy protections are those not involving any formatting tricks. For instance, "Battle Chess" has a copy protection which is based on having the original manual. On start up, the game just asks for a move from one of the many classic chess games listed in the manual. Other games came as a game set which included gadgets like code wheels etc. which were needed to play the game. "Lenslok" is another example - but after many decades, the plastic material got brittle, so even that is not for eternity.
Still, back in the 1980s I saw both sides of the copy protection wars and used my mind to forge mighty weapons for either side, depending on which side just had betrayed me. I developed exactly one undefeatable copy protection for Atari which however somehow was leaked or stolen from me, and it appeared on some titles, but they only knew the basic idea of the format, and did not know my whole system, which would have protected any software without using any protection interrogation code, so nothing could be "cracked": if there is no protection code checking the exotic format, it can't be removed or neutralized. The end of the story is that I made no money from that innovation of mine, but those who used the half-baked solution on their software titles promptly fell prey of "crackers" who used the Atari equivalent of the Apple "Wildcard". A real pity of lost opportunities both for the software industry and me. Despite of my efforts I never found out how the other developer of that protection had learned of my method. Really, really weird.
Now, as for the "crackers". IMHO these were worse for the software industry than those "software pirates" wielding copy chips (in the Apple II world, Locksmith and the like. But Atari 8-bit always needed a hardware upgrade in the floppy disk drive, a new firmware ROM in the simplest case). The reason is that once a "crack" is done and out, every school kid with a sector copier (or, if the "crack" was a file, with DOS) could make further copies, which then spread like wildfire.
One interesting philosophical question comes out of this conundrum: if a software house chooses a weaker protection instead of a "hard" one, so that those with the copy chip / copy "enhancement" hardware could copy it, but the school kids could not, due to lack of money for the copy chip, wouldn't that deter "crackers" because they could make copies without spending any time on the crack, and hence, keep the software title from circulating in school yards ?
I think that some reasoning along these lines of thought may have contributed to the non acceptance of the "harder" copy protections. Which always have been available, since the early days of floppy disk mastering machines, and despite of that, many software houses used abysmally primitive copy protection formats which could be reproduced with the standard floppy disk controllers that came with these microcomputer systems. It is really easy to design some exotic format that can't be reproduced, say, on a DISK II controller, or a WD279x or WD177x LSI FDC. The harder part is to embed the check for the protection in the software such that it cannot be removed too easily. I had found the holy grail where no such check is necessary and still have the copy protection. Impossible ? No.
The problem with the "cracks", as I see it, is unclean cracks which may cause the software to crash on certain configurations of machines or, worse, make the software unusable. In the case of games, unplayable. Many software protection checks had two phases, the loader would do a coarse check and crash (or even say: "This is a pirated copy ... here you can order an original: ...") but later, finer, checks would make the game unplayable. Very subtle things like difficult jumps made impossible because the gap was widened by one pixel. Or turning potions needed to complete the game into poison (used in "Prince of Persia"). You can never really trust a crack. Some are better than others, though. I.e. "4AM" is really good.
The preferred method to preserve copy protected software titles from crumbling floppy disks (or from getting eaten by the mold / mould growing in them) are flux engines like Catweasel, AS, etc., and good floppy emus which can reproduce the RDDATA stream from the files made by these tool chains. But we can all see that some emulators are struggling to get it right, especially when "unstable bits" are involved.
As far as I'm concerned, I'm not working on preserving any disks. That work has been done by others many years ago. But I need to get up to speed with Apple II copy protections to qualify my DISK II and IWM substitutes with them. Especially the latter one is troublesome. I know I must add a legacy mode the original IWM does not have. Lots of tests with original copyprotected disks are needed for that. Before I don't know that my IWM substitute works with all the copy protections ever used on the Apple II, I can't release it and then I only have the DISK II substitute. Not sure if Apple ever cared about compatibility of the IWM with legacy copy protections. The read state machines definitely are different, which spells trouble. Hence, the proposed legacy mode.
But I do have a pet project which was unfulfilled for many decades: a newly produced 5.25" floppy disk which contains samples for all known copy protections for the Atari 8-bit. But since I got sucked into the Apple-1 and Apple II world, which is even more fascinating for me (because I know less about it, so I can explore more), the scope of this pet project is expanding. Maybe this floppy disk, if it ever gets done, will have two sides, one for Apple II, one for Atari 8-bit. But don't hold your breath - I have lots and lots of projects I want to complete before I die, and need to make choices which ones should get priority. Having good MMU, IOU and IWM substitutes has highest priority right now. After that, finishing my memory expander, color graphics, and floppy disk controller cards for the Apple-1. After that, I'll tackle the NMOS 6502. I want faithful RTL for it which is efficient. There is one version out there which was automatically generated from the SPICE netlist that came out of the "Visual 6502" project. But this version is not efficient (as faithful as it is). For the CMOS 6502, no such work is ever needed. You can buy the Verilog source code from Western Design Center. I did not ask Bill Mensch how much it costs. But certainly it's cheaper than my RQLT.
- Uncle Bernie
There is one insidious form of copy protection that has gained a LOT of traction today.
And that is the subscription based software license.
Adobe and Microsoft have moved to this model, whereby you have to shell out money every year (or month) in order to continue to use their software.
And more and more software packages used by industry are subscription based, and I point my finger at companies like QuickBooks, Simply Accounting, and any number of tools required by tens of thousands of restaurants and bars that pay huge sums monthly to use relatively simple software packages to track orders and meal tickets. Add the subscription fees for card processing services, too...
Back in the 90s you'd actually buy your accounting software (and pay a graduated license fee for the number of users) and then subscribe to the payroll and tax charts as they were issued each year, but that was optional...payroll tables are public knowledge that you could enter manually if you so chose. But now, if you fail to pay your subscription, you lose access to all your corporate accounting completely. Like those numbers are not even yours.
As a business owner one of the growing line items on my expenses are for "subscriptions". Every goddamn computer based thing is a subscription these days. And it costs a fortune every month.
This will end up being the ruination of software as a marketable product if it continues the way it does.
In post #17, 'baldrick' wrote:
" There is one insidious form of copy protection that has gained a LOT of traction today. And that is the subscription based software license. "
" This will end up being the ruination of software as a marketable product if it continues the way it does."
Uncle Bernie comments:
You are absolutely right. This is the worst software licensing model that exists. The same bait-and-switch happened with many electronics CAD tools, one example is the "Eagle" PCB CAD suite. I had bought some of their licenses for various machines when these were "eternal". Was happy with the software for more than a decade. Then CadSoft, the maker of Eagle, sold it to Autodesk and they changed to the subscription based model. Which, as you stated, "will end up being the ruination of software as a marketable product". I did not upgrade my Eagle licenses for that reason and bought a DIPTRACE license instead. Oh, Autodesk announced about a year ago that they would stop supporting Eagle after Y2026. So "Eagle PCB" is dying. Here is a link for those who want to know more (many Apple II folks used Eagle):
https://news.ycombinator.com/item?id=36231201
Where I can accept subscription fees is for tools like ForeFlight - they do have a lot of work to keep their database current with FAA releases. But if you do the math you will find out that buying charts at the local jet center is cheaper. And then you have the chart on paper, which is failsafe. And not in a non redundant tablet computer which also has these dangerous lithium ion batteries I don't want anywhere in the cockpit.
CONSEQUENCES
What will be the consequences of subscription based software be ?
If the subscription prices are reasonably low, people will accept it. They also accept monthly payment plans for smartphones ( I only use a prepaid dumb flip phone, need maybe $30 to fill it up every 3 months or so, lots of money saved).
But if the subscription gets too expensive, people will look for alternatives, and this is the opportunity for new software companies to get a foot in the market. Example: DIPTRACE. (So far they did not switch to a subscription model).
Last but not least, there is free / open source software. But there is a problem: somebody must maintain it. The pity is that most open source software is abandoned by the authors, put on github, or for HDL designs on OpenCores, and left there, unattended, to rot and die. Some open source software fares better because its development is founded by "foundations" and the like.
PROPOSED SOLUTION
A solution to this problem, as I see it, is to provide incentives for developers / maintainers of open source software to keep their stuff up to date and up to snuff. There should be some intermediary (like Patreon or GoFundMe - not necessarily the best choices, can't say, I never used them because I can finance my projects myself) where users of open source software can donate to pay for the maintenance and further development.
Some (honest) coordinator is necessary to vet prospective contributors and to pay out rewards to those who were accepted and make valuable contributions. Contributions of each individual could be tracked, and users could vote how valuable a particular contribution is. This provides positive and negative feedback which will attract and keep valuable contributors and deter / weed out those who don't make any contributions deemed necessary or worthy.
Organizing the process is not trivial. The human element is a big threat - corruption, cronyism, theft / misappropiation of funds, nepotism is a permanent threat to the success of the grand scheme. So it may be necessary to develop some form of AI, incorruptible, to handle this part of the task.
And I'm aware that, AFAIK, no software system has been built able to properly handle such a cooperative software development effort without human overseers ("managers"). I mean handling the code database, revision control, accepting / rejecting contributions - they can't be allowed to break the software, automatic regression testing can help here, finally, greenlighting releases. No AI needed nor wanted for these subtasks. Which already exist in some crude form, so it's doable.
Sounds a little bit like the fictional universe of "Star Trek" ? Well, I despise most of their basic rules as it boils down to Communism. Which we all know doesn't work, and never will work. But a cutthroat universe filled with gangsters, scoundrels, pirates, and mass murderous tyrants as seen in "Star Wars" is certainly worse, and we already have it in our real world, minus the SciFi tech of course.
So, who has a mind great enough to build such a software development system and website ? Github isn't it. OpenCores isn't it neither. Key elements of my scheme I mentioned above are missing from those. And I'm too old to build it. I now have humbler goals (like finishing and publishing my Apple-1 and Apple II developments before I kick the bucket). I'm sure that somewhere, out there, is a younger person with the programming skills to do it. With 8.1 billion people on the planet, there ought to be not only one, but a whole bunch of those candidates. I know that lots of young people look for business opportunities which are really new.
I showed you one for free ! Grab it, do it, get rich ! (The platform would be paid by the projects thereon, and those get funds by donations from users of the software, as decribed above).
- Uncle Bernie
With regards to open source software useful for hobbyists and pros, my vote goes solidly to two products:
Audacity - an incredibly well supported audio processing software with hundreds of functional plugins and modules.
And more to the point here: KiCAD, another superb piece of software that is actively maintained and widely accepted in both pro and amateur ranks and has probably more support and component data, footprints and symbols than the big pay-for equivalents, Eagle included (a package that I used to use 15 years ago because, well there was nothing better, and absolutely hated at the same time)
KiCAD is rapidly becomming one of the industry standards because almost all of the commercial products have gone to pricing and licensing models that are out of the reach not only for hobbiests and students but also small to even mid sized business. I've been trying to learn it better. Some parts of the UI seem a little clunky but it may just be I don't know what I'm doing. I have seen some positive progress in the past few versions of KiCAD and it seems like with the increased attention and use it is getting that it may start improving more quickly.
No it's not you, it's clunky. I really wish they didn't pull the plug on eagle last year (?) or maybe the year before that. I don't like learning new things just to do simple projects. =) A hundred more hours in and maybe it will just make sense... but that's a long way away.
I expect many others would agree Lane is a great guy, don't know the other author and agree with UncleBernie, if curious buy the book!!
Reminds me of a story after moving to cupertino, one of my friend coworkers invited me to dinner with his older brother who was working at (or had just left) EA. I was interested in getting into game development so was excited to meet the brother. At dinner when asked what he woked on at EA, his response was copy protection schemes! Oh man... so I started asking questions, and I had tons of question! Super smart guy, with lots of great stories. He also shared some experimental techniques they had played with. It was a very interesting low-level nuts and bolts conversation. I did not share that had spent years reversing some of his work!
I would later learn reversing copy protection schemes was a common gateway into game dev, and that's just a bit ironic. lol
I really wish that more companies when a commercial package reaches the end for them as a product that they would just release it as open source. In a way it would really be the best way to serve their existing customer base rather than just dropping support for something. Sometimes they may just drop an old product if they have something new that they want to move customers to, but in cases where that isn't a factor you'd think they wouldn't have a lot to lose by just giving it away.
In post #23, 'softwarejanitor' wrote:
" I really wish that more companies when a commercial package reaches the end for them as a product that they would just release it as open source. "
Uncle Bernie comments:
You can read my mind ;-)
However, having been a developer of a (expensive) commercial CAD software package myself, I can tell you that 'making it open source' is highy unlikely, once the software has been sold by the original developer to another party - the latter may be a software publisher, or a competitor, and herein lies the rub.
Unless the developer keeps the copyright (and then no software publisher or buyer will touch the software, not even with the proverbial 10 foot pole), then usually there are so many legal entanglements (read: opportunities for being targeted by a lawsuit) that it's more prudent for the last owner (or "caretaker") of the software to just bury it somewhere in a landfill (joking, in reality they will just put the source code somewhere in a company archive where it disappears, often because the storage media gets obsolete and nobody can read it anymore, and eventually it goes into a shredder or ends up in a dumpster. Some legacy Atari games and technical documents were 'rescued' by dumpster divers ...).
Yet another issue is this: Many software sales are triggered by a competitor who wants the competitive product off the market. The buyers usually are the big ones, to monopolists, or wannabe monopolists, and their own product loses sales to the one made by the smaller software house. So the big guy makes an offer that the small guy cannot refuse - Mafia style, because such an offer is often accompanied with the more or less veiled threat of a lawsuit over software patents, copyright violations, etc., and the big guy knows that the small guy never ever can pony up the money for his defense lawyers. The big guy can do that and by tricks can extend the lawsuit over many years, until the small guy would be bankrupted by his lawyer fees anyways, even if they could pony up the first retainer. The USA is particularly bad in this respect because the defendant can't hit the plaintiff with his own legal expenses, even when winning the lawsuit. So the big guy always wins, even if they lose the lawsuit. But the other jurisdictions are not much better - for instance, in most EU countries the losing party must pay the legal expenses of both parties, plus the court fees. But this only works for the small guy if he wins the lawsuit. If he goes bankrupt during the process, losing the lawsuit is almost inevitable (unpaid lawyers walk away) and then justice is not done. So, in most of these cases, the small guy will accept the offer he can't refuse, and sells. Usually, the buyer throws them a bone in the contract work, a clause which says they will support the software for X years. Now, see how Autodesk "supports" the Eagle package they bought.
So here you have two reasons why "open sourcing" of abandoned commercial software is unlikely to ever happen, especially if it was sold by the original developer. But if the original developer kept the copyright, then he can make it open source. Jordan Mechner did that with his "Prince of Persia" which IMHO is the finest game ever written for the Apple II. So it will live on as source code.
I am speaking out of experience. When my CAD software blew the competition out of the water so they could not sell any of their inferior competitive product anymore, they first threatened us with a lawsuit, and claimed the IP was stolen by one of us three partners, who previously had been a sales manager at their distributor. Who by the nature of the job never had access to the source code. We neutralized that threat by telling the story to the press and ridiculed the big guy by saying that their algorithms are so cr@ppy and outdated and braindead that stealing and using them would have made our software as bad and ineffective as theirs. Besides the fact that the algorithms they obviously used can be found in college textbooks, while ours were completely novel and based on "AI methods". Everybody (except the big guy) laughed and the lawsuit was off the table. Then came the offer to buy our software (for millions). I wanted to take the money and run, but my partners were so enraged by the threat of the lawsuit that they refused to sell. I had assigned the rights for the software to our LLC and so I had no option to bail and take the money. In the end we made less than if we had sold it to the big guy. But we still sold enough to become financially independent. Which means: no need to work in a job anymore. Which is good.
So I know first hand how that game is being played. That was ~35 years ago. Nowadays, with software patents, the game is rigged and the small guy stands no chance. This is why software patents should be declared null and void, and abolished. They are an abomination.
Readers might argue now that the small guy could use software patents, too. But this is a fallacy. The patent system as a whole is rigged, too. For the reasons I gave about the financials of lawsuits above. If you are an independent inventor and file a patent, you are an idiot (I am such an idiot, too, so don't feel offended). Everybody is allowed to have delusions about filing a patent and then getting rich with it. The point is that by filing a patent you gave away the crown jewels. You have to disclose how your invention works. The big corporations now can use your description to appropriate your invention for their own products. Without paying you a dime in license fees. You want to sue them ? Sure. Everybody laugh. Snare drum. Curtains. Was a good joke. (for reasons see above, financials of lawsuits). There is one example where in inventor who got ripped off by the big guys won his lawsuit. See the 2008 movie "Flash of Genius". The key point of this true story is that Robert Kearns, who invented the interval windshield wiper, and had an ironclad patent on it, was ripped off by the big guys (Detroit car makers) and these big guys just laughed because they knew that Kearns could never afford a lawyer, and hence, could not sue them for anything. But Kearns found a way. (I don't want to tell you more, not to spoil the movie for you. It is an absolute must see for any independent inventor).
So what is the conclusion. It is that it is highly unlikely that any company or software house would ever make their end-of-life software "open source". A few exceptions may happen, from time to time. But we can't count on that. And before "Software Patents" are not abolished, the chances of independent developers are slim. The only thing they could do is to make a "workalike" of ~20 year old software, such that any and all "Software Patents" have expired (life of a patent depends on each country, so be careful).
If you invent a new user interface, the best advice I can give to you is to never patent it. Instead, make demos and publish them everywhere. Make sure that some descriptions / photos of the demos appear in printed magazines or trade journals. This establishes irrefutable 'prior art' so the big guys who will get word of your invention sooner or later (this is inevitable) can't file and get patents of their own to steal the idea from you. Important: never tell anyone about the inner workings of your invention. So they can't steal it, but need to invest time and money to find their own mechanisms to implement the action that can be seen in the demo. And here is the key point: if they can do that and produce a copy that works as well as yours, you really don't have an edge. You had a good idea, but nothing that qualifies as "Flash of Genius". So whatever you had, most likely, was not worth to patent anyways, because the way to i m p l e m e n t it is too trivial, anyone could do it. So there must be some vital component, some "secret sauce", which is not obvious, not trivial, but quite difficult to understand, which gives your i m p l e m e n t a t i o n the edge over everybody else who is just a copycat. Then you have something that is worth to pursue / produce. And you have to produce it by yourself and then you need to be able to market it by yourself. Only then you will be able to make a good profit before the novelty effect wears off. Here is one example: DOOM. This game has many astounding innovations in the algorithms and the low level programming. No "software patent " necessary. Any competitor who is inspired by the visible game play and wants to make a knock off first needs to understand all the inner workings, and this takes a long, long time - long enough for "id software" to rake in the millions.
Time to go to bed (my hair is now dry). Hope it was a good read for you.
Uncle Bernie
This is basically what Autodesk did, they saw the opportunity, grabbed CadSoft and I think it was within a year switched to their subscription license model which... was also not backwards compatible and didn't work great for anyone not willing to move forward and never look back. Maybe fine for professionals, but not for many hobbists which I think must have been a fair percentage of Eagle users which isn't a surprise with their original pricing model when one can start simple for free and later upgrade if/when design complexities grow.
What would be nice is if the original EAGLE authors had their rights to any older version which could be used as a foundation for an open-source project. I'm think it's also something that anyone who worked on the project may be able to "quicky" create a framework from scratch for then the OS community take over. But who that worked on it would be insane enough to do that?!? I have a strong belief developers would flock to an OS-EAGLE project and it wouldn't take long before something quite amazing would be available. KiCad is nice, but it ain't EAGLE. For moderate sized "home" projects EAGLE may always be by favorite.
The curious thing with software patents is there's always other ways to skin a cat, patent lawyers are good at providing terms in very general (open-ended) ways but software patents would seem to be difficult to enforce. I think Copyrights would be easier, but they come with a different set of problems. Id's (lol, that's an timely reference given this thread!) fast inverse square root is a good example of an algorithm that deserves some protection but there are other ways to get the similar result at some additional cost.
In Post #59, 'jeff d' wrote:
a) " The curious thing with software patents is there's always other ways to skin a cat "
b) " Id's . . . fast inverse square root is a good example of an algorithm that deserves some protection. "
c) " I think Copyrights would be easier, but they come with a different set of problems. "
Uncle Bernie comments:
to a). Correct. This is how patents for 'utility devices' or 'manufacturing processes' actually foster technical progress. Competitors are blocked by the patent(s) as long as these are in force, and it they want to make a competitive product, they have to innovate and find another way to do it, which does not infringe upon any patents. This other way may be inferior or superior to the patented one. If superior, technical progress was made. If inferior, the product must be viable even if sold cheaper. When the USA still was an industrialized country, the latter applied to lots of her products ... innovation to make them as cheap to manufacture as possible. Being cheap, these products conquered the world market. But this has downsides, too.
to b) Incorrect. Algorithms as such are a mathematical method and can't be patented (in most countries). But if the algorithm is uses a clever method to employ a computer system, i.e. by special memory allocation tricks, it may be patentable. But then the claims for the patent will rotate around these tricks / methods of implementation and not on the algorithm itself. Back in the late 1980s, with my CAD software suite, I employed algorithms of my own design, some of which bordering on "AI", i.e. self learning about a state machine by planning experiments and executing them, and then reducing the findings to useful information to guide the ATVG process. Back then there was no way to patent this. I so I never did. And because I never published anything on how it works, technical progress was slowed down. A while ago I found a Y2016 paper from the Department of Energy:
K. Ohler and C. Miller, "Reverse Engineering Integrated Circuits Using Finite State Machine Analysis", PNLL-25330. They are basically where my own proprietary research had been a quarter of a century earlier. Their math is a bit more involved. But my algorithms could handle asychronous state machines, too. They also can use stacks of modern computing "blades". I had a lousy 80286. And forged successful commercial products out of it.
I mention this to show an example that not patenting an innovation (and not publishing its inner workings at all) means it disappears in a "black hole" and has to be reinvented / rediscovered by others, possibly decades later. So decades of potential progress get lost. This is the case f o r patents (even software patents) but as long as the patent system and patent infringement proceedings in a court of law are rigged against the individual innovator / inventor and for the big corporations, it is smarter not to patent and not to publish. Let the competitors spend lots of times and money while they try to reverse engineer your code or your IC. In the meanwhile, produce, market and sell your superior product and rake in the millions.
to c): Correct. The problems with copyright are manyfold. But the worst is that they 'live' too long. There should be an amendment to Copyright Law which is similar to what exists for Trademark Law (in some countries): the rule should be that if a copyrighted work is not commercially produced or sold for X amout of years, the copyright would become null and void. So anyone could then pick up the pieces and reproduce and sell them. The parameter 'X' would depend on the field of the copyrighted work. For computer firmware ROMs, it could be i.e. 10 years. So 10 years after the last Apple II variant has been sold, we could finally - legally - copy their firmware ROMs and make and sell Apple II substitute / replica stuff.
That would be great ! (But's it's daydreaming ...)
As for the same issue with trademarks, I actually challenged a registred trademark of a larger corporation which had fallen into disuse, but I wanted it for my own product. The effect was what they rubber stamped a few of their cr@ppy four function calculators with that trademark and displayed them prominently for sale at a kiosk of a subway station. Which happened to be used by may employees of the Patent and Trademark Office on their way to and from the job. (I did not get that trademark, but still made a lot of money with my product. It had all what it needs . . . the (R) was not needed).
Where software patents can get destructive, here are examples: suppose somebody patents the mouse pointer as "a movable object or symbol on a computer screen which indicates where user input action shall take effect". Or think about the infamous "shopping cart" symbol in online sales.
None of these are innovative (lack of inventive height) but could block (or at least bog down) the development of entire industries.
But for me, all these "adventures" with copyrights, trademarks, and patents are long over. The only thing which still bugs me is the copyright on Apple II firmware ROMs which will still last longer than my own anticipated life time. So I need to find a way to get around it ... otherwise, no "Replica 2e" could be sold as a kit. I think I have a solution but it involves one original Apple IIc firmware ROM to be supplied with the kit, or obtained by the kit buyer. It's still a long way to go ... because the 'code morphing' logic is not as trivial as it looked, considering the numerous bank switching schemes which were used with firmware Apple II slot cards.
- Uncle Bernie