@Kronos

My original point was and still is: whatever standard we use for one, applies to the other.

Ergo, if the Apollo Team is a failure, so too is A-EON.

But since there are multiple standards by which we can measure, and when we measure both with all the various standards, the Apollo Team comes out on top.

They’ve sold more units, they’ve released more SKUs, they’ve shipped within reasonable and acceptable timeframes, they communicate better with the market, they have more engagement, they are actually profitable.

Last edited by agami on 01-Nov-2023 at 01:59 PM.

_________________
All the way, with 68k

@agami

I'm all for improved custom chipset funkiness if it's neatly backwards compatible, but it it's just adding basic chunky pixel/RTG support it seems like it's already well catered for with PiStorm.

_________________
Doing stupid things for fun...

@matthey

Quote:

matthey wrote: cdimauro Quote: I know it, but why to repeat the same mistakes which Commodore and Vampire engineer have made? Since there's no software written, the AGA chipset could be expanded in a different way. For example, virtualizing the old register set and providing a brand new set of 32-bit registers which have a clean design and that are already open for future enhancements WITHOUT requiring horrible patches every time. If you recall it, I've already defined all details more than 10 years ago on Olaf's Amiga forum. Unfortunately he closed it and everything is lost now (I had not even the time to make a copy of such threads). An example, taking the 16 voices of SAGA that you've talked about. This was made by simply copying 4 times the Audio registers from Paula and with another horrible patch for extending the length of the samples. My design, instead, defined 64 voices (but you don't have to implement all of them: only a subset can be added on first versions, and more to be added in subsequent ones) where the 4 original audio channels are mapped on 4 new channels of the new audio subsystem, all of them using 32-bit registers for holding the settings WITHOUT using bits randomly where they are free. Interrupts generated by the audio subsystem are grouped in 4 "macro channels", with additional registers used to signal which audio channels of the specific group have played all samples (and need to be set again). Abandoning completely the support for 16-bit systems then 128 voices could be added (e.g.: 32 voices for each "macro channel group"). I'v made something similar for each Amiga subsystem (display with multiple playfields, sprites, big colour palettes, packed/chunky, Load-registers-DMA, and I think more). There are different options which are not always right or wrong. I'm not a hardware expert and I don't know what would be the best for hardware register compatibility. It would be best to talk to experts and try to form a consensus but a conservative route is likely better for retro appeal marketing.

Better is to stick to the existing platforms (OCS/ECS, AGA). Because talking with some experts you know what can happen.
Quote:

cdimauro Quote: But they're running Linux: a monolithic mammoth. Yet it is more competitive for the desktop than the AmigaOS. There are other kernel options as well. The macOS uses a hybrid kernel and provides standardization that Linux lacks. Yes, it has more BSD influence than Linux but they both have Unix roots.

Google's FucsiaOS could be a better candidate.
Quote:

cdimauro Quote: Yes, but only this. More MMU support can be provided for new Amiga software just not old Amiga software. For better security, old software could be selectively restricted from executing. It sounds crazy to talk about a significant amount of new 68k Amiga software but I'm talking about mass produced affordable hardware which should spur development.

Well, talking about new applications is a completely different thing, of course.

Unfortunately now we've only the old ones, with all those problems.
Quote:

cdimauro Quote: You can use it for protecting code and data, but then the memory granularity increases a lot and becomes aligned to the MMU pages size, wasting a lot of memory (which isn't good on a system which can address only 2GB of memory). Plus, it can lead to incompatibilities (since everything is shared on the Amiga o.s. address space). Yes, MMU use significantly increases memory requirements. Adding full AmigaOS MMU use is difficult and bad for compatibility as AmigaOS 4 found. Perhaps optional and modular partial MMU use is an acceptable compromise for small footprint systems?

It depends on what do you mean with "partial MMU". Could you please elaborate more?
Quote:

cdimauro Quote: That's totally against the Amiga o.s. foundation and cannot be achieved. Unless you want to drop the compatibility. But then you've other, much bigger, problems. I believe ARIX launches each program in an isolated process, albeit Linux process underneath AROS code. The lack of code and memory sharing is not only good for security but also allows other CPU cores to be used since the sharing is a problem for SMP as well. It uses more memory than sharing and inter process communication is not possible but the small size of the AmigaOS reduces the overhead. Sometimes it would be nice to sand box programs which are known to mis-behave.

That's what deadwood already did with its AxRuntime. Maybe you could give it a look / try.
Quote:

Perhaps a poor man's hardware virtualization without the overhead of twin pointers on every memory access is possible?

Well, the twin pointers isn't a full solution, in each case, since it works only with simple data structures.
Quote:

cdimauro Quote: This is possibly only for games which had / require no o.s. interaction, where WHDLoad has full control of what they are doing (basically the games only take care of hitting the hardware registers for the business logic. All I/O stuff is delegated to WHDLoad). A good part of them should work like that, but others will be problematic (e.g.: some jump to the Kickstart, for example). Anyway, isolating such processes when running isn't an easy task. WHDLoad is already providing some process isolation. An MMU may be able to improve the isolation.

It uses the MMU if it's found and it can be used for the specific game.

Anyway, WHDLoad is for games (and demos), so something which runs alone and takes the entire system, so isolating their execution could be feasible.
Quote:

A single chip SoC is a big advantage especially in the era of de-globalization and common supply disruptions. On chip flash would be nice but there are some disadvantages. The cheapest flash memory only works down to a certain chip process node. There are alternatives but they are more expensive and have disadvantages as well. Joseph Quote: If you want to talk about hard to get it is the $5 pi Zero. They did say this was a newer process so maybe they can’t get the other stuff themselves? The RP2040 uses a very low power design but only has dual Arm Cortex-M0+ CPU cores at 133MHz. The Raspberry Pi Zero uses a single core ARM1176JZF-S at 1 GHz and the new RPi Zero 2 W uses a 4 core Cortex-A53 at 1 GHz. The RPi Zero isn't completely replaced by the Zero 2 W because the former is $5-$10 and the latter is $15. They both have only 512MiB of memory limiting them in some cases to the Thumb2 ISA instead of AArch64 ISA to save memory. Right here is your sweet spot in demand and where I believe a 68k Amiga SoC would be best placed. The 4x64 bit cores of the Cortex-A53 are unnecessary and inefficient use of transistors while in-order RISC CPU cores offer underwhelming performance. If transistors didn't matter, the successors to the Cortex-A53 would be used instead but it is the smallest AArch64 core and remains popular.

An 1Ghz 68060 requires a redesign, because it should be adapted to the new processes.

However the primary problem is: would Motorola/Freescale/NXP provide the 68060's schematics / RTL? This is the showstopper. Same for 68000 and 68020.

If this is unblocked, the next one is: who'll do this redesign work?

So, in general I think that a SoC like what you like to have is blocked by missing the required IPs / licenses for the needed components (CPU, chipset). Secondary, it's blocked by the lack of engineers expert on this field.

But assuming that you had both, IMO you should start with some simple project for the first SoC. Which means focusing on games, primarily.

Games require perfect hardware compatibility, so this SoC should be able to boot in tre different "execution modes":
1) 68000@7Mhz + OCS/ECS chipset + 2MB Chip Mem + 8MB Fast Mem + 1.5MB Slow RAM;
2) 68EC020@14Mhz + AGA chipset + 2MB Chip Mem + 8MB Fast Mem;
3) 68060@MAXIMUM_POSSIBLE_MHZ + AGA chipset + 2MB Chip Mem + 8MB Fast Mem + 128MB RTG + 512MB 32-bit Fast Mem.

The last is for o.s. / applications.

If the project is selling good, THEN you can think about extending it.

@ppcamiga1

Quote:

ppcamiga1 wrote: vampire failed

STRA-LOL. If vampire "failed" with more than 10k products sold, then tell me about your beloved AmigaNOne which are much less than that: how do you define it? Different kind of success?
Quote:

bacause - it has not mmu even simple zero page protection

Well, your belowed (Under)Power(ed)PCs have the MMU but its barely used.
Quote:

- it has not 3D

It has it.
Quote:

- it has not compatible FPU

MEGA-LOL.

Please, tell me about the A1222's FPU.

But even taking a standard (Under)Power(ed)PC, are you able to run ALL 68k software which is using the FPU?
Quote:

all this shoud be in vampire v2 instead of useless AGA and AMMX. people should not be forced to buy v4 for it

In fact you're not: can still keep the v2.
Quote:

ppcamiga1 wrote: New amiga retro hardware should be ECS and somethign better for 2D/3D in parallel to ECS. Amiga retro fans should use ECS for old things. Play games on it, use DP PT etc on it. Use ECS for everything that was made on Amiga up to spring 1993. For never games and apps use something better for graphics in parallel to ECS. 2D is 3D without one D. So if You have 3D You may use it as well in 2D. New amiga retro hardware should have some easy to use basic 3D. zbuffer, perspective correction 640x480 25 fps. no more. New amiga retro hardware should be made in way that

And entered again the PARROT MODE...
Quote:

it may be used as graphics card in Amiga NG.

AmigaNoWhere, not NG: there's NOTHING "NG" on you CrapPowerPCs.
Quote:

so everybody will use it.

Everybody? How many? Less than the number of Vampires sold...


@kolla

Quote:

kolla wrote: I just want “turbo AGA”, compatible with existing AGA software, only faster.

Which software? I assume not games: they should work as they are (besides loading them from an HD).

@cdimauro

Quote:

Which software? I assume not games: they should work as they are (besides loading them from an HD).

I would love to see some games being fully used, games like stunt car racer, elite, gunship 2000...to play locked at 50/60fps, we already have hardware more then capable, the problem is that it would be needed to tweak the code of the games themselves

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@pixie

Quote:

pixie wrote: @cdimauro Quote: Which software? I assume not games: they should work as they are (besides loading them from an HD). I would love to see some games being fully used, games like stunt car racer, elite, gunship 2000...to play locked at 50/60fps, we already have hardware more then capable, the problem is that it would be needed to tweak the code of the games themselves

OK, for those it makes sense... as long as the game's business logic isn't accelerated as well.

@Karlos

Quote:

Karlos wrote: @kolla Isn't that what the Vampire is for?

Not much, SAGA has been more about adding new stuff.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Sure, but does the new stuff not include basic bandwidth expansion ?

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @kolla Sure, but does the new stuff not include basic bandwidth expansion ?

Of course it does. As usual, he’s being pedantic.

_________________
All the way, with 68k

@agami

Quote:

Of course it does. As usual, he’s being pedantic.

Please... don't poke the bear! :P

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@matthey

Quote:

The Pentium FPU is fully pipelined but not superscalar. The 68060 FPU is superscalar but not fully pipelined. https://en.wikipedia.org/wiki/Motorola_68060#Architecture Quote: Against the Pentium, the 68060 can perform better on mixed code; Pentium's decoder cannot issue an FP instruction every opportunity and hence the FPU is not superscalar as the ALUs were. If the 68060's non-pipelined FPU can accept an instruction, it can be issued one by the decoder. This means that optimizing for the 68060 is easier: no rules prevent FP instructions from being issued whenever was convenient for the programmer other than well understood instruction latencies. However, with properly optimized and scheduled code, the Pentium's FPU is capable of double the clock for clock throughput of the 68060's FPU.

1. Pentium FPU's FDIV runs concurrently with non-dependent FADD or FMUL instructions. It has limited out-of-order processing. PC's Quake exploits this feature.

2. 68060 has the old 68040's 32-bit front-side bus while Pentium has a 64-bit front-side bus.

Pentium's 64-bit FSB matches FP64 and dual INT32 bandwidth requirements. Pentium Overdrive for 486's 32-bit front side bus wasn't optimal.

3. Pipelining enables "instructions in flight" parallelism.

Q1 1997's Pentium MMX's FPU has the improved 1 IPC and 64-bit integer SIMD (pack math).
There's no need for PA-RISC MAX SIMD.

AMD's 3DNow 64bit SIMD FP was released in 1998.

4. My motherboard's Intel 430VX chipset is cache coherent competency with 512 KB L2 cache.


Quote:

The Pentium FPU has the edge in performance but the 68060 is not as far behind as theoretical performance suggests. Easier optimizing is very important, applies to the 68060 in general and is special for an in-order CPU. The vbcc support code I worked on allowed a vbcc compiled ByteMark floating point benchmark to nearly achieve the same per MHz performance. Since most floating point code is mixed code, an improved integer vbcc backend and/or instruction scheduler could allow the 68060 to outperform the Pentium. That won't happen with an emulated 68k Amiga platform of course. Vbcc's Dr. Volker Barthelman and Frank Wille are Amiga fans but emulation indicates a dead platform and not a compiler target.

Prove it with 68060 Rev 6 @ 100 Mhz OC Quake benchmark beating or matching Pentium 100 Mhz.

Amiga's core audience is gaming.

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

@Kronos

Quote:

Kronos wrote: @matthey Goalposts, goalpost a forest of goalposts -rPI So after selling millions of tinker level HW each year they are now at a point where they can license some IP and have a custom IC made. Far cry from someone (like C= in the 90s) trying to build maintain their own IP from the bottom up (based an flawed legacy tech and with SW relying on that flawed legacy tech). - 1GHz 68060 Now this needs to be sperated: - alternate history Moto/FreeScale/... trying to do that for a 2000 release to compete with Pentium3 and Athlon.

1 Ghz 68060?

K7 Athlon has out-of-order processing with three-way x86 decoders, branch prediction, three pipelined ALU, three pipeline AGU, three pipelined FADD/MMX/3DNow, FMUL/MMX/3DNow, FStore. K7 Athlon's FSB EV6 is a DDR 64-bit bus.

K7 Athlon is designed to win the 1 GHz race.

64-bit 100 Mhz DDR (266 MT/s) has 2.1 GB/s front-side bandwidth.

68060's I/O wasn't designed with 1 Ghz CPU core with 266 MT/s front side bus.

68060 would need I/O and front-end upgrades since memory performance in the year 2000 wasn't 1 GHz or 1 GT/s.

1 Ghz 68060 is in dreamland.

Last edited by Hammer on 01-Jan-2024 at 02:11 PM.
Last edited by Hammer on 01-Jan-2024 at 02:01 PM.

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

@pixie

Quote:

pixie wrote: @NutsAboutAmiga But how can I trust these values when there's no Quake running standalone RPI on EMU68? Besides, all these values you have in one side RTG using gfx acceleration and the using only CPU. I'm also wondering on why OS4 needs such beafy setup. As long as you have a gfx accceleration supported which apps exactly need that amazing power. Quake on a RPI4 09/2023 320x240 - 92.1 FPS 640x480 - 47.2 FPS Then we have RPI 5 is 2–3× the speed of 4, at 60$. Still it isn't know if it is possible to use it with pistorm due to latency, and there's a new gfx chip also, still if it could be used standalone those values would surely go way higher. I guess it would have power enough to beat a SAM

Unlike PiStorm, SAM460 is a standalone FlexATX desktop computer that has no hardware access to the classic Amiga chipset e.g. running Deluxe Music 2 68K.

Running UAE on AmigaOS 4.1 opens the competition from PCs running WinUAE e.g. I have Zen 4 PBO max for WinUAE.

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

@ppcamiga1

Quote:

ppcamiga1 wrote: vampire failed bacause - it has not mmu even simple zero page protection - it has not 3D - it has not compatible FPU all this shoud be in vampire v2 instead of useless AGA and AMMX. people should not be forced to buy v4 for it

1. Apollo 68080 has an MMU, you can enable Memory Protection with the "Apollo-Shield" utility
You can find this utility on the ApolloOS distro. The 68080's MMU is different from Motorola's 68K MMUs, hence it's useless for legacy Amiga 68K MMU software and Linux 68K.

I managed to get my hands on the ApolloOS distro and poked around.

AmigaOS 4.1's 68K emulator is only userland 68K while MMU functions are provided by PowerPC's MMU.

2. Apollo's V4 has Maggie 3D, but it's useless for legacy Amiga Warp3D/OpenGL. Gunnar claimed OpenGL is on the roadmap.

3. 68080 V4 has 68K FP64. Both 68080 V2 and V4 FPUs can run Quake's FPU requirements.

If it's good enough for AMD's 3DNow (double-pack single-precision FP32) and Intel SSE's FP32 and SSE2/AVX's FP64, it's good enough for 68080.

Intel SSE's and AVX's precision scales up to FP64. FP80 is outside of SSE and AVX.

I'm aware of IBM Power 9's IEEE 754 quadruple-precision binary floating-point format which has its niche use case.

The NEC Vector Engine architecture PCIe card supports adding, subtracting, multiplying, and comparing 128-bit binary IEEE 754 quadruple-precision numbers.

Last edited by Hammer on 05-Jan-2024 at 05:27 AM.
Last edited by Hammer on 05-Jan-2024 at 05:16 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

Quote:

AmigaOS 4.1's 68K emulator is only userland 68K while MMU functions are provided by PowerPC's MMU.

There is no kernel land, or user land concept, 68K can be executed in forbid state, true you can’t bang hardware, if its not emulated.

NallePuh that can emulate some hardware need multitasking, as it’s a program, but even NallePuh can run MMU exceptions in Forbid state, its technically possible, but not practical possible, how do you estimate time without using Amiga library, bang the AmigaONE hardware bios clock?? Well perhaps.

The greater problem is that, on AmigaOS4 system, a program can’t just dump memory to file, or do what ever it wants, it must allocate memory, and be kind of system friendly. Even in forbid.

But as soon as you stay in forbid state your USB stack stops working, so you will have no keyboard. You Network stack will stop working, and sound won’t work, as you need AHI drivers etc.

The idea that you want to take over the computer, is just idiotic, as you won’t be able to use any drivers. And with all different hardware addons it becomes a nightmare.

Last edited by NutsAboutAmiga on 05-Jan-2024 at 09:21 PM.
Last edited by NutsAboutAmiga on 05-Jan-2024 at 09:16 PM.

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

@Hammer

The problem with 68080 FPU is that it causes rounding errors with legacy Amiga software, so 1.5 * 3 may end not being the same as 15*3/10, etc. Not a problem with Quake (which wasn’t a legacy Amiga game to begin with), but damn annoying whith just about anything else.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

It's a QPU, not an FPU, eh?

_________________
Doing stupid things for fun...

@poll

Quote:

agami wrote: I hope to hear about the future plans and progress for MorphOS before 2023 is done.

A week into 2024 and I see my late 2023 hopes for a MorphOS plan update have been dashed.
In my lament, I reflected on the poll results to date:

- A small contingent of respondents, fewer than 10%, a.k.a a small minority, are Not interested in Emulation, and I have a feeling that @ppcamiga1 voted about 6 times for this option.
- Over 50% are interested in running AmigaOS 4 in emulation, ~10% of which already run AOS4 in emulation of some form.
- Which is to say, only a minority of Amigans potentially interested in AmigaOS 4 care about the hardware upon which it is running.

Something:
- for Hyperion and A-EON to seriously evaluate, and
- which does not bode well for @ppcamiga1 and his ilk

_________________
All the way, with 68k

@agami

I'm not interested in using year 2000 level os on commodity hardware
simply because everything may be done many times faster on decent os
on exactly the same hardware
it is rational

@ppcamiga1

Hence your PowerPC "Amiga" is running Linux?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC