Who is the author of Locksmith?

[Toinet]

Hi All,

Just wondering whether the author's name was known or not. I have
always heard that nobody knows who the author of the program is. As
far as I am concerned, I do not know who he is and I would like to
know.

Regards,
antoine

[vladitx]

Sir Toto, I'd like to know as much. Locksmith 6.0 is one of the
greatest Apple II software.

[Bill Buckels]

Donald W. Larson wrote:

>In August 1982, I was hired as the Customer Support Manager for Omega
>MicroWare, Inc., publishers of LockSmith and other Apple II disk utilities.

>LockSmith was the premier copy program of the day for Apple II's. It had
>ways to nibble-copy disks, edit specific headers and trailers of sectors,
>and manipulate parameters to overcome almost any copy-protection scheme.
>Omega MicroWare sold tens of thousands of copies of LockSmith in the early
>1980's.

http://static.userland.com/userLandDiscussArchive/msg018908.html

[Toinet]

Thank you Bill,

That does not give the programmer's name, alas !

antoine

[CC Rider]

From Hardcore Computing Issue 1, page 10:
Dave Alpert is the head of Omega Software, Inc. as well as the
president of the Northern Illinois Apple users Group.
HARDCORE: Did you write Locksmith?
DAVE: No.
HARDCORE: Then who wrote Locksmith?
DAVE: I am not allowed to talk about the author.

[CC Rider]

Omega Microware names that I have seen include:
Donald W. Larson
Dave Alpert
Ron Metzker
Bob Noll

The question I would like to ask the author, unless someone else
knows, is about the 5-6 minutes it normally took to copy a single
disk. Was there a delay loop built in? I recall hearing about this
but was never able to substantiate it.

Clay

[vladitx]

On Mar 9, 10:33 pm, CC Rider <alask...@yahoo.com> wrote:

> The question I would like to ask the author, unless someone else
> knows, is about the 5-6 minutes it normally took to copy a single
> disk.  Was there a delay loop built in?  I recall hearing about this
> but was never able to substantiate it.

Do you mean the bitcopy? It needs time analyzing each track data (if I
understood your question properly) and probably does few revolutions
of read attempts to sync.

I personally don't understand why the brilliant Locksmith author(s)
preferred to stay in the shadows, maybe they feared something back
then. But today, only appraisals are left. :-)
I'd definitely want to get in touch with them and buy them drinks
(note: they can contact me in private email). :-)

There was even Locksmith for the IBM PC and I've fiddled with it, but
it was nowhere near the Apple II. Could even be a product of another
company/authors, can't remember any details.

[Michael J. Mahon]

vladitx wrote:
> On Mar 9, 10:33 pm, CC Rider <alask...@yahoo.com> wrote:
>
>> The question I would like to ask the author, unless someone else
>> knows, is about the 5-6 minutes it normally took to copy a single
>> disk. Was there a delay loop built in? I recall hearing about this
>> but was never able to substantiate it.
>
> Do you mean the bitcopy? It needs time analyzing each track data (if I
> understood your question properly) and probably does few revolutions
> of read attempts to sync.
>
> I personally don't understand why the brilliant Locksmith author(s)
> preferred to stay in the shadows, maybe they feared something back
> then. But today, only appraisals are left. :-)

No doubt they were concerned about being named in a lawsuit...

Corporations provide significant immunity for individuals, so I'm
sure they'd prefer that the corporation be sued. ;-)

-michael

******** Note new website URL ********

NadaNet and AppleCrate II for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

[vladitx]

On Mar 10, 2:58 am, "Michael J. Mahon" <mjma...@aol.com> wrote:

> No doubt they were concerned about being named in a lawsuit...
>
> Corporations provide significant immunity for individuals, so I'm
> sure they'd prefer that the corporation be sued.  ;-)

True. But the drink offer is still valid (along with guarantee to keep
their names secret). :-)

OTOH, Nibbles Away with it's NADOL was quite similar to the Locksmith
"parameters" in the end result - providing ready way to copy certain
title. Same with Super Copy. Were their authors kept hidden too?

[joj...@gmail.com]

Dear Clay,

Disk Muncher by The Stack of Corrupt Computing could copy 140K non-protected DOS 3.3 floppy in 27 seconds.

http://www.moofgroup.com/moof/Roby_Sherman/Adventures_in_Silicon/Entries/2006/12/24_READING,_ANALYZING,_WRITING,_VERIFYING.html

[joj...@gmail.com]

What I appreciate the most as a programmer, is LockSmith 6.0 Boot Tracer. It's truly a great 6502 emulator that runs on 6502 itself :-)

Started from Locksmith 4.0 Nibble-counting routine that is made specially for Apple LOGO, I then look at the reading & analyzing routine of Locksmith 3.0, several versions of Copy ][ Plus, EDD, Back-It-Up, Nibbles Away. I also went into Lock-It-Up RWTS on how they read and write.

My first Wowwww was with the way Nibbles Away C2 used to detect bit-insertion : LDA $C08C,X, followed by CMP $C08C,X in the next instruction to see if the register is shifted or not.

After that, Framing-bit analyzer routine inside LockSmith 6.0 is one of the most CPU clock cycle crtitical routine I've every seen.

BTW. LockSmith PC is from Alpha Logic Business.

[qkumba]

> Started from Locksmith 4.0 Nibble-counting routine that is made specially for Apple LOGO, I then look at the reading & analyzing routine of Locksmith 3.0, several versions of Copy ][ Plus, EDD, Back-It-Up, Nibbles Away. I also went into Lock-It-Up RWTS on how they read and write.
>
> My first Wowwww was with the way Nibbles Away C2 used to detect bit-insertion : LDA $C08C,X, followed by CMP $C08C,X in the next instruction to see if the register is shifted or not.

My biggest wowww was the protection technique that attacks a vulnerability in the EDD and Copy ][ Plus read routine (and perhaps others, since it's the same code). By strategically placing timing bits across the track, and then counting the nibble sequences, you get a significant difference in the number between the copy and the original.

[Tempest]

Ah Disk Muncher. My go to disk copier from back in the day. I still use it to copy disks.

[Moose_S...@yahoo.com.au]

Baah, you want to see fast, copy a disk with BCOPY - the fastest disk copier I ever saw for the A][ (but it was only good for non-copy protected disks). IIRC, it beat the shit out of Disk Muncher.

[Tempest]

Probably, but I think everyone sticks with what they know. Plus it brings back so many memories.

[Michael J. Mahon]

And these fast copiers didn't verify that the copy was correctly written,
as I discovered when I was using Disk Muncher to keep backup copies of an
important data disk.

That was the day that I 1) learned more than I planned about low-level disk
format and 2) relegated Disk Muncher to the "cute toy" pile.

You get what you "pay" for...
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

[bpi...@gmail.com]

I also remember DISK MUNCHER being extremely fast. In fact, the fastest out there.

So, 30+ years later, it's a pleasant surprise to hear about BCOPY. I'd like to check out BCOPY. I searched and found references to a "BCOPY v1.5", but can't find a disk image anywhere. Would you kindly tell me where to find it? Thanks.

[mver...@libero.it]

Mac GUI have an excellent search function. You can find a couple of disk images with BCOPY.

Marco

[joltenjoe]

In 2009 or so cringely had article that Woz wrote locksmith but he had so many other errors like making it sound like IWM was there from beginning of disk ii.

Anyway in comments to that someone tossed out Mark pump who ended up running alpha logic later.

So many clues. However David m Albert of lake forest Ill wrote a letter to PC mag August 20 1885 explaining that an earlier article quoting him from esquire mag was wrong or never happened and that he distributed locksmith but Mark pump developed it.

There were a few discussions here in 2006 2009 and 2011. Mark pump is in a video debating locksmith with electronic arts or activision around the same 1985 period.

