[UserReview] Vampire V2-128 received and it's just pure p0rn.

[grond]

Ok, ram performance is >10 higher then a Cyberstorm 060, but the Vampire 2 cpu, with current core is <2 times faster.
Higher memory benchmarks does not gain any higher perfomance of the Vampire cpu ?

RAM performance only affects stuff that is not cached. Typical Amiga benchmark programs fit entirely into the cache so you don't see much effect of the RAM performance. However, if you look at e.g. the little fire demo effect flype coded, you'll notice that the vampire does something like sixty fps in hires. Just try doing half of that on a cyberstorm... :lol:

[grond]

I've not looked at whether instructions take a variable number of clocks

Except for some bitfields (2 cycles), movem (1 cycle for each word to be moved), mul (2 cycles) and div (many cycles) all 68k instructions take 1 cycle on apollo. Some instruction combinations can be fused or bonded which makes the second instruction effectively take 0 cycles. EA modes are free (except for braindead double-indirect). As far as I remember all pipelines can execute all single-cycle instructions.

Pretty strong compared to an 68060 that could execute two instructions in one cycle only if they fit into four bytes.

[grond]

Yeah, so you can't take how fast one program runs compared to a 68060 and infer how fast another program will run.

You never can.

A performance analyser that can show you how full the instruction pipelines are and how much time is spent waiting for memory accesses would be awesome.

They usually don't wait for mem because memory is clocked at twice the core clock and 32 bit wide. The caches prefetch so unless you have a random access pattern, data will be in the caches. The D-cache can provide 8 bytes of data to the ALUs per cycle and accept another 8 bytes from the ALUs in the same cycle. The I-cache can provide 16 bytes worth of instructions to the core per cycle.

As I understand that is a P96 driver for Apollo developed by Jason McMullan. Why does it also exist another P96 driver by Thomas Richter dated 27/12/2015 ?

What happened? I am a bit confused. Two P96 drivers? Why?

The first driver could not be used because of a lacking permission so a second one was written which is not using any knowledge provided by other parties. Jason implemented the driver completely from scratch without inspecting other people's work. The driver works on both AmigaOS and AROS so don't be confused by the "based on AROS" bit.

The only downside I can see with this is that they have been pretty clear that they aren't too bothered with 100% compatibility (especially MMU) and using AROS rather than AOS will make that easier.

Where did you read that? It's bull%&$#?@!%&$#?@!%&$#?@!%&$#?@!. The fact is that the MMU was hardly used in the Amiga. Most Amiga people don't even know what its purpose is. On the other hand some features of an MMU (address translation, to be precise) make memory access MUCH slower. If anyone wants an MMU, there in fact is a chance that it will be implemented. But there's a catch: with so much work do be done on the core, it's a matter of priorisation. FPU and even 64bit processor modes are more important right now that an MMU that isn't even used for anything. Of course, some UNIX or Atari people could be interested in a fast 68k that also has some MMU. But the project is about Amiga. If there is so much interest in an MMU, there needs to be an incentive for the main developers. This incentive is money (yes, sorry, it's a capitalist world). If there is money to be earned (which may be money to be invested in all this again), there must be some interest in an MMU. So set up some sort of funding and it may happen. If you still only want an MMU because the 060 had one, well, I don't think you really need it.

If they committed to 68060 MMU compatibility then I would be less cynical.

Again, what for? The apollo core is more 68k compatible than any other 68k processor. There never even was a standard MMU for 68k, they were all different. The 68000, 68010 and 68020 never even had one, the 68020 could be provided with an extra chip comprising the MMU (68851). I think there was one (1) Amiga processor board that had the 851 and was intended to be used for UNIX. Some but not all 030s, 040s and 060s have an on-chip MMU. There are like three Amiga programs in total making use of it.

I find it morally annoying that Apollo is and never will be opensource

You probably also find it morally annoying that you don't get free housing and food.

making it incompatible is made easier by the work put into AROS for free.

This is utter bull%&$#?@!%&$#?@!%&$#?@!%&$#?@!. You can run DOS on an i7. But you can't use the i7's 64bit mode in DOS. That's the same situation as with AmigaOS 3.1 and the apollo core and the reason why only AROS makes it possible...

I suppose one day someone will reverse engineer their FPGA bitstream and fix it.

It will be the day right after somebody reverse engineers the i7 to make its 64bit mode DOS compatible.

No, none of them are legitimate, unfortunately. Gunnar decided against licensing P96, which means that the drivers cannot be used on solid grounds.

This is not true. You make such statements rather frequently only to then point out that you are not a lawyer. I'm a patent attorney by profession (with a background in microchip development) so I am not a lawyer either but I do understand something about the legal situation. And I don't see a reason why a piece of software that was written without relying on non-disclosed knowledge would be illegal solely for the reason that it is intended to interface somebody else's software. If it were, this would be Microsoft's dream come true.

I understand that you don't like the availability of a free RTG driver. BigGun often stated that the original P96 authors deserved payment for their work that meant important technical progress for the Amiga. He wanted to have them get this money. For reasons unknown to me it was not possible to get an agreement with the original P96 authors (in fact it looks like they never even responded to any request for license but I don't know the details). Now it looks like Hyperion bought the exclusive rights to P96. They do not intend to develop it any further. They just want to use it to make more money. While that is legitimate, it is nothing that the apollo team has to accept if there are legal and cheaper alternatives.

Does the apollo core need a patched exec.library or not?

The 128MB RAM in an A600 need some changes in the standard memory map which are not supported by the A600 ROMs without patching. If you want to run the apollo core in its 64 bit mode, obviously you need to patch the context switching mechanism. These are only two of the issues with an unpatched ROM.

Again, Gunnar decided against licensing, so you'll have to use AROS.

Not true either. The user will be able to flash any ROM you want. But in order to run, it will have to be patched for the apollo core.

If the driver implements the P96 API, the problem remains - no license. If it only uses CGfx, I guess they'll have to deal with whether or not this is a legitimate option for CGfx. The latter I do not know. For P96, the situation is quite clear: No license, not legal.

...and not true.

I do not know what the conditions are for a third party to offer a CGfx driver. I can only tell you want the conditions for the P96 API are.

Let me put it like this: it's not a well thought out licensing model. It is circumvented by the mere fact that the apollo team doesn't agree to the license terms offered. As with any contract, you can simply not agree to the conditions and not sign a contract.

My opinion is simply that: If you're basing your work on the work of others, you'll better have an agreement with this other party. If this other party wants payment, and you don't want to pay, then this agreement does not exist, quite the opposite. Full stop, end of story.

No, the story goes on. You can do the same without basing your work on the work of others. And there is nothing that would stop a user from mixing your work with that of others.

[grond]

You cannot safely transmit data via DMA on an Amiga system without some MMU magic. This is an issue with the cache of the 68060 and 68040 CPUs. The only other alternative is to disable the cache completely while a DMA is running.

So? If you wanted, you could run the DMA on the apollo while keeping the cache updated. Some old SCSI stuff isn't relevant here.

As in, how much, for example? It creates actually no additional wait states for the 68040 or 68060

Since you are the resident MMU guru, you know better than this. There is a thing called translation look-aside buffer which has a finite size. There are many scenarios when an address translation cannot be done transparently which then can require a table walk of the translation table. And you probably also know that it's the TLB that is the most important constraint on overclocking an 060. This shows that the mem access had to be slowed down on the 060 in order to allow address translation.

Look, it's ok if you don't know, but please don't make such statements then.

You frequently do the same about legal issues.

No. I don't like taking other's people's work for selling my own work

Nobody takes other people's work here. Money would have been paid to the people who actually did the work but not to some company buying the rights and using 68k Amigas to milk some money for their main business.

even more so when first coming to an agreement with them ("We only use this for testing and come and pay you as soon as we make profit") and then later on run away as soon as it involves payment.

Excuse me, you haven't been involved, so you cannot know, but again, please do not make statements if you do not know.

So you were involved. How about you tell the story and then I tell it as I heard it and we all compare?

Excuse me, I've been a bit more involved in the whole process. Gunnar didn't want to license. There was an offer on the table by Hyperion, in fact.

Yes. And it was ridiculously overpriced and clearly a desperate attempt to make some money for a company facing economic doom.

Excuse me, that's neither correct. That's just Gunnar's interpretation of the answer.

How can you know better?

Which, by pure coincidence, also use the P96 API?

No, by design and intention. Just like the NTFS driver for linux, for example. Again, what do you think is illegal about this?

Ok, if they want to go for free, go for AROS completely and do not rely on the P96 API in first place.

That is kindergarten reasoning not worthy of a person as intelligent as you are.

Yes, they are. It's called autoconfig and supported by the Os ROM. Expansion, to be precise. Again, you do not seem to know, but here I am and tell you that it's all possible.

Thank you for telling me. How does it work in detail?

But if you do not sign, then you cannot use the work of others. Full stopo. I cannot offer a P96 driver if I don't want to pay for P96.

Yes, I can. It doesn't become true just by repeating it.

I cannot offer a patched Kickstart if I do not pay for the kickstart. It's really quite simple.

I agree for the kickstart under some circumstances because it involves patching (and thus deriving the patched kickstart from the original copyrighted work). However, there is a thing called "exhaustion of rights" which basically means that you don't need to pay a second time for something you already bought. That's also why it is perfectly legal to patch and flash the kickstart already owned by the customer.

Yes, there is. It is called "Copyright" and "licensing conditions".

I think I know more about copyrights in western legislations than you do. As for the licensing conditions, this is just an offer for a licensing contract. The apollo team did not accept that offer so no licensing contract was made. It's as simple as that. If you think about the GPL, it's precisely how it works: it is an offer for licensing which is accepted by the person using and modifying the source code ("konkludent", as we call it in German, or something like "implied by action of the party"). Licensing conditions are not like a law that you yourself made for a specific item you created. They are an offer for a licening contract. And such offers can be accepted or declined.

There is "normal use" of a work, i.e. I use the binary as intended.

That's what users of the vampire RTG subsystem will do.

What I cannot do is simply take the binary of somebody else, patch it up and deliver it as part of my product.

That is true. But not relevant for the picasso drivers as nobody took somebody else's binary.

Or base my product on an API of a closed product that, as intended by the authors, requires licence payments.

And here you are wrong again. I did my best explaining the legal situation. Perhaps I'm not good at it. My experience is that many engineers are not very good at understanding law (and lawyers not good at understanding technology) which is why we patent attorneys are such a rare breed.

[grond]

However, the rtg.library has two interfaces: One public, for programs calling into the rtg.library, and one private, for the rtg.library calling into the chip and card interfaces. The latter interface is private, has not been publically available, and requires a license.

Correction: no documentation of the latter interface is publically available, the interface itself is available on all picasso installations. And without using private information which will only be disclosed as part of a license contract, a license is not necessary to use this interface.

It's like you invent a secret language to speak with your buddy and everybody wanting to converse with your secret language needs to become member of your club of buddies by passing some test of courage. Well, how would that stop me from listening to you conversing publically in your language, deciphering it and then using it for my own entertainment?

But this all aside: How would you feel if you would offer a third party a license to your work

Who's feeling now? I think there is too much hearsay and communication by proxies in all this. If the original picasso authors have not sold all their rights to the software, they should speak up and communicate with the apollo team in person(s) and not by proxy.

Would you really believe that any follow-up work would really be based on a genuine re-implementation?

It's actually documented on github or wherever the new driver is hosted. And you are not going to suspect Jason McMullan for copying other people's work?

Look, it's not as if the work wasn't available for licensing in first place.

You can also license Microsoft's documentation for NTFS. However, if I were to write a filesystem driver for AmigaOS, I would just look into the linux NTFS driver and open-source my own driver.

Authors were there, a seller was there

authors != sellers? Were the authors there in person or representated by somebody, e.g. you?

[grond]

Hooking into "graphics.library" is pretty simple, and writing an  "rtg.library" is almost trivial especially if you have access to the  hardware designer who's written the underlying chip.

It's not trivial and it is not what was done here. What was done wasn't difficult (for Jason, that is) because indeed there is very little in the apollo RTG subsystem to set up. The documentation is somewhere in the apollo forum. Basically you set some bits in some registers thereby selecting the colourdepth and resolution you want.

The difficult part is indeed the patching of the graphics.library. And that has not been reimplemented by the apollo team which  means that you need a standard picasso installation and then install the apollo picasso drivers on top of that picasso installation. This is still legal because the picasso files are distributed freely with permission by their authors (e.g. on aminet).

