@OlafS25

ARM is the only reasonable way forward.
Native port of AROS_64bit MP would go a long way to waking people up.

@Lou

Has anyone started AROS for ARM? (ARMAROS?)

_________________
Sometimes we give people a lot of credit just because they're writing nice sentences even if it isn't adding up to much.

@Birbo

I think Michal did and can answer that. He worked on Aros on RPi but I do not know how far it got.

@Lou

The experimental SMP-Version of AROS was the X64 version. It booted but I myself never used or tested it because it is not in my interest

@OlafS25

Quote:

his idea is to have a "amiga-like" desktop on top of linux and everything amiga.

Unix - NOT Linux.

Like NeXTStep. Like IRIX. Like A/UX. Like Solaris. Like Ultrix. Like TruOS. Like AIX. Like macOS.

Sigh, it’s really frustrating to see all nonsense showing up to ridicule a quite sane and obvious concept.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Rose

Quote:

I agree that his ramblings make zero sense. It's just funny that he basically says that nobody wants the shit he's rambling about.

Well, I want it - it’s what I really have wanted since CBM, the merger of AMIX and AmigaOS, similar to what Apple did with A/UX, similar to NeXTStep etc - an Amiga desktop on top of UNIX. It was what a large portion of developers wanted, replace TRIPOS etc with a BSD lite ontop of Mach and modernise the rest of the OS with contemporary technology. Since it quickly became obvious after the demise of CBM that this wasn’t happening, these developers left Amiga to persue their interests elsewhere - there are rather core developers of the BSDs and Linux that have Amiga background.

Last edited by kolla on 28-Oct-2021 at 07:37 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@OlafS25

Quote:

OlafS25 wrote: @Birbo I think Michal did and can answer that. He worked on Aros on RPi but I do not know how far it got.

He seems to have paused to work on his 68k emulator ... which is nice ... but he made it run on RaspberryOS instead of AROS(on RPi4)...

I understand you are into the classics but that's just it - it can be emulated trivially today so if 'Amiga' is ever to evolve, it needs MP, among other things...like you know CHEAP HARDWARE. Hence my desire for AROS native RPi4 port.

@IridiumFX

Quote:

No custom chips = no Amiga

All modern computers are littered with custom chips, to the point that they are running their own tiny micro “operating systems” (and typically RT too), which the “computer OS” only communicate with through APIs - we typically refer to them as “firmware”. So a modern computer isn’t running one operating system that controls all the hardware, but rather a good handful of operating systems that together present “a system” that looks like a yesteryears computer on which what we call “the operating system” is running. So, all modern computers are very much Amiga like these days.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

calling them "custom chips" is a shortcut for "Amiga custom chips". As there's no ISO standard for a chip, every chip is "custom". But on the Amiga, I think, we are talking about Amiga custom chips.

I have seen already people here around that battle, fight and shout for "Amiga" as a name and nothing else. What about you? Behind the sticker "Amiga", what do you expect to find? Any pc ? then why keeping the sticker at all ?

Yes, by nowadays standard they are slow (and as someone pointed out, they were slow even in 1990), but that's how it goes. Amiga is a platform from 1988 after all

@IridiumFX

Time to make the "custom chips" into shared libraries and just be done with them.

New libraries for newer hardware.

Maybe that's just a stupid idea.

_________________
It's not the question that's the problem, it's the problem that's the question.

@SHADES

That’s what P96 and AHI are, so … already done.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla @SHADES

And a macintosh with P96 or a process running a Paula-in-a-shared-library would be an Amiga by this definition ?

What's the differentiator between an Amiga and a windows PC if you reduce everything to "I have installed this library" ? should we suggest Hyperion to start printing a couple billion labels so they can have their OS sticked next to the dozen wintel stickers on a freshly bought machine ?

Frankly speaking, I don't see what would this solve. Would you also add a polling mechanism to detect reads / writes to specific memory addresses and behave like the Amiga (you know, the actual one, not the sticker-One "NG"s ) ?

@Birbo

The point is: Stop crap "PPC has died" and start working on something usable on x86.

@Rose

Nobody wants shit alled AROS that is not compatible, not modern, not fast at the same time.
Unix is the only way that Amiga OS may be modern and fast again.

@ppcamiga1

Geeeeesus! I feel amazed that I am actually having a conversation with you.

Last edited by Birbo on 29-Oct-2021 at 11:15 AM.

_________________
Sometimes we give people a lot of credit just because they're writing nice sentences even if it isn't adding up to much.

@kolla

Quote:

kolla wrote: Is Shell-Seg 47.47 supposed to work with previous OS releases (like 3.1.4.1), or is it supposed to just crash and reboot the system with an exotic guru code? Asking for a friend.

The V47 shell no longer contains the big bundle of functions which handle edge cases and workarounds for data structures previous shells had to account for.

dos.library V47 is expected to do right by the shell now, which was not a given in all earlier versions of both shell and dos.library (going back to 1989 onwards).

This is the reason why shell V47 will "panic" and show the alert. Sadly, it's safe to say that the shell code is not nice in any way whatsoever. The code is basically an augmented 'C' port of the original BCPL version, ca. 1989.

In the shell everything is difficult to achieve, from working around data structure limitations, creating such data structure substitutes on the fly, to properly unwinding the data structures which shell created and exiting safely.

If they let us do another AmigaOS 68k release, shell is at the top of the list of components which need a code review, possibly therapy or an exorcism. It's that level of baffling/complex/disheartening, I'm afraid

@Mobileconnect

Quote:

@olsen As a former engineer from the similarly constrained Symbian OS I would love to discuss with you ideas for making AmigaOS more robust without breaking it, like using a cleanup stack to introduce a form of MMU-less resource tracking. Or rearchitecting DOS, Intuition etc to use something like Symbian's R classes under the hood. I've emailed you in the past but sadly not had responses.

I am truly sorry

I have been so much better at answering e-mails and checking forum messages in the past, but the last two years have taken their toll, I'm afraid. Right now I really suck at responding to e-mail and forum messages, with more than 800+ unanswered e-mails alone.

That said, I would really like to take you up on your offer. We humble developers already discussed resource tracking briefly, but it is a knotty problem, with the operating system not designed from the ground up to accommodate it from the start (reportedly, the exec we have today is the "plan B" implementation with the original design getting axed which would have featured resource tracking).

@olsen

And it’s this “plan B” that seemingly define what is Amiga for many people.
Isn’t it ironic, these people would have “hated” if “plan A” (CAOS) had succeeded, with all its “unixy” features (pardon all the bunny ears) :)

Regarding shell… after the mind boggling situation with shell v46 in kickstart 3.1.4, it’s my conclusion that a better option would be to have a minimal shell in kickstart, and “upgrade” it after boot with L:Shell-Seg using Setpatch, like it was done in old 1.x times, and also in 3.1.4.1 update. The shell in the kickstart does not need to be as feature rich as interactive shells, but it really needs to be solid.

For the bug vs. features list… changes since 3.1.4.1
With Os3.2 one cannot have env variables as default values in script arguments, for example, this no longet works…

.key RUSER/K,RHOST/K
.def RUSER "${RSH/RUSER}"
.def RHOST "${RSH/RHOST}"

echo "<RUSER> <RHOST>"

Last edited by kolla on 30-Oct-2021 at 04:49 PM.
Last edited by kolla on 30-Oct-2021 at 04:48 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@SHADES

Quote:

Time to make the "custom chips" into shared libraries and just be done with them.

I have already done, that. But no program uses that library, so it solves nothing really. It can be way port software or play around CIAA/B timing or something. but the way this should work, is that hardware is polling sates, from values in hardware, they are basally busy looping, that’s not ideal for anything system friendly application or game, in the end it makes most sense in hardware, not in software.

i have:

chipset.library for timing and puala
libblitter.library for the hardware blitter
libcopper.library for rendering the cooper list.

chipset.library is one that makes the least sense, the libblitter.library and libcopper makes the most sense. its lot of work when you can just run the game/app in euae instead, of porting it over. libcopper is work in progress

Last edited by NutsAboutAmiga on 30-Oct-2021 at 06:16 PM.
Last edited by NutsAboutAmiga on 30-Oct-2021 at 06:15 PM.
Last edited by NutsAboutAmiga on 30-Oct-2021 at 05:07 PM.
Last edited by NutsAboutAmiga on 30-Oct-2021 at 05:05 PM.
Last edited by NutsAboutAmiga on 30-Oct-2021 at 04:58 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Lou

Quote:

ARM is the only reasonable way forward.

I noticed in the AmiWest video for the ARM 68K emulator that the ARM instructions needed to split a 32-bit load into two seperate 16-bit operations. So it must be a similar RISC design to PowerPC. It's the perfect replacement for PPC!