I would link it but safari for iOS is now a pain. It scrolls all over and entry screens don't stay put.

I don't know if Mark pump ever confirmed it or if he was just part of development team and there was someone else involved as well. (See "Mike's" comments to the cringely article )

[David Schmidt]

On 10/1/2015 11:36 PM, bpi...@gmail.com wrote:
> [...]

> So, 30+ years later, it's a pleasant surprise to hear about BCOPY. I'd like to check out BCOPY. I searched and found references to a "BCOPY v1.5", but can't find a disk image anywhere. Would you kindly tell me where to find it? Thanks.

Look for Beneath.Apple.DOS.dsk. It's not as fast as Deckard's FASTDSK
on reads, but it has the advantage of also writing. ;-)

[John Brooks]

I've recently been working making accurate bit-images of floppies (5.25 & 3.5). My current imaging util can bit-read all 35 tracks of a 5.25 into memory on an Apple IIGS in ~8 seconds.

I think this means that the theoretical fastest bit copy could be done in about ~16 seconds, or ~24 with a write verification pass.

The writes might take a little longer than 8 seconds since for the reads I leave the head-phase magnet active during the read as it allows head-settle time to overlap with header-detection. But for writing, I wouldn't want the stepper phase magnets drawing current while powering the head to magnetize the disk.

-JB

[Michael J. Mahon]

It certainly won't add any perceptible time to turn off the stepper
phases...and you *have* to turn off phase 1 to write.

There is no power issue, regardless of stepper phase state (unless you turn
all four on and leave them on for minutes--that will warm up the stepper).

[Moose_S...@yahoo.com.au]

On Friday, October 2, 2015 at 1:36:26 PM UTC+10, bpi...@gmail.com wrote:
> So, 30+ years later, it's a pleasant surprise to hear about BCOPY. I'd like to check out BCOPY. I searched and found references to a "BCOPY v1.5", but can't find a disk image anywhere. Would you kindly tell me where to find it? Thanks.

I've searched my hard-drive but cannot locate my disks with BCopy. It will be in one of my backups somewhere .... My poor Apple ][c died 10+ years ago, and I have not transferred any Apple ][ disks or used a real ][ since then. Back then, I uploaded at least 1 disk to Asimov containing BCopy (and my transfer software), but it looks like these disk images have been deleted or renamed ... The site index for Asimov does not contain any reference to BCopy, but there are lots of generic disks "copy utils" etc, and one of them may contain BCopy. I did a quick search on Mac GUI, and search results were returned, but I could not actually pin down a disk that contained BCopy (it's a matter of checking each result).

If / when I find BCopy, I'll post back here .... unless someone else has already found it and posted here. :)

[John Brooks]

On Friday, October 2, 2015 at 6:04:28 PM UTC-7, Michael J. Mahon wrote:

The speed gain is not in the time to turn off the stepper, but in the 36.6ms head settle delay just prior to turning off the last stepper phase before reading data.

Here's the Apple timing chart which shows the seek wait stages and times:
http://goo.gl/mergGO

Leaving the phase active while reading and skipping the head-settle wait saves about 1 second per pass of the disk (36ms*35tracks=1.26 seconds).

The disk spins at 300RPM, or 200ms per track. So a disk copy only spends about 15 seconds transferring bits from the source disk to the destination. The rest of the time is lost to delays for head step/recal, motor spin-up, and data analysis (looking for sector headers, etc).

-JB

[J. Random Hacker]

On 2015-10-01 23:13:28 +0000, Michael J. Mahon said:
> And these fast copiers didn't verify that the copy was correctly written,
> as I discovered when I was using Disk Muncher to keep backup copies of an
> important data disk.
>
> That was the day that I 1) learned more than I planned about low-level disk
> format and 2) relegated Disk Muncher to the "cute toy" pile.
>
> You get what you "pay" for...

Agreed. It was certainly quick but it sure seems like Disk Muncher ignored
checksum errors. It would happily copy dodgy sectors with zero retries but
you'd wind up with an invalid backup. I always used Fastcopy instead...

[Michael J. Mahon]

So how do you determine when you're reading valid data, since the head's
still moving?

The wait time is, of course, conservative, even for an SA400 drive, and
split band positioners are much faster, so in most cases the 36.6ms is more
than necessary. But reading between tracks will result in "noise" nibbles.


I suppose you can overlap the track read by at least 36ms (about a fifth of
a track) and then compare to determine where the nibbles became valid, but
that still costs the 36ms.

[John Brooks]

On Saturday, October 3, 2015 at 10:49:24 AM UTC-7, Michael J. Mahon wrote:

I've tried a few methods and have yet to settle on the best approach.

The trickiest timing to optimize for is motor-on as there is no information where the head is at or if there's even a disk in the drive. What Apple does with GS/OS is read until they get a valid sector header. That works great if your data is in a standard format, but not if the disk is protected with altered headers or is failing badly.

I've been using the GS $c02f 980ns 'pixel clock' timer to measure how fast nibbles are coming in from the disk controller and how many leading 0 bits were ignored by the controller. I can definitely see under-speed drive RPM after motor-on as well as irregular nibble read timing on unformatted tracks. However this technique has clock drift which is cpu intensive to correct, so I'm not sure this is the best final solution as I want to use head-step time for track analysis.

For track stepping I'm leaning toward using disk nibble validation to determine when to start reading. The basic idea is that the controller can return 128 possible values ($80-$FF), but only 66, or about 1/2 are written on both standard and protected disks. The rest are 'illegal'.

At 1/2 tracks, the head reads a lot of random bits resulting in a large number of illegal nibbles coming in. Once the head gets to within +/- 1/4 track the data reads correctly, so it isn't a requirement that the head be absolutely stopped before reading, only that it doesn't overshoot past +-1/4 track. Hence the advantage of leaving the stepper phase active so head-settle overlaps the track read time.

Interestingly, using nibble-validation as the trigger to start reading also minimizes reading misaligned byte-framed data as misaligned user-data in the data field will often return illegal nibbles until the byte framing syncs up. The problem with nibble-validation is that it doesn't work well for badly failing disks, but in those cases I can use a timeout to eventually read whatever data is there, legal or not.

I've also found that it is possible to read and write data on the disk with 3 consecutive 0 bits instead of the usual 2 as long as I reduce the read signal intensity by reading 1/4 track away from where the track was written. I've been able to write and read entire tracks of $88 nibble data, for example.

I believe this works because the amp-boosting behavior of the controller over-amplifies and reads an upcoming 1 bit too early after two 0's, but by reducing the signal intensity, it allows the 2nd amp-boost to succeed and not read the next 1 bit too early. However, the tolerances are very tight and some tracks read better than others, so I think this is more an interesting observation than something that could be reliably used to increase data density.

My 80's Apple II & GS games relied on writing and reading illegal nibbles for copy protection. Now I'm hoping to use those techniques to be able to archive copy protected disks without alteration, and also to image failing disks so they can be preserved and recovered with modern machines and software.

-JB
@JBrooksBSI

[Michael J. Mahon]

Very interesting, John! It seems we've been down some of the same roads.
;-)

So it's certainly possible to "cheat" on the track-to-track settling time.
Have you done any experiments (on various drives) to determine how soon the
head is close enough to read good data? I would think that a short
"experiment" on the outer tracks with decreasing delays would allow you to
determine adaptively the minimum safe settling time for a drive. Then the
next 30 or so tracks could be read with minimal delay (and without nibble
validation).

Nice work!

[John Brooks]

On Saturday, October 3, 2015 at 2:44:52 PM UTC-7, Michael J. Mahon wrote:

I have a small sampling of drive mechs and have been testing on the >1983 Unidisk half-height drives. I'm not sure exactly how these half-heights compare with the older full-height drives, much less the very early Shugart drives but I believe Apple said the Unidisk/Duodisk drives have better 1/2 tracking. Since I'm focusing on IWM control by the IIGS, the full-height drives aren't applicable.

