Welcome, Guest. Please login or register.

Author Topic: Second NatAmi MX board assembled!  (Read 13525 times)

Description:

0 Members and 2 Guests are viewing this topic.

Offline SamuraiCrow

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 2280
  • Country: us
  • Gender: Male
    • Show all replies
Re: Second NatAmi MX board assembled!
« on: April 12, 2011, 05:14:50 PM »
Quote from: _ThEcRoW;631226
estimated price?


When first released it will probably cost about the same as a SAM440ep did when it was new:  about 500 Euros for the main board.
 

Offline SamuraiCrow

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 2280
  • Country: us
  • Gender: Male
    • Show all replies
Re: Second NatAmi MX board assembled!
« Reply #1 on: April 13, 2011, 02:18:44 AM »
@DCAmiga

The '060 board will cost extra.  Most people won't need it.  By the time the N050 will be fully tested there will likely be an N070 softcore out.  The only part missing from the N070 will be the MMU of the 68060.
 

Offline SamuraiCrow

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 2280
  • Country: us
  • Gender: Male
    • Show all replies
Re: Second NatAmi MX board assembled!
« Reply #2 on: April 13, 2011, 04:22:15 PM »
Quote from: vidarh;631390
I'm curious as to why this would be the case for the Natami CPU designs. It'd require some quite odd design decisions, IMHO.

Every "real" 680x0 design since the 68010 has been able to support a fully external MMU just by supporting full recovery after a bus fault and external bus mastering.

With those two features in place, the CPU doesn't need to know whether or not the MMU is there or not. The only way the CPU would "notice" the presence of a MMU would be that it'd occasionally lose bus access or get a bus fault if the MMU had a TLB miss or an access violation respectively - if the MMU isn't present, nothing would interfere with memory accesses.

Many early MMU designs did this. Sun and others even managed to do this with plain 68000's, though doing this on a 68000 required some pretty nasty "magic" and/or running two 68000's in parallel on the same instruction stream (yikes, but it worked), offset so that you could halt and restart the second CPU when the first caused an access violation (because the trapped instructions are not fully restartable).

A MMU design that slowed down the CPU when it's turned off would a be a major design flaw, IMHO, as there's no good reason for that to be the case at all. Most designs with MMU's only ever "lose" cycles due to the presence of the MMU if there's a TLB miss or access violation even when the MMU is on.


IIRC, the N68050 shares its memory controller with the SuperAGA chipset.  This makes external mastering difficult.  Also, the bus faulting requires a few extra stages in the pipeline which will make the CPU suffer more dramatic performance losses if code doesn't follow a linear path (eg. with branching).  But I'm not the expert on these issues so I'll leave you to think about this.