@coriolis

Quote:

Any news?

The "news" for Natami is the same its always been VAPOUR

Quote:

CodeSmith wrote: @cdimauro Wow, this looks like a neat project. Please learn from the mistakes of the natami team and don't let the feature list grow for years.

Our goal is to release the board ASAP.
Quote:

On the topic of learning from others' mistakes: I'm a bit concerned by the move from SDRAM to DDR memory.

We moved to DDR2 memories.
Quote:

What steps are you taking to make sure that you won't have the same memory module compatibility problems that the AmigaOne SE/XE did? From the various forum discussions back then it came out that DDR is notoriously fickle and it takes someone with the resources of Intel or AMD to make a memory controller that will work reliably with most store-bought RAM (MAI Logic didn't...) I myself had to re-buy my RAM twice, eventually what worked was a module I bought from an AW forum member who'd done the research and worked out which specific memory chips worked with the XE's memory controller.

Frankly speaking, I'm not an hardware engineer, so I don't know how they'll address these issues.

@cdimauro

Quote:

OK, G4s can do better, but they have an old design and limited frequencies, so the overall speed isn't great.

e6500 core offers higher performance per MHz than G4/e600 core. e6500 1800 MHz could be as fast as G4 2500 MHz (if Freescale DMIPS values for both CPUs are true). Still only 1/6 of single core/thread performance of common Core i5.

Quote:

If you can have very good performance in a specific, limited, scenario (mostly RTG / not hardware-hitting software) with a 750FX model, it doesn't change what I described above.

As I wrote, only games need full OCS/AGA compatibility and most games don´t require faster CPU than 68030. Recent 1.5 GHz PowerPC core is able to fully emulate A1200 (not even counting 68k UAE JIT in developement) and has 68060 500+ MHz class performance for OS friendly applications on OS4/MorphOS. With proper UAE integration (eg. RunInUAE) this solution offers best of both NG and classic worlds.


That doesn´t mean I don´t welcome projects like TiNA. It is really ambitious and I hope it will not met same fate as Natami.

@pavlor

cmon guys, i understand its for sake of argument, but ppc is completely off topic here.

@cdimauro

Quote:

cdimauro wrote: Quote: NutsAboutAmiga wrote: @cdimauro [quote]We know that AmigaOS is a 32-bit only o.s., so there's no chance to see it working on a 64-bit processor without trashing compatibility. But addressing more than 2GB of memory is a very important feature nowadays, even for an hobby project like this. 68020 is a 32bit processor anyway, so your limit is that 4Gbytes of address space, I guess it might be possible to use more some kind of flash drive or RAM drive, if you have MMU that supports more than 32bit, aka paged memory (memory window), you might use it as disk cache, to speed up io reads.

Yes, an MMU can help, but AmigaOS doesn't support it very well. Some work is needed to take advantage of it.

However, even the 80386 was 32-bit processor, but AMD extended it to 64-bit with his K8.
ARM made the same with his brand new ARM64 ISA, which is also binary incompatible with the old 32-bit ARM ISA.

I think that, once the SuperAmiga was up and running, we must thought about a proper successor for the good old 68K. Extending the existing ISA adding some new istructions has limited usefulness. OK, we can also add a brand new and modern SIMD unit. Fine. But an architecture rewrite and enhancement is a completely different thing, opening the road to a much better ISA (even to implement).

Anyway, it'a MUCH premature thing to talk about. [/quote]

(Grrrrrrr..... somehow the mechanism that deals with quoted material here isn't displaying it right, and I can't figure out how to fix it.)

Still, the idea of a 64-bit 680x0 descendant, particularly if there was some way to keep it binary compatible with 32bit executables, would be a great thing to have someday. But just having a 64bit 680x0 as and of itself would be nice, even if there was no way to directly run the old exe's on it, and presumably all they'd have to do is just recompile OS4 or an OS4-descendant on it. I'm wondering just how good and fast a 64-bit 680x0 processor could be, would it be as good and as fast as current 64bit x86 CPUs, while staying simpler than those to write OSs for, or would it at least be better and faster than the current, fastest PPC?

In any event, I'm looking forward to the first coming models of (32bit) Tina, since I do want something I can run things on that uses RTG to give me a large screen on regular, off the shelf LCD monitors and that, presumably, refreshes fast as the dickens on them, and am not really needing to run AGA-ish games. Most of what I did on my dead A1200 wasn't AGA anyway.

Last edited by NomadOfNorad on 10-Jun-2013 at 08:16 PM.
Last edited by NomadOfNorad on 10-Jun-2013 at 08:15 PM.

_________________
"I love peacenicks, they're so easy to conquer." --Ivan J Ironfist, the Dictator

@cdimauro

Quote:

Our goal is to release the board ASAP.

Good

Quote:

Frankly speaking, I'm not an hardware engineer, so I don't know how they'll address these issues.

I'm not one either, so all I can do is make sure that you guys are aware of the problem so you don't repeat history (I don't know how many of you were around back when this all took place). My advice, for what it's worth, is to either solder in the memory (a 68K amiga with 1GB of RAM is an absolute monster and that much RAM is dirt cheap these days) or test as many different types as you can, so you can have a large compatibility list.

Quote:

NomadOfNorad wrote: 68020 is a 32bit processor anyway, so your limit is that 4Gbytes of address space, I guess it might be possible to use more some kind of flash drive or RAM drive, if you have MMU that supports more than 32bit, aka paged memory (memory window), you might use it as disk cache, to speed up io reads.

It might be possible to give up to 4GB per task/process using an enhanced MMU and virtual memory. Some recent versions of 32 bit x86 and ARM support this already.

Quote:

However, even the 80386 was 32-bit processor, but AMD extended it to 64-bit with his K8. ARM made the same with his brand new ARM64 ISA, which is also binary incompatible with the old 32-bit ARM ISA.

64 bit is overrated for the integer units. The extra caches, alignment costs and larger code is always a penalty while only some code is up to 2x as fast and addressing over 4GB is rare. It makes even less sense in an fpga where 64 bit multiply and shift instructions are slower than 32 bit versions.

Quote:

I think that, once the SuperAmiga was up and running, we must thought about a proper successor for the good old 68K. Extending the existing ISA adding some new instructions has limited usefulness. OK, we can also add a brand new and modern SIMD unit. Fine. But an architecture rewrite and enhancement is a completely different thing, opening the road to a much better ISA (even to implement).

The 68020 ISA is pretty good for how old it is. It doesn't have as many mistakes as the x86 and ARM ISAs have from all the changes. It could be simpler to decode but then it has better code density than x86 or Thumb2 and is easier to use. The main advantages to changing would be due to newer fabs and cheaper costs but not the ISA.

Quote:

Still, the idea of a 64-bit 680x0 descendant, particularly if there was some way to keep it binary compatible with 32bit executables, would be a great thing to have someday. But just having a 64bit 680x0 as and of itself would be nice, even if there was no way to directly run the old exe's on it, and presumably all they'd have to do is just recompile OS4 or an OS4-descendant on it. I'm wondering just how good and fast a 64-bit 680x0 processor could be, would it be as good and as fast as current 64bit x86 CPUs, while staying simpler than those to write OSs for, or would it at least be better and faster than the current, fastest PPC?

I'm not so sure 64 bit for the 68k integer units would be a good idea. I would like to experiment with a virtual memory implementation first. 64 bit addressing would not work in Amiga structures where a pointer is required. Even PPC AmigaOS 4 and MorphOS only run in 32 bit mode. If the virtual memory solution worked and was good enough, it should be possible to improve 68k code density by 5-15% from ISA enhancements and much more by improving 68k compilers. This approach may provide better performance than true 64 bit in resource limited computing environments where most of the processors are going these days.

Quote:

In any event, I'm looking forward to the first coming models of (32bit) Tina, since I do want something I can run things on that uses RTG to give me a large screen on regular, off the shelf LCD monitors and that, presumably, refreshes fast as the dickens on them, and am not really needing to run AGA-ish games. Most of what I did on my dead A1200 wasn't AGA anyway.

I agree. The TiNA project has fpga's and is more open than some other projects so it should be possible to upgrade (AGA?) also.

Last edited by matthey on 12-Jun-2013 at 01:44 AM.

@matthey

Quote:

matthey wrote: Quote: NomadOfNorad wrote: 68020 is a 32bit processor anyway, so your limit is that 4Gbytes of address space, I guess it might be possible to use more some kind of flash drive or RAM drive, if you have MMU that supports more than 32bit, aka paged memory (memory window), you might use it as disk cache, to speed up io reads. It might be possible to give up to 4GB per task/process using an enhanced MMU and virtual memory. Some recent versions of 32 bit x86 and ARM support this already.

Not for AmigaOS. It is a single address space operating system so the POSIX type of separate memory spaces per process is hard to retrofit.
One could use remapping of message areas or copying of the same however that would require new APIs. Alternatively one could make sure all message passing stuff was limited to a shared portion of memory but even that wouldn't be completely backwards compatible.

Quote:

Quote: However, even the 80386 was 32-bit processor, but AMD extended it to 64-bit with his K8. ARM made the same with his brand new ARM64 ISA, which is also binary incompatible with the old 32-bit ARM ISA. 64 bit is overrated for the integer units. The extra caches, alignment costs and larger code is always a penalty while only some code is up to 2x as fast and addressing over 4GB is rare. It makes even less sense in an fpga where 64 bit multiply and shift instructions are slower than 32 bit versions.

If the register file is expanded at the same time as a 64 bit extension one probably will see the same effect as AMD64 did: the extra performance from the register extension will in most cases make up for the 64 bit performance loss. Some code would be faster, some slower.
The slowness of multiplication and shifts also "only" affects the latency not the throughput and would be mostly hidden if the processor supports out of order execution. With more hardware dedicated to the task the latency difference can be reduced too.

Quote:

Quote: I think that, once the SuperAmiga was up and running, we must thought about a proper successor for the good old 68K. Extending the existing ISA adding some new instructions has limited usefulness. OK, we can also add a brand new and modern SIMD unit. Fine. But an architecture rewrite and enhancement is a completely different thing, opening the road to a much better ISA (even to implement). The 68020 ISA is pretty good for how old it is. It doesn't have as many mistakes as the x86 and ARM ISAs have from all the changes. It could be simpler to decode but then it has better code density than x86 or Thumb2 and is easier to use. The main advantages to changing would be due to newer fabs and cheaper costs but not the ISA.

May I ask what mistakes you are thinking of?
Also the numbers I've seen show Thumb2 to be more compact than 68k.

Quote:

Quote: Still, the idea of a 64-bit 680x0 descendant, particularly if there was some way to keep it binary compatible with 32bit executables, would be a great thing to have someday. But just having a 64bit 680x0 as and of itself would be nice, even if there was no way to directly run the old exe's on it, and presumably all they'd have to do is just recompile OS4 or an OS4-descendant on it. I'm wondering just how good and fast a 64-bit 680x0 processor could be, would it be as good and as fast as current 64bit x86 CPUs, while staying simpler than those to write OSs for, or would it at least be better and faster than the current, fastest PPC? I'm not so sure 64 bit for the 68k integer units would be a good idea. I would like to experiment with a virtual memory implementation first. 64 bit addressing would not work in Amiga structures where a pointer is required. Even PPC AmigaOS 4 and MorphOS only run in 32 bit mode. If the virtual memory solution worked and was good enough, it should be possible to improve 68k code density by 5-15% from ISA enhancements and much more by improving 68k compilers. This approach may provide better performance than true 64 bit in resource limited computing environments where most of the processors are going these days.

Any other type of memory extension wouldn't work either.

Quote:

Quote: In any event, I'm looking forward to the first coming models of (32bit) Tina, since I do want something I can run things on that uses RTG to give me a large screen on regular, off the shelf LCD monitors and that, presumably, refreshes fast as the dickens on them, and am not really needing to run AGA-ish games. Most of what I did on my dead A1200 wasn't AGA anyway. I agree. The TiNA project has fpga's and is more open than some other projects so it should be possible to upgrade (AGA?) also.

Quote:

megol wrote: Quote: matthey wrote: It might be possible to give up to 4GB per task/process using an enhanced MMU and virtual memory. Some recent versions of 32 bit x86 and ARM support this already. Not for AmigaOS. It is a single address space operating system so the POSIX type of separate memory spaces per process is hard to retrofit. One could use remapping of message areas or copying of the same however that would require new APIs. Alternatively one could make sure all message passing stuff was limited to a shared portion of memory but even that wouldn't be completely backwards compatible.

If programmers had used the MEMF_PUBLIC flag correctly, it wouldn't be that difficult. Messages and MEMF_PUBLIC memory would remain shared memory between tasks/processes. Only Non MEMF_PUBLIC memory would be virtual. Since MEMF_PUBLIC is so abused, a new virtual memory bit and API like AmigaOS 4 uses could be done. Old Amiga programs rarely need more that a 1 or 2 GB of memory anyway ;).

Quote:

If the register file is expanded at the same time as a 64 bit extension one probably will see the same effect as AMD64 did: the extra performance from the register extension will in most cases make up for the 64 bit performance loss. Some code would be faster, some slower. The slowness of multiplication and shifts also "only" affects the latency not the throughput and would be mostly hidden if the processor supports out of order execution. With more hardware dedicated to the task the latency difference can be reduced too.

A single multiplication or shift is limited in it's parallel operations. Sure, a longer pipeline can hide about anything but there are disadvantages too. The difference in the caches between 32 bit and 64 bit is usually underestimated. The extra 64 bit cache use comes from:

1) extra alignment, padding and wasted extended data (more effect on DCache)
2) less dense instruction set (ICache)
3) bigger branch caches for longer pipeline

