⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ZORRAM

















⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀

Last edited by MEGA_RJ_MICAL on 18-Apr-2026 at 02:44 AM.

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@pixie

Quote:

pixie wrote: @MEGA_RJ_MICAL I am clearly no zorram, I saw the opportunity and went for it, sadly I was mistaken, I do not have the strenght to keep it going. Now I understand how hard it is to be zorram each and everytime

Why have you joined the trash-side of the schwartz? What's having a troll here enough?

@matthey

Quote:

matthey wrote: pixie Quote: Still no Zorram for you, but you may get a new Neo Geo made with new asics. NEOGEO AES+ – Plaion Replai EU https://share.google/JvBX0lmm8wcpKqiZW If this thread was not vandalized with hate speech and anti-free speech censorship by the mentally ill, the Plaion NeoGeo may be of interest to Amiga fans.

*
Quote:

https://plaionreplai.us/pages/faq Quote: PLAION REPLAI is a brand by PLAION dedicated to bringing classic gaming experiences back to life. Through partnerships with Retro Games Ltd. and Atari, we recreate iconic consoles and accessories with modern technology while preserving their original charm and design. RGL tried to get Jeri Ellsworth to produce an Amiga ASIC which she had almost completed through reverse engineering after completing a successful C64 ASIC. The primary goal of these ASICs was cost reduction for increased competitiveness which is likely similar for NeoGeo ASIC(s). https://plaionreplai.us/products/neogeo-aes Quote: Gameplay on the NEOGEO AES+ is not achieved through emulation - instead the console is powered by its legacy ASIC chips, re-engineered by modern standards to accurately replicate the original machine's hardware and software. The system natively plays game software from both new and old game cartridges for the most authentic retro gaming experience. Not emulation, not FPGA approximation, but true console reincarnation etched back into silicon. ... No emulation - Powered by re-engineered ASIC chips Affordable FPGAs have no problem accurately simulating a 68000@12MHz and Z80@4MHz. With the large for the time NeoGeo chipset, a FPGA more expensive than ~$10 FPGAs which can be used to simulate a 68000 Amiga is necessary.

I wonder which 68k softcore are they using. Usually those systems require a 100% compatible implementation because games can rely on specific timings.

Having a perfect reproduction of a 68000 is mandatory in the "retro market", and this is especially true for our beloved Amiga.

@cdimauro

Quote:

What's having a troll here enough?

Friend cdimauro,

you might want to look at that little rectangle on your driving license,
and reconsider the whole "troll" question.

https://www.hplovecraft.com/writings/texts/fiction/o.aspx

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@cdimauro
"Why have you joined the trash-side of the schwartz? What's having a troll here enough? "

for this very same reason, the content i want to put got diluted by his posts, so i wanted to clear the page. Neao Geo is about to launch a neo console based on a new asic, which goes showing somewhat that a new 68k asic could also be possible.

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

cdimauro Quote:

I wonder which 68k softcore are they using. Usually those systems require a 100% compatible implementation because games can rely on specific timings. Having a perfect reproduction of a 68000 is mandatory in the "retro market", and this is especially true for our beloved Amiga.

From advertising, I expect there is no "68k softcore" used but rather a 68k core.

https://presse.plaion.com/en/NEOGEO-AES Quote:

Uncompromising gaming machine Gameplay on the NEOGEO AES+ is not achieved through emulation - instead the console is powered by its legacy ASIC chips, re-engineered by modern standards to accurately replicate the original machine's hardware and software. The system natively plays game software from both new and old game cartridges for the most authentic retro gaming experience. Not emulation, not FPGA approximation, but true console reincarnation etched back into silicon.

The "Not emulation, not FPGA approximation, but true console reincarnation etched back into silicon." implies no FPGA simulation in the console, which I interpret as derogatory negative connotations for FPGA simulation. This is propaganda as FPGA simulation can provide as accurate of logic and timing as an ASIC. There is likely no advantage to using ASICs for low clocked CPUs and custom chips in the NeoGeo except to reduce costs for mass production. The ASIC(s) provide a cost advantage over the MiSTer. A 68k Amiga ASIC SoC could provide much more value as even the CD32 has the AmigaOS which already supports a 68060@100MHz with much higher clock speeds possible. The NeoGeo 68000 core does appear to support likely limited "overclocking" though.

https://presse.plaion.com/en/NEOGEO-AES Quote:

Retro gaming of the future While maintaining the original look and feel, the NEOGEO AES+ implements modern-day quality-of-life features such as low-latency HDMI display output (whilst also including the original AV output for CRT enthusiasts), DIP switches for language selection, overclocking and different display modes, and the ability to store permanent High Scores (Memory Card accessory required).

The 68SEC000 CPU is still available from NXP but, as I recall, it used a fully static embedded version of the 68000 core which is incompatible due to "MOVE to SR" becoming privileged. It is too bad NXP did not make the newer 68000 CPUs configurable to select "MOVE to SR" to be privileged or not from supervisor mode. Considering the resurgence of 68k retro hardware, such a 68000 CPU may still be viable today instead of EOL. The NeoGeo AES+ will likely sell hundreds of thousands of units alone. The more popular Sega Genesis/MegaDrive Mini sold over 1.5 million units and could have used a 68000 and small FPGA for chipset if compatible 68000 CPUs were still available in quantity. I doubt the NeoGeo AES+ will reach 1 million units sold due to the high cost of cartridges but I would not be surprised to see half a million unit sales for the NeoGeo and X68000 each. The 68k Amiga market is likely larger than the NeoGeo, X68000, Atari 68k and Mac 68k markets but likely not as large as the Sega Genesis/MegaDrive market. The 68k Amiga, X68000, 68k Atari and 68k Mac markets allow significant upgrades, as they already support the 68060 at much higher clock speeds, which increases the value more. It is likely the NeoGeo AES+ uses a 68000 core in ASIC. Advertisements say "ASIC chips" implying more than one while the best cost reduction would be a single chip 68k ASIC SoC like single chip ARM ASIC SoCs, often used instead with cheap emulation for Mini consoles. The retro competition appears to be heating up. Too bad the Amiga IP squatting road blocks increase uncertainty for the Amiga market and people with foresight who tried to steer Amiga development toward max cost reduction and value mass market 68k ASIC SoCs were not listened to. Amiga developers could have led the way with the use of ASICs but instead we get no Ultimate 68k Amiga. Sadly, there were millions USD spent on niche of niche PPC bastard Amiga markets instead and these Amiga IP squatters still sabotage the much larger 68k Amiga market.

pixie Quote:

for this very same reason, the content i want to put got diluted by his posts, so i wanted to clear the page. Neo Geo is about to launch a neo console based on a new asic, which goes showing somewhat that a new 68k asic could also be possible.

The NeoGeo AES+ is being launched with the collaboration of SNK, the old NeoGeo developer.

https://presse.plaion.com/SNK-and-PLAION-Announce-the-Return-of-the-King-The-NEOGEO-AES-Comes-Ho Quote:

With pre-orders opening today, and the launch date set as 12th November 2026, the NEOGEO AES+ has been produced in collaboration with SNK, the producers of the original hardware.

I expect SNK licensed NeoGeo related IP to Plaion and not much more. It is likely not much different than Amiga Corporation licensing Commodore/Amiga IP to RGL, a partner of Plaion. Amiga IP uncertainty due to hostile Amiga IP squatters and lawsuits means we get cheap emulation using ARM ASIC SoCs instead of 68k Amiga ASICs, not even FPGAs for the Amiga market from pros. The amount of investment often directly correlates to the amount of uncertainty. Amiga is like a 3rd world country with many shenanigans that normal investors and developers avoid.

By the way, you should have started a new thread about the Plaion NeoGeo with ASICs. The few PPC AmigaNOne fanboys do not read this thread and their sabotage of the 68k Amiga turned off the retro 68k Amiga masses killing Amigaworld.net. That leaves only a few 68k Amiga stragglers and many are not interested in development but are more likely to be interested in retro gaming. The healthy AtariAge site has 5 pages of info and comments about the Plaion NeoGeo in contrast.

https://forums.atariage.com/topic/389647-the-neo-geo-aes-thread/

Only Atari makes it possible.

Last edited by matthey on 19-Apr-2026 at 04:23 AM.

@pixie

Quote:

pixie wrote: @cdimauro "Why have you joined the trash-side of the schwartz? What's having a troll here enough? " for this very same reason, the content i want to put got diluted by his posts, so i wanted to clear the page. Neao Geo is about to launch a neo console based on a new asic, which goes showing somewhat that a new 68k asic could also be possible.

The page should be cleared by moderators: please, write them, signal the page and the troll.


@matthey
Quote:

matthey wrote: cdimauro Quote: I wonder which 68k softcore are they using. Usually those systems require a 100% compatible implementation because games can rely on specific timings. Having a perfect reproduction of a 68000 is mandatory in the "retro market", and this is especially true for our beloved Amiga. From advertising, I expect there is no "68k softcore" used but rather a 68k core.

Makes sense. Especially if 68000 is cheap.

Quote:

The 68SEC000 CPU is still available from NXP but, as I recall, it used a fully static embedded version of the 68000 core which is incompatible due to "MOVE to SR" becoming privileged. It is too bad NXP did not make the newer 68000 CPUs configurable to select "MOVE to SR" to be privileged or not from supervisor mode.

Indeed, but then it's not fully compatible. MOVE SR isn't a rare instruction on old software, so this core can't be used as a full replacement.
Quote:

I expect SNK licensed NeoGeo related IP to Plaion and not much more. It is likely not much different than Amiga Corporation licensing Commodore/Amiga IP to RGL, a partner of Plaion.

But I doubt that the original Neo Geo chips are still available.

Likely, they produced ASICs out of the original schematics. And kept the 68000 core from NXP.

It makes sense invest on ASICs with good enough numbers (which is expected for this product).
Quote:

Amiga IP uncertainty due to hostile Amiga IP squatters and lawsuits means we get cheap emulation using ARM ASIC SoCs instead of 68k Amiga ASICs, not even FPGAs for the Amiga market from pros. The amount of investment often directly correlates to the amount of uncertainty. Amiga is like a 3rd world country with many shenanigans that normal investors and developers avoid.

All relevant Amiga IPs are under Amiga Corporation.

However, the main problem is that important schematics are missing, so it's not possible to perfectly reproduce the old chips. AFAIK only Alice schematics are available.

Without schematics there's no way to faithfully replicate the operation of the original chips --> problems with the retromarket.
Quote:

By the way, you should have started a new thread about the Plaion NeoGeo with ASICs.

pixie should have done it.

Let's see if a moderator can move the posts there (which I prefer: I'd like to keep this thread for code density discussions).

Added a paper on the Literature post.

It's interesting to notice that our beloved 68k are very well positioned to implement such technique which allows to sensibly reduce the number of executed instructions and, hence, very positively contributing to the code density. That's thanks to the extreme flexibility of its MOVEM instructions.

The only downside is that this instruction requires 32 bit (whereas ARM's Thumb-2 equivalent is 16-bit, and can't save any arbitrary register).

However, this technique is hard to implement for compilers. So, it's more tailored towards manually written code.

For regular compilers, which normally push and pop a certain number of sequential registers, there could be the possibility to introduce a few 16-bit instructions which should help in this common case.

For example, PUSHM {reglist} and POPM {reglist} which work on a limited set of registers marked as non-volatile in a new ABI.

Using 2 x 4-bit of opcode space in 16-bit instructions it would be possible to efficiently implement them. reglist could be {d0-d2, a0-a2} or {d4-d6, a4-a6} (which is preferable, since a7 is also non-volatile and should be saved if changed by the callee), with any sequential subrange always starting from the first register (d0, d0-d1, d0-d2, a0, a0-a1, a0-a2).
Essentially, the 4 bits of each instruction define how many data (2 bits) and/or address (2 bits) registers should be saved, or none. The 4 bits are needed because of the separation between data and address registers on 68k (and a few other architectures).

BTW, PUSHM and POPM aren't really new instructions, rather just 16-bit aliases of the corresponding 32-bit MOVEM instructions.

Using one of the two proposed new ABIs should help a lot the generation of code from compilers, with a concrete benefit for the code density.

cdimauro Quote:

Added a paper on the Literature post. It's interesting to notice that our beloved 68k are very well positioned to implement such technique which allows to sensibly reduce the number of executed instructions and, hence, very positively contributing to the code density. That's thanks to the extreme flexibility of its MOVEM instructions. The only downside is that this instruction requires 32 bit (whereas ARM's Thumb-2 equivalent is 16-bit, and can't save any arbitrary register). However, this technique is hard to implement for compilers. So, it's more tailored towards manually written code.

There are 3 ways to load/store multiple registers and "flexibiilty" is the same word used to describe the bitmap mask of the 68020 MOVEM instruction in another research paper.

Methods for Saving and Restoring Register Values across Function Calls
https://www.cs.fsu.edu/~whalley/papers/spe91.pdf Quote:

The experimentation with various methods for saving and restoring registers gave some insight into which hardware mechanisms are most appropriate for saving and restoring registers. First, the measurements reported here indicate that the approach taken in the VAX-11 (a mask at the entry of the called function) results in poorer performance due to the requirement that the mask also must be saved and restored. Furthermore, this mechanism does not support shrink-wrapping. Special instructions that save and restore a set of registers are more flexible and yield better performance. These instructions can be placed at the most appropriate site and the operand(s) that specify the registers to save or restore is part of the instruction and therefore does not need to be saved and restored. These special instructions also reduced the number of instructions executed in the smarter methods. This shows that even though data-flow analysis was used to place saves and restores at more beneficial locations in the code, many saves and restores still tended to cluster together. The question of whether these special instructions should employ a mask or specify a range of registers to preserve is more problematic. The simple approaches could be implemented using the latter mechanism. The advantages are that the instruction may execute faster (no need to scan the mask) and the instruction can be encoded in fewer bits than an instruction that uses a mask. However, the smarter approaches favour the use of bit masks since it would be rare that a contiguous range of registers would be saved before a call (smarter caller) or when shrink-wrapping has been applied (smarter callee). Given the advantages of the smarter approaches, special instructions that use a mask seem to offer the most flexibility.

I will mention the paper notation to save time when examining their results.

1 "load/store" - no load/store multiple registers
2. "special inst" - MOVEM style instructions with static bitmap
3. "mask" - dynamic reg list bitmap used by VAX and 68k FMOVEM with dynamic reg list

A load/store multiple with a range instead of bitmap mask register list is mentioned above as a "special inst" but there is no research data in the paper for it. The dynamic reg list "mask" generated the smallest code and fewest instructions for the "simple callee" method which is closest to simple compilation using most 68k ABIs. The "simple hybrid" method is similar but performs some "data-flow analysis" for function calls reducing the "special inst" code size to about even but using a dynamic list "mask" still uses fewer instructions. However, using a "special inst" like MOVEM reduces the "total memory references performed". See figure 10-12 for 68020 results. Memory data accesses may be more important for small embedded devices as the code may be in flash memory, often SRAM CPU memory is very limited and code accesses are more predictable than data accesses often allowing some prefetch even if no instruction cache. The paper authors mention, "Our production compilers use the simple hybrid approach."

Your paper does not reference my paper even though it uses older references. It does reference Vince Weaver's old "Code Density Concerns for New Architectures" paper with outdated code density data that slighted the 68k, the same paper that led to SuperH being revived instead of the 68k. With all the CISC code density improving techniques being brought back with for example, extensions in RISC-V and already borrowed in Thumb-2, I would expect old CISC research would be important. It sill feels like CISC and the 68k are some ancient forgotten bad tech while compressed load/store ISAs are good after borrowing most of the tech. The RISC propaganda lives on.

cdimauro Quote:

For regular compilers, which normally push and pop a certain number of sequential registers, there could be the possibility to introduce a few 16-bit instructions which should help in this common case. For example, PUSHM {reglist} and POPM {reglist} which work on a limited set of registers marked as non-volatile in a new ABI. Using 2 x 4-bit of opcode space in 16-bit instructions it would be possible to efficiently implement them. reglist could be {d0-d2, a0-a2} or {d4-d6, a4-a6} (which is preferable, since a7 is also non-volatile and should be saved if changed by the callee), with any sequential subrange always starting from the first register (d0, d0-d1, d0-d2, a0, a0-a1, a0-a2). Essentially, the 4 bits of each instruction define how many data (2 bits) and/or address (2 bits) registers should be saved, or none. The 4 bits are needed because of the separation between data and address registers on 68k (and a few other architectures). BTW, PUSHM and POPM aren't really new instructions, rather just 16-bit aliases of the corresponding 32-bit MOVEM instructions.

I do not believe a register list with a range of registers would be good because of the Dn/An register split. Thumb does not use a register list for their LDM/STM instructions either. They have an 8-bit bitmap register list for r0-r7 using a 16-bit encoding and a 16-bit bitmap register list for r0-r15 using a 32-bit encoding. Bitmaps are more "flexible" and easier for compilers to use.

Possible 68k 16-bit encodings for multiple load/store registers.

1. 8-bit bitmap register list for d0-d3/a0-a3 using a 16-bit encoding
- same encoding space as your sequential register range which is not cheap
2. push2/pop2 two consecutive registers using a 16-bit encoding
- cheap encoding using 4-bits for a register
- more viable if better performance than MOVEM of 2 register

These instructions could be peephole optimizations of 32-bit MOVEM encodings too.

While Thumb with their variable length LDM/STM and non-split registers may appear to have an advantage at first glance, T32 is actually at a disadvantage compared to the 68k.

Thumb has Inefficient use of registers
- can only use r0-r12, 13 GP registers as PC and LR lost (68k has 15 GP registers)
- most 16-bit encoded instruction can only use 8 GP regs (68k can use 15 GP regs more often)
- an extra scratch reg is required when loading data (68k uses mem-reg)
- variables in mem require a load and free reg before use (68k barely slows down using mem vars)
- reg spills are more expensive for load/store architectures (68k uses data & vars in mem)
- A32 had SWP(B) like x86 XCHG to swap reg & mem but not T32 (68k does not have but needs less)
- no way to exchange 2 registers so requires 3 instructions (68k has EXG instruction)

These Thumb disadvantages around function calls are significant. The 68k appears to be pretty optimum around function calls from the paper I linked, other than the most common 68k ABI passing function args on the stack. This is not as inefficient as it may first appear as the 68k is CISC and can use args in memory efficiently. It would be nice to pass registers in scratch regs though, especially with smart data-flow analyzed allocation of which args are chosen and not just in the order specified in the function.

cdimauro Quote:

Using one of the two proposed new ABIs should help a lot the generation of code from compilers, with a concrete benefit for the code density.

One ABI talked about in your paper is the Thumb ABI. The other is an optional variable ABI which would make debugging more difficult. I would rather not change the number of scratch regs depending on the function called. Reordering function args so they are scratch or not is ok though. I believe it could improve 68k Amiga code. For example, functions in libraries commonly pass a context pointer in a0 which has to be copied from a2-a5 for each function call where it would be more efficient to hold the variable in a2 and pass it as an arg in a2 where it would be preserved. The called functions may have to spill a register to move the context before calling another function too.