Re: Data transfer methods

From: Marko Mäkelä (
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

> 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


       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.