So we got a new high-end classic Amiga market merging, Vampire, Pistorm, A600GS, Emulation have all pushed the Classic Amiga platform and the 68k performance far above anything the original 68000 platform could do. I think the fastest 68060 was pushed on real hardware was 100Mhz. Most ran at 50mhz. Most users only ever had 68030 or 040 running around that speed, and these were great Amigas for their time. Again most users only had 8, 16 or 32mb of fast Ram only hard core Amiga fans and top end user had 128mb+ of Ram. Plus, the software that required this much was very little back in the day. Now thanks to these new platform we got 68000 system running as fast as PPC system! Now I know some may not like this, due to it being virtual or FPGA based but I just see these as tools bring us an Amiga platform we could only dear to dream about in 90s.

This new platform is starting to get an increase in software support, Amikit XE a high end Amiga Desktop system that was design more for emulation platform, due to it slow performance on classic Amiga, has finally come back on to the system, thanks to things like Vampire or Pistorm. Hollywood and Hollywood Designer runs so much better on these Enhanced Amiga's. Quake 2 port really works well on these platform ad so do many other high end 3d games that would struggle on real hardware.

Gorky 17 a 3d RPG game that Hyperion ported to AmigaOS4 will soon be ported to these Advance Amigas as well, hopefully proving that this new classic Amiga market is now here to stay.

Which leads me to this question what and if this new market needs a name and minimum spec to qualify be of this new platform. In a way I guess Vampire V4 system could be the formation of the minium spec being that Pistorm and Emulation system can push a bit above it grunt.

But as names, here my ideas "Classic Next Gen Amiga", "Advance Amigas", "Enhanced Amiga's", "New Amiga Market", "Amiga Plus", "68K+", "ClassicNG" what do you think and does this new platform need a name/ minium spec standards to help devs etc?

_________________
AmigaNG, YouTube, LeaveReality Studio

@amigang

Vampire V4 is different from PiStorm (hardware)

you can at highest say performance of Vampire is new minimum

@OlafS25

I know, so is Emulation, but they are all designed and can push 68000 platform faster than any 68060 every could and like I said software is starting to appear where it will only really run on Vampire, Pistorm and Emulation based Amigas, but wont run or would struggle on anything less than the top end 68060 cpu. Which not many people have got.

_________________
AmigaNG, YouTube, LeaveReality Studio

@amigang

Quote:

So we got a new high-end classic Amiga market merging,

Merging? You mean emerging? ‘cause if anything, they are diverging!

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@amigang

Gorky is not available “soon� for these systems,
it is available since end of last month already ;)

That not in all countries like s due to not many
resellers reacting (or reacting slowly) on the offer.

If you want it in your country ask your local reseller
about the game. It is available!

I do not think we do need a new name for this asides
from “68k� or “Classic Amiga�. There are big performance
differences (Pistorm at the top of the bunch with distance, then
Vampire, then the rest - emulation system not considered
here). When i port a game to 68k i consider every system
separate and test it separate if it can do this game,
Not as one platform.

Btw not even pistorm would reach x1000 speed though
a pistorm clocked with 2.2 ghz (runs 100% stable, have
my own at that speed) runs only minimally slower than
a Sam460. But a x1000 is out of reach. A x5000 runs
circles around the pistorm (difference not as big as between
pistorm and vampire but still big). I guess pistorm at
2.5 ghz (the maximum) would beat Sam460 but i heard
higher than 2.2 you might get instabilities. For all
Pistorm overclocking you need active cooling but i
got this ;)

@amigang

https://metrosiege.com/download/
It has arrived!

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@amigang

I do not know all different categories means, but you need a advanced Amiga, to have 3D graphics, to write software, you need to find bugs, and this means you need a MMU, or you need to use language that catch errors, any system that sucks at catching bugs, is useless for software development.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

kolla Quote:

Merging? You mean emerging? ‘cause if anything, they are diverging!

Yes, Amiga support is fragmenting and diverging. This includes both the hardware and the AmigaOS with 68000+OCS or 68020+AGA or 68020+AGA+RTG being the base hardware spec and AmigaOS 3.1 being the base AmigaOS spec.

Standardization of a higher 68k Amiga spec could be advantageous but is unlikely. I tried to create an upgraded 68k ISA standard that was a compromise for emulation, FPGA and a potential future ASIC. Most of the retro emulation and simulation developers are focused on accurate existing hardware emulation and simulation and aren't interested in a new spec even as they often provide features like RTG, upgraded audio and/or upgraded I/O. There is much difference between higher end and lower end hardware and emulation, FPGA and ASIC hardware making it difficult to create standards. For example, AMMX emulation may not provide any performance benefit and MMU hardware support is a major performance bottleneck for emulation, a moderate bottleneck for FPGA cores and potentially a minor performance reduction for an ASIC core. A new 68k 64 bit standard would be useful to develop but Gunnar wanted the AC ISA minimal 64 bit support which may not be adequate for 64 bit addressing and is limited by compatibility when I thought it was prudent to consider better 64 bit support using a separate 64 bit mode like x86-64. In any case, cooperation with AmigaOS (or AROS) developers would be needed to add good 68k 64 bit support and test it (AC hardware lacks enough mem and GPU address space for testing but UAE could be used for testing with cooperation). Code density improvements are possible, benefit all by saving caches/mem and are likely to improve performance of all but even this would leave high clocked 68060 hardware out of the spec. Gunnar was against ColdFire optimizations but may have changed his mind after realizing they are simple to enable in dev tools where they often already exist and that the benefit is better than my deliberately conservative estimates. The big problem is that the 68k is an EOL emulation and retro FPGA platform. The funny thing is that this all changes when planning to revive the 68k with an updated 68k ASIC but then the leap forward in performance and value is so far that it completely antiquates all other 68k hardware and creates a unified hardware standard (emulation will copy an ASIC).

How about 1996-68k for the new 68k standard? We already have P96 and the Pentium MMX (P55C) CPU came out in 1996 which AMMX copies from. The 68060 came out in 1994 and the new 68k spec moves the 68k forward about 2 years in 30 years time. Is this enough to build standards on? Is Amiga Neverland the land where we perpetually where bags over our head? What happened to the creativity, innovation and integration that made the 68k Amiga special?

@amigang

I would absolutely love to see a new Amiga 1200 in basically the same form factor sporting 68k under the hood that could support both legacy and new peripherals. It has to be possible right?

_________________

@amigang

commodore hardware with pistorm is not amiga.
it is just joystick, mouse and keyboard inteface for rpi.
nothing more.
no reason to use this shit.
just use rpi and linux on it.

and no it is still not as fast as ppc system.
emu68 on my rpi3 still few times slower than my sam460.
and this is my slowest ppc system.

@matthey

Quote:

matthey wrote: A new 68k 64 bit standard would be useful to develop but Gunnar wanted the AC ISA minimal 64 bit support which may not be adequate for 64 bit addressing

In fact, it's not a 64 bit ISA. It has some support for 64 bit, but definitely not a 64 bit architecture.
Quote:

and is limited by compatibility when I thought it was prudent to consider better 64 bit support using a separate 64 bit mode like x86-64. In any case, cooperation with AmigaOS (or AROS) developers would be needed to add good 68k 64 bit support and test it (AC hardware lacks enough mem and GPU address space for testing but UAE could be used for testing with cooperation).

IMO a 64 bit mode for 68k is needed so that opcodes could be a bit cleaned-up and better (re)used, simplifying the implementation of this new mode. Otherwise you need to revert to the horrible solution of using (16-bit!) prefixes.
Quote:

Code density improvements are possible, benefit all by saving caches/mem and are likely to improve performance of all but even this would leave high clocked 68060 hardware out of the spec.

Correct. In the last period I've converted your source for the "Linux logo" (Weaver's code density challenge) to my new(est) architecture, and I was just barely be able to save a couple of bytes compared to the 68k size.

68k is really a GREAT ISA when coming to code density (and more).

BTW, with your extensions (for the shift instructions and the shorter immediates) the 68k code can shrink a little bit more, taking again the lead.
Quote:

Gunnar was against ColdFire optimizations but may have changed his mind after realizing they are simple to enable in dev tools where they often already exist and that the benefit is better than my deliberately conservative estimates.

Do you mean the MVS and MVZ instructions?

@ppcamiga1
We need more wisdom pearls like this one, sadly you can only repeat them so many times! I remember those times where Amiga was far more then using keyboard, a mouse, the hardware, the operating system, it was an out of body experience. We're missing those days

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@AmigaMac

Quote:

I would absolutely love to see a new Amiga 1200 in basically the same form factor sporting 68k under the hood that could support both legacy and new peripherals. It has to be possible right?

Well Yes, it already here. Pistorm32 or Apollo Icedrake V4 (vampire) if you add these to A1200 you basically have a top end Amiga with GPU support, Sd card, USB, Internet etc.

If the A500 Maxi or Amiga Kit do another Arm board but inside a full size Amiga keyboard I think it will do well, and again give you possibility of emulating a top spec Amiga.

I even kinda like Steve / Checkmate idea of combing Minimig with a Pistorm, so you got Amiga chipsets up to ECS in FPGA form, 1 to 1 emulation and then add the speed of Pistorm. He designed it for his monitor, but again put inside a nice Amiga A1200 like case, call it the A2400 and again I think it would do well.

_________________
AmigaNG, YouTube, LeaveReality Studio

@amigang

I would like to something of an a1200 slim, rather like PS2 slim, retaining the functionality but streamline the design further

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@pixie

Quote:

pixie wrote: I remember those times where Amiga was far more then using keyboard, a mouse, the hardware, the operating system, it was an out of body experience. We're missing those days

Amen.

_________________
All the way, with 68k

@amigang

I see a lot of people voted for 68k+, but I voted for Amiga Plus, because even though these software 68k cores can be used by other classic platforms based on 68k, e.g. Atari, the largest demographic for these products is the Amiga community. Most are engineered as expansions for Amiga computers, and/or are centred around running the Amiga software library, so I feel it's more apt to call this category of systems:

Amiga Plus

Last edited by agami on 13-Jul-2024 at 03:06 AM.

_________________
All the way, with 68k

cdimauro Quote:

In fact, it's not a 64 bit ISA. It has some support for 64 bit, but definitely not a 64 bit architecture.

I'm not sure. Defining a 64 bit CPU is easier as usually the data bus width is adequate. A 64 bit ISA may be more than an ISA for a 64 bit CPU though. The 68000 ISA was often considered 32 bit even though the 16 bit data bus made the CPU 16 bit.

1. data bus width - 68000 CPU is 16 bit, 68000 ISA is undefined
2. max int datatype width - 68000 CPU is 32 bit, 68000 ISA is 32 bit
3. max pointer width - 68000 CPU is 32 bit, 68000 ISA is 32 bit
4. register width - 68000 CPU is 32 bit, 68000 ISA is 32 bit
5. ALU width - 68000 CPU is 16 bit, 68000 ISA is undefined

A 68k CPU with 32 bit ALU and 32 bit cache accesses but 16 bit external data bus would have blurred the lines between a 16 bit and 32 bit CPU. Fewer pins and cheaper memory would have reduced cost while performance could have been closer to the 68020 depending on the cache size.

Now lets consider the AC68080. I believe it has a 64 bit data bus making it a 64 bit CPU.

1. data bus width - AC68080 CPU is 64 bit, AC68080 ISA is undefined
2. max int datatype width - AC68080 CPU is 64 bit, AC68080 ISA is 64 bit
3. max pointer width - AC68080 CPU is 64 bit, AC68080 ISA is 64 bit (lacks 64 bit addressing modes?)
4. register width - AC68080 CPU is 64 bit, AC68080 ISA is 64 bit
5. ALU width - AC68080 CPU is 64 bit, AC68080 ISA is undefined

The AC68080 looks like a 64 bit CPU with a 64 bit ISA except for the lack of 64 bit addressing modes as far as I know (the documentation is poor and I haven't kept up with it). I doubt the lack of 64 bit addressing modes would disqualify either the CPU or ISA from being 64 bit even though it is bizarre when everything else appears to be in place. It isn't really needed without a GPU or more memory so the only reason to add it would be to plan and prepare (R&D) for the future but that doesn't seem to be a high priority. Ironically, the main motivation of most other ISAs to support 64 bit was to gain increased addressing space which appears to be the one 64 bit feature lacking in the AC68080 CPU core.

cdimauro Quote:

IMO a 64 bit mode for 68k is needed so that opcodes could be a bit cleaned-up and better (re)used, simplifying the implementation of this new mode. Otherwise you need to revert to the horrible solution of using (16-bit!) prefixes.

Separate 68k 32 and 64 bit modes looks compelling to me too.

One 68k mode for 32 and 64 bit with prefixes
+ smaller core
+ no mode or mode change overhead
- more instruction decoding overhead from prefixes (size=8/16/32, 64 is prefix)
- reduced code density from prefixes
- less encoding space available
- 16 bit stack alignment for compatibility inefficient for 64 bit

Separate 68k 32 and 64 bit mode
+ 64 bit mode instruction decoding nearly as efficient as 32 bit mode (size=8/16/32/64 bit)
+ maximizes free encoding space and cleans up encoding space in 64 bit mode
+ industry leading 32 and 64 bit code density should be possible
+ more efficient 32 or 64 bit stack alignment is possible in 64 bit mode
+ improved ABI with better performance possible in 64 bit mode (reg args!)
+ 64 bit mode only core is possible to reduce core size
- larger core is necessary for supporting 32 and 64 bit modes
- multiple mode and mode change overhead

Is this an unfair evaluation or did I miss anything important?

cdimauro Quote:

Correct. In the last period I've converted your source for the "Linux logo" (Weaver's code density challenge) to my new(est) architecture, and I was just barely be able to save a couple of bytes compared to the 68k size. 68k is really a GREAT ISA when coming to code density (and more). BTW, with your extensions (for the shift instructions and the shorter immediates) the 68k code can shrink a little bit more, taking again the lead.

The ColdFire instructions and my immediate compression idea would not save much for Weaver's code density contest. The 68020 ISA is close to optimal already for his contest which is good considering how general purpose the 68k instructions used are.

cdimauro Quote:

Do you mean the MVS and MVZ instructions?

Primarily. You may recall that Gunnar changed the AC68080 ISA to add several ColdFire instructions back in including MVS, MVZ and MOV3Q.

Robo Kupka Quote:

What is "mvs" instruction ? I only found it mentioned with the ColdFire cpus and your own note from 2016, mentioning the instruction being removed from Apollo ISA. (http://apollo-core.com/knowledge.php?b=1¬e=1943)

Tommo Noorduin Quote:

It cannot be the coldfire one, that opcode is already used by bank. There was talk about it on discord yesterday, and... Gunnar Quote: lets us talk about .... 68080 instructions -- ROBINHOOD.exe instruction count mvs = 833 mvz = 5670 mov3 = 8826 dbf = 1787 addiwl = 2186 cmpiwl = 5511 src: https://discord.com/channels/726870908568076380/730698753513750539/1192861868029644940 I guess it is very new and does move.b & extb.l like the coldfire one.

http://apollo-core.com/knowledge.php?b=4¬e=40433&z=Bwgk67

For the ROBINHOOD.exe alone, there should be close to 15,329 fewer instructions to execute and at least 30,658 bytes of code saved by the three ColdFire instructions. The "addiwl" and "cmpiwl" are a similar idea to my immediate compression idea although my idea covers all opiw.l including the valuable moviw.l. Just the "addiwl" and "cmpiwl" save another 15,394 bytes. That is 46,052 bytes of code reduction together. The executable is no doubt large (a x86 version of Robin Hood Game.exe may be 2,899,968 bytes but the 68k version is likely smaller) so it may only be ~2% code density improvement. More improvement is possible with other opi.l instructions which are not listed and may not exist in the AC68080 ISA. A few percent code density improvement could give an updated 68k ISA the code density advantage against Thumb2 and they are relatively simple changes for dev tools. This is unlikely to happen with an emulation and even FPGA ISA though. Compiler developers know that emulation is EOL and FPGA development is only important if a competitive ASIC follows.

Last edited by matthey on 13-Jul-2024 at 05:16 AM.

@matthey

Quote:

matthey wrote: cdimauro Quote: In fact, it's not a 64 bit ISA. It has some support for 64 bit, but definitely not a 64 bit architecture. I'm not sure. Defining a 64 bit CPU is easier as usually the data bus width is adequate. A 64 bit ISA may be more than an ISA for a 64 bit CPU though. The 68000 ISA was often considered 32 bit even though the 16 bit data bus made the CPU 16 bit. 1. data bus width - 68000 CPU is 16 bit, 68000 ISA is undefined 2. max int datatype width - 68000 CPU is 32 bit, 68000 ISA is 32 bit 3. max pointer width - 68000 CPU is 32 bit, 68000 ISA is 32 bit 4. register width - 68000 CPU is 32 bit, 68000 ISA is 32 bit 5. ALU width - 68000 CPU is 16 bit, 68000 ISA is undefined A 68k CPU with 32 bit ALU and 32 bit cache accesses but 16 bit external data bus would have blurred the lines between a 16 bit and 32 bit CPU. Fewer pins and cheaper memory would have reduced cost while performance could have been closer to the 68020 depending on the cache size. Now lets consider the AC68080. I believe it has a 64 bit data bus making it a 64 bit CPU. 1. data bus width - AC68080 CPU is 64 bit, AC68080 ISA is undefined 2. max int datatype width - AC68080 CPU is 64 bit, AC68080 ISA is 64 bit 3. max pointer width - AC68080 CPU is 64 bit, AC68080 ISA is 64 bit (lacks 64 bit addressing modes?) 4. register width - AC68080 CPU is 64 bit, AC68080 ISA is 64 bit 5. ALU width - AC68080 CPU is 64 bit, AC68080 ISA is undefined The AC68080 looks like a 64 bit CPU with a 64 bit ISA except for the lack of 64 bit addressing modes as far as I know (the documentation is poor and I haven't kept up with it). I doubt the lack of 64 bit addressing modes would disqualify either the CPU or ISA from being 64 bit even though it is bizarre when everything else appears to be in place. It isn't really needed without a GPU or more memory so the only reason to add it would be to plan and prepare (R&D) for the future but that doesn't seem to be a high priority. Ironically, the main motivation of most other ISAs to support 64 bit was to gain increased addressing space which appears to be the one 64 bit feature lacking in the AC68080 CPU core.

Exactly. Previously I was talking about the ISA, so I don't care about the bus width and/or the ALU width, but I'm only interested on the architecture.

In this case, what's missing is the ability to:
- access any memory location;
- call/jmp code on any memory location.

Whereas the Apollo architecture is crippled to 32-bit. So, and definitely, not a 64-bit architecture.
Quote:

cdimauro Quote: IMO a 64 bit mode for 68k is needed so that opcodes could be a bit cleaned-up and better (re)used, simplifying the implementation of this new mode. Otherwise you need to revert to the horrible solution of using (16-bit!) prefixes. Separate 68k 32 and 64 bit modes looks compelling to me too. One 68k mode for 32 and 64 bit with prefixes + smaller core + no mode or mode change overhead - more instruction decoding overhead from prefixes (size=8/16/32, 64 is prefix) - reduced code density from prefixes - less encoding space available - 16 bit stack alignment for compatibility inefficient for 64 bit Separate 68k 32 and 64 bit mode + 64 bit mode instruction decoding nearly as efficient as 32 bit mode (size=8/16/32/64 bit) + maximizes free encoding space and cleans up encoding space in 64 bit mode + industry leading 32 and 64 bit code density should be possible + more efficient 32 or 64 bit stack alignment is possible in 64 bit mode + improved ABI with better performance possible in 64 bit mode (reg args!) + 64 bit mode only core is possible to reduce core size - larger core is necessary for supporting 32 and 64 bit modes - multiple mode and mode change overhead Is this an unfair evaluation or did I miss anything important?

I mostly agree, because I don't see a big overhead in the mode change: it's a one bit set on SR, and then the decoder which should take it into account when decoding parts of the opcodes.
Quote:

cdimauro Quote: Correct. In the last period I've converted your source for the "Linux logo" (Weaver's code density challenge) to my new(est) architecture, and I was just barely be able to save a couple of bytes compared to the 68k size. 68k is really a GREAT ISA when coming to code density (and more). BTW, with your extensions (for the shift instructions and the shorter immediates) the 68k code can shrink a little bit more, taking again the lead. The ColdFire instructions and my immediate compression idea would not save much for Weaver's code density contest. The 68020 ISA is close to optimal already for his contest which is good considering how general purpose the 68k instructions used are.

I agree, but your extensions (I don't think that the ColdFire ones could contribute it. To be checked) save some bytes here, which is good.
Quote:

cdimauro Quote: Do you mean the MVS and MVZ instructions? Primarily. You may recall that Gunnar changed the AC68080 ISA to add several ColdFire instructions back in including MVS, MVZ and MOV3Q. Robo Kupka Quote: What is "mvs" instruction ? I only found it mentioned with the ColdFire cpus and your own note from 2016, mentioning the instruction being removed from Apollo ISA. (http://apollo-core.com/knowledge.php?b=1¬e=1943) Tommo Noorduin Quote: It cannot be the coldfire one, that opcode is already used by bank. There was talk about it on discord yesterday, and... Gunnar [quote] lets us talk about .... 68080 instructions -- ROBINHOOD.exe instruction count mvs = 833 mvz = 5670 mov3 = 8826 dbf = 1787 addiwl = 2186 cmpiwl = 5511 src: https://discord.com/channels/726870908568076380/730698753513750539/1192861868029644940 I guess it is very new and does move.b & extb.l like the coldfire one.

http://apollo-core.com/knowledge.php?b=4¬e=40433&z=Bwgk67

For the ROBINHOOD.exe alone, there should be close to 15,329 fewer instructions to execute and at least 30,658 bytes of code saved by the three ColdFire instructions.[/quote]
Unfortunately there's no information about how many instructions where decoded, to have some concrete idea about their impact.
Quote:

The "addiwl" and "cmpiwl" are a similar idea to my immediate compression idea although my idea covers all opiw.l including the valuable moviw.l.

Indeed. Those two instructions are brain dead. The compressed immediate addressing mode should have been the obvious solution to the problem. Bah...
Quote:

Just the "addiwl" and "cmpiwl" save another 15,394 bytes. That is 46,052 bytes of code reduction together. The executable is no doubt large (a x86 version of Robin Hood Game.exe may be 2,899,968 bytes but the 68k version is likely smaller) so it may only be ~2% code density improvement.

Good, but not so much to make any sensible difference.

IMO what's more important here is the number of executed instructions, which can have a bigger impact on performances. However, and as I've said before, there's no data about it.
Quote:

More improvement is possible with other opi.l instructions which are not listed and may not exist in the AC68080 ISA.

Indeed. Especially considering a 64-bit ISA, you need a compressed immediate mode to have a general solution to this problem. Otherwise you need to add more and more instructions to cover those cases in 64-bit mode as well.
Quote:

A few percent code density improvement could give an updated 68k ISA the code density advantage against Thumb2 and they are relatively simple changes for dev tools.

I agree. However I think that a 64-bit ISA/mode would be much more useful, talking about enlarging the application fields of the architecture.
Quote:

This is unlikely to happen with an emulation and even FPGA ISA though. Compiler developers know that emulation is EOL and FPGA development is only important if a competitive ASIC follows.

Maybe it can come after. But if there's nothing available, there's for sure no chance to have something implemented.

An important thing which I've forgot: a new 68k 64-bit mode allows to better handle several legacy aspects of the current 68k ISA.

I'm talking specifically about the double memory indict modes, which are a big burden to be implemented in a pipelined ISA. However, similar things could be done for complicated stuff like the chk instructions, to give another example.

Since a 68k64 (!) architecture is (by definition!) binary incompatible with the 68k one and it can be compatible only at the source level, this allows to find some creative solutions to such problems. So, you can keep the same source but when compiled to the new ISA the output will be different (albeit the execution is the same, at the very end).

That's why I'm a big fan of source-level compatibility.

amiga community don't need 64 bit or thumb in 68k
what is really needed is cheap real (FPGA or ASIC) 68k with easy to use 16 bit graphics