Hello AF-members...
at another thread this topic was touched and i decided to move this off from that thread, because it´s worth to be treated in an own thread.
It started up with a statement that the Spple Dealers Disk may probably
not contain DOS on the disk to be required for booting.
DOS = > DISK OPERATION SYSTEMI´d be curious about the explenation how to use a disk WITHOUT DOS ????
The use of Apple Dealers Disk is impossible without DOS ! Only solution would be using
UCSD as operation system ( Pascal ). BUT also UCSD is a Disk Operation System !
Similar is valid to CPM and to ProDOS.sincerely speedyG
this caused rhis following reply:
DOS = > DISK OPERATION SYSTEMI´d be curious about the explenation how to use a disk WITHOUT DOS ????
Of course you can. All you need to do is make sure the program is coded to manipulate the hardware directly. Part of the appeal of Apple was that unlike other platform of the time, it's disk hardware is very... "soft," affording coders a lot of flexibility in disk format and copy protection schemes.
There's no requirement a program must go through DOS to access the disk. Plenty of application do not use DOS at all (granted a lot are games with ... interesting copy protections.)
Speedy, I've skewed off topic here. If you're okay with it, we can follow up through PM.
I do agree with the proposal that this topic is to complex to be treated within the thread of
"This is Laughable !" .... the purpose of that thread is treating the "skyrocketing prices"
on the market for used Apple parts far beyond worth of the items - and it should remain with that topic only...
therefor i decided to open this thread to the DOS topic to keep it apart from the other thread....
just besides it´s a very complex topic by itself and worth it´s own discussions.....
it could probably even get that complex like the former thread of the Mountain Computer Expansion Box.....
sincerely speedyG
Hello dorkbert,
the point is:
DOS is the definition of any kind of system accessing to the disk ( see encyclopedia or wikipedia )
even if you have integrated with several commandingroutines the access to the Disk within a program -
it still is then a kind of DOS ( Disk Operation System ).....
The only difference is, that it´s then a "homebrew" version and its integrated in the other program......
This statement is valid to any kind of system containing a group of routines, that permits you
to read from disk and
write to disk
with the inclusion of routines how to handle that access
( unless a somehow kind of DOS is present in RAM ) .
Just to point out this very clear: the moment you access a disk - you must have a kind of DOS present
for the further handling of that disk.....
Of course you can do this, by writing machine-code with poke-commands to memory or assembler routines collected
to a bunch of subroutines.....
- but the very moment you have booted a disk and want to access that disk again -
Applesoft itself won´t know how to handle tracks and sectors and Volume Table of Contents ( VTOC )
i.e. finding a file with a name - unless a kind of DOS-system is present ( even if it´s a "homebrew" version ) !
It´s not becomming DOS because it has been published to public or a modified version ( like Pronto DOS,
FDOS , ADOS, David DOS, Diversi DOS and many others... or even MS-DOS or OSxx ) or because it´s related to an entire other peration system like UCSD, CPM, SOS or whatever you like to call it....
to be very precise: any kind of "Operation System" contains a portion of Disk Operation System
- i.e. the shortform: any kind of OS contains a portion of DOS if it permits access to diskette or Harddisk
and its irrelevant, if that Portion is related to Diskettes and Harddisks or only to Harddisks - it still remains to be DOS !
it´s by definition a variation of DOS because it contains a group of routines to handle the disk.
And its also not becoming DOS because it has been separated in a independent kind of program,
that only contains the "disk-handling".
UCSD, CPM, SOS and other operation systems still contain a portion that belongs to the group of DOS
- it´s just another version and another kind ...
sincerely speedyG
On this point I would disagree with you. At least in the sense in which I think you meant it. The firmware of the Disk II controller contains a kind of proto-DOS, I suppose you could say. The moment a Disk II controller is given control to boot, it reads the first sector of any disk (and subsequent sectors up to the count specified in the first byte of the first track). You can't get off the first track with this capability, but it does allow you to read the disk and to bootstrap an arbitrary program (not even necessarily a DOS!) of short length. No DOS (beyond the firmware) required!
Proloc copyprotection
In this system a hole was made by laser within the disk and after that the disk was scanned to identify the track and sector that contained the laserhole......
then the programs were saved to the disk and the specific DOS version skipped the damaged sector.
in the next step the program was loaded with a editor and the trackno. and sectorno. of the damaged sector was added to the subroutine containing the copyprotection.
Thereafter if the disk was started by the user - somewehre between booting and a specific action related to disk access the program passed the copyprotection system and tried to write a specific group of bytes to that damaged sector and then tried to read back that content and verify it with the original sequence of bytes.....
Of course the verification MUST fail due to the fact that the sector is damaged and if the verification failed it turned out to be the original disk and the program will continue with its further operations after blocking away the error mesaage....
But if the writing happens to another disk ( without the laserhole in the specified trackno. and specified sectorno. ) the verify would solve to be the same content and turnback without error....
and in that case there was a routine started that will stop all action after a period of time
and display the notice - that it won´t continue with the wrong disk
or at least not before the original disk would be inserted for checking out the presence of the original disk by repeating the test to the damaged disk....
it might even have contained a routine to delete portions of the copied disk to disable any further bootup from the illegal copy.....
in severe cases that copyrotection system was called several times within the program at different stages of work...
cruel programmers even let the user continue work but disabled the saving of that work and / or printing actions...
in such case a user could even lose one or more hours of work without preleading warning as revenge for using an illegal copy....
How do i have to come around with this protection system ?
well first of all - it will require quite a bit of experienced knowledge in assembler programming, patching disks ( using sector editors like Locksmith ), and use of disassemblers...
i also must be aware that the copy protection must not be within the program itself
- but may be loaded at later stage by reading a overlay file or libraryfile from disk....
it might therefor be needed to scan ALL files used by the program....
next will be the need to disassemble all that programs for a group of routines ( identified by bytegroups )
in this special order:
actions previous........
write specific bytes to specific track and specific sector
read bytes from specific track and specific sector
verfify bytestring with specific bytes to content from previous reading
branch
if verfiy fails jump to routine "continue action"
if verify does not fail jump to routine "action on illegal copy"
(starting at this point "FU the user of the illegal copy" )
- start timer and set BA-flag to "bastard online"
- stop any kind of access to save data from programm if BA-flag is set to "true"
- if BA-flag is set demand insertion of original disk
- if original disk is inserted delete flag and set it to "good user online" BA-flag="false"
- if BA-flag is still set to "true" delete bootup-portion of disk...
- display FU-message
- crash system ....
after this portion of code is located it must be replaced with this code:
actions previous........
delete the following portion of code and replace by "jump to ignore fake"
write specific bytes to specific track and specific sector
read bytes from specific track and specific sector
delete this portion of code:
verfify bytestring with specific bytes to content from previous reading
and replace this previous portion by:
label "jump to ignore fake", replace result of verify specific bytes by result of verification is "fail"
branch
if verify is "fail" jump to routine "continue action"
because result was set by manual statement to "fail" the following code was never executed
and the program was copied/distributed illegal in working version containing the hacking code...
if verify is "not fail" jump to routine "action on illegal copy" and set BA-flag to "true"
(starting at this point "FU the user of the illegal copy" )
- start timer and set BA-flag to "bastard online"
- stop any kind of access to save data from programm, if BA-flag is set to "true"
- if BA-flag is set demand insertion of original disk
- if original disk is inserted delete flag and set it to "good user online" BA-flag="false"
- if BA-flag is still set to "true" delete bootup-portion of disk...
- display FU-message
- crash system ....
after the hackers detected this method of deactivating this kind of protection system
the next step followed up :
the programmers added within the program at a later stage of action a routine to verify that the above listed
portion of commands have not been altered by comparing this code with the former original code.....
so that portion of verifying code had to be located again by the hackers and deactivated by skipping that code again...
then it turned out to become needed, to search for a new kind of protection system....
end of this part of the story...
speedyG
Hello David,
i do agree with this explenation - but i explained in the further text that exactly after this very first access
a kind of DOS is required for any kind of further access to the disk !
and in the further place of that same text too:
and related specifically to the "Apple Dealers Disk" this is absolute valid !
after display of the menu parts of the disk with specific testprograms are loaded at later point
of action depending to the choice within the menu.... this will require in any kind of case at least a kind of "homebrew" DOS....
sincerely speedyG
Going by the logic of this thread I take it that any program that accepts keyboard input is a "Word Processor". Correct?
Yes. And the Apple II shipped with a TOS "Tape Operating System" in the ROM.
Hi Speedy,
Your definition seems to classify any routine (or collection thereof) that manipulates disk hardware as DOS.
I have a different definition of DOS, particular in the context of Apple II. My view of it is that a DOS must entails UI and external API for 3rd party applications.
Much of the commercial applications of the day integrates the disk access functions into its binary, and do not have even the notion of directory or external application interface. Such were the days when a singular application can pwn3d an entire machine
Hello to all AF-members,
well lets make things short:
@ eudimorphodon: nice joke - but fail in place .....
@ resman: nice joke too.... same reply....
to dorkbert: if you want to start putting the single words to a pair of goldscales, you should at least be fair enough:
to read correct and entire the text and then also make citation correct:
this does not sound like talking about a single "any routine"... shall we discuss this with a linguistic ?
and just to add to the other part of your reply:
DISK OPERATION SYSTEM does NOT contain the definition
that a UI MUST be integrated
NOR that a kind of API MUST be present,
allthough in normal case even a API ( even if it is of "homebrew type" )- in the sense of being a "system" recommends that a kind of API to entrypoints of the routines will be present - i.e. a DOS must for example not contain commands like catalog, copy or other commands to be present at a UI ! Even if it just contains the routines and they are only accessable by calls to the routines from within the program and the access is documented somehow it still will be by DEFINITION
a version of DOS ( allthough i would call such version "homebrew".
BUT in case you want to release a "homebrew version" of DOS to the public - it will be highly recommended to
integrate a kind of UI.
There seems to be very different level to the use of terms like "Definition" ....
otherwise such replies would not have taken place here... maybe i´m wrong in this place ....
i at least expected that there is a basic knowledge to decide between DEFINITION and COMMON USE of a term....
And it still remains BY DEFINITION => DISK OPERATION SYSTEM is a system of routines to perform access to a disk period.
We can continue this of course endlessly .... i just fear that the part related to the dependency and copyprotection will die upfront very fast and the thread will be killed unfortunatly by splitting hair.... intead of examining how the disk have been protected by manipulation of disks or DOS...
just my 5 cents...
speedyG
Uhm...
"fail-in-place"
A term used to describe the ability of an actuator to stay at the same percent of travel it was in when it lost its air supply. On SPRING RETURN actuators this is accomplished by means of a lock-up valve. On piston actuators a series of compressed air cylinders must be employed."
Thank you?
How is it a joke? An Apple II has *documented* software ROM routines for reading and writing various sorts of data to and from its built in audio tape interface. It's perfectly legitimate to call that a "TOS".
Anyway, what is the point of your linguistic hair-splitting? Sure, you can certainly plant your flag to the broadest definition of "DOS" to say that whatever custom disk operating routines a piece of copy protected software might use to fetch data off the disk, even if they're nothing more than a skeletal (and purposefully obfuscated) set of "Read some bytes at this absolute track/sector combination" routines do count as a "DOS" within the context of application (or at least its loader) and be technically correct. But it seems to me that's entirely missing the point that was trying to be made in the first place, which is there are disk-based Apple II programs that don't run on top of DOS3.x/ProDOS/whatever (and therefore any assumptions based on those systems with regard to disk format/memory maps/executable format go completely out the window when you're discussing them). Those programs may have their "own DOS" but they're not "(Apple) DOS programs". Freaking out and insisting that the only definition of "DOS" is the broadest possible one doesn't really seem like the best way to add clarity to the subject.
Eh, whatever, do carry on. Just couldn't help but be amused by this thing going on here. Sorry for interrupting.
Just to be painfully pedantic, the definition of an Operating System is software that abstracts the hardware for higher level (i.e. application) software. You can find that definition in the link provided at the top of this thread. Take note: DOS != RWTS. Low level sector reading and writing is no different than the tape reading and writing in the ROM, from a conceptual standpoint (and not an OS, by definition). Many games and single-load programs on the Apple II just read data from a given sector range. That doesn't provide a high enough abstraction to qualify as a DOS. I challenge you to study operating system architecture, take a class, etc. instead of making up a definition.
Back on the (what I believe the original intended) topic of copy protection; that is a different operation from abstracted file I/O that a DOS would provide. Think of copy protection as file encryption on a modern OS. So there is no need to split hairs, just agree to abide by universally accepted definitions.
Dave...
Hello Dave,
lets start with the splitup:
first thing: i did complete study in university and finished successfully with degree in electronic engineering of microprocessors in Germany... and therefor i am aware and keeping to exactly that definition.....
an yes - i am very aware of architecture of operation systems, i even took part in the development of BSD UNIX...
you might even find my name there within several sourcecodes....
next: do you realy keep up to that definition ? Just to remind you to the very exact point of the definition:
the very first access to the disk might be taken by entering the routine of the ROM at the controller....
But only a very small amount of games remain at that point and NEVER again perform access to the disk !!!
Most games ( and applications ) permit to save status of the player within the game or access helpfile or at least permit to save
highscore..... and most games are working with overlays and libraries permitting to load maps or hires graphics to the hirespage locations depending to the status of the game....[/b]
So remembering this and turning back to the question:
MOST games and applications have a further access to the disk more than the initial load and therefor require by DEFINITION
a kind of DISK OPERATION SYSTEM....
Just to keep up splitting the definitions by turning to the levels:
Top of the level is the operation system
UI and API of DOS are applications above DOS to provide access to DOS
DOS is only part of the operation system
DRIVERS to access hardware are next level below)
so back again to my remark to your first reply ..: good joke...
but before entering discussion
- it´s wise to read carefully
- it´s wise to think about what you want to explain....
just to compare your first reply with the posting from david-schmidt...
his argument was precise and explained exactly a point i havn´t explained within my text
but i did agree immediatly with his text because it explained a very important point remember too...
and to get along with the copyprotection systems:
file-encryption was rather rarely used at games and/or applications ( if we leave the hardware protection by dongles out of this view at this point of discussion )....
In the days of the Apple II most games and applications have been copy-protected with manipulation of DOS
by:
- changing manualy the checksums ,
- manipulating speed of drives ( while copying them to disk ),
- relocating catalog tracks,
- changing amount of sectors,
- adding garbage tracks or
- manipulating the access of the disk to perform halftrack steps
- and so on....
is that enough hairsplitting ???
or do you want to explain one of the protction systems explained in the listing above and
explain how it works and howto overcome that protection ?
speedyG
So lets examine now the next copy protection system that has been used....
DOS adds to every sector of the disk at the end of the sector a so called "checksum"-byte
to be used for verification if the content of the sector has been changed or damaged...
the CHECKSUM trick....
Nearly every copyprogramm is written that way, that it performs a task of math
to get the checksum of a sector and compare that sum with the sum that has been
copied from the original disk.... if that two amounts are not the same, the
copyprogram will believe it had made a mistake or the sector to be damaged and stop copy procedure with a
errorcode and turn back to menu, questioning how to handle that error, or it just will stop
the procedure of performing to copy the disk....
At the other side within the program on the original disk there will be a routine to ignore
the manipulated checksums and resulting wrong errorcodes while reading the disk and just continue with reading....
If the original disk is inserted it will just keep on performing the reading and then skip to
the program after it has been loaded and
at later point in the program it performs a read to various sectors and checks if the checksum is still wrong
- if that is true it should be the original disk...
if the checksum has been corrected
this correction to the correct checksum must have been performed by a copyprogram
and the disk must have been copied and
therefor the original disk is not present in the drive....
and then the copy protection routines will be triggered similar to the
shematic that has been explained at the PROLOC system above....
This copy protection system just targets to the copyprogram and its behaviour
targeting to prevent it from performing the task of generating a copy of the disk
by forcing it to handle errors...
In such a case the solution to overcome the trick is - to set the parameters/options of the copyprogram
that way that it gets the instruction to
just ignore the errorcodes and
continue the task of copying the disk just right ahead and
keeping the wrong checksum from the original disk
instead of using the sum resulting from it´s own math work......
This was a rather simple protection system and it was used rather more in the early days of the Apple II...
the most companies that made copyprograms offered later a revised version of their program
and added the ability to set such options:
of ignoring errorcodes and
not insisting to correct the wrong checksum...
that was the end of using this copyprotection system and new systems were developed....
speedyG
the next copyprotection system explained in this posting is the
trick to make disks by using diskdrives with manipulated drive speed
this trick results from the fact that under normal conditions
the amount of bytes written to a disk sector is within a limited/defined amount.
If the drive is manipulated in drive speed the sector may be extended to
contain a larger amount of bytes than defined in the specification of the
Disk Operating System. Of course this will also result to the fact that
the reading disk or a disk writing the same content to another drive without
manipulating that drivespeed too will result to errors
because of couse that amount of bytes won´t fit anymore within a sector written
with "normal" speed and
that the copyprogram does not know how to deal with that errors....
Another point is that reading a disk with additional bytes is more easy than
writing the additional bytes to a drive with normal speed....
and of course of working with a drive, with manipulated speed
the DOS-system on that disk must be manipulated to and instructed
to permit a sector to contain that additional amount of bytes....
for additional information about diskspeed and sectors just jump to:
http://www.harrowalsh.de/Elektronik/APPLEBOX/appleboxdiskiipage2.htm
I´ve explained in that page at the beginning, this topic in brief overview....
Up to this point we may just remain with the statement, that it is not possible to
copy the content of a disk that has been generated with far lower diskspeed
to another drive and it´s disk if that drive is operating with normal speed .
If a hacker wanted to copy such a disk in former days he had to perform several steps:
1st he had to find out hom many bytes have been within a sector....
2nd he had to find out how far to slow down the speed of the drive
that would permit him to copy that amount of bytes to a sector... and
3rd he was forced to adjust the speed of the targetdrive that shall write the copy
of the disk to the correct slower speed
4th copy the disk
and finally then after the copy had been finished again turn back and adjust the speed
of that drive to normal speed....
and of course he had to turn off all corrections that a copyprogram would like to perform:
he must adjust the amount of bytes per sector to the correct amount with lowered speed
he must turn off the attempt to correct the checkbyte and take the originl one
and leave it the way it is...
and of course afterwareds turnback to normal conditions when copy has been made
he also has to restore the settings of the copyprogram
disks containing such protection system could only be copied with copyprograms that offer
the option to copy in "track copy mode" - with the option set to copy in "byte copy" mode
like later versions of copy II plus from Cental Point Software with version above 4.2
or Locksmith or Nibbles away II. In general you can say that such disks con only be copied
with advanced experience...
the only option for normal user to copy such program was the use of a
interfacecard like the crackshot or the wildcard - because such cards just picked up
the image of the program while it was resident in the memory and saved that back to a normal disk...
and that option was limited to such programs or games that did not contain additional hidden
routines about cheking/verifying the disk in the drive at low level access...
otherwise a check to the checksum would fail and detect a copied disk...
speedyG
In this posting i will treat several rather more simple tricks for copyprotection from the more early days of the Apple II... and besides talk a small bit about very powerful and usefull tools for disk manipulation that might also be used when discussing later methods of copy protection...
At this point we may just stop a short while and think a little bit in general about copyprograms.....
in general its meaning is that programs residing in one location are reproduced in a second location...
but for better understanding the user schould be aware that there are 2 different ways to attempt this goal...
the first and most simple attempt is to copy the source file by file from one disk to another...
this is performed in general by the filecopy-programs....
in most simple form by a command of the operation system like sopy *.* s6,d1 s6,d2 which will take
file by file all files from the drive 1 attached to the controller in slot 6
to the drive 2 attached to that controller and save them at the targetdisk drive 2 to the disk.
By making more precise command the user may instead of copying all files instead choose the option
to only copy a group of files with selected files remaining at the source without transferring them....
The other method is the so called imagecopy. In this case the copyprogram will transfer the content
from to another disk track by track. This can be for example performed by the operation system itself
with the command copy s6,d1 s6,d2 without specifying files with wild cards or similar ( i.e. *.* ).
In such case the result should be that the targetdisk is nearly a exact copy of the source disk.
To explain the difference: While using the filecopy command it is not mandatory that the file transferred
will reside in the targetdisk within rhe same group of tracks and sectors.... if for example the operationsystem
has detected before the copy command was issued a damaged sector it will skip that sector and save the file
in alternating sector that is not damaged....
Within the later years of the Apple II therefor the most commercial copyprograms offered to use the one or the
other mode just by selecting within a menu which method should be used....
the reason was that each method had it´s advantages and besides also it´s disadvantages....:
using the trackcopy method for example beared the risk that information would be transferred
to a damaged sector in the target disk resulting to a partialy damaged disk with not readable sectors.....
- relocating catalog track ans other simple tricks
At the other hand it was rather simple to manipulate a disk and thereby prevent the simple filecopy programs
to complete their task. One of the most simple tricks in the early days was to use programs that
have been distributed by the Beagle Brothers (*). They offered several programs that permitted to
cheat DOS. With one program for example the catalog track could be relocated to another track and
a computer that booted normal DOS wouldn´t find that Catalog and therefor the user had no access to the filenames.
It was neccessary to boot exactly the cheating disk to get DOS loaded that way that it knew where at
the disk the catalog had been hidden.
To read about the trick see the manual of Utility City from the Beagle Brothers at page 25: COPY STOPPERS
Another program offered to rename files on the Utility City Disk from the Beagle Brothers is the program
FILENAME ZAP explained at page 28 of the Utility City Manual by editing the
entries in the Catalog and therby using "lllegal" characters. You might sometimes recognize this when
viewing old disks and viewing flashing characters in the catalog of the disk or
seemingly files with same identical filenames....
so if a mein program was hidden behind the second similar title in the catalog the filecopy refused to copy it
and if it was copied anyway, then the creator of the disk made several more similar sounding fileentries
and there was risk of again overwriting the important main programfile....
and some other utilities permitted to change the display of the correct filelength,
so that a user later viewing the catalog didn´t know behind which file the real programfile was hidden...
Just besides : the Utility City disk contains in the manual also other neat little snippets like
hiding commands within programlines at Applesoft which will prevent the User while performing
a list on your program, to read the real content at the line by displaying a fake content...
(*) The disk "Bag of Tricks" from the Beagle Brothers contained 4 programs:
TRAX permitted to read any kind of disk - ignoring any kind of mistakes -
and dumping the content track by track and sector by sector to the display.
This anables the User to examine any kind of desk or diskprotection system....
it also contains a editor that permits to alter the content of the sector and
write that altered information back to the disk....
- in other words : Trax is e very powwerfull "sector editor" program
Fixcat is a program to correct a damaged catalog ( or the Volume Table Of Contents below at disklevel )
to restore a damaged VTOC and to detect and sometimes also restore deleted files....
INIT is a tool that permits the user to format or write single selected tracks on a disk
- without touching the other tracks and even changing order of sectors or the amount of sectors...
this for example would permit to write a track with only 13 sectors to a disk
with the remaining tracks containing 16 sectors.... so this is a very dangerous and powerfull tool !
ZAP is one of the most powerful "sector editors" availiable... it reads anything you kick in the drive...
no mater if the disk is in DOS or UCSD or CPM format.... and you can manipilate any secotr in the disk
just the way you desire the sector to look like... but of course it´s same dangerous like
TRAX.... so you also take risk to produce devasting results up to non accessable disks after
performing wtriting operations - if touching sectors occupied by the operation system....
therefor before you use any of this 4 porgrams it´s highly recommended to follow up the following advice !
And of course : DONT TRY TO USE THIS PROGRAMS WITHOUT READING THE MANUAL - BEFORE STARTING THAT PROGRAMS !
ZAP and FIXCAT have both been made by Don Worth the author of "Benath DOS" one of the most
compehesive tutorials about DOS and the stuctures of disks at low level.
TRAX and INIT have been created by Pieter Lechner, who had same distiguished level of knowledge
to DOS and low level structures on the disk.
Before using this disk and it´s tools it´s highly recommended in not to say obligatory to read
the book "beneath DOS" from Don Worth before attempting to the use of this tools
- otherwise a lot of damaged disks will turn out to be the results of such attempts....
This advice is also valid before using tools like the sector editor within Locksmith,
or Nibbles Away II.... otherwise the user will carry same risks of damaging disks....
Another package by the Beagle Brothers is DOS BOSS - it contains in the manual a lot of little tricky programlines
to do very nasty things with your disk like saving a boring copyright notice within the catalog that is nearly irremovable....
and the manual contains a lot of other nasty tricks for simple copyprotection at catalog level of normal DOS.
In such cases a filecopy program will refuse to copy a files with the seemingly same filename a second time but
in another filespace... it believes that the command is repeated and asks if the file is realy to be copied
and then - it copies the seemingly similar file to the former filespace of the previously copied file
and overwrites the former other file !
But in such cases it was easy to overcome that kind of tricks by using a copyprogram in track copy mode.....
speedyG
I decided to open this thread to the DOS topic to keep it apart from the other thread.