By dinner time today I implemented all file system commands that USB BASIC needs access to for read/write operations: the unit tests fired by my Commodore 64 mock-up device all passed 🙂
Here’s the debug log output on the USB host replacement’s console:
opendir() = 0 stat(TXT) = 0 chdir(TXT) = 0 opendir() = 0 stat(turric10.txt) = 0 open(turric10.txt, OPEN_EXISTING | READ) = 0 lseek(13) = 0 read(7, 7) = 0 read(0, 0) = 0 close() = 0 stat(..) = 0 chdir(..) = 0 stat(TAP) = 0 chdir(TAP) = 0 opendir() = 0 stat(LFN) = 0 chdir(LFN) = 0 opendir() = 0 stat(..) = 0 chdir(..) = 0 stat(..) = 0 chdir(..) = 0 stat(test011.txt) = 4 open(test011.txt, CREATE_ALWAYS | WRITE) = 0 write(43, 43) = 0 close() = 0
What do these tests do? In no particular order I would mention: browse the file system, list directory contents, open an existing file, “turric10.txt”, move the file pointer 13 bytes ahead, read out 7 bytes (“Welcome”), close the file, create a new file, “test011.txt”, and write 43 bytes to it before closing it.
Here’s the contents of the file created:
Essentially, I am done with the implementation of the USB host replacement for access to SD/SDHC cards with support for long file names from a Commodore 64. The latter is now in a position to reuse my USBhost-64 drivers to access an SD/SDHC card, without knowing exactly what medium is in use, thanks to the abstraction layer I am working at.
What I might also add is a file rename command, which is tricky when long file names are supported as a blank space cannot be used as name separator: e.g. “rename file1 file2”. The USB host does NOT support long file names and uses a single space character as separator. I might end up extending this behaviour and using a separator char that cannot occur within file names, such as ‘>’: e.g. “rename long file name number 1>long file name number 2”.
We shall see 🙂