The Unidisk reads data fine at +/-0.25 track and starts losing bits beyond about +/- 0.30 track.

Writes with the Unidisk alter bits at +/-0.40 track which explains why 3/4 tracking doesn't work reliably as the 0.8 track width can corrupt neighbor 3/4 tracks.

-JB

[Michael J. Mahon]

So, I'm curious...are you microstepping the head? Your reference to
non-quarter-track positioning got my attention!

[John Brooks]

Yes. I get additional tracks by micro-stepping. I'm also using a higher-density GCR encoding to get 19 sectors per track.

-JB

[Michael J. Mahon]

Very cool!

[bpi...@gmail.com]

> Yes. I get additional tracks by micro-stepping. I'm also using a higher-density GCR encoding to get 19 sectors per track.
>
> -JB

Absolutely amazing! So, if my math is correct, you get (35/0.8)*19*256 = 212,800 bytes per 35-track disk and 243,200 bytes per 40-track single-sided disk, assuming you use 0.8 track stepping? Quite a fabulous hack.

Using 512-byte sectors perhaps you could get 10 sectors / track?

I've been toying with doing this for YEARS. Would you enlighten us by sharing your custom RWTS code?

Back in the day, with MFM, I achieved 2.23 Mbyte per 1.44M disk, using an Alps drive which stepped out to 90 tracks, and single-sectored tracks of ~12400 bytes each.

[mmphosis]

The thought of increasing the disk space has crossed my mind too. I
wondered about micro-stepping, but I don't know enough about how the timing
with the stepping motor works or if it would work. Single sector tracks
might also add more available space. I used to format some of my disks with
36 tracks.

Again, assuming the 0.8 number...

35 tracks / 0.8 = 43.75 tracks
36 tracks / 0.8 = 45 tracks

[joltenjoe]

I assume Mark Pump created Alpha Logic so he could continue to distribute Locksmith himself but it appears the first 5-6 versions were distributed by Omega/David Alpert.

page 63 PC magazine August 20, 1985 David M. Alpert Omega Microware:


https://books.google.com/books?id=wtckANahGXIC&lpg=PA63&ots=aiIgvVjEQb&dq=mark%20pump%20pc%20magazine&pg=PA63#v=thumbnail&q=mark%20pump%20pc%20magazine&f=false

The Lowenstein article he responds to
https://books.google.com/books?id=vVNXxWE6BX0C&lpg=PA186&ots=rK7aK5OJGf&dq=david%20alpert%20pc%20magazine&pg=PA178#v=twopage&q=david%20alpert%20pc%20magazine&f=true

More reading on Locksmith 4.0 in Infoworld 2-1-1982
https://books.google.com/books?id=dT4EAAAAMBAJ&lpg=PA28&ots=yB41fnUgLQ&dq=david%20m%20alpert%20omega%20microware&pg=PA22#v=onepage&q=david%20m%20alpert%20omega%20microware&f=false

[John Brooks]

On Tuesday, October 6, 2015 at 12:57:17 AM UTC-7, bpi...@gmail.com wrote:
> Absolutely amazing! So, if my math is correct, you get (35/0.8)*19*256 = 212,800 bytes per 35-track disk and 243,200 bytes per 40-track single-sided disk, assuming you use 0.8 track stepping? Quite a fabulous hack.

I'm getting between 60 tracks & 66 tracks per side by partially overlapping writes and writing the tracks in ascending order. The 66 track version goes out to the head-stop at track 38 on my Unidisk drives.

> Using 512-byte sectors perhaps you could get 10 sectors / track?

I'm using 8 sectors of 608-bytes per sector (4.75k per track).

> I've been toying with doing this for YEARS. Would you enlighten us by sharing your custom RWTS code?

Yes, I plan on cleaning up and releasing the code once I finish my experiments.

