@matthey

Is that your way of saying "Sorry, I can't back up my claims about performance because it was an anally derived figure I made up because I hate emulation" ?

Last edited by Karlos on 26-Dec-2024 at 10:25 PM.

_________________
Doing stupid things for fun...

@matthey

Please explain how a product like the THEA500 Mini or A600GS could even be possible with just ASIC 68k and AmigaOS?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Karlos

Quote:

You need to show your working/data behind this claim. You would need to compare a benchmark compiled for 68K on the PiStorm, versus a native ARM compiled version.

Apple's Rosetta layer has been measured running Geekbench at up to 80% of native performance.

Quote:

You'd also have to work within like for like conditions, which would mean the ARM native version needs to be running 32-bit Big Endian and wouldn't be allowed to make use of vector extensions.

Surely the JIT should be able to use anything a compiler can use, including vectorisation.

@Matt3k
Quote:

There isn't really much to be done in Amiga 68k productively these day, and we seem to have very healthy options for hardware for 68k that is very welcome. ... I just don't see any slow down or need for more computing power. I

I expect that's true for almost all 68K software but there may be a little bit.
I wrote a software synth on the Amiga many years ago and I tried to be clever and use high resolution waveforms but it was massively overkill and it runs like a dog.
I just got a Raspberry Pi 5 to play with Amiga stuff, and it finally runs at a respectable speed.

I played with sculpt 3D back in the day, I once did a render that took 4 days! I wonder how well it goes these days.

_________________
Whyzzat?

@kolla

Quote:

Please explain how a product like the THEA500 Mini or A600GS could even be possible with just ASIC 68k and AmigaOS?

With sufficient funding it is perfectly possible to build a chip that matches a processor that was slow 12 years ago. However, it's a very expensive process and the market is so small they'll end up costing thousands each.

...or you can buy a chip form China for a few dollars each.

_________________
Whyzzat?

@Hammer

Quote:

1. FYI, AmigaOS 4.1 FE has a userland 68K emulator.

That also allows 68K software to run/emulate inside native supervisor level interrupts.

But we also have a race condition here: Deluxe Music 2.0

One day I will fully investigate it by writing a patch to get trapcode exceptions working, so MonAM can work, and single step through Deluxe Music 2.0 to see where it breaks. I also want to do the same with some VirusCheckers because they fail on library open for no obvious reason. It's been frustrating me the last 20 years no being able to run code through MonAM and see why it breaks.

Quote:

AmigaOne PowerPC's price failed the A500 aspect.

The last would be the A4000 and it's more comparable to an A4000. Expensive against what other computers were offering. But 20 years ago it was better value for money and had computers with similar architecture it could be compared against.

Quote:

A gaming PC nuked video editing workstations like DraCo.

That might explain why they didn't follow it up with a PowerPC version, like was all the rage in Mac and Amiga markets, and instead just replaced it with a PC. Don't know what OS they used. Suppose Windows or Linux possibly but can't find info.

Quote:

A gaming PC with a GeForce card nuked SGI's 3D workstations.

That explains what happened to SGI. So Amiga users shouldn't feel bad that Amiga was cut before it's time. The Atari had chunky graphics in the Falcon, along with the killer MIDI ports and Cubase, and it still only lasted a few more years than the Amiga.

Last edited by Hypex on 27-Dec-2024 at 03:16 AM.

@matthey

Quote:

matthey wrote: Arrogance and incompetence led to this point. The problems started with how Hyperion strong armed and illegally coerced a financially distressed Amiga Inc., likely with Trevor/A-Eon funding instead of buying the Amiga IP like was done later for Amiga Corporation. The shenanigans, uncertainty and financial draining lawsuits reduce the chances of the needed investment to become competitive. Amiga Market analysis was likely inadequate. Targeting the desktop market with an inadequately enhanced AmigaOS was a mistake

To be fair, the arrogance wasn't confined to Amiga IP owners. Many users also had an arrogant attitude towards those of us who didn't want to be dragged into the NG rat race. This site is/was particularly bad. It caused me to throw away most of my Amiga stuff in 2015 because I thought it was worthless.

Quote:

bhabbott Quote: We can already do the equivalent of 68k SoC ASIC with FPGA or bare metal software emulation, so what is the actual market for this chip? I doubt it's enough to justify the expense, so it won't be better value and cheaper. Emulated 68k performance is a fraction of native performance, made worse by different endianness and load-to-use stalls that do not exist on 68k CPUs. High performance FPGA CPU performance is even worse with clock speeds limited to about 100MHz in affordable FPGAs. Power and price are improved with an ASIC. Nothing else comes close to competing with the value of an ASIC. Memory requirements of native code are a fraction of JIT compilation allowing further reductions in price.

Wrong. You are forgetting that hardware performance matters. A cheap Rpi can emulate a 68k CPU much faster than any actual 68k CPU that was ever made or ever will be. It doesn't matter that it's executing ARM instructions 'underneath', any more than it matters what a modern x86 CPU is doing 'underneath'. It executes the code and produces the expected results, which is all we need.

My V2 Vampire is twice as fast as the fastest 68060 you can (or could) get, which makes it just about perfect for those us who want something just a bit better than the fastest Amiga we could have (or did have). Having RTG with HDMI output is the icing on the cake. V4 Vampire is even more powerful and also dramatically enhances AGA. The only real downside of the Vampire is the cost - one would think that new FPGAs would make it cheaper, but the opposite has occurred.

Theoretically an ASIC could be faster, but in practice it won't be because the cost is prohibitive. Unless there is a huge breakthrough in small-scale ASIC production costs it will never be viable in our tiny market.

But that's only one of its flaws. Others include:-

- Making the tiniest change requires doing a whole new production run with similar setup costs, discouraging continued development. If it ever happens it will probably be a one-off, and we will have to put up with what comes out despite its inevitable flaws.

- That's just the CPU. The logical thing to do is make an SoC to emulate custom chips etc., and then the problem gets even worse.

- Due to the high development and production costs and consequences of failure, the project will require strict gatekeeping that limits diversity and innovation. That's very different from an FPGA, Rpi or software emulator where anyone can modify the code without too much effort. People may want to add some feature only they are interested in - perhaps with hacky code that just does the job good enough for them - which wouldn't be appropriate or safe to put into an ASIC.

Quote:

There is no question of the huge ASIC value advantage but it does need mass production volumes which are less clear for the Amiga. ASIC production has risks while there is no risk in micro production for the desktop market which is guaranteed failure.

Wrong again. Failure will be if the retro Amiga scene dies. An ASIC 68k CPU won't help there, in fact it could help destroy it. The idea of an ASIC much faster than anything we have today is silly when we already have far more power than is necessary or even desirable.

Last edited by bhabbott on 27-Dec-2024 at 05:54 AM.

@bhabbott

Checking to see if replying to posts still doesn't work?

Last edited by sibbi on 03-Jan-2025 at 11:01 PM.
Last edited by sibbi on 03-Jan-2025 at 10:56 PM.

_________________
---
Sibbi

Disclaimer:
The opinions stated do not neccesarily represent those of my employer.

@amigakit

Is there a plan to offer a case for this main-board ?

Maybe an Amiga1200 look-a-like case with a fitting keyboard or a desktop case?

Karlos Quote:

Is that your way of saying "Sorry, I can't back up my claims about performance because it was an anally derived figure I made up because I hate emulation" ?

Emulation can not provide the same continuous performance as native in the same way a perpetual motion machine can not provide the same continuous energy as direct energy transfer. Emulation is useful in the same way a flywheel and battery are useful to store energy but the output will be less than the input and there may be other disadvantages. I have examined the disadvantages of emulation already in the following Amigaworld.net post.

https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=45043&forum=14&start=160&176#864212

"Almost 1:1 code" translation chosen by Emu68 programmer Michal Schulz was +24% instructions and +32% code size from 68k to ARM code. Additionally, the in-order Cortex-A53 would only achieve 69% of the performance of a scalar 68k CPU with single cycle basic instruction throughput at the same clock speed where the superscalar in-order 68060 executes more than 1 instruction per cycle (largely due to the lack of instruction scheduling causing load-to-use stalls). This is nearly best case translation of cherry picked 68k code for JIT compilation with the average case for Emu68 translated code traces being much worse. ARM OoO execution can improve performance but the cost is high.

core | transistors
68060 2,500,000
ARM11 9,000,000 (original RPi and RPi Zero)
Cortex-A53 15,000,000 (RPi 3)
Cortex-A57 90,000,000 (predecessor OoO core to the RPi 4 Cortex-A72)

The OoO Cortex-A57 was already ~6 times the transistors of a Cortex-A53 (and ~36 times the transistors of a 68060) with the RPi 4 Cortex-A72 likely significantly more. The additional heat of the OoO Cortex-A72 required an expensive die shrink from 40nm to 28nm while still producing more heat than the RPi 3 and limiting the power budget of the GPU. The RPi 5 required a die shrink to 16nm, can no longer be passively cooled and the price with cooling is close to low end x86-64 SBCs which have better GPUs and much better GPU support. JIT compilation has additional PPA overhead beyond OoO execution and additional large memory requirements. Do not let the relatively cheap price of OoO ARM SoCs using JIT compilation obscure the inefficiency and lack of competitiveness. RPi uses in-order CPU cores in their fabless semiconductor developed RP2040 and RP2350 MCU/SoCs for a reason and they would be wise to upgrade their RPi 3 to a Cortex-A55. While OoO performance may receive more publicity on the high end, the lack of power efficiency of newer ARM cores limits their options for embedded use.

kolla Quote:

Please explain how a product like the THEA500 Mini or A600GS could even be possible with just ASIC 68k and AmigaOS?

The chipset(s) can use a FPGA or eFPGA blocks on the SoC. The "ROMs" can be in NOR flash which is practically required to be external from the SoC as NOR flash only scales to ~45nm chip process. The RP2350 stacks the NOR flash die on top of the SoC die which is an option. A FPGA can have NOR flash which may be possible to read out by the SoC. There are other NOR flash replacements as well with advantages and disadvantages. The CPU cores are hard blocks in the SoC and OSs are in NAND flash drives these days. What else do you think is required?

bhabbott Quote:

To be fair, the arrogance wasn't confined to Amiga IP owners. Many users also had an arrogant attitude towards those of us who didn't want to be dragged into the NG rat race. This site is/was particularly bad. It caused me to throw away most of my Amiga stuff in 2015 because I thought it was worthless.

Software only businesses have to make money from software. They try to protect their software and force people to upgrade to their software. Killing the classic Amiga to gain Amiga NG users backfired with the flow now reversing back to the 68k Amiga. This would not be a problem if using 68k Amiga hardware for a NG AmigaOS as the classic 68k AmigaOS would still be supported.

bhabbott Quote:

Wrong. You are forgetting that hardware performance matters. A cheap Rpi can emulate a 68k CPU much faster than any actual 68k CPU that was ever made or ever will be. It doesn't matter that it's executing ARM instructions 'underneath', any more than it matters what a modern x86 CPU is doing 'underneath'. It executes the code and produces the expected results, which is all we need.

PPC Amigas can already be emulated with higher performance on high end OoO x86-64 CPU cores due to the old silicon of PPC chips. Even modern silicon low cost and power in-order CPU cores can be similar performance to old OoO PPC cores. The transition from low end to obsolete happens fast when a $30 USD OoO CPU SoC can be replaced by a $3 USD in-order CPU SoC. Emulation makes a $30 USD OoO CPU perform like a $3 USD in-order CPU which is also undesirable. Emulation using a $3 USD in-order CPU SoC may outperform ancient 68k CPU silicon but has obsolete performance compared to native code on an in-order CPU SoC which is actually lower cost considering less resources are required. It may be possible to sell obsolete hardware using emulation like THEA500 Mini in a toy but I believe it sold a fraction of what it could have if it had the best performance in the Amiga market. I hear people say emulated performance is good enough but performance is important even in the 68k Amiga market. The Vamp/AC hardware sales are hurt by PiStorm sales too. Trevor got into the Amiga NG because of the performance compared to classic hardware according to a more recent interview. There are zero sales of emulated Amigas into the embedded market where half of RPi sales are into the embedded market. This would all change with an in-order 68k CPU ASIC SoC.

bhabbott Quote:

My V2 Vampire is twice as fast as the fastest 68060 you can (or could) get, which makes it just about perfect for those us who want something just a bit better than the fastest Amiga we could have (or did have). Having RTG with HDMI output is the icing on the cake. V4 Vampire is even more powerful and also dramatically enhances AGA. The only real downside of the Vampire is the cost - one would think that new FPGAs would make it cheaper, but the opposite has occurred. Theoretically an ASIC could be faster, but in practice it won't be because the cost is prohibitive. Unless there is a huge breakthrough in small-scale ASIC production costs it will never be viable in our tiny market. But that's only one of its flaws. Others include:- - Making the tiniest change requires doing a whole new production run with similar setup costs, discouraging continued development. If it ever happens it will probably be a one-off, and we will have to put up with what comes out despite its inevitable flaws. - That's just the CPU. The logical thing to do is make an SoC to emulate custom chips etc., and then the problem gets even worse. - Due to the high development and production costs and consequences of failure, the project will require strict gatekeeping that limits diversity and innovation. That's very different from an FPGA, Rpi or software emulator where anyone can modify the code without too much effort. People may want to add some feature only they are interested in - perhaps with hacky code that just does the job good enough for them - which wouldn't be appropriate or safe to put into an ASIC.

ASIC production costs are cheap and the 68k may have a cost advantage over ARM by avoiding royalty costs. Development costs may be higher depending on how cheaply mature 68k CPU cores could be licensed. There is the risk that mass production would not be high enough but at least the in-order CPU performance could be much higher than twice a 68060 and likely competitive again. ARM in-order CPU core designs are disappointing while SiFive in-order core designs are much better but suffer from a weak RISC-V ISA handicap compared to the 68k.

bhabbott Quote:

Wrong again. Failure will be if the retro Amiga scene dies. An ASIC 68k CPU won't help there, in fact it could help destroy it. The idea of an ASIC much faster than anything we have today is silly when we already have far more power than is necessary or even desirable.

Are WinUAE and PiStorm performance killing "the retro 68k Amiga scene"? A 68k ASIC offers more performance and compatibility at a lower cost so why would it kill it?

@matthey

Quote:

What else do you think is required?

Have you ever used any of them, or seen a review on youtube?

Notice how there is actual HDMI output? 50 or 60 Hz, with up-scaling options and CRT simulation filters, USB that handle hubs, storage devices, all kinds of HIDs. Software and games presented using carousel (THEA500 mini) or other fancy interface (A600GS), on-screen soft-keyboard that of course can be brought up in the middle of game play, custom mapping of joystick/controller buttons etc etc.

Look at the FPGA systems. The Apollo V4 is nowhere near dealing with all these things, they struggle enough to maintain compatibility with USB input devices of their rather limited user base (and who knows what's really going on under the hood). Same for MiST and its clones, which btw do have baremetal firmwares on ARM that can do all the keyboard/joystcick mapping. The only FPGA system that does it well enough for "the masses" is the MiSTer and its clones, with a dual core ARM running Linux, the firmware doing all "minimig I/O" as well as HUD, being a Linux program, with input mapping, display filters, wifi, networking... The Turbo Chameleon 64 from IComp as well as the Flea FPGA Ohm have _two_ 68k cores running on the FPGA, of which one is just used to host the firmware, HUD and do I/O, while the other is for AmigaOS.

So again... exactly how would you go about doing this with just a 68k chip and AmigaOS? Dual-core or multithreaded 68k chip that does the "firmware stuff" as well as being CPU for AmigaOS? Bare metal or under some host operating system other than AmigaOS? A dedicated instance of AmigaOS to be a frontend (you do claim it is the perfect embedded OS)?

Last edited by kolla on 05-Jan-2025 at 11:22 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey

Quote:

A 68k ASIC offers more performance and compatibility

Please elaborate, how can you have more compatibility with an ASIC 68k that cannot easily be reprogrammed? Do you intend to have different "modes" the ASIC can run as, to provide this "more compatibility"? The AC68080 core can be told to run in "turtle mode", the TG68 core can be told to run as 68000, 68010 or 68020, with or without "turbo", Fx68k is 68000 cycle exact only, Emu68 has a whole range of parameters that can be tweaked on the fly for compatibility with existing software, as do all incarnations of UAE, qemu, musashi etc. What's your plan for an ASIC 68k to accomplish "more compatibility"? Have you never experienced compatibility problems with a 68060?

Last edited by kolla on 05-Jan-2025 at 11:35 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

The only things I really want a _new_ fast 68k ASIC for, are Linux and *BSD, where all sources are available.

When I did my little survey for Gunnar in all the 68k camps, a decade or so ago, the only thing everyone really wanted was a drop-in replacement for 68040, one that doesn't run hot even when you clock it to whatever is possible on the NeXTStation, Mac or whatever.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

kolla Quote:

Have you ever used any of them, or seen a review on youtube? Notice how there is actual HDMI output? 50 or 60 Hz, with up-scaling options and CRT simulation filters, USB that handle hubs, storage devices, all kinds of HIDs. Software and games presented using carousel (THEA500 mini) or other fancy interface (A600GS), on-screen soft-keyboard that of course can be brought up in the middle of game play, custom mapping of joystick/controller buttons etc etc. Look at the FPGA systems. The Apollo V4 is nowhere near dealing with all these things, they struggle enough to maintain compatibility with USB input devices of their rather limited user base (and who knows what's really going on under the hood). Same for MiST and its clones, which btw do have baremetal firmwares on ARM that can do all the keyboard/joystcick mapping. The only FPGA system that does it well enough for "the masses" is the MiSTer and its clones, with a dual core ARM running Linux, the firmware doing all "minimig I/O" as well as HUD, being a Linux program, with input mapping, display filters, wifi, networking... The Turbo Chameleon 64 from IComp as well as the Flea FPGA Ohm have _two_ 68k cores running on the FPGA, of which one is just used to host the firmware, HUD and do I/O, while the other is for AmigaOS.

Licensing SiFive IP is likely the fastest way to advance Amiga I/O and add a memory controller. This gives SerDes capable semi-modern and tested high speed I/O and LPDDR5 memory support. There may be some challenges as far as mapping and configuring the hardware on the Amiga but the code is written in Verilog, uses AMBA interconnects and is designed to be modular like the 68060 core (AC68080 and SAGA are written in VHDL). Amiga drivers would need some work but Linux drivers are available and the situation is no different than where Amiga1 hardware started. There is the advantage that much of the SoC I/O could be standardized and reused in subsequent SoCs while Amiga1 hardware often uses completely new SoCs requiring new drivers.

kolla Quote:

So again... exactly how would you go about doing this with just a 68k chip and AmigaOS? Dual-core or multithreaded 68k chip that does the "firmware stuff" as well as being CPU for AmigaOS? Bare metal or under some host operating system other than AmigaOS? A dedicated instance of AmigaOS to be a frontend (you do claim it is the perfect embedded OS)?

I believe a cycle exact 68000 core for compatibility that could double for I/O and other uses would be valuable along with multiple 68060+ cores. Other CPU cores may be worthwhile to include too. The RP2350 has ARM and RISC-V cores for example. I do not have details on a 68k SoC ASIC as I have neither fully investigated the opportunity nor am I a hardware guy. If you are waiting for a hardware engineer with business and investment knowledge then a project like this would never happen. The idea is not to build a competitive desktop OoO CPU core and I/O into a modern SoC but to license old embedded 68k in-order CPU cores and use with embedded semi-modern SiFive I/O to make a 68k ASIC SoC. The idea assumes Amiga IP is available including kickstarts/ROMs, AmigaOS and Amiga branding.

kolla Quote:

Please elaborate, how can you have more compatibility with an ASIC 68k that cannot easily be reprogrammed? Do you intend to have different "modes" the ASIC can run as, to provide this "more compatibility"? The AC68080 core can be told to run in "turtle mode", the TG68 core can be told to run as 68000, 68010 or 68020, with or without "turbo", Fx68k is 68000 cycle exact only, Emu68 has a whole range of parameters that can be tweaked on the fly for compatibility with existing software, as do all incarnations of UAE, qemu, musashi etc. What's your plan for an ASIC 68k to accomplish "more compatibility"? Have you never experienced compatibility problems with a 68060?

Ideally, actual 68000 and 68060 cores could be licensed. Each 68k core could have the clock frequency dynamically reduced for better compatibility so a turtle mode would be unnecessary. I believe missing 68060 instructions and support could be added back to the 68060 potentially improving 68k compatibility and performance. I have experienced 68060.library problems as the support is difficult with so much missing and games that boot without SetPatch and 68060.library in kickstart can be problematic but both of these issues can be improved.

High performance emulation can be less than compatible. JIT compilation WinUAE bug reports are ignored and THEA500 Mini has JIT off by default for better compatibility. Double precision FPU emulation instead of extended precision is common so the host hardware FPU can be used and may be the only FPU emulation available. The performance option of JIT compilation with double precision FPU lacks 68k compatibility.

kolla Quote:

The only things I really want a _new_ fast 68k ASIC for, are Linux and *BSD, where all sources are available. When I did my little survey for Gunnar in all the 68k camps, a decade or so ago, the only thing everyone really wanted was a drop-in replacement for 68040, one that doesn't run hot even when you clock it to whatever is possible on the NeXTStation, Mac or whatever.

While it should be possible to include a 68040V core and I know some 68k fans would want it, it may be better to save the transistors (68040V is a full static design clockable down to zero, ~800,000 transistors with MMU but no FPU). The 68060 MMU is similar to the 68040 MMU and may need some changes for more modern memory sizes even as a 32-bit CPU. Adding back instructions and support to the 68060 would improve user mode compatibility with the 68040 but supervisor mode is different and would require changes. I believe MMU and Linux/BSD support are valuable but it may be better to modernize the software support for more modern 68k hardware if it was available.

My dream machine would be an A1200NG that could triple boot AmigaOS 3.2, 4.1 and MorphOS.

Last edited by AmigaMac on 07-Jan-2025 at 03:31 PM.

_________________

I wrote a lengthy post on how an ASIC might actually work yesterday, but the internet went down and I lost it grrrr.

Anyway, here's what might actually be possible without spending millions.

There's a free microcoded 68K available so that might provide a route around the different instructions on different processors.

I'd build a singe core with cache, a memory controller and an I/O interface. I'd do the actual I/O on a different FPGA or CPU.

It'd be on an old process, they'll be a lot cheaper to use now. Modern processes are incredibly expensive. Even at 28nm masks were $1 million and prices go up exponentially.

Some ASIC companies allow you to share the wafer with other designs so that'd save more money.

Going to GHz speeds is completely pointless, it would only serve to illustrate what Motorola knew in the mid 80s - 68K was a dead end. The instruction decoding is complex and slow, and the variable length means reading further into the instruction stream is incredibly difficult. At GHz speeds the CPU would spend most of it's time sitting idle waiting on memory.

You might be able to use low latency memory to help here but it's not cheap, something like SRAM might work but it'd severely restrict the amount of memory possible, however on the Amiga this shouldn't be a problem.

It'd get well into hundreds of MHz so well faster than any other 68K, but anything beyond this will cost vast sums.

_________________
Whyzzat?

@matthey

Quote:

I believe MMU and Linux/BSD support are valuable but it may be better to modernize the software support for more modern 68k hardware if it was available

Linux and the BSDs are pretty much the only options you have for any modern 68k incarnation, they are the only ones with … flexible code base and enough developers with skill and willingness.

Anyways, your so called 68k SoC looks kinda ridiculous as it will have "I/O" and "mamagement" processors that are more capable than what the "main" 68k is likely to be.

Last edited by kolla on 09-Jan-2025 at 12:00 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Hypex

Quote:

That also allows 68K software to run/emulate inside native supervisor level interrupts.

Without UAE, the classic AmigaOS 4.1 FE's 68K emulator doesn't work with WHDLoad games and ShapeShifter.

ShapeShifter and Fusion run pretty well on PiStorm-Emu68 PRi 4-equipped Amigas.

WHDLoad games works on PiStorm-Emu68 1.0 PRi 4 equiped Amigas. PiStorm-Emu68 hypervisor fully emulates 68K's supervisor and survives from WHDload.

Quote:

One day I will fully investigate it by writing a patch to get trapcode exceptions working, so MonAM can work, and single step through Deluxe Music 2.0 to see where it breaks. I also want to do the same with some VirusCheckers because they fail on library open for no obvious reason. It's been frustrating me the last 20 years no being able to run code through MonAM and see why it breaks

Deluxe Music 2.0 is useful for quickly double-checking AROS classic Amiga chipset driver compliance.

Quote:

The Atari had chunky graphics in the Falcon, along with the killer MIDI ports and Cubase, and it still only lasted a few more years than the Amiga.

Atari Falcon didn't have memory bandwidth saving 8-bit chunky graphics.

Atari Falcon's unit sales are in the 10,000 to 15,000 range which is worse than AGA's unit sales.

Last edited by Hammer on 09-Jan-2025 at 05:16 AM.

_________________

@matthey

Quote:

Ideally, actual 68000 and 68060 cores could be licensed. Each 68k core could have the clock frequency dynamically reduced for better compatibility so a turtle mode would be unnecessary. I believe missing 68060 instructions and support could be added back to the 68060 potentially improving 68k compatibility and performance. I have experienced 68060.library problems as the support is difficult with so much missing and games that boot without SetPatch and 68060.library in kickstart can be problematic but both of these issues can be improved.

For WHDLoad games, turtle modes are necessary for AC68080 and PiStorm-Emu68.

Modern PC's bare metal legacy doesn't solve PC DOS games that depend on 8088/286 CPU's game loop timings. Running the CPU too fast can break gameplay.

TF1260 has a software-controllable clock speed feature for 68060, hence user can control 68060's clock speed with the WHDLoad startup script.

WinUAE has a quick config profile feature for each of the C= Amiga models. WinUAE's A500 quick config has disabled JIT.


@matthey

Quote:

The ColdFire V5, which is based on the 68060, increased the instruction fetch to 8 bytes per cycle and quadrupled the L1 caches from 8kiB-I/8kiB-D to 32kiB-I/32kiB-D. A modern memory controller and at least a L2 cache would be wanted for a 68k SoC. Integrated eDRAM or a MCU with SRAM memory are alternative options. I do not see any problems as caches and memory are more efficiently used by the 68k than equivalent architectures with the same caches and memory.

ColdFire V5 has 9 stages i.e. 4 stage IFP + 5 stage OEP.

ColdFire V5e = optional MMU and FPU.

Coldfire V5's Dhrystone 2.1 Performance is 1.83 DMIPS/MHz

Coldfire V5 is missing an L2 cache for a modern memory controller.

Coldfire V5 implementations in 0.13 microns with the fastest known variant in the 540 Mhz range.

Reference
https://www.nxp.com/docs/en/supporting-information/RPT68KFORUM.pdf


X86's 0.13-micron examples are
Pentium M with up to 1.8 Ghz (24.5W, Banias),
Pentium M LV with up to 1.3 Ghz (12W, Banias),
Pentium M ULV with up to 1.1 Ghz (7W, Banias),
Mobile Athlon 64 DTR 3700+ 2.4Ghz (19W to 81W, C0 or CG stepping),
Mobile Athlon 64 LP 2700+ 1.6 Ghz (35W, C0 stepping),
Mobile Athlon 64 LP 3000+ 2.0 Ghz (35W, CG stepping),
Athlon 64 FX Socket 939 with up to 2.6 Ghz (CG stepping), supports dual 64bit memory controllers. K8s transition from a 64-bit memory controller into a dual 64-bit memory controllers with Socket 939. K8's FADD SIMD is 128-bit wide, FMUL SIMD is 64-bit wide, 3 64bit ALUs and 3 AGUs.

Pentium M Processor 1.30 GHz includes 1 MB L2 cache with 400 Mhz FSB and DDR1-400
Mobile Athlon 64 LP 3000+ 2Ghz includes 512 KB L2 cache with 800Mhz HT and DDR1-400

Last edited by Hammer on 09-Jan-2025 at 07:58 AM.
Last edited by Hammer on 09-Jan-2025 at 07:56 AM.
Last edited by Hammer on 09-Jan-2025 at 07:53 AM.
Last edited by Hammer on 09-Jan-2025 at 07:45 AM.
Last edited by Hammer on 09-Jan-2025 at 05:45 AM.

_________________

@bhabbott

Quote:

To be fair, the arrogance wasn't confined to Amiga IP owners. Many users also had an arrogant attitude towards those of us who didn't want to be dragged into the NG rat race. This site is/was particularly bad. It caused me to throw away most of my Amiga stuff in 2015 because I thought it was worthless.

I did the opposite when I purchased "for parts" risk A1200, TF1260 (bundled with cheap 68LC060 Rev4), and 68060 rev1 during the COVID-19 lockdown.

"For parts" risk A1200 is mostly working with broken FDD and a timing issue with the expansion edge connector.

I used my 1989 A500 era's external FDD to replace the A1200's internal FDD.
I followed instructions to fix the timing issue with the expansion edge connector.

Emu68's modern Pi WiFi helps with integrating the A1200 into my gaming PC network.

Neo-AmigaNG PPC camp doesn't affect me since none of them follows the "Amiga 500" ideology.

_________________

from developer pov only Amiga NC PPC follows the "Amiga 500" ideology
nice fast usable graphics made on other graphics coprocessors on graphics cards