Apollo Team has new Cyclone 5 FPGA accellerator cards

[kolla]

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.

Originally Posted by meynaf

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.

[meynaf]

Originally Posted by kolla

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.

[kolla]

I'm not saying he's lying, just that "proof" is in showing running working software.

[meynaf]

Originally Posted by kolla

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.

[happymondays]

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.

[eXeler0]

@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.

[meynaf]

Technical glitch with the web server ? I don't think so. It's not the first time the whole forum gets deleted.

[eXeler0]

Originally Posted by meynaf

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

[Mrs Beanbag]

Originally Posted by meynaf

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

[pandy71]

Waiting 20 years for such card so i can wait another year...

[Adrian Browne]

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?

[matthey]

Originally Posted by Adrian Browne

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.

[jbenam]

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.

[Megol]

Originally Posted by meynaf

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.

[meynaf]

Originally Posted by Megol

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".

Originally Posted by Megol

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.

[Megol]

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.

[matthey]

Originally Posted by Megol

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 .

[Adrian Browne]

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.

[meynaf]

Originally Posted by Megol

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 ?)

Originally Posted by Megol

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.

Originally Posted by Megol

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.

[matthey]

Originally Posted by Adrian Browne

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.

Originally Posted by meynaf

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 .

Originally Posted by meynaf

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.