As already mentioned before the work of the original authors is respected and acknowledged. They are invited to talk to the apollo team directly.

*Sigh*. Again, you want to find a twist around it. What's so hard to understand? Authors want payment. You don't want to pay, but still use it? Is this a fair trade in your language?

It may not be fair but it is legal. That's an important difference.

I don't know what he did or not did, but one may wonder where the API docs came from. Such information is not on file or on github. It's at least a pretty questionable practise.

AFAIK the "documentation" came from looking at the open-source implementation in uaegfx.

No. Tobias and Alex didn't want to sell directly to Gunnar. Too much hassle for them. The business was planned indirectly through Hyperion, which would have bought full rights on P96 (or probably even have them bought, right now).

This is almost funny. First you use the author's hurt feelings as an argument and then you say they weren't even interested enough to take part in the negotiations and of all possible companies left it to Hyperion to make a deal? And Hyperion itself negotiated with a potential licensee while trying to take over the rights to the product to be licensed? Do you understand what you are saying there? I had to look up the English term because I don't deal with penal law: this could be a case of breach of trust on the side of the proxy ("Untreue" in German).

Maintenance would have been done through an external team, again to be  paid by Hyperion (by people like me, for example). No, I do not  represent either Hyperion, nor the P96 developers. I'm only very  remotely related to this at all.

Hyperion pays people? I hope the contractors demand up-front payment. People "like you" but not you? Or do you have an interest in this deal yourself? As you know, the devil fools with the best laid plans. Sorry if it didn't work out.

[grond]

As a personal friend of mine I take offense to your questioning his ethics.

Give him a little rest. Thomas wrote the first vampire/apollo RTG driver hoping that the whole project would go the route he favours. His work seems now to have been done in vain because it was replaced by a second driver. I can understand this doesn't feel good. And the new driver was written in such a short time (I'm still awed) that I can also understand that somebody who didn't witness its progress would wonder about whether this could be done without peeking at some illegitimate resource.

Just a few hours ago Jason asked when he will finally get the SDcard hardware documentation. He brought it up only yesterday and I wonder whether BigGun & Co can deliver fast enough to keep him happy. If they do, we can probably expect the Sdcard driver by the end of the week... :lol:

It's such a pity for us that his interests have moved away from AROS/Amiga. Just imagine what he could do if this was his main project.

[grond]

Regarding open-sourcing the apollo core, this is not going to happen for a reason which we all should agree with: the possibility of an ASIC made from the apollo core (think 2 GHz apollo instead of 100 MHz...). This will definitely not happen if the core were open-sourced because no investor will ever invest the necessary money into an open-sourced core. This is because

a) any competitor could just do the same killing the ASIC economically

b) the investor would have to fear that the open nature of the source will invite patent trolls who could claim that some part of the source infringes some patent (try proving that from the ASIC alone and you'll understand the difference...)

I'm 100% sure that anyone interested will be allowed (or rather encouraged) to replicate the 64-bit 68k mode and the SAGA extensions that apollo core will bring in their respective projects.

[grond]

That is certainly not the impression I got from following this project over a year and a half.

"Replicate", not "take the code and use it". I suppose AMD didn't give Intel the VHDL sources to their x64 extension either...

For a neat sum of money, the core can be licensed to your FPGA project, of course.

I don't think for an FPGA project because then the code would spread. For an ASIC? I guess that would be a dream to come true.

Why is there an Apollo vs. PowerPC vs NION (of all things) soft core speed comparison on the apollo-core website?

A comparison against PowerPC makes sense in the Amiga world, even more so since the PPC softcore is actually marketed as an ASIC, too, I just forgot the part number. NIOS is a popular softcore and probably was available to the testers at IBM and serves the role as a neutral third for comparing both apollo and PPC.

What/who is Gunnar trying to attract with that?

I don't know. He may be proud of their 68k implementation which took them seven years and isn't even complete yet? He likes to point out that dropping 68k and going RISC wasn't as wise a move as it seemed in the early 90s. Perhaps he hopes that somebody will license the core for an ASIC?

[grond]

For Amiga users only, that is a very small market for doing ASIC production of an oddball CPU.

The apollo core could be interesting for other applications besides Amiga, Atari and other legacy 68k based devices. After all there are still companies producing 68k processors. Perhaps the company willing to invest into an apollo ASIC wouldn't even be aware of its possible use in an Amiga.
 

Are you saying that there are AmigaOne systems around running a FPGA softcore PowerPC?

I don't know because I never was interested in PPC-Amigas. But I'm pretty sure Gunnar mentioned that the same VHDL as the PPC Softcore was available as an ASIC.

However, those other cores have features that appeal to the real world markets

Which features do you think the apollo core is lacking that the others offer? PPC/NIOS code compatibility does not count.

That could happen if the first products would be truly compatible with existing OSes, toolchains and software. Instead it is a core that is not really compatible enough

Why do you think so? MMU again? An MMU may be implemented if there is enough interest.

I have asked around in various other 68k camps (NetBSD, Linux, NeXT, Atari), and the answer is always the same - not compatible enough, cannot be bothered.

And they based their assessment on what source of information?

[grond]

without FPU and MMU it is worthless to me.

All FPU instructions are implemented and tested but the FPU subsystem (e.g. program flow) needs testing which is postponed right now.

As for the MMU, I already mentioned that Gunnar said that it may happen if there is enough interest. However, this interest would have to manifest itself in the form of money. So go collecting and it may get some priority over SAGA (unless Amiga people outbid you... :roflmao:).

BigGun just confirmed to me that they could do a full 68k MMU that would e.g. allow Debian to run on the apollo core. He said that it would take quite a few week-ends worth of work. So what do you think that would be worth?

it is a cripled CPU implementation

IMHO Coldfire is far more a crippled 68k implementation than apollo...

And don't make Gunnar angry or the price for an MMU will double immediately... :lol:

[grond]

That's strange. Now that the vampire depends on open source

It doesn't, why should it?

wouldn't it be a better or at least more plausible alternative to let open source developers implement it?

Why? I don't see a logical connection there.

Why do you need a MMU? Because you'll need one in big box Amigas with DMA sources that transmit data on memory from one Zorro slot the same Zorro slot. Such transfers are not visible neither snoop-able by the CPU. Or you need to disable caching while DMA is running.

Yes, you mentioned that before. Looking at the numbers of Amigas sold, there are not really all that many bigbox Amigas out there. So it would be an economical decision whether they would get to enjoy an apollo or not.

Why? Why should Gunnar implement it in first place? Just open source the core, and somebody else will implement it for him.

I have seen the source code and I know VHDL (I happen to be a microchip developer by first profession although I mainly did high-speed transistor level CMOS design and less synthesised VHDL design). I don't think anybody could pick up development on that giant project easily.

The T68K opensource CPU we use in FPGAArcade and Mist runs at 28MHz single cycle when using I&D cache (in replay at least). If I was to build this on a Kintex ultrascale+ 16nm device (which are relatively cheap now) I'm pretty sure it would run at the base clock of 114MHz -  which would give it similar performance to the Apollo core for zero effort. I'll try this next week.

It's about performance per USD or %&$#?@!%&$#?@!%&$#?@!8364;. Gunnar mentioned that he has some Stratix boards available. So what performance could we expect from them? It doesn't really matter as it would be pointless to put a 10,000 USD FPGA on an Amiga accelerator. How much do FPGAArcade and Mist cost and how does their 68k performance compare to the 150%&$#?@!%&$#?@!%&$#?@!8364; vampire?

But let us hear about your results.

EDIT: btw, are you interested in implementing the 64 bit mode in your enhanced tg68 (or SAGA features)?

These will likely be licensed under the GPL which would not enable them to be used with a closed source core.

Aren't you using GPL'ed stuff and thus have to open-source your modifications anyway?

I really wish Gunnar well with his project, it's certainly a lot of work, but I don't believe it's going to end up as an ASIC.

It's not very likely, yes. That doesn't mean that this possibility should be killed from the start by open-sourcing the project.

[grond]

Mike, I also have to say that I doubt that the tg68 can reach anywhere  near the speed of the apollo core without rewriting it to become the  apollo core. Perhaps you just haven't realised the speed the apollo  delivers yet. Just look at the different real world programs and  benchmarks out there. What about tg68's adoom fps in 640x480? Riva media  player? mp3 decoding?

I saw the tg68 vhdl about a year ago and  even just judging from the code size it is the bare minimum for making  it execute 68k code. I guess the apollo code is several dozen times  bigger, if not 100s of times. Heck, I bet there are more signal  declarations in apollo than tg68 has lines of code! Gunnar and the  others making the apollo core are professional CPU designers and have  been working on the apollo core for seven years!

Obviously the  tg68 didn't do any pipelining (as you mentioned). Then what about  superscalar code execution? This would mean another order of magnitude  of complexity to add. We already had three times superscalar core  versions. Has any work been done on an FPU for tg68? I don't remember  seeing any code for that (but I only went through the code quickly and,  as it seems, there are several variations of it). As already mentioned  the apollo FPU was implemented a long time ago but needs testing which  is why it's not enabled in the public cores.

Making the buses  wider will sure help throughput of the tg68 but it won't make clocking  the core higher any easier either. Then what about the 64 bit mode and  new instructions (which you are invited to add if you want)? I guess  with all the other tasks required to speed up tg68 this would be of low  interest. But these enhancements will enable the apollo core to run a  whole new range of software while tg68 would still be struggling to  reach 030 or even 040 speeds (which would require a lot of progress  already).

I think the FPGAArcade has its strong points in being a  stand-alone board (of course, this advantage will be rendered moot by  the vampire stand-alone board), in emulating other systems for which no  such thing as the apollo exists and for people exclusively interested in  running legacy code  written for unaccelerated A500s or A1200s and  WHDload stuff similar to the ACA cards. But  it would be a very, very,  very long way for the tg68 core to surpass what actual Amigas could do  in 1994.

[grond]

I think you miss understand me a little. I am not suggesting the TG68 will out perform the Apollo core, I am saying then if targeted to a more modern FPGA it will get similar performance for little effort.

This is a hare and tortoise type argument. When you put tg68 in a faster FPGA to narrow the gap to apollo, apollo will already be in that faster FPGA and again far ahead of you.

"But it would be a very, very, very long way for the tg68 core to surpass what actual Amigas could do in 1994. "

It already is petty much

"Actual Amigas" meant 060 and graphics cards.

complete system compatibility is more important to me.

Yes, that makes a lot of sense. People that want to "smell and feel" an Amiga will rather put an accelerator board into an Amiga. People bored with software emulation running in some window on their desktop computer but do not want to worry about aging hardware, leaking capacitors and so on will consider an FPGAArcade or vampire stand-alone. Compatibility will be a major factor, though, as it's not very likely that software will be written having workarounds specifically for some incompatibilities of these FPGA Amiga reimplementations. Assuming you have enough Amigas to test compatibility, I wonder whether it would make sense to provide you and/or your team with a few vampires so that we could assure that there is no new software that works only on one of the two reimplementations but not on the other.

EDIT: "new software" as in drivers or any other stuff we write for our projects

[grond]

The gap will  be narrower. As I said the routing delays become similar to the logic delay. I'll run some tests next week.

America and Europe are getting closer to each other each year by continental drift...

That in itself doesn't mean much. Let us hear about your test results, any progress is good. But right now it doesn't sound like a convincing approach to have a more expensive product which has less processing power than your competition and then trying to solve this by putting in a more expensive component.

Yup, we have a HD capable graphics card with dedicated blitter, and ~ 060 performance (sans MMU and FPU) already.

That must be a very wide interpretation of "approximately". You have 28 MHz clock, the 060 at least 50 MHz. The 060 does simple instructions in one clock cycle and so do you. But the 060 can do a second simple instruction in the same clock cycle while you can't. The 060 has very good branch prediction and fast branches, you have none. The 060 has 32 bit wide buses, you still need to remove the 16 bit limitation. The 060 has fast caches, you still need to add those.

I estimate that you are currently in the 030 range of performance. If you manage to do the caches, the wider buses and improve the clock rate, you'll be entering 040ish performance. Still a long way to go as the apollo core is twice as fast as an 060 right now and still improving. Let's hear your adoom fps, Riva playback, mp3 decoding and how they are improving while you are making the core faster. For us the adoom fps is a standard test because it is more interesting than just some sysinfo MIPS.

BTW, does the fact that you didn't say anything about the offer to try to maintain compatibility between the apollo core and the fpgaarcade's implementation of AGA and 68k that you are going to consider it?