AmigaOS 3.1.4! [beta]

[Jope]

Originally Posted by Olaf Barthel

Anything prior to the Kickstart/Workbench 1.2 appears to be lost, including the rationale for the title bar decoration change.

Thanks for checking! :-)

I also asked RJ Mical about it years ago, but it happened after he had already left.

[Olaf Barthel]

Originally Posted by Jope

Thanks for checking! :-)

I also asked RJ Mical about it years ago, but it happened after he had already left.

So that probably means Jim Mackraz (jimm) might know why and when it happened.

[mark_k]

I'd bet the title bar pattern change followed the addition of support for interlaced Workbench screen in Kickstart/WB 1.2. The pre-1.2 pattern flickers really badly with the default Workbench colours. (The flickering is even worse on PAL machines, not sure whether that was a consideration.)

[Olaf Barthel]

Originally Posted by mark_k

I'd bet the title bar pattern change followed the addition of support for interlaced Workbench screen in Kickstart/WB 1.2. The pre-1.2 pattern flickers really badly with the default Workbench colours. (The flickering is even worse on PAL machines, not sure whether that was a consideration.)

This makes good sense to me. I am not sure about the effects of the flickering (back in the day, you sort of grudgingly had to accept that there were several trade-offs to be made when you wanted to use the higher vertical resolution) being the sole possible reason.

I suspect that the pattern introduced with Kickstart 1.2 ("thicker" stripes) yields better brightness contrast against the background colour than the Kickstart 1.1 pattern (50% detail pen, 50% background pen). In the original colour palette, the window titles are easily the brightest elements on the screen, and that can at times be a distraction.

Apple had it easier with the Macintosh, since all the user interface elements were essentially black ink "line art" on a paper-white background The Amiga default user interface colours had to work well even on a poor quality, low resolution NTSC television set.

[Jope]

Originally Posted by mark_k

I'd bet the title bar pattern change followed the addition of support for interlaced Workbench screen in Kickstart/WB 1.2. The pre-1.2 pattern flickers really badly with the default Workbench colours. (The flickering is even worse on PAL machines, not sure whether that was a consideration.)

This is a much better reason than the ones I came up with.

I always liked the theory that Apple told them to stop due to the similarity with the Mac System SW. :-)

[mark_k]

To illustrate the difference between the old and new title bar patterns I created an example image.

https://www.media!fire.com/file/puz3dag4m4wfdm3/Patterns.ilbm.lha

Also uploaded to The Zone. 320×400 1-plane, load into any image viewer (e.g. MultiView SCREEN). If using WinUAE, enable vsync and set interlaced line mode to "Double, fields+".

You should notice that all parts with the "old" pattern flicker significantly more than areas of "new" pattern.

[asymetrix]

@thread

hang on, before anyone gets too excited why not consider :

Replace ROM chip with a piggy back board that holds much larger ROM(s).

If anyone is going to dig around messing with single threaded workbench in ROM, you might as well get in and do it right.

Make workbench and others modular so we could handle multi threaded workbench, maybe from more that one cpu.

We could switch to many workbenches running apps on each core seperately.

AmigaOS rewritten in Clojure super clean data language would be a very powerful functional Operating System - aka BEAST.

[Romanujan]

Originally Posted by asymetrix

Replace ROM chip with a piggy back board that holds much larger ROM(s).

How exactly this can be done? What about address lines?

Originally Posted by asymetrix

If anyone is going to dig around messing with single threaded workbench in ROM, you might as well get in and do it right.

Make workbench and others modular so we could handle multi threaded workbench, maybe from more that one cpu.

We could switch to many workbenches running apps on each core seperately.

AmigaOS rewritten in Clojure super clean data language would be a very powerful functional Operating System - aka BEAST.

IMHO a terrible idea. I would prefer to play with the update before I get old and die...

[ptyerman]

Just been reading the thread over on amiga.org about this update and there is a comment by Thomas Richter that is worthy of a reply. However I don't have a account over there so will put it here by chance he reads it.

Originally Posted by Thomas Richter
he more relevant question is probably "will there be a printer.device". Quite frankly, which printers do you want to connect to the Amiga, and how? Parallel printers are hard to get, except in a museum, and printers you can get are most likely not supported by any printer driver we have. So what exactly do you plan to do?

At this time, I'm not sure whether I have an updated printer.device, but we most certainly do not have updated printer drivers, so this device is kind of pointless.

