Click Here
home features news forums classifieds faqs links search
6061 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
73 crawler(s) on-line.
 24 guest(s) on-line.
 2 member(s) on-line.


 eliyahu,  Srtest

You are an anonymous user.
Register Now!
 eliyahu:  1 min ago
 Srtest:  3 mins ago
 NutsAboutAmiga:  7 mins ago
 Amigamia:  12 mins ago
 BigD:  23 mins ago
 ppcamiga1:  27 mins ago
 kolla:  35 mins ago
 Trixie:  37 mins ago
 vulture:  50 mins ago
 Jasper:  1 hr 3 mins ago

/  Forum Index
   /  Amiga General Chat
      /  Amiga OS versions and what makes them different/better
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 )
PosterThread
matthey 
Re: Amiga OS versions and what makes them different/better
Posted on 18-Nov-2021 2:53:54
#81 ]
Super Member
Joined: 14-Mar-2007
Posts: 1213
From: Kansas

kolla Quote:

Let's do the common thing these days and lean on wikipedia...

https://en.wikipedia.org/wiki/16-bit_computing

"The Motorola 68000 is sometimes called 16-bit because of the way it handled basic mathematics. The instruction set was based on 32-bit numbers and the internal registers were 32 bits wide, so by common definitions, the 68000 is a 32-bit design. Internally, basic 32-bit arithmetic is performed using two 16-bit operations, and this leads to some descriptions of the system as 16-bit, or "16/32"."


By 32 bit design, they mean 32 bit ISA design. I can agree with that. The core design is still 16 bit.

Are pictures easier?





Don't you think Sega would have liked to print 32 bit instead of 16 bit on their 68000 console? Do we understand why CBM could print 32 bit on the Amiga CD32 with a 68EC020?

There are trickier CPU examples. The Pentium Pro has integer 32 bit ALUs, integer 32 bit registers, integer 32 bit datatype sizes, 36 bit address bus and 64 bit data bus. Does it have a 32 bit ALU and 32 bit data bus? No. It is a 32 bit CPU.

 Status: Offline
Profile     Report this post  
kolla 
Re: Amiga OS versions and what makes them different/better
Posted on 18-Nov-2021 4:01:17
#82 ]
Super Member
Joined: 20-Aug-2003
Posts: 1862
From: Trondheim, Norway

@matthey

"The appearance of the Mega Drive was designed by a team led by Mitsushige Shiraiwa that drew inspiration from audiophile equipment and automobiles. Shiraiwa said this more mature look helped to target the Mega Drive to all ages, unlike the Famicom, which was aimed primarily at children. According to Sato, the Japanese design for the Mega Drive was based on the appearance of an audio player, with "16-bit" embossed in a golden metallic veneer to create an impression of power"

It wasn't about CPU, it was about being able to play audio CDs, 16-bit audio.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

 Status: Offline
Profile     Report this post  
ppcamiga1 
Re: Amiga OS versions and what makes them different/better
Posted on 18-Nov-2021 7:28:52
#83 ]
Regular Member
Joined: 23-Aug-2015
Posts: 357
From: Unknown

@matthey

386SX has 16 bit external bus but nobody say it is 16 bit cpu.
68000 is the same.

 Status: Offline
Profile     Report this post  
Chris_Y 
Re: Amiga OS versions and what makes them different/better
Posted on 18-Nov-2021 12:04:05
#84 ]
Elite Member
Joined: 21-Jun-2003
Posts: 3176
From: Beds, UK

@Hypex

Quote:
I find it doesn't. Like on Linux, I find newer -lha5- LhA files break in Unarc. Never found a fix. This is because I'm using LhA which is newer on OS4. Though I'm sure the sources are old so don't know why a 68k fix wasn't made.


It needs a build of xadmaster v13 (most recent sources with the fixed LhA module). It shouldn't really be a problem for somebody to build with the correct compiler, but nobody has bothered.

Quote:
And I recently found out that OS4 classic has the same problem so it's worse than I thought.


