Available now: AmigaOS 3.1.4

[supercompman]

The first place I started was the FAQ. None of the scenarios described apply to my situation.

This is my complete hardware configuration:
NTSC Amiga 500 with full ECS chipset and 2 MB chip RAM
68010 @7.16MHz
Kipper2k 8MB CF expansion using an 8GB CF (PFS3 as the file system)
Indivision ECS
A500Flash Kickstart Switcher 1MB, currently using KS 3.1, but will be flashing KS 3.1.4
Plipbox

I have also used a 512 MB CF card formatted with FFS for testing as well. Using a completely clean install of 3.1.4.1 (using the icon.library that comes with 3.1.4.1), and a freshly quick formatted drive with nothing additional installed other than FinalWriter 97, I can reproduce the slow application startup behavior. Starting FinalWriter from the shell or from a script starts the application in the same amount of time OS 3.1 would. I have also tried with a flashed KS 3.1.4 ROM with the same result.

[gulliver]

@supercompman

The A500 was tested with 3.1.4 and no issue like the one you describe has ever surfaced both in the beta testing phase and after its release. Granted no one I saw was using a 68010 with it.

Anyway, have you tested your PSU? I see you have a heavily expanded A500, and most of the times these intermitent and odd behaviours are related to an unstable 5 volt rail under heavy load. Also what is the state of your motherboard caps?

Anyway, just for the sake of testing, if you have it at hand, replace the 68010 for a 68000, to discard any potential incompatibility issue there (which I doubt is the case, but you can never know for sure untill you try).

[supercompman]

I'm using an Amiga 500 PSU from c64psu.com. It's only a few months old. It seems to work great, but I suppose it's worth testing. I recapped the motherboard about 6 months ago and it's all seems fine. I'll certainly give the 68000 a shot when I have some time. Thanks @gulliver

[PeterK]

Originally Posted by supercompman

Also, probably not directly related, when using IconLib_46.4 from aminet, TurboText 2.0 crashes and reboots the whole system. Launching TurboText from the command line works fine. Using the icon.library included with 3.1.4.1 launches TurboText just fine (albeit slowly) from Workbench.

Any thoughts as to what is going on here would greatly be appreciated. I'm very curious if anyone else has noticed these things.

Increase the stacksize in your TurboText icon from 2000 to 4096 (or higher) and it should work with IconLib_46.4 too.

[supercompman]

Thanks @PeterK! Haven't had time to do any Amiga stuff for a bit now (like everyone else here, real life gets in the way) but I'll try it out when I have time.

[supercompman]

@PeterK That worked like a charm. TurboText is working great even with IconLib_46.4

@gulliver I tested my power supply and it looks just fine. I also tested a plain old 68000 and it performed identical to the 68010.

I used a different CF card and did a completely clean install of OS 3.1.4.1 and a clean install of FinalWriter 97. KS 3.1.4 is flashed to ROM. Here's a video of my results (still exactly the same as I previously described):

[ Show youtube player ]

Maybe this is all performing as expected, but I was surprised that it took so much longer to load an application by double-clicking the icon from Workbench than launching it from CLI or launching it from OS 3.1. Other large applications also take substantially longer to load, it's not just FW.

[gulliver]

@supercompman

Thank you for the video.

From it we get:

FinalWriter97 running from CLI takes 9 seconds.
FinalWriter97 running from Workbench takes 24 seconds.

It does not seem normal to me to have such a big difference. It should
be really much smaller.

Could you please time it again running it from Workbench under the
exact same conditions, but this time remove all the tooltypes from the
FW97 icon first. Just to discard anything weird related to the
tooltype's operation and have a plain level field to compare?

BTW, is anyone over here experiencing such a big difference between
the CLI and Workbench when running a program both ways on 3.1.4.1?

[supercompman]

@gulliver I removed everything from the tool types and ended up with the exact same result.

[gulliver]

Thanks again.

I will fill a bug report for this, and report back when I get some answers.

[supercompman]

@gulliver Thanks for taking a look at this.

[Thomas Richter]

Got this one, thanks for reporting. The culprit here was the implementation of the Boyer-Moore search algorithm in the workbench. Which was nice from an implementation point of view, but not fast. I replaced this by the implementation of the shell (which was designed with speed in mind), and things went back to normal. This is the algorithm that looks for the stack cookie and extends the stack automatically if requested. Thanks for reporting.

