@LiveForIt

Block numbers are always stored in 32 bit integers, either signed or unsigned. That was not what I meant.

I was speaking about the blocks the bitmap is stored in. Bitmap blocks contain one 32bit checksum and the rest of the block is used for the bitmap, so you have 508*8 bits = 4064 bits per block.

I am not sure (and not interested in) how FFS organizes its bitmap. But as I already wrote, it was my (false) impression that it reserves a fixed number of them. So for example if you reseve 4096 bitmap blocks, you can map 4096 * 4064 = 16,646,144 data blocks which represents a little less than 8 GBytes.

But as I already admitted, my assumption was wrong, there is no such limit, at least not for version 45 of FFS.

Bye,
Thomas

@acefnq

AFAIK the partition size limit for FFS is caused by a fixed number of bitmap blocks. I always thought that there is a 8GB limit for 512 Byte blocks which could be extended by increasing the file system block size.

However, recently I tested the creation of a 33 GB partition with FFS V45 (the one which comes with OS 3.9) and 512 byte blocks. And I could successfully format it. So the 8gb limit seems not to exist.

However, this huge partition with such a small block size needed about 10 seconds to mount on reboot. Increasing the block size to 4096 bytes fixed this.

So with OS 3.9 there seems to be no size limit for FFS partitions. I don't know which limitations the AFFS driver in Linux has, though.

Bye,
Thomas

@Skov

Quote:

Yes, that's the migration procedure. The only one. Backup, change, reboot, format, restore. One or more partitions at a time.

Quote:

Yes, each partition has its own file system settings.


Quote:

I don't know if it's just you. But in the prefs you can only change the debug level anyway, so it's not so important.

Bye,
Thomas

@Skov

At the UBoot prefs press Esc and select "enter UBoot shell". At the shell prompt enter printenv. Press cursor-down quickly to stop the scrolling list. Check if there is a variable called menuboot_delay and if it is set to 0.

If it is 0, enter setenv menuboot_delay 3 or any other number of seconds. Then enter saveenv and reset.

Now you should see a progress bar which allows you to enter the UBoot prefs by a key press. When the delay is over, it should boot without entering the menu.

Bye,
Thomas

@slcroucher

Quote:

It should work perfectly.

Quote:

Use quick format. Full format does nothing else but produce hot air.

Bye,
Thomas

@joerg

Does that mean Spirantho's card is fried now ?

@frl9lk

You cannot go past the 4GB limit with Kickstart 3.1. So once you start writing to the 5th 1GB-partition, it will destroy the first one. Perhaps even filling up the 4th partiton with data might overwrite the beginning of the HDD. One day you might even loose all partitions when you overwrite the partition table.

Run Check4GB from Aminet to check. If you have further questions, post its output here.

Bye,
Thomas

@Swoop

The assign command creates something like a logical alias. The alias name is called TurboCalc: (with colon !). If you want to refer to the alias you have to use the full name TurboCalc: (with colon).

So you can create an alias for a directory

assign TurboCalc: Work2:TurboCalc

Now you can refer to the directory as TurboCalc: and to the program as TurboCalc:TurboCalc.

Or you can create an alias for a file

assign TurboCalc: Work2:TurboCalc/TurboCalc

Now you can refer to the file as TurboCalc: (with colon). You cannot refer to it as TurboCalc (without colon).

This means, if you want to point your project icons to the assign, the project icons have to have TurboCalc: (with colon !) as default tool.

If you want to refer to TurboCalc without colon as default tool, then assign is not the tool to use. In this case you should add the directory where TurboCalc is in to the system path and remove the assign alltogether.

user-startup:

path add Work2:TurboCalc

Then you can use "TurboCalc" without colon and without absolute path as default tool.

IMHO assigns to files are something strange and shouldn't be used.

Bye,
Thomas

@Swoop

If you have external hard drives with multiple partitions, then yes, probably.

Bye,
Thomas

@Swoop

Quote:

No, but it's related to CrossDOS.

CrossDOS uses the last character of the drive name to identify the partition: C = first partition, D = second, E = third etc.

If the last character is not a letter (as for example in PC0), it treats the volume as a floppy disk without any partitions.

Bye,
Thomas

@tiffers

http://thomas-rapp.homepage.t-online.de/os39uae.html

Bye,
Thomas

@MamePPCA1

Below the source path there is an entry field which can be enabled by the checkbox next to it and it allows you to enter a directory name. It's labelled "Image path". For each source path you can enter a different image path.

Bye,
Thomas

@Snuffy
Quote:

Why don't you read the E-UAE manual then ? It's an UAE-specific config file, you won't find anything about it in any OS4 manual.

Bye,
Thomas

@Spirantho

You can remove the fan without the heat sink. No need for glue or thermal paste. Just four screws.

You should replace the fan ASAP. The PPC runs hot (and dies) even if it has nothing to do.

Bye,
Thomas

@LiveForIt

Then give more details. Post your code or something. One cannot tell you what is wrong if you don't say what you did.

Bye,
Thomas

@LiveForIt

Check io_Error.

@SZAMAN

That's strange. OS3 datatypes don't support alpha, OS4 datatypes do. So you should have a border around the images on OS3, but not on OS4.

Perhaps MUI does not support alpha blending and the images have a grey background. So you don't notice it on OS3, although it's there.

Bye,
Thomas

@Valiant

Quote:

How is it added to E-UAE ?

Quote:

Yes. If you used HDToolbox to partition it, then you have to use HDToolbox to flag it bootable.

Quote:

Do you run E-UAE on that Amiga ? What do you understand by a "real" Amiga ? AmigaOne is not a real Amiga in this context.

Bye,
Thomas

@Valiant

Yes, it's supposed to boot from HDD, even without an installed OS.

However,Quote: What do you mean by that ?

If this is a real HDD partition on a real Amiga HDD or a HDF in RDB mode, then it has to be flagged as bootable in HDToolbox. Only HDD directories or conventional HDFs boot automatically.

Bye,
Thomas

@abalaban

Quote:

Icon positions are stored in the icons (.info files). When you snapshot the ram disk icon, the coordinates are stored in ram:disk.info, i.e. in the ram disk itself. And all files stored in ram are lost after a reboot, so the snapshot is lost, too, unless you manually copy the icon somewhere and restore it before Workbench is loaded next time.

There is a quite elegant solution for the ram disk which works since OS3.9 with Boingbag 2: add the following line to your user-startup:

makelink ram:disk.info envarc:sys/def_ram.info soft

This connects the ram disk icon to the file it is loaded from by default. So you can snapshot it like any other (permanent) disk icon.

Workbench also moves icons out of the way automatically if they are too near at each other. This is only done on the desktop, though, not in drawers. IIRC you can specify the minimum distance between two icons in Workbench prefs since OS3.9, too.

Bye,
Thomas