News of Free 060 Like Apollo Core License

[TrashyMG]

LOL. Majsta wasnt at Amiga32.

@Chucky So yeah talking to Gunnar on IRC, it wasn't Majsta you where talking to. You where complaining about Gunnar directly to his own face...

[amiadudeorwat]

@Chucky So yeah talking to Gunnar on IRC, it wasn't Majsta you where talking to. You where complaining about Gunnar directly to his own face...

:roflmao::roflmao::roflmao:
It would have been worth it to go just to see this.

[Methuselas]

tl;dr

Since everyone here seems to be gentlemen, I'll just come out and say it, myself:


DUDE, SHUT THE FRAK UP ALREADY!

We get it!

You don't like the Vampire nor the '80 softcore.

It's not what *YOU* want.

All I'm seeing you do is b!tch and complain about how "crappy" it is, ad nauseam.

You're as pathetic as McEwen, BBRV, Hyperion, H&P, et al.

I'm  *SORRY* that your accelerator got bumped off the Top News on Amiga.org.  I'm *SORRY* that the Vampire's FPGA softcore is more popular than your board. I'm  *SORRY* that Vampire users "don't get you", when in reality, they just  see you as a whiny crybaby, complaining for the sake of trolling.

GET OVER IT!

Let me spell it out for you: There is NOTHING in the world that makes EVERYONE 100% happy.

Nothing.....

You need to spend more time on your own threads, for your OWN board, than derailing another thread, for the sake of being toxic.

Speaking of your board. Let's get a few things out of the way:

ZOMG! You ripped off Commodore's original '40 design! That's theft!

ZOMG! You turned it into an '60 board, which means it's not "pure!"

ZOMG! You added ram to it, which it didn't have before and that means it's not original hardware. It's FAKE!!!!

You see how ridiculous you sound?

*rolls eyes*


You  know, Chucky, it's people like you, that made people like me leave the  Amiga scene. I was offered a free Vampire, in exchange for testing  trackers, by making mods. It never happened, but it wouldn't matter,  'cos my heart isn't in it as I am so SICK and TIRED  of the  incessant b!tching, moaning, complaining  and whining of scenesters that  act like the Amiga is the second coming or the frakking Kiwsatz  Haderach.

I was one of the ones, in the early 2000s that wanted a  switch to x86. I wanted hardware, I could buy off the shelf, on my own  and be done with it. I didn't get that and when the first of the over  priced PPC boards started coming out, I voiced my opinion, but I wasn't  as petulant as you're coming across. I didn't CONSTANTLY gripe and piss  and moan about what I didn't get, what I didn't have, what it should  have been.

I moved on.

That's something YOU need to do. Move on.

And do us all a favor. Go set up a play date with Atheist already!

That's MY 2p.

I'm  going to go back to lurking now. Don't bother responding and to  everyone else, especially if we've spoken on a personal level, my  apologies for this, but this nutbag needed to be told off.


PS - Where the frak is the moderation around here? Has it REALLY gotten this bad? Geez.

-M

[Gulliver]

I am just wandering what would people say if this offer included exactly the same core we know, but was only advertised as being a fast 68020 feature reduced compatible VampireV2 core? Would any developer be interested in it anyway?

Or is it that Gunnar is so unfriendly/difficult to work with/to deal with, that no one wants to bother with his offer?

I have seen all known Amiga hardware developers reject his offer. So either the core sucks or Gunnar sucks or something else sucks. Which one is it?

[Chucky]

ok I mixed up people. AGAIN!..  this is my handicap.. so. sure.  put me in a odd situation.  used to it. move along..  nothing to see here...   me and faces %&$#?@!%&$#?@!%&$#?@!%&$#?@!ing never works..  thats it.  laugh about it? please do.  it is on me.  used to it...  




Anyway.. interesting how a simple thing as pointing out that things like a MMU that we are used to can fork to this..

and.. I see that many HW developers reject this.  and I know things JUST like the  MMU is one for the main reasons. and THIS thread is a good reason why.  but yeah..  better maybe be quiet..  fool more people into the hype. (if they DO know that they are buying something that can do more new incompabilities. FINE!  that's what I knew when I back in the days bought a new CPU card.. I was always early with them all (except 060 due to price))
but now. 20+ years later.. it is about preserving our old memories.

we STILL need that debuggingtools to get developers on the platform. and without the developers, platform is dead like the PPC.

demosceners will have no interest as they like to show off what they can do within the limits there is.. remove them and shadertoy.com is suddenly more intersting.

Anyway.. moderator: please.  remove this thread completley.  put in the first post..  I will stay out..


Some day. when I get time.  I will post my blogpost with more detailed info about pros (YES! there are!) and cons..

but..  repeat Iknow.  HW designers declined this generous offer.. think about why...

[TuKo]

Hi Chucky,

If you refer as "majsta" to "the guy to who you gave ShK's Fusion Forty", it was actually me.

You told me that you will write an article on your blog to explain why you don't like Vampire and after will stop bashing it. I found it pretty smart coming from you because it means you understand what you are doing.

Reading all this, it's pretty obvious you still haven't written it :-)

[Chucky]

ok sorry for mixing up!.   it is me and faces.  just never f... works.  but still I am doing that same %&$#?@!%&$#?@!%&$#?@!%&$#?@!ing thing EVERY FUC. TIME..  


it is halfwritten.

so!  serious: please anyone.  give me ANY arguement. (in some kind of private way)  for pros and cons of what YOU think..

I will do a calm (not forumwise.   ) argument.

and as I told:  I LOVE the hwardware. it is the implementation that I have issues with.  and the bad handling of the feedback.

anyway!.. I am out.

[gregthecanuck]

Chucky - I suggest you wait until the 2.7 core is out and some user feedback happens.

[Chucky]

good idea..  and maybe prep my vamp with it..

(but if it requires me to register. well this will not happen unless taking a copy from someone)

[OlafS3]

I am just wandering what would people say if this offer included exactly the same core we know, but was only advertised as being a fast 68020 feature reduced compatible VampireV2 core? Would any developer be interested in it anyway?

Or is it that Gunnar is so unfriendly/difficult to work with/to deal with, that no one wants to bother with his offer?

I have seen all known Amiga hardware developers reject his offer. So either the core sucks or Gunnar sucks or something else sucks. Which one is it?

I do not understand what people are thinking... Gunnar and the others in the team have a plan with priorities behind what in which order and how it will be implemented. That would only change if someone offers money or when there are serious developers who help them implementing something f.e. by doing new software showing the new features. When they asked about that a long silence. Now they offer what they have for free because they think it might be interesting outside there is only moaning and people claiming this or that is needed otherwise it is not useful, even though that would mean lots of work and delays for the other projects/developments. It is simply a take or leave it offer, if the few hardware developers think it is not useful they are still free to buy limited original processors. No problem...

[johnklos]

All of this back and forth about pros and cons seems counterproductive.

I'm in the camp of people who aren't interested in FPGA accelerators until they can do at least what a real m68k can already do, and that means an FPU and an MMU. I haven't added anything to these threads because nobody is talking about a compatible FPU and a compatible MMU in these products, but the naysayers and the apologists going back and forth are just making this all too annoying.

What I would genuinely like to see would be real, technical information about the technical roadblocks for a proper compatible implementation.

As far as I'm concerned, there are so few differences between the m68040 and m68060 that a core could and should be a superset of both. An option can be set at boot time to determine if the exception stack and status register should match one or the other. Options to enable / disable superscalar and branch folding in the PCR and CACR are a superset of the '040, and 64 bit instructions from the '040 can be implemented instead of trapped without breaking anything.

The FPU could easily be a superset of m68881/m68882/m68040/m68060 since anything emulated by the M68060SP can just be made in to directly working instructions.

With regards to an MMU, there are many differences between the m68040 and m68060 MMUs, so one would have to be chosen, probably based on whether there's enough support for the '060 MMU model. The access error stack frame is more detailed in the '060 MMU, the '060 has the PLPA instruction instead of PTEST to translate logical to physical addresses, the cache modes for the TTRs are different, and so on.

I wish I knew more about FPGA development because I think it'd be interesting to try to implement an MMU. It'd certainly be challenging!

[OlafS3]

All of this back and forth about pros and cons seems counterproductive.

I'm in the camp of people who aren't interested in FPGA accelerators until they can do at least what a real m68k can already do, and that means an FPU and an MMU. I haven't added anything to these threads because nobody is talking about a compatible FPU and a compatible MMU in these products, but the naysayers and the apologists going back and forth are just making this all too annoying.

What I would genuinely like to see would be real, technical information about the technical roadblocks for a proper compatible implementation.

As far as I'm concerned, there are so few differences between the m68040 and m68060 that a core could and should be a superset of both. An option can be set at boot time to determine if the exception stack and status register should match one or the other. Options to enable / disable superscalar and branch folding in the PCR and CACR are a superset of the '040, and 64 bit instructions from the '040 can be implemented instead of trapped without breaking anything.

The FPU could easily be a superset of m68881/m68882/m68040/m68060 since anything emulated by the M68060SP can just be made in to directly working instructions.

With regards to an MMU, there are many differences between the m68040 and m68060 MMUs, so one would have to be chosen, probably based on whether there's enough support for the '060 MMU model. The access error stack frame is more detailed in the '060 MMU, the '060 has the PLPA instruction instead of PTEST to translate logical to physical addresses, the cache modes for the TTRs are different, and so on.

I wish I knew more about FPGA development because I think it'd be interesting to try to implement an MMU. It'd certainly be challenging!

they never ruled something out for future but it is a question of priorities. They need a advanced AGA compatible chipset for standalone so this is priority, the same is true for all new features of the V4 generation, f.e. new drivers are needed. FPU will be in hardware where possible or as software emulation depending on FPGA size. All is left for naysayers is compatible MMU. It has no high priority because not much software uses it, only development software. Normal user related software not needs it at all. They do the project for average users, not the few developers who need MMU. As I understand it they also will offer development software using the implemented MMU replacing the old software, perhaps that already ends the discussions. People should simply wait. It is a project by a small group of people doing it in their spare time. They do it because they want to do it. If people want them to do different things they should offer money or give good very good reasons for it. I have not seen anything like that, just the typical whining. If someone bought a vampire in past and is unhappy with it sell it, I am pretty sure that there is no problem to sell it. If these people keeps the hardware than make a proposal what you would like to have, developers will read it and perhaps do it later or not because of good reasons but the agressive bitching only makes bad impressions.

[Iggy]

I have always wondered why people in Amiga scene want to comment things that they are not interested? Previous example was Amiga OS4, every thread got tens of post from MorphOS people who are not interested Amiga OS4.

Seems that Vampire is now in that position.

I'm not interested Vampire, develobment took wrong course. For me that is end of story. I usually just don't read Vampire threads.

What is wrong with you people?

Only thing wich I have against Vampire team, is that they named their product to Apollo. Now it is very annoying to look anything (real) Apollo accelerator related from internet.

***************************************************************
There should be limit how many times one person can comment to one thread.
***************************************************************

Commenting 100 posts of nonsense is just pointless and ruins interesting news threads.

This particular kind of nonsense really pisses me off.
OK, I have MorphOS systems, I'm buying an X5000 in the future, BUT I own an A2000.
So why don't you censor yourself, or just STFU, instead of critisising me for having an opinion about something I'd like to buy?

The compatibility issues ARE important. And since high end accelerators for the A2000 are not common, this device is about the only option.
On one side you talk about future goals, and then you say we need to judge the device only on its current feature.
You keep telling us how great everything is, and what a wonderful person Gunnar is, then you attack anyone who dares challenge your Rose colored glasses viewpoint.

Apparently none of you have experience in actual commerce, because your lack of social skills would doom you to failure if you tried to use these tactics on an average consumers.

Your eccentric approach is turning people off and your losing potential supporters.
It's immature and offensive.

[soviet]

Could be cool if somebody can post a list of incompatible software?

From my experience i don't see any particular issue on the software i have run.

Even old games that if run out of whdload could crash on my old 68060 run nice and dandy on the vamp.

Also you don't even need the setpatches and the 68060 libs that if not installed could crash the os even before getting to the desktop.

That for me look a lot more compatible than a plain 68060.

[grond]

@Chucky:  

If you were to implement the integer CPU, an FPU, an MMU, and the chipset, in which order would you tackle those?  

I think it is reasonable to do the integer CPU first because else you cannot execute any code. The FPU should be implemented before the MMU because there is far more code using the FPU than the MMU. So the order Integer, FPU, MMU makes a lot of sense. FPU is in the making so MMU will have to wait. This is where we are now and it makes a lot of sense.  

What about AGA and SAGA? Obviously there is some confusion about what SAGA is. SAGA is an enhanced AGA with an additional chunky playfield. The chunky playfield is controlled via registers in the Amiga register address range and can be controlled by the copper. Since AmigaOS doesn't know about chunky playfields, there is a P96 driver for the chunky playfield which makes this chipset feature appear as standard RTG even though it can/could do much more (e.g. copper scrolling and copper palette shading).

The most notable advantage of SAGA is that the screen DMA can read directly from the local Vampire RAM which is faster than previous fastmem but functionally chipmem. All previous RTG software was slowed down by outdated hardware buses with something like 16 MB/s maximum throughput. The Vampire does hundreds of MB per second.  

So far we have only seen the chunky playfield part of SAGA, i.e. the part that seems to be simple RTG but is implemented in an Amiga-way, in public releases. The Gold3 previews already have the AGA chipset, i.e. the planar part of SAGA added but there are still some bugs. You could call this the AGA in SAGA. Simply put SAGA = AGA + RTG on one and the same screen.  

I think it wouldn't make any sense to make an effort to purposely slow down the planar part of SAGA to AGA speed. It is not even required for (my broader understanding of) compatibility. I can understand that democoders want to work around a known set of limitations and that for this reason the Vampire/Apollo project doesn't make sense for them. Well, so be it, it is not as if the demosceners were such a big part of the Amiga usergroup. Their wishes just don't comply with the goals of the project and this is not going to Change no matter how much "input" and "listening" there might be.  

Now let's return to the CPU: you are very emotional about AMMX, hyperthreading and 64 bit extensions which you consider crap that is not going to get used and that take FPGA real estate that could be used for stuff that does get used like FPU and MMU.  I know that you do not agree to Gunnar's vision but perhaps this explanation will make you see that there is an inner logic to the sequence in which the individual items on the TODO list are tackled.  

Gunnar wants to improve the 68k ISA and extend it to what it might look like if Motorola hadn't dropped the ball over 20 years ago. This is what drives him, this is why it is happening at all.

You want something different. Everybody understood that and the project is not going to change its goals for you and those who think alike no matter how much you voice your opinion and personal preferences. You are free to conclude that Apollo/Vampire does not cater your very well defined needs and that's all there really is.  

Anyway, if one wants to do a modern extension of the 68k architecture, it immediately follows that the 8 address, 8 data and 8 FPU registers just aren't enough. There is a need for 64 bit datatypes handled in the integer part while the need for 16 bit datatypes is almost zero in today's computing. More registers and especially more FPU registers are a must.

Whether you agree with this vision or not, if you want to end up with such a CPU, you can either build a 32bit CPU, throw it away and start with another one that is 64bit OR you build a 64bit CPU right from the start which means to have those additional registers and to make them wider right from the start. Adding a few AMMX instructions that actually work on those wide registers then is far less work than building and testing an FPU.

And AMMX actually does get used not only in RiVA but more importantly in the P96 driver. So even the totally-anti-AMMX user will have some benefit from the presence of AMMX even if it remains completely hidden from the user.  

The same goes for the FPU itself: if you implement a 68k FPU with just 8 registers and everything the way it used to be, then all this work will go to the trashcan if you do an FPU afterwards that can access 24 registers. It is simply easier to first implement the _superset_ and then the _subset_ based on the finished superset.  

The AMMX parts and additional registers are the foundation of a house that will have an FPU and MMU as a roof. You simply can't start with the roof and then build the foundation.  

Another thing you have addressed multiple times is how femu is not better than the 68060.library approach. This is wrong for a simple reason: femu will be included in the core and thus not visible to outside code, most of all it cannot be overwritten by accident. More importantly femu will be present from power-on and does not need to get loaded from disk or wherever. This means that thanks to femu the FPU looks to any code exactly like an 882 FPU right after power-on/reset.  

When you compare the Apollo FPU in its current state to the 040/060 FPU, the Apollo FPU is just as well a software/hardware mix as the 040/060 FPUs are. While the 040/060 FPUs have a fixed distinction between hardware instructions and emulated instructions, the Apollo FPU is flexible and can be handtuned for the FPGA at hand. For a smaller footprint you can implement less instructions in hardware, for a larger FPGA you can implement all instructions in hardware. I think that is actually a very interesting approach.  

It is unfortunate that the FPGA in the V2 is too small for the full-featured Apollo Core. However, please understand that this isn't a concern to Gunnar. The Vampire isn't his baby, it is a card that licenses his core and is now too small to hold all of it. He doesn't develop the core for the Vampire, he develops the core as an end in itself.  

I hope this clears up a few things...

[smf]

 

It is unfortunate that the FPGA in the V2 is too small for the full-featured Apollo Core. However, please understand that this isn't a concern to Gunnar.

So i have been ripped off twice again and sits on hardware for a fortune that will not be fully functional for me just like the V600? ;(

I knew i should have stayed away from it when i bought the second card but i was even more stupid when i bought the third one.