65536 cylinder hardfile limit

[Anubis]

Toni, while working on RaspberryPi, I created 2 HD in WinUAE and neither WinUAE or UAE4ARM can see them. I can recall we had similar issues some times back, when HD is given incremental size of 1024MB / 1GB.

If you create HDF of 1023MB and/or 1025MB, everything works fine, but 1024 for some strange reason does not even show?!

ps. This issue is easy to recreate - but if you need anything, let me know.

[Toni Wilen]

EDIT: moved from beta thread.

Standard question: what does this have to do with 3.3 betas?

It is pre-OS3.9 AmigaOS limit, number of cylinders must be less than 65536. Increase surfaces value until WinUAE stops warning about "Too high cyls". (For example 15 should be fine)

Or use RDB hardfiles.

[Anubis]

Originally Posted by Toni Wilen

Standard question: what does this have to do with 3.3 betas?

It is pre-OS3.9 AmigaOS limit, number of cylinders must be less than 65536. Increase surfaces value until WinUAE stops warning about "Too high cyls". (For example 15 should be fine)

Or use RDB hardfiles.

It was tested with 3.3 betas and interestingly works with 1023 or 1025MB, but not with 1024?! (or any increment of 1024?!) Not sure that you want new topic with any issues...

Why only 1024MB HD gets wrong number of cylinders??

Yep, simple change in number of surfaces lowered number of cylinders - can you make it default to higher number of number is 65536??

[Toni Wilen]

Originally Posted by Anubis

It was tested with 3.3 betas and interestingly works with 1023 or 1025MB, but not with 1024?! (or any increment of 1024?!) Not sure that you want new topic with any issues...

Why only 1024MB HD gets wrong number of cylinders??

Read first post! ("Main rule: Before reporting, make sure bug is NOT in previous offical version. It must be unique to this beta series! (If it is -> post in separate thread). No feature requests.")

Because 1G becomes exactly 65536 cylinders (with default geometry) which AmigOS sees as 0 cylinders.

[Toni Wilen]

I am not going to change the calculation method. Geometry is saved in config file, not in hardfile -> any geometry calculation change would break existing hardfiles that use similar size! (Too many users just expect hardfile to work without also copying geometry)

EDIT: there is also another problem, if it gets changed, it gets different geometry in different emulation (If it also does not have the same update). It would not really fix anything. Only guaranteed "fix" is to adjust the geometry manually.

[Anubis]

This is not a problem if you use RDB setting?

Not asking you to do anything to HDF, just in emulator to recognize when surfaces are equal to 65536 and no RDB set - HD will not be visible in emulator. Either that or give some warning when user as stupid as me tries to create 1GB HD.

Thanks for splitting it from 3.3 discussion.

[Toni Wilen]

As I said, it is AmigaOS restriction (Unless you have OS39) and winuae already warns about cylinder value. It is tiny warning because there is nothing wrong from emulation point of view and depending on AOS version, there is no limit.

[Toni Wilen]

Originally Posted by Anubis

This is not a problem if you use RDB setting?

HDToolbox (or other partitioning programs) generate more compatible geometry. Note that geometry is logical/virtual only but it still needs to be inside certain limits, depending on OS version.

I really recommend using RDB hardfiles because all metadata (geometry and partitions etc) is inside the hdf, it can be transferred between different emulators or even to/from real hardware and it still works.

"Partition" harddrives were practically only a workaround because in early days full RDB support didn't exist. Of course they are also too easy to use

[Anubis]

What would happen if by default HDF is RDB?

[Toni Wilen]

Originally Posted by Gimba1

What would happen if by default HDF is RDB?

Most users would get confused and think something got broken. "Partition" hardfiles are too popular. (because they are too easy to create and use).

I guess defaulting to RDB mode when file is larger than >=1G could be acceptable.

[Anubis]

Now we getting somewhere...

[mark_k]

Originally Posted by Toni Wilen

As I said, it is AmigaOS restriction (Unless you have OS39) and winuae already warns about cylinder value. It is tiny warning because there is nothing wrong from emulation point of view and depending on AOS version, there is no limit.

Is the restriction really on the FFS version? If the user has the latest FFS version on their PC and tells WinUAE to use that, does the problem still happen?

[Toni Wilen]

Originally Posted by mark_k

Is the restriction really on the FFS version? If the user has the latest FFS version on their PC and tells WinUAE to use that, does the problem still happen?

No idea, possibly. (really useful, wasn't it? )

[rsn8887]

Does it really break some hdf's if surfaces is defaulted to e.g. 4 instead of 1? I tested a few of my hdf's with surfaces = 4 and they all still work, although they were created with surfaces=1 or 2.

[meynaf]

Originally Posted by rsn8887

Does it really break some hdf's if surfaces is defaulted to e.g. 4 instead of 1? I tested a few of my hdf's with surfaces = 4 and they all still work, although they were created with surfaces=1 or 2.

The condition is that surfaces * sectors * cylinders ends up being the same value (I think).
Perhaps indeed winuae should change to 4 before displaying "too many cyls", and keep 1 when 1 works fine.

[rsn8887]

I implemented an automatic switch like that in my latest mod of UAE4ALL2 for Vita. It seems to work. I did it like this: if hdf size >1024 * 1024 * 1000 bytes (1GB) use surfaces = 2. If size larger than 2*1024 * 1024 * 1000 (2GB) then use surfaces = 4.

Of course the user can still go in and modify the geometry in the config file manually. But it is a better default than always using surfaces = 1, which, together with the sectors=32,blocksize=512 default setting will never work if the hdf is >1GB.

The only thing that still baffles me is that hdf > 2Gb does not work in UAE4ALL/UAE4Arm, even with surfaces = 4. But in WinUAE it works fine.

I am know using three 2GB hdf's to store the full WHDLoad collection, which should be ok but only works with iGame, since no other menu program allows >2 source directories. I wish I had time to code another menu program, like a super simple stripped down version of Tinylauncher that allows up to 8 source directories to create a combined list.

I wonder if it is possible to combine the tiny launcher database by hand to merge three into one?