@olegil

"Unfortunately, there's no 68060@500MHz, the only thing that comes close is emulation."

Not yet

People are working on a FPGA version of 68060

@matthey

I got the information some time ago that AROS X64 supports up to 128 GB RAM. If you really need that (at least for desktop use) is another question...

@Hypex

I meant that if one uses a cell phone, one ends up using mobile network (&cellular Base Stations) powered by PPC SoC chips.
(I was intentionally unclear, I think, sorry for that)

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@KimmoK

It's not your fault that people don't know the difference between a cell and a phone

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@OlafS25

I have yet to see an FPGA run anything except serialized IO faster than 600MHz, to reach 500MHz for something as complex as a CPU emulation it would have to be parallellized to the point of sillyness. In my experience. Never seen anything practically useful run at more than 155MHz.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@olegil

I read the discussion about it but of course we will have to wait for the final core

Quote:

olegil wrote: I have yet to see an FPGA run anything except serialized IO faster than 600MHz, to reach 500MHz for something as complex as a CPU emulation it would have to be parallellized to the point of sillyness. In my experience. Never seen anything practically useful run at more than 155MHz.

Higher clock speeds are possible in fpga with some specialized programming and longer pipelines and latencies (drawbacks). Altera is doubling the clock speed of their Cyclone V up with the help of Intel and it should start to be available soon (less than 1 year). The upcoming high end and expensive Stratix should be able to handle a 500MHz plus enhanced 68k. The new Arria with the higher clock speed should be close to achieving 500MHz and would at least be affordable compared to Amiga E-bay pricing craziness. The new Cyclone 5, which may take a little longer, is the most interesting for Amiga projects as it is quite affordable. It should be good enough for 300MHz plus. With enough quantity, an ASIC would be the way to go where 500MHz shouldn't be a problem. Freescale's V5 ColdFire is rumored to be clocked near that and it is very similar to the 68060. The 68k is very powerful even at lower clock speeds. The 68060 was outperforming the early PPC processors which had twice the clock rate and twice the caches to the embarrassment of Motorola trying to sell PowerPC based on it's superior performance. Later versions of MacOS mysteriously stopped working with the 68060 because the fastest Macs were Amigas with emulation on a 68060. Apple, IBM and Motorola (AIM agreement) had already decided to go PowerPC so Motorola actively tried to sabotage the 68060 sales in a rare case of anti-marketing. The 68060 was acceptable for embedded, telecom and the military but PowerPC was the future for desktops and workstations. PowerPC received great compiler support (while 68k code quality deteriorated) but never achieved the holy grail of code generation quality that was supposed to make it far superior to any other processor. It was all hypothetical.

The advantage of creating one's own CPU is that the ISA can remain constant and availability should never be a problem. These reasons may be why Apple started making their own processors. Apple was kind of slow in the beginning (almost went bankrupt) but finally learned about vertical integration and economies of scale. Hyperion obviously doesn't understand either of these business/economics concepts as they suffer more and more. Maybe the Amiga will survive in some form but I doubt it will be because of AmigaOS 4 and PowerPC, 64 bit or not.

Last edited by matthey on 03-Feb-2014 at 06:47 PM.

@olegil

Quote:

olegil wrote: @cdimauro Quote: cdimauro wrote: Exactly. Despite of many claims of some people who don't want to accept the reality... Noone here (as fas as I can remember) claimed Freescale had any new cores on the roadmap. Freescale is (as you are probably aware from previous discussions) busy with two projects: 1: finishing their T-series, which is what they call the 28nm process 64-bit POWER-arch SoC range. Most of these can be bought now, even though there are erratas to the current revisions. New revisions are in the works. 2: LayerScape A, which enhances the peripherals on the P and T series, and introduces ARM cores. The suffix A indicates ARM, and they are saying that they will have both POWER and ARM cores available. I suggest reading http://cache.freescale.com/files/32bit/doc/white_paper/LAYARCHTECHOVWP.pdf?&Parent_nodeId=11824329976657261625E4&Parent_pageType=homepage as it has some good info.

I've read it, but doesn't change the whole picture. I'll talk about it below.
Quote:

Freescale does not see ARM as an improvement over POWER, they see it as a way of reaching those whose CEOs use an ARM-powered phone and therefore believes in the hype. It's extremely good for low power devices for the handheld world, but performance-per-watt is not the only metric out there

It depends entirely by the micro-architecture. ARMs have not intrinsicly less performance than PowerPCs.
Quote:

If you think about it for a moment, it's been a LONG time since Freescale last made a new POWER core, so why would it be busy making a new one NOW, when it JUST last year made e6500? Now is the time to USE the e6500. For crying out loud, they used the e600 (model number for the core previously known as G4) for 8 fricking years (first chip introduced 1999, last chip introduced 2007). If e6500 is any good, we should be using speed-upgraded versions of it for at least a FEW years before migrating. Edit: Ok, maybe not so long time since last, as they made the e5500 (e500mc + 64-bit + e600 FPU) not so long ago. I also see that in another thread here I said the e5500 won't be as good as an e600 on FPU stuff, but if you don't use Altivec it turns out I was wrong there But Freescale has not been doing the "new core every 18 months" (Edit: is it 12?) thing that Intel does. And I don't want them to, either.

But I don't see any roadmap for future, NEW, PowerPC micro-architectures coming from Freescale. Yes, you don't have to release a new architecture after 18 months, but you have to show at least to your customers that in the future new micro-architectures will come, to continue supporting PowerPC.

Freescale has disclosed that it'll invest in R&D only for ARMs. That's the crude reality...

Quote:

Hypex wrote: @cdimauro Quote: Except cases like these, you'll not see new 64-bit applications that can freely run in a 64-bit address space AND be able to "collaborate" (share resources, primarily) with the old 68K and PowerPC software, included the o.s., like it happens now. My point about 64-bit wasn't this. My point was using the latest 64-bit as that should be easier to source than an old 32-bit CPU. And also provide a forward thinking path.

It can happen only if a radical way will be followed, as discussed with itix. See also michalsc interesting messages, which I agree to.
Quote:

After all, if the X1000 developers were thinking only of the current limitations of AmigaOS, they wouldn't have put a dual core 64-bit CPU on the board!

That was just for marketing, to attract people with "modern features".

They have promised SMP, but after the scheduled 2 years nothing was shown, and then reverted to a generic "multi-core" support.

They also announced 64-bit "support", which is generic enough to let people think and dream that a 64-bit o.s. and applications will come. But we have discussed about the enormous problems that 64-bit can bring, and I've already stated what kind of "support" will come for 64-bit.

So, this's just marketing, as I said...
Quote:

You could then argue that OS4 won't be running 64-bit applications or make use of the other core and you'd be right. Except for Linux. So what? If it's possibly cheaper then use it.

A very expensive and limited platform to make Linux running on it...
Quote:

OS4 itself can make use of 64-bit registers. And in theory 68K and current OS4 software can be sandboxed in 32-bit space. Although it seems silly to sandbox OS4 apps when I thought this would have been handled in a new API for OS4 only. It just seems silly to me to have two versions of OS4, one a native OS3 clone and the other a new modern AmigaOS4.

It'll not happen, for the exposed reasons. What you'll see with OS4 is the good old Amiga o.s. 3.1 which'll be patched again to introduce SOME support for multi-core and 64 bits. That's all.

This is all that you can get from a small company which has no resources to work on a radical new AmigaOS4 version which gives support to all the features which are normally expected by a modern o.s.. It's easier to just make a patch over another patch, than thinking about a brand new platform (strongly inspired by the Amiga o.s. APIs).

Be realistic...
Quote:

Linux comes into this. According to the Linux CDs, somehow Linux has a 64-bit PPC kernel, but works with standard 32-bit applications. That is, one CD covers both 32-bit and 64-bit PPC, namely the kernel. Userspace apps somehow run on either 32-bit or 64-bit kernel. Well that's how it looks. Perhaps some insight there into how it's done.

Take a look at the sources: they are available. You'll see that it's easier to get all this stuff because you've a completely different approach. In fact, you don't have public structures (unless for some stuff used by drivers). The key, as explained, is to hide the internals and provide APIs for accessing everything which is needed by applications and drivers.

You cannot achieve this on an Amiga-like/o.s., unless you want to break compatibility with the existing stuff. But, again, it was already discussed.
@Hypex

Quote:

Hypex wrote: @cdimauro Quote: Last but not least, Apple's ARM64 ISA is different from ARM's one, because they changed the pointers "meaning" to introduce some very interesting and useful things. 64-bit pointers only give 8GB of virtual address (which NOW is quite "enough" for anypne), leaving the remaining bits to be used as garbage collector's objects reference counting, plus quick data type check, and some other stuff. This sounds like a bad idea. It sounds just like pointer typing which got Apple into trouble on 68K Why would they do that again? Apple cripped the 68K MAc address space by utilising the upper 8-bits for OS info leaving only 24-bits for the address and no upward 32-bit path. IIRC this was part of the reason Apple had to dump the real Mac OS to get proper multitasking. Replace it with OSX. Apple employed some Amiga developer to get multitasking into Mac OS but after trying he said it was a lost cause, if memory serves.

No, actually it was/is a very good idea, because how the pointers' "tagged" bits are used is handled by the runtime, and non directly by the applications.

The application receive a pointer, and it only has to (de)reference it as usual. In this case the CPU will mask & cut off the tagget bits, so that a correct virtual address can be generated.

The runtime, viceversa, knows how a pointer is structured, and will use the encoded information to make some useful work without requiring checks to external / ad hoc data structures, so avoiding using both more space, bandwidth, and CPU power, compared to the regular runtime.

It's a great advantage.

Quote:

matthey wrote: Quote: Last but not least, Apple's ARM64 ISA is different from ARM's one, because they changed the pointers "meaning" to introduce some very interesting and useful things. 64-bit pointers only give 8GB of virtual address (which NOW is quite "enough" for anypne), leaving the remaining bits to be used as garbage collector's objects reference counting, plus quick data type check, and some other stuff. Using the upper bits of 64 bit pointers would only be a problem when moving to 128 bit addressing (128 bit processors).

No, it isn't. At least for the Apple's solution on how to use some pointer's bits for tagging additional, useful, information.

Again, hiding the internal structures is the key of the success. Applications don't know and are not allowed to access to the internal structure: they just use the pointers the usual way. It's the runtime / o.s. which knows it, and is responsible to handle it correctly.
Quote:

I could mention about how much memory that would address and how unnecessary and wasteful it would be but some marketing genius will probably be contemplating it in a couple of years and then the next thing you know cell phones, cars and even the toaster will be 128 bit. A couple of die shrinks and 128 bit will be a performance enhancement up to twice as fast.

I don't subscribe a future with 128-bit pointers / integer processors. In my vision, 64 bits will be the foundation of a general purpose architecture, which will be accompanied by a (very) wide SIMD unit, which can handle >>64 bits data structures.
Quote:

Quote: This sounds like a bad idea. It sounds just like pointer typing which got Apple into trouble on 68K Why would they do that again? Apple cripped the 68K MAc address space by utilising the upper 8-bits for OS info leaving only 24-bits for the address and no upward 32-bit path. IIRC this was part of the reason Apple had to dump the real Mac OS to get proper multitasking. Replace it with OSX. Apple employed some Amiga developer to get multitasking into Mac OS but after trying he said it was a lost cause, if memory serves. As I recall, the 24 bit addressing was a problem when the 68020 came out. However, it was fixed (made 32 bit clean) pretty early and I would expect had nothing to do with the abandonment of MacOS or the 68k. MacOS did add cooperative multitasking which Apple deemed good enough at the time. Preemptive multitasking must not have been a big factor in computer sales early on or the Amiga would have come out on top.

24-bit addressing was a problem only for badly written applications, which used the upper 8-bit for their stuff, totally ignoring the existence of processors which used some or all of the upper 8-bits of the pointers. Even the 68012, which is a 68010 with 30 bits address bus, is affected by such stupid decision.

@matthey

Quote:

matthey wrote: Quote: NutsAboutAmiga wrote: When you go 64bit, the executable increase in size, etch instruction takes a lot more space. The result is that programs are larger and takes longer to load from disk. While in clock speed has not increased and so the program is not running any faster. x86 -> x86_64 increased about 15% in executable size. This is a variable length encoding though.

To give just a rough idea, Photoshop CS6 public beta executable was 42984904 bytes for the 32-bit version, and 62229448 byte for the 64-bit version. So, it means that the x64 executable is about 45% fatter than the 32-bit one.

I don't know the precise reason for such big increase. I can only say that, on average, x86 instructions are 3.2 bytes long on average, whereas for x64 they are 4.3 bytes long (again, on average). It means that, taking only the code, the increase is about 34%. So, IMO the additional overhead comes from the enlarged data structures (pointers, sizes), which is a huge increase by itself.
Quote:

Does anyone know how much code size will increase with 64 bit PowerPC? If there is enough free encoding space in the 32 bit fixed instructions then it may not be as much although executables tend to grow because of alignment restrictions for 64 bit as well. There ends up being a lot of wasted caches and memory as Cesare Di Mauro pointed out. Not to mention that latencies are increased and can only partially be hidden. This can be offset by die shrinks but PowerPC isn't keeping up.

Exactly. You cannot avoid it.
Quote:

Quote: * What we can get from going 64bit is a clean Power ISA 2.05, no illegal instruction hits, no slowdowns because of it. * We can also get program using more then 4Gbytes. * Memory copy routines can possibly be speeded up. I think 64 bit makes a lot of sense for the PowerPC. Part of the problem is that PowerPC is 20-40% less dense than the 68020+ so it needs a lot of memory. The lack of unaligned load/store on the PowerPC also increases code size. If moving to 64 bit PowerPC increased executable size by 15% like the x86 then executables would start to get really big. That's the problem with going big and it may make sense for servers and workstations.

It'll be interesting to see at least the executables sizes for 32 and 64 bits PowerPC binaries of a big application.
Quote:

On the other hand, an enhanced 32 bit 68k CPU should be able to improve the already excellent code density of the 68k by 5%-15% resulting in executables that could be as little as 2/3 the size of 64 bit PowerPC (64 bit PowerPC executable could be 50% larger than 68k). A Gigabyte of memory is already a huge amount on a 68k Amiga. The 68k has unaligned load/store, doesn't need instructions to pre-fetch memory and the 68060 doesn't need an unrolled loop for maximum performance of a memory copy. Theoretical performance and maximum clock speeds of an enhanced 68k would be a little lower than the PowerPC but it would perform better with mediocre and poor quality code which brings the PowerPC to a crawl. Yes, 64 bit makes sense for the PowerPC but does 64 bit PowerPC make sense for the Amiga?

At least PowerPCs have 64-bit support.

Anyway, no, it's not useful for the Amiga, because it's a dead platform.

For new Amiga o.s./derived platforms a 64-bit version will be good, IF the o.s is also modernized.
Quote:

Quote: AmigaOS Next Generation or OS5.x: ExecBase can be cleaned up, obsolete stuff can be dropped, and more secure ways to deals whit List and massaging can be implemented. Shared Memory can be cleaned up, Shared memory does not need to available all the time, it can be changed to be on a request bases, this will improve memory protection. To keep legacy to AmigaOS4.1 is to moved into virtual box, where its happy believing its the only OS running. With all the 64 bit problems, virtual boxing, development time spent, lack of new software to support the new OS and lack of a PowerPC future with no guarantees that the AmigaOS will come out anything like it was before, it might actually be better and cheaper to develop an enhanced 68k CPU.

Which lacks 64 bits unfortunately and, last but least, a modern FPU and SIMD unit.

I don't know how much interesting will be improving the 68K ISA beyond the Motorola work. Personally I really like this ISA, because it was a pleasure to code. But, honestly, it has too much quirks.

Just for fun, it could be better to develop a new ISA which is modern and strongly 68K inspired.

@Hypex

Quote:

Hypex wrote: @KimmoK Quote: PPC in every cell (almost). With the demise of flip phones and the popular choice being Apple or Android these days is this still the case? In the two above example ARM is used and AFAIK both iOS and Android are locked to the ARM architecture.

No, at least for Android. There's an x86 version, and an x64 is coming soon. There's also a PowerPC version, and may be a MIPS one.
Quote:

I don't know if Windows mobile used Intel or of Motorola uses PowerPC in their phones,

Windows Mobile (aka PocketPC) used ARMs. Windows Phone, also, uses ARMs.

@Hypex

Quote:

Each instruction remains 32-bits as is rigid for PowerPC. However, the increase appears when loading 64-bit values direct to register. Which on PowerPC is worse as it needs 5 serial instructions to do it. Four direct 16-bit loads and a swap.

It can be done with less instructions if some of 16-bit loads are zero. I.e. 16-bit constants need only one instruction.

Quote:

However, I think this can be work around by avoiding a direct load and just reading in from memory instead. Sure it's not from the cache and has more overhead in memory but reduces code size.

It only works if you have base address loaded for easy relative addressing but reduced code size would compensate greater data size.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

It works only for small constants, but they are the common ones.

If you want to see some numbers, I've written a series of articles for x86 & x64 analyzing them from a statistical point of view:

http://www.appuntidigitali.it/18228/statistiche-su-x86-x64-parte-6-valori-immediati/
http://www.appuntidigitali.it/18192/statistiche-su-x86-x64-parte-5-indirizzamento-verso-la-memoria/

The first talks about immediates and second about addressing modes (and the offsets that they use). They are in Italian, but they can be easily translated to another language without losing the content.

When talking about switching from 32 to 64-bit, I think that the executable sizes are mostly affected by function pointers and VMTs, which double their size. That's for the data. For the code it's different.

@matthey

Quote:

Add an additional 15% to that for 64 bit PowerPC (x86 -> x86_64 is about 15%) and now you could be close to 50% larger than 68k. That does start to make a difference in total memory usage but memory is cheap these days as you say. Speed is more important but the 64 bit PowerPC could need 50% more caches than the 68k too. Program load times could take up to 50% longer (not counting data). Going the "big" route is powerful with enough resources like the Intel i series but is PowerPC getting that? It looks to me like the PowerPC is throttled to lower wattages and the ISA forever changed (with instructions dropped from hardware) for embedded markets and particular applications. The PowerPC is more difficult than most modern processors to develop for and to maximize performance yet the AmigaOS 4 users want a 64 bit PowerPC AmigaOS without any slowdowns. Good luck.

If you care about the size of executables, then you should complain about using .so libraries which are eating a lot of memory on OS4 (they are apparently shared only on the harddrive, in RAM every opener of .so library gets its own copy). You should complain about using foreign frameworks (like Qt) instead of less resource hungry reaction/mui. There are really a lot of places where memory is awfully wasted in amiga land, going 64-bit route is not really one of them ;)

Oh, yeah. That's the Unix, ehr, ehm, the ("new") Amiga way...

@cdimauro

At least on Unix/Linux the .so libraries share as much as possible between all instances, including .data sections (with help of "copy on write"). mmap ftw! ;)

Last edited by michalsc on 04-Feb-2014 at 07:48 AM.

Exactly. But, you know, new amigans should differentiate themselves from the others, so for the "new" way they got the worst solution.
How to kill Amiga o.s. history and philosophy just to easier porting alien software...

@cdimauro

"ARMs have not intrinsicly less performance than PowerPCs"

So far ARM has been totally inferior for high end embedded use.
Too low computing power, memory capability and throughput.
(at least according to coremark)

(IIRC, fastest ARM chips have been 1/6 of the speed of the fastest PPC or intel chips and fastest ARM integrated GPUs have been similarly slow when compared to RadeonHD series)

But coming 64bit ARM chips most likely change things...

"Freescale has disclosed that it'll invest in R&D only for ARMs. That's the crude reality..."

Where? Link please.
Last time I read that they reduce architectures that they develop (like 68k/coldfire).

(and in y2012 material there was NG Power Architecture after T/AMP series, but surely that would happen only after/if AMP series is superb succesfull)

To my understanding past ARM chips have been pretty incompatible with each other.
Meaning that users need to recompile their apps for every ARM chip, or to use JAVA.

Is that changing?
Are ARM 64bit chips binary compatible with each other?

(binary compatibility has been one PPC advantage with "only" few exceptions (like the v500 core).


Said this hundred times, but IMO, ARM is not a sane option yet.
x64 is the only sane option beside PPC.
(and I vote that Amiga developers should focus in x64 and PPC only)

(When some linux distro like Bodhi drop ARM support, I feel our niche has hard time to do what they could not.)

UPDATE: ARM chips binary compatibility is not as bad as I thought. But often it is just recommended to recompile your code.
http://stackoverflow.com/questions/4381102/differences-between-arm-architectures-from-a-c-programmers-perspective "To sum up, if you have C code, then recompile it. Do not try to reuse code compiled for another architecture or system." " The floating point units though are not binary compatible so you have to be careful there. In theory you could compile one least common denominator binary that works across the board, it might not perform well enough though. And/or you could have if-then-else code in the program that if this core or whatever is detected then use it otherwise dont."
Interesting bits: "By default all Android apps run in a VM and are thus processor architecture agnostic, Intel believes that roughly 75% of all Android apps in the Market don't feature any native ARM code." etc... http://www.anandtech.com/show/5365/intels-medfield-atom-z2460-arrive-for-smartphones/5

Anyway... it still seems that there is no ARM (binary) standard CPU family that could be used like PPC or x64 can be used.

UPDATE2: Before doing any ISA change... it might be more sane to do some VM to abstract the CPU core.... I think the rest of the world might do it everywhere, then there would not be any sane binary compatible cores to use natively.
(windows has .net, android some other, how long will we see fully binary compatible x64 chips?)

Last edited by KimmoK on 04-Feb-2014 at 09:39 AM.
Last edited by KimmoK on 04-Feb-2014 at 09:33 AM.
Last edited by KimmoK on 04-Feb-2014 at 08:56 AM.
Last edited by KimmoK on 04-Feb-2014 at 08:54 AM.
Last edited by KimmoK on 04-Feb-2014 at 08:52 AM.
Last edited by KimmoK on 04-Feb-2014 at 08:43 AM.
Last edited by KimmoK on 04-Feb-2014 at 08:33 AM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

I personally would love to know what are the plans with xkernell.
Is it planned to have full backwards compatibility with AOS4.1 SW binaries?
Is it bringing “some” use for 64bit addressing (like RAM disk above 4GB or swap file in high RAM or???)?
Is it bringing new API for NG apps?

Ideally we should have one 64bit branch for true ArOS64, that MOS, AOS and AROS fans could use to build 64bit SMP + MP capable NG of their flavour.


Small update about freescale roadmaps:
Freescale:
"We absolutely stay committed to our Power Architecture and our new e6500
core delivers an unmatched performance/power ratio for the years to come.
We continue to invest in this area."

After e6500 there are "planned": e6501, NGC

from: http://www.freescale.com/files/training/doc/dwf/DWF13_APF_NET_T0795.pdf

And for the first time I read about freescale plans for 64bit ARM.
They plan to have some 4MIPS/Mhz/core while e6500 already does 6MIPS. etc...

Future LayerScape with ARM: 8 ARM Atlas CPUs, 64b, up to 2.4GHz

LayerScape 3400: 20x e6500, 64b, up to 1.5GHz (40 virtual cores per SoC?)

Some new “T” model: T4400 (no details of it, most likely below 2Ghz + 40 virtual cores)

From MZone:
http://www.morphzone.info/modules/newbb_plus/viewtopic.php?forum=3&topic_id=7675&post_id=106836&viewmode=flat&sortorder=0&showonepost=1

update...
And LS2035P seems to be e5500 based....

PCIe Gen3, DDR4, USB etc. are coming. (someone might find use for 100Gbit ethernet as well )
Not real info about T5xxx and T3xxx. Dualcore T5 would be nice for A1. Also there might be some variant with P5 pincompatibility. The NGCore should bring more single thread performance...

Last edited by KimmoK on 04-Feb-2014 at 03:02 PM.
Last edited by KimmoK on 04-Feb-2014 at 10:26 AM.
Last edited by KimmoK on 04-Feb-2014 at 10:18 AM.
Last edited by KimmoK on 04-Feb-2014 at 10:07 AM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?