Do you think 64 bit needs 10-20% more caches all the time to get 2x the performance some of the time? The 2x performance looks good but it depends on how often it can be used. My cache cost estimate for 64 bit may be too conservative too. The logic cost will be more than double for 64 bit which comes into play more for an fpga.

Quote:

Quote: The 68020 ISA is pretty good for how old it is. It doesn't have as many mistakes as the x86 and ARM ISAs have from all the changes. It could be simpler to decode but then it has better code density than x86 or Thumb2 and is easier to use. The main advantages to changing would be due to newer fabs and cheaper costs but not the ISA. May I ask what mistakes you are thinking of? Also the numbers I've seen show Thumb2 to be more compact than 68k.

The ARM program counter used to be less than 32 bits, branches are messy (same on x86), there are all these modes with restrictions on what is used in them and weird ways of switching between them, many new instructions were added that are antiquated now because of newer instructions, every ARM processor has different units making programming a pain, there are alignment and addressing restrictions. It's not too bad if you stick to Thumb2 only but the 68k is still easier to program.

The 68k had better code density until the 68k compilers started getting worse. We had a good discussion about it with links to supporting articles here:

http://www.amigacoding.de/index.php?topic=310.msg1454#msg1454

Last edited by matthey on 21-Jun-2013 at 12:39 AM.
Last edited by matthey on 21-Jun-2013 at 12:37 AM.
Last edited by matthey on 21-Jun-2013 at 12:35 AM.

