@kolla

Quote:

Main issue with DiskDoctor is that it doesn’t doctor disks… Maybe FileRescue would be a better name?

I know this is just an example but it doesn't have the same ring to it. DiskDoctor is an alliteration. The name is constructed to act like a hook in song and be catchy.

@NutsAboutAmiga

Quote:

I think AmigaOS 68k should be developed in parallel with AmigaOS PowerPC, it makes sense to have same API, when SMP is available, even if AmigaOS 68k can’t take full advantage due to only having one CPU, but hey, adding some extra CPU’s in UAE can’t be too hard.

Problem is the OS4 API uses that interface stuff so logically it would need to be dragged over. Which would break 68k sources on 68k that wouldn't made sense. But, OS4 has lots of parts rewritten in C. Like the AHI 4 to 5 transition, the newer code made for PowerPC wouldn't perform as well. So 68k code is best with hand coded assembly. Like most of the original code. Using portable code would slow it down. Except for emulation of FPGA, C code would be too slow for practical use, unless SAS/C is really good at it. And more terrible on 68000 which I read more about.

@amigang

Quote:

AmigaOS 3.2 - Is the best most stable, bug free version of AmigaOs on 68k,

I disagree - there’s plenty of bugs and ..ehm… “issues” - it is VERY hard sometimes to know whether something got fixed or got broken - stuff changed, behavior is different, nothing relevant in changefile, no reference to what is “correct” expected behavior…new bug, or new feature?

The great thing with old 3.9 (and for that matter, 3.1) is that issues and limitations are rather well known and documented to various degrees. With 3.2 (and even 3.1.4.2) bugs known to the developers are kept “secret”, and when something weird happens on your system, you don’t really have a way to look up if it is just your system or if it is a known problem.

Also - the user base is a heck lot smaller now, including so called “advanced” users, so smoking out bugs takes more time.

Last edited by kolla on 16-Nov-2021 at 02:08 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

My fastest system with a real 68000 chip is running close to 50MHz, and is significantly faster than many 68020 systems, so why should it not be supported? The 020 requirement for 3.9 was always bogus.

This may be worlds apart, but wouldn't that be like expecting Windows 95 to run on a 16 bit 286, because it was souped up and faster than some 386?

At the time 3.9 came out, it would make sense it would only support 32-bit CPUs. Now, if the Amiga hasn't become 32-bit as standard by the mid 90's, that really shows how behind it was. The 68020 was likely too expensive but still using a 1979 CPU core in the year 2000 looks a bit ridiculous.

@Hypex

68000 is 32bit - please.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@OlafS25

Yes it's very useful.

But DOpus 5 isn't part of OS3.1 as standard which is easily beat by any AmigaOS with shell drag and drop.

@kolla

It's only internally 32 bit. And that is still lacking 32 bit math operations as well as direct FPU support. Externally it still has a 16 bit data bus and 24 bit address bus. That limits it to 16MB though most 68K Amigas were limited to 8MB. Even with RTG setup I can hardly use OS3.9 with 8MB. So unless you've got some funky memory device it would be impractical.

@Hypex

Yes but I use it as standard

As a example:_
http://www.aros-platform.de/archivebrowsing.png

browsing in a lha archive with a GUI and unpacking it (the same works for anything XAD related)

And now you

All "68k"

I do not need PPC for a better desktop

What I do not understand is the hardware concentration... hardware perhaps limits what effects are possible but basically the desktop defines the user experience. And that is independent of the hardware. Short said: a good configured desktop on slower hardware offers a better user experience than a bad configured and limited desktop on better hardware.

Last edited by OlafS25 on 16-Nov-2021 at 03:40 PM.
Last edited by OlafS25 on 16-Nov-2021 at 03:22 PM.
Last edited by OlafS25 on 16-Nov-2021 at 03:20 PM.
Last edited by OlafS25 on 16-Nov-2021 at 03:20 PM.

@Hypex

In modern lingo, 68000 is 32bit - it’s the instruction set that counts, address space, databuses etc come and go with changing “bit sizes”. Or do you suggest that lots of AMD64/x86_64 CPUs are not REALLY 64-bit because they “only” do 48-bit RAM adressing? Well, they compensate with 128bit SSE, so heh… no, stop it, please - the entire 68k series uses 32bit instruction set, and that’s what counts. 286 did NOT.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Chris_Y

Quote:

Chris_Y wrote: @olsen Quote: Could you elaborate on the issues you are facing? Lots of linker errors, probably best to point you back to our original discussion at https://github.com/bebbo/amiga-gcc/issues/222#issuecomment-899099508 Aside from that, some of the fd/sfd files are missing (basically anything to do with ReAction), so the 3.9 NDK is still required in order to rebuild the inlines. I had to build them myself for vbcc too, but can't remember if I was getting similar problems.

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:

- The sfd files for the ReAction classes are now complete. Their omission was a combination of bad timing and the release schedule taking priority, I'm afraid

- Speaking of the sfd files in general, they have been reviewed and combed for odd defects, such as those which tripped up the sfdc tool which could fail to process function descriptions for which the register list would contain blank spaces (apparently, the lack of a grammar for the sfd file format was an issue here, also, processing these files needs a lexer and not just regular expression matching). This sfdc tool was and still is part of Stefan Franke's GCC cross compiler. The blank spaces causing inline functions not to be even generated might explain why you encountered the linker errors you reported. It's both baffling and sadly plausible

- In related news, the sfd files now contain the basetype and libname keywords which were prominently added to the NDK 3.9. Back to the future

- The graphics 'C' header files have been reviewed, and while the work is still far from complete (there's just too much to research and make sense of in these header files), we at least kicked the SetOutlinePen() macro out. Also, for the first time in decades the "graphics/gfx.h" file actually attempts to explain what the macros and data structures are intended for.

- The workarounds for getting a timeval out of "devices/timer.h" or using your own choice are now more robust and also documented.

- More cleanup work happened on the dos, devices, libraries and intuition header files, hopefully making the content more readable and consistent.

- Data structures defined in the 'C' header files now use variants of the TEXT or STRPTR types rather than an odd mix of char, BYTE, UBYTE, etc.

- The fancy "compiler-specific.h" header file now properly covers vbcc.

- The inline header file format which vbcc needs is now supported and we ship with the full set. Frank Wille has given the thumbs up for the last batch, but we'll certainly make another one and hopefully will pass muster, too.

- The "proto/#?.h" header files now also cover vbcc properly.

- It's still quite a formidable boulder to roll up that hill, but we've been busy updating the AutoDocs, filling in blanks which so far were at best the subject of speculation. Look forward to read about the horrors lurking beneath select amiga.lib, dos.library, graphics.library and other APIs, now with warnings, cautions, workarounds, example code and neat tricks of how not to set your Amiga on fire while trying to make use of these functions. Now for the first time explains how not to use the blitter functions, the BitMap allocation, etc. functions and their limitations. For the first time ever explains how BltBitMap() works and describes every single minterm know to work (how many are there? just 16; how hard was that?). There's for the first time ever detailed coverage of the Write/Read/PixelLine/Array8 family of functions as well as the mystery for the ages known as WriteChunkyPixels. Read it and weep

- By popular demand we brought back assembly language header files which this time cover all the library vector offset values for the known and documented Amiga operating system. Also handy if you don't ever intend to you link your assembly language code against amiga.lib (which contains all the very same LVOs but which I fully understand if you don't want to go near it with even a ten foot pole to poke it).

Researching AmigaOS APIs which so far didn't get their due (neither through the AutoDocs, nor through the RKMs, nor through reverse engineering or other occult practices) can be both fun and disheartening, but given the huge gaps we have there, somebody has to do it. I wish there was more time and more research results, but, hopefully, future NDK releases will expand upon what the AutoDocs can say about the operating system's features, its bugs and how to actually make use of them without guessing.

While this may not sound super exciting (except perhaps the bit about BltMaskBitMapRastPort, no really!) the plan is to improve the quality of the developer material and in particular raise the level of the AutoDocs quality. The AutoDocs tend to be what developers consult first and, if you've been around long enough, you have learned to be disappointed and confused. This is not how it should be, seriously. This has to be better than it currently is, especially for dos.library and graphics.library, just to name the two biggest problem children.

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...

Last edited by olsen on 16-Nov-2021 at 05:43 PM.
Last edited by olsen on 16-Nov-2021 at 05:42 PM.
Last edited by olsen on 16-Nov-2021 at 05:41 PM.

@BigD

Quote:

BigD wrote: @matthey I can't believe 68000 binaries are the only target for OS3.2 currently! It's beyond belief in an age of Vampires and cheap PiStorm boards!

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.

Given the resources and how many developers are spending their spare time on the project I'd say we need to choose our battles carefully...

@Hypex

Unarc uses XAD, OS 3.9 came with version 10.4 or something like that…

https://aminet.net/search?query=xadmaster

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@olsen

Quote:

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:

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).

Last edited by kolla on 17-Nov-2021 at 09:47 AM.
Last edited by kolla on 17-Nov-2021 at 09:46 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Hypex

Quote:

DiskDoctor is an alliteration.

If that's a requirement, then many programs need renaming :)

Last edited by kolla on 17-Nov-2021 at 09:47 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@OlafS25

Well I was concentrating on AmigaOS only. Since it is what I know about the most. And not Amiga inspired OS.

But your comparison is rather unfair. Since it is comparing a full on distro with extra components to the basic OS that inspired it from almost 30 years in the past. And also using code from a one commercial product with advanced Workbench replacement.

@kolla

Quote:

