MAMEWorld Forums - EmuChat - Apple /// emulation bug-a-boos

So....what happens when Apple /// February 2014 emulation takes place a few years ago. You get user incidents similar to what has just been reported starting to appear. Seeing the blog entry on Friday 13th....which Apple /// dev writers walked under ladders, crossed paths with black cats, or accidentally walked on sidewalk cracks? Way to go.

*kidding/ragging*

Okay....so...expect some updates with associated source files later on? ;-)

src/mame/drivers/apple3.cpp

hash/apple3.xml

==
https://twitter.com/a2_4am

4am Retweeted

https://twitter.com/jrobj_/status/918795738615726080

https://robjapple.blogspot.com.au/2017/10/apple-advanced-visicalc-and-interesting.html

Apple /// Advanced Visicalc and an interesting discovery Friday, 13 October 2017

To summarise things:
- SOS has copy protection support built into the operating system (aka SSAFE)
- For programs using the protection, the sos.interp file is encrypted with a key stored on the original disk
- SOS uses eight volume numbers stored across eight track/sectors to 'hide' the key- The tracks are read in sequential order via a timed routine, and this expects a particular sector to be read on the last track, so they must be synced!
- When the disk is booted, the key is read and then the sos.interp file is decrypted with the key, and then run.
- without the key, the software cannot be decrypted and run!

I wonder how many other Apple /// software packages used this support. I could see it possible to read the key from the original disk and decrypt the sos.interp file and then make a new disk with this on it. Then the software would be permanently unprotected. This may be worthwhile if there are a few disks that have this protection used.

Wow, not how I thought this journey would have ended.