Apollo Maggie 3D Chip - Preview Demo

[Bruce Abbott]

Originally Posted by Gorf

I would have thought this would be the least complex part of the design in this case. Wherein does the complexity lie with SAGA (by modern standards)?

By 'modern standards' the most complex parts are generally preexisting IP that needs very little effort to get going. In contrast, SAGA combines the original Amiga AGA chipset with enhanced features like 8bit and 16bit Chunky, ATARI and NEO-GEO screenmodes etc. and now a proprietary 3D system. That makes it more complex to implement than just bolting on an ARM CPU, SD-RAM or HDMI controller etc., and much more likely to have to go through several revisions before becoming stable enough to put into an ASIC.

The same may be true of the 68080 CPU, but that's another topic (and I didn't say SAGA was the most complex part of the Apollo chipset).

So I guess a batch of 10k board would be sold rather quickly - I would buy two or three.

As might many of us if it was cheap enough. But would you buy another 3 boards in 6 month's time, when they spin up another revision to fix all the bugs?

Realistically I doubt we will see a GHz speed Apollo ASIC anytime soon, but it's nice to dream. My dream is a low power ASIC chipset to replace AGA for reproductions of classic machines (that are now becoming ridiculously expensive and scarce due to being gobbled up by rich hoarders).

[paraj]

Originally Posted by Bruce Abbott

My dream is a low power ASIC chipset to replace AGA for reproductions of classic machines (that are now becoming ridiculously expensive and scarce due to being gobbled up by rich hoarders).

Curious what you envision here. AGA compatible custom chips as ASIC and everything else sourced as NOS or something else?

[BeamCoder]

Originally Posted by Bruce Abbott

Realistically I doubt we will see a GHz speed Apollo ASIC anytime soon, but it's nice to dream. My dream is a low power ASIC chipset to replace AGA for reproductions of classic machines (that are now becoming ridiculously expensive and scarce due to being gobbled up by rich hoarders).

For AGA, maybe it's not far fetched. For example, somebody could use the Minimig AGA as a starting point to implement an ASIC by joining the OpenMPW program https://platform.efabless.com/open_shuttle_program/

A lot of projects have tried the program already which can be viewed on the site.

Sprite generator: https://platform.efabless.com/projects/1

[Gorf]

Originally Posted by Bruce Abbott

By 'modern standards' the most complex parts are generally preexisting IP that needs very little effort to get going. In contrast, SAGA combines the original Amiga AGA chipset with enhanced features like 8bit and 16bit Chunky, ATARI and NEO-GEO screenmodes etc. and now a proprietary 3D system.

While this is surely all a masterful accomplishment by the Apollo team, it strikes me not more complex in as many "basic" gpu cores that others combine with e.g. ARM or RISC-V cores in their ASIC.

And modern synthesis tools are able to simulate all relevant timings and layouts before the first mask is done. (Assuming the persons involved know what they do.)

But maybe there is some hidden complexity I am not aware of in this case ...

My dream is a low power ASIC chipset to replace AGA for reproductions of classic machines (that are now becoming ridiculously expensive and scarce due to being gobbled up by rich hoarders).

Something like this would also be a nice gfx+sound-expansion for:
https://rosco-m68k.com

Or on a little addon board for the RasPi to have a "Reverse PiStorm"

[lmimmfn]

Ì think it's pointless implenting this in the FPGA.
It's time they supported delegating to an arm processor, they're he'll bent on implementing everything in the fpga that it makes no reasonable sense.

[grelbfarlk]

Originally Posted by grond

grelbfarlk knew this, of course, and you fell for it.

I beg to differ, because in the OP, it states clearly: "the new exciting Apollo Maggie 3D chip added to the already impressive ApolloSAGA chipset."


There is a new chip added to the chipset. A chipset as we understand it in the Amiga world as a grouping of chips. With ECS we would say a set of chips is Denise, Agnus and maybe Buster. With AGA we would say that set of chips is Alice, Lisa and Gary and maybe Super Buster. So a new chip has been added.
Unless you're saying I know that there is one chip which got a new library, from the same thing. If I make a new MC68800 library because I have put some functions which can be called to hardware in shorter form, that's a new chip too?
Or maybe like there is no library at all, and here's just a couple couple code segments you can substitute declaring your own functions into?
Which is it?
Is it a Warp3D driver?!? We have a new Warp3D HW driver and can just straight run Warp3D 68k programs and they'll be faster and look better on MC68E0C80 chips? Awesome!

[Bruce Abbott]

Originally Posted by lmimmfn

Ì think it's pointless implenting this in the FPGA.
It's time they supported delegating to an arm processor,

But there is no ARM processor in the FPGA or on the board, so how would they do that?

they're he'll bent on implementing everything in the fpga that it makes no reasonable sense.

If there is space in the FPGA, why not use it?

[Bruce Abbott]

Originally Posted by grelbfarlk

There is a new chip added to the chipset. A chipset as we understand it in the Amiga world as a grouping of chips. With ECS we would say a set of chips is Denise, Agnus and maybe Buster. With AGA we would say that set of chips is Alice, Lisa and Gary and maybe Super Buster. So a new chip has been added.

So if Alice, Lisa and Gary were implemented in a single FGGA, would we still call them a chipset? Or will we pedantically say no, it's only one 'chip'?

Unless you're saying I know that there is one chip which got a new library... Is it a Warp3D driver?!? We have a new Warp3D HW driver and can just straight run Warp3D 68k programs and they'll be faster and look better on MC68E0C80 chips? Awesome!

Not sure what you are trying to say here. A driver is obviously not a chip, it is software that virtualizes control of some chip(s).

We don't know anything about this 'Maggie 3D chip' yet, but I bet it will be accessible at the hardware level. They may have (or will have) driver software for it too, perhaps even with Warp3D API. Which would be awesome because right now Warp3D only works on certain graphics cards that most people don't have. But even it doesn't do Warp3D it will still be awesome.

[Promilus]

But there is no ARM processor in the FPGA

There's Cyclone V SE which does have ARM on-chip and also slightly more LE. And Gunnar knows that as well. But he DOESN'T WANT TO delegate any 3rd party processor in his design.

If there is space in the FPGA, why not use it

because doing everything on FPGA doesn't make it efficient or fast. But it hardly matters in retro stuff. On the other hand ppl from MiSTer and it's 68k core have begun to work with on-die ARM since their platform actually uses such SoC FPGA. But - afaik - that's just one of those JIT emulations - so it allows you to choose between heavily modded TG68k which still lacks in power (in comparison to AC68080) and JIT 68k. But I doubt it'd overwhelm 080 even with JIT. On-die Cortex-A9 is rather poor 32bit processor and shouldn't be used to emulate 68k but rather as coprocessor for 3d - so implement Wazp3D on it, run mpeg decoding on it etc. etc. But since no FPGA on Apollo cards does have that all those guys can work on is FPGA itself.

[Thomas Richter]

Originally Posted by Bruce Abbott

But there is no ARM processor in the FPGA or on the board, so how would they do that?

Many modern FPGA chips do have an arm core on the chip as well. In rather typical applications of FPGAs, you need a little bit of (non-speed critical) software for the control logic which is then outsourced to the arm core, while the "heavy data shuffling" is done by the FPGA. To give you an example, the ZZ9000 uses such an FPGA. The FPGA is for creating the image and the display signal, and the arm core is for the network, audio and (AFAIK) blitter operations.

[Bruce Abbott]

Originally Posted by Promilus

There's Cyclone V SE which does have ARM on-chip and also slightly more LE. And Gunnar knows that as well. But he DOESN'T WANT TO delegate any 3rd party processor in his design.

And he's not the only one.

because doing everything on FPGA doesn't make it efficient or fast. But it hardly matters in retro stuff.

Actually it does matter in retro stuff. The Vampire V2 in my A600 runs much more efficiently (cooler, lower power) than a 68060 would, and a lot faster too. FPGA made 060 class performance with RTG possible in the A600. That was a big deal for me because it gave me higher performance than the 060 equipped A3000 I used to have.

On-die Cortex-A9 is rather poor 32bit processor and shouldn't be used to emulate 68k but rather as coprocessor for 3d - so implement Wazp3D on it, run mpeg decoding on it etc. etc. But since no FPGA on Apollo cards does have that all those guys can work on is FPGA itself.

Historically the Vampire FPGA never had an ARM core in it, probably because it wasn't considered necessary and/or the chosen FPGA chip didn't have that option. The original V1 Vampire was designed to simply be a fast 68000 CPU. V2 expanded it to 060 class and added RTG etc., which needed a larger FPU. But an ARM core was not part of the design, so why use a more expensive FPGA with something you don't need?

It was a different story for projects that were originally created on an FPGA dev board that already had an ARM core. Since it was there from the start it made sense to think of a use for it. But those projects didn't achieve the performance of the Vampire.

[Promilus]

Actually it does matter in retro stuff. The Vampire V2 in my A600 runs much more efficiently (cooler, lower power) than a 68060 would, and a lot faster too. FPGA made 060 class performance with RTG possible in the A600

Yeah, so what? That alone makes it the most efficient solution to the problem of old and slow A600? Would e.g. TI AM6548 with PJIT, USB3, DDR4, giga ethernet, eMMC and 3D graphics with similar price to Icedrake be something less interesting and efficient? No? And it's all possible as it's natural upgrade to OSD335x used in Buffee. Why do you even care HOW those kind of features are made? Is it softcore implementation in programmable logic or software implementation on hard logic? What's important is what one solution offers and how much it costs. FPGA isn't most efficient way to deal with everything (so... yeah, it's actually LESS efficient to implement 3d graphics on FPGA than use "hard" 3D graphics in SoC FPGA - so e.g. Mali 400 in Zynq UltraScale+ MPSoC FPGA - the big downside is that such FPGA costs around the V4 itself but it offers way more in return).

But an ARM core was not part of the design, so why use a more expensive FPGA with something you don't need

PiStorm already proves you don't need FPGA to implement fast storage, RTG, networking and USB HID. And that's a solution I'm not fond of due to misuse of GPIO as 68k interface (it's not the best way to do so but for RPi it's the only way). On the other hand Buffee uses far less advanced CPU Core but more suitable to the role thanks to GPMC (again - downside is 16bit datapath which isn't bad for A500 and A600 as those computers have such data bus anyway). AM6548 costs around 60$ - it's less than Cyclone V 5CEFA23 used in V4 and further designs. And yes, all those fancy features like multiple SPI, SDIO interface, eMMC interface, gigabit ethernet, USB3 first needs AOS driver to be usable (and that's a lot of work) but it doesn't change a fact this kind of chip actually is more efficient way to do turbo + RTG + networking + connectivity than FPGA.

They do stuff this way - that's their right and I am impressed how much progress they've made with that. But I'm no blind to everything else. It's not the most efficient design. Or cheapest. But (atm) it's the ONLY design with powerful 060-like CPU.

[Bruce Abbott]

Originally Posted by Thomas Richter

Many modern FPGA chips do have an arm core on the chip as well. In rather typical applications of FPGAs, you need a little bit of (non-speed critical) software for the control logic which is then outsourced to the arm core, while the "heavy data shuffling" is done by the FPGA. To give you an example, the ZZ9000 uses such an FPGA. The FPGA is for creating the image and the display signal, and the arm core is for the network, audio and (AFAIK) blitter operations.

Yes, I knew that. But the Vampire doesn't have one of those SoC FPGAs.

"So why don't they switch to the SoC version?", you retort. One reason might be that there is a world-wide chip shortage and Cyclone V5's are virtually unobtainable right now. A few months back Apollo made the sensible decision to obtain a large quantity of the larger FPGAs they needed for the new V4 cards, avoiding the chip shortage problem. Their foresight and investment means we can now buy V4 cards, and take advantage of new features that may be added in the future.

But that's not good enough for Amiga fans. Never satisfied with what they can get, they refuse to accept anything less than their wildest fantasies. It's not good enough to have twice the performance of an 80MHz 060 and RTG over HDMI at 1024x768 in 32 bit, as well as enhanced AGA, 16 bit sound, fast IDE, 100Mb/s Ethernet etc. Oh no, it has to be at least equivalent to a 1GHz 060, have resolutions so high you need a magnifying glass to read standard size text, and 3D equivalent to a modern gaming PC - all for less than the price of the FPGA alone.

"The Apollo team could easily do all that and more simply by throwing in an ARM core and chucking the whole lot into an ASIC.", they say. "It won't really cost a million dollars to do it either, promise! And don't worry about getting enough sales - I'll buy 3 of them!". I had hoped since the Amiga is now a retro platform that attitude would disappear, but it seems to have gotten worse. After all these years, Amiga fans are still suffering from PC envy.

[Gorf]

Originally Posted by Bruce Abbott

It's not good enough to have twice the performance of an 80MHz 060

Of course not.
Not by a long shot!
We are writing the year 2022 and CPUs in <50$ devices have usually >20 times more powerful processors on board.

And with a decent desktop CPU you can emulate a faster Amiga than these FPGA boards are offering now..

Oh no, it has to be at least equivalent to a 1GHz 060

Yes - the x86 equivalent reached such performance 20 years ago, so asking for just that seems very modest to me.

[Promilus]

I don't find apollo cards lacking in terms of CPU performance. But it doesn't mean there's no room to improvements. USB HID and mass storage on any port (instead of dedidacted ports) is just from the top of my head. Remember - just because there isn't a single "final" design of ARM SoC based turbo card doesn't mean it's bad solution. Igor's idea was treated just like that - why bother with FPGA when there's plenty of 030, 040 and fairly good amount of 060 out there... And guess what. There aren't that many 060 out there and those are pretty expensive. Using ARM SoC instead of FPGA isn't bad idea or "less amiga". It doesn't mean what you use but how you use it. If end result benefit user then that's a good product. Be it FPGA, ARM SoC, old PowerPC PCI card or whatever.

It should be pretty obvious that PiStorm shows a lot of promise - both CPU performance and features for substantially less money than Icedrake and it's nowhere near the end of it's capabilities. Buffee won't show much of the SoC features in the first developed version. I don't know if nonnarkitten will make another batch with improved capabilities (more SoC features exposed) and/or newer version of SoC - I doubt that, but either way there's a whole new world of amiga accelerators opening up and at much more affordable levels. It'd be in the best interest of Gunnar to pay close attention to what those solution offers.

[Thomas Richter]

Originally Posted by Bruce Abbott

"So why don't they switch to the SoC version?", you retort.

Not really, was more an observation than anything else. It's what we (my employer, big German research foundation) is looking into, but not on a hobby basis.

Originally Posted by Bruce Abbott

But that's not good enough for Amiga fans. Never satisfied with what they can get, they refuse to accept anything less than their wildest fantasies.

Not really, or at least not on my end. I really don't mind whether it reaches 50Mhz, 100Mhz or 200Mhz, it doesn't matter too much for me because the Amiga is not a productive machine in the sense the PC is. So I'm fine with the speed. I'm not fine with their ignorance of good engineering principles, Amiga legacy architecture and their ignorance of rights of third parties. That's what sets me up. They surely generated a very fine 68EC080, but that's all it is. A "by design" incomplete, but fast FPGA implementation of a 68K core.


But making it complete is hard, you retort. But that's exactly why we are doing it, right? We do things *because* they are hard and non-obvious. Getting the thing *right* would be a motivation for me, not getting it fast. Fast but not quite right I have, thank you, UAE on my PC works already.

Originally Posted by Bruce Abbott

It's not good enough to have twice the performance of an 80MHz 060 and RTG over HDMI at 1024x768 in 32 bit, as well as enhanced AGA, 16 bit sound, fast IDE, 100Mb/s Ethernet etc.

Probably because I have all that. Ok, it's a 50Mhz 060, but RTG with pretty much that resolution, which is well much beyond AGA, and I have fast SCSI and 100MB ethernet. Except that the machine I have is modular, I can query components according to CBM specs, I can use ROMs without custom patches, etc... So again, it's certainly a fine system, but it would be much better if it would work in the tradition of Amiga and how to extend an Amiga.

Originally Posted by Bruce Abbott

Oh no, it has to be at least equivalent to a 1GHz 060, have resolutions so high you need a magnifying glass to read standard size text, and 3D equivalent to a modern gaming PC - all for less than the price of the FPGA alone.

Not for me, certainly. I have a 3GHz PC, and my eyes won't take the high resolution anyhow, and I don't play or appreciate 3D games. So that's all good. But instead, it's just an ignorant "I say so" system. I need to patch up the ROM because they don't follow principles, hardware is not properly announced to the system, and it needs custom debugging tools because it doesn't have a MMU, and it has a cut-down FPU because "we say so". Thanks, but if I want a "we say so" machine, I have a PC already, and then it is "Microsoft says so" instead of "Gunnar says so".



The Amiga is, for me, an interesting piece of history, let's preserve that history. Sure, one can extend, but please not by ignoring the traditions of the system. It's a "tiny bit too late" for revolutions like that. It would have been great 20 years ago, of course, but then we still had "some sort of market" 20 years ago. Today, it's retry computing, so let's keep it retro and in the spirit of the machine.

Originally Posted by Bruce Abbott

"The Apollo team could easily do all that and more simply by throwing in an ARM core and chucking the whole lot into an ASIC.", they say.

Actually, I don't think this would be the way to go. The arm code could be quite useful in taking over tasks the 68EC080 cannot do, or not well enough. Network communication and 3D may be, if you really care, an application for such a core. But again, I personally do not quite care about all that too much. Network, yes, that's very practical, but as said, I already have that. The ZZ9000 is a graphics card (actually, more than that) in this development spirit. Certainly a nice piece of hardware and also good development.

Originally Posted by Bruce Abbott

"It won't really cost a million dollars to do it either, promise! And don't worry about getting enough sales - I'll buy 3 of them!". I had hoped since the Amiga is now a retro platform that attitude would disappear, but it seems to have gotten worse. After all these years, Amiga fans are still suffering from PC envy.

Not sure who is, but I'm not. I have a PC.



My motivation is more like "Hey look, here's an interesting piece of hardware from that period, can I make it to work? And what are the limits of this hardware, let's see...".


That's much more a driving factor for me. Interesting obsolete old graphics card for the Amiga that still doesn't work quite right? Yeah, gimme! I can make it work! I don't mind if it cannot reach 1024x768x24, but hey, if it can reach something it wasn't meant to produce, that's an interesting experience. That is, "get most out of the components you got" is for me much more than a 3D core for which we probably see only a couple of home-brew games I don't mind playing. I'm not a 3D player anyhow. I appreciate a mind-boggling adventure much more than a 3D shooter which gets booring after 10 minutes of game play.

[pandy71]

Originally Posted by Promilus

Would e.g. TI AM6548 with PJIT, USB3, DDR4, giga ethernet, eMMC and 3D graphics with similar price to Icedrake be something less interesting and efficient? No?

Shortly - yes and no.

Longer version: many modern SoC's for sure offer substantially higher performance (thanks to hard(soft)cores) - there is only one issue and it is called NDA - if you have no NDA then you have no documentation to 3D chipset and you are forced to use provided driver and there is no driver for baremetal i.e. you introducing all Linux mumbojumbohogopogomix (and vendor drivers are buggy too) so at some point you ends in coding some SoC based on ARM that will emulate MC68K at (under) Linux.

So as ARM emulation of the MC68K in baremetal have sense then using 3D in Linux running on ARM that emulate MC68K has no sense as you can use UAE to create similar impression (and this is Amiga-mini approach i believe).

Sadly to say but 3D graphics core, video cores are undocumented intentionally to avoid patent legal disputes and there is no chance to change this.

As such even limited FPGA 3D natively driven by MC68K has sense.

[Promilus]

@pandy - with Zynq UltraScale there's Mali 400 - of course there's iirc binary driver for linux and android. There's no official sources for Mali 400 which you can use to build amiga driver. Yes. But there's Lima project which is basically open source, reverse engineered driver for Mali 400 and 450. Same goes with Broadcom (RPi) and of course that's a lot of effort to make decent driver for AOS but it's the same with 3d fpga implementation (what's worse, you have to first design the hardware logic, write verilog code for it and make it fit in already packed up FPGA). As for SGX544 (from AM6548 and similar) - there's kernel space driver under GPL v2 but there's no sources for user space driver which makes things kind of bleak. RK3399 has great documentation and it's Mali T860 has open source driver (Panfrost) as well. So while I admit there are some obstacles... that's true to everything in amiga world. And also - the more "open" chip you use the easier is to make native amiga drivers without resorting to hide chip functionality under linux system device facade (like initial PiStorm).

[pandy71]

Originally Posted by Promilus

@pandy - with Zynq UltraScale there's Mali 400 - of course there's iirc binary driver for linux and android. There's no official sources for Mali 400 which you can use to build amiga driver. Yes. But there's Lima project which is basically open source, reverse engineered driver for Mali 400 and 450. Same goes with Broadcom (RPi) and of course that's a lot of effort to make decent driver for AOS but it's the same with 3d fpga implementation (what's worse, you have to first design the hardware logic, write verilog code for it and make it fit in already packed up FPGA). As for SGX544 (from AM6548 and similar) - there's kernel space driver under GPL v2 but there's no sources for user space driver which makes things kind of bleak. RK3399 has great documentation and it's Mali T860 has open source driver (Panfrost) as well. So while I admit there are some obstacles... that's true to everything in amiga world. And also - the more "open" chip you use the easier is to make native amiga drivers without resorting to hide chip functionality under linux system device facade (like initial PiStorm).

So at some point you are stuck with Linux (or distant Linux fork Android) - with no access to HW you are forced to emulate at higher abstraction layer and as such deal with all limitations.
For today we observe API paradigm shift - back to low level access - popularity of Vulkan is clear proof for this.
IMHO it will be way easier to write Vulkan API for Maggie than do similar thing in case of way more powerfull but not open sourced (properly documented) modern 3D HW.
Classical problem with sparrow in your hand and pigeon on the roof, which one is better ("Der Spatz in der Hand ist besser als die Taube auf dem Dach").
Don't get me wrong - i've wrote about MC68K emulation on ARM and using it in Amiga way before PiStorm, with help of TI PRU-ICSS it should be possible to interface ARM directly with CPU socket in Amiga - but still - even most open SoC i.e. RPi is still not fully documented and as such can't be used in Amiga fully... same or worse for other SoC's.
btw i have no Vampire as IMHO cost of the HW is too high but i wish Apollo all the best.

[Promilus]

So at some point you are stuck with Linux

No. You're stuck with porting whatever linux community achieved to amiga standards. As I wrote - more available resources are there (both documentations and source code) - easier to use chip features NATIVELY under AmigaOS.

IMHO it will be way easier to write Vulkan API for Maggie

Maggie has absolutely NO Vulkan capabilities and it would be hard to get even TinyGL level of features implemented (and relevant driver developed). And as I mentioned I'm not really interested with bringing up features like OpenCL, OpenCV, fairly decent GLES or even H.264 codecs to Amiga. I don't care. But USB mass storage with level at least similar to 2.0 standard and mass storage, HID device classes on ANY usb port - that's clearly something which should be achievable and improves functionality for end user. Same with fast SD or with WiFi solutions readily available.
Having hard USB host in ARM SoC doesn't mean it magically supports any USB device. It does only what hardware does, the rest depends on software (so drivers in OS). ARM SoCs aren't magical cure for every problem amiga user might have but are affordable solutions with vast support (yes, mostly in Linux community). And - just like FPGA - if it CAN be used it SHOULD be used.