English Amiga Board


Go Back   English Amiga Board > Support > support.Other

 
 
Thread Tools
Old 21 May 2018, 18:37   #161
Nounouss33
Registered User
 
Nounouss33's Avatar
 
Join Date: Apr 2018
Location: France
Age: 53
Posts: 22
Quote:
Originally Posted by cyberhead97 View Post
I have re-factored Build EAB WHDLoad Install into Build Install Entries for a more broad support, so it should also support WHDLoads from WHDownload and KGWHD even though I'm not sure if anyone use them at the moment. They use the same filename convension, which adds the support for them.

At the same time I have added best version filtering based on identical entry name and rank calculated from conventions used for WHDLoad filenames. It now gives the user selection between following entries sets:
  1. All: Install all entries.
  2. Best-Version: Install best version of identical entries.
  3. Best-Version-Lowmem: Install best version of identical entries for low mem Amigas (unexpanded chip mem only or low fast mem e.g. 1-2mb).
Best version means Build Install Entries will pick the highest ranking entry per entry name, hardware and language. This is also done for lowmem WHDLoads, which basically means these entries will get a higher score, if they have words like "chip", "lowmem" and memory size words like "512k" also gives higher score than "2mb".

I have attached some screenshots of the new re-factored Build Install Entries, showing the added entries sets and extended support for handling multi language entries.

Then I have done some testing with PFS/3 image template "4gb_hdf_rdb_dh0-100mb-pds3_dh1-3.4gb-pds3.zip" and got following results installing best version and best version lowmem entries sets:
  1. Install: Entries set = Best Version. Hardware = AGA, OCS. Language = EN. Result = DH1 has ~61MB of 3.4GB free.
  2. Install: Entries set = Best Version LowMem. Hardware = AGA, OCS. Language = EN. Result = DH1 has ~73MB of 3.4GB free.
  3. Install: Entries set = Best Version. Hardware = OCS. Language = EN. Result = DH1 has ~542MB of 3.4GB free.
  4. Install: Entries set = Best Version LowMem. Hardware = OCS. Language = EN. Result = DH1 has ~542MB of 3.4GB free.

The is the goal I was aiming for with introduction of best version and best version lowmem entries sets being able to install "all" games on a 4GB HDF image.

So far I only have Windows version done and next is refactoring python version for macOS and Linux users.

This will be part of upcoming v1.2.0-BETA5 release.
Hi Cyberhard97,
Now that i was successfull in using the BETA4 self-installed 16gigs image, i decided to go for your main program and build my own image.
However there's oviously an issue when it comes to handling user packages :

1) I have ensured that the directories names for games and demo have the correct name :

C:\temp2\userpackages\eab-whdload-demos
C:\temp2\userpackages\eab-whdload-games

All demos and games subdirectories have been copied here like i did for the self-installed image.

2) I select option 6 => configure user packages
3) I select option 1 => Change user packages
And i choose C:\temp2\userpackages
4) The directory name is correctly reflected in main display
5) then i choose option 2 => Select user packages Menu
6) I choose option 1 => Select "Select all"
And here comes the problem : In main display, "Install user packages" does not change, it keeps to "None".

So i cannot select user packages to install. Is it expected ? Is it something which is not yet handled in Beta4 ?

Thanks again for this incredible stuff, and last but not the least, I just took the 16gig self-installed HDF files which was successfully installed a few days ago, and transferred it to my mister FPGA : It works

If you can help on the main program issue with user packages that would be cool

Thanks again !

Last edited by Nounouss33; 21 May 2018 at 18:46.
Nounouss33 is offline  
Old 21 May 2018, 20:22   #162
cyberhead97
Registered User
 
Join Date: Feb 2016
Location: Denmark
Posts: 333
Quote:
Originally Posted by Nounouss33 View Post
Hi Cyberhard97,
Now that i was successfull in using the BETA4 self-installed 16gigs image, i decided to go for your main program and build my own image.
However there's oviously an issue when it comes to handling user packages :

1) I have ensured that the directories names for games and demo have the correct name :

C:\temp2\userpackages\eab-whdload-demos
C:\temp2\userpackages\eab-whdload-games

All demos and games subdirectories have been copied here like i did for the self-installed image.

2) I select option 6 => configure user packages
3) I select option 1 => Change user packages
And i choose C:\temp2\userpackages
4) The directory name is correctly reflected in main display
5) then i choose option 2 => Select user packages Menu
6) I choose option 1 => Select "Select all"
And here comes the problem : In main display, "Install user packages" does not change, it keeps to "None".

So i cannot select user packages to install. Is it expected ? Is it something which is not yet handled in Beta4 ?

Thanks again for this incredible stuff, and last but not the least, I just took the 16gig self-installed HDF files which was successfully installed a few days ago, and transferred it to my mister FPGA : It works

If you can help on the main program issue with user packages that would be cool

Thanks again !
I haven't got around to write documentation for user packages yet, so I would expect some potential issues.

Does HstWB Installer list user packages at "5) then i choose option 2 => Select user packages Menu" something like this:
  1. Select all
  2. Deselect all
  3. + eab-whdload-demos
  4. + eab-whdload-games
  5. Back

Does your user packages "C:\temp2\userpackages" have a "_installdir" file? E.g. do you have the file "C:\temp2\userpackages\eab-whdload-games\_installdir"?

A user package must contain "_installdir" file for HstWB Installer to accept it as "_installdir" file tells HstWB Installer where the user package should be installed. If these are not present, then it could explain why you see "None" for install user packages after selecting all. The directory "Support\User Packages" in HstWB Installer contains all files incl. "_installdir" for EAB WHDLoads from Retroplay, if those are there ones you need.

Thanks for testing on your Mister FPGA and confirming that a 16GB hdf works there.

Last edited by cyberhead97; 21 May 2018 at 20:24. Reason: Removed double numbering for list
cyberhead97 is offline  
Old 21 May 2018, 21:24   #163
Nounouss33
Registered User
 
Nounouss33's Avatar
 
Join Date: Apr 2018
Location: France
Age: 53
Posts: 22
Quote:
Originally Posted by cyberhead97 View Post
I haven't got around to write documentation for user packages yet, so I would expect some potential issues.

Does HstWB Installer list user packages at "5) then i choose option 2 => Select user packages Menu" something like this:
  1. Select all
  2. Deselect all
  3. + eab-whdload-demos
  4. + eab-whdload-games
  5. Back

Does your user packages "C:\temp2\userpackages" have a "_installdir" file? E.g. do you have the file "C:\temp2\userpackages\eab-whdload-games\_installdir"?

A user package must contain "_installdir" file for HstWB Installer to accept it as "_installdir" file tells HstWB Installer where the user package should be installed. If these are not present, then it could explain why you see "None" for install user packages after selecting all. The directory "Support\User Packages" in HstWB Installer contains all files incl. "_installdir" for EAB WHDLoads from Retroplay, if those are there ones you need.

Thanks for testing on your Mister FPGA and confirming that a 16GB hdf works there.
Thanks a lot for promptly answering.

Now you make it clear :

1) No The user packages are not listed when selecting all packages

2)
- I thought i just had to create the directory and put eab-whdload-games / eab-whdload-demos in it.

- Then i told myself that i should take scripts from 16g self-install image subdirectory "userpackages" place them in C:\temp2\userpackages and run the script (as i did for self-install image). That's what i did, but, indeed, _installdir files are missing.

How are they supposed to be created ? I can see that they are delivered by the 16g self-install image (and not created afterward). So obviously i'm missing a step to have this file in each sub-directory.

Would you be able to advise what i should do ?

Thanks again, and frankly this stuff is just amazing and a true gem for people having a few knowledge about installing an Amiga on hard drive, really !
Nounouss33 is offline  
Old 21 May 2018, 22:03   #164
cyberhead97
Registered User
 
Join Date: Feb 2016
Location: Denmark
Posts: 333
The easiest way of getting the files you need for user package directories "eab-whdload-games" and "eab-whdload-demos", is copy files from HstWB Installer "Support\User Packages" and copy the files to your user packages directory "C:\temp2\userpackages". It has all the files you need and should have same directory names "eab-whdload-games" and "eab-whdload-demos". Otherwise download HstWB Installer standalone, it also has the files in "Support\User Packages" directory.

Please try this and see if it helps.

Thanks, it's good to get feedback that it helps people uncommon to Workbench and setting up Amiga from scratch.
cyberhead97 is offline  
Old 21 May 2018, 22:41   #165
Nounouss33
Registered User
 
Nounouss33's Avatar
 
Join Date: Apr 2018
Location: France
Age: 53
Posts: 22
Quote:
Originally Posted by cyberhead97 View Post
The easiest way of getting the files you need for user package directories "eab-whdload-games" and "eab-whdload-demos", is copy files from HstWB Installer "Support\User Packages" and copy the files to your user packages directory "C:\temp2\userpackages". It has all the files you need and should have same directory names "eab-whdload-games" and "eab-whdload-demos". Otherwise download HstWB Installer standalone, it also has the files in "Support\User Packages" directory.

Please try this and see if it helps.

Thanks, it's good to get feedback that it helps people uncommon to Workbench and setting up Amiga from scratch.
I tried both options and it perfectly works !!!!!! Thank you so much !!!!
It's definitively helping people uncommon to Workbench and setting up Amiga from scratch. There's nearly nothing to do, you made the perfect solution !!! I could not believe someone had spent so much time on doing this. You can't imagine how much time i've searched youtube and the internet, trying to mix different tuto and getting lost. Not that i don't want to learn Amiga, i will. But there are many people planning to run the Amiga on their FPGA and it's not that easy. Even not talking about people trying to do the same for their rapberry pi ..... I'm spreading the work on facebook about your nice tool. And i have planned to make a simple tuto for the Mister group. Thanks again !!!
Nounouss33 is offline  
Old 22 May 2018, 14:03   #166
cyberhead97
Registered User
 
Join Date: Feb 2016
Location: Denmark
Posts: 333
Quote:
Originally Posted by Nounouss33 View Post
I tried both options and it perfectly works !!!!!! Thank you so much !!!!
It's definitively helping people uncommon to Workbench and setting up Amiga from scratch. There's nearly nothing to do, you made the perfect solution !!! I could not believe someone had spent so much time on doing this. You can't imagine how much time i've searched youtube and the internet, trying to mix different tuto and getting lost. Not that i don't want to learn Amiga, i will. But there are many people planning to run the Amiga on their FPGA and it's not that easy. Even not talking about people trying to do the same for their rapberry pi ..... I'm spreading the work on facebook about your nice tool. And i have planned to make a simple tuto for the Mister group. Thanks again !!!
Thats good to hear.

I'm have planned to build a wizard to help making optimal choice of image templates and packages to install as it can be a tricky process to determine for new users.

It will be something like:

Quote:
Step 1: What do you want to install?
1. Install Workbench from scratch.
2. Install packages or user packages for existing Amiga setup.

Step 2: Which Amiga do you have?
1. Amiga 500, 600, 1000, 2000, CDTV.
2. Amiga 1200, Amiga 4000, CD32.
3. Emulator.

Step 3: Which emulator are you using? (shown only if emulator is selected)
1. WinUAE.
2. FS-UAE.
3. UAE4ARM.
4. Amiberry.

Step 4: Which expansions do you have installed? (not shown, if emulator is selected)
1. None.
2. Accelerator card with fast ram.
3. Accelerator card with cpu, fast ram.
4. RTG card.

Step 5: Which Workbench setup do ou want to use?
1. Workbench 3.1.
2. Amiga OS 3.9.
3. ClassicWB.
4. HstWB.

... more to be added.
The choices from the wizard would then result in a sort of recipe for HstWB Installer. For install mode using HstWB Installer, all choices could result in preconfigured setup ready to run. For self install images it would compose a step by step guide with links to relevant tutorials.

It's on the drawing board and planned for v2.0.0, when I start development for that.

Refactoring of Build Install Entries scripts is now complete supporting Windows, macOS and Linux. This means I'm will start building and releasing HstWB Installer v1.2.0-BETA5 including an updated version of Amibian img for RaspBerry Pi with latest changes.

I'm quite amazed by the speed of python compared to powershell versions of Build Install Entries scripts. On my Windows PC python version is ~10 times faster than powershell.

Last edited by cyberhead97; 22 May 2018 at 14:04. Reason: spelling
cyberhead97 is offline  
Old 27 May 2018, 19:39   #167
Nounouss33
Registered User
 
Nounouss33's Avatar
 
Join Date: Apr 2018
Location: France
Age: 53
Posts: 22
Quote:
Originally Posted by cyberhead97 View Post
Thats good to hear.

I'm have planned to build a wizard to help making optimal choice of image templates and packages to install as it can be a tricky process to determine for new users.

It will be something like:



The choices from the wizard would then result in a sort of recipe for HstWB Installer. For install mode using HstWB Installer, all choices could result in preconfigured setup ready to run. For self install images it would compose a step by step guide with links to relevant tutorials.

It's on the drawing board and planned for v2.0.0, when I start development for that.

Refactoring of Build Install Entries scripts is now complete supporting Windows, macOS and Linux. This means I'm will start building and releasing HstWB Installer v1.2.0-BETA5 including an updated version of Amibian img for RaspBerry Pi with latest changes.

I'm quite amazed by the speed of python compared to powershell versions of Build Install Entries scripts. On my Windows PC python version is ~10 times faster than powershell.
That sounds really cool And yeah, python seems to be a really good choice even for any further of your own developments. It's a terrific scripting language and it's used all over the place in the IT industry.

By the way have 2 questions :
1) Do you have any plan to handle boing bag 3,4,4a ?
2) I though that might be helpfull to report you this if your program is meant for real amiga hardware. Maybe you're already aware about this, and if not i guess you can better understand thant me :
It seems like Images created with winuae are not compatible with real Amiga hardware. This is a comment from our Mister FPGA facebook group by the Mister main dev following a recurrent problem reported by users not sometime being able to boot their winuae hdf file image (Minimig is the FPGA code name for the Amiga):

=======================
"All in all. After analyzing images from WinUAE i want to tell: be careful when you create image in WinUAE. They are NOT compatible with real Amiga hardware and can be used only in WinUAE. WinUAE injects its own fake driver uaehf.device which bypass Amiga IDE implementation and can use illegal CHS values. I even see that HDToolBox on such images has patched reference in icon properties to uaehf.device. So if you start this HDToolBox on Minimig you won't see any HDD. You need to change this reference back to scsi.device.
I'm not sure if there is a way to create an image in WinUAE compatible with real Amiga - it has many options when you connect the image in WinUAE. So, this part need investigation. May be if you choose IDE 600/1200 while connecting the image, then it will use original scsi.device driver and then won't provide illegal CHS while initializing."
=======================

Then a follow up :
=======================
i'm testing fall back to old calculated CHS values if RDB has illegal values. With this workaround you can boot these strange HDFs, but you won't be able to add/edit partitions as it's totally screwed because Workbench uses values from RDB header while Minimig itself uses calculated CHS values. So, now i'm testing 12GB image with 255 heads and 63 SPT. HDToolBox sees only 8GB. The number of cylinders is wrong.
Do you have any idea if it's possible to make an image which removes this uaehf.device scsi driver ?
=======================

And someone having the original problem and providing a possible working solution :
=======================
OK I find a way to make it on Winuae. First make an image not greater that 14GB (I had problems with those over 14GB) I used an 12GB hdf file. Then mount it as Amiga600/1200/4000 IDE not uaehf.device (I used SCSI 2+ or SCSI 2+ Strict mode). Partition it, format and copy or install the system (on Winuae or as wanted). Don't forget to upgrade scsci.device to for example 44.20 (that's what i use) and of course to add PFS/3 file system. Anyway I someone will need help (step by step instructions), feel welcome to ask.
=======================



I must admit i do not get everything. I would appreciate if you could help me to clarify this. I had no problem to boot your images, but was wondering how your program is creating the disk images (are you enforcing real Amiga Hardware when creating them ?). And is it possible to create a real amiga hardware disk image not screwed up by this fake driver uaehf.device ?


Thanks !

Last edited by Nounouss33; 27 May 2018 at 19:57.
Nounouss33 is offline  
Old 27 May 2018, 20:27   #168
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
That explanation does not make any sense.

Geometry stored in RDB is virtual, it rarely have anything to do with "real" (it has not been real since SCSI and IDE was invented) drive geometry and driver should not use it for anything else than telling dos to do its job with the partition.

You can partition drive using SCSI controller and move it to Amiga IDE (or vice versa) or partition CF card in WinUAE with UAE controller and move it to real IDE/SCSI controller and still boots normally, even if "geometry" is different, as long as both understand RDB partition tables. (and aren't stupid or buggy) (EDIT: Of course you need adapter if you move between IDE and SCSI, for example CF in Amiga IDE and CF in ACard adapter in A3000 SCSI)

EDIT2: Even simply copying HD image to another type of HD works fine, drive even can be larger than source drive. Without any changes to "geometry".

Last edited by Toni Wilen; 27 May 2018 at 20:52.
Toni Wilen is offline  
Old 27 May 2018, 21:37   #169
Nounouss33
Registered User
 
Nounouss33's Avatar
 
Join Date: Apr 2018
Location: France
Age: 53
Posts: 22
Quote:
Originally Posted by Toni Wilen View Post
That explanation does not make any sense.

Geometry stored in RDB is virtual, it rarely have anything to do with "real" (it has not been real since SCSI and IDE was invented) drive geometry and driver should not use it for anything else than telling dos to do its job with the partition.

You can partition drive using SCSI controller and move it to Amiga IDE (or vice versa) or partition CF card in WinUAE with UAE controller and move it to real IDE/SCSI controller and still boots normally, even if "geometry" is different, as long as both understand RDB partition tables. (and aren't stupid or buggy) (EDIT: Of course you need adapter if you move between IDE and SCSI, for example CF in Amiga IDE and CF in ACard adapter in A3000 SCSI)

EDIT2: Even simply copying HD image to another type of HD works fine, drive even can be larger than source drive. Without any changes to "geometry".
OK, but how does it come these observations are made : I mean the person who has provided a way to avoid this problem ("then mount it as Amiga600/1200/4000 IDE not uaehf.device (I used SCSI 2+ or SCSI 2+ Strict mode") was the person having the problem while using "uaehf.device". Any idea where the issue could come from ?
What's the difference between using "uaehf.device" and "Amiga600/1200/4000 IDE" ? Why these options do exist ?

Not blaming at all, juste trying to figure out what many persons have reported this problem
Nounouss33 is offline  
Old 28 May 2018, 08:39   #170
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
It most likely does not work because it does some extra geometry translation logic that should not be done. It probably is something that old 8-bit systems need, systems that don't have native HD support and needs all kinds of weird geometry support to work with the HD.

AmigaDOS side geometry is always imaginary, it exists but does not need to match HD geometry, as long as geometry calculated size is same or less than LBA size. RDB block CHS values should be also considered as imaginary, for example hdtoolbox and hdinsttools use different method to generate it.

Filesystem (or if application directly access drive) uses LBA (actually byte offset from beginning of drive but only functional difference is annoying 32-bit 4G limit). There is also Direct SCSI access mode but it does not change much.

Device driver gets LBA, converts it to whatever HD needs. It never needs to know geometry values stored to RDB to access the drive. RDB partition geometry values are also only needed during automounting phase and driver only needs to pass them to dos that does the rest.

If drive is SCSI: convert to SCSI READ/WRITE commands. (easy and simple)
If drive is LBA IDE (and driver supports LBA): convert to matching IDE READ/WRITE commands. Similar to SCSI case.
If drive is CHS IDE: more complex calculation, take drive's current CHS geometry (INIT PARAMETERS is also used to set default geometry, because apparently some ancient Conner returned bogus geometry in initial IDENTITY DRIVE), use it to convert LBA value to CHS IDE READ/WRITE commands.
If drive is some ancient MFM one: driver again does the translation transparently.

All this is completely hidden from AmigaDOS and application. Application or filesystem does not need to know (and should not know, it only needs to know that it is a HD-like) type of storage device used.
Toni Wilen is offline  
Old 28 May 2018, 13:22   #171
cyberhead97
Registered User
 
Join Date: Feb 2016
Location: Denmark
Posts: 333
Quote:
Originally Posted by Nounouss33 View Post
That sounds really cool And yeah, python seems to be a really good choice even for any further of your own developments. It's a terrific scripting language and it's used all over the place in the IT industry.

By the way have 2 questions :
1) Do you have any plan to handle boing bag 3,4,4a ?
2) I though that might be helpfull to report you this if your program is meant for real amiga hardware. Maybe you're already aware about this, and if not i guess you can better understand thant me :
It seems like Images created with winuae are not compatible with real Amiga hardware. This is a comment from our Mister FPGA facebook group by the Mister main dev following a recurrent problem reported by users not sometime being able to boot their winuae hdf file image (Minimig is the FPGA code name for the Amiga):
I did have plans to support Boing Bag 3 & 4, but focused more on Boing Bag 1 & 2 as they are original patches where 3 & 4 are built by the community. I might add these at a later point in time, so for now it's a manual installation.

The image templates I have created and the resulting images that HstWB Installer builds works fine on real Amigas. I have written them to SD-cards for both my A600 and A1200 and I don't have any issues there.

If you're a new Amiga user then these questions are quite common. The tricky part is how does Mister FPGA handle hdf files.

When you going beyond 4GB harddrive, then you will hit some well known issues, which all boilds down to knowing your limits with your Amiga and it's attached hardware.

There is a lot of techincal details you need consider for IDE and SCSI harddrives and Toni definitely knows a lot about this as you can see with his insight.

Since I primarily use real A600, A1200 and emulators those are the ones I have most experience with.

For A600 and A1200 with IDE harddrive or CF/SD card using Kickstart 3.0 or Kickstart 3.1 consider the following:
  1. Boot partition must be smaller than 4GB and inside the first 4GB of the harddrive.
  2. Additional data/work partitions can be larger than 4GB and even up to 127GB+ depending on filesystem.

To get A600/A1200 to support more than 4GB you need to do one of the following:
  1. During boot load patched scsi.device v43.43+ using LoadModule. This causes a reboot.
  2. Custom built and burned Kickstart 3.X with patched scsi.device v43.43+ and install it in A600/A1200.
  3. Accelerator cards like ACA, Blizzard and Apollo can also load custom built Kickstart 3.X into fast ram to avoid having to burn an eprom with Kickstart 3.X. But it may still require a 4GB partition to boot and load Kickstart 3.X to fast ram.

WinUAE or FS-UAE by default supports more than 4GB using it's UAE controller. Therefore it's important not to create partitions that will not work in a real Amiga depending on hardware used and limits that apply.

So e.g. creating one single partition sized to 14GB will only work on a real A600 or A1200 with custom built and burned Kickstart 3.X with patched scsi.device v43.43+.

In general it's recommended to create a boot partition at 300-500MB as the first part of the harddrive then most Amiga can boot this without patched. Then during boot you can apply patches to scsi.device using e.g. LoadModule. This approach works fine with my 16GB images.

In some cases I have experienced that I need to keep images below 4GB for best compatibility in real Amigas, so if all fails then go for 4GB images and no patches.

With Mister FPGA I don't much about it's Amiga core and it's capabilities regarding hdf implementation. The main developer of Mister FPGA can probably help with details about what hdf images it supports like:
  1. Can it use RDB HDF?
  2. Does the I/O implementation support hdf files larger than 4GB? This may even be a limit with filesystem running on SD-card inserted in Mister FGPA. If this is FAT32, then hdf files are by definition limited to 4GB due to FAT32 limits.

The second part of 4GB harddrive size issues is the filesystem. The default FastFileSystem (FFS) in Kickstart 3.0/3.1 doesn't support more than 2GB. So an updated or patched filesystem is also required for large harddrives and partitions.

For filesystem I would recommend Toni's latest PFS3AIO 3.0 with gives better performance than FFS and supports up to 127GB+ partitions. More than 127GB is possible, but is in experimental state.

To summarize on images created with WinUAE doesn't work on real Amiga is not true, if you do it the right way. It can tricky to make hdf images compatible with optimal partitioning, support more than 4GB, so I would recommend to use a prebuilt hdf file unless you're willing to spend the time it requires to research and experiment with this.

Here's some answers to the comments you provided.

Quote:
Originally Posted by Nounouss33 View Post
I'm not sure if there is a way to create an image in WinUAE compatible with real Amiga - it has many options when you connect the image in WinUAE. So, this part need investigation. May be if you choose IDE 600/1200 while connecting the image, then it will use original scsi.device driver and then won't provide illegal CHS while initializing."
As Toni also has written, Amiga's doesnt really care about the CHS values as long as it's RDB is valid. You can have a drive geometry in RDB that doesn't match physical drive.

Quote:
Originally Posted by Nounouss33 View Post
Do you have any idea if it's possible to make an image which removes this uaehf.device scsi driver ?
Uaehf.device is only present when running an image in emulators like WinUAE, FS-UAE, UAE4ARM or Amiberry as it a device part of the emulator and it's UAE controller. So running the image on a real Amiga will not have uaehf.device present, which makes it easy to remove.

Quote:
Originally Posted by Nounouss33 View Post
OK I find a way to make it on Winuae. First make an image not greater that 14GB (I had problems with those over 14GB) I used an 12GB hdf file. Then mount it as Amiga600/1200/4000 IDE not uaehf.device (I used SCSI 2+ or SCSI 2+ Strict mode). Partition it, format and copy or install the system (on Winuae or as wanted). Don't forget to upgrade scsci.device to for example 44.20 (that's what i use) and of course to add PFS/3 file system. Anyway I someone will need help (step by step instructions), feel welcome to ask.
I have created hdf images at 64GB and they work fine in my A600 or A1200. This is all about creating the hdf image, so it works within the limits that apply for real Amiga depending on it's hardware. My image templates are created with WinUAE, Amiga OS 3.9 and UAE controller's uaehf.device. The trick is to keep the boot partition inside the first 4GB, load patched scsi.device during boot and use a filesystem that supports partitions larger than 4GB.

Quote:
Originally Posted by Nounouss33 View Post
I must admit i do not get everything. I would appreciate if you could help me to clarify this. I had no problem to boot your images, but was wondering how your program is creating the disk images (are you enforcing real Amiga Hardware when creating them ?). And is it possible to create a real amiga hardware disk image not screwed up by this fake driver uaehf.device ?

Thanks !
My images part of HstWB Installer are prebuilt and ready for use meaning they are partitioned, formatted, blank with no data on them. I haven't got a step by step guide to create them, but might write much a tutorial at a later point in time. For now you're welcome to request special hdf images and I can create them for you.

I'm sure uaehf.device is not a fake device, but more harddrive controller only available in WinUAE, FS-UAE, UAE4ARM and Amiberry emulators using UAE controller for harddrives. It's actually a big help as it's doesn't have all the limits that scsi.device has making it easy to create and use large harddrives. But remember to use it wisely to create, partition and format hdf images that are within the limits of the real Amiga's scsi.device or the hardware.

Oh dear, this became a long answer, but I hope it helps clarify some of the issues related to hdf images on real Amiga or in emulators .
cyberhead97 is offline  
Old 28 May 2018, 20:14   #172
Nounouss33
Registered User
 
Nounouss33's Avatar
 
Join Date: Apr 2018
Location: France
Age: 53
Posts: 22
Quote:
Originally Posted by cyberhead97 View Post
I did have plans to support Boing Bag 3 & 4, but focused more on Boing Bag 1 & 2 as they are original patches where 3 & 4 are built by the community. I might add these at a later point in time, so for now it's a manual installation.

The image templates I have created and the resulting images that HstWB Installer builds works fine on real Amigas. I have written them to SD-cards for both my A600 and A1200 and I don't have any issues there.

If you're a new Amiga user then these questions are quite common. The tricky part is how does Mister FPGA handle hdf files.

When you going beyond 4GB harddrive, then you will hit some well known issues, which all boilds down to knowing your limits with your Amiga and it's attached hardware.

There is a lot of techincal details you need consider for IDE and SCSI harddrives and Toni definitely knows a lot about this as you can see with his insight.

Since I primarily use real A600, A1200 and emulators those are the ones I have most experience with.

For A600 and A1200 with IDE harddrive or CF/SD card using Kickstart 3.0 or Kickstart 3.1 consider the following:
  1. Boot partition must be smaller than 4GB and inside the first 4GB of the harddrive.
  2. Additional data/work partitions can be larger than 4GB and even up to 127GB+ depending on filesystem.

To get A600/A1200 to support more than 4GB you need to do one of the following:
  1. During boot load patched scsi.device v43.43+ using LoadModule. This causes a reboot.
  2. Custom built and burned Kickstart 3.X with patched scsi.device v43.43+ and install it in A600/A1200.
  3. Accelerator cards like ACA, Blizzard and Apollo can also load custom built Kickstart 3.X into fast ram to avoid having to burn an eprom with Kickstart 3.X. But it may still require a 4GB partition to boot and load Kickstart 3.X to fast ram.

WinUAE or FS-UAE by default supports more than 4GB using it's UAE controller. Therefore it's important not to create partitions that will not work in a real Amiga depending on hardware used and limits that apply.

So e.g. creating one single partition sized to 14GB will only work on a real A600 or A1200 with custom built and burned Kickstart 3.X with patched scsi.device v43.43+.

In general it's recommended to create a boot partition at 300-500MB as the first part of the harddrive then most Amiga can boot this without patched. Then during boot you can apply patches to scsi.device using e.g. LoadModule. This approach works fine with my 16GB images.

In some cases I have experienced that I need to keep images below 4GB for best compatibility in real Amigas, so if all fails then go for 4GB images and no patches.

With Mister FPGA I don't much about it's Amiga core and it's capabilities regarding hdf implementation. The main developer of Mister FPGA can probably help with details about what hdf images it supports like:
  1. Can it use RDB HDF?
  2. Does the I/O implementation support hdf files larger than 4GB? This may even be a limit with filesystem running on SD-card inserted in Mister FGPA. If this is FAT32, then hdf files are by definition limited to 4GB due to FAT32 limits.

The second part of 4GB harddrive size issues is the filesystem. The default FastFileSystem (FFS) in Kickstart 3.0/3.1 doesn't support more than 2GB. So an updated or patched filesystem is also required for large harddrives and partitions.

For filesystem I would recommend Toni's latest PFS3AIO 3.0 with gives better performance than FFS and supports up to 127GB+ partitions. More than 127GB is possible, but is in experimental state.

To summarize on images created with WinUAE doesn't work on real Amiga is not true, if you do it the right way. It can tricky to make hdf images compatible with optimal partitioning, support more than 4GB, so I would recommend to use a prebuilt hdf file unless you're willing to spend the time it requires to research and experiment with this.

Here's some answers to the comments you provided.



As Toni also has written, Amiga's doesnt really care about the CHS values as long as it's RDB is valid. You can have a drive geometry in RDB that doesn't match physical drive.



Uaehf.device is only present when running an image in emulators like WinUAE, FS-UAE, UAE4ARM or Amiberry as it a device part of the emulator and it's UAE controller. So running the image on a real Amiga will not have uaehf.device present, which makes it easy to remove.



I have created hdf images at 64GB and they work fine in my A600 or A1200. This is all about creating the hdf image, so it works within the limits that apply for real Amiga depending on it's hardware. My image templates are created with WinUAE, Amiga OS 3.9 and UAE controller's uaehf.device. The trick is to keep the boot partition inside the first 4GB, load patched scsi.device during boot and use a filesystem that supports partitions larger than 4GB.



