Vampire discourse, keep it civil (was: Vampire 1200 V2 waiting times)

[hammer]

Originally Posted by Bruce Abbott

And their worst business decision was taking on the Amiga. If only they had stuck to just making the C64 line and PC clones! The world would be a duller place of course, but we would never know what we were were missing...

And a good thing that was too. CBM died exactly when we needed it to, before they were able to rip out the Amiga's soul and replace it with clone technology (or worse). Unfortunately that didn't stop others from attempting to do it.

Fortunately we now have teams who are getting Amiga development back on track. The Apollo team is one of those. They are the only ones dedicated to extending the Amiga chipset rather than replacing it with clone technology - breathing new life into the Amiga's soul.

Commodore Amiga Hombre's semi-custom PA-RISC 7150 with hardware 3D acceleration and SGI OpenGL target was interesting.

68K CPU is Motorola's baby, not Commodore's. Commodore has a license for PA-RISC and HP allowed its semi-customizations.

Precision RISC Organization, an industry group led by HP, was founded in 1992, to promote the PA-RISC architecture. Members included Convex, Hitachi, Hughes Aircraft, Mitsubishi, NEC, OKI, Prime, Stratus, Yokogawa, Red Brick Software, and Allegro Consultants, Inc.

Amiga CD64 would be like SGI design Nintendo 64 (with OpenGL-based 3D target) with a CD drive.

OpenGL's 3D perspective parallax beats AAA chipset's fake 2D multi-parallax.

Other PC GPU vendors have a similar plan as Commodore's OpenGL direction. Key personnel who design Nintendo 64 form a company called ArtX, and it was later brought out by ATI. PlayStation 4/4 Pro/5 and Xbox 360/Xbox One/Series S/Series X continue ArtX's game console GPU evolution. AMD's Mantle API-based Vulkan API replaced OpenGL. NVIDIA also targeted OpenGL-based 3D ASICs via RIVA 128.

[hammer]

Originally Posted by Bruce Abbott

The Amiga is now 25 years behind the times and will never catch up. Which is a good thing. It means we can relax and take our time doing stuff we would have done 'back in the day' if only we had the time. I always deplored the constant pressure to switch to a new or 'improved' platform just as I was getting to grips with the current one. A body of knowledge would build up and ideas conceived, only to be discarded as I moved on to the 'next level'. A few years ago I gave up computers as hobby because there wasn't anything in it for me. But now the Amiga is back in the game, and so am I - fully retro - where I always wanted to be.

Switching to a modern ARM CPU just as the original Amiga team has selected 68000 has the best chance for the "Amiga" to catch up to modern computer standards. PiStorm is already making inroads within the Amiga community.

Acorn designed the ARM CPU as a response to Commodore's bad CSG/MOS 65xx R&D road map.

On a side note, Raspberry Pi Foundation's control over Pi manufacturing licenses illustrates the single-source nature of the Pi platform. Despite Raspberry Pi Foundation's open source virtue, Pi is not an open clone platform like the PC. Other Pi clones are not compatible with Pi.

Buffee uses TI's ARM SoC instead of Broadcom's ARM SoC, and they are only compatible at the CPU ISA level.

There are many RISC CPU families that tried to replace 68K e.g. SuperH, MIPS, PA-RISC, PowerPC and 'etc'.


With various CPU accelerators, the Commodore's classic Amiga platform acts like a hardware platform target that enables a common platform cloning e.g. Minimig 1.8's 68000 socket enables any Amiga 500 accelerator card to be fitted (e.g. PiStorm, Vampire, TF536 and etc), hence duplicating Commodore's Amiga 500's expandability behavior.


Apollo Team's Vampire V4SA (standalone) doesn't duplicate Commodore's Amiga 500/1200's expandability behavior i.e. Vampire V4SA is a dead-end door stop like any ARM-based Android device while Minimig 1.8/Amiga 500 is not bound by a single CPU vendor. I rather see an A1200 FPGA clone with an A1200 expansion edge connector.

[grelbfarlk]

ARM is weak, the ARM core on the DE10 Nano was so slow compared to the Vampire core that they decided making an adaptor for it would actually slow the Vampire Core down too much. Also for the same reason adding a PowerPC to the Vampire would make it like a Vampire just sloshed in garlic and silver, it'd lurch around like a zombie because of the inferior CPU architectures slowing down the awesome power of a homebrew 68EC060 running at double the MHz of a full 68060.

[Korodny]

Originally Posted by Bruce Abbott

In fact the Amiga is expanding into the future, and is capable of doing some 'modern' tasks such as email/web/media.

email: none of the mail clients is maintained anymore. one doesn't do IMAP, the other only has a very buggy implementation.

web: LOL

media: uhm, granted - JPEG and PNG are well supported. As is ASCII text.

[Promilus]

@grelbfarlk
DE10 nano has ~600MHz Cortex A9 core. Which takes circle around AC68080 when it comes to pure computational performance. Gunnar didn't chose SE series of Cyclone not because ARM was weak but because:
1. he don't want to pay royalties to implement ARM on ASIC along AC68080 should he integrate ARM within his FPGA design
2. he thinks his AC68080 in ASIC will run circles around ARM in ASIC (well, RISC-V developed by many companies with much more worldwide support doesn't, why would he expect different result with AC68080 I cannot fathom)
3. he doesn't want anything else than 68k or his own extensions of 68k.

Now as for PowerPC - there were some FPGAs with PPC cores but
1st - those cores were most likely less powerful than 604e
2nd - those FPGAs are obsolete
3rd - those hard processors had max speed of ~400MHz

and making softcore PPC is not something Gunnar ever cared about (not to mention it would not fit chosen FPGA along with AC68080 and would still suffer from the same FPGA constraints as AC68080 - what good is to have ~100-150MHz PowerPC?)

Why ZZ9000 doesn't get much out of the second ARM core? Well that's because:
- AmigaOS has no adaptor like WarpUP to let arm code run on it hence it requires some tricks to do it
- ARM on ZZ9000 has only fair access of local memory so it cannot run or efficiently share data with 68k code in fast ram region outside ZZ.
ARM integrated in FPGA holding 68k softcore can share efficiently data with 68k through - shared - fast ram. With 68k, RTG, ARM and other peripherals connected through single shared memory and implemented in single FPGA it can achieve much more than just 68k softcore with rtg, ide and networking alone.
Gunnar messes with you about ASIC but all you have is FPGA based vampire. And should he ever make ASIC AC68080 it will still be new hardware. There is no real obstacle and never was to integrate ARM into the mix as. Should he get enough funds to produce ASIC he'd most likely have enough to buy ARM license as well, especially after licensing policy was changed to charge AFTER chips are being produced rather than before.

Now then what does it change in the long term. It might change nothing at all. It might change everything. Why? Let us just assume that PiStorm does reach a point when it's really mature. And it does mature nicely, faster than Vampire did. At some point ppl will start asking "ok, so we got ourselves JIT on one Cortex A72 core, what about the other 3?" And in that moment should someone write adapter to let AmigaOS access other ARM cores and run ARM code inside AmigaOS it might effectively destroy while AC68080@ASIC concept due to ... performance gap it could never hope to fill. Should Buffee succeed and get Van Helsing (buffee 2) on AM623/5 with same thing (other ARM cores available under AOS and maybe IGP as well) - the result will be the same. There are plenty of h/w options revolving around ARM available for Amiga nowadays. It lacks support firmware/software side but more and more ppl see how viable those SoCs are as potential Amiga accelerators.

I was a fan of Igor's initial work. It was about relatively cheap accelerator. V2 was still intended to be cheap, compact and powerful retro accelerator. But it eventually evolved into rather expensive power creep design. I'm not that much into the performance grind either Apollo or PiStorm team offers. There are plenty of ppl which want to just enjoy their retro machines with rather inexpensive yet versatile accelerators with great compatibility. And both of those products can't offer it.

[jbenam]

Originally Posted by hammer

Commodore Amiga Hombre's semi-custom PA-RISC 7150 with hardware 3D acceleration and SGI OpenGL target was interesting.

And in hindsight, another lovely dead-end just like PowerPC was. Except that PowerPC was supported by a major vendor (Apple) and that it got much more mileage out of it.

Everyone keeps forgetting that Amiga isn't a console. You can't compare it to the N64. Nobody expected the GameCube to be compatible with the previous generation. With a computer like the Amiga that is a given - and these days, even consoles need to support previous generations to avoid the ire of their userbases.

Hombre was amazing on paper, but even if launched as a console (where the lack of compatibility would've been acceptable), it would've been a very rocky transition with the risk of alienating the entire "application" side of the userbase. I guess that Commodore kept pushing developers towards using OS-level APIs because that way they would've achieved at least some level of compatibility with older apps.

Originally Posted by grelbfarlk

ARM is weak, the ARM core on the DE10 Nano was so slow compared to the Vampire core that they decided making an adaptor for it would actually slow the Vampire Core down too much. Also for the same reason adding a PowerPC to the Vampire would make it like a Vampire just sloshed in garlic and silver, it'd lurch around like a zombie because of the inferior CPU architectures slowing down the awesome power of a homebrew 68EC060 running at double the MHz of a full 68060.

@Promilus

Back in 2010 I remember saying that the only way for Amiga NG to survive, was to move over to ARM. Do a Raspberry Pi port and the Amiga (or at least AOS4) could've had a renaissance of users like RiscOS and Haiku did. That was the only sensible move to do back then when AOS4 development was still active enough.

[OlafSch]

@jbenam

I think I somewhere saw a picture describing what was planned with PA-RISC. It would have been a complete new and incompatible hardware platform. There was even planned to use NT for certain models as main system. The chipset was not compatible either. I am not sure if that really would have had any chance (it was never more than some electronic papers as far as I know). You can moan about Windows but Microsoft always was aware that compatiblity is extremely important for the acceptance. In this context I think Hombre would have been a commercial failure. Only if the new platform would have been as superior as amiga originally was in 1985 then there might have been a chance. And even then it would have been a bumpy ride, economic history is full of superior technologies that failed economically like Video 2000 versus VHS. Finally content sells hardware.

@Bruce

World has changed. Even if you would have a 1 Ghz Amiga you would still not have something "modern". Security today is extremely important today, a system where apps can turn off the OS has no chance as a mainstream system today. I like amiga and its concepts and the simplicity it has compared to mainstream platforms but I would not use it for serious tasks where security is important. Vampire is a nice retro platform, a kind of "what would have been if Commodore would have survived and Motorola continued with 68k processors" but I do not see it as a mainstream platform. A growing niche of course is possible. If that is already the "revival" Gunnar thinks of is outside of my knowledge.

[Samurai_Crow]

Originally Posted by jbenam

Hombre was amazing on paper, but even if launched as a console (where the lack of compatibility would've been acceptable), it would've been a very rocky transition with the risk of alienating the entire "application" side of the userbase. I guess that Commodore kept pushing developers towards using OS-level APIs because that way they would've achieved at least some level of compatibility with older apps.

Commodore was rumored to also plan on switching to Windows NT as a kernel.

[Promilus]

Commodore in their late years had many plans and few solutions... I wouldn't count on NT that much. Without distinct hardware AND operating system that would be disaster. Even Apple knew they need something good for their macs and ended up buying (back) Jobs along with NeXTstep.

Now then just as OlafSch said - should Apollo ever reach that 1GHz what exactly will it change?

[Rotzloeffel]

Originally Posted by Promilus

Now then just as OlafSch said - should Apollo ever reach that 1GHz what exactly will it change?

Nothing

[Thomas Richter]

Originally Posted by grelbfarlk

ARM is weak, the ARM core on the DE10 Nano was so slow compared to the Vampire core that they decided making an adaptor for it would actually slow the Vampire Core down too much.

Actually, "arm" is a lot of things, not just a single CPU. "arm" is an open platform, and the "arm" CPUs you can get range from low-end PI-like CPUs up to Apple's M1/M2 CPUs which outrun the latest intel and AMD chips in terms of performance.

Thus, you cannot really say anything about the speed of "arm" as it really depends on a particular incarnation of the arm architecture. This is actually one of the biggest advantages of the architecture that it upscales easily.

[Promilus]

@Thomas Richter - well, not really, no. ARM isn't open platform. While you sure can make your own implementation (so did Apple, Qualcomm, Samsung and Nvidia) you still have to pay royalties to arm holding. There's microcontroller oriented Cortex M family and more general purpose Cortex A family. And even Cortex M4 and later already outperform current FPGA implementation of AC68080 in native code. And that's few $ piece of hardware.

There is absolutely no reason to fight on terms of either performance or cost effectiveness with modern solutions. Fortunately there's not single solution which at this particular moment can provide a challenge in the field of Amiga performance. PiStorm32 and (hopefully) port to RPi4 for regular PiStorm are still in development. And due to the shortage of chips (and boards) there's a problem getting Pi3 or CM4 essential to this project. In the meantime Apollo released A1200, A500/2000 and soon enough A600 version of V4 and those boards will sell out immediately.

[Thomas Richter]

Originally Posted by Promilus

@Thomas Richter - well, not really, no. ARM isn't open platform. While you sure can make your own implementation (so did Apple, Qualcomm, Samsung and Nvidia) you still have to pay royalties to arm holding.

That *is* open. "arm" works differently than intel or AMD where you have a company that keeps control on the platform which is developed behind closed doors. "Open" is something different than "royalty free". Note that this discussion is different from "should I use arm to emulate a 68K". It was more the question of "if I would want to modernize AmigaOs, which CPU would I pick", and that is not "68K emulation on arm", but "arm natively", which is quite different from what PiStorm attempts.

This being said, I do not consider it reasonable to "modernize" AmigaOs in this respect because it is a retro platform, not a system that is used for productivity. Compatibility is of utter importance, not speed.

[jbenam]

Originally Posted by OlafSch

I think I somewhere saw a picture describing what was planned with PA-RISC. It would have been a complete new and incompatible hardware platform. There was even planned to use NT for certain models as main system. The chipset was not compatible either. I am not sure if that really would have had any chance (it was never more than some electronic papers as far as I know). You can moan about Windows but Microsoft always was aware that compatiblity is extremely important for the acceptance. In this context I think Hombre would have been a commercial failure.

I agree wholeheartedly. Even the fabled Hombre wouldn't have saved Commodore. We all know how the other architectures supporting NT ended. They were just cast aside as x86 grew in popularity.

Originally Posted by Thomas Richter

This being said, I do not consider it reasonable to "modernize" AmigaOs in this respect because it is a retro platform, not a system that is used for productivity. Compatibility is of utter importance, not speed.

You don't see anyone want to modernize Win3.1 in the PC community - it doesn't make any sense

Patches and fixes, yes. New developments, sure. But you have to stay compatible to the original system (MS-DOS, in this case) or otherwise no one would use it.

I guess we keep seeing this being repeated every now and then in the Amiga community because everyone would love to have a second chance at the Amiga succeeding... While MS-DOS did have its moment and it just naturally evolved in 3.1, 95, NT, etc. so everybody these days just enjoys these systems for what they were and nothing more.

Well, I now hereby name this kind of behaviour the "Amiga saviour complex"

[Promilus]

@jbenam - you can hardly run 16bit apps without VM on modern windows and same goes to old 32 bit apps as well. So ... not really, no. It was never about backward compatibility per se, but both windows and macos somehow did support older apps one way or another. But those solution which indeed worked out with mac and pc wouldn't work with Amiga just because amiga fans won't accept it. So running OS3 apps in isolated environment on fully memory protected OS and different CPU arch with no chipset is no go.

[jbenam]

Originally Posted by Promilus

@jbenam - you can hardly run 16bit apps without VM on modern windows and same goes to old 32 bit apps as well. So ... not really, no. It was never about backward compatibility per se, but both windows and macos somehow did support older apps one way or another. But those solution which indeed worked out with mac and pc wouldn't work with Amiga just because amiga fans won't accept it. So running OS3 apps in isolated environment on fully memory protected OS and different CPU arch with no chipset is no go.

Erm, users had something like 30+ years where it was possible to do so without any VM - from Win95 to Win10. Nothing stops you from running 16-bit apps in the 32-bit version of Win10 while still receiving security upgrades. Win11 is the first OS that actually does not let you run 16-bit apps natively as it drops the 32-bit version entirely.

It's plain as day that backwards compatibility was of the utmost importance to Microsoft, and for good reason.

Never used AOS4 so I am not sure how seamless the RunInUAE approach was.

[Promilus]

But the OS wasn't backward compatible. It was achieved through special subsystems created only for that. If you didn't know process name which kicks in when running 16bit app is ntvdm - nt virtual dos machine. And when running 32bit app on 64bit os - syswow64 - windows on windows64. And yes, you have to manually enable ntvdm on win10. It doesn't go enabled out of the box. And of course only works on 32bit. NT line was quite a lot incompatible with mainstream 95 and 98 back then.

The point of my post was - why both PC and Mac users are happy with newer, more modern hardware and operating system and mechanisms allowing old apps running on new soft/hardware combo but it would never worked out with Amiga?

[Thomas Richter]

Originally Posted by Promilus

The point of my post was - why both PC and Mac users are happy with newer, more modern hardware and operating system and mechanisms allowing old apps running on new soft/hardware combo but it would never worked out with Amiga?

Back then, it might have worked, all provided Amiga could have gained some track in commercial applications, i.e. users that would have been willing to invest some money into the architecture. Unfortunately, Amiga was perceived and used as some games console, and for those users, it did not make a lot of sense - in fact, their applications just booted from the floppy and took over the system, so how hot archive compabilty for such "applications"? We already had, back then, some developments such as RTG - and I would believe the majority of users did not pick them off, mostly because games did not use them. But back then is back then, and 30 years later this makes no sense anymore.

[grelbfarlk]

Originally Posted by Thomas Richter

Actually, "arm" is a lot of things, not just a single CPU. "arm" is an open platform, and the "arm" CPUs you can get range from low-end PI-like CPUs up to Apple's M1/M2 CPUs which outrun the latest intel and AMD chips in terms of performance.

Thus, you cannot really say anything about the speed of "arm" as it really depends on a particular incarnation of the arm architecture. This is actually one of the biggest advantages of the architecture that it upscales easily.

Pardon me, sir but you absolutely can.

From: http://www.apollo-core.com/features.html

Originally Posted by Apollo, not the ACT Electronics one

The 68080 is 100% pipelined and easily beats the ARM |

And

Originally Posted by Apollo, not the ACT Electronics one

68080 is clearly the fastest 68K ever - and even outperforms PowerPC machines at 1000MHz for some benchmarks.

This is clearly true, in the Time to Display the Vampire Logo from Power On benchmark the most standard test of performance today in Amigaland:
Vampire V2=<1s
PowerPC 1GHz=43s
Which makes the Vampire over 43X faster!

[Thomas Richter]

Originally Posted by grelbfarlk

Pardon me, sir but you absolutely can.

I afraid you do not understand my argument. You cannot compare two things that are not properly defined. "arm" is not a single CPU, but a whole variety of CPUs with very different performances, "arm" specifies an architecture, not a platform. A statement as bold as this one does not make sense. Also note that by "arm" I do not mean "68K emulation on a Pi". Please note that of course there are arm implementations that are pipelined. What they probably compared to is a low-end processor such as the Pi. Comparing the time to show a logo is really a hillarious benchmark. How long it takes to display a logo depends on how much hardware on the board needs to be initialized, but that is not defined by the CPU speed, but typically on the performance of the on-board embedded controller to read the configurations from on-board devices, and to configure them. At this point, the CPU is still on halt and not operating at all. If the FPGA is the only thing on the board, then there is of course nothing to initialize at all, but that is not how a modern system is booted. This 68EC080 cannot compete with a 1GHz processor, this is just a nonsense benchmark.