gregf |
Ramtek's Trivia promoter
|
|
|
Reged: 09/21/03
|
Posts: 8615
|
Loc: southern CA, US
|
|
Send PM
|
|
Apple /// emulation bug-a-boos
10/14/17 05:22 PM
|
|
|
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.
|
|