@NutsAboutAmiga

I never towered my Amiga. I only towered my drives. And the tower was rather ugly since it would have been based of a common PC case at the time.

The XE was slightly on par with an eMac at the time. Just slightly more expensive for a full setup. I don't think I had any PC at the time and certainly not the latest. The only PC desktops I've had are hand me downs. But I wouldn't compare an XE to a PC as you can't make a direct comparison and Apple were still producing PPC Macs so I would compare to that.

I could have got my G4 module fixed. Not ACube then but may be Thendic France going from memory. However I just thought it would be too expensive and IIRC it wouldn't be any faster but same as what I had. I would end up paying a lot of money for a card repair that didn't even upgrade it. Which tends to happen when you break things.

One thing I know of personally is how PPC CPUs do not do well with heat. Maybe it is the setup of the CPU module, I don't know for sure, but when my new XE was sitting there idling with UBoot the fan suddenly broke loose. And the CPU immediately overheated. I don't know why but on Intel and AMD these things just work. The PPC appears to have no concept of thermal shutdown at all even when it just running firmware code and not being pushed. This would add to the reasons why people have said in the past how PPC is crap CPU. Though I mostly didn't see any reasons and just trash talk but an expensive CPU not protecting itself from harm is a bad CPU. What I do know for sure the fan setup was bad and plastic screws aren't good on a CPU fan! So a cheaper x86 is just more professional on any design you see. I mean, they have rods on a drawbridge holding it down. Fancy!

The X1000 wasn't too expensive for me but I did buy a beta board to keep the cost down. Maybe slightly more than my XE cost me but at least it was better and more powerful over all and just really only let down by slow buggy firmware. Which ironically caused UBoot to reverse it's pop position and put UBoot in a popular light. Last I checked the X5000 was a lot more expensive and would cost even more than my X1000 to setup. Offering better firmware and DDR3 but only 200Mhz faster CPU with no vector unit. Guess that's a deal breaker for me in PPC land. Even people buying POWER9 servers when they can buy a cheaper Ryzen desktop that can run Doom are criticising the X5000. Unheard of!
:

@Hypex

Quote:

A Pi with only RTG won't be able to play real Amiga games. Only RTG games and could it do Warp3D? Sure you can emulate AGA but there's already an A500 mini for that.

Why can't it? I see no reason why it cannot play real Amiga games.

Here's the thing. Currently, it's mainly software emulation, for AGA
Could an AGA chipset card, be produced, maybe in FPGA that plugs in for Legacy routines for whtever?
I see why not, but why bother.

The AGA chipset could be established via an [AGA-Chipset.library] if legacy gaming is required or some other subsystem emulation.
Moving to ARM/RISC or subset, is only moving the CPU and if moving platforms, you can also access the on-board GPU etc to what's inside the RISC-SoC if one is there. I/O gets a boost. Memory speed and size. There is so much that can be done if the OS is configured to use it.

There is absolutly no reason why new Amiga computers, in the flavour of A500 all the way to 4000 cannot be designed with expansions, that usher in a new generation of computing, without breaking wallets.

PiStorm is already proving this ground and improves daily.
The only exception to PiStorm in hardware, is that it is hamstrung by the old chipset it plugs into.
Could that chipset be re-designed and improved upon? why not.
Renee Cousins has been doing that in replacements for Agnus and Denise etc on FPGA. Even Vampire modes are being supported.
Vampire is doing more again, however, it still has limitations with I/O in FPGA.

What about mini-mig? Well, I have seen PiStorm running in that too. Replacing the 68k.

So, doing away with legacy isn't a problem, already being done, and software can emulate 99% of all AGA/ECS/OCS why can't a future can be plotted out away from aging chipset slowness and limitations.

As long as it stays a standard, like a legacy library or set of them, in how they are implemented, is not going to end anything. It's not like that AGA/ECS/OCS is changing any time soon, there's no moving yard stick here to try cater for.
PPC anything is not cheap. If it was, it would have survived and people would have bought them but for what you pay to what you get, it's fate was sealed a long time ago.

Personally, I like the emulation sub-system and moving the heck on from the old hardware chipset.
PCIe, heck even USB is a lot faster than any Zorro BUS.
Lets face it, there is a lot faster and better hardware out there than Zorro based stuff now, so I see no point in supporting that interface anymore.
What's left?

Last edited by SHADES on 27-Mar-2023 at 10:23 PM.

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

@SHADES

Quote:

The AGA chipset could be established via an [AGA-Chipset.library] if legacy gaming is required or some other subsystem emulation.

Well, yeh… sure… but chipset does not work like a library it works on writes and reads to addresses, it requires a MMU, and has to be setup before any games run… and because its software, you can never take over the system, already there is a lot of demos and games will break it, because of that.

We have this kind of things in form of Blitzen / NallePuh / ciaagint / libBlitter.library, chipset.library, libCopper.library It’s not at all a new idea, it sort / kind is possible.

A library API will require rewrite of old Software, it might not worth writing using old coding style, it be easier to use what developers chose to ignore that was sometimes already there in the OS. If you chouse to rewrite, you might as well throw out the old code in many cases, it be less work, a lot of code is also not commented. In worst case you need work discompiled assembler, with no proper label names.

Last edited by NutsAboutAmiga on 27-Mar-2023 at 11:05 PM.
Last edited by NutsAboutAmiga on 27-Mar-2023 at 11:00 PM.

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

@NutsAboutAmiga

Quote:

Well, yeh… sure… but chipset does not work like a library it works on writes and reads to addresses, it requires a MMU, and has to be setup before any games run… and because its software, you can never take over the system, already there is a lot of demos and games will break it, because of that. We have this kind of things in form of Blitzen / NallePuh / ciaagint / libBlitter.library, chipset.library, libCopper.library It’s not at all a new idea, it sort / kind is possible.

"Well, yeah" Exactly, it is possible. WinUAE does it via emulation. So, possible!
Adding it in as a subsystem or sandbox emulation for just Legacy gaming could be done, is being done already, not even in AmigaOS. Like Windows or Linux.
It's quite possible, even on a completely alien / unsimilar enviroment.

Quote:

A library API will require rewrite of old Software, it might not worth writing using old coding style, it be easier to use what developers chose to ignore that was sometimes already there in the OS. If chouse to rewrite, you might as well throw out the old code in many cases.

Sure!. Adding in any new features like multi-core etc is also going to require re-writes.
What's going to start all this happening is not on the PPC platform or 68k (Although that somewhat is developing due to software interperation) It needs to be cheap and well supported.
PiStorm or the 68emu for that matter, wouldn't be happening on PPC. As an example of hardware Vs cost. People don't buy-in. No point.

Last edited by SHADES on 27-Mar-2023 at 11:11 PM.
Last edited by SHADES on 27-Mar-2023 at 11:10 PM.
Last edited by SHADES on 27-Mar-2023 at 11:09 PM.
Last edited by SHADES on 27-Mar-2023 at 11:07 PM.
Last edited by SHADES on 27-Mar-2023 at 11:04 PM.

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

@SHADES

UAE is more of full software isolation, method and instructions are excused as sub routines, read and writes are function tables, different routines for different address spaces. It’s not particular efficient but it’s easy to forget that all cores modern CPU’s have, with high clock speeds, mask this kind problem, Amithlon tried cut down on the boilerplate, by cutting out that.

On other hand you take UAE apart and adapt it into libraries, I have been thinking about it, the UAE code pretty good, it has been worked on for many years. Integrating into a OS is a different problem, you need think about different licenses etc.

Last edited by NutsAboutAmiga on 27-Mar-2023 at 11:17 PM.

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

@NutsAboutAmiga

Quote:

AE is more of full software isolation, method and instructions are excused as sub routines, read and writes are function tables, different routines for different address spaces. It’s not particular efficient but it’s easy to forget that all cores modern CPU’s have, with high clock speeds, mask this kind problem, Amithlon tried cut down on the boilerplate, by cutting out that.

Right. So, the need for playing obscure old games and demos, can be implemented to go into that "mode"
It's not like this old stuff is changing. The yard-stick isn't a moving target. This stuff is old and the horsepower is there now, without needing to hamstring everything else along with it.
Multi-core is going to break just as much "stuff"

Quote:

On other hand you take UAE apart and adapt it into libraries, I have been thinking about it, the UAE code pretty good, it has been worked on for many years. Integrating into a OS is a different problem, you need think about different licenses etc.

Ok, licenses hasn't stopped this stuff from being made in the first place but yes, sure, Amiga-land is full of spiders. It's a concern, granted. I'm not sure how library/emulation to implement such a subsystem is going to effect things but to just limit everyting to play an old legacy game or demo is just silly and really not nessacary. It's being done in "alien" OS's already without license breeches as full enviroments, granted.

Last edited by SHADES on 27-Mar-2023 at 11:29 PM.
Last edited by SHADES on 27-Mar-2023 at 11:27 PM.
Last edited by SHADES on 27-Mar-2023 at 11:21 PM.

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

@SHADES

Quote:

Multi-core is going to break just as much "stuff"

(Break the egg, and then duck-tape it.)
Maybe some stuff can be binary patched.

At least until want to go 64bit.

But Win3.11 was 16bit, but did run 32bit code using Win32s..

https://www.youtube.com/watch?v=a5QdUuuLSCM

Not saying that’s a good idea, you have also 64bit OS, running 32bit code.

Last edited by NutsAboutAmiga on 27-Mar-2023 at 11:36 PM.
Last edited by NutsAboutAmiga on 27-Mar-2023 at 11:35 PM.

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

@NutsAboutAmiga

Quote:

True, but maybe some stuff can be binary patched. at least until want to go 64bit. But Win3.11 was 16bit, but did run 32bit code suing Win32s.. https://www.youtube.com/watch?v=a5QdUuuLSCM Not saying that’s a good idea, you have also 64bit OS, running 32bit code.

That was interesting, that 32bit enviroment under 3.11.

32bit under 64bit OS? sure, why not. Windows can. Linux can. Re-write is going to be needed for so much stuff anyway. I/O, multi-core why not (emulated / chipset function calls)
I can run DOS on ARM under emulation. FreeDOS under QEMU if i really want to play Ally Cat or something.

My point was, PPC is too expensive to look at implementing. You could argue, why is ARM any different, however, you can look towards the open-sourcew projects already achieving this to understand, it's really not. If a bedroom coder/hobbiest can do it and then have it sold mainstream, why not start to support this offically. It won't stop, it's gaining traction.
There is your oppertunity to develop and support your Amiga OS product, without the million $ price tag to try get hold of (insert number of old PPC CPU stock) and keep trying to code new OS to it.

Subsystem for legacy can be done now. Re-write for future compute has to happen regardless, but isn't a show-stopper.

Last edited by SHADES on 27-Mar-2023 at 11:51 PM.
Last edited by SHADES on 27-Mar-2023 at 11:50 PM.
Last edited by SHADES on 27-Mar-2023 at 11:50 PM.
Last edited by SHADES on 27-Mar-2023 at 11:45 PM.

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

@SHADES

I wouldn't trivialise the implementation of legacy hardware as a library of some sort. It would almost certainly be better realised as some form of bare metal emulation module - e.g. for PiStorm something that runs on the Pi directly. Ideally this would be as a separate process on a different core than the CPU but this may still be extremely non trivial. I believe much older versions of UAE had a similar mode where chipset emulation could run on a separate core (maybe I'm misremembering) but assuming I'm not senile, there's likely a good reason it wasn't continued.

_________________
Doing stupid things for fun...

@SHADES

Quote:

Why can't it? I see no reason why it cannot play real Amiga games.

Because real Amiga games bang the hardware and won't work on RTG alone.

Quote:

Here's the thing. Currently, it's mainly software emulation, for AGA Could an AGA chipset card, be produced, maybe in FPGA that plugs in for Legacy routines for whtever? I see why not, but why bother.

Sure, it's already been done. FPGA Mister can be configured as Amiga.

Quote:

The AGA chipset could be established via an [AGA-Chipset.library] if legacy gaming is required or some other subsystem emulation. Moving to ARM/RISC or subset, is only moving the CPU and if moving platforms, you can also access the on-board GPU etc to what's inside the RISC-SoC if one is there. I/O gets a boost. Memory speed and size. There is so much that can be done if the OS is configured to use it.

What NutsAboutAmiga said.

Quote:

There is absolutly no reason why new Amiga computers, in the flavour of A500 all the way to 4000 cannot be designed with expansions, that usher in a new generation of computing, without breaking wallets.

Given the popularity of the A500 mini that is possible. Designing a new set of Amiga models would be hard work, yet rewarding, but why risk it?

Quote:

PiStorm is already proving this ground and improves daily. The only exception to PiStorm in hardware, is that it is hamstrung by the old chipset it plugs into. Could that chipset be re-designed and improved upon? why not.

The point of the PiStorm is to plug into the real thing. But that is also a point of contention. Since internally the CPU is emulated.

Quote:

Renee Cousins has been doing that in replacements for Agnus and Denise etc on FPGA. Even Vampire modes are being supported. Vampire is doing more again, however, it still has limitations with I/O in FPGA.

Now that AAA details have been released we can drop SAGA. It can be like AGA was to be treated as a stop gap. So now there can be Andrea, Lisa, Mary and Monica in their place.

Quote:

What about mini-mig? Well, I have seen PiStorm running in that too. Replacing the 68k.

Didn't know that but suppose it's expected. But now I think a Mister and PiStorm could be where it's at.

Quote:

So, doing away with legacy isn't a problem, already being done, and software can emulate 99% of all AGA/ECS/OCS why can't a future can be plotted out away from aging chipset slowness and limitations.

It was done almost 20 years ago. First with Amithlon. Then with OS4 and MOS. But back then people were interested in a souped up Amiga. Now people just want a fast 68K and to play games. Anything above and beyond that they just look at their PC and wonder what the point of doing that with an Amiga is. As if they missed the last 20 years.

Quote:

As long as it stays a standard, like a legacy library or set of them, in how they are implemented, is not going to end anything. It's not like that AGA/ECS/OCS is changing any time soon, there's no moving yard stick here to try cater for. PPC anything is not cheap. If it was, it would have survived and people would have bought them but for what you pay to what you get, it's fate was sealed a long time ago.

ECS has become somewhat the defacto standard. A500 gets more love than AGA. I'm always reading about some A500 port of some DOS game and how it looks so good in 32 colours. Well that's kind of living in the past with the A500 coloured glasses on. AGA can match 256 colour DOS like it was meant to be and with more colour resolution so why not port it to the best Amiga architecture there is and win some for once?

Quote:

Personally, I like the emulation sub-system and moving the heck on from the old hardware chipset. PCIe, heck even USB is a lot faster than any Zorro BUS. Lets face it, there is a lot faster and better hardware out there than Zorro based stuff now, so I see no point in supporting that interface anymore. What's left?

But would the Amiga base accept this? The A500 example gives a clue. 20 years ago an Amiga was full of PC cards. But now RTG and sound cards hasn't caught on like it did in the past. We had RTG games but now I see most Amiga people just want to play ECS or AGA games.

Last edited by Hypex on 28-Mar-2023 at 02:50 PM.

@Karlos

Quote:

I wouldn't trivialise the implementation of legacy hardware as a library of some sort. It would almost certainly be better realised as some form of bare metal emulation module - e.g. for PiStorm something that runs on the Pi directly. Ideally this would be as a separate process on a different core than the CPU but this may still be extremely non trivial. I believe much older versions of UAE had a similar mode where chipset emulation could run on a separate core (maybe I'm misremembering) but assuming I'm not senile, there's likely a good reason it wasn't continued.

Fine. Emulation sandbox, libraries to tie in seamlessly. I mean, Apple did it with Rosetta. No one is saying it's trivial, and neither is multi-core or 64bit.
Limiting the growth of the OS just to OCS/ECS/AGA is dumb.

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

@Hypex

Quote:

Because real Amiga games bang the hardware and won't work on RTG alone.

Irrelevent. Can be done via emulation. 99% of ALL of it.

Quote:

Sure, it's already been done. FPGA Mister can be configured as Amiga.

Answering the first point.

Quote:

What NutsAboutAmiga said.

Ok.

Quote:

Given the popularity of the A500 mini that is possible. Designing a new set of Amiga models would be hard work, yet rewarding, but why risk it?

Why do anything then? Why even make an A500 mini, PiStorm, PiStorm32-Lite, Vampire.

Quote:

The point of the PiStorm is to plug into the real thing. But that is also a point of contention. Since internally the CPU is emulated.

So? The whole need to move away from 68k or PPC isn't going to go anywhere. M1/M2 on Apple do simliar while they "transition" What's the problem.

Quote:

Now that AAA details have been released we can drop SAGA. It can be like AGA was to be treated as a stop gap. So now there can be Andrea, Lisa, Mary and Monica in their place.

That have "zero" software for them. Why bother.
The AAA chipset now would still be the retarding factor in anything new. It's no longer a stop-gap. It's a non-event. Nothing coded for it and not even backward compaitible for your ECS gaming niche.
There is much faster, modern chipsets now. It's really not needed.

Quote:

Didn't know that but suppose it's expected. But now I think a Mister and PiStorm could be where it's at.

It's on YouTube if you search for it. The old stuff has had it's day. The only reason PiStorm is making so much headway is due to the sheer COST of doing anything on PPC. The reason there is such slow development on OS4 is also beacuse, no one is buying the hardware to run it. It's expensive to manufacture and expensive to buy.

Quote:

t was done almost 20 years ago. First with Amithlon. Then with OS4 and MOS. But back then people were interested in a souped up Amiga. Now people just want a fast 68K and to play games. Anything above and beyond that they just look at their PC and wonder what the point of doing that with an Amiga is. As if they missed the last 20 years.

Yeah, the last thing we needed was another souped up Amiga to play games, yet here we are, it's cheap, the OS is getting updates, being sold and people want more. Go figure!
Imagine if PPC was that cheap and easy to work on / design boards for.

Quote:

ECS has become somewhat the defacto standard. A500 gets more love than AGA. I'm always reading about some A500 port of some DOS game and how it looks so good in 32 colours. Well that's kind of living in the past with the A500 coloured glasses on. AGA can match 256 colour DOS like it was meant to be and with more colour resolution so why not port it to the best Amiga architecture there is and win some for once?

Because it's very limited and people obviously want souped up Amigas they can start using again that aren't limited in memory, graphics, I/O etc and can browse the web again. What was that latest Browser software relased that uses a modern PC to do the rednering and then pipe it to the Amiga??
That's why.
It's not winning, that hardware exisits and you can emulate it if you want the ECS experience.
PiStorm is a "wake-up" alarm.

Quote:

But would the Amiga base accept this? The A500 example gives a clue. 20 years ago an Amiga was full of PC cards. But now RTG and sound cards hasn't caught on like it did in the past. We had RTG games but now I see most Amiga people just want to play ECS or AGA games.

That doesn't explain Vampire, PiStorm, Minimig, Morph, Aros or even OS4 now does it.
No, that's just a niche already taken care of.

Last edited by SHADES on 28-Mar-2023 at 10:37 PM.
Last edited by SHADES on 28-Mar-2023 at 09:44 PM.

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

@SHADES

There's zero reason, btw, why you couldn't just use UAE on AmigaOS on a standalone Pi to indulge your legacy gaming needs. Certainly no OS4 users should have a complaint since this is how it works there.

The fact you can also run your Pi as an expansion on a real Amiga satisfies the needs of those that want to have it all, anyway. Personally I'd love to see CPU slot versions of the PiStorm for the A3000 and A4000 so that pretty much every classic Amiga is covered.

The main thing to recognise is the diversity of the 68K users before making projections about how the solution should work. Not everyone wants the same thing.

Some just want to run old games and the mini is probably the best choice for them. People specifically looking for a higher end Pi solution are more varied in their needs:

Users wanting to have a more powerful 68K experience for running older productivity software, coding, etc. A standalone PiStorm using RTG/AHI without chipset emulation (beyond CIA anyway) would be a good fit.

Users wanting to accelerate an existing classic machine that have missed out on the higher end 68060 / Vampire, and/or want to have RTG, networking etc. without sourcing a bunch of expensive and hard to find upgrades. The PiStorm fitted as an expansion board is the best fit there.

Users that want to imagine what the Amiga could've been in its hey dey would likely want something like the Vampire with its enhanced chipset.

Oddballs like me fit all three. I personally would love to have something along the lines suggested by Hans with an FPGA for the "retro chipset of your dreams", PiStorm for the fastest (non UAE) 68K on board, complete with all the productivity benefits of RTG, networking etc, and all of it rammed into a physical Amiga, that I can then tinker with, code away on and run OctaMED like the 90s never ended.

Users that want to push AmigaOS into a 64-bit, memory protected SMP "present day" are a difficult intersection to please. AROS on x64 already covers this to varying degrees but here we are. The same users likely want to have backwards compatibility with the 68K back catalogue. You get increasingly challenging groups within, that want this in a physical Amiga, that want AmigaOS proper to support it and so forth.

Personally, as awesome as a virtual 64-bit 68K multicore CPU sounds, without a seamless 32-bit 68K backwards compatible OS to run on it it's less appealing. So that's a now really big ask that requires the alignment of a lot of disparate groups to make a reality. So that leaves a native AROS on ARM to run on it which then goes back to lacking transparent 68K support.

I'm more than happy with best possible single core 32-bit 68K hardware Amiga experience, so the PiStorm as it is sounds like my best bet for now. I'd very much like to be able to bang the spare ARM metal within it in order to create virtual devices that can be accessed from the Amiga side, though I don't yet know how feasible that will be.

_________________
Doing stupid things for fun...

@Karlos

Quote:

There's zero reason, btw, why you couldn't just use UAE on AmigaOS on a standalone Pi to indulge your legacy gaming needs. Certainly no OS4 users should have a complaint since this is how it works there. The fact you can also run your Pi as an expansion on a real Amiga satisfies the needs of those that want to have it all, anyway. Personally I'd love to see CPU slot versions of the PiStorm for the A3000 and A4000 so that pretty much every classic Amiga is covered.

Very true. Legacy gaming is covered. Both in Hardware (the old Amigas) and new stuff (emulated)
I'd like the same as well. I'm not sure how hard those CPU connectors are to get these days but i'm sure it's in the works. 1200 got done.

Quote:

The main thing to recognise is the diversity of the 68K users before making projections about how the solution should work. Not everyone wants the same thing. Some just want to run old games and the mini is probably the best choice for them. People specifically looking for a higher end Pi solution are more varied in their needs: Users wanting to have a more powerful 68K experience for running older productivity software, coding, etc. A standalone PiStorm using RTG/AHI without chipset emulation (beyond CIA anyway) would be a good fit. Users wanting to accelerate an existing classic machine that have missed out on the higher end 68060 / Vampire, and/or want to have RTG, networking etc. without sourcing a bunch of expensive and hard to find upgrades. The PiStorm fitted as an expansion board is the best fit there. Users that want to imagine what the Amiga could've been in its hey dey would likely want something like the Vampire with its enhanced chipset.

Which is covered. Mini-mig, Vamp etc.

Quote:

Oddballs like me fit all three. I personally would love to have something along the lines suggested by Hans with an FPGA for the "retro chipset of your dreams", PiStorm for the fastest (non UAE) 68K on board, complete with all the productivity benefits of RTG, networking etc, and all of it rammed into a physical Amiga, that I can then tinker with, code away on and run OctaMED like the 90s never ended.

Right. Well, the previous and current form of PPC makes that very expensive and not cost effective.
It also means very little OS development on the newer AMIGA OS. That's why there is no movement. Not a lot of people buy OS4 because to run it in anything not emulated is expensive and always has been. No point. No interest. OS4 stagnates.
Can somewhat be done with interperation and cheap alternative hardware, somewhat, but relies on old platform chipsets or FPGA. Again what for.
If you talk 68k again, you're in enmulation. There are not going to be new 68k chips made. As much as Matthey may argue for it. It's just not needed. There are just as many good-enough alternatives that don't need the multi-millions to go ASIC.

Quote:

Users that want to push AmigaOS into a 64-bit, memory protected SMP "present day" are a difficult intersection to please. AROS on x64 already covers this to varying degrees but here we are. The same users likely want to have backwards compatibility with the 68K back catalogue. You get increasingly challenging groups within, that want this in a physical Amiga, that want AmigaOS proper to support it and so forth. Personally, as awesome as a virtual 64-bit 68K multicore CPU sounds, without a seamless 32-bit 68K backwards compatible OS to run on it it's less appealing. So that's a now really big ask that requires the alignment of a lot of disparate groups to make a reality. So that leaves a native AROS on ARM to run on it which then goes back to lacking transparent 68K support. I'm more than happy with best possible single core 32-bit 68K hardware Amiga experience, so the PiStorm as it is sounds like my best bet for now. I'd very much like to be able to bang the spare ARM metal within it in order to create virtual devices that can be accessed from the Amiga side, though I don't yet know how feasible that will be.

That's the future though isn't it? I don't see CPU instruction going back to single core or less memory or slower speeds, less colours. AOS moved to OS4 away from 68k to a more expensive instruction that does cost millions to design, secure product, create borads, debug, drivers etc..... All of it.
AROS is no different, again, currently not being really developed due to lack of resources and well it's based off 68k.
OS4, is at least looking forward and activly researching and applying effort to progress to multi-core as even it cannot use the multiple PPC cores it was written to however...COST. The PPC platform is just far too obscure and not cost effective to develop, or purchase. It's underpowered for the price and behind.
Users are not going to buy these. It's niche. It can be done better without going to all that expence.
Personally, the effort to go x86 away from PPC is still valid however, as we have seen, development can be done on alternatives to even x86 at lower costs and remain competitive.
Apple did it, Linux has, and PiStorm shows how to do it from your bedroom with 3rd party circuit board manufactures.
Is it OS4?? no.
Currently, development there is 3.1 (ish OS) using 68k which really is only going to stay in emulation. The RISC/xxx platforms have standards, are cheap, even cheaper than x86 and competing with modern abilities.....Efforts to push the OS forward and retain modern function like Emu68 can STILL be supported for that retro experience, wihout sacrifcing the modern OS requiremnts than need to let go of the 68k retro intuition side of things but should be focused on OS4/5 etc with the ability to go EMU68.
PPC.......not so much. It's far too expensive. Even back in the day. I beleive Trevor had to put a few mill down just to secure PPC stock. That's not board development or drivers or coding, just stock. It's not finacially viable. Who wants to pay for those PPC chips to go web browsing under OS4? = very few

If it was a nice Pi 8GB DDR4 and all that comes with it, GPU, PCIe expansion board for other things.....running OS4 multi-core and STILL has EMU68k because, well, you can........well now. Isn't that something.
Can it be done cheap? the boards? yep. already being done.
The OS4-5-6-7....well, that's a different story but why keep pushing for the SAME things on PPC which does cost a small fortune and is extremely difficult to develop for.
Pretty sure Michael got EMU68k running on ARM faster than OS4 got 64bit/multi-core or 68 speed on PPC faster and he's one person. The hardware for it all too, done for like 60 pound.
It's not hard to figure out what's possible and waiting. (all without sacrificing the legacy fun)

Last edited by SHADES on 30-Mar-2023 at 01:18 AM.
Last edited by SHADES on 30-Mar-2023 at 01:16 AM.
Last edited by SHADES on 30-Mar-2023 at 01:09 AM.

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

@Karlos

While your list covers most if not all 68k camps, and like you, there would be people who are interest in multiple options, these are not necessarily mutually exclusive or needing to be all executed right now, in parallel.

Some of these would feed the next, which could then grow and feed the next, all the way up to AROS68k 64-bit on 68k 64-bit vCPU.

Also, I too would love a PiStorm32 for A4000 CPU slot. While I’d happily get an Apollo “Kraken” for it when it eventually comes out, I’d prefer to run a super fast Emu68-based CPU.

_________________
All the way, with 68k

@SHADES

Not time to respond to everything just now, but this caught my eye as there are some misconceptions.

Quote:

That's the future though isn't it? I don't see CPU instruction going back to single core or less memory or slower speeds, less colours. AOS moved to OS4 away from 68k to a more expensive instruction that does cost millions to design, secure product, create borads, debug, drivers etc..... All of it. AROS is no different, again, currently not being really developed due to lack of resources and well it's based off 68k. OS4, is at least looking forward and activly researching and applying effort to progress to multi-core as even it cannot use the multiple PPC cores it was written to however...COST.

It's not the future, it's recent history. Multicore 64-bit processors are totally mainstream for about 15-20 years now?

AmigaOS4 didn't move away from 68K to PowerPC. It moved away from assembler to C. The instruction set that it compiles to is mostly irrelevant in that regard. Every major architectural aspect stemming from the 68K was retained, namely pointers are 32 bit and memory layout is big endian. This is a significant factor in realising the binary backwards compatibility and the interoperability between 68K applications making host OS calls and sharing data structures with the OS.

AROS is not the same. It's not "based off 68k". Since AROS doesn't need to have binary compatibility, it was free to redefine things like pointer size and is not be tied to a particular endianness.

Also it's not stagnant. It's made more progress than OS4 towards the holy grail of modernness: AROS has 64-bit support. It also has SMP support for what, 6 years now? Didn't know? See this video from 6 years ago:

https://youtu.be/kdB1Vc_CbsI

So there. AROS cracked it and runs 64-bit native and has SMP. Why isn't everyone using it already? The answer, as far as I can determine, is that it lacks seamless backwards compatibility with 68K binaries. That's the price of progress. From being the "world's bestest 32-bit single core OS" it's gone to "the world's okayest 64-bit multicore OS". Without seamless 68K binary support it's now just another OS in a vast ocean of esoteric, multiplatform (but especially x64) OSes all of which share the issue of a lack of software to run on them, bar open source ports of software designed for more mainstream OSes.

While AROS has some good Amiga application source ports available, most of the Amiga software in existence is not available as source, much of it was written in assembler or other languages that were vogue in its heydey but are lost in time now. All we have are the binaries.

This is (part of) the dilemma for OS4. Going 64-bit is difficult because it compromises the interoperability it has with 32-bit application code it has now: those applications share data structures with the OS. Those data structures contain 32-bit pointers. It is possible to run 32-bit code on 64-bit OSes as you can see elsewhere but generally those OSes don't share data structures with applications that way and they also have better process isolation and memory management to allow every 32-bit process to see an address space that looks 32-bit to the application but in reality can be mapped anywhere the OS wants in the 64 bit space.

Going SMP (regardless of 64-bit) is probably a simpler prospect but again comes with complications, in particular things like IPC, interrupts, locking etc. and again the fact that some of these things are arbitrated by mechanisms that are directly shared with the application code, in particular for applications that exist only as binaries and can't be recompiled to some newer standard.

If you want a modern 64-bit SMP AmigaOS experience for the PiStorm, AROS exists. It may not support ARM for this yet (I honestly don't know) but I'm sure it could be ported. After all, like OS4, AROS is written C.

_________________
Doing stupid things for fun...

@Karlos

Quote:

It's not the future, it's recent history. Multicore 64-bit processors are totally mainstream for about 15-20 years now?

I think we are agreeing here?? i'm not sure your point.
Yes, core cpu counts are continuing to climb, big littlle etc. Good???
It's not going to go backwards, that was my point.
AOS4 wasn't able to use even the cores on PPC that it was written for in OS4. Although, that is changing, it's a very expensive arcitecture to be trying to do that on.
The future for any OS is being able to utilize that effectively. That means cost as well. No one is interested in multi-core PPC if it's north of 500 pounds, just to do it or run a browser.

Quote:

AmigaOS4 didn't move away from 68K to PowerPC. It moved away from assembler to C. The instruction set that it compiles to is mostly irrelevant in that regard. Every major architectural aspect stemming from the 68K was retained, namely pointers are 32 bit and memory layout is big endian. This is a significant factor in realising the binary backwards compatibility and the interoperability between 68K applications making host OS calls and sharing data structures with the OS. AROS is not the same. It's not "based off 68k". Since AROS doesn't need to have binary compatibility, it was free to redefine things like pointer size and is not be tied to a particular endianness. Also it's not stagnant. It's made more progress than OS4 towards the holy grail of modernness: AROS has 64-bit support. It also has SMP support for what, 6 years now? Didn't know? See this video from 6 years ago:

Very very slow progress. Why?
Cost.
Why is OS3.x making strides suddenly? Why is there an interest to provide very SOUPED up AMIGAs?
Cost.
Great! AROS is slowly making progress with multi-core and x64 like OS4.

The problem with the x86 platform is the sheer ammount of chipsets to cater for and different designs.
That yard-stick is always moving and what was once supported, is no longer used. This bumps up cost needing resources to hardware that isn't free to write drivers for.

In part, this was the same for PPC as well, albeit, also with an underused instruction set and purchase cost.

For PiStorm, the standard, remained and wasn't changing to run on a multitude of designs. Vampire, well, it is self-changing being FPGA so, it's not a deal breaker but even it to, has unchanging standards so, less prressure in programming and tool chains or board development.

Quote:

lso it's not stagnant. It's made more progress than OS4 towards the holy grail of modernness: AROS has 64-bit support. It also has SMP support for what, 6 years now? Didn't know? See this video from 6 years ago: https://youtu.be/kdB1Vc_CbsI

Yes, I did know, that's true. I've tried it. It's not very stable. Maybe it's time for a revisit. I beleive OS4 is making further headwind now however, well, all of the above.

Quote:

So there. AROS cracked it and runs 64-bit native and has SMP. Why isn't everyone using it already? The answer, as far as I can determine, is that it lacks seamless backwards compatibility with 68K binaries. That's the price of progress. From being the "world's bestest 32-bit single core OS" it's gone to "the world's okayest 64-bit multicore OS". Without seamless 68K binary support it's now just another OS in a vast ocean of esoteric, multiplatform (but especially x64) OSes all of which share the issue of a lack of software to run on them, bar open source ports of software designed for more mainstream OSes. While AROS has some good Amiga application source ports available, most of the Amiga software in existence is not available as source, much of it was written in assembler or other languages that were vogue in its heydey but are lost in time now. All we have are the binaries. This is (part of) the dilemma for OS4. Going 64-bit is difficult because it compromises the interoperability it has with 32-bit application code it has now: those applications share data structures with the OS. Those data structures contain 32-bit pointers. It is possible to run 32-bit code on 64-bit OSes as you can see elsewhere but generally those OSes don't share data structures with applications that way and they also have better process isolation and memory management to allow every 32-bit process to see an address space that looks 32-bit to the application but in reality can be mapped anywhere the OS wants in the 64 bit space. Going SMP (regardless of 64-bit) is probably a simpler prospect but again comes with complications, in particular things like IPC, interrupts, locking etc. and again the fact that some of these things are arbitrated by mechanisms that are directly shared with the application code, in particular for applications that exist only as binaries and can't be recompiled to some newer standard. If you want a modern 64-bit SMP AmigaOS experience for the PiStorm, AROS exists. It may not support ARM for this yet (I honestly don't know) but I'm sure it could be ported. After all, like OS4, AROS is written C.

Maybe. It has been a while since I tried the x86 smp varient however, it wasn't stable in my VM.
As for real hardware, x86 yard stick is a lot to code for unless you stick with VM and then, well, it's almost emulation isn't it. VMWare ran't going to make drivers for you either. Virtualbox and ICH6 or PIIX3 ish?
Having a built in single core emulation envriroment for legacy is doable. 32bit apps all run under Linux Windows. Pointers for 32 can all be (semi-retained) for compatibility with new modes using additional pointers for above if really required. Will some stuff break, sure, unless sandboxed.

As for 64bit PiStorm, that's not the point, it's emulation. There is no real 64bit 68k to code for, maybe some Vampire modes but zero software.
No, i'm talking about how CHEAPLY a new series of AMIGA computers can be realised. Even a bedroom coder can produce a better product, cheaply.

If AOS was written to take advantage of a hardware base that's standard and devleop that way, incorperate EMU68 as library function for legacy subsystem, it wouldn't matter if it's running under Linux via musashi or AOS4 using musashi (clearly banging the hardware is faster) but allowing scope to tie-in function calls for this "space/sandbox" with drivers written to share common data like clipboard, mouse etc
I am talking "future" AOS4+ as the base on cheap, modern hardware. Doable for market, and customer. Maybe that will be AROS??? It's not currently.

500 or 3k pound hardware for AOS4 is not the way. Millions of pounds to secure PPC CPU for boards is not the way. PiStorm wouldn't have even been born with these costs. Why keep trying to force that issue.
I already conceeded x86 would still be a better platform than PPC however, cheap x86 hardware in a standard that is modern and useable is not cheap, has problems due to IP etc to try code for any dev board.

Last edited by SHADES on 30-Mar-2023 at 09:46 PM.
Last edited by SHADES on 30-Mar-2023 at 09:45 PM.

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

Yet another thread that has wandered off topic.

@Hypex

Quote:

Hypex wrote: @NutsAboutAmiga I never towered my Amiga. I only towered my drives. And the tower was rather ugly since it would have been based of a common PC case at the time. The XE was slightly on par with an eMac at the time. Just slightly more expensive for a full setup. I don't think I had any PC at the time and certainly not the latest. The only PC desktops I've had are hand me downs. But I wouldn't compare an XE to a PC as you can't make a direct comparison and Apple were still producing PPC Macs so I would compare to that. I could have got my G4 module fixed. Not ACube then but may be Thendic France going from memory. However I just thought it would be too expensive and IIRC it wouldn't be any faster but same as what I had. I would end up paying a lot of money for a card repair that didn't even upgrade it. Which tends to happen when you break things. One thing I know of personally is how PPC CPUs do not do well with heat. Maybe it is the setup of the CPU module, I don't know for sure, but when my new XE was sitting there idling with UBoot the fan suddenly broke loose. And the CPU immediately overheated. I don't know why but on Intel and AMD these things just work. The PPC appears to have no concept of thermal shutdown at all even when it just running firmware code and not being pushed. This would add to the reasons why people have said in the past how PPC is crap CPU. Though I mostly didn't see any reasons and just trash talk but an expensive CPU not protecting itself from harm is a bad CPU. What I do know for sure the fan setup was bad and plastic screws aren't good on a CPU fan! So a cheaper x86 is just more professional on any design you see. I mean, they have rods on a drawbridge holding it down. Fancy! The X1000 wasn't too expensive for me but I did buy a beta board to keep the cost down. Maybe slightly more than my XE cost me but at least it was better and more powerful over all and just really only let down by slow buggy firmware. Which ironically caused UBoot to reverse it's pop position and put UBoot in a popular light. Last I checked the X5000 was a lot more expensive and would cost even more than my X1000 to setup. Offering better firmware and DDR3 but only 200Mhz faster CPU with no vector unit. Guess that's a deal breaker for me in PPC land. Even people buying POWER9 servers when they can buy a cheaper Ryzen desktop that can run Doom are criticising the X5000. Unheard of! :

AMD wants to avoid another Tomshardware fire starter K7 Athlon PR debacle.

https://www.youtube.com/watch?v=C8hQKHq81hM
Tom's Hardware Archive, How Modern Processors Cope With Heat Emergencies

AMD K7 Athlon 1400 Mhz with VIA KT133A chipset = fail, CPU and motherboard up in smoke.
AMD K7 Athlon MP with VIA KT266 chipset = fail. CPU is up in smoke.

Intel Pentium IV 2000 Mhz with Intel 850 chipset = CPU survives.
Intel Pentium III 1000 Mhz with Intel 815 chipset = CPU survives.
Overheat protection is a feature.

Last edited by Hammer on 31-Mar-2023 at 11:32 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)

@Karlos

Quote:

Karlos wrote: @NutsAboutAmiga Look at all the other CPUs NASA use before trying to suggest that it paints PPC in a positive light. It doesn't. The stuff they still use is ancient. They use it because it's available in radiation hardened, ultra durable packages and that's the only reason they use it. The RAD750 for example is basically a G3 clocked up to 200MHz which puts it on par with the 603e, performance wise. This part makes perfect sense when going into the CRP shooting gallery beyond earth's protective atmosphere and magnetosphere. You don't need to calculate stuff that fast but you do need your calculations to be correct and not stuffed up by bit flipping events.

FYI, Space X's Falcon 9 has 3 dual-core x86 processors running an instance of Linux on each core. The flight software is written in C/C++ and runs in the x86 environment.

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