English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 31 July 2015, 12:37   #221
kolla
Registered User
kolla's Avatar
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 765
Kipper2k: some videos on youtube of The Full Apollo Core, demonstrating actual compatibility with OSes (OS3.9, maybe MacOS via Fusion or Shapeshifter) and productivity software (especially 040 and 060 optimized), would be excellent.

Quote:
Originally Posted by meynaf View Post
USA did land guys on the Moon. They announced this themselves. But maybe it's wrong ?
The moon landing Apollo missions were monitored and verified by multiple scientific communities spread around the world, and even the big enemy and competition, the Soviet Union was following the missions closely.

http://history.stackexchange.com/que...e-moon-landing

Regarding the Apollo mission that is topic of this thread, the story is different.

Last edited by TCD; 31 July 2015 at 16:22. Reason: Back-to-back posts merged.
kolla is offline  
AdSense AdSense  
Old 31 July 2015, 13:00   #222
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,457
Quote:
Originally Posted by kolla View Post
Regarding the Apollo mission that is topic of this thread, the story is different.
If the story is different, just tell me why would Gunnar lie.
meynaf is offline  
Old 31 July 2015, 13:37   #223
kolla
Registered User
kolla's Avatar
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 765
I'm not saying he's lying, just that "proof" is in showing running working software.
kolla is offline  
Old 31 July 2015, 15:02   #224
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,457
Quote:
Originally Posted by kolla View Post
I'm not saying he's lying, just that "proof" is in showing running working software.
I'm afraid that without testing the physical board yourself, you can't have any proof of any sort.
meynaf is offline  
Old 19 August 2015, 15:12   #225
happymondays
Registered User

 
Join Date: Aug 2014
Location: Szeged
Posts: 141
Are there any updates on these boards (availability and specs)? I am very excited about this project and really hope to have an end product under the Christmas tree to cheer up my A500.
happymondays is offline  
Old 19 August 2015, 19:19   #226
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 43
Posts: 1,418
@happymondays Its been real quiet for a week or so when the apollo-core.com forum was wiped. Not seen any recent news from Majsta either.
Hopefully theres nothing to worry about and they are simply experiencing a texhnical glitch with their web servers.

But the last news we got was that Majsta was about to do another resesign to accomodate larger RAM.
eXeler0 is offline  
Old 19 August 2015, 21:15   #227
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,457
Technical glitch with the web server ? I don't think so. It's not the first time the whole forum gets deleted.
meynaf is offline  
Old 19 August 2015, 22:44   #228
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 43
Posts: 1,418
Quote:
Originally Posted by meynaf View Post
Technical glitch with the web server ? I don't think so. It's not the first time the whole forum gets deleted.
I honestly have no idea what happened, but I ventured a guess...
There could be a couple of other reasons of course..
eXeler0 is offline  
Old 20 August 2015, 00:57   #229
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by meynaf View Post
I'm afraid that without testing the physical board yourself, you can't have any proof of any sort.
are we getting into epistomology now?

i think, therefore i am... i think...
Mrs Beanbag is offline  
Old 20 August 2015, 01:56   #230
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,546
Waiting 20 years for such card so i can wait another year...
pandy71 is offline  
Old 20 August 2015, 02:02   #231
Adrian Browne
Jackie Chan
 
Join Date: Mar 2012
Location: Ireland
Age: 40
Posts: 652
Ive never heard of the apollo forum being deleted before.
I wonder if they infringed upon someones patents. The apollo core is an evolution of the old motorola chipset right?
Adrian Browne is offline  
Old 20 August 2015, 02:36   #232
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Adrian Browne View Post
Ive never heard of the apollo forum being deleted before.
I wonder if they infringed upon someones patents. The apollo core is an evolution of the old motorola chipset right?
All the posts on the apollo forum were wiped once before it was opened to the public. Someone might have said it was a "restart" corresponding to a new direction with the core or it could have had something to do with the content of more recent threads at the time. Meynaf wasn't the only one who considered the wipe annoying as it had useful technical information (much as the Natami forum does). Maybe if you had known some of the insiders involved with the Natami project then you would understand the "problem". Meynaf and I are strongly opinionated but we are pretty easy going team players. There are reasons why we are not actively involved with the apollo project anymore.
matthey is offline  
Old 20 August 2015, 12:23   #233
jbenam
Italian Amiga Zealot

 
Join Date: Jan 2009
Location: Italy
Age: 29
Posts: 1,226
More drama coming from some of the people involved with the old Natami project? Colour me surprised

I hope they resume the work on it, though.
jbenam is offline  
Old 20 August 2015, 12:33   #234
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 252
Quote:
Originally Posted by meynaf View Post
Which is a proof that, during all that time, it was perfectly doable - and that its cost isn't as high as some said.
Of course it is/was doable - but your assertion that the cost wasn't high is fundamentally flawed.

It may be that for this implementation the bottlenecks were elsewhere and/or that some other feature made this easier to implement.

But MOVEP is still a problem instruction in a general implementation.
Megol is offline  
Old 20 August 2015, 14:40   #235
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,457
Quote:
Originally Posted by Megol View Post
Of course it is/was doable - but your assertion that the cost wasn't high is fundamentally flawed.
You argue against something i have not written.
I've written "not as high as some said", not "not high at all".


Quote:
Originally Posted by Megol View Post
It may be that for this implementation the bottlenecks were elsewhere and/or that some other feature made this easier to implement.

But MOVEP is still a problem instruction in a general implementation.
A problem instruction, yes, but up to what point ? Many instructions can be problematic. This is life. For example MOVEM is a magnitude more difficult than MOVEP.
meynaf is offline  
Old 20 August 2015, 17:14   #236
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 252
In my processor design MOVEM was easier to support than MOVEP. Now that is a dead project, not a complete 68k processor and optimized for high clock speeds (for a FPGA that is) so it may not have been representative. Still:

MOVEM is only complicated in that it uses a special format to indicate registers to store/load. Otherwise it consists of straight stores/loads using increment or decrement mode. This is handled with a sequencer in parallel with the decoder.

MOVEP in comparison require splitting/concatenation of register data, something not used elsewhere in the design. This means either one have to complicate the cache access path or use µops+a temporal register to handle that. It also stores/loads bytes while increasing the address by two so this requires special handling.

In short MOVEP touches more critical spots than MOVEM. For a speed demon design this can be a huge problem.
Megol is offline  
Old 20 August 2015, 21:18   #237
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Megol View Post
In short MOVEP touches more critical spots than MOVEM. For a speed demon design this can be a huge problem.
They are both tricky to implement but the most important difference is how often they will be used. MOVEM needs to be as fast as possible because it would remain very important for any future 68k CPU. MOVEP is an ancient kludge which has very limited modern usefulness and can be slow. It is nice that Gunnar figured out a way to avoid trapping MOVEP but it was never a high priority. Now if MOVEM could move a pair of registers to and from memory each cycle then he has struck gold .
matthey is offline  
Old 20 August 2015, 21:22   #238
Adrian Browne
Jackie Chan
 
Join Date: Mar 2012
Location: Ireland
Age: 40
Posts: 652
So trouble brewing in Apollo core world eh?
Oh boy. A drastic change in direction would spell the end for this project at this point, surely.
Adrian Browne is offline  
Old 20 August 2015, 22:01   #239
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,457
Quote:
Originally Posted by Megol View Post
MOVEM is only complicated in that it uses a special format to indicate registers to store/load. Otherwise it consists of straight stores/loads using increment or decrement mode. This is handled with a sequencer in parallel with the decoder.
So once MOVEM.L is done, doing MOVEM.W is peanuts ? (As the special format is what's tough here, when you have it, you can reuse it, right ?)


Quote:
Originally Posted by Megol View Post
MOVEP in comparison require splitting/concatenation of register data, something not used elsewhere in the design. This means either one have to complicate the cache access path or use µops+a temporal register to handle that. It also stores/loads bytes while increasing the address by two so this requires special handling.
But many instructions are in this case. They require a special handling that's not reused elsewhere, e.g. DIV is in this case.
Others like LINK need to use several µops.

Of course if the problem comes from the total number of subops you have (i.e. the total for all instructions), i can understand it becomes a big problem.


Quote:
Originally Posted by Megol View Post
In short MOVEP touches more critical spots than MOVEM. For a speed demon design this can be a huge problem.
MOVEM needs to be reasonably fast, while MOVEP does not. Isn't it easier when it can be slow ?
Basically it's just a bunch of shift + move.b, and these already exist in the cpu. It's not like if we want it to run in 1 clock.
meynaf is offline  
Old 20 August 2015, 23:06   #240
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Adrian Browne View Post
So trouble brewing in Apollo core world eh?
Trouble? No, there is no new trouble. Gunnar likes to be the leader of obedient followers. Unfortunately, he tends to overwhelm other leaders and loses the advantages of a diverse group. This makes his job more difficult but perhaps he may succeed doing everything his way. I believe his technical processor design knowledge is sound.

Quote:
Originally Posted by meynaf View Post
So once MOVEM.L is done, doing MOVEM.W is peanuts ? (As the special format is what's tough here, when you have it, you can reuse it, right ?)
MOVEM.W is not much more difficult although register destinations require more resources to do the sign extensions. Again, it would be nice to give the resources to MOVEM.W a word pair in cache to/from registers in 1 cycle. Some other DSP like processors or processors with DSP like extensions have special instructions to load and store pairs but it would be better if we could speed up what we have rather than introduce new instructions. Loading separately with MOVE requires instruction scheduling to avoid the 1 read or write per cycle limitation and is not always possible. Adding some SIMD like instructions like ADD2W.L and ADD4B.L would be simple and could help also but it would be good to see what a separate SIMD design could do first. I know you well enough that you would probably say forget the SIMD and add MOVEM.B though .

Quote:
Originally Posted by meynaf View Post
MOVEM needs to be reasonably fast, while MOVEP does not. Isn't it easier when it can be slow ?
Basically it's just a bunch of shift + move.b, and these already exist in the cpu. It's not like if we want it to run in 1 clock.
Any instruction which takes more than 1 cycle adds complexity to the pipeline design and is more costly. The 68k does and probably always will support multi-cycle instructions so some of the support for multi-cycle instructions is already in place. The actual cost likely depends on the specific 68k design.
matthey 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
T4060 68060 accellerator and heat videofx support.Hardware 24 26 November 2014 23:54
maybe classic Amiga at 402.5 Mhz with CPU Cyclone II FPGA 20K PQFP-240? ematech support.Hardware 25 07 November 2013 15:18
How do accelerator cards work? This one Apollo 1240 theugly support.Hardware 25 27 August 2013 20:08
What accellerator do I need ? Kakaboy Hardware mods 13 23 March 2010 05:33
Wanted: A1200 Accellerator jabsy MarketPlace 0 08 January 2007 13:27

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:11.


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