Home   News   Concept   AMIGA-Compatible   Hardware   Forum   Questions+Answers   Pictures   Contact & Team

Welcome to the Natami / Amiga Forum

This forum is for AMIGA fans interested in the new NATAMI platform.
Please read the forum usage manual.



All TopicsNewsQAFeaturesTalkTEAMLogin to post    Create account
The team will post updates and news here

NatAmi LX Evaluation Baseboard Bringuppage  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 >> 
Ayodele Stephenson
USA

Posts 83
04 Jan 2010 16:50


It's Great to see such positive progress, I guess in some ways we will have an even more "modern" Natami, simply because of the need to work with Ram controller, hopefully this will allow for additional performance gains with the "custom chips"

Good Work!!

Erik Bauer
Italy

Posts 301
04 Jan 2010 17:29


Thomas Hirsch wrote:

Light at the end of the tunnel.
 
  Yes, there is. But unfortunately because the memory went from asynchronous to to fully registered and pipelined almost all components need to be "reconsidered" to a certain point. But to show a little bit of progress:
 
 
 
  There are still some problems regarding the memory controller - but in general the memory management begun to work. So this is a screenshot of the working copper. The copper can now read chipram memory and write DFF register addresses. At the same time this copperlist is processed by the copper the processor (M68k) is running and can read the copperlist out of the memory:
 
 
 
  This second picture is a screenshot of TeraTerm (serial port terminal program) which is connected to the debug serial port of the SyncZorro CPU card.

GREAT!
My favourite Amiga piece of Hardware showing it's heartbeat in the Natami debug board!!

I'm so excited about it!

I can't understand what you mean with "because the memory went from asynchronous to to fully registered and pipelined almost all components need to be "reconsidered" to a certain point"
But I guess you know what you're doing.

Keep it up!

Channel Z

Posts 227
04 Jan 2010 19:12


@Erik Bauer

My guess is that in the first design chip RAM was to be asynchronous SRAM. In the current design chip RAM is buffered synchronous DRAM (DDR2), and thus some design concepts have to be reworked. And maybe Thomas didn't realize that until trying them out on the physical board.

Marcel Verdaasdonk
Netherlands

Posts 3991
05 Jan 2010 07:54


Probably the timings need tweaking since now it isn't a clock a read, we need to do 4 sequential reads, that is where Angus and some of the chips will need to be modded for.

Claudio Wieland
Germany
(Natami Team)
Posts 706
05 Jan 2010 08:25


IIRC, the Natami DDR2-RAM is programmed for a 4-burst access. Since DDR2 delivers 4 databits per pin and external IO clock, we should get (4 cycles)*(4 dbits/pin)*(16 data pins) = 256 bits of data with each burst access with length = 4 per module. Since there are two DDR2 modules (CHIP and FAST) with independent buses, maximum should be 512 bits per burst access. If this isn't completely correct, please clarify.

The old memory access access scheme was quite "simple". However, to get DDR2 to its maximum throughput possible, the memory accesses have to be optimally scheduled. That is what this is all about, I guess.

Gunnar von Boehn
Germany
(Moderator)
Posts 5775
05 Jan 2010 09:19


Claudio Wieland wrote:

IIRC, the Natami DDR2-RAM is programmed for a 4-burst access. Since DDR2 delivers 4 databits per pin and external IO clock, we should get (4 cycles)*(4 dbits/pin)*(16 data pins) = 256 bits of data with each burst access with length = 4 per module. Since there are two DDR2 modules (CHIP and FAST) with independent buses, maximum should be 512 bits per burst access. If this isn't completely correct, please clarify.

Natami DDR2-RAM is programmed for a 4-burst access : correct
DDR2 delivers 4 databits per pin: DDR2 does 2 per pin.
The 4-burst access accounts for the 2 transfer of DDR2 already.
This mean:
a 16bit memory interface does 64bit bursts.
a 32bit memory interface does 128bit bursts.

I hope this helps.

But in general you were right.
The original AMIGA did do single memory access and did wait for it to fully complete until doing the next single memory access.
The Natami originally behaved 100% the same.

The new Natami changes the memory access in two ways.
a) It always burst.
Every read access is done in burst lines.
Writes access also burst but the Natami can mask individual bytes - therefore its possible to write single bytes or words as usual.

b) The Natami holds several access in flight.
To improve memory performance the NATAMI does not do a single memory access as the old AMIGA but can hold up to 8 burst access in flight per chip/fast bank.

The concept of keeping multiple burst in flight is crucial for state of the art memory performance.
This required some significant enhancements to AGNUS.

Cheers

Louis Dias
USA

Posts 217
05 Jan 2010 18:34


I see the change in memory controller explains the long silence...

Details, details!

Nice simple copper list effect.  What resolution and frequency is that display?

Bartek "Banter" K.
Poland
(Natami Team)
Posts 2277
05 Jan 2010 18:57


Louis Dias wrote:

What resolution and frequency is that display?

I second that question. ?


Thomas Hirsch
Germany
(MX-Board Owner)
Posts 647
06 Jan 2010 20:33


800x600 50Hz, meaning a total of 628 lines and 902 pixels

Louis Dias
USA

Posts 217
06 Jan 2010 20:58


Aw shucks!  :)

Show us something a "normal" Amiga couldn't do. ;-)

Hagbard Celine
Norway

Posts 24
08 Jan 2010 13:01


Thomas Hirsch wrote:

Light at the end of the tunnel.
 

I can see the light!!
Wonderful work!

Channel Z

Posts 227
08 Jan 2010 13:51


@Louis Dias
 
  800x600 planar non-laced? :)

Thundery End
United Kingdom

Posts 32
09 Jan 2010 01:04


Gratz on getting a display out considering you went from an SRAM system to a DDR2 RAM based system, it's not like people routinely design and implement memory controllers for a computer that was so tightly tied to its RAM and DMA engine.
 
  *BOWS*

(Is not worthy :) )

Thomas Hirsch
Germany
(MX-Board Owner)
Posts 647
14 Jan 2010 12:20


bitplanes

The bitplane DMA has ram access now. Each plane now uses a buffer of 32 byte to store incoming data. The data receiving path is now detached from the read access initiating logic.

The red lines in the picture show the display window limits. Plane one (yellow) and two (red) are drawing a lores circle. The planar data is read from chip memory. For now a line is drawn only once not twice leading to a 2:1 display field.

Guillaume Michalakakos
France
(MX-Board Owner)
Posts 454
14 Jan 2010 12:47


Congratulations Thomas !

It's great to see some good progress.

Cheers.

Bartek "Banter" K.
Poland
(Natami Team)
Posts 2277
14 Jan 2010 13:50


Hallo Thomas,

Thank you for the update!

Good luck!

Marcel Verdaasdonk
Netherlands

Posts 3991
14 Jan 2010 14:27


Yep, mind blowing.

I am sure some heads will explode. :P

Erik Bauer
Italy

Posts 301
14 Jan 2010 16:50


Cool!

Keep us updated! We do love seeing progress step by step!

Ayodele Stephenson
USA

Posts 83
14 Jan 2010 17:44


This brings a :-D to my face!!

Hagbard Celine
Norway

Posts 24
14 Jan 2010 22:02


Ayodele Stephenson wrote:

This brings a :-D to my face!!

Second that :D


posts 735page  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 >>