[supercompman]

@Thomas Richter Thanks for getting this squared away so quickly.

[Thomas Richter]

Originally Posted by AC/DC HACKER!

No way, man. Once was it. Hahaha! I'm glad I ditched embarrassment many years ago.

Thanks, I now looked into it. Say, is this the HDToolBox from 3.1.4 or 3.1.4.1? The former had a couple of legacy issues for "oddball" drives that do not support mode pages.

Is it right that you go to "add new drive type", then "read configuration", and then you see the strange config popping up? I tried to simulate this as best as I can with the drives I have, but results are consistent with drive capacity.

Could you report how the configuration looks like exactly? (sectors,heads,cylinders etc...)

Also, could you please try the following: Run Sashimi, then run HDToolBox up to the point where you would press "Read configuration", then start "SCSISnoop" (also on Aminet), run that on the device/unit this drive is attached to, and then press "ReadConfiguration"?.

The SCSISNoop output will appear in the Sashimi window, this is what I would need next.

Sorry for the back and forth.

[AC/DC HACKER!]

I had to start with 3.1.4 because I haven't created a new floppy from the disks I bought. I still haven't done that yet. So, yup, 3.1.4's and then 3.1.4.1's HDToolBox. HDToolBox 3.1.4 doesn't read it correctly whereas 3.1.4.1 does..at least more accurately. I noticed it when I was helping someone else and decided to find a word-around. Yep, I found the problems for oddballs. HA HA!

In another version of HDToolBox I didn't have click "Read configuration" but then for many years I haven't used the HDToolBox that comes stock. I'll share some images first, and if then in a bit I'll locate those programs.

1) HDToolBox from Installer3.1.4 run from RAM. Showing first info.
2) CF Specs.
3) Same, but Clicked "Read configuration".
4) From 3.1.4.1 update, and small additions, like showing P96 running stock. That the HDToolBox.
5) Is after "Read Config.."
6) For fun, added cover of CF...maybe you'll want to locate one?

Productive back and forth is okay and fun. Drama back and forth is not. Haaa!

Edit: Added Sashimi info.

[Thomas Richter]

Thanks - I found at least one of the problems, but I wouldn't claim that the problem is solved. Part of the problem is that there are two protocols how to discover the capacity of a SCSI drive (or how to use the SCSI protocol to read the capacity of a drive). One is READ_CAPACITY, and the other uses MODE_SENSE which provides (ideally) some more details on the number of heads and cylinders - at least for mechanical drives. Unfortunately, the SD card you have there returns results that are inconsistent between the two protocols, so HDToolBox is confused. I'm trying to create some sort of workaround, but I'm not sure how successful this may be.

[AC/DC HACKER!]

Sure.

Which is why, with the CompactFlash, I figured a decent work-around for now is make a small partition vs anything larger or more for the 32GB and get a bootable "drive" and once 3.1.4.1 is copied and running then do it again where it's read correctly..then reinstall. I was also thinking this is a difference between mechanical and digital...but I considered that after sharing the above info.

[asymetrix]

I really like appreciate the hard work put into this.
What would be a nice feature to have would be if the OS could handle overlays on icons.

Maybe with a separate PNG icon image layer, with rows of fixed sized tiles.


So if I am reading a PDF and set save progress the icon on the pdf, this could reveal /overlay a small image over the icon with a 'read mark' to show it being read and also optional chapter logo - reading with a 3 to show currently reading chapter 3.

once read is completed, one could set as finished reading and the icon would overlay a tick over the icon to show it has been read.

I think it could be very user friendly, beautiful and very useful to a lot of people.

Later it could be used to add flash effect animation with a set reminder script.

[darkwave]

Am I right in thinking that the Workbench disks for this are identical for each hardware version, the only difference being the specific "Modules" disk?

[gulliver]

Originally Posted by darkwave

Am I right in thinking that the Workbench disks for this are identical for each hardware version, the only difference being the specific "Modules" disk?

Yes, you are correct.

[AC/DC HACKER!]

You're correct. Oops..Gulliver beat me.