[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Joliet FS (WAS: SCSI Interface for A2GS)
Could anyone let me have a copy of "Dr Bayzar" mentioned below?
On Thu, 28 Jun 2001 20:46:02 GMT, Mitchell Spector wrote:
> dempson@actrix.gen.nz (David Empson) wrote:
>
>>It would be worth seeing whether the High Sierra FST can handle names
>>that exceed the ISO level 1 restrictions.
>
> Possibly not on its own, but there was a INIT released several
> years back called "Dr. Bayzar" which patched the HS.FST and
> allowed it to access CDs (and folders within) which used illegal
> characters in filenames. From what I can recall, that included
> spaces and non-alphanumeric characters.
>
> I suppose that would qualify as exceeding those restrictions,
> as least in part (the other would be using > than 8.3 characters
> for naming the file).
>
>>On the Mac, when burning an ISO-9660 CD, Toast has the option of
>>specifying the form to be used for the filenames. The options are:
>>
>>- ISO level 1 (8.3, very restricted character set)
>>- MS-DOS (8.3, more relaxed character set)
>>- Macintosh filenames (31 characters, Mac 8-bit character set)
>>- Joliet (separate Joliet directory plus ISO level 1 8.3 for
>>compatibility).
>>
>>A PC running Win95, WinNT, etc. is quite happy reading an ISO CD with
>>Macintosh naming. The question is whether the IIgs can cope.
>
> Hmm, for the very short time I had a Chinon 1x CD-ROM attached
> to my IIgs (I pulled it once the mechanism more or less died) I _was_
> able to mount and access several CD-R's that were created on a
> Win98/2K machine. These definitely included longer than 8.3
> characters in the filename.
>
> Now, I only have an extremely vage recollection of how the
> HS.FST handled those filenames. I *think* (and I stress think) it
> displayed them much the way MS-DOS sees long filenames.
> That is "This_is_a_long_filename.txt" would display as
> "This_~.txt". I can't remember if I ever installed that INIT
> patch mentioned above. Probably not.
>
> One thing I do remember is that particular drive had trouble
> reading several color dyes and temporarily locked up control
> of the IIgs when playing audio CD's with the RamFAST (a
> Creative Labs 2x/4x burner worked perfectly with audio,
> though I didn't have the chance to test reading data
> CD's).
>
> Unfortunately I can't do any further testing as the only working
> SCSI CD-ROMs I have on hand (Toshiba 1x and 4x) are seen as
> non-removable devices by both my RamFAST and Apple SCSI
> controllers. I'm assuming either the drives are internally jumpered
> to work with 512 byte block size for Sun SPARCstations (or the
> firmware is setting it up this way) or simply defective.
>
> Mitchell Spector
> a_specto@alcor.concordia.ca
--
... Transformer designers take turns doing it.