@ppcamiga1

And here we have the SoundByte X9000 chiming in with random words.

Vampire failed?
By whatever measure the Apollo Team is considered a failure with their Apollo range of FPGA-based accelerators and Standalone 080 + SAGA devices, then by the same measure A-EON is also failure with their range of non-upgradable PPC-based line of computers and system boards.

The Apollo team has sold more V2 + V4 devices than A-EON and Eyetech (combined) have sold PPC systems for AmigaOS 4.

Nobody was forced to buy anything. Though I’m sure the fascist in you would like to force everyone to buy a PPC-based AmigaOS 4 + Enhancer 2 compatible computer.

Commodore failed because they released ECS in 1990 instead of 1988.

_________________
All the way, with 68k

@Karlos

Quote:

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

According to some, a computer is only as good as can be used to feel superior and lord over others.

The V2 and V4 series of 080 + SAGA retroputers do very little to confir status. Worthy only of the disapproval which parents have for wayward children.

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

_________________
All the way, with 68k

@agami

Quote:

agami wrote: Vampire failed? By whatever measure the Apollo Team is considered a failure

I'd say we use their own words/plans as "measure" .... oh boy.

Pointing out that the failed a bit less than a total s##tshow is pretty much admitting that they failed even in your eyes.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Missing a target in some original plan, does not a failure make.

Sony may “fail” to release a game by some pre-announced date. That does not make SONY, nor the game in question, a “failure”.

_________________
All the way, with 68k

@agami

No idea what you are talking bout, but at least one Apollo team member (leader) had made statements over a long period of time that were and still are outright delusional.

You know like the "on schedule and rocking","2 more weeks" kinda obvious BS swallowed wholesale by the gullible parts parts of the community a decade before.

By those claims they have failed and anything but a failure was never even a possibility.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@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