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.