Click Here
home features news forums classifieds faqs links search
6068 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
Home
Features
News
Forums
Classifieds
Links
Downloads
Extras
OS4 Zone
IRC Network
AmigaWorld Radio
Newsfeed
Top Members
Amiga Dealers
Information
About Us
FAQs
Advertise
Polls
Terms of Service
Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
50 crawler(s) on-line.
 23 guest(s) on-line.
 1 member(s) on-line.


 AMIGASYSTEM

You are an anonymous user.
Register Now!
 AMIGASYSTEM:  4 mins ago
 eliyahu:  7 mins ago
 amigakit:  11 mins ago
 AmigaPapst:  15 mins ago
 VooDoo:  40 mins ago
 JACurley:  41 mins ago
 thomas:  42 mins ago
 Everblue:  1 hr 34 mins ago
 emeck:  1 hr 41 mins ago
 Hypex:  1 hr 47 mins ago

/  Forum Index
   /  Amiga News & Events
      /  Amiga37 News
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 Next Page )
PosterThread
Rob 
Re: Amiga37 News
Posted on 19-Oct-2022 6:52:59
#21 ]
Elite Member
Joined: 20-Mar-2003
Posts: 6216
From: S.Wales

@Hypex

Quote:
The A500 Mini went down the custom route and it even comes in a case!


It's not low volume, which is where the problem is for OS4 hardware.

@cdimauro

Calm down Rambo. I was just replying to Benny's suggestion that they were developing it for a different CPU arch.

 Status: Offline
Profile     Report this post  
bennymee 
Re: Amiga37 News
Posted on 19-Oct-2022 6:59:50
#22 ]
Cult Member
Joined: 19-Aug-2003
Posts: 679
From: Netherlands

@cdimauro

We should give them a few days: they announced for Amiwest 2022 some kind of demo ;)



Last edited by bennymee on 19-Oct-2022 at 07:00 AM.

 Status: Offline
Profile     Report this post  
BigD 
Re: Amiga37 News
Posted on 19-Oct-2022 10:03:07
#23 ]
Elite Member
Joined: 11-Aug-2005
Posts: 6620
From: UK

@Thread

I enjoyed the coverage, I'm sure the atmosphere was brilliant. I was particularly interested in the AmiBerry section and comments about A500 Mini and how RGL should have worked with the developer rather than try and hide the inner workings! A1222 Plus saga is just sad! The ACube chap and Trevor are legends as is Stephen Jones!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Amiga37 News
Posted on 19-Oct-2022 21:00:04
#24 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3084
From: Germany

@Rob

Quote:

Rob wrote:

@cdimauro

Calm down Rambo. I was just replying to Benny's suggestion that they were developing it for a different CPU arch.

And I've replied to a specific point. So?

@bennymee

Quote:

bennymee wrote:
@cdimauro

We should give them a few days: they announced for Amiwest 2022 some kind of demo ;)

Can't wait, after more than 10 years.

So, they have presented nothing on Amiga37, right?

 Status: Offline
Profile     Report this post  
Rob 
Re: Amiga37 News
Posted on 19-Oct-2022 21:19:19
#25 ]
Elite Member
Joined: 20-Mar-2003
Posts: 6216
From: S.Wales

@cdimauro

I'm just relaying what has been stated publicly. I offered no opinion.

http://blog.a-eon.biz/blog/?p=13076

If you have a problem with the statements in the blog I'm not the one you should be addressing.

 Status: Offline
Profile     Report this post  
matthey 
Re: Amiga37 News
Posted on 19-Oct-2022 22:04:03
#26 ]
Super Member
Joined: 14-Mar-2007
Posts: 1684
From: Kansas

BigD Quote:

I enjoyed the coverage, I'm sure the atmosphere was brilliant. I was particularly interested in the AmiBerry section and comments about A500 Mini and how RGL should have worked with the developer rather than try and hide the inner workings! A1222 Plus saga is just sad! The ACube chap and Trevor are legends as is Stephen Jones!


The A500 Mini will likely outsell all PPC AmigaNOne hardware by 100:1 and it is emulation, isn't as cheap as it should have been and lacks general purpose AmigaOS capabilities without hacking it. RGL planned to have Jeri Ellsworth develop an Amiga ASIC which could have dramatically lowered the price. Perhaps they didn't go for it because they couldn't get a license for the AmigaOS. Amiga Bill asked Michele Battilana about an Amiga Maxi at Amiga 37 (there is a funny Dave Haynie walk by during the interview).

Commodore Amiga - Live from Amiga37 (1:01) https://www.twitch.tv/videos/1625889488 Quote:

Amiga Bill: But speaking of hardware, I know you probably can't say but a lot of people have been talking how much they love the Amiga 500 Mini and they want to know about a Maxi. Is there any chance of a Maxi in the Future?

Michele Battilana: What do you want a Maxi without the operating system?

Amiga Bill: No.

Michele Battilana: So, there needs to be a solution that meets also the constraints, which right now, so you know, Cloanto and Amiga and the Amiga parties took prudent approach. We preferred to wait until the legal issue has clarity. Also, others think they should jump faster and risk. We are more risk adverse. I can not speak for our partners. I think the Mini is doing very well now. It's a form factor, a price point and has this power flow effect that appeals to the masses. A Maxi might be more of a niche product which certainly now you have challenges like pandemic. Logistics like a container used to cost $1,000 now its $20,000. Chip constraints, chips not being available and costing ten times as much. These devices are proof that you can with a nice group deliver hardware in spite of all of this and deliver hardware in quantities than normal Amiga hobby manufacturing can not reach with their scale. Here we can talk about hundreds of thousands of units, sure. An Amiga Maxi with hundreds of thousands of units would be cool but it should be legally available maybe with an operating system and not just games.


Trevor talks about producing 200 A1222 units while Michele talks about hundreds of thousands of niche market Amiga Maxi units (the Mini hardware "appeals to the masses"). If the Amiga Maxi was developed smart, it could outperform the A1222 and beat it in production price. The price could likely compete with the Amiga Mini and the performance/price beat it so that is "appeals to the masses".

Trevor talks like he wants the AmigaOS 4 PPC hardware to be higher end without emulation but then he uses this crap bastard NXP P1022 CPU without a real FPU. It has decent integer performance but nothing special.

DMIPS/MHz
1.56 68060 (32 bit in-order)
1.83 ColdFire V5 (32 bit in-order)
2.03 Raspberry Pi 3 Cortex-A53 (64 bit in-order)
2.40 P1022 (32 bit OoO)
3.76 Raspberry Pi 4 Cortex-A72 (64 bit OoO)

The 1994 68060 was using only 8kiB I+D L1 caches and an ancient chip process compared to these other CPUs. The 2002 ColdFire V5 is a similar design which lost performance due to cutting down the 68k ISA in order to scale lower but it added larger L1 caches and a hardware return stack which the 68060 lacks and moved from 600nm to 130nm. The ColdFire is close to the performance of one of the most popular 32-64 bit CPU cores in the world and likely the most popular in-order CPU core in the world, the Cortex-A53. The Cortex-A53 in the Raspberry Pi 3 has L2 caches and is down to 40nm. This performance is poor but this CPU remains popular because in-order CPUs have a smaller area than OoO CPUs and x86-64 CPUs can't scale down that small and draw too much power for many embedded uses. As I recall, the NXP/Freescale P1022 also uses a 40nm process. I've stated before that in-order RISC CPUs have terrible performance and even the lackluster P1022 outperforms the Cortex-A53. The main reason the Coretex-A53 is so bad is difficult to schedule code and a 3 cycle load-use penalty while the 68060 has easy instruction scheduling (performs amazing with unscheduled code but don't try this on a Cortex-A53) and the 68060 has zero load-use penalties for the common mem-reg load (actually one cycle savings so like -1 cycle load-use penalty in compared to RISC). The Raspberry Pi 4 Cortex-A72 is a much improved modern ARM OoO design at 28nm and has a FPU and SIMD unit while we know how much it costs. This is the OoO competition for the P1022 which is embarrassing in comparison. I believe a modernized 68060 could outperform the Cortex-A53 and compete if not outperform the P1022 in integer performance. A modernized 68060 would reunite the Amiga instead of divide it with an EOL low end bastard PPC P1022 CPU. There is already the overpriced low end performance SAM systems that will make it to market first so why Trevor, why? Why not invest in the 68k and uniting the Amiga instead?

Trevor wants to make higher performance PPC Amigas but targets the low end market with expensive systems to enlarge the customer base while ignoring the 68k Amiga market? This makes about as much sense as CBM developing the Amiga as a low end C64 replacement toy and cost reducing it into the Amiga 500 but then trying to sell it as a computer instead of a toy and console competitor.

"The Gaming Chronicles Episode 1, the Commodore Amiga 500 Story"
Jeff Porter Quote:

They walked away from all the shelf space in Toys-r-us, Kmart, Sears and stores like that. They walked away from all that shelf space and went to Entre Computer, Computer Land, CompUSA, whatever and what filled up that shelf space? Nintendo and Sega.


Commodore Amiga - Jeff Porter Interview Re-cap, New Game Demos, Amiga News, SEGA Ports & More!
33:20 https://www.twitch.tv/videos/1619731252

Trevor deserves the hall of shame with CBM managers. You are out of touch. If you aren't going to help the Amiga then please get out of the way of the retro Amiga rebirth and take your crony Ben Hermans with you. The Amiga is not for a rare piece of your computer collection but for the masses. Michele has been too patient and nice in my opinion considering your plot to steal the Amiga and all your shenanigans.

Last edited by matthey on 19-Oct-2022 at 10:15 PM.
Last edited by matthey on 19-Oct-2022 at 10:07 PM.
Last edited by matthey on 19-Oct-2022 at 10:05 PM.

 Status: Offline
Profile     Report this post  
number6 
Re: Amiga37 News
Posted on 19-Oct-2022 22:36:30
#27 ]
Elite Member
Joined: 25-Mar-2005
Posts: 11464
From: In the village

@matthey

If you recall the interview with Darren and Chris from last December, it was mentioned that any involvement by Jeri was not going to occur due to her other obligations, hence Chris stepped into her perceived role.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

 Status: Offline
Profile     Report this post  
matthey 
Re: Amiga37 News
Posted on 20-Oct-2022 0:19:44
#28 ]
Super Member
Joined: 14-Mar-2007
Posts: 1684
From: Kansas

#6 Quote:

If you recall the interview with Darren and Chris from last December, it was mentioned that any involvement by Jeri was not going to occur due to her other obligations, hence Chris stepped into her perceived role.


The chipset is not the problem anyway. There are plenty of AGA compatible chipset cores with AA+/AAA RTG/chunky, 16 bit 8+ voice, etc. enhancements to choose from and plenty of FPGA developers to work on it. Newer I/O support may want/require to use SerDes and may be more difficult (Joe Decuir Amiga Corporation badge #3 could probably help). The chipset could stay in a small FPGA if it is not ready for an ASIC. The difficult part is the 68k CPU core. Finding a good chief architect is hard enough but one that has CISC experience is even more rare. I would try to get Mitch Alsup who seems like a perfect fit if we could get him. He would probably know whether it would be worth licensing/buying the 68k CPU cores. Mitch Alsup and the "MC" qualified 68060 core would give instant credibility and interest to the project. The 68060 was only 35% synthesized logic which could be troublesome to move to a more modern process. The ColdFire V5 is a similar design but uses 100% synthesizable logic which makes changing processes easier so it may be useful to license it as well. Another option would be to start with the Apollo core if we could get Jens to takeover chief architect from Gunnar. I'm afraid Gunnar has made a lot of poor design decisions and the core is a long way from what is needed for a professional ASIC. It was ok to make the core 64 bit but the main reason that is done is to increase addressing space but he did it without a MMU and still using 32 bit addressing so he could use 64 bit SIMD registers where a competitive SIMD unit would have 256 bit registers. There are other 68k CPUs available but they are not as advanced with most only being scalar and lacking pipelining although they could be upgraded. The CPU would likely be the slowest to develop and needs an ASIC so it should be worked out first. The lack of a good 68k CPU core likely contributed to the demise of at least the BoXeR and Natami projects which we don't want to see happen again as the Amiga is running out of time for a rebirth.

It would be necessary to raise probably $5-$15 million and raising more later which dilutes shareholders may be necessary. I would hope the businesses involved could raise most of it. Merging some of the businesses would likely make things easier and allow to combine assets instead of all this stepping on each others feet and the potential for deteriorating relations and more lawsuits. I think this is where Michele is headed with Amiga Corporation and a few good business partners like Retro Games Ltd. Allowing investment through stock purchases from outsiders could raise more cash, which as far as I've seen, hasn't even been attempted. Of course it needs a good game plan to attract investors. From what I've seen from Amiga businesses, I would short A-Eon and Hyperion if they were public business and I've never shorted a business before. I would be happy to invest in Amiga Corporation if they want to raise cash to relaunch the 68k Amiga. I still have a descent amount of cash on the side lines while I have been nibbling at stock market lows (DVN, DOW, UAN). I don't consider myself a "rich" investor compared to some of my friends but my commodity heavy portfolio has done well recently.

Last edited by matthey on 20-Oct-2022 at 12:28 AM.

 Status: Offline
Profile     Report this post  
Hans 
Re: Amiga37 News
Posted on 20-Oct-2022 4:01:51
#29 ]
Elite Member
Joined: 27-Dec-2003
Posts: 4985
From: New Zealand

@Hypex
Quote:
Technically there are problems they would need to solve getting it to run. They'd have to port it to little endian first before any major move like that. But my hybrid idea would be a custom compiler that compiled all code using only x86 big endian instructions.

Porting the core OS to little-endian probably wouldn't be that hard, given that most of the code is C. Even drivers shouldn't be difficult, provided they've been written correctly. The RadeonHD/RadeonRX drivers use endianness conversion macros, so compiling it for a little-endian CPU is possible (but never tried). Filesystems may need some rework if the code wasn't written to be endian-agnostic (i.e., without endian conversion macros).

The endianness challenge would be with backward compatibility. Interfacing big-endian PowerPC/68K code with native little-endian code requires conversion. Generating the conversion stubs could be partially automated, except for tag-lists. Tag-list conversions would have to be at least checked manually, because the correct conversion depends on the tag's data type.

EDIT: Endianness handling would also have to be done with message passing.

IMHO, an endianness change is inevitable, and has great value. Even IBM are using little-endian Linux on PowerPC/Power CPUs.

@BigD
Quote:
I enjoyed the coverage, I'm sure the atmosphere was brilliant. I was particularly interested in the AmiBerry section...

That's got my attention. What was said? Is there a link to a video (direct to the starting point where they talk about it)?

Hans


Last edited by Hans on 20-Oct-2022 at 06:14 AM.
Last edited by Hans on 20-Oct-2022 at 04:03 AM.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Amiga37 News
Posted on 20-Oct-2022 5:04:50
#30 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3084
From: Germany

@Rob

Quote:

Rob wrote:
@cdimauro

I'm just relaying what has been stated publicly. I offered no opinion.

http://blog.a-eon.biz/blog/?p=13076

If you have a problem with the statements in the blog I'm not the one you should be addressing.

No, I've absolutely no problem: it's still a paper project...

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Amiga37 News
Posted on 20-Oct-2022 5:14:12
#31 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3084
From: Germany

@matthey

Quote:

matthey wrote:

The difficult part is the 68k CPU core. [...] The 68060 was only 35% synthesized logic which could be troublesome to move to a more modern process. The ColdFire V5 is a similar design but uses 100% synthesizable logic which makes changing processes easier so it may be useful to license it as well.

That would be a good starting point. What is missing could be integrated late, while working on the softcore.
Quote:
Another option would be to start with the Apollo core if we could get Jens to takeover chief architect from Gunnar. I'm afraid Gunnar has made a lot of poor design decisions and the core is a long way from what is needed for a professional ASIC. It was ok to make the core 64 bit but the main reason that is done is to increase addressing space but he did it without a MMU and still using 32 bit addressing

Matt, you still haven't got how is his mindset.

This design decision wasn't driven by getting a 64-bit address space. In fact, and as you stated, the external addresses are still 32-bit and there's no PMMU (P is very important here).

His decision to have all 64-bit is dictated by his very simple and primitive logic: reduce the implementation costs. Having a single, homogeneous, register set for all different type or registers was very easy to implement and then the decision was taken. Even if the result is a hacky & horrible patch: it does't matter, as long as it fits the goal (simple implementation).

Exactly the same happened with its prefix for extending the existing instructions to 64 bit and using more registers: driven by the lowest cost implementation.

It's very simple. Do you see it?
Quote:
so he could use 64 bit SIMD registers where a competitive SIMD unit would have 256 bit registers.

256-bit? Not even 128! Ask to the poor Samurai Crow.

See above: it's all about lowest implementation cost.
Quote:
It would be necessary to raise probably $5-$15 million and raising more later which dilutes shareholders may be necessary. I would hope the businesses involved could raise most of it. Merging some of the businesses would likely make things easier and allow to combine assets instead of all this stepping on each others feet and the potential for deteriorating relations and more lawsuits. I think this is where Michele is headed with Amiga Corporation and a few good business partners like Retro Games Ltd. Allowing investment through stock purchases from outsiders could raise more cash, which as far as I've seen, hasn't even been attempted. Of course it needs a good game plan to attract investors. From what I've seen from Amiga businesses, I would short A-Eon and Hyperion if they were public business and I've never shorted a business before. I would be happy to invest in Amiga Corporation if they want to raise cash to relaunch the 68k Amiga. I still have a descent amount of cash on the side lines while I have been nibbling at stock market lows (DVN, DOW, UAN). I don't consider myself a "rich" investor compared to some of my friends but my commodity heavy portfolio has done well recently.

Forget A-Eon, Hyperion, and Trevor: it's not their market (only for Hyperion when Ben needs to fill his pocket invading the emulation market).

Here Michele is the right / best person.

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Amiga37 News
Posted on 20-Oct-2022 5:16:31
#32 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3084
From: Germany

@Hans

Quote:

Hans wrote:
@Hypex
Quote:
Technically there are problems they would need to solve getting it to run. They'd have to port it to little endian first before any major move like that. But my hybrid idea would be a custom compiler that compiled all code using only x86 big endian instructions.

The endianness challenge would be with backward compatibility. Interfacing big-endian PowerPC/68K code with native little-endian code requires conversion.

How do you make them co-exist? That's the biggest burden.

You can't do it. Even trying to convert as much as possible.

That's if you want to keep full backward-compatibility with the existing software. So, having 68k (and even PowerPC) applications running as "first citizens" on the new little-endian system.

 Status: Offline
Profile     Report this post  
Hans 
Re: Amiga37 News
Posted on 20-Oct-2022 5:26:19
#33 ]
Elite Member
Joined: 27-Dec-2003
Posts: 4985
From: New Zealand

@cdimauro

Quote:
How do you make them co-exist? That's the biggest burden.

You can't do it. Even trying to convert as much as possible.

That's if you want to keep full backward-compatibility with the existing software. So, having 68k (and even PowerPC) applications running as "first citizens" on the new little-endian system.

How did Apple do it when they transitioned from PowerPC to x86?

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

 Status: Offline
Profile     Report this post  
PixelHi 
Re: Amiga37 News
Posted on 20-Oct-2022 11:39:14
#34 ]
Member
Joined: 23-Aug-2022
Posts: 34
From: Unknown

@Hans

they basically used "emulator" to run old code on the Intel :). What Apple did differently, they did iit in a way that users would not know that is happening.

That is why I completely don't mind running UAE under AmigaOS4.1 to run the "old" code.

That how I see it.

What about transition from Intel to M1? The same.

Last edited by PixelHi on 20-Oct-2022 at 11:41 AM.

 Status: Offline
Profile     Report this post  
OlafS25 
Re: Amiga37 News
Posted on 20-Oct-2022 13:23:29
#35 ]
Elite Member
Joined: 12-May-2010
Posts: 6171
From: Unknown

@Hans

they do the same now when transitioning from INTEL to ARM

they seem to have a compiler that creates a new binary after first started on the new platform. So first time a user wants to start a program there is a lag, later it is faster. I think one binary can include different hardware platforms

https://www.macrumors.com/2020/07/11/arm-intel-powerpc-universal/

it is called "universal binary" there

 Status: Offline
Profile     Report this post  
Kronos 
Re: Amiga37 News
Posted on 20-Oct-2022 15:42:03
#36 ]
Elite Member
Joined: 8-Mar-2003
Posts: 2284
From: Unknown

@Hans

Quote:

Hans wrote:

How did Apple do it when they transitioned from PowerPC to x86?



The did it with replacing their OS with a proper modern one some years before, no direct memory sharing between apps and no apps peeking (and poking) around in system structures.
And a billion or 2 (or more...) in SW development.

It was far from painless, but most apps used on the Mac were still in active development and those that did not make the transition where soon to be forgotten.

Same can be seen today with their move to ARM.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

 Status: Offline
Profile     Report this post  
matthey 
Re: Amiga37 News
Posted on 20-Oct-2022 17:42:56
#37 ]
Super Member
Joined: 14-Mar-2007
Posts: 1684
From: Kansas

cdimauro Quote:

Matt, you still haven't got how is his mindset.

This design decision wasn't driven by getting a 64-bit address space. In fact, and as you stated, the external addresses are still 32-bit and there's no PMMU (P is very important here).

His decision to have all 64-bit is dictated by his very simple and primitive logic: reduce the implementation costs. Having a single, homogeneous, register set for all different type or registers was very easy to implement and then the decision was taken. Even if the result is a hacky & horrible patch: it doesn't matter, as long as it fits the goal (simple implementation).

Exactly the same happened with its prefix for extending the existing instructions to 64 bit and using more registers: driven by the lowest cost implementation.

It's very simple. Do you see it?


The added registers increase the resource and implementation costs though. He could have just as easily used wider SIMD registers as SIMD sub-operations can be done in parallel as long as they don't get too wide. The SRAM is available in the FPGA he uses to make wider register files and they can be partitioned however desired. Perhaps the max memory access width (128 bit?) is the limiting factor or he doesn't like the corner cases which become worse with wider SIMD registers. Perhaps he likes all the registers the same width so they can hold anything giving him more which is his obsession (it would likely make a rename register implementation easier too but some of his posts make it sound like he is not using rename registers). The result is one man's obsession optimized for the resources of a particular FPGA resources which is not what we need. If FPGA resources were so important and there was no planning for an ASIC, then he should have stayed with a 32 bit CPU core design with compatible FPU and waited to add a SIMD unit (which I advised him at the time to keep the SIMD ISA additions experimental and to finish the FPU implementation instead).

cdimauro Quote:

256-bit? Not even 128! Ask to the poor Samurai Crow.


Poor Samurai Crow who is so helpful but asks questions Gunnar doesn't want to hear. He will never make it to Gunnar's inner circle.

I was thinking it would be better to define fewer 256 bit wide SIMD registers rather than more 128 bit registers. CISC SIMD mem-reg accesses allows to get by with fewer registers, this saves encoding space and SIMD performance is potentially doubled every time the SIMD register width is doubled. Lower end implementations may split the 256b operations into 2x128b operations taking double the cycles. The SIMD unit could be optional also but a standard 256b wide SIMD unit for a 64 bit CPU shouldn't require too many resources with a minimal implementation either. There is also the possibility of a vector unit instead of SIMD unit. That would all be something to consider later by a development team.

cdimauro Quote:

Forget A-Eon, Hyperion, and Trevor: it's not their market (only for Hyperion when Ben needs to fill his pocket invading the emulation market).

Here Michele is the right / best person.


Yes, I agree. Retro Games Ltd. did due diligence before entering into a contract for THEA500 Mini. Michele even said they could have used the "Amiga" name which I thought he may have reserved for a return of Amiga Corporation making real Amiga hardware considering his efforts to reassemble the pieces. Cloanto/Amiga Corporation has more of a right to license AmigaOS 3.1 with it, being the owner, than Ben ever had but we need one AmigaOS development path. I don't understand why Amiga users keep supporting Ben and Trevor instead of boycotting the products from their businesses. It's very risky to buy anything from them as their house of cards is built on the house that Cloanto/Amiga Corporation owns and the retro winds are picking up and likely to blow them over.

OlafS25 Quote:

it is called "universal binary" there


They used to be called fat binaries but the "PC" police must have corrected them. A "ARM64, 32-bit PowerPC, 64-bit PowerPC, i386 and x86_64" binary would be one obese binary. I hope the "PC" police don't make it to our Amiga too. The fat and obese Agnus would have to be renamed in historical revisionism also.

Last edited by matthey on 20-Oct-2022 at 05:56 PM.

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Amiga37 News
Posted on 21-Oct-2022 5:06:11
#38 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3084
From: Germany

@Hans

Quote:

Hans wrote:
@cdimauro

Quote:
How do you make them co-exist? That's the biggest burden.

You can't do it. Even trying to convert as much as possible.

That's if you want to keep full backward-compatibility with the existing software. So, having 68k (and even PowerPC) applications running as "first citizens" on the new little-endian system.

How did Apple do it when they transitioned from PowerPC to x86?

Hans

Because Rosetta had several constraints: https://en.wikipedia.org/wiki/Rosetta_(software)#Rosetta

Basically only user-level applications were supported.

For the rest and as Kronos already briefly replied, MacOS wasn't a toy o.s. and offered getters, setters, and enumerators to access critical resources, providing the right abstraction.

This is totally missing on the Amiga. o.s. and its ports/reimplementation.

So, if you port it to a little-endian architecture you cannot run 68k/PowerPC applications as "first class citizens", freely mixing their execution with the native ones. You cannot convert every single datatype hoping to solve all problems, because this works on limited cases and with simple data structures.

AROS had the same problem since the beginning and the maximum possible is presented by Janus-UAE: https://sourceforge.net/projects/janus-uae/

So, running the 68k Amiga on a sandbox with some interface with the host AROS, trying to make the execution as transparent as possible.

But with all limits of this solution, of course.

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Amiga37 News
Posted on 21-Oct-2022 5:16:52
#39 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3084
From: Germany

@matthey

Quote:

matthey wrote:
cdimauro Quote:

Matt, you still haven't got how is his mindset.

This design decision wasn't driven by getting a 64-bit address space. In fact, and as you stated, the external addresses are still 32-bit and there's no PMMU (P is very important here).

His decision to have all 64-bit is dictated by his very simple and primitive logic: reduce the implementation costs. Having a single, homogeneous, register set for all different type or registers was very easy to implement and then the decision was taken. Even if the result is a hacky & horrible patch: it doesn't matter, as long as it fits the goal (simple implementation).

Exactly the same happened with its prefix for extending the existing instructions to 64 bit and using more registers: driven by the lowest cost implementation.

It's very simple. Do you see it?


The added registers increase the resource and implementation costs though.

For the implementation costs I was primarily referring to the effort needed by an hardware engineer to get a solution for its specific problem.

With the 68080 you have a single register file, all 64-bit in size, which is used for all kind of registers: simple and easy to implement and use.
Quote:
He could have just as easily used wider SIMD registers as SIMD sub-operations can be done in parallel as long as they don't get too wide. The SRAM is available in the FPGA he uses to make wider register files and they can be partitioned however desired. Perhaps the max memory access width (128 bit?) is the limiting factor or he doesn't like the corner cases which become worse with wider SIMD registers. Perhaps he likes all the registers the same width so they can hold anything giving him more which is his obsession (it would likely make a rename register implementation easier too but some of his posts make it sound like he is not using rename registers).

Indeed. See above my reply.
Quote:
The result is one man's obsession optimized for the resources of a particular FPGA resources which is not what we need. If FPGA resources were so important and there was no planning for an ASIC,

It looks like that the FPGA has more than enough resources for implementing a so big register file. In fact, he also implemented something like Hyperthreading, so you have two registers files being used at the same time from the two hardware threads which are running at the same time.
Quote:
then he should have stayed with a 32 bit CPU core design with compatible FPU and waited to add a SIMD unit (which I advised him at the time to keep the SIMD ISA additions experimental and to finish the FPU implementation instead).

Indeed: full compatibility first. The funny thing is that he's claiming 100% compatibility with the Amiga code, which is clearly a lie.
Quote:
cdimauro Quote:

256-bit? Not even 128! Ask to the poor Samurai Crow.


Poor Samurai Crow who is so helpful but asks questions Gunnar doesn't want to hear. He will never make it to Gunnar's inner circle.

I was thinking it would be better to define fewer 256 bit wide SIMD registers rather than more 128 bit registers. CISC SIMD mem-reg accesses allows to get by with fewer registers, this saves encoding space and SIMD performance is potentially doubled every time the SIMD register width is doubled. Lower end implementations may split the 256b operations into 2x128b operations taking double the cycles. The SIMD unit could be optional also but a standard 256b wide SIMD unit for a 64 bit CPU shouldn't require too many resources with a minimal implementation either. There is also the possibility of a vector unit instead of SIMD unit. That would all be something to consider later by a development team.

Vector is the way: you don't have to fix an ISA to a specific register size. This becomes an implementation detail that developers should not care about anymore.

So, a "vector AMMX" could have been 64-bit in size internally and 128-bit in a next implementation, and so on. Without that developers had to change the code each time.
Quote:
cdimauro Quote:

Forget A-Eon, Hyperion, and Trevor: it's not their market (only for Hyperion when Ben needs to fill his pocket invading the emulation market).

Here Michele is the right / best person.


Yes, I agree. Retro Games Ltd. did due diligence before entering into a contract for THEA500 Mini. Michele even said they could have used the "Amiga" name which I thought he may have reserved for a return of Amiga Corporation making real Amiga hardware considering his efforts to reassemble the pieces. Cloanto/Amiga Corporation has more of a right to license AmigaOS 3.1 with it, being the owner, than Ben ever had but we need one AmigaOS development path. I don't understand why Amiga users keep supporting Ben and Trevor instead of boycotting the products from their businesses. It's very risky to buy anything from them as their house of cards is built on the house that Cloanto/Amiga Corporation owns and the retro winds are picking up and likely to blow them over.

Simple: because for them OS4 is the real Amiga o.s. and they are viscerally attached to it. So, they defend everything which is related to OS4, included Hyperion and Ben.

Blind Talibans...
Quote:
OlafS25 Quote:

it is called "universal binary" there


They used to be called fat binaries but the "PC" police must have corrected them. A "ARM64, 32-bit PowerPC, 64-bit PowerPC, i386 and x86_64" binary would be one obese binary. I hope the "PC" police don't make it to our Amiga too. The fat and obese Agnus would have to be renamed in historical revisionism also.

Now it's different: the universal binary is like an IL and the binary get generated at the install time for the specific ISA. AFAIR.

 Status: Offline
Profile     Report this post  
Hypex 
Re: Amiga37 News
Posted on 21-Oct-2022 8:19:29
#40 ]
Elite Member
Joined: 6-May-2007
Posts: 10826
From: Greensborough, Australia

@agami

Quote:
Something more like this perhaps https://en.t-firefly.com/product/industry/itx3568jq


That's more like it!

Quote:
Though personally I'll be ordering this little gem https://en.t-firefly.com/product/industry/itx3588j


Hardcore. Looks like some nice contenders. USB3 and SATA ports. Serial. The only problem with these is they lack PCie slots. So it will end up like a Sam. Even the X5000 is lacking in SATA ports as you only get two ports. It needs more PCie slots as Radeon card will be needed. And the firmware will need an x86 UEFI card emulator. It may have nice built in GPU but unless it's Radeon compatible that won't work. Along with other hardware like sound and Ethernet. If there is no stable working OS4 driver they can code on board devices will be redundant and it will need extra expansion slots,

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 Next Page )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle