ULIfAC:Usb Mass storage,WiFi, 512KB Ram/32XROM Board/256K Ram+16X Rom Board!

[ikonsgr]

Thank you very much! That's exactly what I needed! 

Should we expect soon an official futureos support for USIfAC/ULIfAC boards then? 

[vasilisk]

Is there a way to copy original dsk image (special tracks, copy protection) to 3" disc?
I suppose IDSK is for normal games , because I tried it. Discology maybe?

[GUNHED]

Thank you very much! That's exactly what I needed! 

Should we expect soon an official FutureOS support for USIfAC/ULIfAC boards then? 

I wish it would be soon. But realistically it could be in 2025. Depends on how quick I can proceed to support all features (read DIR, read/write file, rename file, delete file, create sub-directory). In addition it would be nice to have a way to work with files bigger than 64 KB. 

Also (since FutureOS is ROM based) I need to check compatibility with ROM expansions and create a positive list, but that's only the quick part.

[ikonsgr]

In addition it would be nice to have a way to work with files bigger than 64 KB. 

The 64k limit exists only when you use Amsdos routines to access files (CASOPEN, CASDIRECT, etc)  . If you develop your own file access routines (like i've already done for accessing dsk images that can be up to 800kb for parados images), there is practically no limit, as the pointer to a file is 32bit e.g. you can create/read/write files up to... 4GigaBytes in size!

[ikonsgr]

Is there a way to copy original dsk image (special tracks, copy protection) to 3" disc?
I suppose IDSK is for normal games , because I tried it. Discology maybe?

DSK routine support copying dsk images of  many formats (even mixed ones), various sector lengths (from 256bytes up to 4096 bytes) , tracks (up to 82) and heads (single/dual head), so you might be able to copy some protected games, but it can't handle write/read GAPs (the most common way of copy protections).  Unfortunately 3" disk drive is rather limited in utilizing all available functions of the 765 FDC controller, so even using Discology with a gotek drive (with flash floppy firmware), i don't think you will be able to transfer copy protected images to  3" disks, but  you might be able to do it, with a 3.5" disk drive.
In any case, since nowadays you can find everything in unprotected/cracked images, why bother doing this? 

[GUNHED]

In addition it would be nice to have a way to work with files bigger than 64 KB. 

The 64k limit exists only when you use Amsdos routines to access files (CASOPEN, CASDIRECT, etc)  . If you develop your own file access routines (like i've already done for accessing dsk images that can be up to 800kb for parados images), there is practically no limit, as the pointer to a file is 32bit e.g. you can create/read/write files up to... 4GigaBytes in size!

Exzellent! Cause I already have mid-level-functions dealing with that. 

[vasilisk]

Is there a way to copy original dsk image (special tracks, copy protection) to 3" disc?
I suppose IDSK is for normal games , because I tried it. Discology maybe?

DSK routine support copying dsk images of  many formats (even mixed ones), various sector lengths (from 256bytes up to 4096 bytes) , tracks (up to 82) and heads (single/dual head), so you might be able to copy some protected games, but it can't handle write/read GAPs (the most common way of copy protections).  Unfortunately 3" disk drive is rather limited in utilizing all available functions of the 765 FDC controller, so even using Discology with a gotek drive (with flash floppy firmware), i don't think you will be able to transfer copy protected images to  3" disks, but  you might be able to do it, with a 3.5" disk drive.
In any case, since nowadays you can find everything in unprotected/cracked images, why bother doing this? 

Call it nostalgia... ZaptBallsAE was one of the few original games I own. Of all the disks I have only this one suddenly is not loading. Could be the drive, but in order to eliminate it, I have to load the disk in another amstrad. Of course I can write the cracked dsk's in the disk but... I would like the original. 

[GUNHED]

Another question about access to files using the USB stick:
Is it true that only upper case characters can be used? Or is there a way to be able to use lower case characters too?

[eto]

Is it true that only upper case characters can be used? Or is there a way to be able to use lower case characters too?

Afaik that's a limitation of the  CH376 usb host module. It only supports the ancient 8.3 format :-(

[Prodatron]

Is it true that only upper case characters can be used? Or is there a way to be able to use lower case characters too?

Afaik that's a limitation of the  CH376 usb host module. It only supports the ancient 8.3 format :-(

So what's the issue with this?
You can either choose between 8+3 (FAT12-32 without long file names) or 256 or more with UTF16 (have a lot of fun with an 8bit machine ).
And why complaining? Either you implement your own FAT file system on the Z80, or you are not able to do it and have to use an external CPU (M4Board, CH376) which is 100-10000 times faster like the CPCs Z80, to have access to modern SD cards and USB stick. I prefer the first one, where the CPC is doing the complete job - just because it can do it with no limitations.

[eto]

So what's the issue with this?

My (only) issue is that on a USB Stick with hundreds of directories and files it's not easy to navigate when the file and directory names become barely readable.

And why complaining?

I think I did not complain. I just explained why there is no upper/lower case support and that it's a hard limit with no workaround.  

[Prodatron]

So what's the issue with this?

My (only) issue is that on a USB Stick with hundreds of directories and files it's not easy to navigate when the file and directory names become barely readable.

And why complaining?

I think I did not complain. I just explained why there is no upper/lower case support and that it's a hard limit with no workaround. 

The problem for an 8bit system is, that it is really hard to handle long filenames with UTF16 chars. If you don't use long filenames too much and keep most stuff within 8+3 you can still handle a FAT32 filesystem with the CPC quite well. Anyway this has nothing to do with implementing an own filesystem in Z80 or using an external high power chip.
I know that there are implementations like on the Atari8, but for me as a programmer it would be hell to implement it in an OS and support it in an app.

[GUNHED]

So.... can that system with long file-names work with small letters or not?

[Prodatron]

So.... can that system with long file-names work with small letters or not?

As mentioned in my previous post, it is UTF-16 based. You probably know what that means?

[GUNHED]

So.... can that system with long file-names work with small letters or not?

As mentioned in my previous post, it is UTF-16 based. You probably know what that means?

No, else I wouldn't ask.

[Prodatron]

No, else I wouldn't ask.

I am sorry, I didn't know this!

Here you see a screen shot of directory sectors containing long file names (LFNs) on a FAT32 device:

You cannot view this attachment.

Like in CP/M, when a file is >16K, they are using multiple extends for storing the same file. These extends are used for storing the second _long_ version of the filename. And these are stored in UCS2 (which is a subset of UTF16) encoding, which allows not only to store all standard ASCII, upper/lowercase etc. chars but every char you can imagine, as it is always using 16bit (sometimes even 32bit) for storing one single char.

Here you can find a description:
https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#VFAT

Norecess already implemented LFN support in the HxC manager, like FlashJazzCat for some of his Atari8 stuff. For read only it is ok, but for implementing a full R/W directory handling it will use several more resources than just the 8.3 filename handling.

Anyway somehow I am glad, that the CH376 is still providing the 8.3 way, when using its high level filesystem access, as that still keeps it easier and compatible on an 8bit machine.

[GUNHED]

Thank you PDT! As you know I'm a pure CPC-guy, while you worked in PC world professionally quite some time. PC related stuff is still strange to me. 

From your explanation, I see: Eventually we can use lower cases with the ULIfAC to. And this is done by working with long file-names (what I prefer anyway, due to better readability). 

[Prodatron]

As you know I'm a pure CPC-guy, while you worked in PC world professionally quite some time.

When you work professionally in the PC world you have nothing to do with low level filesystem stuff

From your explanation, I see: Eventually we can use lower cases with the ULIfAC to. And this is done by working with long file-names (what I prefer anyway, due to better readability). 

I don't know about any documentation how to handle long file names with the CH376. It is limited to 8.3, see "5.15. CMD_SET_FILE_NAME" in the official datasheet. LFN support is mentioned in the specs, but I wonder if anyone found out how to use this?

[GUNHED]

Well, if I find out I let you know. Maybe I did misread a post before. We'll see. 

[ikonsgr]

Another question about access to files using the USB stick:
Is it true that only upper case characters can be used? Or is there a way to be able to use lower case characters too?

Directly, yes, CH376 needs upper case characters, BUT i've overcome this, by using a small routine that replace "on the fly", the lowercase with uppercase chars, before sending filename to CH376:

Code Select Expand

do_upper_case:
upper_loop:
ld a,(hl)
cp 32
jr z,cont_upper_loop
call upper_case
out (c),a
cont_upper_loop:
inc hl
dec e
jr nz,upper_loop
ret

upper_case:
    ld    a,(hl)
    cp 'a'                ; A-'a'  C=1 if A<'a'
    jr c, no_offset          ; if character < 'a' is not a lowercase
    cp 'z'+1              ; A-'z'+1 C=0 if A>'z' 
    jr nc, no_offset      ; if character > 'z' is not a lowercase
    sub 32                ; sub 32 to convert it to UPPER case
    ld    (hl),a
no_offset:
    ret
 I'm using this routine for all RSX commands that need string arguments, so practically all rsx commands can take upper/lower case characters without problem 

[ikonsgr]

Afaik that's a limitation of the  CH376 usb host module. It only supports the ancient 8.3 format :-(

Well, ancient Amstrad CPC and ancient Amsdos, also uses the same ancient format, so why spoil the... "tradition"? 

And as prodatron wrote, and i totally agree with that:

Anyway somehow I am glad, that the CH376 is still providing the 8.3 way, when using its high level filesystem access, as that still keeps it easier and compatible on an 8bit machine.

[ikonsgr]

I just explained why there is no upper/lower case support and that it's a hard limit with no workaround.   

Actually there is a quite easy workaround for that: https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/ulifacusb-mass-storage-wifi-512kb-ram32xrom-board256k-ram16x-rom-board!/msg243866/#msg243866   

[ikonsgr]

I don't know about any documentation how to handle long file names with the CH376. It is limited to 8.3, see "5.15. CMD_SET_FILE_NAME" in the official datasheet. LFN support is mentioned in the specs, but I wonder if anyone found out how to use this?

@GUNHED , @Prodatron CH376 can perfectly access files with any upper/lower case and long filename, you just have to "translate" it to uppercase 8.3 format!
For example, lets say we have a file, named: "story_of_my_life.bas" . In order to open it for either read or write,  you should call it as: "STORY_~1.BAS".  So if you give an open file sequence to CH376 that has a name of "STORY_~1.BAS", it will actually open the file "story_of_my_life.bas" 

[GUNHED]

Thank you all for the clarification. 

[Manuel3D]

I don't know about any documentation how to handle long file names with the CH376. It is limited to 8.3, see "5.15. CMD_SET_FILE_NAME" in the official datasheet. LFN support is mentioned in the specs, but I wonder if anyone found out how to use this?

@GUNHED , @Prodatron CH376 can perfectly access files with any upper/lower case and long filename, you just have to "translate" it to uppercase 8.3 format!
For example, lets say we have a file, named: "story_of_my_life.bas" . In order to open it for either read or write,  you should call it as: "STORY_~1.BAS".  So if you give an open file sequence to CH376 that has a name of "STORY_~1.BAS", it will actually open the file "story_of_my_life.bas" 

I don't know about any documentation how to handle long file names with the CH376. It is limited to 8.3, see "5.15. CMD_SET_FILE_NAME" in the official datasheet. LFN support is mentioned in the specs, but I wonder if anyone found out how to use this?

@GUNHED , @Prodatron CH376 can perfectly access files with any upper/lower case and long filename, you just have to "translate" it to uppercase 8.3 format!
For example, lets say we have a file, named: "story_of_my_life.bas" . In order to open it for either read or write,  you should call it as: "STORY_~1.BAS".  So if you give an open file sequence to CH376 that has a name of "STORY_~1.BAS", it will actually open the file "story_of_my_life.bas"