@matthey

Quote:

Those who fail to learn from history are doomed to repeat it.

George Santayana, more or less. One of the few trite aphorisms that happens to be true (as can be seen daily by simply watching the news).

_________________
"Unix is supposed to fix that." -- Jay Miner

@matthey

we all know that you have (to say it politely) different views regarding Gunnar. But (as I said lots of times already) it is Gunnars project, he invested years of work in it and has a clear vision where the project should go. Perhaps you are right that if he would have done what you proposed commercial chances in embedded market would be bigger, perhaps not because I cannot judge that but it is work so he can decide what happens. He was the only person ever something really delivering in opposite to many others just talking and then vanishing.

I voted ARM.

The wide availability, support and low price of Raspberry Pi boards make ARM a very compelling choice for the future. It would remove so much uncertainty from the platform on the hardware side, and lower the barrier to entry for growing the Amiga community.

Recognizing that's a longer-term project, I am currently most excited about the near future with fast 680x0 on the Vampire standalone.

@Fl@sh

Quote:

Maintaining a standard API between PPC and 68k AmigaOS would have prevented the split between 2 factions and made 3rd party development easier. Instead of 68k AmigaOS, PPC AmigaOS, MorphOS and AROS, there would have been only AmigaOS, MorphOS and AROS with AmigaOS being the largest user base for developers to target.

It is fairly standard across the board. The main differences being those interfaces. That I hate as much as the next Amiga programmer.

But not only is there the API to consider but the ABI as well. Most of the API works the same, at least on the "C" level, but is way different on the lower ABI level.

I don't know where the original ABI comes from. Using A6 as a base register. And also a negative jump table. Even years ago I could see a backwards jump table as a problem since C structures don't naturally go backwards, if ever. It always looked like a hack to me. And it was tied to 68K since the jump table has jumps to 68K code.

So they needed to replace that system. And decided on the interfaces. Had the interfaces simply been put in place of the base it would have been relatively transparent. But they were added on to get to the jump table. And so need opening. It extends the idea so one library can have multiple interfaces. But it does complicate the once simple opening for a "base" function library. As well as for resources which didn't before need to be closed.

IIRC MorphOS retains the 68K jump table structure and uses some ABI emulation when calling functions so normal 68K style library calls are routed to the PPC routine transparently.

Last edited by Hypex on 31-Jan-2019 at 02:56 PM.

@matthey

Quote:

http://www.fleasystems.com/forums/showthread.php?tid=67 AGA+RTG and maybe SATA would be nice as well. In any case, it should be possible to create a cheap Raspberry Pi like Amiga that is more powerful than any existing 68k hardware for cheap enough to buy as Christmas stocking stuffers.

I know the guy that does the Flea. Tends to frequent my Amiga club. Not seen in a while. Before it had an FPGA it emulated x86 code on some microcontroller.

I meant to invest in one. But then forgot too. Against that was knowing what to do with it. And refreshng my memory it goes beyond what my knowledge is with FPGAs and logic gates.

I'd be intersted to see how it would perform as a drop in CPU replacement.

There was a thread a while back discussing 64 bit OS and 68k. I like this idea the best. If SMP could be managed this would be a good project for Gunnar to make a multi core 68k CPU in ASIC. I bet it could be quite eye opening.

Chris

@QuikSanz

Don't Freescale / NXP hold the patents to the 68k line of CPUs? How can Gunnar and the Apollo team tweak and use their general designs at will? Is it like AMD reinterpretting the x86 requests in a completely different design?

Could someone do the same with PPC?

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

I voted PowerPC knowing the current reality of Amiga and its hardware support. However, I would love to see ARM or RISC-V as possible options. I don't get excited about anything x86 related myself.

Last edited by AmigaMac on 31-Jan-2019 at 05:57 PM.

_________________

@BigD
There are no current 68k patents and implementing something compatible wouldn't be a problem anyway unless some critical mechanism requires a patented implementation.
So it comes to copyright and trademarks, nothing copyrighted is needed for a 68k implementation and the 68*** pattern can't be trademarked.

@matthey

Quote:

matthey wrote: Quote: megol wrote: Yes because the history isn't relevant now. Those who fail to learn from history are doomed to repeat it.

Those that think the current mirrors the past are likely to be disappointed. A modern 68k implementation would look a lot like a modern x86, some features would be lower overhead and some higher.

Quote:

Quote: The full of security holes thing I don't know anything about, what architectural features are you referring to? x86_64 gives too much control in user space. Is it just a coincidence that Spectre and Rowhammer attacks were first documented using the CLFLUSH instruction?

IMHO yes. Most attacks are targeted at x86 as it's the dominating architecture, the equivalent of CLFLUSH are in many other architectures like the PPC which may be familiar? :P
CLFLUSH is just a lazy shortcut BTW, all cache coherent SMP systems are open to the same types of attack and all mainstream architectures are.
CLFLUSH can be replaced by a number of reads forcing the current data to be pushed from L1 cache.

Intels TSX transactional instructions are useful for some attacks as they allow protection violations to be caught in user mode (in an architecturally safe manner). But again that is just a lazy shortcut, data leakage due to Spectre is still there without TSX.

Intel did have the Meltdown problem but it isn't linked to the x86 architecture. Any OoO design could make the same implementation choice and a few ARM and IBM implementations did.
Quote:

Quote: In the future ARM or RISC-V will probably be the best choice but for now x86 is obviously better, price performance is very good and availability is superb. Running big-endian code isn't a problem since several years (just reduces fusion opportunities) with the MOVBE instruction. The best single core performance architecture gets the games (profitable PC/laptop market) and stays king. Do you think AArch64 or RISC-V single core performance will eventually match x86_64? How?

X86 doesn't have the advantages it had in the past (superior manufacturing processes) so other architectures are likely to equal or surpass it. More registers and architectural warts gone means RISC would theoretically be superior with everything else being equal... But one shouldn't exaggerate the overheads of x86 or (if a modern implementation would exist) 68k.

Quote:

Quote: The problem isn't choosing a processor architecture, it's that Amiga OS and clones are using a dead-end design and have to be rewritten from scratch. That was obvious over 20 years ago... Maintaining full compatibility while adding SMP, memory protection and security is a problem. I don't think Hyperion has been honest while stringing AmigaOS 4 users along for years. I disagree that AmigaOS needs to be rewritten completely from scratch though. These issues can be addressed with custom hardware where off the shelf commodity hardware would be more of a challenge.

The core OS would need rewriting for supporting modern* programming practices, compatibility would require some type of virtual machine. Single address space could possibly be kept but with some costs, passing messages by reference would be very hard to keep without a redesign, resource tracking would require a redesign. Don't know if other code or concepts would even be worth rescuing?
(* not necessary better, just what's expected from an OS)

Quote:

OlafS25 wrote: we all know that you have (to say it politely) different views regarding Gunnar. But (as I said lots of times already) it is Gunnars project, he invested years of work in it and has a clear vision where the project should go. Perhaps you are right that if he would have done what you proposed commercial chances in embedded market would be bigger, perhaps not because I cannot judge that but it is work so he can decide what happens. He was the only person ever something really delivering in opposite to many others just talking and then vanishing.

For your faith in Gunnar, you were confident enough that his FPGA only CPU will go nowhere that you voted for ARM instead of 68k. The AmigaOS is an inferior, alien and uncompetitive OS on ARM where the market is saturated by feature rich and more mature OSs. Gunnar could have created the first compatible and kludge free SMP implementation for AmigaOS, worked on improving the efficiency and security of the AmigaOS microkernel implementation and worked on the most compatible 64 bit implementation possible. Instead, he uber optimizes for an FPGA core to reach the performance of a 68060@100MHz when an ASIC could reach 1000MHz with multiple cores, have multiple SIMD units with floating point support and full precision FPUs all for, perhaps, 1/10 of the price of the FPGA he uses. Let's ignore opportunities in Amiga lala land, put the blinders on and forward march. Of course Hyperion does the same. Maybe Amiga land is like Venezuela where all the reasonable people left and only the incompetent psychopathic leaders and their loyal followers remain.

Last edited by matthey on 31-Jan-2019 at 09:41 PM.

Quote:

Hypex wrote: It is fairly standard across the board. The main differences being those interfaces. That I hate as much as the next Amiga programmer.

The interfaces seemed unnecessary to me and require extra typing. They are not a big problem though. The important part of the API is to have the function names, function purpose and parameters the same.

Quote:

But not only is there the API to consider but the ABI as well. Most of the API works the same, at least on the "C" level, but is way different on the lower ABI level. I don't know where the original ABI comes from. Using A6 as a base register. And also a negative jump table. Even years ago I could see a backwards jump table as a problem since C structures don't naturally go backwards, if ever. It always looked like a hack to me. And it was tied to 68K since the jump table has jumps to 68K code. So they needed to replace that system. And decided on the interfaces. Had the interfaces simply been put in place of the base it would have been relatively transparent. But they were added on to get to the jump table. And so need opening. It extends the idea so one library can have multiple interfaces. But it does complicate the once simple opening for a "base" function library. As well as for resources which didn't before need to be closed. IIRC MorphOS retains the 68K jump table structure and uses some ABI emulation when calling functions so normal 68K style library calls are routed to the PPC routine transparently.

The ABI is mostly transparent for high level programmers. Negative offsets are not a problem on most modern CPUs. As I recall, the first m88k CPU did *not* support negative offsets which caused much complaining by OS programmers and resulted in a late change to the CPU. OSs were using negative offsets in the memory management functions enough that the code would have required major changes to port to the m88k. Structures are easier if the anchor pointer starts at the beginning but C handles negative offsets with ease. Moving some data to a negative offset can be faster as the offset is often a 16 bit signed number (+-32kiB) allowing a range of 64kiB instead of 32kiB to access data with a single pointer. This applies to both the 68k and PPC.

Quote:

Hypex wrote: I know the guy that does the Flea. Tends to frequent my Amiga club. Not seen in a while. Before it had an FPGA it emulated x86 code on some microcontroller. I meant to invest in one. But then forgot too. Against that was knowing what to do with it. And refreshing my memory it goes beyond what my knowledge is with FPGAs and logic gates. I'd be interested to see how it would perform as a drop in CPU replacement.

Valentin Angelovski is sharp and sounds like a really cool guy. I missed the Indiegogo myself but I'm more interested in his new prototype. The fleaFPGA is not fast though. It only has a TG68 core with MiniMig ECS custom chip simulation. The Apollo Core is probably close to 10x faster. My point was that a 68k ASIC could be 10x faster than the Apollo Core while reducing the already very affordable cost which was $45 U.S. on Indiegogo and approaching Raspberry Pi pricing territory.

@matthey

I voted that because both (ARM and 68k) are different and ARM will become reality very propably (as you propably know), it is a good idea because ARM offers cheap and powerful hardware and with Raspberry standardized hardware with a big community. So to get outside and win new users ARM is best option in my view. Vampire is a nice retro amiga hardware offering features people always asked for. Will it win new users? Yes, at least the standalone version. Will it become a mass product in todays terms? No. There were discussions about a ASIC version with more than 1 Ghz. We will see what will happen.

That does not change the fact that Gunnar did all the work and decides where it goes.

@matthey

I voted that because both (ARM and 68k) are different and ARM will become reality very propably (as you propably know), it is a good idea because ARM offers cheap and powerful hardware and with Raspberry standardized hardware with a big community. So to get outside and win new users ARM is best option in my view. Vampire is a nice retro amiga hardware offering features people always asked for. Will it win new users? Yes, at least the standalone version. Will it become a mass product in todays terms? No. There were discussions about a ASIC version with more than 1 Ghz. We will see what will happen.

That does not change the fact that Gunnar did all the work and decides where it goes.

My choice was 68k. A very close second choice, if I could have made it, would have been PPC.

With respect to 68k, this is by far the most compatible CPU platform from which to enjoy our AMIGA computers. However, the lack of availability (especially for 060 but also even for 030) is a significant problem in our community. The ideal scenario here, from my perspective, would be an open source effort to implement 68k in a modern FPGA, whilst providing it in packages which match the existing pinout of the real CPUs so that they can be used as drop in replacements.

With respect to PPC, this CPU platform provides an excellent way to have the best of both worlds in terms of enjoying the old and experiencing a bit of the new with more powerful machines. I like this direction for the AMIGA, but from my perspective it is still enjoyed as a hobby and I don't see my AMIGA computers as a viable computing platform for general purpose modern day computing tasks.

I am very surprised to see that an overwhelming majority voted x86. Are these genuine votes? It seems to me that there is very little possibility of enjoying the AMIGA platform on the x86 platform. It would mean porting over the OS, and I don't think that's ever likely to happen. Even if it did, this would be a choice that effectively discards the 'old' AMIGA experience and embraces a purely 'new' experience. This, for me, crosses x86 off the list because the old AMIGA computers are an important part of my AMIGA experience as a whole.
I suppose these votes (if genuine) could be driven be a desire to see AROS lead the future direction of the AMIGA platform. I do respect AROS and it's an interesting project. It doesn't capture everything that I personally want from my AMIGA experience, though.

Last edited by BrianHoskins on 01-Feb-2019 at 06:48 AM.

Quote:

matthey Wrote: Go to NXPs web site and see what they are marketing. ARM replaced PPC. I know the feeling as Motorola replaced the 68k with the PPC when the 68k was still the best selling 32 bit embedded CPU in the world.

I have read some of their website. Unless things have changed, ARM is a different implementation of the PPC/RISC technology. Yes, Motorola did good with the 68k. It’s a good processor. However, looking forward, 64 bit is in while 32 bit is fading. A 64 bit chip and arch would be better for Amiga NG.

Quote:

matthey Wrote: Losing money on a product for years with few prospects or a plan for change is no longer an investment risk but financial suicide.

Of course, that’s why I mentioned that ARM could be considered once the PPC has run its course (A-Eon X5000 and A1222 products no longer produced and stocks gone) for the X5000 and A1222 product lines. But the money has already been spent for PPC on X5000 and A1222. The market will decided once the A1222 arrives, and by my understanding there is a market base prepared to buy.

Quote:

matthey Wrote: The beauty of the AmigaOS is its modularity and scalability. The AmigaOS is more marketable when it is small for low powered CPUs than it is big for high end CPUs. IMO, it was pointless to go big without SMP support, better memory protection and better security. There aren't very many OSs that can go as small as the AmigaOS while still being as functional. This is valuable for certain markets like embedded and the smallest and lowest cost hardware where lower performance hardware can be used. The 68k was part of the recipe which allowed a small 68k AmigaOS foot print and there is room to go smaller. Modern electronic devices keep going smaller while OS resource requirements keep going up but this is unsustainable with Moore's Law ending. Opportunity?

Are you suggesting 68k in a multi-core framework? Like an m3, m5, or m7 (similar to i3, i5, i7) but Moto instead of Intel? Aros has SMP.

Quote:

matthey Wrote: Tabor owners who bought production run #1 boards using the e500v2 core would be "unhappy" if production run #2 boards used the more compatible e500mc core. Tabor is still not so cheap that the old board can be discarded when the new one comes out.

I think Trevor has recently mentioned that there has already been a revision to the A1222/Tabor motherboard due to components not being available. It could be that a new core may also be included before the A1222 ships. An owner could easily sell an older Tabor motherboard to acquire a newer model (happens on eBay frequently for Amiga Classics, so Tabor would probably be no different). Others may simply add the 1st generation Tabor to their collection and buy a newer version later.

Quote:

matthey Wrote: It is kind of ironic to call it NG and then say "it should handle retro gaming adequately" (most retro Amiga games won't run on it either).

Of course. I only mentioned retro gaming as only one of the possibilities. I read and see many using their NG Amigas for retro gaming. The X5000 and A1222 can run retro games plus many other (newer) tasks than could be done previously. It wasn’t an exclusive example.

Quote:

OlafS25 Wrote: I voted that because both (ARM and 68k) are different and ARM will become reality very probably (as you probably know), it is a good idea because ARM offers cheap and powerful hardware and with Raspberry standardized hardware with a big community. So to get outside and win new users ARM is best option in my view. Vampire is a nice retro amiga hardware offering features people always asked for. Will it win new users? Yes, at least the standalone version. Will it become a mass product in todays terms? No. There were discussions about a ASIC version with more than 1 Ghz. We will see what will happen.

This is why I also think that ARM would be a better choice than 68k once the PPC in the X5000 and A1222 have run their course. An AmigaOS 4.x that would run natively on a RP3+ would gain potential users since it’s cheap, and cheap is practically king in American consumerism.


I have read where some think open sourcing AmigaOS is a good pathway. However, I think open sourcing AmigaOS would lead nowhere. Aros is already open source and it hasn’t developed as quickly as AmigaOS 4. I’m not saying it’s a bad product. It is a good alternative. But because Aros is open source and it has developed and spread slower than AmigaOS 4, then it can be concluded that open sourcing AmigaOS would be no better.

Last edited by davidf215 on 01-Feb-2019 at 10:31 AM.

@BrianHoskins

I didn't vote and I don't care. However you nailed exactly how the x86 look to separate Amiga from a major asset and that having one hand in its gloried past which is still exciting to a certain core crowd (and perhaps can still be a fun basis for those looking for simple and easy computing and gaming) and one hand reaching for the future (like the ability to use newer gfx cards which is mind boggling considering the base structure is still stemming from 1982-3 design). Especially since x86 isn't the future. You already can see various companies making an in-house cpu to put in various devices, starting from OLED tvs and going to car cpus or microwaves. X86 isn't just an illusion as some kind of a tech advantage for Amiga, it also goes against the Amiga's relative strengths without offering any market advantages. Why? because as of right now you can do whatever you want to do there with what is available there. Even the concept of "there" is wrong because that market is a derivative of consoles and online activities. That is why there's not really an argument by wanting to take Amiga there. This is more of a case of anti AmigaOne, PPC and Hyperion. Mind washed nostalgia crowd driven by the same peeps Elena Novaretti talked about before leaving the scene.

Last edited by Srtest on 01-Feb-2019 at 12:40 PM.

@Srtest

hehe.. u nailed it there:)

_________________
nox's in the house!

@matthey

Quote:

The interfaces seemed unnecessary to me and require extra typing. They are not a big problem though. The important part of the API is to have the function names, function purpose and parameters the same.

From a look at the function calls they are the same from what I can tell. Includng older functions that crossed libraries and had the same function in different names. Interfacing allows to refer to these as one proper name if they chose it. But it also expects functions to be called from an interface name which complicates system calls. The easiest way to deal with it being to activate inline macros.

Quote:

The ABI is mostly transparent for high level programmers. Negative offsets are not a problem on most modern CPUs. As I recall, the first m88k CPU did *not* support negative offsets which caused much complaining by OS programmers and resulted in a late change to the CPU. OSs were using negative offsets in the memory management functions enough that the code would have required major changes to port to the m88k. Structures are easier if the anchor pointer starts at the beginning but C handles negative offsets with ease. Moving some data to a negative offset can be faster as the offset is often a 16 bit signed number (+-32kiB) allowing a range of 64kiB instead of 32kiB to access data with a single pointer. This applies to both the 68k and PPC.

That's interesting about the 88K. I didn't know that. Not that is survived to really make any difference. I'm not a C expert but after learning the basics of structures I just don't see how a structure can work backwards. All examples I read are in a top down approach. Sure you can build a function table as top down then calculate the bottom as a reference pointer to work backwards from. But in Amiga libraries the library pointer is after the function table, where the library structure begins, as part of a whole data block. Suppose I just don't see a way to specify where the intended start is directly in a C structure.

Quote:

Valentin Angelovski is sharp and sounds like a really cool guy. I missed the Indiegogo myself but I'm more interested in his new prototype. The fleaFPGA is not fast though. It only has a TG68 core with MiniMig ECS custom chip simulation. The Apollo Core is probably close to 10x faster. My point was that a 68k ASIC could be 10x faster than the Apollo Core while reducing the already very affordable cost which was $45 U.S. on Indiegogo and approaching Raspberry Pi pricing territory.

Yeah he is a cool guy. The TG68 could be something to build on. An FPGA allows updates and error fixes. But for an ASIC it would need­ a solid core with no mistakes. A lot less margin for error. With that in mind, wouldn't an ASIC of any size require a million bucks for a short run? A major investment.

Quote:

OlafS25 wrote: I voted that because both (ARM and 68k) are different and ARM will become reality very probably (as you probably know), it is a good idea because ARM offers cheap and powerful hardware and with Raspberry standardized hardware with a big community. So to get outside and win new users ARM is best option in my view. Vampire is a nice retro amiga hardware offering features people always asked for. Will it win new users? Yes, at least the standalone version. Will it become a mass product in todays terms? No. There were discussions about a ASIC version with more than 1 Ghz. We will see what will happen.

The future of ARM does look bright because the embedded market is expanding exponentially. The 68k is also good at embedded.

1996 32-bit embedded CPU sales
68k 53.6 million
MIPS 19 million
SuperH 18 million
x86 15 million
i960 6.2 million
ARM 4.2 million
AMD 29k 2.1 million
Coldfire 1 million
SPARC 0.9 million
PowerPC 0.5 million

There were more than double the number of embedded 32 bit 68k CPUs sold in 1996 than x86, ARM and PPC CPUs combined. Motorola abandoned the 68k to push PPC into the embedded market where it was poorly received as demonstrated by ARMs market share today. PPC was much up scaled compared to the 68k and was cache and memory hungry. AArch64 is also up scaled from Thumb2, more complex and cache and memory hungry. It has lackluster performance on mid to low end CPUs like the Cortex-A53 in the Raspberry Pi. The old 32 bit ARM and Thumb2 ISAs out perform it in more than a few cases.

Cortex-A53 Single Core 7-Zip Compression and Decompression (higher is better)
ARM32 880 1600
Thumb2 890 1370
AArch64 860 1420

Thumb2 outperforms AArch64 in compression and ARM32 outperforms it in decompression on the Cortex-A53 using a single core. AArch64 probably does outperform Thumb2 and ARM32 on high end hardware but it is definitely up scaled in comparison. The 68k ISA is closer to the also much liked in embedded Thumb2. Thumb2 is simpler and uses fewer branches but the 68k uses fewer instructions, has less memory traffic and uses fewer caches. The 68k can be improved significantly with enhancements to the ISA which compilers can easily enable. Thumb2 can probably down scale more but the 68k has better performance traits and can be significantly improved. I strongly believe the 68k can be competitive with ARM for mid to low performance CPUs. I have also shown ways to potentially reduce a 68k ASIC price to be competitive considering the Raspberry Pi is subsidized.

Quote:

That does not change the fact that Gunnar did all the work and decides where it goes.

Gunnar contacted people (including me) to join a "team" to help with the project so he could do all the work? An ASIC requires a team effort of professionals and not a one man show so maybe he is a no go. There are other options even though they would likely take longer. There was a business opportunity, but the CPU designer always knows best according to Gunnar. Maybe Steve Wozniak could have created Apple by himself too.