Probably it's a build with the broken LhA module.Try this one

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

 Status: Offline
Profile     Report this post  
Chris_Y 
Re: Amiga OS versions and what makes them different/better
Posted on 18-Nov-2021 12:06:29
#85 ]
Elite Member
Joined: 21-Jun-2003
Posts: 3176
From: Beds, UK

@olsen

Quote:
Thank you! I was concerned that the situation had become worse while we were working on the current NDK 3.2 iteration.


No, haven't even had chance to look at it since then!

Thanks for your work on this, look forward to the updated version.

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

 Status: Offline
Profile     Report this post  
olsen 
Re: Amiga OS versions and what makes them different/better
Posted on 18-Nov-2021 12:22:30
#86 ]
Cult Member
Joined: 15-Aug-2004
Posts: 749
From: Germany

@kolla

Quote:

kolla wrote:
@olsen

Quote:

And here’s an old bug still present in 3.2…

https://youtu.be/L-TNqcvFnSE


Thank you!

That's two issues, isn't it? Firstly, the two windows completely overlap. This is exactly how it should not be done.


If you say so... this is so common on Amiga that it didn't occure to me to be a bug in itself.
[/quote]

It's not supposed to work like that. Windows should not overlap, they should be staggered so as not to obscure the title bars.

Quote:

Quote:
Secondly, the option to format the second volume is denied without giving any reason or hint. Is the second volume really a writable fixed disk or something else?


These are just two (or more) "NDOS" partitions, on the same disk. I select both, go to "format", the two windows pop up, both have "quick format" enabled, I click "quick fomat" on either of them, and the "quick format" in the remaining window becomes denied (greyed out), leaving only "format" and "cancel" (and here it then easy to accidently select "format"). If the partitions are not NDOS, but for example already formatted, this doesn't happen (which is a hint, I think).


I checked the code and this appears to be a side-effect of a test intended to detect unformatted floppy disks. It should not occur for mass storage devices such as you used

 Status: Offline
Profile     Report this post  
olsen 
Re: Amiga OS versions and what makes them different/better
Posted on 18-Nov-2021 13:05:14
#87 ]
Cult Member
Joined: 15-Aug-2004
Posts: 749
From: Germany

@matthey

Quote:

matthey wrote:
olsen Quote:

Thank you! I was concerned that the situation had become worse while we were working on the current NDK 3.2 iteration.

So far we've touched the following areas:

...


That is an impressive accomplishment for a few days, even if some of it was already in the works.


A few days? It felt like a short eternity here