My images part of HstWB Installer are prebuilt and ready for use meaning they are partitioned, formatted, blank with no data on them. I haven't got a step by step guide to create them, but might write much a tutorial at a later point in time. For now you're welcome to request special hdf images and I can create them for you.

I'm sure uaehf.device is not a fake device, but more harddrive controller only available in WinUAE, FS-UAE, UAE4ARM and Amiberry emulators using UAE controller for harddrives. It's actually a big help as it's doesn't have all the limits that scsi.device has making it easy to create and use large harddrives. But remember to use it wisely to create, partition and format hdf images that are within the limits of the real Amiga's scsi.device or the hardware.

Oh dear, this became a long answer, but I hope it helps clarify some of the issues related to hdf images on real Amiga or in emulators .
So many stuff to learn about Thank you very much for this very detailed answer. Actually by posting first Toni answer on our facebook group, it triggered a really large discussion between the mister dev and another person. I did not get everything, just caught that it's complex topic for a newb. I don't want to polute this thread and actually i do not have Toni knowledge to argue. I was just trying to figure out where the issue was. And the mister dev knows also a lot, so i guess only a discussion between him and Toni could lead to clarification. If i were the mister dev i would have contacted tony to sort this out. But again i'm simply an end user, and i produced nothing, so i'm not really legit to discuss about all this and how to sort it out. So i will stop this specific discussion here Again thanks a lot for your work, can't wait to test next release ! and thanks a lot for taking the time to answer. This forum is really friendly
Nounouss33 is offline  
Old 28 May 2018, 20:17   #173
Nounouss33
Registered User
 
Nounouss33's Avatar
 
Join Date: Apr 2018
Location: France
Age: 53
Posts: 22
Quote:
Originally Posted by Toni Wilen View Post
It most likely does not work because it does some extra geometry translation logic that should not be done. It probably is something that old 8-bit systems need, systems that don't have native HD support and needs all kinds of weird geometry support to work with the HD.

AmigaDOS side geometry is always imaginary, it exists but does not need to match HD geometry, as long as geometry calculated size is same or less than LBA size. RDB block CHS values should be also considered as imaginary, for example hdtoolbox and hdinsttools use different method to generate it.

Filesystem (or if application directly access drive) uses LBA (actually byte offset from beginning of drive but only functional difference is annoying 32-bit 4G limit). There is also Direct SCSI access mode but it does not change much.

Device driver gets LBA, converts it to whatever HD needs. It never needs to know geometry values stored to RDB to access the drive. RDB partition geometry values are also only needed during automounting phase and driver only needs to pass them to dos that does the rest.

If drive is SCSI: convert to SCSI READ/WRITE commands. (easy and simple)
If drive is LBA IDE (and driver supports LBA): convert to matching IDE READ/WRITE commands. Similar to SCSI case.
If drive is CHS IDE: more complex calculation, take drive's current CHS geometry (INIT PARAMETERS is also used to set default geometry, because apparently some ancient Conner returned bogus geometry in initial IDENTITY DRIVE), use it to convert LBA value to CHS IDE READ/WRITE commands.
If drive is some ancient MFM one: driver again does the translation transparently.

All this is completely hidden from AmigaDOS and application. Application or filesystem does not need to know (and should not know, it only needs to know that it is a HD-like) type of storage device used.
Thanks for your answers Toni. I realize it's not a convenient way to act as a postman and hopping for having the mister dev contact you to sort this out At least i managed to have the mister dev exchange further about the handling of Amiga HDF. Too much complex for me, so i will stop here this discussion. By the way Thanks a lot for the incredible work put into winuae
Nounouss33 is offline  
Old 28 May 2018, 20:20   #174
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
(I was writing this when last 2 posts appeared)

Better check: http://eab.abime.net/showthread.php?t=61666
Because it is never too simple..

Assuming it is not FAT limited (4G file size), easiest way is to return "illegal" IDE CHS geometry which enables direct scsi (with matching filesystem) support up to 128G. Without any driver patches when using A600/A1200/A4000 IDE.

Quote:
As Toni also has written, Amiga's doesnt really care about the CHS values as long as it's RDB is valid. You can have a drive geometry in RDB that doesn't match physical drive.
It probably never matches "physical" geometry if not IDE. HDtoolbox just generates geometry when using SCSI drives because SCSI does not have any kind of geometry (some mode pages return imaginary values but hdtoolbox does not care).

I think this whole fake geometry stuff in Amiga was only needed because dos.library (Tripos) internally uses it.

Quote:
I'm sure uaehf.device is not a fake device, but more harddrive controller only available in WinUAE, FS-UAE, UAE4ARM and Amiberry emulators using UAE controller for harddrives. It's actually a big help as it's doesn't have all the limits that scsi.device has making it easy to create and use large harddrives. But remember to use it wisely to create, partition and format hdf images that are within the limits of the real Amiga's scsi.device or the hardware.
Exactly. It is like any other Amiga device driver that implements exact same API as any other device driver. Technically you could still say it is fake because all entry points only contain magic trap instructions that redirect control to native side. But from Amiga point of view it looks normal.

Amiga has huge amount of different HD controllers (Commodore and 3rd party). Most of them have differently named driver that implements same common driver API.

Some support >4G drive access, some support direct scsi (which also means >4G support), many don't. Some have other limits..
Toni Wilen is offline  
Old 28 May 2018, 23:53   #175
Nounouss33
Registered User
 
Nounouss33's Avatar
 
Join Date: Apr 2018
Location: France
Age: 53
Posts: 22
Quote:
Originally Posted by Toni Wilen View Post
(I was writing this when last 2 posts appeared)

Better check: http://eab.abime.net/showthread.php?t=61666
Because it is never too simple..

Assuming it is not FAT limited (4G file size), easiest way is to return "illegal" IDE CHS geometry which enables direct scsi (with matching filesystem) support up to 128G. Without any driver patches when using A600/A1200/A4000 IDE.



It probably never matches "physical" geometry if not IDE. HDtoolbox just generates geometry when using SCSI drives because SCSI does not have any kind of geometry (some mode pages return imaginary values but hdtoolbox does not care).

I think this whole fake geometry stuff in Amiga was only needed because dos.library (Tripos) internally uses it.



Exactly. It is like any other Amiga device driver that implements exact same API as any other device driver. Technically you could still say it is fake because all entry points only contain magic trap instructions that redirect control to native side. But from Amiga point of view it looks normal.

Amiga has huge amount of different HD controllers (Commodore and 3rd party). Most of them have differently named driver that implements same common driver API.

Some support >4G drive access, some support direct scsi (which also means >4G support), many don't. Some have other limits..
Thanks a lot for this very interesting post Toni, lots of usefull information. Indeed it's not that easy
Nounouss33 is offline  
Old 03 June 2018, 18:05   #176
RoC
Registered User
 
Join Date: May 2011
Location: Italy
Posts: 214
Quote:
Originally Posted by roc View Post
- The HstLauncher looks very promising for supporting low-end classics. While I use AGS2 on the A1200, I plan using HstLaunch for the rest of the WHDload collection such the magazines/intros/betas, although I should start the work and don't know if this is going to be feasible. I am reporting if you like the idea for the "official" release.

Hi there,


After some time, I completed the AGS2 menu entries creation for both Cracktros and Magazines. To do so, I have customised one of your PowerShell scripts, downloaded the images from Janeway (when available) or created in WinUAE. Both sets include your "usual" txt, run and iff files.


If you feel this could be of any help, I can "zone" the AGS2 entries for Cracktros and Magazines together with the PowerShell script.

Click image for larger version

Name:	001.png
Views:	349
Size:	13.7 KB
ID:	58459

Click image for larger version

Name:	002.png
Views:	282
Size:	58.9 KB
ID:	58460

Click image for larger version

Name:	003.png
Views:	323
Size:	55.7 KB
ID:	58461


Moreover, I have made some progress with the Amiga scripts. In essence, they are meant to extract the LHAs into the various A-Z folders of the beta3/beta4 images while customising the options of the AGS2 and some other softwares to my needs. Again, I am a total noob, but could uplodad these Amiga scripts, should you like to. Your image works well on WinUAE, classic real and FPGA solutions like the FPGArcade.



Look forward to adopting the beta5 once that would be available

Last edited by RoC; 05 June 2018 at 11:34. Reason: Added Images
RoC is offline  
Old 05 June 2018, 23:08   #177
cyberhead97
Registered User
 
Join Date: Feb 2016
Location: Denmark
Posts: 333
Quote:
Originally Posted by roc View Post
Hi there,


After some time, I completed the AGS2 menu entries creation for both Cracktros and Magazines. To do so, I have customised one of your PowerShell scripts, downloaded the images from Janeway (when available) or created in WinUAE. Both sets include your "usual" txt, run and iff files.


If you feel this could be of any help, I can "zone" the AGS2 entries for Cracktros and Magazines together with the PowerShell script.

Attachment 58459

Attachment 58460

Attachment 58461


Moreover, I have made some progress with the Amiga scripts. In essence, they are meant to extract the LHAs into the various A-Z folders of the beta3/beta4 images while customising the options of the AGS2 and some other softwares to my needs. Again, I am a total noob, but could uplodad these Amiga scripts, should you like to. Your image works well on WinUAE, classic real and FPGA solutions like the FPGArcade.



Look forward to adopting the beta5 once that would be available
This is fantastic roc.

I noticed Retroplay WHDLoads contains Magazines, so I had plans to add those in future packages for HstWB Installer. It's really great that you have Cracktros added as well.

I would like to have your script changes included in the repo and they could be added as a pull request with commit flow described here https://gist.github.com/Chaser324/ce0505fbed06b947d962.

It sounds like we should create Magazine and Cracktros menu packages.

For HstWB Installer v1.2.0-BETA5 I have been working on an update of the Install UAE Config script, which is being refactored to a new HstWB Image Setup script.

The new HstWB Image Setup script will work on any UAE or FS-UAE config files and is no longer tied to HstWB Installer config files for WinUAE or FS-UAE. It will read UAE or FS-UAE config files to determine if it going to create self install directories (workbench, kickstart, os39 and userpackages directories) or not and install Workbench 3.1 adf and Kickstart rom files into them.

HstWB Image Setup script performs following installation steps:

1. Automatically detect and find Cloanto Amiga Forever data dir.
- Scans drives or mounted iso on Windows, macOS and Linux.
- Environment variable "AMIGAFOREVERDATA".
2. Detect if UAE or FS-UAE configuration files contains self install directories.
- Detect and install Workbench 3.1 adf and Kickstart rom files from Cloanto Amiga Forever data dir using MD5 hashes.
- Validate files in self install directories workbench, kickstart, os39 and userpackages using MD5 hashes to indicate, if all files are present for self install.
3. Detect files for patching configuration files.
- Find A1200 Kickstart rom 3.1 in kickstart dir.
- Find Amiga OS 3.9 iso file in os39 dir.
4. Patch and install UAE and FS-UAE configuration files.
- For FS-UAE configuration files, .adf files from Workbench directory are added as swappable floppies.

So in short it means users don't have to know anything about how to properly configure and setup UAE or FS-UAE config files and Workbench 3.1 and Kickstart rom files. All that is required is that either Cloanto Amiga Forever is installed (Windows only) or Cloanto Amiga Forever dvd iso is mounted (Windows, macOS and Linux), then HstWB Image setup script does the rest.

Final tweaks are being done, so HstWB Installer v1.2.0-BETA5 can be released.

Here's output from current python version of HstWB Image Setup script.

Code:
PS D:\hstwb-installer\support\Install UAE Config> python .\hstwb_image_setup.py --installdir 'test'
-----------------
HstWB Image Setup
-----------------
Author: Henrik Noerfjand Stengaard
Date: 2018-06-05

Install dir 'test'

Cloanto Amiga Forever
---------------------
Autodetecting Amiga Forever data dir:
- Detected Amiga Forever data dir from environment variable
Done

Amiga Forever data dir 'C:\Users\Public\Documents\Amiga Files\'
Install Workbench 3.1 adf and Kickstart rom files from Cloanto Amiga Forever:
- Amiga Forever data dir shared adf dir 'C:\Users\Public\Documents\Amiga Files\Shared\adf'
- Installing Workbench 3.1 adf files to Workbench dir 'test\workbench'...
- Amiga Forever data dir shared rom dir 'C:\Users\Public\Documents\Amiga Files\Shared\rom'
- Installing Kickstart rom files to Kickstart dir 'test\kickstart'...
Done

Workbench dir 'test\workbench'
Kickstart dir 'test\kickstart'
OS39 dir 'test\os39'
User packages dir 'test\userpackages'

Self install directories
------------------------
Validating Workbench dir 'test\workbench'...
- 6 of 6 Workbench 3.1 adf files detected
- Workbench 3.1, Extras Disk (Cloanto Amiga Forever 2016) MD5 match 'test\workbench\amiga-os-310-extras.adf'
- Workbench 3.1, Fonts Disk (Cloanto Amiga Forever 2016) MD5 match 'test\workbench\amiga-os-310-fonts.adf'
- Workbench 3.1, Install Disk (Cloanto Amiga Forever 2016) MD5 match 'test\workbench\amiga-os-310-install.adf'
- Workbench 3.1, Locale Disk (Cloanto Amiga Forever 2016) MD5 match 'test\workbench\amiga-os-310-locale.adf'
- Workbench 3.1, Storage Disk (Cloanto Amiga Forever 2016) MD5 match 'test\workbench\amiga-os-310-storage.adf'
- Workbench 3.1, Workbench Disk (Cloanto Amiga Forever 2016) MD5 match 'test\workbench\amiga-os-310-workbench.adf'
Done

Validating Kickstart dir 'test\kickstart'...
- 5 of 5 Kickstart rom files detected
- Kickstart 1.2, 33.180, A500 Rom (Cloanto Amiga Forever 7/2016) MD5 match 'test\kickstart\amiga-os-120.rom'
- Kickstart 1.3, 34.5, A500 Rom (Cloanto Amiga Forever 7/2016) MD5 match 'test\kickstart\amiga-os-130.rom'
- Kickstart 3.1, 40.068, A1200 Rom (Cloanto Amiga Forever 7/2016) MD5 match 'test\kickstart\amiga-os-310-a1200.rom'
- Kickstart 3.1, 40.068, A4000 Rom (Cloanto Amiga Forever 7/2016) MD5 match 'test\kickstart\amiga-os-310-a4000.rom'
- Kickstart 3.1, 40.063, A600 Rom (Cloanto Amiga Forever 7/2016) MD5 match 'test\kickstart\amiga-os-310-a600.rom'
- Kickstart 3.1, 40.068, A1200 Rom (Original) MD5 match 'test\kickstart\Kickstart ROM v3.1 (A1200 v40.63).rom'
- Kickstart 3.1, 40.063, A600 Rom (Original) MD5 match 'test\kickstart\Kickstart ROM v3.1 (A500,A600,A200 v40.63).rom'
Done

Validating OS39 dir 'test\os39'...
- 3 Amiga OS 3.9 files detected
- Amiga OS 3.9 iso MD5 match 'test\os39\amigaos3.9.iso'
- Boing Bag 1 for Amiga OS 3.9 MD5 match 'test\os39\BoingBag39-1.lha'
- Boing Bag 2 for Amiga OS 3.9 MD5 match 'test\os39\BoingBag39-2.lha'
Done

Validating User Packages dir 'test\userpackages'...
- 0 user packages detected
Done

Files for patching
------------------
Finding A1200 Kickstart 3.1 rom and Amiga OS 3.9 iso files for patching configuration files...
- Using A1200 Kickstart 3.1 rom file 'test\kickstart\amiga-os-310-a1200.rom'
- Using Amiga OS 3.9 iso file 'test\os39\amigaos3.9.iso'
Done

UAE configuration
-----------------
UAE install dir 'C:\Users\Public\Documents\Amiga Files\WinUAE\Configurations\'
Patching and installing UAE configuration files from 'test'...
- 'test\hstwb-installer.uae'
Done

FS-UAE configuration
--------------------
FS-UAE install dir 'C:\Users\hst\Documents\FS-UAE\Configurations'
Patching and installing FS-UAE configuration files from 'test'...
- 'test\hstwb-installer.fs-uae'
Done
cyberhead97 is offline  
Old 06 June 2018, 22:45   #178
RoC
Registered User
 
Join Date: May 2011
Location: Italy
Posts: 214
Quote:
Originally Posted by cyberhead97 View Post
This is fantastic roc.



I noticed Retroplay WHDLoads contains Magazines, so I had plans to add those in future packages for HstWB Installer. It's really great that you have Cracktros added as well.



I would like to have your script changes included in the repo and they could be added as a pull request with commit flow described here https://gist.github.com/Chaser324/ce0505fbed06b947d962.


...


Final tweaks are being done, so HstWB Installer v1.2.0-BETA5 can be released.



Glad you found it somehow useful!
I am out for vacation until the end of this week, so I am going to update the Github once I am back in a few days.

Good to hear about the beta5 new features: One question. In the beta 4 I noticed a HstWB option in the option screen: Does it work together with the BetterWB?
RoC is offline  
Old 06 June 2018, 23:38   #179
cyberhead97
Registered User
 
Join Date: Feb 2016
Location: Denmark
Posts: 333
Quote:
Originally Posted by roc View Post
Glad you found it somehow useful!
I am out for vacation until the end of this week, so I am going to update the Github once I am back in a few days.

Good to hear about the beta5 new features: One question. In the beta 4 I noticed a HstWB option in the option screen: Does it work together with the BetterWB?
Sounds good, let me know if you have any issues with github forking and pull requests.

HstWB is build upon BetterWB, so it requires that BetterWB is installed together with HstWB. Selecting HstWB package in self install or using HstWB Installer should automatically also select BetterWB.
cyberhead97 is offline  
Old 11 June 2018, 20:29   #180
RoC
Registered User
 
Join Date: May 2011
Location: Italy
Posts: 214
Quote:
Originally Posted by cyberhead97 View Post
Sounds good, let me know if you have any issues with github forking and pull requests.

HstWB is build upon BetterWB, so it requires that BetterWB is installed together with HstWB. Selecting HstWB package in self install or using HstWB Installer should automatically also select BetterWB.

I have just updoaded the files. In the readme you can find all the info


Good to know about the HstWB option, from now on I will be selecting it all the times.
RoC is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
HstWB Installer for Classic Amiga AMIGASYSTEM News 26 05 March 2021 17:31
Legal Issues if Sharing RP9 Snapshots? tygre Retrogaming General Discussion 17 18 September 2014 20:04
Making cf_ClassicWB_FULL.hdf bigger? emuola project.ClassicWB 3 06 June 2009 00:23
New ruling making retro-archives legal? Bloodwych Retrogaming General Discussion 3 24 November 2006 19:30

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 10:23.

Top

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Page generated in 0.69298 seconds with 14 queries