Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A600 Memory

AuthorTopic: Second NatAmi MX board assembled!  (Read 10056 times)

0 Members and 1 Guest are viewing this topic.

Offline magnetic

Re: Second NatAmi MX board assembled!
« Reply #30 on: April 13, 2011, 02:29:32 AM »
Big deal, another pic of a board. I held the Boxxer in my hand and what happend V A P O U R .... nobody has seen one screenshot of this thing working so ... read above.
bPlan Pegasos2 G4@1ghz
Quad Boot:Reg. MorphOS | OS4.1 U4 |Ubuntu GNU-Linux | MacOS X

Amiga 2000 Rom Switcher w/ 3.1 + 1.3 | HardFrame SCSI | CBM Ram board| A Squared LIVE! 2000 | Vlab Motion | Firecracker 24 gfx

Commodore CDTV: 68010 | ECS | 9mb Ram | SCSI -TV | 3.9 Rom | Developer EPROMs
 

Offline x56h34

Re: Second NatAmi MX board assembled!
« Reply #31 on: April 13, 2011, 02:32:52 AM »
So cool. Looking forward to its release.
 

Offline runequester

  • It\'s Amiga time!
  • Hero Member
  • *****
  • Join Date: Oct 2009
  • Posts: 3695
  • Total likes: 0
Re: Second NatAmi MX board assembled!
« Reply #32 on: April 13, 2011, 02:43:04 AM »
Quote from: magnetic;631324
Big deal, another pic of a board. I held the Boxxer in my hand and what happend V A P O U R .... nobody has seen one screenshot of this thing working so ... read above.

THere's youtube footage of the prototypes booting a few games.
 

Offline commodorejohn

Re: Second NatAmi MX board assembled!
« Reply #33 on: April 13, 2011, 02:48:33 AM »
Quote from: magnetic;631324
Big deal, another pic of a board. I held the Boxxer in my hand and what happend V A P O U R .... nobody has seen one screenshot of this thing working so ... read above.
Actually, people have seen entire videos of it working. What's the matter - can't conceive of a new Amiga not made by CUSA?
Computers: Amiga 1200, DEC VAXStation 4000/60, DEC MicroPDP-11/73
Synthesizers: Roland JX-10/MT-32/D-10, Oberheim Matrix-6, Yamaha DX7/FB-01, Korg MS-20 Mini, Ensoniq Mirage/SQ-80, Sequential Circuits Prophet-600, Hohner String Performer

"\'Legacy code\' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrup
 

Offline magnetic

Re: Second NatAmi MX board assembled!
« Reply #34 on: April 13, 2011, 02:57:43 AM »
Ah well my bad guys i'd love to see this come to fruition. I also want the X1000 to succeed and the new C64!
bPlan Pegasos2 G4@1ghz
Quad Boot:Reg. MorphOS | OS4.1 U4 |Ubuntu GNU-Linux | MacOS X

Amiga 2000 Rom Switcher w/ 3.1 + 1.3 | HardFrame SCSI | CBM Ram board| A Squared LIVE! 2000 | Vlab Motion | Firecracker 24 gfx

Commodore CDTV: 68010 | ECS | 9mb Ram | SCSI -TV | 3.9 Rom | Developer EPROMs
 

Offline Iggy

Re: Second NatAmi MX board assembled!
« Reply #35 on: April 13, 2011, 03:11:09 AM »
Quote from: magnetic;631331
Ah well my bad guys i'd love to see this come to fruition. I also want the X1000 to succeed and the new C64!

I'd settle for Powerbook support under MorphOS (or better yet, G5 support).
"Not making any hard and fast rules means that the moderators can use their good judgment in moderation, and we think the results speak for themselves." - Amiga.org, terms of service

"You, got to stem the evil tide, and keep it on the the inside" - Rogers Waters

"God was never on your side" - Lemmy

Amiga! "Our appeal has become more selective"
 

Offline Forcie

Re: Second NatAmi MX board assembled!
« Reply #36 on: April 13, 2011, 08:54:39 AM »
Quote from: commodorejohn;631322
Is the MMU likely to be added in future revisions?

Current FPGA tech (that is, chips that are affordable enough to use in projects like this) does not really allow a MMU, because it would slow the CPU design down too much to be acceptable.
FPGA tech is advancing super fast though, and it might be possible in a future Natami design with a more advanced FPGA. But in my opinion the power of a more advanced FPGA should rather be  focused on making the CPU and chipset even faster than hogging it down  with a MMU.

The goal is to run AmigaOS and AROS, and they do not need MMU:s. The MMU is primarily useful for devtools like MuForce/Enforcer etc. So it is not a big drawback (unless you want to try and run Linux, of course). But then there is a 68060 expansion card to play with if you want.
 

Offline vidarh

Re: Second NatAmi MX board assembled!
« Reply #37 on: April 13, 2011, 09:15:54 AM »
Quote from: Forcie;631376
The goal is to run AmigaOS and AROS, and they do not need MMU:s.


They might not *need* MMU, but partial memory protection for AROS using MMU is in the works. Personally I see this as the biggest drawback of the Natami. It's still awesome enough that I'll buy one, but it'd be a lot more interesting with a MMU - nothing would prevent  you from making it optional (e.g. possible to turn it on/off at boot time or runtime) so it doesn't affect performance for those who don't want it... But I accept that there doesn't appear to be much support for the idea of a full MMU in your team (based on the public forum discussions, at least).
 

Offline kolla

Re: Second NatAmi MX board assembled!
« Reply #38 on: April 13, 2011, 09:31:50 AM »
What prevents a CPU card for Natami with a real 68k on it?
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Forcie

Re: Second NatAmi MX board assembled!
« Reply #39 on: April 13, 2011, 09:35:45 AM »
Quote from: kolla;631380
What prevents a CPU card for Natami with a real 68k on it?

If you did not already notice, we already _have_ a CPU card with a real 68060 on it for the SZorro bus. Two versions in fact (including the rare SMD 060FE chip which is factory specced at 133 MHz)

http://www.natami.net/hardware.htm
 

Offline Forcie

Re: Second NatAmi MX board assembled!
« Reply #40 on: April 13, 2011, 09:44:59 AM »
Quote from: vidarh;631379
nothing would prevent  you from making it optional (e.g. possible to turn it on/off at boot time or runtime) so it doesn't affect performance for those who don't want it...

It is just not that simple. The entire CPU design has to be rethought and reworked if a MMU is to be included, even if it could be turned off. And even if it could be turned off, it would affect the design performance-wise. So it is not a realistic option for the close future.

It is cool that AROS is getting memory protection though! I hope that AROS68k will get proper planar screenmodes soon so I can play with it some more :)
 

Offline vidarh

Re: Second NatAmi MX board assembled!
« Reply #41 on: April 13, 2011, 10:23:48 AM »
Quote from: Forcie;631385
It is just not that simple. The entire CPU design has to be rethought and reworked if a MMU is to be included, even if it could be turned off. And even if it could be turned off, it would affect the design performance-wise. So it is not a realistic option for the close future.


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.
 

Offline SamuraiCrow

Re: Second NatAmi MX board assembled!
« Reply #42 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.
 

Offline vidarh

Re: Second NatAmi MX board assembled!
« Reply #43 on: April 13, 2011, 04:53:51 PM »
Quote from: SamuraiCrow;631453
IIRC, the N68050 shares its memory controller with the SuperAGA chipset.  This makes external mastering difficult.  


That certainly does qualify as "odd". Fair enough tradeoff I suppose, though a pity given the loss of functionality.

Quote

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


Sounds strange. You shouldn't need more than the ability to effectively halt execution, clear the pipeline and store the full user-observable state (all registers, condition codes and the PC value at the start of the instruction as well as information of the access that caused the error) to stack. Then again I'm not privy to the design of the 68050, so maybe there are good reasons.

Of course this would cause a full pipeline stall, but then again when you have to call an exception handler to handle an access violation triggered by an MMU, the cost of a pipeline stall is a rounding error.
 

Offline Bamiga2002

Re: Second NatAmi MX board assembled!
« Reply #44 on: April 13, 2011, 08:40:19 PM »
There was a thorough discussion about the MMU and how it slows down the system on Natami forum (search there).  It left me the impression that it is not necessarily needed anywhere but debugging and that can be done within WinUAE. So bye bye MMU for me i won't miss you :) (then again i'm no programmer).

Great to see this project has had steady progress, been lurking 'round the forum quite often ;)
CD32
A500