From: Jim Brain (brain_at_jbrain.com)
Date: 2005-05-12 16:39:58
Marko Mäkelä wrote:
>On Thu, May 12, 2005 at 02:06:33AM -0500, Jim Brain wrote:
>
>
>>If an 0xe5 is needed, you can use 0x05, which is interpreted as an
>>escaped e5.
>>
>>0xe5 cannot be used (use 0x05 instead)
>>
>>
>
>So, 0x05 cannot be used.
>
>
In position 0, yes.
>
>
>>As for the metacharacters, I'm not sure you need to stay away from them
>>anymore.
>>
>>
>
>I think using them in a FAT filesystem is asking for trouble. You know,
>if someone still uses Commodore computers, he might also use some weird
>MS-DOS 2.11 based computer. :-)
>
>
Possible, yes, probable, no. And, it's trivally easy to add a switch to
code to conditionally disallow such chars in firmware/software. I'm OK
with disallowing traditional FAT naming in lieu of VFAT. My idea is
that names should be stored in FAT dir entries if they can (8.3), and
VFAT LFN entries if they cannot (250).
Fact remains, FAT is by far the most popular format. It's easy to
implement, it's well understood and supported.
o If someone wants to support an IDE/SCSI drive in a CBM-only drive
unit, one can choose any format one wants. The only issues would be if
you want to pull your IDE/SCSI drive out and hook it up to a
PC/Mac/etc., but I would think this is relatively infrequent, and can be
accomplished with some tooling written on the PC OS.
o If someone wants to support a MMC/CF/SD/MemoryStick/SmartMedia card in
a CBM unit, there is an expectation that the data will travel from a
PC/Mac (or some digital camera) platform to the CBM. This is where
FAT/VFAT support is a must.
o If someone wants to support the use of the PC as a virtual HD, then
disk format support is largely irrelevant, as you are mainly limited by
the underlying OS. Except for very early OSes like DOS, common OS types
today support much a larger character set than the CBM can provide. 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. As a point
to note, in VFAT, one can store a file name with any 16 bit character up
to 250 chars in length.
o We can debate the ugliness of FAT all day long, but it is the common
denominator. Support for FAT (VFAT) is, in my opinion, a feature sorely
needed by CBM HW.
>>My plan is still RS232, and maybe integrate the FDTI chipset for USB
>>support, as drivers exist for that USB device that makes it look like
>>a serial port to the system.
>>
>>
>
>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.
>The Keyspan USB to serial adapters, which have been proven to work with
>the C2N232 on Mac OS X, are based on the EzUSB microcontroller. That
>controller only has RAM, and you will have to download the firmware over USB
>every time before using it.
>
>
I'm not married to a particular solution, but I don't want to write
drivers for every OS. Support for USB is a means to an end for me.
>
>
>>but supporting a C64/128 talking to the PC via USB I can't
>>think of a USB fmaily that would fit into.
>>
>>
>
>USB HID with custom software on the PC, perhaps? Nah, it would be too slow.
>Maybe something with libusb?
>
>
Anything is possible. Probability (at least from this viewpoint) is
inversely proportional to how much per-platform code is required.
Jim
--
Jim Brain, Brain Innovations
brain@jbrain.com http://www.jbrain.com
Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times!
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.