> Back in the day, with MFM, I achieved 2.23 Mbyte per 1.44M disk, using an Alps drive which stepped out to 90 tracks, and single-sectored tracks of ~12400 bytes each.

Wow, that's a big gain with 10 extra tracks. I guess a lot of the gain was from single-sectoring?

I used 3.5" single-sectoring on Tomahawk GS in 1988 to get 924k per disk. The extra space and faster reads were was used to stream PCM music off the disk to the Ensoniq DOC. Tomahawk GS also debuted 3200 color mode on the title screen.

-JB

[bpi...@gmail.com]

> > Back in the day, with MFM, I achieved 2.23 Mbyte per 1.44M disk, using an Alps drive which stepped out to 90 tracks, and single-sectored tracks of ~12400 bytes each.
>
> Wow, that's a big gain with 10 extra tracks. I guess a lot of the gain was from single-sectoring?
>
> I used 3.5" single-sectoring on Tomahawk GS in 1988 to get 924k per disk. The extra space and faster reads were was used to stream PCM music off the disk to the Ensoniq DOC. Tomahawk GS also debuted 3200 color mode on the title screen.
>
> -JB

Very cool! Always wondered why more groups back in the day didn't tweak the disk capacity. Impressive gains can be realized with even modest optimizations, which 99.9% drives can handle.

My forays in the MFM world came very close to realizing the "2M unformatted" capacity of the 3.5" (I got to 2024k formatted capacity per 80 tracks). Using single-sectored tracks eliminates the gaps between sectors, and you can even slow the speed per revolution down a few ms to get some more bytes per track. Also tweaking the FAT12 / FAT16 filesystem a bit and max dir. entries of 16 or 32 and large clusters. I was lucky in finding a 90-track Alps drive which, to this day, still works. So, 200k+ of my extra capacity was due to the 10 extra tracks. To be on the safe side, for distribution purposes, I'd format with 84 - 85 tracks, which most good drives can handle.

[Patrick Asato]

On Sunday, March 8, 2009 at 2:38:59 PM UTC-7, Antoine Vignau wrote:
> Hi All,
>
> Just wondering whether the author's name was known or not. I have
> always heard that nobody knows who the author of the program is. As
> far as I am concerned, I do not know who he is and I would like to
> know.
>
> Regards,
> antoine

That would be awesome to know! I'm still looking for a .DSK image of the original Locksmith , the very first version , which I would imagine would be Locksmith 1.0 ? Anyone know of a site for this? I think this was the premiere software for Apple back in the day , so powerful.

THanks...

[joltenjoe]

The locksmith 6.0 manual gives a history and in it they state the first version was a proof of concept named NIBY or something like that. So I think it started out as version 2.0.

[David Schmidt]

On 10/8/2015 1:52 PM, joltenjoe wrote:
> The locksmith 6.0 manual gives a history and in it they state the first version was a proof of concept named NIBY or something like that.

Oh, the irony...

[mdj]

On Friday, 2 October 2015 09:13:31 UTC+10, Michael J. Mahon wrote:

> And these fast copiers didn't verify that the copy was correctly written,
> as I discovered when I was using Disk Muncher to keep backup copies of an
> important data disk.

I never used Disk Muncher, but LockSmith could do verify after-write (just type V), which of course doubles the "cost" of the write phase.

If you have a RAM card LockSmith also does a single-pass copy which saves a few seconds.

IIRC, verified copies are about 25 seconds (2 drives, single pass), unverified about 16 seconds.

> That was the day that I 1) learned more than I planned about low-level disk
> format and 2) relegated Disk Muncher to the "cute toy" pile.
>
> You get what you "pay" for...

I think it's fair to say that those who scored a noticeable productivity improvement from reducing a 25 second copy to 16 were in an unusual market niche ... ;-)

[Michael J. Mahon]

Clearly!

I suspect that Disk Muncher was used because it was so much faster than
COPYA, and free. ;-)

And we all know how much fun it is to spend more time building tools than
using them. ;-)