commodore chipset in amiga is not important.
it has not support for 256 or thousand colors.
commodore graphics in amiga in 256 or thousand colors acts just as dumb framebuffer
and may be changed to whatever want.

68k in amiga is not important.
amiga software is written mostly in c/c++.
68k may be changed to almost everything that work in 32 bit big endian mode.

one and only thing from original amiga hardware that still "clasic" amiga have to have
is 32 bit big endian cpu. which means no x86, no arm, no risc-v.

@ppcamiga1

Get some new material for pity's sake, you're embarrassing yourself and all of trollkind.

_________________
Doing stupid things for fun...

@Karlos

Are you doing your own brexiteering? :)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: It's too late: it was perfectly legit to disable/enable the multitasking and even the interrupts. I don't know why they dragged it along 20 years ago. Then 10 years ago or so wonder how to work around it. They needed a new API.

Once you need a new API you can think about a new o.s..
Quote:

Quote: Amiga, as a platform, is well defined and we've to take it as it is. It was. Since it never was able to become anything different. I do recall reading about talks Amiga magazines had about what an Amiga was. And if different hardware with different chips would still be an Amiga. We know Commodore were planning this but we'll never know the result. Would an Amiga computer that wasn't an Amiga as we knew it be accepted as an Amiga in a new Amiga generation?

I don't think that it would be relevant. What the owner of brand decides, is it's own business.

However and since it's a business, the customers don't like its new products are entitled to don't buy them and boycott the new generation.

What people often don't understand is that the real power stays on the customers hands / pockets: companies have to make money otherwise they starve and go bankrupt. And customers can and, IMO, SHOULD orient companies' decisions with the power which is coming from their pockets.
If they don't so, then they shouldn't blame the company for such decisions because they are co-responsible for the situation.
Quote:

Quote: If you want something more then it's better to define another platform, even greatly inspired to Amiga, but which will be different and running different software. I wonder what Commodore would have called the Amiga follow up? Amiga C65?

Amiga 1555++
Quote:

After some years I have my own name. I'm thinking the AmigaOne could have been called an Amigos. But not as a plural, referring to one machine. The Amigos would be inspired by the Amiga, similar in idea, but also different. The Amigos would reflect how it is like the Amiga but focuses more on the OS. AmigaOS.

Then it should have been AmigOS.
Quote:

Quote: POWER has no competitor because it's another dying horse, like PowerPC: it has absolutely no appealing point / features compared to the other CPUs, besides a software library and support which are coming since some decades. A few years ago it was still relevant or still existed. A software library won't last with a CPU redesign, unless it's more stable than PPC, which his plagued with incompatibility. The latest Debian and Ubuntu do how ever still support it in PPC64intEL mode.

Which means bye bye PCs-with-PowerPCs: no big-endian, no party.

It would be interesting to know which endianess is supported by the Chinese company which is producing new PowerPCs (let's if it succeeds, first).
Quote:

I've heard of a large software base as a reason to still use CP/M today. Which apparently has a million programs.

That's really hard to believe. Maybe some tens thousands (which is already A LOT for that time), but a million... doesn't look realistic.
Quote:

Quote: By masking the data which isn't used (and should be left untouched). I imagine so but it still looks fiddly. It would also need to be strictly ASM.

No, intrinsics are perfectly fine, if the programming language supports them.
Quote:

Well, 68K is the same really that way, since it needs to be atomic on 68K as well and ASM will do that.

On 68k yes. But not on Amiga, because it doesn't work without Fast Mem.
Quote:

Quote: It's not only about Forbid/Permit and Disable/Enable: it's about ANY code which is touching their specific counters which should be intercepted and treated accordingly. I'm not sure what they've done about that. 68K code can touch the Exec count. But, on the PPC side, it still needs to be atomic or it's not threadsafe so to speak.

I don't think so. Since the Amiga o.s. is purely single core/thread, no atomics are needed in principle as long as the architecture has RMW instructions (I mean: a single instruction doing it).

AFAIR PowerPCs have only the classic (for L/S AKA former RISC architectures) load/acquire + store/release instructions, which aren't threadsafe (per sé: there can be a context switch in the middle).
Quote:

Quote: Which means: FORGET IT! It's too hard work because there's simply too much software which did it (and it was LEGIT!). Right now they are working on ways to reimplement the old mechanisms. I don't know how. I can think of a few ways. 1. Defer a Forbid lock, put task in wait queue, then process all in next task switch interrupt. 2. Trigger a Cause and run code in soft interrupt, which is higher than task and lower than hard interrupt. 3. Given a Forbid should execute quickly, and if a task still has quantum it would have executed in the quantum, simply let it do its work and switch it out after the lock. Of course, these are not without flaws. Such as it would need to be known where lock code starts and ends. But it seems to me the best place would be inside an interrupt where it needs to do housekeeping. Of course the cores then need to operate in parallel without conflict. And the main problem is to avoid cores holding each other up.

The main problem is stopping ALL cores, IMMEDIATELY, once a sensible API is invoked.

For 68k code, then you also need to trap accesses to sensible counters. AND stop all cores (IMMEDIATELY). This is the major challenge. Good luck!
Quote:

Quote: What's consistent with the Amiga o.s. is that it was written by geeks which made what for them were local optimal choices for solving a specific problem. And with the hurry to finish the work ASAP because of the deadline. Sorry I meant *inconsistent* with BYTE in Forbid count and WORD in library count.

The reason is simple: the library counter can NOT be a byte, otherwise the structure is not 16-bit aligned anymore (AFAIR. I haven't checked now).

The Exec's counters can be byte, only because they are grouped, so the following fields are 16-bit aligned.
Quote:

Quote: This lead to so many bad design decisions, unfortunately. It is. I look at other OS like Linux, inspired by Unix, and wonder how it ended up on top. I mean, the terminal looks olds fashioned and the API is full of lower case functions as are commands. I know I'm only looking surface deep but the Amiga looks so much neater with Capitals used in function names and commands. Unfortunately it also needed to be neat underneath and expandable.

Abstraction/Opaque structures is the key: something which is alien to the Amiga o.s., since it published almost everything.
Quote:

Guess why the Amiga o.s. was so lightweight: it's because it completely lacked any protection / abstraction. Do you need something? Do it! Everything is public and you can do whatever you want (well, there were some guidelines, but that's very little stuff compared to the "openess" of the platform).

And, ironically, it was designed to have memory protection and be more like Unix with similar path structure. But instead we got Tripos. Or Tripe some would say. I find it hard to imagine as Tripos became the DOS layer and Exec was still the kernel layer. But protection would need to be built into the kernel. That said I do like how AmigaDOS turned out. It has it's quirks. But internally it looks like a hack, using a node name to point to a DOS packet or something. No wonder it went wrong![/quote]
Please, please, please! DOS is essentially Tripos, so it's like having an o.s. running inside another o.s.! Only Amiga's engineers made it possible!!!

And what about the most pervert thing in the worlds. BCPL pointers (BSTR included)!!! GOSH!!!!!!!!

@kolla

Not sure what you mean. Happy here in the NGtherlands. I just need validation from Classic Dutch of my Dutch Identity...

_________________
Doing stupid things for fun...

@Bosanac

Quote:

Bosanac wrote: @Hypex An Amiga is whatever the owners of the Amiga trademark say it is. That’s it.

This is EXACTLY the reason why before I've stated this:

Something doesn't necessarily need to be made by Commodore to be called Amiga. "Obviously" (!).

Glad that someone else pointed it out as well.

@matthey

Quote:

A semaphore or other locking mechanism can be required before changing the (unaligned) counter and released afterward.

It couldn't use an OS semaphore as that uses Forbid internally. Though it should be self contained since it contains a Forbid like counter. It's also more complex by the looks of it. OS4 does add mutexes.

Quote:

On a Forbid, other SMP cores need to empty the pipeline, flush the store buffer and stall on any globally available memory access. Deeper pipelines, a weak memory model and OoO make this more expensive. Custom hardware may be able to reduce the overhead but SMP support with older software would be a kludge at best while newer software could avoid Forbid with better APIs.

Of course they needed the APIs in place by now. There is a lot of talk about 68K compatibility holding it back. But I don't see that as relevant since 68K is emulated anyway. 68K library functions have their own jump table. And while the direct integration was good with 68K apps being their own task as always, there comes a time when there needs to be a middle man layer, then perhaps some sand boxing.

On top of this is that OS4, like on 68K, doesn't support threads I thought they would have added them by now but I'm still waiting. This is ironic since, without any memory protection, nothing sophisticated needs to be put in place for threading. OS tasks have equal access to all shared data. Threading could be made in the context of a parent task. So all threads could run with their own stack and registers like a task, but would share a parent task and environment.

Last edited by Hypex on 10-Dec-2023 at 12:37 PM.

@Hypex

Quote:

Hypex wrote: @matthey table. And while the direct integration was good with 68K apps being their own task as always, there comes a time when there needs to be a middle man layer, then perhaps some sand boxing.

Remove the perhaps: it doesn't make any sense have a system which is crippled only because of the pathological disease to keep this umbilical cord.
Quote:

On top of this is that OS4, like on 68K, doesn't support threads I thought they would have added them by now but I'm still waiting. This is ironic since, without any memory protection, nothing sophisticated needs to be put in place for threading. OS tasks have equal access to all shared data. Threading could be made in the context of a parent task. So all threads could run with their own stack and registers like a task, but would share a parent task and environment.

It's the exact opposite: the Amiga o.s. has only threads (running on a single process).

So, what's missing is the process concept & implementation.

@ppcamiga1

Quote:

ppcamiga1 wrote: commodore chipset in amiga is not important. it has not support for 256 or thousand colors. commodore graphics in amiga in 256 or thousand colors acts just as dumb framebuffer and may be changed to whatever want. 68k in amiga is not important. amiga software is written mostly in c/c++. 68k may be changed to almost everything that work in 32 bit big endian mode. one and only thing from original amiga hardware that still "clasic" amiga have to have is 32 bit big endian cpu. which means no x86, no arm, no risc-v.

Commodore's Amiga chipset is important for the Amiga 68K software legacy.

Commodore's AGA chipset has 256 colors e.g. Turrican AGA.

PiStorm-Emu68 preserves Amiga's Auto-Config with real Amiga 68K Broadcom graphics drivers.

PiStorm-Emu68's ARMv8 CPU operates in big-endian mode.

Last edited by Hammer on 10-Dec-2023 at 01:37 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

More importantly most of the source code of the classic programs are not available.

This why can’t pick any CPU we like, and this is why the chipset is not irrelevant.
but with fast CPU, that’s emulate classic computer quite well, never perfect.

Last edited by NutsAboutAmiga on 10-Dec-2023 at 09:40 AM.
Last edited by NutsAboutAmiga on 10-Dec-2023 at 09:31 AM.
Last edited by NutsAboutAmiga on 10-Dec-2023 at 09:30 AM.

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

@Karlos

Ok, was under the impression that you were located in the UK.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro


“Child process” I kind a think of as tread in AmigaOS4.1, etch task / process has their own signals, but child process is expected to have access to parent local variables. the thing missing sense of memory ownership, private memory only belongs to the parent process, and is not shared with its child processes, not sure it’s an issue, but be nice if there was something in between. But then the OS will actually need resource tracking.

The place where AmigaOS screwed up was on network sockets because they depend on the file descriptor but can be shared but not by default. And this what breaks libc / newlib and so on. and that’s kind of stupid sense its API is on top of the that is supposed to simulate a BSD / Linux / POSIX environment. My hope is that that part will be completely rewritten in the new clib3, so it works more like a service. maybe a process per connection. so it do not depend directly on the low level Amiga API’s, that has to be keep in order for old programs to work as they should.

An alternative to that be to replace bsdsocket.library with something new, that do not have this issues, and then bsdsocket.library can be emulated on top of new and better API, but that’s is easier to say then to do, but in any case it be idea to make more like Linux, so it becomes easier to port kernel modules to AmigaOS.

In the sana ii API, the packet are where in efficiently copied around, it seams to me, it be more efficient sort the packed and send them off to a new owner if possible, but sure memory has to copied from network card to system memory, that can not be avoided, but at least do most efficient method, like with a DMA transfer.

Last edited by NutsAboutAmiga on 10-Dec-2023 at 10:46 AM.
Last edited by NutsAboutAmiga on 10-Dec-2023 at 10:37 AM.
Last edited by NutsAboutAmiga on 10-Dec-2023 at 10:31 AM.
Last edited by NutsAboutAmiga on 10-Dec-2023 at 10:30 AM.
Last edited by NutsAboutAmiga on 10-Dec-2023 at 10:29 AM.

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

@kolla

How very dare you. You are literally committing an erasure, denying the existence of NG Dutch people by deadnaming their entire country like that! The NGtherlands is just across the sea from Classic Netherlands.

Any day now. It's in the post, I'm sure of it...

_________________
Doing stupid things for fun...

@Karlos

I write 68K software, that identify them self as PPC software, because it written on PPC OS, so program feels they born as wrong file format.

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

@NutsAboutAmiga

Quote:

I write 68K software, that identify them self as PPC software, because it written on PPC OS, so program feels they born as wrong file format.

That’s your right as a transdisabled NG woman of colour! Preach sister!!!!

@Karlos

Quote:

How very dare you. You are literally committing an erasure, denying the existence of NG Dutch people by deadnaming their entire country like that! The NGtherlands is just across the sea from Classic Netherlands.

Don’t mention NG Oliebollen the Classic Dutch get very offended.

[url] https://youtu.be/QDJau6C1TRQ[/url]

@Bosanac

We don't have such obsolete things in the NGtherlands, oliebollen doesn't have chunky. Instead we have gulab jamon. These are superior in every way to the oliebollen and represent what the originators of the Classic Dutch intended to upgrade to before they went (morally) bankrupt and began asserting all this nonsense about what it means to be Dutch.

_________________
Doing stupid things for fun...

@Karlos

Sacrilege! Jij klassieke kankerhoer buitenlander!

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Hammer More importantly most of the source code of the classic programs are not available. This why can’t pick any CPU we like, and this is why the chipset is not irrelevant. but with fast CPU, that’s emulate classic computer quite well, never perfect.

RPi 5B's price approaches the entry-level AMD AM4 and Intel LGA 1200 price range.

It's about AUD $137 for barebone RPi 5B 8 GB.

In AUD
$99 for MSI B450M-A PRO MAX or ASRock B450M-HDV Rev4
$64 for AMD Ryzen 2200G (4C/4T) with Vega 8 IGP.

AMD solution murders RPi 5B in the Genshin Impact test. AM4 is upgradeable to near gaming CPU king Ryzen 5800X3D later down the road while ARM clone competition needs to switch towards the full Apple M1/M2/M3 products.


In terms of $$$ per performance, RPi 5B is inferior compared to the X86 competition. I'm aware of MorphOS AMD64 build.

Last edited by Hammer on 10-Dec-2023 at 11:47 AM.
Last edited by Hammer on 10-Dec-2023 at 11:45 AM.
Last edited by Hammer on 10-Dec-2023 at 11:44 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@NutsAboutAmiga
"More importantly most of the source code of the classic programs are not available."



100%. That is a problem. 1.3 software that doesn't run with faster cpu's or 3.2. The other problem to your point is that NG sometimes cannot run classic software that doesn't hit the hardware because of poor coding. I have tried to get source code for a couple of products without any luck.

The last problem is that most software running on 3.x and 4.x isn't very good, so the uses are limited.

So a new cpu won't give us much other than to run weak software faster. That is why 4.1 is putting the cart before the horse, so they can legally be free (I do find that most ironic, looking back at the history of it all).