Hyperion Entertainment Message Boards

The picture tells it all.
May I try to burn that iso with AmiDVD?
Latest public OS4, Enhancer stuff.

What are your versions of RAWBInfo and exFATFileSystem?

You could also try listing the file directly with the list command ("list USB0D:xxx.iso") and see if it outputs the correct size (if you do this also report what version your list command is).

The latest RAWBInfo should be able to handle files of up to a few terabytes but it's possible that the public version is older.

salass00 wrote:What are your versions of RAWBInfo and exFATFileSystem?

I checked my 4.1 FE update #1 installation and the latest public version of RAWBInfo is version 53.19 from 2014, which still uses the old FileInfoBlock based examine method.

I replaced all the FIB code for version 53.22, which was released to beta testers November 2015 (a year too late to make it into the 4.1 FE release).

So don't worry about it, it's just a cosmetic issue.

As you said 53.19 RAWBInfo is here.
The list display file size correctly.

The original icon information window (when RAWBInfo inactive) is even worse. Displays -2 bytes for size.

lazi wrote:The original icon information window (when RAWBInfo inactive) is even worse. Displays -2 bytes for size.

That code is even older and since barely anyone is using the old, built in WBInfo() in workbench.library there is not much motivation to update it, and it is also more work to update since it depends more heavily on the FileInfoBlock structure.

Does exfat understand umlauts (utf-8, i think) in the meantime?

Raziel wrote:Does exfat understand umlauts (utf-8, i think) in the meantime?

AFAIK, All the new filesystems (NGFS and FUSE based filesystems) now support UTF-8 encoded Unicode,
even RAM: and ENV: handlers also do, (I added it myself). The problem is that we don't currently have a way
of displaying UTF-8 (other than the low 7 bit ascii values) it in a shell (or elsewhere), without custom support.

The graphics system still uses 8 bit code pages at the moment. This limitation is being addressed.

For example;
You could name a removable USB stick on Linux with UTF-8 encoded Unicode characters for another language,
but currently, when it is inserted on the Amiga, the special UTF-8 byte sequences would be interpreted and displayed
in the current locale charset as 8 bit code page values instead, which would make the name show incorrectly.
However, the stick would still be perfectly functional.

It's only the display of UTF-8 encoded Unicode values (above 127) that are currently affected.

@colinw

Thank you for the info

colinw wrote:

Raziel wrote:Does exfat understand umlauts (utf-8, i think) in the meantime?

AFAIK, All the new filesystems (NGFS and FUSE based filesystems) now support UTF-8 encoded Unicode,
even RAM: and ENV: handlers also do, (I added it myself).

Thanks!

The graphics system still uses 8 bit code pages at the moment. This limitation is being addressed.

Very Good news!

The option I use for testing is to dump displayables into a text file (c:list >t:listing) and then open the text file made in TimberWolf,

if you have a full Unicode Arial / Meiryo Ui / MS Mincho or other font available and set in Timberwolf,
*all* of the font provided Unicode characters become viewable.

I'm using this as my workaround in trying to validate that I have correct Kanji selections as part of my own efforts.

I’m currently waiting for Intuition to display Unicode so that I can actively begin building/testing user viewable parts of perception and polymorph as well ( not yet 100% happy with these code sections so not yet pushed to the public repositories)