Question: I want to hook a hard drive up to my EPS, but the only size I can find are ones above 4gig's. I thought these weren't compatible with the EPS? Can I use those drives?
Answer: Yes! You can use any size SCSI Drive with the EPS/ASR. The most you can write is 8gig, due to the 24-bit FAT.
However, the Ensoniq OFTEN does not do a perfect job FORMATTING drives larger than 2gig. The specifics are described below. However, it is just fine after they are formatted, of course if they are formatted properly.
The news is worse with drives larger than 8gig. Larger than 8gig and less than 16gig effectively allow writing safety "x"gig minus 8gig; that is, a 12gig drive will yield 4gig of safe writing. The Ensoniq will not warn you that you can't write past 4gig in this case - it'll just corrupt data.
Any drive 16gig or over is formatted as a 16gig drive, and the news is the worst: although the headres are written correctly, the drive yields ZERO blocks of safe writing due to a bug in Ensoniq's format routine.
However, there is a workaround for all this: A drive does not HAVE TO BE formatted by the Ensoniq; my company's Translator program (a Free download version is available on the site www.chickensys.com/translatorfree) can format any SCSI drive perfectly. So, format with Translator, and then use the full 8gig with freedom.
I pulled out two SCSI Drives, one a 4.3gig and another a 20gig. I tried to format them both and then write to them.
This received FILE OPERATION ERROR while formatting. After shutting the drive off, and rebooting, the drive has able to be accessed, written the OS, and was able to be read and written to with no problems.
Upon investigation, this drive was given perfect formatting - the capacity was set at 4.3gig, free block the same, and the FAT was written perfectly. I do not know why the FILE OPERATION ERROR happened, looks like a harmless bug.
My assumption is that this FILE OPERATION ERROR happens with any drive > 2gigs < 8gigs, and > 12 < 16gig. Reasons are found below.
This did not receive a FILE OPERATION ERROR while formatting. It got to the COPY OS TO DRIVE? display, and when I said YES, it errored saying BAD FAT SIGNATURE. Any recurring attempts to the drive got the same message. I then
reformatted, did not put the OS on the drive, and everything was fine. I then tried to write a small file, was successful, but could not load it in again, got a Insert Disk 1 error.
So, upon investigation, it turns out at least the headers were right. The
capacity was record as 0x1FFFFF blocks; 33554431 blocks. That's (33554431
2048)mb = 16383mb. The real capacity of the drive is slightly larger than
that, so I assume that the formatting capacity of the EPS/ASR is maxed out at 16mb.
But the surprise was how the FAT was written. The FAT refers to the entirety of the disk, EVERY block is accounted for. Thus, since the first five blocks on a disks are always headers, the FAT automatically marks those as used. That was done with the 20gig drive. Then the FAT is supposed to mark all the FAT blocks that are used; mark itself off, in a sense. This was NOT done; thus the bad results on trying to write a file.
It would do this: write the file data to the first available location (block 6 - over the first FAT block!), then write the FAT, and usually fail the save since the FAT was written over to likely bad information.
The interesting thing is that the FAT blocks were written to the drive (each FAT block ends with two signature bytes), but they just weren't marked off as being used.
My guess is that the Ensoniq's "FAT writing" routine writes the FAT in sizes equivalent to 8gig boundaries. Meaning that if you have anything up to 8gig, it will be OK. A 9gig drive will have a 1gig-worth of FAT blocks marked used, a 12gig drive will have a 4gig worth of FAT blocks marked used. Perhaps an 8gig drive would have no FAT blocks marked as used, like our 20gig (seen as 16gig) drive showed.
Any case of FAT-to-capacity differential restricts the useful capacity of that drive, and of course allows for the possibility of corruption once you hit the differential amount.
Back to Knowledge Base Index