Purpose of two disk drives on the Osborne 1
up vote
8
down vote
favorite
I recently discovered the Osborne 1 computer, and I noticed it had two floppy disc drives.
What was the purpose of including two drives?
hardware floppy-disk cp-m
New contributor
add a comment |
up vote
8
down vote
favorite
I recently discovered the Osborne 1 computer, and I noticed it had two floppy disc drives.
What was the purpose of including two drives?
hardware floppy-disk cp-m
New contributor
4
By the way, the drives were named "A" and "B", and that is the precise reason why the hard disk was named "C".
– Mr Lister
Nov 30 at 7:15
1
I remember when I needed to make a copy of a whole floppy (ok, games...) from a single drive computer, there was some utility (under DOS), that was doing the copy in chunks, because the whole data did not fit in memory. So you had to switch to/from the original/copy floppies three or four times for the whole process to complete. That was very inconvenient.
– dim
Nov 30 at 8:53
add a comment |
up vote
8
down vote
favorite
up vote
8
down vote
favorite
I recently discovered the Osborne 1 computer, and I noticed it had two floppy disc drives.
What was the purpose of including two drives?
hardware floppy-disk cp-m
New contributor
I recently discovered the Osborne 1 computer, and I noticed it had two floppy disc drives.
What was the purpose of including two drives?
hardware floppy-disk cp-m
hardware floppy-disk cp-m
New contributor
New contributor
edited Nov 30 at 14:44
Thorbjørn Ravn Andersen
1769
1769
New contributor
asked Nov 29 at 15:27
BasementJoe
363129
363129
New contributor
New contributor
4
By the way, the drives were named "A" and "B", and that is the precise reason why the hard disk was named "C".
– Mr Lister
Nov 30 at 7:15
1
I remember when I needed to make a copy of a whole floppy (ok, games...) from a single drive computer, there was some utility (under DOS), that was doing the copy in chunks, because the whole data did not fit in memory. So you had to switch to/from the original/copy floppies three or four times for the whole process to complete. That was very inconvenient.
– dim
Nov 30 at 8:53
add a comment |
4
By the way, the drives were named "A" and "B", and that is the precise reason why the hard disk was named "C".
– Mr Lister
Nov 30 at 7:15
1
I remember when I needed to make a copy of a whole floppy (ok, games...) from a single drive computer, there was some utility (under DOS), that was doing the copy in chunks, because the whole data did not fit in memory. So you had to switch to/from the original/copy floppies three or four times for the whole process to complete. That was very inconvenient.
– dim
Nov 30 at 8:53
4
4
By the way, the drives were named "A" and "B", and that is the precise reason why the hard disk was named "C".
– Mr Lister
Nov 30 at 7:15
By the way, the drives were named "A" and "B", and that is the precise reason why the hard disk was named "C".
– Mr Lister
Nov 30 at 7:15
1
1
I remember when I needed to make a copy of a whole floppy (ok, games...) from a single drive computer, there was some utility (under DOS), that was doing the copy in chunks, because the whole data did not fit in memory. So you had to switch to/from the original/copy floppies three or four times for the whole process to complete. That was very inconvenient.
– dim
Nov 30 at 8:53
I remember when I needed to make a copy of a whole floppy (ok, games...) from a single drive computer, there was some utility (under DOS), that was doing the copy in chunks, because the whole data did not fit in memory. So you had to switch to/from the original/copy floppies three or four times for the whole process to complete. That was very inconvenient.
– dim
Nov 30 at 8:53
add a comment |
4 Answers
4
active
oldest
votes
up vote
23
down vote
accepted
Remember that these systems (not only the Osborne 1) didn't have harddisks. Everything ran from floppies.
So usually you had one floppy where the program was on, together with OS related files. And another floppy for your data, texts and so on.
That was workable with two drives, but still was impractical if you wanted to copy data. Usually there was some way to load a program and then use the first drive for a second data disk while doing the copying, but then you had to re-insert the system disk etc. So a third drive wouldn't have been too bad (but few systems had one).
TL;DR: You could never have enough floppy drives. Working with one floppy drive was a pain sometimes because you often had to switch disks; working with two was enough for most cases; and sometimes more than two would have been nice.
The same was true for other systems like the DEC PDP-8, which used DEC tapes pretty much the same way floppies were used on CP/M systems. And there were tape controllers which allowed for four tape drives. This was there for a reason...
3
I'd say the same thing is true for any floppy-based micro I've ever used. You needed two floppy drives for usability either as a boot disk+data disk setup, or for when you were making backups. One disk floppy systems were far less convenient for real work, but fine if you just booted games.
– Brian H
Nov 29 at 20:59
1
Yes, and the arrival of 3.5" disks made it worse; then you needed a minimum of four drives (two for each size).
– Mr Lister
Nov 30 at 7:13
@MrLister or 3 if you treated the 5.25" as "data in only" and used it only to migrate to 3.5" disks.
– Prof. Falken
Nov 30 at 9:27
1
@MrLister: Though by the time 3.5" floppies arrived, harddisks were not so expensive anymore. So the default configuration for that time was one harddisk, one 5.25" drive, one 3.5" drive. That was workable, even for copying disks.
– dirkt
Nov 30 at 9:56
@BrianH: Usability with a single floppy depended on the machine. Micros with OS &c in ROM and/or with plenty of RAM could easily make do with one. We had a BBC Micro with an OS ROM, a BASIC ROM, and additional ‘sideways’ RAM and ROM for various other things. Most programs were designed to load into and run from RAM (though a few big ones used overlays), and so you could then swap the program disk for a files disk. The only time it was a real pain was copying disks: being able to load only 20-odd KB at a time meant a lot of disk swapping!
– gidds
Nov 30 at 18:17
|
show 2 more comments
up vote
5
down vote
Note CP/M (the Operating system of the Osborne) didn't have subdirectories as we know today (which more or less forced you to dedicate a disk for a specific purpose in order to keep the overview), it also had very limited storage capacity per disk drive (~180k on a SS/SD disk as on the Osborne 1).
That means you typically held the application (for example WordStar, with a typical disk footprint of ~50-60kBytes) on one drive on a write-protected disk (in case it had to load overlays or messages) and the actual text you were working on on a disk in the other drive (the working disk). If you didn't want to be forced to constantly swap disks, you also put the operating system files on your program disk which also took some of the capacity.
You could have worked with only one drive, but that was much more cumbersome and carried the risk of destroying your program disk (because that could not be write-protected, then) or you had to change disks occasionally.
Obviously copying between disks was much simpler with a 2-drive setup, as others have mentioned.
1
Starting with CP/M 2.2, which I believe the Osborne I shipped with, it did have 16 user areas per disk so you could split up files and useuser 1
etc to switch between user areas.
– Brian
Nov 29 at 21:41
From what i understand, the user areas were similar to folders in MacOs 1.0; all files were stored in the same directory, but the user area number (or folder number) was treated as part of the name, so the within user areas 2 and 3, "foo.txt" would behave like "2foo.txt" or "3foo.txt", respectively. While write protecting master program disks would have been desirable, not all programs could usefully run from write-protected disks. The CP/M equivalent of batch files, for example, required the ability to write to the startup disk.
– supercat
Nov 29 at 22:23
@brian Right, but: On a 180k disk, user areas are not particularly useful - It doesn't make the disk space any larger. Many people didn't use user areas anyhow: they were more of a nuisance than useful because they simply hide files completely, and PIP.COM must be present in each user area you want to copy files into.
– tofro
Nov 29 at 22:28
1
@ChrisStratton You're drastically underestimating the dumbness of the average user ;)
– tofro
Nov 30 at 11:26
1
@supercat user areas were not part of the file name under CP/M.
– Thorbjørn Ravn Andersen
Nov 30 at 12:50
|
show 7 more comments
up vote
2
down vote
The Osborne 1, like many computers of the time, had no means of data storage other than floppy disks. On powering up, the user would be prompted to insert the operating system disk, so the machine could boot.
Even when running other software, the computer would need to access and run parts of the OS periodically. If you only had one floppy drive, you'd have to continuously eject and insert the OS disk and your data disk when running some commands. It was far more desirable to have two drives available, so the OS disk could be left in one drive for most of the time.
Having two floppy drives also speeds up copying files between different disks, but this is a secondary benefit.
The provision of two floppy drives was also common with other machines, such as the IBM PC and the BBC Micro (though the latter had its OS in a ROM on the motherboard). When hard drives were installed in computers, the OS could be installed there, and there was no longer such a benefit from having a second floppy drive.
1
Why would a machine of that error need to access the OS while running a program? Reloading the command-prompt handler after exiting would be commonplace, but if part of the OS got displaced by another program, it wouldn't be able to reload until that program gave up the memory, which wouldn't usually happen until that program exited.
– supercat
Nov 29 at 15:57
2
@supercat Just as now, an "OS" like CP/M included a collection of stand-alone utility programs as well as the permanently resident code. If you wanted to use CPM's "PIP" to copy a file from one disk to another on a single-drive system, you would have to (1) insert the CPM disk to start PIP (2) insert the first data disk to read a chunk of data into memory (3) insert the second data disk to write the data (4) repeat steps 2 and 3 till done. The probability of "user error" was not small! With two drives, you only needed to do one disk change. to swap the OS disk for one of the data disks.
– alephzero
Nov 29 at 16:09
1
@alephzero: When copying data from one disk to another, having two drives was better than one, obviously. My issue was with the first sentence of the second paragraph. If a program wanted to use PIP to copy a file, it would need to save its state and arrange things so that when PIP exited, the disk in the first drive would contain a file with a certain special name whose last block contained a command to re-run the original program and have it reload its state. Were there any programs that went through that rigmarole to use PIP rather than simply using their own internal copy-file code?
– supercat
Nov 29 at 16:46
add a comment |
up vote
1
down vote
Since the computer only has disk drives and no hard-disk, the normal usage was to have the system programs and a word processor or database handler on one diskette and using the other for data or documents.
Those drives were single side, single density as standard, which gave a storage capacity of somewhere around 100 kBytes each.
add a comment |
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
23
down vote
accepted
Remember that these systems (not only the Osborne 1) didn't have harddisks. Everything ran from floppies.
So usually you had one floppy where the program was on, together with OS related files. And another floppy for your data, texts and so on.
That was workable with two drives, but still was impractical if you wanted to copy data. Usually there was some way to load a program and then use the first drive for a second data disk while doing the copying, but then you had to re-insert the system disk etc. So a third drive wouldn't have been too bad (but few systems had one).
TL;DR: You could never have enough floppy drives. Working with one floppy drive was a pain sometimes because you often had to switch disks; working with two was enough for most cases; and sometimes more than two would have been nice.
The same was true for other systems like the DEC PDP-8, which used DEC tapes pretty much the same way floppies were used on CP/M systems. And there were tape controllers which allowed for four tape drives. This was there for a reason...
3
I'd say the same thing is true for any floppy-based micro I've ever used. You needed two floppy drives for usability either as a boot disk+data disk setup, or for when you were making backups. One disk floppy systems were far less convenient for real work, but fine if you just booted games.
– Brian H
Nov 29 at 20:59
1
Yes, and the arrival of 3.5" disks made it worse; then you needed a minimum of four drives (two for each size).
– Mr Lister
Nov 30 at 7:13
@MrLister or 3 if you treated the 5.25" as "data in only" and used it only to migrate to 3.5" disks.
– Prof. Falken
Nov 30 at 9:27
1
@MrLister: Though by the time 3.5" floppies arrived, harddisks were not so expensive anymore. So the default configuration for that time was one harddisk, one 5.25" drive, one 3.5" drive. That was workable, even for copying disks.
– dirkt
Nov 30 at 9:56
@BrianH: Usability with a single floppy depended on the machine. Micros with OS &c in ROM and/or with plenty of RAM could easily make do with one. We had a BBC Micro with an OS ROM, a BASIC ROM, and additional ‘sideways’ RAM and ROM for various other things. Most programs were designed to load into and run from RAM (though a few big ones used overlays), and so you could then swap the program disk for a files disk. The only time it was a real pain was copying disks: being able to load only 20-odd KB at a time meant a lot of disk swapping!
– gidds
Nov 30 at 18:17
|
show 2 more comments
up vote
23
down vote
accepted
Remember that these systems (not only the Osborne 1) didn't have harddisks. Everything ran from floppies.
So usually you had one floppy where the program was on, together with OS related files. And another floppy for your data, texts and so on.
That was workable with two drives, but still was impractical if you wanted to copy data. Usually there was some way to load a program and then use the first drive for a second data disk while doing the copying, but then you had to re-insert the system disk etc. So a third drive wouldn't have been too bad (but few systems had one).
TL;DR: You could never have enough floppy drives. Working with one floppy drive was a pain sometimes because you often had to switch disks; working with two was enough for most cases; and sometimes more than two would have been nice.
The same was true for other systems like the DEC PDP-8, which used DEC tapes pretty much the same way floppies were used on CP/M systems. And there were tape controllers which allowed for four tape drives. This was there for a reason...
3
I'd say the same thing is true for any floppy-based micro I've ever used. You needed two floppy drives for usability either as a boot disk+data disk setup, or for when you were making backups. One disk floppy systems were far less convenient for real work, but fine if you just booted games.
– Brian H
Nov 29 at 20:59
1
Yes, and the arrival of 3.5" disks made it worse; then you needed a minimum of four drives (two for each size).
– Mr Lister
Nov 30 at 7:13
@MrLister or 3 if you treated the 5.25" as "data in only" and used it only to migrate to 3.5" disks.
– Prof. Falken
Nov 30 at 9:27
1
@MrLister: Though by the time 3.5" floppies arrived, harddisks were not so expensive anymore. So the default configuration for that time was one harddisk, one 5.25" drive, one 3.5" drive. That was workable, even for copying disks.
– dirkt
Nov 30 at 9:56
@BrianH: Usability with a single floppy depended on the machine. Micros with OS &c in ROM and/or with plenty of RAM could easily make do with one. We had a BBC Micro with an OS ROM, a BASIC ROM, and additional ‘sideways’ RAM and ROM for various other things. Most programs were designed to load into and run from RAM (though a few big ones used overlays), and so you could then swap the program disk for a files disk. The only time it was a real pain was copying disks: being able to load only 20-odd KB at a time meant a lot of disk swapping!
– gidds
Nov 30 at 18:17
|
show 2 more comments
up vote
23
down vote
accepted
up vote
23
down vote
accepted
Remember that these systems (not only the Osborne 1) didn't have harddisks. Everything ran from floppies.
So usually you had one floppy where the program was on, together with OS related files. And another floppy for your data, texts and so on.
That was workable with two drives, but still was impractical if you wanted to copy data. Usually there was some way to load a program and then use the first drive for a second data disk while doing the copying, but then you had to re-insert the system disk etc. So a third drive wouldn't have been too bad (but few systems had one).
TL;DR: You could never have enough floppy drives. Working with one floppy drive was a pain sometimes because you often had to switch disks; working with two was enough for most cases; and sometimes more than two would have been nice.
The same was true for other systems like the DEC PDP-8, which used DEC tapes pretty much the same way floppies were used on CP/M systems. And there were tape controllers which allowed for four tape drives. This was there for a reason...
Remember that these systems (not only the Osborne 1) didn't have harddisks. Everything ran from floppies.
So usually you had one floppy where the program was on, together with OS related files. And another floppy for your data, texts and so on.
That was workable with two drives, but still was impractical if you wanted to copy data. Usually there was some way to load a program and then use the first drive for a second data disk while doing the copying, but then you had to re-insert the system disk etc. So a third drive wouldn't have been too bad (but few systems had one).
TL;DR: You could never have enough floppy drives. Working with one floppy drive was a pain sometimes because you often had to switch disks; working with two was enough for most cases; and sometimes more than two would have been nice.
The same was true for other systems like the DEC PDP-8, which used DEC tapes pretty much the same way floppies were used on CP/M systems. And there were tape controllers which allowed for four tape drives. This was there for a reason...
answered Nov 29 at 15:46
dirkt
8,84812447
8,84812447
3
I'd say the same thing is true for any floppy-based micro I've ever used. You needed two floppy drives for usability either as a boot disk+data disk setup, or for when you were making backups. One disk floppy systems were far less convenient for real work, but fine if you just booted games.
– Brian H
Nov 29 at 20:59
1
Yes, and the arrival of 3.5" disks made it worse; then you needed a minimum of four drives (two for each size).
– Mr Lister
Nov 30 at 7:13
@MrLister or 3 if you treated the 5.25" as "data in only" and used it only to migrate to 3.5" disks.
– Prof. Falken
Nov 30 at 9:27
1
@MrLister: Though by the time 3.5" floppies arrived, harddisks were not so expensive anymore. So the default configuration for that time was one harddisk, one 5.25" drive, one 3.5" drive. That was workable, even for copying disks.
– dirkt
Nov 30 at 9:56
@BrianH: Usability with a single floppy depended on the machine. Micros with OS &c in ROM and/or with plenty of RAM could easily make do with one. We had a BBC Micro with an OS ROM, a BASIC ROM, and additional ‘sideways’ RAM and ROM for various other things. Most programs were designed to load into and run from RAM (though a few big ones used overlays), and so you could then swap the program disk for a files disk. The only time it was a real pain was copying disks: being able to load only 20-odd KB at a time meant a lot of disk swapping!
– gidds
Nov 30 at 18:17
|
show 2 more comments
3
I'd say the same thing is true for any floppy-based micro I've ever used. You needed two floppy drives for usability either as a boot disk+data disk setup, or for when you were making backups. One disk floppy systems were far less convenient for real work, but fine if you just booted games.
– Brian H
Nov 29 at 20:59
1
Yes, and the arrival of 3.5" disks made it worse; then you needed a minimum of four drives (two for each size).
– Mr Lister
Nov 30 at 7:13
@MrLister or 3 if you treated the 5.25" as "data in only" and used it only to migrate to 3.5" disks.
– Prof. Falken
Nov 30 at 9:27
1
@MrLister: Though by the time 3.5" floppies arrived, harddisks were not so expensive anymore. So the default configuration for that time was one harddisk, one 5.25" drive, one 3.5" drive. That was workable, even for copying disks.
– dirkt
Nov 30 at 9:56
@BrianH: Usability with a single floppy depended on the machine. Micros with OS &c in ROM and/or with plenty of RAM could easily make do with one. We had a BBC Micro with an OS ROM, a BASIC ROM, and additional ‘sideways’ RAM and ROM for various other things. Most programs were designed to load into and run from RAM (though a few big ones used overlays), and so you could then swap the program disk for a files disk. The only time it was a real pain was copying disks: being able to load only 20-odd KB at a time meant a lot of disk swapping!
– gidds
Nov 30 at 18:17
3
3
I'd say the same thing is true for any floppy-based micro I've ever used. You needed two floppy drives for usability either as a boot disk+data disk setup, or for when you were making backups. One disk floppy systems were far less convenient for real work, but fine if you just booted games.
– Brian H
Nov 29 at 20:59
I'd say the same thing is true for any floppy-based micro I've ever used. You needed two floppy drives for usability either as a boot disk+data disk setup, or for when you were making backups. One disk floppy systems were far less convenient for real work, but fine if you just booted games.
– Brian H
Nov 29 at 20:59
1
1
Yes, and the arrival of 3.5" disks made it worse; then you needed a minimum of four drives (two for each size).
– Mr Lister
Nov 30 at 7:13
Yes, and the arrival of 3.5" disks made it worse; then you needed a minimum of four drives (two for each size).
– Mr Lister
Nov 30 at 7:13
@MrLister or 3 if you treated the 5.25" as "data in only" and used it only to migrate to 3.5" disks.
– Prof. Falken
Nov 30 at 9:27
@MrLister or 3 if you treated the 5.25" as "data in only" and used it only to migrate to 3.5" disks.
– Prof. Falken
Nov 30 at 9:27
1
1
@MrLister: Though by the time 3.5" floppies arrived, harddisks were not so expensive anymore. So the default configuration for that time was one harddisk, one 5.25" drive, one 3.5" drive. That was workable, even for copying disks.
– dirkt
Nov 30 at 9:56
@MrLister: Though by the time 3.5" floppies arrived, harddisks were not so expensive anymore. So the default configuration for that time was one harddisk, one 5.25" drive, one 3.5" drive. That was workable, even for copying disks.
– dirkt
Nov 30 at 9:56
@BrianH: Usability with a single floppy depended on the machine. Micros with OS &c in ROM and/or with plenty of RAM could easily make do with one. We had a BBC Micro with an OS ROM, a BASIC ROM, and additional ‘sideways’ RAM and ROM for various other things. Most programs were designed to load into and run from RAM (though a few big ones used overlays), and so you could then swap the program disk for a files disk. The only time it was a real pain was copying disks: being able to load only 20-odd KB at a time meant a lot of disk swapping!
– gidds
Nov 30 at 18:17
@BrianH: Usability with a single floppy depended on the machine. Micros with OS &c in ROM and/or with plenty of RAM could easily make do with one. We had a BBC Micro with an OS ROM, a BASIC ROM, and additional ‘sideways’ RAM and ROM for various other things. Most programs were designed to load into and run from RAM (though a few big ones used overlays), and so you could then swap the program disk for a files disk. The only time it was a real pain was copying disks: being able to load only 20-odd KB at a time meant a lot of disk swapping!
– gidds
Nov 30 at 18:17
|
show 2 more comments
up vote
5
down vote
Note CP/M (the Operating system of the Osborne) didn't have subdirectories as we know today (which more or less forced you to dedicate a disk for a specific purpose in order to keep the overview), it also had very limited storage capacity per disk drive (~180k on a SS/SD disk as on the Osborne 1).
That means you typically held the application (for example WordStar, with a typical disk footprint of ~50-60kBytes) on one drive on a write-protected disk (in case it had to load overlays or messages) and the actual text you were working on on a disk in the other drive (the working disk). If you didn't want to be forced to constantly swap disks, you also put the operating system files on your program disk which also took some of the capacity.
You could have worked with only one drive, but that was much more cumbersome and carried the risk of destroying your program disk (because that could not be write-protected, then) or you had to change disks occasionally.
Obviously copying between disks was much simpler with a 2-drive setup, as others have mentioned.
1
Starting with CP/M 2.2, which I believe the Osborne I shipped with, it did have 16 user areas per disk so you could split up files and useuser 1
etc to switch between user areas.
– Brian
Nov 29 at 21:41
From what i understand, the user areas were similar to folders in MacOs 1.0; all files were stored in the same directory, but the user area number (or folder number) was treated as part of the name, so the within user areas 2 and 3, "foo.txt" would behave like "2foo.txt" or "3foo.txt", respectively. While write protecting master program disks would have been desirable, not all programs could usefully run from write-protected disks. The CP/M equivalent of batch files, for example, required the ability to write to the startup disk.
– supercat
Nov 29 at 22:23
@brian Right, but: On a 180k disk, user areas are not particularly useful - It doesn't make the disk space any larger. Many people didn't use user areas anyhow: they were more of a nuisance than useful because they simply hide files completely, and PIP.COM must be present in each user area you want to copy files into.
– tofro
Nov 29 at 22:28
1
@ChrisStratton You're drastically underestimating the dumbness of the average user ;)
– tofro
Nov 30 at 11:26
1
@supercat user areas were not part of the file name under CP/M.
– Thorbjørn Ravn Andersen
Nov 30 at 12:50
|
show 7 more comments
up vote
5
down vote
Note CP/M (the Operating system of the Osborne) didn't have subdirectories as we know today (which more or less forced you to dedicate a disk for a specific purpose in order to keep the overview), it also had very limited storage capacity per disk drive (~180k on a SS/SD disk as on the Osborne 1).
That means you typically held the application (for example WordStar, with a typical disk footprint of ~50-60kBytes) on one drive on a write-protected disk (in case it had to load overlays or messages) and the actual text you were working on on a disk in the other drive (the working disk). If you didn't want to be forced to constantly swap disks, you also put the operating system files on your program disk which also took some of the capacity.
You could have worked with only one drive, but that was much more cumbersome and carried the risk of destroying your program disk (because that could not be write-protected, then) or you had to change disks occasionally.
Obviously copying between disks was much simpler with a 2-drive setup, as others have mentioned.
1
Starting with CP/M 2.2, which I believe the Osborne I shipped with, it did have 16 user areas per disk so you could split up files and useuser 1
etc to switch between user areas.
– Brian
Nov 29 at 21:41
From what i understand, the user areas were similar to folders in MacOs 1.0; all files were stored in the same directory, but the user area number (or folder number) was treated as part of the name, so the within user areas 2 and 3, "foo.txt" would behave like "2foo.txt" or "3foo.txt", respectively. While write protecting master program disks would have been desirable, not all programs could usefully run from write-protected disks. The CP/M equivalent of batch files, for example, required the ability to write to the startup disk.
– supercat
Nov 29 at 22:23
@brian Right, but: On a 180k disk, user areas are not particularly useful - It doesn't make the disk space any larger. Many people didn't use user areas anyhow: they were more of a nuisance than useful because they simply hide files completely, and PIP.COM must be present in each user area you want to copy files into.
– tofro
Nov 29 at 22:28
1
@ChrisStratton You're drastically underestimating the dumbness of the average user ;)
– tofro
Nov 30 at 11:26
1
@supercat user areas were not part of the file name under CP/M.
– Thorbjørn Ravn Andersen
Nov 30 at 12:50
|
show 7 more comments
up vote
5
down vote
up vote
5
down vote
Note CP/M (the Operating system of the Osborne) didn't have subdirectories as we know today (which more or less forced you to dedicate a disk for a specific purpose in order to keep the overview), it also had very limited storage capacity per disk drive (~180k on a SS/SD disk as on the Osborne 1).
That means you typically held the application (for example WordStar, with a typical disk footprint of ~50-60kBytes) on one drive on a write-protected disk (in case it had to load overlays or messages) and the actual text you were working on on a disk in the other drive (the working disk). If you didn't want to be forced to constantly swap disks, you also put the operating system files on your program disk which also took some of the capacity.
You could have worked with only one drive, but that was much more cumbersome and carried the risk of destroying your program disk (because that could not be write-protected, then) or you had to change disks occasionally.
Obviously copying between disks was much simpler with a 2-drive setup, as others have mentioned.
Note CP/M (the Operating system of the Osborne) didn't have subdirectories as we know today (which more or less forced you to dedicate a disk for a specific purpose in order to keep the overview), it also had very limited storage capacity per disk drive (~180k on a SS/SD disk as on the Osborne 1).
That means you typically held the application (for example WordStar, with a typical disk footprint of ~50-60kBytes) on one drive on a write-protected disk (in case it had to load overlays or messages) and the actual text you were working on on a disk in the other drive (the working disk). If you didn't want to be forced to constantly swap disks, you also put the operating system files on your program disk which also took some of the capacity.
You could have worked with only one drive, but that was much more cumbersome and carried the risk of destroying your program disk (because that could not be write-protected, then) or you had to change disks occasionally.
Obviously copying between disks was much simpler with a 2-drive setup, as others have mentioned.
edited Nov 29 at 16:37
answered Nov 29 at 16:32
tofro
14.2k32980
14.2k32980
1
Starting with CP/M 2.2, which I believe the Osborne I shipped with, it did have 16 user areas per disk so you could split up files and useuser 1
etc to switch between user areas.
– Brian
Nov 29 at 21:41
From what i understand, the user areas were similar to folders in MacOs 1.0; all files were stored in the same directory, but the user area number (or folder number) was treated as part of the name, so the within user areas 2 and 3, "foo.txt" would behave like "2foo.txt" or "3foo.txt", respectively. While write protecting master program disks would have been desirable, not all programs could usefully run from write-protected disks. The CP/M equivalent of batch files, for example, required the ability to write to the startup disk.
– supercat
Nov 29 at 22:23
@brian Right, but: On a 180k disk, user areas are not particularly useful - It doesn't make the disk space any larger. Many people didn't use user areas anyhow: they were more of a nuisance than useful because they simply hide files completely, and PIP.COM must be present in each user area you want to copy files into.
– tofro
Nov 29 at 22:28
1
@ChrisStratton You're drastically underestimating the dumbness of the average user ;)
– tofro
Nov 30 at 11:26
1
@supercat user areas were not part of the file name under CP/M.
– Thorbjørn Ravn Andersen
Nov 30 at 12:50
|
show 7 more comments
1
Starting with CP/M 2.2, which I believe the Osborne I shipped with, it did have 16 user areas per disk so you could split up files and useuser 1
etc to switch between user areas.
– Brian
Nov 29 at 21:41
From what i understand, the user areas were similar to folders in MacOs 1.0; all files were stored in the same directory, but the user area number (or folder number) was treated as part of the name, so the within user areas 2 and 3, "foo.txt" would behave like "2foo.txt" or "3foo.txt", respectively. While write protecting master program disks would have been desirable, not all programs could usefully run from write-protected disks. The CP/M equivalent of batch files, for example, required the ability to write to the startup disk.
– supercat
Nov 29 at 22:23
@brian Right, but: On a 180k disk, user areas are not particularly useful - It doesn't make the disk space any larger. Many people didn't use user areas anyhow: they were more of a nuisance than useful because they simply hide files completely, and PIP.COM must be present in each user area you want to copy files into.
– tofro
Nov 29 at 22:28
1
@ChrisStratton You're drastically underestimating the dumbness of the average user ;)
– tofro
Nov 30 at 11:26
1
@supercat user areas were not part of the file name under CP/M.
– Thorbjørn Ravn Andersen
Nov 30 at 12:50
1
1
Starting with CP/M 2.2, which I believe the Osborne I shipped with, it did have 16 user areas per disk so you could split up files and use
user 1
etc to switch between user areas.– Brian
Nov 29 at 21:41
Starting with CP/M 2.2, which I believe the Osborne I shipped with, it did have 16 user areas per disk so you could split up files and use
user 1
etc to switch between user areas.– Brian
Nov 29 at 21:41
From what i understand, the user areas were similar to folders in MacOs 1.0; all files were stored in the same directory, but the user area number (or folder number) was treated as part of the name, so the within user areas 2 and 3, "foo.txt" would behave like "2foo.txt" or "3foo.txt", respectively. While write protecting master program disks would have been desirable, not all programs could usefully run from write-protected disks. The CP/M equivalent of batch files, for example, required the ability to write to the startup disk.
– supercat
Nov 29 at 22:23
From what i understand, the user areas were similar to folders in MacOs 1.0; all files were stored in the same directory, but the user area number (or folder number) was treated as part of the name, so the within user areas 2 and 3, "foo.txt" would behave like "2foo.txt" or "3foo.txt", respectively. While write protecting master program disks would have been desirable, not all programs could usefully run from write-protected disks. The CP/M equivalent of batch files, for example, required the ability to write to the startup disk.
– supercat
Nov 29 at 22:23
@brian Right, but: On a 180k disk, user areas are not particularly useful - It doesn't make the disk space any larger. Many people didn't use user areas anyhow: they were more of a nuisance than useful because they simply hide files completely, and PIP.COM must be present in each user area you want to copy files into.
– tofro
Nov 29 at 22:28
@brian Right, but: On a 180k disk, user areas are not particularly useful - It doesn't make the disk space any larger. Many people didn't use user areas anyhow: they were more of a nuisance than useful because they simply hide files completely, and PIP.COM must be present in each user area you want to copy files into.
– tofro
Nov 29 at 22:28
1
1
@ChrisStratton You're drastically underestimating the dumbness of the average user ;)
– tofro
Nov 30 at 11:26
@ChrisStratton You're drastically underestimating the dumbness of the average user ;)
– tofro
Nov 30 at 11:26
1
1
@supercat user areas were not part of the file name under CP/M.
– Thorbjørn Ravn Andersen
Nov 30 at 12:50
@supercat user areas were not part of the file name under CP/M.
– Thorbjørn Ravn Andersen
Nov 30 at 12:50
|
show 7 more comments
up vote
2
down vote
The Osborne 1, like many computers of the time, had no means of data storage other than floppy disks. On powering up, the user would be prompted to insert the operating system disk, so the machine could boot.
Even when running other software, the computer would need to access and run parts of the OS periodically. If you only had one floppy drive, you'd have to continuously eject and insert the OS disk and your data disk when running some commands. It was far more desirable to have two drives available, so the OS disk could be left in one drive for most of the time.
Having two floppy drives also speeds up copying files between different disks, but this is a secondary benefit.
The provision of two floppy drives was also common with other machines, such as the IBM PC and the BBC Micro (though the latter had its OS in a ROM on the motherboard). When hard drives were installed in computers, the OS could be installed there, and there was no longer such a benefit from having a second floppy drive.
1
Why would a machine of that error need to access the OS while running a program? Reloading the command-prompt handler after exiting would be commonplace, but if part of the OS got displaced by another program, it wouldn't be able to reload until that program gave up the memory, which wouldn't usually happen until that program exited.
– supercat
Nov 29 at 15:57
2
@supercat Just as now, an "OS" like CP/M included a collection of stand-alone utility programs as well as the permanently resident code. If you wanted to use CPM's "PIP" to copy a file from one disk to another on a single-drive system, you would have to (1) insert the CPM disk to start PIP (2) insert the first data disk to read a chunk of data into memory (3) insert the second data disk to write the data (4) repeat steps 2 and 3 till done. The probability of "user error" was not small! With two drives, you only needed to do one disk change. to swap the OS disk for one of the data disks.
– alephzero
Nov 29 at 16:09
1
@alephzero: When copying data from one disk to another, having two drives was better than one, obviously. My issue was with the first sentence of the second paragraph. If a program wanted to use PIP to copy a file, it would need to save its state and arrange things so that when PIP exited, the disk in the first drive would contain a file with a certain special name whose last block contained a command to re-run the original program and have it reload its state. Were there any programs that went through that rigmarole to use PIP rather than simply using their own internal copy-file code?
– supercat
Nov 29 at 16:46
add a comment |
up vote
2
down vote
The Osborne 1, like many computers of the time, had no means of data storage other than floppy disks. On powering up, the user would be prompted to insert the operating system disk, so the machine could boot.
Even when running other software, the computer would need to access and run parts of the OS periodically. If you only had one floppy drive, you'd have to continuously eject and insert the OS disk and your data disk when running some commands. It was far more desirable to have two drives available, so the OS disk could be left in one drive for most of the time.
Having two floppy drives also speeds up copying files between different disks, but this is a secondary benefit.
The provision of two floppy drives was also common with other machines, such as the IBM PC and the BBC Micro (though the latter had its OS in a ROM on the motherboard). When hard drives were installed in computers, the OS could be installed there, and there was no longer such a benefit from having a second floppy drive.
1
Why would a machine of that error need to access the OS while running a program? Reloading the command-prompt handler after exiting would be commonplace, but if part of the OS got displaced by another program, it wouldn't be able to reload until that program gave up the memory, which wouldn't usually happen until that program exited.
– supercat
Nov 29 at 15:57
2
@supercat Just as now, an "OS" like CP/M included a collection of stand-alone utility programs as well as the permanently resident code. If you wanted to use CPM's "PIP" to copy a file from one disk to another on a single-drive system, you would have to (1) insert the CPM disk to start PIP (2) insert the first data disk to read a chunk of data into memory (3) insert the second data disk to write the data (4) repeat steps 2 and 3 till done. The probability of "user error" was not small! With two drives, you only needed to do one disk change. to swap the OS disk for one of the data disks.
– alephzero
Nov 29 at 16:09
1
@alephzero: When copying data from one disk to another, having two drives was better than one, obviously. My issue was with the first sentence of the second paragraph. If a program wanted to use PIP to copy a file, it would need to save its state and arrange things so that when PIP exited, the disk in the first drive would contain a file with a certain special name whose last block contained a command to re-run the original program and have it reload its state. Were there any programs that went through that rigmarole to use PIP rather than simply using their own internal copy-file code?
– supercat
Nov 29 at 16:46
add a comment |
up vote
2
down vote
up vote
2
down vote
The Osborne 1, like many computers of the time, had no means of data storage other than floppy disks. On powering up, the user would be prompted to insert the operating system disk, so the machine could boot.
Even when running other software, the computer would need to access and run parts of the OS periodically. If you only had one floppy drive, you'd have to continuously eject and insert the OS disk and your data disk when running some commands. It was far more desirable to have two drives available, so the OS disk could be left in one drive for most of the time.
Having two floppy drives also speeds up copying files between different disks, but this is a secondary benefit.
The provision of two floppy drives was also common with other machines, such as the IBM PC and the BBC Micro (though the latter had its OS in a ROM on the motherboard). When hard drives were installed in computers, the OS could be installed there, and there was no longer such a benefit from having a second floppy drive.
The Osborne 1, like many computers of the time, had no means of data storage other than floppy disks. On powering up, the user would be prompted to insert the operating system disk, so the machine could boot.
Even when running other software, the computer would need to access and run parts of the OS periodically. If you only had one floppy drive, you'd have to continuously eject and insert the OS disk and your data disk when running some commands. It was far more desirable to have two drives available, so the OS disk could be left in one drive for most of the time.
Having two floppy drives also speeds up copying files between different disks, but this is a secondary benefit.
The provision of two floppy drives was also common with other machines, such as the IBM PC and the BBC Micro (though the latter had its OS in a ROM on the motherboard). When hard drives were installed in computers, the OS could be installed there, and there was no longer such a benefit from having a second floppy drive.
answered Nov 29 at 15:51
Kaz
1664
1664
1
Why would a machine of that error need to access the OS while running a program? Reloading the command-prompt handler after exiting would be commonplace, but if part of the OS got displaced by another program, it wouldn't be able to reload until that program gave up the memory, which wouldn't usually happen until that program exited.
– supercat
Nov 29 at 15:57
2
@supercat Just as now, an "OS" like CP/M included a collection of stand-alone utility programs as well as the permanently resident code. If you wanted to use CPM's "PIP" to copy a file from one disk to another on a single-drive system, you would have to (1) insert the CPM disk to start PIP (2) insert the first data disk to read a chunk of data into memory (3) insert the second data disk to write the data (4) repeat steps 2 and 3 till done. The probability of "user error" was not small! With two drives, you only needed to do one disk change. to swap the OS disk for one of the data disks.
– alephzero
Nov 29 at 16:09
1
@alephzero: When copying data from one disk to another, having two drives was better than one, obviously. My issue was with the first sentence of the second paragraph. If a program wanted to use PIP to copy a file, it would need to save its state and arrange things so that when PIP exited, the disk in the first drive would contain a file with a certain special name whose last block contained a command to re-run the original program and have it reload its state. Were there any programs that went through that rigmarole to use PIP rather than simply using their own internal copy-file code?
– supercat
Nov 29 at 16:46
add a comment |
1
Why would a machine of that error need to access the OS while running a program? Reloading the command-prompt handler after exiting would be commonplace, but if part of the OS got displaced by another program, it wouldn't be able to reload until that program gave up the memory, which wouldn't usually happen until that program exited.
– supercat
Nov 29 at 15:57
2
@supercat Just as now, an "OS" like CP/M included a collection of stand-alone utility programs as well as the permanently resident code. If you wanted to use CPM's "PIP" to copy a file from one disk to another on a single-drive system, you would have to (1) insert the CPM disk to start PIP (2) insert the first data disk to read a chunk of data into memory (3) insert the second data disk to write the data (4) repeat steps 2 and 3 till done. The probability of "user error" was not small! With two drives, you only needed to do one disk change. to swap the OS disk for one of the data disks.
– alephzero
Nov 29 at 16:09
1
@alephzero: When copying data from one disk to another, having two drives was better than one, obviously. My issue was with the first sentence of the second paragraph. If a program wanted to use PIP to copy a file, it would need to save its state and arrange things so that when PIP exited, the disk in the first drive would contain a file with a certain special name whose last block contained a command to re-run the original program and have it reload its state. Were there any programs that went through that rigmarole to use PIP rather than simply using their own internal copy-file code?
– supercat
Nov 29 at 16:46
1
1
Why would a machine of that error need to access the OS while running a program? Reloading the command-prompt handler after exiting would be commonplace, but if part of the OS got displaced by another program, it wouldn't be able to reload until that program gave up the memory, which wouldn't usually happen until that program exited.
– supercat
Nov 29 at 15:57
Why would a machine of that error need to access the OS while running a program? Reloading the command-prompt handler after exiting would be commonplace, but if part of the OS got displaced by another program, it wouldn't be able to reload until that program gave up the memory, which wouldn't usually happen until that program exited.
– supercat
Nov 29 at 15:57
2
2
@supercat Just as now, an "OS" like CP/M included a collection of stand-alone utility programs as well as the permanently resident code. If you wanted to use CPM's "PIP" to copy a file from one disk to another on a single-drive system, you would have to (1) insert the CPM disk to start PIP (2) insert the first data disk to read a chunk of data into memory (3) insert the second data disk to write the data (4) repeat steps 2 and 3 till done. The probability of "user error" was not small! With two drives, you only needed to do one disk change. to swap the OS disk for one of the data disks.
– alephzero
Nov 29 at 16:09
@supercat Just as now, an "OS" like CP/M included a collection of stand-alone utility programs as well as the permanently resident code. If you wanted to use CPM's "PIP" to copy a file from one disk to another on a single-drive system, you would have to (1) insert the CPM disk to start PIP (2) insert the first data disk to read a chunk of data into memory (3) insert the second data disk to write the data (4) repeat steps 2 and 3 till done. The probability of "user error" was not small! With two drives, you only needed to do one disk change. to swap the OS disk for one of the data disks.
– alephzero
Nov 29 at 16:09
1
1
@alephzero: When copying data from one disk to another, having two drives was better than one, obviously. My issue was with the first sentence of the second paragraph. If a program wanted to use PIP to copy a file, it would need to save its state and arrange things so that when PIP exited, the disk in the first drive would contain a file with a certain special name whose last block contained a command to re-run the original program and have it reload its state. Were there any programs that went through that rigmarole to use PIP rather than simply using their own internal copy-file code?
– supercat
Nov 29 at 16:46
@alephzero: When copying data from one disk to another, having two drives was better than one, obviously. My issue was with the first sentence of the second paragraph. If a program wanted to use PIP to copy a file, it would need to save its state and arrange things so that when PIP exited, the disk in the first drive would contain a file with a certain special name whose last block contained a command to re-run the original program and have it reload its state. Were there any programs that went through that rigmarole to use PIP rather than simply using their own internal copy-file code?
– supercat
Nov 29 at 16:46
add a comment |
up vote
1
down vote
Since the computer only has disk drives and no hard-disk, the normal usage was to have the system programs and a word processor or database handler on one diskette and using the other for data or documents.
Those drives were single side, single density as standard, which gave a storage capacity of somewhere around 100 kBytes each.
add a comment |
up vote
1
down vote
Since the computer only has disk drives and no hard-disk, the normal usage was to have the system programs and a word processor or database handler on one diskette and using the other for data or documents.
Those drives were single side, single density as standard, which gave a storage capacity of somewhere around 100 kBytes each.
add a comment |
up vote
1
down vote
up vote
1
down vote
Since the computer only has disk drives and no hard-disk, the normal usage was to have the system programs and a word processor or database handler on one diskette and using the other for data or documents.
Those drives were single side, single density as standard, which gave a storage capacity of somewhere around 100 kBytes each.
Since the computer only has disk drives and no hard-disk, the normal usage was to have the system programs and a word processor or database handler on one diskette and using the other for data or documents.
Those drives were single side, single density as standard, which gave a storage capacity of somewhere around 100 kBytes each.
answered Nov 29 at 15:46
UncleBod
576110
576110
add a comment |
add a comment |
BasementJoe is a new contributor. Be nice, and check out our Code of Conduct.
BasementJoe is a new contributor. Be nice, and check out our Code of Conduct.
BasementJoe is a new contributor. Be nice, and check out our Code of Conduct.
BasementJoe is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Retrocomputing Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8405%2fpurpose-of-two-disk-drives-on-the-osborne-1%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
4
By the way, the drives were named "A" and "B", and that is the precise reason why the hard disk was named "C".
– Mr Lister
Nov 30 at 7:15
1
I remember when I needed to make a copy of a whole floppy (ok, games...) from a single drive computer, there was some utility (under DOS), that was doing the copy in chunks, because the whole data did not fit in memory. So you had to switch to/from the original/copy floppies three or four times for the whole process to complete. That was very inconvenient.
– dim
Nov 30 at 8:53