SUGGESTED PROJECT(s): C64/C128 -To- USB Flash Drive / "C64 DreamDOS"???



Would it be possible, through a combination of hardware and software,
to interface a C64 or C128 to one of those ubiquitous USB Flash Drives
(also called a "Jump Drive" or "Thumb Drive")?

In addition to the physical interface itself, there would need to be
provision for some form of Commodore DOS, both so that the drive could
be formatted in some CBM-compatible way (I'd suggest using the equivalent
of a native FD-2000 partition, to provide the greatest number of blocks
free -- in this case, 6,336 blocks, or 1,609,344 bytes, free), and to
provide access (i.e., load, save, write, validate, directory, etc.) to
the drive and its contents.

COMMENTS REQUESTED: Feasibility? Ease Of Construction? Software Complexity?
Cost? General Interest?

ON A RELATED SUBJECT: Since some form of DOS would have to be provided
for, this brings up the spectre of either modifying the existing CBM DOS,
or of creating an entirely new version from scratch. And THAT, in turn,
suggests the subject of improving upon, and correcting the deficiencies
of, the original version!

What features and capabilities would YOU include in YOUR version of
"C64 DreamDOS"? :)

I'll begin the discussion with my OWN suggestions for a "C64 DreamDOS":

* Native ability to un/lock files, with stricter enforcement ("@SAVE"
would no longer undo the lock!). That is, a DOS command something
like "L0:Filename" would lock or unlock the file (it toggles).

* Similarly, a DOS command to Write un/protect the entire disk. To
help protect the user, you could require the correct diskname and
ID to be included in this command. For example, "W0:diskname,ID"

* A "format Protect" command: this doesn't "write un/protect" the
disk or any file, but flags the disk so that a subsequent format
command fails with a "FORMAT PROTECTED" error. The command would
toggle, and like the "write un/protect" command above should
require th diskname and ID as part of the command. Example,
"P0:diskname,ID". If given without the ID, the current protect
status would be returned but no change made. Whether or not the
current disk is "format protected" should be noted in some way
on the first line of the disk directory.

* Ability to specify custom filetypes (they would act as SEQ files,
but could be filtered for in directory listings). For example,
the user might specify "XYZ" as a custom filetype. This would
act the same as any other SEQ file, but a directory command such
as @"$0:*=XYZ" would list only the "XYZ" type files. The standard
filetypes would of course be reserved and unusable.

* Ability to custom-format a disk -- for example, shrinking the
directory in exchange for more blocks free, or (conversely)
giving up some free blocks in exchange for a longer directory;
or providing for an extended directory in which filenames can
run to 32 or 48 characters; or where the disk name and/or ID
are of greater length; or even specifying a different block
size. Any such custom details would need to be stored in a
fixed location on the disk, so that the drive could look up
these details when the disk is first inserted or initialized.

* A DOS "Query" command which would return the diskname, ID,
number of blocks free, and any other special features, of
the currently-inserted disk. For example, "Q0:" might return
"88,DISK NAME,ID,1392,WP,FP" (meaning, disk "error" number 88,
diskname of "DISK NAME", disk ID of "ID", 1,392 blocks free,
write protected, and format protected).

* A DOS "Where" command that gives the starting track and sector,
and the total number of blocks, for any specified file (or 00,00
if the file is nonexistent). Example: "W0:xyzzy" might yeid
something like, "85, FILE START, 23, 17, 143", meaning that the
file "xyzzy" starts at track 23, sector 17, and is 143 blocks
long.

* Ability to store and retrieve "hidden" information within some
normally unaccessed portion of the disk, without the need of a
special program -- great for storing a copyright message, a
staement of ownership, or a serial number!

* Ability to create "hidden" files; these would act otherwise
normally but would not be listed on the directory (although
their size would be reflected in the "blocks free" count).
Accessing any such file would require specifying it by its
exact name, wildcards not allowed.

* Speaking whereof -- expanded use of wildcards, for example
"Ex*ed" to match the word "Expanded".

* An "eXpunge" DOS command that doesn't just scratch files, but
overwrites both the directory entry, AND the file itself, with
null characters (ASCII 0's). You might also allow the user to
specify the number of overwrites! For example, the DOS command
"X0:filename,15" would expunge the file "filename" from both
the disk and the directory with 15 overwrites (!). If you really
wanted to protect the user from himself, you might require this
command to be given twice in succession for it to work.

* Ability to create "link" files, whose sole function it is to point
to other files, effectively allowing one to give the same program
or file several names, while storing it on the disk only ONCE.
The "link" file would have its own filetype (probably "LNK"),
would take up 0 blocks, would act as the same "filetype" as the
file it points to, and could be deleted separately from the main
file (that is, deleting the "LNK" file would NOT cause deletion
of the file it points to... however, I'd suggest that deleting
the main file DO cause the automatic deletion of any "LNK" file
pointing to it).

....There are probably LOTS of other features I'd love to see, but these
happen to be the only ones that I can think of at the present moment!

What set of features would YOU include, in your own version of "C64
DreamDOS"??? :)

-- _____
----------------------------- {~._.~} Astro Boy sets the pace,
"Glenn P.," _( Y )_ On your flight into space;
<C128UserDELETE-THIS@xxxxxxx> (:_~*~_:) What can I do, to be like you?
----------------------------- (_)-(_) And become a real Astro Boy?

:: Take Note Of The Spam Block On My E-Mail Address! ::
.



Relevant Pages

  • Re: DOS prompt
    ... If your computer has no disks or discs, then no DOS is needed. ... prompt) you can then give commands to the disk operating system to ... like xcopy at the command promps, you are still giving commands to ...
    (microsoft.public.windowsxp.basics)
  • Re: Avi file unerasable
    ... The disk is OK, but the avi file on the HD of my computer appears unerasable. ... I've tried erasing from DOS, tried to erase from safe mode, tried to delete using programs such as unlock, moveonboot, etc. ... Use the Attribute command to check. ...
    (rec.video.desktop)
  • Re: Best File copier..
    ... Fast Hackem File Copier and Maverick file copier. ... I hate the command for DOS, there are too many files I select to ... getting a directory of a disk (a full directory with sector counts, ...
    (comp.sys.atari.8bit)
  • Re: XP-pro & DOS
    ... called the DOS window, even by Microsoft, IS ... the Command Prompt is *NOT* the DOS ... the acronym for Microsoft Disk Operating ...
    (microsoft.public.windowsxp.basics)
  • Re: Reinstall just one or two files from the XP disk that may now be either missing or corrupt?
    ... external command, ... > Note that you may be prompted to insert the Windows XP installation CD. ... > Description of the Disk Cleanup Tool in Windows XP ... Protect your PC! ...
    (microsoft.public.windowsxp.help_and_support)