|
|---|
Nathaniel Tolbert
USA
| |
Posts 9
08 Mar 2011 19:22
| This news is very encouraging. Another quick question. When moving from the 32bit bus to a 64bit bus, aside from the speed increase what kind of benefits will this give the Natami versus sticking with a 32bit bus? I know I'm asking a lot of questions and I appreciate the answers, I am inherently too curious for my own good.
| |
Wojtek P
Poland
| |
Posts 1597
08 Mar 2011 19:29
| Nathaniel Tolbert wrote:
|
This news is very encouraging. Another quick question. When moving from the 32bit bus to a 64bit bus, aside from the speed increase what kind of benefits will this give the Natami versus sticking with a 32bit bus? I know I'm asking a lot of questions and I appreciate the answers, I am inherently too curious for my own good.
|
Just speed increase. Nothing will change from software point of view IMHO.
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3976
09 Mar 2011 23:19
| Wojtek P wrote:
|
Just speed increase. Nothing will change from software point of view IMHO.
|
Repost
One of the things this forum has to do it to teach people.
Speed in crease is the chipset going from 3.5MHz roughly to perhaps 200MHz.
this is a speed increase.
What wojtak mistakenly branded speed increase is a bandwidth increase.
Which means more gets from point A to B in the same time frame.
from 32 to 64 bit is doubling the pathways but also doubling the bandwidth.
we do not increase speed however you might notice a speed increase.(more reactive system)
This is because more bandwidth not because the clock rate got up.
Jacob i hope this clears it up.
And AFAIK wasn't this the plan 2 years ago(perhaps 3 already) for memory access anyhow?
| |
Cesare Di Mauro
Italy
| |
Posts 526
10 Mar 2011 05:27
| Nathaniel Tolbert wrote:
|
This news is very encouraging. Another quick question. When moving from the 32bit bus to a 64bit bus, aside from the speed increase what kind of benefits will this give the Natami versus sticking with a 32bit bus? I know I'm asking a lot of questions and I appreciate the answers, I am inherently too curious for my own good. |
It depends on the implementation of internal components, such as the Blitter for example.
The original Blitter fetches 16 bits at the time, and works on 16 bits data; that's why it has never got benefits from AGA's 32 or 64 bits wide fetches...
However a wider bus is not always a good thing, because of several other factors, such as data alignament and/or size. Data can be unaligned in terms of single word (64 bits) or burst(s) (64 bits x 4). Also, size cannot match the word or burst.
That can cause bandwidth wast, or needs a more complex logic to handle these cases, which can be common (think about sprites and BOBs sizes), especially in a bitplane-oriented system such as the Amiga (chunky systems are less sensible to these problems).
| |
Thomas Hirsch
Germany
| | (MX-Board Owner)
Posts 647
10 Mar 2011 21:25
| It was more than a struggle, in the end it became to a fight. But now I have access to the PCI-Gayle FPGA. This is the one partly under the CF card holder. The issue itself is not that spectacular as for example "sprites are working". But this chip provides the very basic functionality of flash and ide. So the flash part is also working, IDE needs to be tested. With that it is for the first time possible to store kickstart and FPGA config on the board. This means after power on the board can now run by its own and does not need to be downloaded. Also - having the PCI-Gayle means that the data transfer of the PCI interface works too! So for PCI only the configuration space and arbiter are now missing.
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3976
10 Mar 2011 21:44
| Thomas does this mean the hardware for the USB and Network are functional?(not asking for the software just the hardware parts.)
| |
Thomas Hirsch
Germany
| | (MX-Board Owner)
Posts 647
10 Mar 2011 21:59
| No, I did not try this yet. For that the arbiter needs to be working and the PCI config space needs to be accessible. So this will follow later on.
| |
Bartek "Banter" K.
Poland
| | (Natami Team)
Posts 2277
10 Mar 2011 22:25
| Hooray! Thank you for this exciting update, Thomas!
| |
Guillaume Michalakakos
France
| | (MX-Board Owner)
Posts 454
10 Mar 2011 23:04
| Very nice Thomas ! Good luck for further :)
| |
Wojtek P
Poland
| |
Posts 1597
11 Mar 2011 07:28
| Marcel Verdaasdonk wrote:
|
Speed in crease is the chipset going from 3.5MHz roughly to perhaps 200MHz.
this is a speed increase.
What wojtak mistakenly branded speed increase is a bandwidth increase.
|
I think i properly branded things. Higher clock=higher bandwidth.
Higher bus size=higher bandwidth.
we do not increase speed however you might notice a speed increase.(more reactive system)
|
Above sentence doesn't make any sense.
| |
Wojtek P
Poland
| |
Posts 1597
11 Mar 2011 07:32
| Cesare Di Mauro wrote:
|
The original Blitter fetches 16 bits at the time, and works on 16 bits data; that's why it has never got benefits from AGA's 32 or 64 bits wide fetches...
However a wider bus is not always a good thing, because of several other factors, such as data alignament and/or size. Data can be unaligned in terms of single word (64 bits) or burst(s) (64 bits x 4). Also, size cannot match.
|
In worst case you will not get improvement from wider bus. But it will never make things slower.
Older software will already be much faster than on A4000.
Programmers writing new software would be aware how hardware works - because contrary to modern PCI hardware full documentation would be available that describes things properly. So they will be able to optimize programs to fit Natami hardware specifics.
You will not be able to get full bandwidth every case. But you will be able to get it often.
| |
Gunnar von Boehn
Germany
| | (Moderator)
Posts 5775
11 Mar 2011 11:13
| Wojtek P wrote:
|
Cesare Di Mauro wrote:
|
The original Blitter fetches 16 bits at the time, and works on 16 bits data; that's why it has never got benefits from AGA's 32 or 64 bits wide fetches...
However a wider bus is not always a good thing, because of several other factors, such as data alignament and/or size. Data can be unaligned in terms of single word (64 bits) or burst(s) (64 bits x 4). Also, size cannot match.
|
In worst case you will not get improvement from wider bus. But it will never make things slower.
Older software will already be much faster than on A4000.
Programmers writing new software would be aware how hardware works - because contrary to modern PCI hardware full documentation would be available that describes things properly. So they will be able to optimize programs to fit Natami hardware specifics.
You will not be able to get full bandwidth every case. But you will be able to get it often.
|
Please people be careful with posting confusing posts here ..... Cesare posts was correct in a general statement -
[B]BUT UNFORTUNATELY IT COULD BE DANGEROUSLY MISUNDERSTOOD! in the NATAMI context. Lets prevent some possible misunderstandings:
AGA did enhance the bandwidth over OCS.
But the way Commodore did this - was not optimal - as to enable the more bandwidth the programmer needed to fully certain alignment rules - which he did not need to do before. This did cause compatibility issues of AGA with older software. While the NATAMI has more bandwidth - there are no compatibilities issues created like in AGA. The NATAMI does not even have the alignment restrictions that AGA has. This means you data can be misaligned as you want and it will still work fine on NATAMI.
| |
Jakob Eriksson
Sweden
| | (Moderator)
Posts 1097
11 Mar 2011 12:33
| I removed many posts, maybe too many, but this thread needs to stay on topic with mostly Thomas' status posts, so newcomers can see progress.
| |
Cesare Di Mauro
Italy
| |
Posts 526
11 Mar 2011 13:21
| [EDIT: PLEASE NO LONG QUOTES WITH NEXT TO NO ANSWER.
PLEASE HELP TO KEEP THIS MX BRINGUP THREAD CLEAR AND ONTOPIC!]
Gunnar von Boehn wrote:
|
While the NATAMI has more bandwidth - there are no compatibilities issues created like in AGA.
The NATAMI does not even have the alignment restrictions that AGA has. This means you data can be misaligned as you want and it will still work fine on NATAMI. |
I never stated that something won't work.
I was just talking about issues that can happen with a wider bus. That's all. ;)
| |
Niclas Aronsson
Sweden
| |
Posts 57
11 Mar 2011 17:25
| Is there a way to add a Level 7 interrupt (NMI) switch to the MX board ?
| |
Thomas Hirsch
Germany
| | (MX-Board Owner)
Posts 647
12 Mar 2011 17:27
| Niclas Aronsson wrote:
|
Is there a way to add a Level 7 interrupt (NMI) switch to the MX board ?
|
Currently it is not planned.
| |
Thomas Hirsch
Germany
| | (MX-Board Owner)
Posts 647
12 Mar 2011 18:06
| Another little news is that the RTC is now working. And also the EEPROM which can be used to keep system specific settings. So for the MX board this is the current feature list:
VGA out ................... working
DVI out ................... o
PCI ....................... transfer only, arbiter and config missing
IDE ....................... PIO mode 0 working
Compact Flash connector ... o
NEC USB PCI ............... o
RTL 8110 LAN .............. o
(new) Battery-backed up clock.... working
15k Video out (module) .... o
15k Video in (module) ..... o
Audio in .................. o
| |
Guillaume Michalakakos
France
| | (MX-Board Owner)
Posts 454
12 Mar 2011 18:43
| Nice !! Congratulations Thomas ! :)
| |
SID Hervé
France
| |
Posts 663
12 Mar 2011 19:01
| thanks for the news.
| |
Wojtek P
Poland
| |
Posts 1597
12 Mar 2011 19:41
| Thomas Hirsch wrote:
|
Another little news is that the RTC is now working. And also the EEPROM which can be used to keep system specific settings.
So for the MX board this is the current feature list:
VGA out ................... working
DVI out ................... o
PCI ....................... transfer only, arbiter and config missing
IDE ....................... PIO mode 0 working
Compact Flash connector ... o
NEC USB PCI ............... o
RTL 8110 LAN .............. o
(new) Battery-backed up clock.... working
15k Video out (module) .... o
15k Video in (module) ..... o
Audio in .................. o[u/code]
|
VGA out...working.Does it mean you actually can boot system and see something?!
That's great.
| |
|
The team will post updates and news here