MPC60 SCSI speed

How fast it the SCSI upgrade? When using a zip drive, how long does it take to Load up a standard 60? How about a fully expanded 60? What about saving speed?

SCSI upgrade doesn't make it that much faster. But it's really more about storage options with it. If the 60 is fully expanded that does not predict the speed of the machine as far as as load time is concerned.

I don't agree, there is a huge speed difference compared to floppy.

Having said that, the SCSI interface itself is not a particularly good one in my opinion, it could've been a lot faster. Either by design or because of limitations in the other hardware (the machine itself) the transfers aren't as fast as they could be.

Also the maximum number of files per partition effectively renders bigger drives a bit of a pointless exercise since there is also a maximum number of partitions.. for instance, if you fill a 1gb jaz disc or something with single drum hits, you'll end up using just a small part of the disc even though it's totally full from the machine point of view. In that case you might as well use a zip disc. For loops and bigger samples it's a different story though.

Still it's worth it to me, I can't stand just sitting and wait for the floppy drive to load.

viewtopic.php?f=4&t=29188&p=284983&hilit=save+load#p284983

elmacaco wrote:Ok, I got a Program with 64 samples, and 0.4 seconds left to sample with, so it's not the absolute full memory, but pretty close.

Loading it from Zip takes 56.8 seconds, this is loading into the machine just turned on, with nothng in the memory. Should be about the same in other circumstances.

58 seconds to save the program to a new partition on the zip disk.

3 minutes and 59 seconds to save the same program to floppy disk (it takes 2 disks, and i wasn't counting the time it took to put in a new disk, which took 9 seconds.)

3 minutes and 41 seconds to load same program from floppy, again not counting the time between disks.

2 minutes to format a floppy.

converting and loading an MPC 3000 Program Exported from the MPC editor took 10 minutes. The program had 64 samples and 1.7 seconds of sample time left.

I got the scsi interface recently- and it speeds up using the 60 loads for me.

pUs wrote:Having said that, the SCSI interface itself is not a particularly good one in my opinion, it could've been a lot faster. Either by design or because of limitations in the other hardware (the machine itself) the transfers aren't as fast as they could be.

Hardware limitations? If I remember correctly, the processor inside is a 80186 which runs at 10Mhz!

MPCHunter wrote:

pUs wrote:Having said that, the SCSI interface itself is not a particularly good one in my opinion, it could've been a lot faster. Either by design or because of limitations in the other hardware (the machine itself) the transfers aren't as fast as they could be.

Hardware limitations? If I remember correctly, the processor inside is a 80186 which runs at 10Mhz!

Don't really understand your point. Of course there are limitations, but I've been using computers back in the days running with similair speced hardware including period-hard drives, and I know for a fact that it's perfectly possible to load 1-2 mb in such scenarios a hell of a lot faster than the 60 is doing. Add to that the fact that the task of simply loading data from disk to memory isn't really cpu-intensive. Or shouldn't be, unless you've performed some really creative coding.

Still, it doesn't really matter. I'm grateful for the SCSI interface being there at all. =)

pUs wrote:

MPCHunter wrote:

pUs wrote:Having said that, the SCSI interface itself is not a particularly good one in my opinion, it could've been a lot faster. Either by design or because of limitations in the other hardware (the machine itself) the transfers aren't as fast as they could be.

Hardware limitations? If I remember correctly, the processor inside is a 80186 which runs at 10Mhz!

Don't really understand your point. Of course there are limitations, but I've been using computers back in the days running with similair speced hardware including period-hard drives, and I know for a fact that it's perfectly possible to load 1-2 mb in such scenarios a hell of a lot faster than the 60 is doing. Add to that the fact that the task of simply loading data from disk to memory isn't really cpu-intensive. Or shouldn't be, unless you've performed some really creative coding.

Still, it doesn't really matter. I'm grateful for the SCSI interface being there at all. =)

In the 60, the hardware designers spent more time fine tuning CPU instructions for sound processing rather than file transfer. At first, I doubt they were expecting users to load and save multiple disks per session or they would have done a better job designing the memory in.

Computers are faster at moving data between disks because it is very important task for what they're designed to do.

MPCHunter wrote:
Computers are faster at moving data between disks because it is very important task for what they're designed to do.

I think that view is too simplified. The MPC is a computer, no matter what way you're looking at it. Although heavily optimized for its purpose, it's still a computer. If - as you write - the engineers naturally focused on other areas then you've proven my one and single point - the disk interface could've been faster.

Because of the way the OS is designed, you can't even use the disk system loading/saving stuff without stopping whatever you're doing at the moment. Because of that the CPU should logically have a very light (or the very least lighter) load while doing disk transfers. Resources freed up. Now - to me, this doesn't really sound like something that would limit the potential disk performance, rather the opposite...

pUs wrote:
Because of the way the OS is designed, you can't even use the disk system loading/saving stuff without stopping whatever you're doing at the moment.

I believe that is a memory problem and not CPU or software.
To be able to load/save while play back is taking place would require an extra buffer.
As memory was really expensive when the MPC60 was made ,I can see why Akai went with this design.

Acid Mitch wrote:

pUs wrote:
Because of the way the OS is designed, you can't even use the disk system loading/saving stuff without stopping whatever you're doing at the moment.

I believe that is a memory problem and not CPU or software.
To be able to load/save while play back is taking place would require an extra buffer.
As memory was really expensive when the MPC60 was made ,I can see why Akai went with this design.

Yeah that might very well be the case. Whatever the reason, that approach should still potentially allow for faster loading/saving speeds and not the other way around.