Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: The Os 3.1.4 Thread  (Read 132646 times)

0 Members and 1 Guest are viewing this topic.

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #300 on: December 25, 2018, 04:09:13 PM »
Yeah but I DID repartition with the tools provided with the new OS..  (Hence my question)
Strange....
Note that "HDToolBox" keeps a database of disks. You can always "add new drive type" and there trigger a re-scan of the harddisk, then use this as basis for new partitions. Otherwise, HDToolBox will use whatever it saved the last time it recognized the drive.
 
The following users thanked this post: Tygre

Offline giZmo350

Re: The Os 3.1.4 Thread
« Reply #301 on: December 25, 2018, 04:16:21 PM »
Note that "HDToolBox" keeps a database of disks. You can always "add new drive type" and there trigger a re-scan of the harddisk, then use this as basis for new partitions. Otherwise, HDToolBox will use whatever it saved the last time it recognized the drive.

Huh, I never knew that. Is that something new? Good to know. Thx!
« Last Edit: December 25, 2018, 04:18:26 PM by giZmo350 »
A500: 2MB Chip, 8MB Fast, IndiECS, MiniMegi, IDE4ZorroII on Z-500, KS1.3/KS3.1, WB3.1&BWB
 
A2000HD: 2MB Chip, 128MB Fast, P5:Blizz 2060@50MHz, PCD-50B/4GBCF, XSurf100, RapidRoad, IndiECS, Matze RTG, MiniMegi, CD-RW, SunRize AD516, WB3.9
 
A1200: 2MB Chip, 64MB Fast, 4GBCF, GVP Typhoon 030 @40MHz w/FPU, Subway USB, EasyNet Ethernet, Indi AGA MKI, FastATA MK-IV, Internal Slim CD/DVD-RW, WB3.5

Surfing The Web With AMIGA Is Fun Again!
 

Offline olsen

Re: The Os 3.1.4 Thread
« Reply #302 on: December 26, 2018, 02:06:36 PM »
Note that "HDToolBox" keeps a database of disks. You can always "add new drive type" and there trigger a re-scan of the harddisk, then use this as basis for new partitions. Otherwise, HDToolBox will use whatever it saved the last time it recognized the drive.

Huh, I never knew that. Is that something new?

No, this is a very old feature which goes back to the days of the A590 which shipped with 3.5" XT drives (ST 506 interface, ~20 MB per drive), but would also accept a SCSI drive.

The problem which the database solved was that the XT drives did not necessarily report their respective model and properties correctly when prodded. Commodore shipped a database of known-working drive types and their properties with the HDToolBox program, with the option for the user to add more drive types by entering the respective configuration data manually. For example, if you flipped over the A590 case, you would see a label describing the type, manufacturer and model, along with the number of cylinders/sectors/tracks/heads. If you ever lost the database, or corrupted it by accident, you could at least set up your drive correctly by following the label data. The usual approach would be to pick a database entry which matched the model and manufacturer information.

The problem with hard disk drives not producing reliable information about their respective configuration persisted for a very long time indeed, right until into the mid-1990'ies before the great mergers/acquisitions of hard drive manufacturers left us with only a handful of companies (Seagate, Western Digital, Fujitsu, Toshiba).

There is some extraordinarily complex code in HDToolBox which tries almost every trick that might work for XT and SCSI drives of that age to figure out the configuration parameters. To those unfamiliar with its purpose the code is perplexing and outright impenetrable. When we updated HDToolBox for the 3.1.4 update, we asked around for help and received kind advice from Ralph Babel and Joanne Dow. When Joanne kindly showed us how the RDPrepX tool approached the same problem as the mystifying HDToolBox configuration code, the penny finally dropped and the pennies just kept dropping. This kind of code is supposed to be as complicated/peculiar as it appeared :o

Long story short: the database in HDToolBox and the arcane configuration parameter heuristics have no place in a (somewhat) modern hard disk setup program. But for the time being we will be stuck with it :(
« Last Edit: December 26, 2018, 02:34:11 PM by olsen »
 
The following users thanked this post: Tygre

Online TribbleSmasher

Re: The Os 3.1.4 Thread
« Reply #303 on: December 26, 2018, 02:49:26 PM »
The problem with this 'drive definitions' database is that sometimes the installdisk where the hdtoolbox is on is rather full and the user gets weird error messages about 'disk full' when reading new drives with it.
 

Offline wmaciv

Re: The Os 3.1.4 Thread
« Reply #304 on: December 27, 2018, 02:46:09 PM »
Ok, waiting for another copy of the 3.1.4 ROM, but the "crashing" seems to involve any command invoked form the "C" directory once the Data Cache on the 060 is enabled.  Assign, Ed, CPU, etc., all generate an immediate crash.  Why only the C directory commands?  Is this REALLY because the ROM chip is too "slow"?  I though after installing MuLibs and remapping KS to RAM, all calls were placed against the re-mapped copy in RAM anyway?  Still does not explain why the exact same hardware setup worked fine with 3.1 and the current MuLibs distribution; nothing else changed. 
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #305 on: December 27, 2018, 11:11:13 PM »
Ok, waiting for another copy of the 3.1.4 ROM, but the "crashing" seems to involve any command invoked form the "C" directory once the Data Cache on the 060 is enabled.  Assign, Ed, CPU, etc., all generate an immediate crash.
There is nothing particular about Ed, CPU or Assign that would prevent them from functioning on a 68060. In fact, I do have a 68060 myself, with a Blizzard 2060, and everything works just fine. If things crash with otherwise "known to be stable commands", then this is an indicator of some hardware defect and not a software failure.

Why only the C directory commands?
I'm sure everything else will also crash, sooner or later, unless you also have a bad disk, or the disk with the 3.1.4 copy you received was bad. As stated, all these commands have been tested fine - if enabling CPU caches makes the system unstable, something is bad with the communications to RAM or ROM.

Enabling caches enables another, faster Bus protocol known as "bursting". If the timing does not fit, this will make the system unstable.


Still does not explain why the exact same hardware setup worked fine with 3.1 and the current MuLibs distribution; nothing else changed.
Yes, the ROM changed, and you touched the machine. It is also possible that the chips received some static and you fried them. If turning caches on or off makes a difference, then this is not a software failure. It is some freaky hardware that is involved.
 

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #306 on: December 28, 2018, 06:19:19 AM »
@wmaciv

You need to isolate the problem...

Does it only happen with 3.1.4 programs on 3.1.4 kickstart, or also with 3.1 programs on 3.1.4 kickstart and/or 3.1.4 programs on 3.1 kickstart?

You write "lock up and guru" - so what is the guru? Same every time?
« Last Edit: December 28, 2018, 06:54:54 AM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline wmaciv

Re: The Os 3.1.4 Thread
« Reply #307 on: December 28, 2018, 02:48:07 PM »
Understand about the isolating the problem (which is ongoing).  Really do not want to go back to 3.1 with patched exec. Absolutely ove MuLibs and think Thomas probably ought to charge for it :).  The hardware I am using is definitely in the realm of "edgy", as it is the GVP G-Force A2000-040 with 060 adapter running at 75MHz.  It was rock stable in last config (3.1 / MuLibs), so will continue to fight the good fight and see if a I can make it work with 3.1.4 / MuLibs. 

I am close to starting the Zeus 040 along the same path, just waiting for the updated device driver ROMs to arrive.  I want to see if I can get 3.1.4 working well with an 060 adapter on the Zeus.  Had one on the card temporarily running at 70MHz under 3.1 with MuLibs a while back, but wanted to wait until I could get the repaired 53C710 device driver before really going full bore.  At least with the Zeus, I have the option of mapping a little bit of the onboard RAM to the ZII address space at boot. 
 

Offline duga

Re: The Os 3.1.4 Thread
« Reply #308 on: December 28, 2018, 02:49:48 PM »
Ok, waiting for another copy of the 3.1.4 ROM, but the "crashing" seems to involve any command invoked form the "C" directory once the Data Cache on the 060 is enabled.  Assign, Ed, CPU, etc., all generate an immediate crash.  Why only the C directory commands?  Is this REALLY because the ROM chip is too "slow"?  I though after installing MuLibs and remapping KS to RAM, all calls were placed against the re-mapped copy in RAM anyway?  Still does not explain why the exact same hardware setup worked fine with 3.1 and the current MuLibs distribution; nothing else changed.

Which speed does your ROM have?
 

Offline wmaciv

Re: The Os 3.1.4 Thread
« Reply #309 on: December 28, 2018, 02:58:38 PM »
You know, the one I have now came from the sordan.ie fellas advertising on Amibay.  The ROM is the produced is completely covered by the registration/serial number sticker and I am loath to peel it back to see.  The patched exec 3.1 I was recently using was 120ns AMD.  I am supposed to be receiving my second kit of ROM+disks today from Amiga on the Lake and will see what shows up.
 

Offline wmaciv

Re: The Os 3.1.4 Thread
« Reply #310 on: December 29, 2018, 01:39:27 AM »
Both the new ROM's (3.1.4) and the original 3.1 patched exec ROM are 150ns.  No explanation there...
 

Offline dschallock

Re: The Os 3.1.4 Thread
« Reply #311 on: December 29, 2018, 09:53:34 PM »
Hi,
First a huge thanks to Thom and the team for making this upgrade.  Truly Amazing!

I think these questions may be very simple and perhaps already covered but I have been looking and I'm sorry I couldn't find the information I need so I will ask anyway:

1) I just received my 3.1.4 disks and Roms from AOTL (thanks guys)... I currently have 3.1 roms and OS installed, Can I/should I upgrade 3.1 to 3.1.4 or do I need to do a fresh install?

2) If I can upgrade, do I swap the roms first and then do the software upgrade?

3) I have a particular version of my 040 and 060 library installed in order to make my Cyberstorm accelerator work, Should I take precautions to copy those immediately over the new install to maintain functionality of that accelerator's 060?

Thanks ahead of time for anyone responding and helping me answer these questions!
-Dan
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #312 on: December 29, 2018, 09:59:40 PM »
1) I just received my 3.1.4 disks and Roms from AOTL (thanks guys)... I currently have 3.1 roms and OS installed, Can I/should I upgrade 3.1 to 3.1.4 or do I need to do a fresh install?
The install script on the Install disk makes a fresh install. Unless you know what you are doing, this is the recommended (and supported) way. If you know your system well, you can also install manually.

2) If I can upgrade, do I swap the roms first and then do the software upgrade?
If you bought the ROM version, please install the ROM first. Otherwise, the installer script will ask you for the Modules disk which include the modules that are in ROM. Since they are not included in the set, installation would then fail.


3) I have a particular version of my 040 and 060 library installed in order to make my Cyberstorm accelerator work, Should I take precautions to copy those immediately over the new install to maintain functionality of that accelerator's 060?
The installer script does not overwrite or replace them. It just warns you that they need to be present, and the default startup-sequence checks whether they are present. There is no CPU library included in the distribution.
 

Offline dschallock

Re: The Os 3.1.4 Thread
« Reply #313 on: December 29, 2018, 11:07:36 PM »
Thanks Thomas for the reply!

So, Install Rom first.  Then install from disk.  It will do a fresh install (over the top of my 3.1 if I point it to that partition) and if that partition already has a libs directory with 040 and 060 libraries on it they would not be over written or erased.  Does that sound correct?

I don't have alot of hacks installed on the system but I do have toolsDaemon installed I think... Should I disable that before letting the install happen?

Thanks,

Dan
 

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #314 on: December 30, 2018, 01:19:32 AM »
You should update ToolsDaemon, and it will work fine with new workbench.library
http://aminet.net/package/util/boot/ToolsDaemon22
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS