I am on the process of upgrading my original A500 Rev8A1 with all the bells and whistles it can possibly get. I bought a HAMA usb card reader which was recognized (all 4 usbscsi.devices) on MorphOS and preparing the compact flash (for later internal use on the A500) on our platform is a crucial part of the project.

I am studying THIS guide on Library but some questions have arise:

1) If partition name gets "CF0", will that cause any conflict to 68k progs looking for DH0 by default?

1A) I have experienced conflicts with HDFs that have Volume name as "System" on MorphOS (usually they are ready to play HDF packages). Sometimes they don't appear on Ambient after mounting or they take over my actual System partition and when I double click my own MorphOS System, instead of my regular System, a 3.x System might appear. I have been able to overcome this by mounting on e-uae, then manually copying its content to a secondary empty hdf (which is mounted on e-uae as well), quit, mount the new hdf on Ambient and rip its content. But this procedure is tiresome, is there a way to overcome this? Because I fear that even if I do a "CF0" the "System" partitions having the same name might conflict again. What do you think?

2) Under PFS3AIO do we have to use a different hex identifier too, same as SFS on the example? Is the MorphOS PFS incompatible with 68k?

3) Max transfer rate is again 0x1FE00 if the CF will be connected to a fast ide port (in my example to TF536 ide)? From benchmarks I saw that accelerator's speed is about the double compared to a stock 1200 ide. So, should the max rate be doubled as well? :D

3A) THIS link states: Specific max transfer settings are not required if you use IDEfix97 on internal IDE, when using PFS3 All-in-One or when using PCMCIA (emphasis mine). If so, then how the setup of the CF should like on MorphOS?

Generally speaking, I think the tutorial on the Library should be updated to include PFS3AIO drive format, since it's considered the defacto on 68k and others might be in my position in the future.

Having 2 partitions with the same name and/or device name can cause issues but shouldn't affect booting.
Booting into AmigaOS (aka the other kind of 3.x ;) ) is more likely due to it having the same or higher BootPri as your main boot partition.

Programs asking for "DH0:" instead of going for "SYS:" are just badly coded and should be fixable by adding an assign.


My advice:
Setup the CF card with non conflicting device and volume name and make sure the BootPri is in clear favour of the MorphOS partition.

If you don't plan to transfer files with this card later just change everything to normal names once booted into AmigaOS on the A500.


Otherwise I would suggest adding the assigns there to fix broken SW.

One can also edit OF env or bootinfo.txt and add „bd dh1:” to boot args. That’d make MorphOS disregard boot priorities entirely.

> that accelerator's speed is about the double compared to a
> stock 1200 ide. So, should the max rate be doubled as well?

MaxTransfer is not about speed per se but about the maximum size of the chunk the controller can transfer to the storage medium at once. This value is specific to the storage controller. It is possible that a slower controller accepts a bigger MaxTransfer value and vice versa. The only ways to know this value for sure are by documentation or trial.

Quote:
I don't think there are many programs hardcoded to DH0, after all it was popular to name partitions as HD0, HD1, etc too in old times and nobody complained. I would say that only couple of really old or amateurish games could be hardcoded for DH0... and they are broken by desing in that case :)

Doesn't even HDToolbox name partitions according manufacturer? At least I'd remember getting QDH0 for a Quantum drive etc. In any case CF0: should be just fine.


Quote:
Too bad someone has named them as System... by default Amiga's system partition is named as Workbench. And for a game installation a game name would be more proper, or so...

But an easier way that should work:
1) Mount a HDF in FileImageCtrl, for example, by dragging&dropping the image file into the program window.
2) Relabel the image from the Shell by using a device name as the first argument. If the image got mounted in unit 0, then "Relabel FILE0: NewName" should do the trick.


Quote:
I don't know if the MorphOS PFS3 and PFS3AIO are compatible, and if nobody (Piru) will confirm, I'd use a different identifier.

MorphOS uses identifier 0x50465303 (PFS3... 50 = "P", 46 = "F", 53 = "S", 03 = 3), and to make it different you could use some other number at the end or change the letters. I don't know if there is any recommendation for AIO or is it common to use the same PFS3 for it too. Direct SCSI version of PFS3 did use PDS3, and then older PFS versions used PFS2 etc. But to pull something out of the hat, maybe AIO3, PAO3, PFS9, or something like that could be used as long as you use the same identifier on the filesystem you add to the RDB and on the actual partition. Use KeyExplorer to convert those letters to hex values, and add a zero in front of a digit :)


Quote:
As told, max transfer value isn't related to the actual speed. I guess there isn't a noticeable difference in transfer speeds on any Amiga hw because of this.


Quote:
If those workarounds in PFS3AIO will make it work like 0x1FE00 anyway, why not use it in the first place too? I don't know.. at least if you put 0x1FE00 and happen to format it with some other filesystem later, it'd be there just in case :)


Quote:
The tutorial was written by me, but I've had better experiences with SFS in the old days, and don't have much experience with PFS3AIO... and its archive is just empty on documentation, so I should dig around all forum threads to learn it properly... maybe some day.

So, I 've finally concluded my little endeavour and thought to post about it since I couldn't find any relevant info :)

It is possible to install AmigaOS 3.2 directly from Ambient but you need to perform the following steps:

1) Rip the adf drawer from AOS3.2 CD to your HD
2) Launch FileImageCtrl and mount adf/install3.2.adf
2a) Browse to install3.2:install/ and right click -> information of the language you wish to proceed with the setup and change default tool to Install3.2:Installer
3) Load your preferred editor (i.e. Flow Development, GoldEd etc) the script located at install3.2:install/install and edit the following lines:
- Line 4630 to (MOUNTADF "Locale_0")
- Line 4643 to (dest "Locale_0")
- Line 4652 to (dest "Locale_0")
- Line 4685 to (UNMOUNTADF "Locale_0")
- Line 5934 to (MOUNTADF "Fonts_0")
- Line 5950 to (dest "Fonts_0")
- Line 5959 to (dest "Fonts_0")
- Line 5970 to (UNMOUNTADF "Fonts_0")

^ Basically you add a "_0" and that's because when you mount the adf/locale.adf and adf/fonts.adf with FileImageCtrl, due to the fact that you have same assigns on MorphOS, it labels the mounted adfs as "Locale_0" and "Fonts_0".

Think, this could be avoided if the original installer requested a volume name such as Fonts3.2 or Locale3.2 same as it happens "Extras3.2" and the likes. Otherwise, the install script would be compatible and even the AmigaOS3.2CD:Install/VirtualFloppies scripts would work, straight from the CD.

Once installation finishes, you can copy the kicka1200.rom from ROM drawer, and point to the newly installed location your e-uae and load AOS3.2. Furthermore, you can proceed to install the 3.2.1 update straight from Ambient too.

For a basic A1200 emulation setup, you don't need the ModulesA1200_3.2.adf and MMULibs.adf as far as I understand.

However, and pay attention to this: if you plan on using AOS 3.2 or 3.2.1 as a platform for WHDLoad think twice given that AOS3.2.x loads at least 5 times slower compared to a plain 3.1 setup and if you go for the the Glowicons option during install think thrice because the redraw of the emulated environment is way too uncomfortable.

PS: MorphOS uses same hex identifier with the 68k PFS3 :)

[ Edited by Cool_amigaN 03.01.2023 - 11:26 ]

Quote:

Not 100% sure, but I think I read somewhere that the option was deprecated after 2.x and is ignored by most controllers.

Lots of talk about data corruption with high values, so probably best to leave it to default anyway.

Quote:

It shouldn't be, but in the past I've found it almost impossible not to use filesystems that were resident in MorphOS. They override any disk-based fs. This may be intended behaviour.

I tried this with an older FFS and an older SFS, on floppies (via Catweasel). It would always use the MorphOS version regardless of any tricks such as different dostypes.

>> MaxTransfer

> Not 100% sure, but I think I read somewhere
> that the option was deprecated after 2.x

MaxTransfer has never been deprecated. In fact, it's only been made superfluous as recent as in AmigaOS 3.2 for internal scsi.device and GVP drivers specifically.

AmigaOS 3.1.4 FAQ:
"You need to change this setting for the built-in scsi.device using HDToolBox (select Partition -> Change), to 1FE00. This will limit block transfers to 255 blocks. In the case of third-party drive interface hardware, please consult the corresponding manual to find out the recommended max transfer setting."
http://aminet.net/docs/help/AmigaOS_3.1.4-FAQ.txt

AmigaOS 3.2 FAQ:
"After some back and forth trying to solve this issue, fortunately enough, the HDToolBox "max transfer" value is no longer required on the built-in scsi.device driver of 3.2, and also on drive interfaces made by the manufacturer formerly known as "GVP". In the case of other third-party drive interface hardware, please consult the corresponding manual to determine the recommended max transfer setting."
http://aminet.net/docs/help/AmigaOS_3.2-FAQ.txt

> and is ignored by most controllers.

Actually, it's the duty of the filesystem to implement MaxTransfer functionality, read the respective value from the RDB and act accordingly with data transfers to the device driver. Controllers or their drivers do not know anything about MaxTransfer as they only get in touch with it indirectly, namely by the size of the chunks they receive from the respective filesystem.

> Lots of talk about data corruption with high values,
> so probably best to leave it to default anyway.

Default is too high for ATA-2 and newer drives, so it must be lowered to 0x1FE00.

Interestingly, it was only in 2011 that Toni Wilen fully discovered the reason for the old issue that makes lowering MaxTransfer necessary:
http://eab.abime.net/showthread.php?p=759918#post759918