I along with others print over the network to a PCL or Postscript compatible printer, or to another computer before the printer. The printer.device is far from pointless and would be a tragic loss if removed, it would instantly cripple the Amiga's that are using this device!
It would be nice to have updated printer drivers but I know that's unlikely to happen, however Postscript and PCL printers continue to be useable and very handy to have available.

[Olaf Barthel]

Originally Posted by asymetrix

@thread

hang on, before anyone gets too excited why not consider :

Replace ROM chip with a piggy back board that holds much larger ROM(s).

If anyone is going to dig around messing with single threaded workbench in ROM, you might as well get in and do it right.

Make workbench and others modular so we could handle multi threaded workbench, maybe from more that one cpu.

We could switch to many workbenches running apps on each core seperately.

Workbench may be the part of the Amiga operating system which users interact with most often, but under the hood it's really just a very simple design "gone wrong" due to memory and ROM space constraints in 1985/1986. My theory is that the original Workbench design still took the limitations of the original 256 Kilobyte RAM Amiga into account.

Workbench neither needs multiple CPU cores to perform well, nor does it deserve them. The major operations Workbench performs involve disk I/O, user interaction and rendering, none of which needs or benefits much from more available CPU power. You can do this on well on a humble 7 MHz Amiga 500, provided the software design is written to accomplish exactly that, rather than to watch carefully how much memory is consumed.

One major limitation is found in how directory contents are read, and how icons are processed. This is the biggest problem to be solved, as it makes the Workbench appear to be much, much slower in operation than it has to be. Mind you, that very problem has existed for some 35 years now...

AmigaOS rewritten in Clojure super clean data language would be a very powerful functional Operating System - aka BEAST.

Actually, I would prefer Haskell instead. If you are going to aim high, why not aim even higher?

[Daedalus]

Originally Posted by ptyerman

I along with others print over the network to a PCL or Postscript compatible printer, or to another computer before the printer. The printer.device is far from pointless and would be a tragic loss if removed, it would instantly cripple the Amiga's that are using this device!
It would be nice to have updated printer drivers but I know that's unlikely to happen, however Postscript and PCL printers continue to be useable and very handy to have available.

There won't be anything to stop you using the existing version of printer.device and the various drivers if they meet your needs, or Turboprint for example. I think the main essence of his post is that it's not worth spending a lot of time on. If the current printer.device works well for you, what updates does it need?

Personally, I think it's a pain to use and needs a complete overhaul, not a couple of minor fixes. It's improved in OS4, but still lacks drivers for most modern printers so it's still very limited.

[ptyerman]

Yes I know that the current version could be used, obviously!
I was just putting the comment across that printer.device is far from pointless.
Just because it's useless to you doesn't mean it is for everyone. May as well say let's all just throw our Amiga gear in the dustbin because it's outdated and pointless!

[idrougge]

I use printer.device both for printing via Envoy and for printing labels with my old Panasonic 9-pin dot matrix.

[tom256]

I have one request if possible for scsi.device:

Please implement SET MULTIPLE MODE detection. This function set maximum number of sector which can be transferred per interrupt on read/write mutiple.
scsi.device could read maximum supported value from drive and set it.

By deafult it's set to 16, but when drive can support bigger values and these values are set it will speed up read/write around 20%. In my case with old 2GB Caviar disk and A4000 build in interface.

If I understand correctly value can be read in WORD 47 and set in WORD59, so implementation should be simple.

Documentation:
ANSI ATA-5 2000.pdf page:89/90.

[kolla]

Originally Posted by Olaf Barthel

In any case, the updated "Info" command no longer has such a pronounced negative attitude towards volumes larger than 2 Gigabytes

How about adding LFORMAT option to C:Info? There are times when one want to get specific info about a device or volume for scripting, and that has been very hard - even something as simple as getting a volume name from a device is tricky.

[wmaciv]

C'mon, this is the most interesting thing for the Amiga in the last 10 years and it needs more discussion!

The suspense is killing me: When?

[gulliver]

Originally Posted by wmaciv

C'mon, this is the most interesting thing for the Amiga in the last 10 years and it needs more discussion!

The suspense is killing me: When?

There is no when yet.

Still bug testing and growing better every day.

And this is a good thing because there is no pressure to release something prematurely.

[kolla]

Can't wait to see the release of 3.1.4.1.5.9.2.6.5.3, maybe they will get there faster than TeX, the race is on

[gulliver]

Be patient, we are all bug hunting and keeping devs away from any kind of social life

But you are spot on the version number

[Amiga1992]

This is genuinely the most awaited "official" thing for me in like 15 years.
Can't wait to get a new 3.x branch AOS!