@matthey
matthey wrote:
Quote:

A single multiplication or shift is limited in it's parallel operations. Sure, a longer pipeline can hide about anything but there are disadvantages too. The difference in the caches between 32 bit and 64 bit is usually underestimated. The extra 64 bit cache use comes from:

Multiplication design depends on the FPGA substrate but without any tricks a 64*64=>128 multiplier would require 12 24*16=>40 multipliers in Xilinx and 8 36x36=>72 multipliers in Altera. Both multipliers blocks would need support logic.

However 64*64=>128 needn't be supported for a 64 extension to be useful. Not even 64*64=>64 is strictly required.

Going from a 32 bit shifter to a 64 bit one adds one level of 2:1 muxes using a rotator with fixup design, 5 layers to 6 layers (before compacted into LUTs and dedicated hardware) isn't significantly slower.

Quote:

1) extra alignment, padding and wasted extended data (more effect on DCache) 2) less dense instruction set (ICache) 3) bigger branch caches for longer pipeline Do you think 64 bit needs 10-20% more caches all the time to get 2x the performance some of the time? The 2x performance looks good but it depends on how often it can be used. My cache cost estimate for 64 bit may be too conservative too. The logic cost will be more than double for 64 bit which comes into play more for an fpga.

(I'm assuming a 64 bit expansion using my proposed AMD64 inspired prefix format)

Alignment of what? A reasonable 64 bit implementation would allow 64 bit data to be aligned on 16 bit boundaries for free and 8 bit boundaries either for free or with one clock latency. Padding etc. wouldn't expand for this reason alone. I thought this was already explained?

Instructions wouldn't expand either unless needed to, 32 bit operations would still have the same encoding as would 16 or 8 bit. 64 bit operations would need a prefix however then the instruction would do the work of two or more 32 bit operations so there would still be no expansion.

Addresses stored in memory would be 64 bit instead of 32 bit giving a 2x expansion however the impact this have in real code would depend on the type of data structures used.

Quote:

The ARM program counter used to be less than 32 bits, branches are messy (same on x86), there are all these modes with restrictions on what is used in them and weird ways of switching between them, many new instructions were added that are antiquated now because of newer instructions, every ARM processor has different units making programming a pain, there are alignment and addressing restrictions. It's not too bad if you stick to Thumb2 only but the 68k is still easier to program.

I meant in x86. Since the 80386 the base architecture haven't changed much except for the SIMD instructions which I'll admit is a bit of a mess.
But "messy" branches? Don't understand what you mean by that for either ARM or x86.

Quote:

The 68k had better code density until the 68k compilers started getting worse. We had a good discussion about it with links to supporting articles here: http://www.amigacoding.de/index.php?topic=310.msg1454#msg1454

Yes but there have been comparisons using hand assembled code too. I'll try to find a link for one of those.

So, any neat new updates on the TiNA project?

_________________
"I love peacenicks, they're so easy to conquer." --Ivan J Ironfist, the Dictator

@NomadOfNorad

Quote:

So, any neat new updates on the TiNA project?

No. Last post on their forum was from July 4 (about FPGA Arcade). Maybe they wait until there is something to announce.

Last edited by pavlor on 11-Jul-2013 at 04:09 PM.

@pavlor

Like doing something more than saying essentially nothing?

On their site there is an "aim" for a 68020 super-scalar processor running at 400MHz. Now that's of course complete bull.
Then there are a diagram with 3 FPGAs and 128 bit data bus. Is that realistic? Is that the most economic solution? Who knows.

In comparison with the Natami there is a board design that's real, mostly tested and with Amiga chipset compatibility (though not 100% compatible).

Now some people call Natami vapor and think the Tina project isn't...

@megol

Quote:

On their site there is an "aim" for a 68020 super-scalar processor running at 400MHz. Now that's of course complete bull.

"Classic" 68020 at 400 MHz would be comparable to 68060 50-75 MHz.

Quote:

Now some people call Natami vapor and think the Tina project isn't...

I still hope it will be released someday.

@pavlor

Quote:

pavlor wrote: @megol Quote: On their site there is an "aim" for a 68020 super-scalar processor running at 400MHz. Now that's of course complete bull. "Classic" 68020 at 400 MHz would be comparable to 68060 50-75 MHz.

Yeah but it wouldn't be a 68020. What I mean is that a superscalar 68020 wouldn't be a 68020 anymore. And that is the problem: if the people behind the TiNA project doesn't understand such a basic technical thing well I don't see how they could make anything :/

Now it still wouldn't be impossible, just look at the A600/A500 Vampire project ( http://www.majsta.com ) where the creator have learned about hardware design while doing the accelerator. But still there isn't a pie in the sky claim like in the TiNA project (400MHz 68020 - if it is possible).

Quote:

Quote: Now some people call Natami vapor and think the Tina project isn't... I still hope it will be released someday.

Me too.

@megol
Yes I agree with you MC68020 and superscalar i don't understand?

I think that any MC68K core could do just fine. After mine investigation I realized that most important part in designing such things are cache. But, there are only few people who can develop such cache. With better cache you can run any core on slow freq and expect large performance. Running standalone core at higher speeds lets say over 100MHz can give little performance boost. I think that apollo-core is only thing that can be used for such projects because according my information's Dcache and Icache are inside core not outside like in systems I m trying to create. Knowledge is basic part of the problem and when you start learning about this then you can see how little you know. I realized that something really special can happen only if those few people unite with better communication and without deadlines or some special goals. Me, I m just trying to force them to create something real because I m at the end regarding knowledge and performance achieved. Please understand that easy part is to design hardware, to connect few FPGA devices and to produce any board. But, coding...

Quote:

megol wrote: Yeah but it wouldn't be a 68020. What I mean is that a superscalar 68020 wouldn't be a 68020 anymore. And that is the problem: if the people behind the TiNA project doesn't understand such a basic technical thing well I don't see how they could make anything :/

I think this is a bit harsh. This is pretty clearly talking about the 68020 ISA. The 68020+ ISA was never formally named so saying "68020 ISA superscalar processor" would probably not be any clearer to most people. While I admit the current board design is difficult, it's also not set in stone. Expect to see some changes. I will wait and see what they come up with and, even then, there isn't a need to criticize or nitpick.

English is not their 1st language either. If English was important, the use of "doesn't" instead of "don't" in your quote from above might disqualify all your knowledge but it doesn't. People should strive to be clear and concise but nitpicking and attacks are worse than small mistakes, IMO.

Last edited by matthey on 15-Jul-2013 at 10:50 PM.

@matthey

Quote:

matthey wrote: Quote: megol wrote: Yeah but it wouldn't be a 68020. What I mean is that a superscalar 68020 wouldn't be a 68020 anymore. And that is the problem: if the people behind the TiNA project doesn't understand such a basic technical thing well I don't see how they could make anything :/ I think this is a bit harsh. This is pretty clearly talking about the 68020 ISA. The 68020+ ISA was never formally named so saying "68020 ISA superscalar processor" would probably not be any clearer to most people. While I admit the current board design is difficult, it's also not set in stone. Expect to see some changes. I will wait and see what they come up with and, even then, there isn't a need to criticize or nitpick.

For most technical people something like that is a big error. The 400MHz-if-it's-possible is also suspect. If they haven't know if 400MHz is possible why mention it at all? In comparison the 68050 design (that I still hope will be released soon) had a design speed less than 200MHz in a comparable FPGA.

But yes, it can be that I'm just to cynical. I really hope that the TiNA project succeeds anyway.

Quote:

English is not their 1st language either. If English was important, the use of "doesn't" instead of "don't" in your quote from above might disqualify all your knowledge but it doesn't. People should strive to be clear and concise but nitpicking and attacks are worse than small mistakes, IMO.

Well I'm well aware that my English skills (or even any other language I speak/read/write) leave something to be desired. But still the difference is a grammatical v.s. a technical terminology error.
I don't see my post as an attack BTW. Wasn't intended as such anyway.

edit: made the whole post readable

Last edited by megol on 18-Jul-2013 at 07:10 PM.

@megol

in einer diskussion on a1k
http://www.a1k.org/forum/showthread.php?t=38998&page=2
jens schoenfeld outlines the only possibility to build up to date amiga replacement as coupling fpga containing the chipset with some fast and cheap mainstream cpu (he proposes mips) running 68kemu/jit.

i think its pretty striking that this is the way.

@wawa

Quote:

he proposes mips) running 68kemu/jit.

Who will write that JIT?