Or do you suggest that lots of AMD64/x86_64 CPUs are not REALLY 64-bit because they “only” do 48-bit RAM adressing?

Do they commonly access memory beyond the 48 bit barrier? Otherwise that's a false equivalency. And the only one suggesting this is you, to answer your question, since you are just trying to put keys in my board.

Unless you only use software that only stores and retrieves 16 bit memory variables I don't see the point. The double bus access of 32 bit data would still slow it down. Just like the Falcon was crippled with a bad bus.

Quote:

Unarc uses XAD, OS 3.9 came with version 10.4 or something like that…

I tried updating it with XAD and tried other archives but it was still broken. I might need to recheck it though. And I recently found out that OS4 classic has the same problem so it's worse than I thought.

Quote:

If that's a requirement, then many programs need renaming :)

Well not a requirement. But it helps to market it if you have a catchy name. I'm sure there are a few Amiga examples but nothing else comes to mind off the top of head.

@Hypex

Quote:

Hypex wrote: @kolla Quote: Or do you suggest that lots of AMD64/x86_64 CPUs are not REALLY 64-bit because they “only” do 48-bit RAM adressing? Do they commonly access memory beyond the 48 bit barrier?

The first 64bit x86 systems only had 40-bit adressing, nowadays 48-bit is the most common - but you don't hear anyone speak of them as anything else than 64-bit architecture.

And on 68000, address calculations of the addressing modes are always 32 bit, even when data bus to external memory is only 16 bit. You may just as well complain that the A1200 and CD32 weren't really 32bit, since they used a 68EC020, and not the full 68020, and hence suffer from the same RAM limitations as the 68000 systems before them.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

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. 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?

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.

olsen Quote:

Given the resources and how many developers are spending their spare time on the project I'd say we need to choose our battles carefully...

There is a lot of uncertainty with the AmigaOS right now. Multiple flavors with different APIs, lawsuits, no competitive hardware, lack of profitability and pay in some cases, etc. It is a tough situation. I can see why you want to keep AmigaOS priorities conservative.

kolla Quote:

The first 64bit x86 systems only had 40-bit adressing, nowadays 48-bit is the most common - but you don't hear anyone speak of them as anything else than 64-bit architecture. And on 68000, address calculations of the addressing modes are always 32 bit, even when data bus to external memory is only 16 bit. You may just as well complain that the A1200 and CD32 weren't really 32bit, since they used a 68EC020, and not the full 68020, and hence suffer from the same RAM limitations as the 68000 systems before them.

The address bus width doesn't affect performance. It is the ALU (Arithmetic Logic Unit calculation) width and data bus width which define whether a processor is 16, 32 or 64 bits. The 68000 has a 16 bit ALU and data bus so it is clearly a 16 bit processor. The 68000 ISA is 16/32 bit and closer to 32 bit considering it requires supporting 32 bit calculations, datatype sizes and registers. This is as good as some fixed length encoding RISC processors but later 68020 instructions allowed 32 bit displacements with BCC.L and LINK.L which is more than any common RISC ISA allows. The 68000 could branch only +-32kiB with a single instruction using a displacement while the 68020 can branch +-2GiB.

The 68EC020 and 68EC030 are 32 bit CPUs as they have a full 32 bit data bus unlike the 386SX competition with a 16 bit data bus. The Atari Falcon with 32 bit 68030 and 16 bit data bus is similar to some cheap 68k Amiga FPGA hardware using only a 16 bit data bus and 16 bit memory. Code compiled for a 68000 but executed on a 68020 should have better performance in comparison as 32 bit datatypes are now accessed in memory at full speed. The only problem is that 16 bit accesses are often favored over 32 bit accesses due to 68000 instruction timings when compiled for a 68000 CPU. The AmigaOS uses many 16 bit datatypes in memory and the 32 bit CPUs could have benefited from instructions like the ColdFire MVS and MVZ instructions which sign and zero extend into the whole 32 bit data register on loads thus allowing better 32 bit pipelining (gain instruction forwarding/bypassing of 32 bit results and avoid partial register write stalls) without increasing the code size. Naturally aligned 16 bit writes to memory aren't any less efficient than 32 bit writes on a 32 bit CPU though. There are times when the data bus isn't used including writes to a copyback data cache. Performance is usually increased with diminishing returns. A 3rd level cache doesn't give as much benefit as a 2nd level cache which doesn't give as much benefit as a 1st level cache and the 1st level cache is the cheapest. In the Amiga Never Land time warp, we often ignore optimizing altogether and use the oldest technology going all the way back to 1979, even with the good old 68000 still in production after more than 40 years. The Amiga seems just as timeless as the 68000 but is that Amiga success like 68000 success and unlike x86-64 success with some of the highest performance CPUs in the world available today?

Last edited by matthey on 17-Nov-2021 at 09:59 PM.

@matthey

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"."

Last edited by kolla on 18-Nov-2021 at 01:32 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC