From: Marko Mäkelä (marko.makela_at_hut.fi)
Date: 2005-05-12 19:27:25
On Thu, May 12, 2005 at 09:39:58AM -0500, Jim Brain wrote:
> I'd have to look at the ISO9960+common extensions spec to see what chars are
> not possible, but VFAT supports 16 bit chars (to Spiro's point), and I
> believe ext*fs/Rieser/jfs/etc. support 16 bit chars as well.
I have the impression that NTFS supports UCS2 a.k.a. 16-bit Unicode. So,
it would be logical for VFAT to support that as well.
The file systems in Linux are character-set neutral. The only forbidden
bytes in a path component are 0x27 ('/') and 0x00 (NUL). Traditionally,
many GNU/Linux installations have been using a 8-bit character set, such
as ISO 8859-1 (which has been the default console mapping of Linux from
the very beginning). GTK 2, GNOME 2 and many other modern applications
expect the file names to be encoded in UTF-8. As you may know, UTF-8 is
a variable-length code for representing Unicode characters. ASCII characters
occupy one byte, and non-ASCII characters have the high bit set in every
byte of the character. 16-bit Unicode characters are encoded in 1 to 3
bytes. A 32-bit Unicode character may occupy up to 6 bytes, if I remember
correctly.
> As a point to note, in VFAT, one can store a file name with any 16 bit
> character up to 250 chars in length.
With Linux Extended file system and its successors, the limit is 255 bytes
per path component. Using UTF-8 encoding of the 16-bit subset of Unicode,
that would be 85 to 255 characters.
> o We can debate the ugliness of FAT all day long, but it is the common
> denominator.
True. Luckily, FAT is only needed for portable media. In cable-based
data transfers, the file name mapping can be implemented in the host software.
When writing to a memory card, the Commodore has to take care of this.
I guess VFAT will be the most straightforward solution, even though 16-bit
Unicode may lack some of the PETSCII characters.
> >My advice is to stay away from FTDI. Their Windows drivers are buggy,
> >and Linux support is lacking as well (it doesn't support XON/XOFF
> >handshaking, although the hardware does).
> >
> >
> So, we write new ones. The HW is fine, and device drivers for this
> cable type would have far-reaching uses. Linux folks would love a good
> driver, as would VIP users. This is no worse than having to write
> custom USB code via libusb.
I appreciate your braveness. I look forward to that and will happily
help with testing. I have a Digital VT420 terminal that is very handy,
especially when slowed down to 300 bps.
The Windows drivers do support XON/XOFF, but there were some other problems,
e.g., when a write timeout occurred in WriteFile, the byte counter would not
be updated. Maybe the C2N232 software could be made to work with the FTDI
drivers on Windows, but I didn't have the patience to work around all the bugs.
The FTDI support denied that there could be any bugs in their drivers, and
ignored me when I provided more detail.
> Anything is possible. Probability (at least from this viewpoint) is
> inversely proportional to how much per-platform code is required.
I agree. It's a pity that there are no USB standards for generic data
communications.
Marko
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.