20 November 2017, 10:48 | #81 |
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 43
Posts: 9,861
|
|
20 November 2017, 13:59 | #82 |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 532
|
|
20 November 2017, 14:24 | #83 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,334
|
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.)
|
20 November 2017, 19:18 | #84 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 532
|
Quote:
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. |
|
21 November 2017, 06:30 | #85 | |
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 43
Posts: 9,861
|
Quote:
I always liked the theory that Apple told them to stop due to the similarity with the Mac System SW. :-) |
|
21 November 2017, 15:57 | #86 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,334
|
To illustrate the difference between the old and new title bar patterns I created an example image.
Code:
https://www.media!fire.com/file/puz3dag4m4wfdm3/Patterns.ilbm.lha You should notice that all parts with the "old" pattern flicker significantly more than areas of "new" pattern. Last edited by mark_k; 21 November 2017 at 18:02. |
23 November 2017, 17:17 | #87 |
Registered User
Join Date: Jul 2009
Location: UK
Posts: 112
|
@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. |
23 November 2017, 17:52 | #88 | ||
Registered User
Join Date: Dec 2007
Location: Szczecin/Poland
Posts: 424
|
Quote:
Quote:
|
||
24 November 2017, 11:32 | #89 | |
Registered User
Join Date: Jun 2012
Location: Worksop/UK
Age: 59
Posts: 1,328
|
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.
Quote:
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. |
|
24 November 2017, 11:38 | #90 | ||
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 532
|
Quote:
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... Quote:
|
||
24 November 2017, 11:51 | #91 | |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,334
|
Quote:
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. |
|
24 November 2017, 11:56 | #92 |
Registered User
Join Date: Jun 2012
Location: Worksop/UK
Age: 59
Posts: 1,328
|
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! |
24 November 2017, 17:59 | #93 |
Registered User
Join Date: Sep 2007
Location: Stockholm
Posts: 4,332
|
I use printer.device both for printing via Envoy and for printing labels with my old Panasonic 9-pin dot matrix.
|
05 January 2018, 00:30 | #94 |
Registered User
Join Date: Dec 2011
Location: Poland
Posts: 166
|
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. |
28 February 2018, 05:25 | #95 |
Banned
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 1,893
|
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.
|
11 April 2018, 03:50 | #96 |
Registered User
Join Date: Mar 2017
Location: Enterprise, AL / USA
Posts: 26
|
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? |
11 April 2018, 05:26 | #97 | |
BoingBagged
Join Date: Aug 2007
Location: The South of nowhere
Age: 46
Posts: 2,358
|
Quote:
Still bug testing and growing better every day. And this is a good thing because there is no pressure to release something prematurely. |
|
18 April 2018, 23:05 | #98 |
Banned
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 1,893
|
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
|
19 April 2018, 01:39 | #99 |
BoingBagged
Join Date: Aug 2007
Location: The South of nowhere
Age: 46
Posts: 2,358
|
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 |
19 April 2018, 19:15 | #100 |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,645
|
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! |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Available now: AmigaOS 3.1.4 | bubbob42 | Amiga scene | 1002 | 14 August 2021 23:22 |
Would AmigaOS 3.9 be ok for me? | stu232 | support.Hardware | 12 | 02 October 2013 18:20 |
AmigaOS 3.9 | PoLoMoTo | support.WinUAE | 8 | 27 August 2011 18:06 |
AmigaOS 3.5 or 3.9 | maddoc666 | support.Apps | 12 | 22 February 2010 08:02 |
AmigaOS XL | sturme | New to Emulation or Amiga scene | 4 | 15 January 2002 02:13 |
|
|