English Amiga Board Amiga Lore


Go Back   English Amiga Board > News

 
 
Thread Tools
Old 19 May 2016, 15:50   #501
cmsj
Registered User

cmsj's Avatar
 
Join Date: Feb 2016
Location: London / UK
Posts: 140
Quote:
Originally Posted by Daedalus View Post
It has to be programmed to behave as a 68k CPU, so it's hardware emulation.
We're really splitting hairs, but it's not emulation. The FPGA is *configured* to be an Apollo processor, which is mostly compatible with a Motorola 68000 (and will get more compatible as the cores improve).

It's not emulation, emulation involves translating one system into another. That's not what is happening here, the logic elements inside the FPGA are being configured to be CPU hardware. For it to really be emulation, the FPGA would have to be a processor in its own right, and be translating m68k instructions into its own internal instructions. That is definitively not what is happening here.
cmsj is offline  
AdSense AdSense  
Old 19 May 2016, 15:52   #502
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 1,990
But does it run it 100% cycle-exact in every possible case for every possible combination of instructions? And what about different FPGA implementations - what if your design is more efficient than my design, resulting in lower propagation times and therefore faster throughput? These are the differences I'm talking about. Your point about the 68020 is a strange one, and is what I was trying to say about the 68060. Yes it runs 68k code, as does the Vampire, but as you say, this doesn't mean it's 100% compatible. It can't be, otherwise there's be no advantage over a 68000. And when you're troubleshooting something as marginal as the issue that was being discussed, the fewer marginal variables like this the better.
Daedalus is offline  
Old 19 May 2016, 15:56   #503
demolition
Unregistered User
demolition's Avatar
 
Join Date: Sep 2012
Location: Copenhagen / DK
Age: 37
Posts: 3,175
An FPGA could run 68000 code 100% cycle-exact if that was what you wanted. But this is not the goal of the Apollo project since they want to make something that operates a lot faster. That the Apollo is not 100% cycle exact to a 68000 is not due to it being in an FPGA. My point with the 68020 is that it is also not cycle exact compared to a 68000 as it is a different design.
demolition is offline  
Old 19 May 2016, 15:57   #504
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 1,990
Right, it's not emulation in the sense of WinUAE or whatever, using a CPU to translate foreign instructions and what not. It is imitating a 68k CPU. Emulation has a broader meaning than software translation of CPU opcodes, and anything that changes its behaviour to mimic something else is emulating that other thing. From the Cambridge English dictionary, just for example:

"to copy something achieved by someone else and try to do it as well as they have".

Just because it's common to think of it in software terms doesn't mean that's the only meaning. But, as you say, we're splitting hairs here. The important point is that it doesn't behave 100% identically to a 68k CPU (because if it did, what would be the point?), so ruling it out of troubleshooting reduces the number of variables to consider.
Daedalus is offline  
Old 19 May 2016, 15:58   #505
kwaku85
Registered User
 
Join Date: Apr 2012
Location: Krakow/Poland
Posts: 20
Quote:
Originally Posted by Daedalus View Post
Give it a rest guys, this isn't the place for 68k bashing, Jens bashing or Vampire worship, nor Vampire bashing or 68k worship.

Excited and all as I am for the Vampire, it's getting tiring reading crap like this polluting otherwise interesting threads. Yes, it's a "real" CPU, but that doesn't mean it behaves identically to any 68k CPU. It has to be programmed to behave as a 68k CPU, so it's hardware emulation. There's no escaping that fact, and it doesn't make it inferior to a 68k, just different. Many of the differences between it and a real 68k CPU can rightly be considered improvements, but this makes it *different*, in much the same way as a 68060 is different from a 68000. And these improvements/differences will cause different behaviour in certain circumstances, again like the difference between a 68060 and a 68000. This adds extra variables to the type of troubleshooting that's going on, so it only makes sense to discount it from testing for now.

What do you hope to achieve by derailing a thread like that? Let the Vampire speak for itself, which shouldn't be a problem if it lives up to the hype.
The real problem is someone try to discourage ppl to something, because care of own bussiness. It's not fair. Most unfair is provading false informations about something about haven't any knowledge.
About your post- you can name it as emulation, even if it's not. If Apollo team will put inside Intell CPU and emulating HW to converse 68k->x86->68k instructions, it will be an emulator. FPGA is configurable hardware, you can create everything inside, it's not emulating, it's building. Real hardware building. That's all.
Apollo team just make their own 68k compatible CPU with peripherials like RTG, uSD, IDE, FastMem and many not existing before instruction inside.
How much it's stable and compatible? Time will show, today it's really good, many people work on it and many other will start for sure. Apollo team will grown and give true support. REMEMBER- SUPPORT. Someone should teach something about this little word, mayby google can help.
That's all from my side, name it emulator, simulator, refrigerator or watever you like. No one care, it works like a charm and become better and better every day.
kwaku85 is offline  
Old 19 May 2016, 15:58   #506
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 1,990
Quote:
Originally Posted by demolition View Post
But this is not the goal of the Apollo project since they want to make something that operated a lot faster. That the Apollo is not 100% cycle exact to a 68000 is not due to it being in an FPGA. My point with the 68020 is that it is also not cycle exact compared to a 68000 as it is a different design.
And this is my point. Glad we're in agreement here. I don't care what it is, I'll probably buy one for an A1200. I'm not having a go at FPGAs, I'm just being realistic about what the Vampire is.
Daedalus is offline  
Old 19 May 2016, 16:04   #507
demolition
Unregistered User
demolition's Avatar
 
Join Date: Sep 2012
Location: Copenhagen / DK
Age: 37
Posts: 3,175
Quote:
Originally Posted by Daedalus View Post
And this is my point. Glad we're in agreement here.
Yay, a discussion on an Internet forum ended with two people agreeing.
From your dictionary quote, I can see how it can be called emulation. They are mimicking the 68k core but since they have not copied it directly (and probably don't have access to the original blueprints), it can be called emulation by that definition.
Lots of people think of emulation in terms of WinUAE and that is something very different indeed. Many people seem to think that the Vampire would be more 'genuine' if it had an ASIC instead of an FPGA but that is important to clearly state that it is the same, only the ASIC could run at a higher clock.
demolition is offline  
Old 19 May 2016, 16:07   #508
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 1,990
Quote:
Originally Posted by demolition View Post
Yay, a discussion on an Internet forum ended with two people agreeing.
Where's that dancing banana?
Daedalus is offline  
Old 19 May 2016, 16:10   #509
demolition
Unregistered User
demolition's Avatar
 
Join Date: Sep 2012
Location: Copenhagen / DK
Age: 37
Posts: 3,175
Quote:
Originally Posted by Daedalus View Post
Where's that dancing banana?
demolition is offline  
Old 19 May 2016, 17:17   #510
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 330
Quote:
Originally Posted by Daedalus View Post
I'm not having a go at FPGAs, I'm just being realistic about what the Vampire is.
The one important thing missing is that you can have an ASIC made from the apollo core code without any difficulties (just lots of money required). The apollo core is developed exactly like any modern processor is (by professional processor developers, as a matter of fact) and it uses the same tools for the same ends. The VHDL code is just put through a logic synthesizer for an FPGA instead of one for a hardware library of an ASIC manufacturer. It's basically the difference between prototyping and mass production. Nobody would 3d-print mainstream computer cases but would use injection molding. However, for a market as limited as the amiga market 3d-printing may be an option. The same goes for FPGAs and ASICs: nobody would put an FPGA into a mobile phone but using FPGAs for amiga turbocards is certainly a good idea. However, in both cases the actual development work is the same: you need to design a proper 3d model (cases example) and you need to write VHDL code (processor example) REGARDLESS of the actual manufacturing method.
grond is offline  
Old 19 May 2016, 17:30   #511
Schoenfeld
electricky.
 
Join Date: Jun 2010
Location: out in the wild
Posts: 1,232
I referred to Vampire as "not a real 68k" because some months ago (over a year? can't remember) I suggested to help the project by giving it a scientific touch: Create a test suite for the target 68k CPU and actually *prove* that it is equal to a 68k. I know it can be done, and I would certainly only accept it as "real 68k" if there is a test suite, and the Apollo core passes this test suite.

When I suggested this on the A1K forum, I have been badly attacked, because everyone was convinced that this is not necessary and it would only make things too complicated and too expensive.

So let me bring this back to topic: While there is no test suite that *proves* equality over the whole instruction set, cache+MMU status, I do not consider Vampire a 68k CPU, hence there is no support for any of my products working properly with Vampire.

This support policy will change as soon as a test suite is available.

Jens
Schoenfeld is offline  
Old 19 May 2016, 17:52   #512
roomeo
Registered User

 
Join Date: Aug 2014
Location: Telemark
Posts: 203
How could we interpret all this from "its not a real 68k"?

However, thumbs up for the clarification.

Now..how are things going with tracking the RR issue?
roomeo is offline  
Old 19 May 2016, 18:08   #513
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 330
Quote:
Originally Posted by Schoenfeld View Post
I referred to Vampire as "not a real 68k" because some months ago (over a year? can't remember) I suggested to help the project by giving it a scientific touch: Create a test suite for the target 68k CPU and actually *prove* that it is equal to a 68k. I know it can be done, and I would certainly only accept it as "real 68k" if there is a test suite, and the Apollo core passes this test suite.

...

So let me bring this back to topic: While there is no test suite that *proves* equality over the whole instruction set, cache+MMU status, I do not consider Vampire a 68k CPU, hence there is no support for any of my products working properly with Vampire.
The proof of the pudding is in the eating. And even if you don't try it, it remains a very tasty pudding.


Quote:
When I suggested this on the A1K forum, I have been badly attacked, because everyone was convinced that this is not necessary and it would only make things too complicated and too expensive.
Link please, I want to read those bad attacks.
grond is offline  
Old 19 May 2016, 18:20   #514
roomeo
Registered User

 
Join Date: Aug 2014
Location: Telemark
Posts: 203
A lot of people will get the Vampire. So if hypotheticaly there is incompatibility with either of icomp's products how will people think? "I'll better get rid of the Vampire then"... No way..

So regardless of the criteria you set for the vampire, you should support it either way. I can agree that the goal of the Apollo-core could be a moving target and hard to support. (an uneducated statement btw) But in the end, it is likely to be the new standard.

Last edited by roomeo; 19 May 2016 at 21:32.
roomeo is offline  
Old 19 May 2016, 21:27   #515
kwaku85
Registered User
 
Join Date: Apr 2012
Location: Krakow/Poland
Posts: 20
Quote:
Originally Posted by Schoenfeld View Post
I referred to Vampire as "not a real 68k" because some months ago (over a year? can't remember) I suggested to help the project by giving it a scientific touch: Create a test suite for the target 68k CPU and actually *prove* that it is equal to a 68k. I know it can be done, and I would certainly only accept it as "real 68k" if there is a test suite, and the Apollo core passes this test suite.

When I suggested this on the A1K forum, I have been badly attacked, because everyone was convinced that this is not necessary and it would only make things too complicated and too expensive.

So let me bring this back to topic: While there is no test suite that *proves* equality over the whole instruction set, cache+MMU status, I do not consider Vampire a 68k CPU, hence there is no support for any of my products working properly with Vampire.

This support policy will change as soon as a test suite is available.

Jens
Hehe, You talk as politicians. Mayby Apollo team not need to prove anything to any one? Mayby we should change sides- mayby you should prove Apollo core is not "a real 68k"?
People like Gunnar know exactly how 68k works and how it's build. They remove any bottleneck from 68k CPU core and add new great fetures. They add 64bit architecture! So, with all this knowledge and having list of every instructions inside any 68k CPU, and then- having skills to build whole CPU inside FPGA and doing this now with many success- can they be wrong? Can they create "not real" and bad working 68k CPU inside this great "Logic Lego"? With all this knowledge and skills?
They not talk. They just do what they promised at the start, Vampire card exist and works, works pretty good. Have bugs yet, but can You imagine they can't find them and not fix them inside their own CPU? I can't. It's ridiculous.
Creating testcase. It's lot of work. Mayby too much. They test any existing software for amiga and all is working. Want see testcase result? Mayby try to write testcase by Yourself? Team will be very thankfull for this hard work I think.
kwaku85 is offline  
Old 19 May 2016, 21:58   #516
Amon_RA
Registered User
Amon_RA's Avatar
 
Join Date: May 2015
Location: Belgium
Posts: 99
I'm really astonished that people actually expect compatibility and support on things plugged into emulated hardware (which doesn't even have a proper test suite). That's like expecting add-ons intended for real Amiga hardware to actually work on a minimig... and blame the add-on vendor if it doesn't. I'm sorry but that's beyond ridiculous. The fact that Jens even bothers to explain and even considered helping the project says a lot about his willingness to help the Amiga community further. I really don't understand the reactions of some people here, it's like they are a bunch of grumpy old men yelling at clouds... what a waste of time.
Amon_RA is offline  
Old 19 May 2016, 22:07   #517
roomeo
Registered User

 
Join Date: Aug 2014
Location: Telemark
Posts: 203
I, for one, don't expect a lot of support from icomp. I'm just pointing out that whatever you want to call vampire, it can't be ignored. By doing so , many potential customers could be lost. That would just be silly.
roomeo is offline  
Old 19 May 2016, 22:20   #518
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 330
Sorry, but Jens explaining to a group of professional CPU developers (who did POWER8 and some ARMv8 among others) how to develop a CPU properly is like a cow explaining a dairy farmer his business. There is a "test suite", of course. There are hundreds if not thousands of asm programs that we call testcases. Some are only a few lines, some are hundreds of lines long. They are verified on real CPUs and tested in simulation. Nobody has to prove anything to Jens S. He can mind his own business and develop superexciting accelerators slower than what I had twenty years ago.
grond is offline  
Old 19 May 2016, 22:35   #519
clebin
Registered User
clebin's Avatar
 
Join Date: Apr 2012
Location: Cardiff
Posts: 248
Quote:
Originally Posted by Amon_RA View Post
I'm really astonished that people actually expect compatibility and support on things plugged into emulated hardware (which doesn't even have a proper test suite).
I don't think anyone's said that, have they? The topic was the A3640 bug and the original mention of the Vampire was just to be helpful. To quote: "just in case the CPU type would have an impact." Jens didn't have to respond in the way he did.
clebin is offline  
Old 19 May 2016, 22:37   #520
roomeo
Registered User

 
Join Date: Aug 2014
Location: Telemark
Posts: 203
Can't an existing test suite for real 68k be used?
roomeo is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
New USB HID mouse / USB Joystick / Gamepad USB adapter for the classic Amiga spidi News 187 24 October 2016 12:11
WinUAE USB Amiga hard drive issue (2014) JayEff support.WinUAE 2 04 April 2014 18:31
BetterWb 3.0 06-OCT-2013 gulliver News 20 06 November 2013 20:22
Away At Amiwest Show (Oct 20 - 26) amigakit.com MarketPlace 1 17 October 2010 23:16
Meet SAM @ ANT Oct 12th 2008 (UK) Mikey_C News 22 14 October 2008 13:52

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 03:58.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.27544 seconds with 12 queries