Seriously, you know you're onto something if you start trying to document why one underdocumented function has such weird effects, side-effects and uses no less weird combinations of parameters that in order to explain better in context why it's like that you have to first document 3 other functions which in turn require research into 2 more (if you're lucky).

Quote:

It's good to see AmigaOS emphasis on development and support. The Amiga launch in 1985 was hampered by a lack of development documentation and support resulting in a slow Amiga start. Now all we need is for the legal problems to come together so the wheel doesn't have to keep being invented.

olsen Quote:

If you have read this far: no idea yet when we will be ready to ship the next NDK 3.2 iteration, but it could be this year. Criticism and encouragement for trying to do the right thing are, as always, welcome. The Amiga developer documentation certainly shines in many areas, but there are still too many dark and uncared for portions which badly need work, always have...


I understand that it is a work in progress type of situation. Do developers like Chris have to wait two more weeks for the next major release of the NDK or was he given access to a beta version to use for testing? Are there beta testers for the NDK?


Chris had access to the regular NDK 3.2, just like everybody else, I'm afraid.

We had decided early on that cross compilers needed better NDK support than was currently available. Much of what vbcc and also Stefan Franke's gcc cross compiler had to put up with were figuratively speaking hand-me-downs from the 1994 GeekGadgets gcc release (header files and libraries). Boy, these header files had issues, but at least the licensing situation was clearer than for the NDK 3.9 and beyond (never mind that the licensing terms still involved the decades long defunct Commodore-Amiga, Inc., so this is essentially still a mess).

But with poor header files you'll have your hands full in making them work correctly, and that's certainly not making your life easier as an Amiga developer using 'C'. Even at the best of times this was a harsh and unforgiving environment which meted out swift punishment if you made even the slightest mistake. And if you can't tell the compiler critiquing the state of the header files contents with regard to types and data structures from justified warnings concerning your own code you're setting yourself up for a long, frustrating afternoon of finding out which is which.

As of now we have no dedicated 3rd party NDK testing in place. We try to get by with building our own code with the current header files to find anything strange, but it's a long development cycle. We first needed to provide for better gcc and vbcc support before we could even share it with the compiler maintainers (these being Frank Wille and Stefan Franke) for feedback.

Feedback for what has been accomplished so far will definitely be needed. Commodore used to have a support department which took care of preparing documentation and the essential tools. We're a tiny army trying to do more with much less...

Quote:

olsen Quote:

For these target system it probably matters very little in terms of performance whether the benefits of the 68020 and beyond are used to any degree. Sure, there will be a difference if we wind up with more code to execute to achieve the same results, but the target machines not being 7 MHz 68000 you might have a hard time even measuring the difference between 68020 code and equivalent but more elaborate, strained 68000 code.


Generally true. Most of the AmigaOS code is designed to have acceptable performance on a 68000 so is minimal and light weight. A 68040 or 68060 is often enough faster than a 68000 that even code which runs at half performance is barely noticeable, with a few exceptions. A 68020@14MHz system is more likely to have a noticeable difference in performance being compiled for a 68020.

The 68000 code on a 68020 CPU is still cringe worthy. Why do 2 dips into memory instead of 1? Why do a 16 bit branch to a branch trampoline which branches to the destination instead of doing a 32 bit branch? Why use multiple instructions to recalculate scale factors when they can be done in a single instruction for free? Why branch to a multiply function when an inline multiply is fewer cycles than the BSR+RTS? Why fill up small instruction caches with more superfluous instructions?

SAS/C is not that good at 68k optimizing either. I can usually hand assembler optimize for performance and still reduce the size of most libraries by at least 10% while significantly reducing stack usage. The following is a real example in AmigaOS using SAS/C code of two consecutive instructions from layers.library.

lea (0,a6),a4 ; should be move.l a6,a4
move.l #0,-(sp) ; should be clr.l -(sp)

This code sequence is 10 bytes instead of 4 bytes and poor code quality like this isn't rare. You aren't going to notice a difference in performance on most Amigas either but these inefficiencies add up. Now we have a compiler that isn't very good at optimizing and it is optimizing for a CPU which is a significantly different processor. It becomes obvious that the AmigaOS isn't nearly as fast or small as it could be, especially on a 68020+. Fixing SAS/C, switching to a different better optimizing compiler and/or adding assembler optimizations is not as easy as flipping a compiler switch to compile for a 68020.



What matters most is that SAS/C is the best integrated compiler for the target platform, hands down. No parameter passing on the stack by default, as it used to be back in 1985/1986, fine control over the register assignment for function parameters, no contortions for calling operating system functions through inline macros, etc., decent support for the 68k family up to and including the 68060 and no easily observed catastrophic code generation bugs (keeping my fingers crossed). This compiler was specifically made to build the Amiga operating system itself.

We are stuck with it until something much better comes along.

Frankly, I don't share your concerns regarding the shortcomings of the code generation. This is not the kind of compiler which would have produced better code in 1993/1994. We were lucky to have it back then, but it was far away from what other commercial 'C' compilers would be capable of by the end of the decade.

I'm old school when it comes to optimization (almost "Old Testament" if you will ). You build, then you measure, then you adapt your data structures and how your code works with them. If necessary, find the spot which would benefit from hand-tuned optimizations, even resorting to straight assembly language. All other things being equal, I favour being lazy rather than to chase possible gains in areas of the code which don't deserve such scrutiny. The compiler's work is, metaphorically speaking, just another day at the office: work is delegated and you have very little control over the results anyway. Not every translation from 'C' to assembly language code has to be a shining model of efficiency that deserves praise or a pat on the shoulder

 Status: Offline
Profile     Report this post  
Rob 
Re: Amiga OS versions and what makes them different/better
Posted on 18-Nov-2021 19:13:41
#88 ]
Elite Member
Joined: 20-Mar-2003
Posts: 6077
From: S.Wales

@kolla

Quote:
It wasn't about CPU, it was about being able to play audio CDs, 16-bit audio.


Are you still talking about the Mega Drive here or something else?

 Status: Offline
Profile     Report this post  
BigD 
Re: Amiga OS versions and what makes them different/better
Posted on 18-Nov-2021 20:24:12
#89 ]
Elite Member
Joined: 11-Aug-2005
Posts: 5941
From: UK

@Rob

Obviously the MegaDrive didn't play CDs! Quite a confusing comment from kolla admittedly.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

 Status: Offline
Profile     Report this post  
bison 
Re: Amiga OS versions and what makes them different/better
Posted on 18-Nov-2021 21:22:10
#90 ]
Super Member
Joined: 18-Dec-2007
Posts: 1906
From: N-Space

@Hypex

Quote:
DiskDoctor is an alliteration

Speaking of, I think this thread should be renamed Bus Width Wars.

_________________
"Unix is supposed to fix that." -- Jay Miner

 Status: Offline
Profile     Report this post  
BigD 
Re: Amiga OS versions and what makes them different/better
Posted on 18-Nov-2021 22:54:58
#91 ]
Elite Member
Joined: 11-Aug-2005
Posts: 5941
From: UK

@bison

The Amiga was good but the CPUs chosen for the low end machines always hampered Fast Ram memory expansion. Accelerators were required to overcome these short sighted design choices! The A1200 was crippled without Fast Ram and the 68k was an absolute joke by the time the A600 appeared and still is.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

 Status: Offline
Profile     Report this post  
matthey 
Re: Amiga OS versions and what makes them different/better
Posted on 19-Nov-2021 6:44:21
#92 ]
Super Member
Joined: 14-Mar-2007
Posts: 1213
From: Kansas

@BigD

1979 68000 4-16.67MHz .169 DMIPS/MHz
1984 68020 12.5-33MHz .297 DMIPS/MHz
1985 68000@7MHz Amiga 1000
1987 68000@7MHz Amiga 500
1987 68000@7MHz Amiga 2000
1987 68030 16-50MHz .358 DMIPS/MHz
1988 68020@20MHz Amiga 2500/20
1989 68030@25MHz Amiga 2500/30
1990 68030@25MHz Amiga 3000
1990 68040 25-40MHz 1.10 DMIPS/MHz
1991 68000@7MHz Amiga 500+
1991 68000@7MHz CDTV
1991 68030@25MHz Amiga 3000T
1992 68000@7MHz Amiga 600
1992 68EC020@14MHz Amiga 1200
1992 68040@25MHz Amiga 4000
1993 68EC020@14MHz CD32
1994 68060 50-60MHz >1.52 DMIPS/MHz (Motorola literature states "over 100 MIPS at 66 MHz")
1994 68040@25MHz Amiga 4000T

The Amiga 600 was using a 68000 13 years after it was released which was the oldest CPU for a CBM Amiga product. Maybe it wouldn't have been so bad if it had been an Amiga 300 with a $300 target price but how this model survived when the price target doubled is beyond comprehension. CBM loved the Motorola bargain bin CPUs. Trevor even learned from CBM how to make cheap Amiga like computers when he went dumpster diving and found the PPC Tabor CPU. Bargain!

The primitive 68000 released in 1979 is still the lowest common denominator as that appears to be sufficient for the AmigaOS to be optimized for today. The 68k architecture never had poor performance and I believe it has similar performance potential to that of the x86 which history proved as high. The problem is and was a lack of modernizing.

Last edited by matthey on 20-Nov-2021 at 01:09 AM.
Last edited by matthey on 19-Nov-2021 at 06:34 PM.

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle