AmigaOS 3.2 and beyond

[gdonner]

Originally Posted by jdb78

I ordered OS 3.2 right away. I am so curious, how it "feels" like, using this brand new OS. Thank you so much for your dedication, devs! <3

I suspect(?) the most immediate thing you'll notice is that it feels snappier/more responsive than 3.1.4. At least that's what always struck me every time I booted into 3.2 as opposed to 3.1.4.

[gdonner]

Originally Posted by Rotzloeffel

You can use your Kick 3.1 ROM but have to reboot the machine once to load all the new Modules. It is better to use the new Roms to have all the improvements which it brings. The new bootmenu the new scsi.device the new intuition.library the new mechanism to update modules automatically and so on......

Not to mention the new Failsafe boot option, which is incredibly helpful--really should have been added by C= back with AmigaOS 2.04 (IMHO).

C='s view was "don't mess with the Startup-sequence--that's what User-startup is for"... which is good advice; but sometimes you have no choice.

Quick snapshot (sorry for the poor quality photo):



...and a quick look at some of the very nicely improved (font-sensitive at last! Prefs editors -- note that most of the icons are from my OS 3.5/3.9 CDs).

Are there people that already have experience with Vampire and OS 3.2? Vampire uses a "3.10" kickstart and allows to map another kickstart over it. In using the map utility, modules vampire needs are added to the list as well. Does someone know whether Vampire and 3.2 can co-exist without crashing, disk corruptions etc?

[TuKo]

3.2 works fine on Vampire

[Rotzloeffel]

Originally Posted by gdonner

...and a quick look at some of the very nicely improved (font-sensitive at last! Prefs editors -- note that most of the icons are from my OS 3.5/3.9 CDs).

Could you please remove the Background of your Icon-Texts? This looks ugly

[bubbob42]

Originally Posted by Rotzloeffel

Could you please remove the Background of your Icon-Texts? This looks ugly

I think Gred did this on purpose because black text does not contrast nicely with a photo-style background picture.

@Greg: Since it's 3.2, you could choose "Shadow" or "Outline" text style as an alternative.

Edit: And please do add 2 extra pixels for title bar in Icontrol design prefs. It'll look much better.

[alancfrancis]

Originally Posted by boemann

An updated NDK is included on the CD

Awesome! I'll look to get it integrated to my bebbo-gcc install :-). Is it backwards compatible? Can I still collaborate on a 2.0 project with the new NDK ?

Alan

[boemann]

Originally Posted by alancfrancis

Awesome! I'll look to get it integrated to my bebbo-gcc install :-). Is it backwards compatible? Can I still collaborate on a 2.0 project with the new NDK ?

Alan

As long as you don't use post 2.0 features yes I don't see why not.

Btw we have included .sfd files so "pragma" files can be build for the various compilers out there. And iirc also prebuilt such files for most compilers

[alancfrancis]

Originally Posted by boemann

As long as you don't use post 2.0 features yes I don't see why not.

Btw we have included .sfd files so "pragma" files can be build for the various compilers out there. And iirc also prebuilt such files for most compilers

Great!

Thanks again for all your hard work and dedication. Not just the actual coding, but fielding questions and dealing with feedback. You guys should have a tip jar somewhere so we can buy you beers. <3

Alan

[Olaf Barthel]

Originally Posted by alancfrancis

Awesome! I'll look to get it integrated to my bebbo-gcc install :-). Is it backwards compatible? Can I still collaborate on a 2.0 project with the new NDK ?

Alan

Nothing has been deprecated, it's still good to develop even for Amiga OS 1.0

A great number of changes have been made for modern compilers (even if those modern compilers are now several years old). For example, the "#include <proto/library_name_of_your_choice.h>" is now much more robust than before, has support for Manx/Lattice/SAS/DICE/GCC baked into it. You no longer need to take "<clib/library_name_of_your_choice_protos.h>" and one of "<pragma/library_name_of_your_choice_lib.h>", "<pragmas/library_name_of_your_choice_pragmas.h>" or "<inline/library_name_of_your_choice.h>" to the dance.

Also new are the "proto/debug.h" and "proto/alib.h" header files. The latter contains, for the very first time, the full, awkward and embarrassing list of global symbols which are defined in amiga.lib (you linked against lib:amiga.lib before lib:lc.lib and your program crashed: now you can see why). These are commented out by default, but you can test your own code to see if it uses symbols defined there and which might cause calamity. When you look at those symbols, try not to groan or laugh: you are being watched

The function prototypes have been sanitized all over again and now use const qualifiers in all the right places (now even more correct than the last time, and just possibly even less correct than the next revision, but such is life). Types have been corrected as well, where necessary.

For cross-compilation or diagnostics/code quality testing the header files now support C99 data types, as defined in "<stdint.h>". C99 data types are enabled automatically and can also be enabled through a "#define AMIGA_STDC_C99". Note that if your compiler defaults to 64 bit pointer addresses you'll still get warnings, though, as the definition of APTR and other pointer types embedded in operating system data structures may not be the same size Unfortunately, there is no good way to produce exactly binary compatible data structure layouts for 32 bit and 64 bit pointers unless you pepper the whole header file collection with sneaky preprocessor macros. As for now, the type checks for pointer types, etc. should be sufficiently consistent for QA work, e.g. by feeding code into clang. The scalar types (8, 16, 32 bits, signed/unsigned) now also have all the right sizes, suitable for range checking.

A long term goal is to go over the data structures with a fine-toothed comb and get every pointer type right, with the right qualifiers and the right function pointer parameters.

[Hedeon]

I know it is niche, but is WarpOS still supported through picture.datatype?

[Rotzloeffel]

Originally Posted by Hedeon

I know it is niche, but is WarpOS still supported through picture.datatype?

You mean warpdatatypes especially ? This was, IMHO never supported since CybergraphX uses his own picture.datatype.... and the hack of this picture.datatype was not supported in V43 since 3.9 nor 3.1.4 or 3.2....

[Michael]

The picture.datatype is now generic 68K code that works on all systems Native/P96/CGX...
As for the warpup support, that was dropped a long time ago. On 060 systems it should not be any issue since it's faster then before.

[Bobson]

Just an idea....

Amithlon was a successful attempt to get AmigaOS 3.9 running on X86 hardware. A linux kernel was modified to boot the X86 hardware, and launch Amithlon as a seamless emulator. Games that relied on the chipset could be run through UAE, within the Amithlon emulation.

Amithlon differed from other emulators in that the Amiga side drivers were capable of accessing the underlying X86 hardware directly, and, it was possible to compile and run native X86 code and run it within AmigaOS 3.9

It was interesting - and could have been a possible pathway to migrate AmigaOS to X86.

ARM is ubiquitous... the Raspberry Pi is offers tons of bang for buck. Indeed, we are seeing Raspberry Pi's used to keep our ageing hardware going... PiStorm... PiZero used for HDMI output etc...

So how about this for an idea: An Amithlon inspired AmigaOS 3.2 designed to run on Raspberry Pi 4, that serves as a way of migrating to ARM. It would have the light weight linux kernel that boots the hardware, booting 'ARMithlon' - running AmigaOS 3.2 etc... ARM code compiled and cable of running inside AmigaOS 3.2.

It may even be possible to produce real kickstart roms running on a PiHat, or new custom chips...

The Pi400 is very much inspired by the Amiga 600. The people behind Raspberry Pi love the Amiga. The user base is massive... if Amiga OS could be introduced as a first class operating system on that machine I can only see good things happening...

[bubbob42]

@Bobson Did you register specifically for that post?

AmigaOS is retro. It is supposed to work on 68k, be it original, FPGAd, emulated. It is a mix of Assembler and (more and more) C.

You won’t port it, we won’t port it and there’s a gazillion of things to be done before anyone with enough time would get bored enough to even consider it.

Back to topic.

[Bobson]

Originally Posted by bubbob42

@Bobson Did you register specifically for that post?

Yes - it was suggested I come here to do just that. I don't know how my post is offtopic when the title of this thread is "AmigaOS 3.2 and beyond"... I've avoided Amiga forums for years because of the snark... glad to see its alive and well

AmigaOS might well be "retro" -- but I invite you to read the opening post by
@gulliver

"For us, developers, it is important to get your ideas and opinions
regarding AmigaOS right. We don't want to lose the feedback loop that
is required for the constant improvement we aim for our beloved OS."

I see my suggestion as part of constant improvement - a way to move the platform along, and sell units (another Magic Pack?)... "nothing happens without a sale! (to quote my former sales director). My suggestion is also still "retro" - as ultimately, its emulated 68k but seamlessly integrated.

It's silly to suggest I won't port it - I can't port it. I don't have the source code... It's been years since I last wrote any C... and I don't know Assembler (Rust, Elixir and JavaScript is what I use for the day job). I'm not qualified to do the job... but I do know people who are...

[E-Penguin]

I think you probably want to look at AROS

[Tigerskunk]

@Bobson: you are only the one millionth person to come around with exactly that kind of idea and everybody hanging out on Amiga forums has been discussing it to death for the last 20 years.
That's why you get answers here you might perceive as 'snark'.
It's not because we are all mean people, it's just that we are tired of these discussions.

Btw, if you want an Amiga OS variant that runs on X86 hardware, check out AROS.
Be prepared for not many people giving much of a fuck about it, though.

[bubbob42]

Originally Posted by Bobson

Yes - it was suggested I come here to do just that. I don't know how my post is offtopic when the title of this thread is "AmigaOS 3.2 and beyond"... I've avoided Amiga forums for years because of the snark... glad to see its alive and well

Ah, don’t be impressed by a sarcastic smiley post.

Suggestions to port AmigaOS to platform XY always make me smile, because people tend to underestimate the amount of work it would entail. If you‘re seriously interested in ARM & Amiga, a ZZ9000 might be something for you to have a look at.

[Hedeon]

Originally Posted by Rotzloeffel

You mean warpdatatypes especially ? This was, IMHO never supported since CybergraphX uses his own picture.datatype.... and the hack of this picture.datatype was not supported in V43 since 3.9 nor 3.1.4 or 3.2....

3.5 or 3.9 (not sure where it came from, but it is installed on my 3.9 system) is a fat binary supporting 68K and PPC. I looked and it says V45.17 and is about 89k.

Originally Posted by Michael

The picture.datatype is now generic 68K code that works on all systems Native/P96/CGX...
As for the warpup support, that was dropped a long time ago. On 060 systems it should not be any issue since it's faster then before.

Long time ago as in... 3.1.4? As it was part of OS3.9 (or at least it did not overwrite if it was installed with OS3.5)

Shame, but understandable. I guess I can always install it over the 3.2 one.