@Hypex

Quote:

Hypex wrote: @matthey I don't think it would fit either. With base 16 bit for each instruction code it isn't designed for anything else.

68k ha 32-bit opcodes as well...
Quote:

The 68K series supports "parameters" but the standard is 8 data/8 address/8 FPU. Possibly 8 vectors can fit

8 vector registers is too little.
Quote:

but they need to fit in the encoding and the Apollo has it somewhere.

There were some bits that were used for the SIMD (not Vector) unit. That's in F-line, of course.
Quote:

But, they must be extra 16 bit codes, after the main code. They cannot be prefixes like on x86. 68K is not x86 nor 68x or K86. Adding prefixes of any size to 68K is wrong. If BigGun has taken his Intel ideas and coded them that way it would be wrong.

AFAIR prefixes were not used for the SIMD unit, but only for extending the regular 68k instructions.
Quote:

That is not in the standard.

Who defines the standard(s)? Do you know that prefixes are being proposed for the PowerPC ISA?
Quote:

No need to mock the 68K with such a abomination.

I agree... if there are some other solutions.

And there are other solutions, of course: see below.

BTW, you don't necessarily need to introduce a new execution mode for enabling new features. On my ISA I've opted for bigger opcodes, to completely avoid using prefixes.


@matthey

Quote:

matthey wrote: For a 16 bit reg-mem instruction, 8 registers and 2 op instructions are the limit. With a 32 bit reg-mem instruction, 16 registers and 3 op instructions are possible (68k FPU instructions are 32 bits).

68k FPU has 32-bit opcodes, but you can define 3 operands only by using registers (so, not referencing memory) and only with your extension. When referencing memory it can only use two operands (so, the destination must also be used as second source operand).

This means that using 3 operands the FPU is working like many other architectures, but with the big limit of using only 8 registers.

However there's a lot of space for adding another 8, which is good for the 68k, which is a great CISC.
Quote:

It is possible to add a 16 bit prefix to access more registers and allow 3 op instructions. It normally isn't so bad if code mostly uses the lower registers which offer better code density. The x86-64 ISA uses a pre-fix to access the upper 8 of 16 GP registers resulting in a decline of code density. A 68k pre-fix adds an extra 16 bits but the 68k already has 16 registers and 16 more registers would be available as well as 3 op and even leaving a few more bits available.

Yes, mixing regular instructions and new/prefixed instructions only when needed might mitigate the impact on code density.

That's also how x64 is trying (limiting the use of the new REX prefix), but with scarse results...
Quote:

16 bit prefix 1 bit - high bit of source register 1 bit - high bit of destination register 1 bit - high bit of index register (may be avoidable by adding bit to full format extension) 4 bits - 3 op 2nd source register Other potential options 1 bit - CC toggle 1 bit - saturation toggle 1 bit - SIMD toggle 1 bit - 64 bit operation datatype size I believe the AC68080 uses a pre-fix like this

Exactly.
Quote:

with a 64 bit operation datatype size bit which I really don't like as 64 bit operations are common on a fully utilized 64 bit CPU greatly reducing code density, overriding the instruction size and length is bad for decoding and address register operations are already auto extended to 64 bit if following current 68k behavior.

I absolutely agree: that was a completely wrong decision: the default data size should be 64 bit on the ISA.

That's what AMD did with x64. It's simply and purely obvious (albeit not for everybody).
Quote:

It may be better to have a separate 64 bit mode where size=byte, word, long or quad after cleaning up the encodings. This is natural and efficient as Gunnar wanted and even tried to do this but it is not compatible.

I agree.

However and what people don't understand is that a 64 bit mode is anyway backward-incompatible with the 32-bit mode! So, sticking with the same opcode formats is a complete non-sense if you already know that there are big issues / challenges with it.

Keep the old 32 bit mode as it is and create a new 64 bit mode taking the good parts. Like ARM did with its AArch64. And like AMD did NOT with x64, unfortunately (which is another horrible patch on x86).
Quote:

A 68k32 high compatibility mode and 68k64 new mode likely uses more transistors and requires more design work so was rejected by Gunnar.

Which isn't a surprise...

@matthey

Quote:

A high end Amiga should be using a full 68040 with MMU at that time not that there was a high end Amiga during the 68040 and 68060 era due to the gimped low end Amiga chipset. I was referring to low end hardware for the masses like an intermediate upgrade for the CD32+ between a 68EC030 and 68040.

That's fine for the masses. But what were developers using to code and test their products? A common problem was bad coding practices and hacking into OS structures rather than code cleanly and leave it alone.

Quote:

No doubt multiply is more difficult than add to detect overflow. The ColdFire RISC castration just cut off all the upper 32 bits including overflow detection. Higher end 32 bit RISC cores have a MUL and MULH at least although two 2-5 cycle multiplies often have to be performed for 32x32=64 to avoid the hardware complexity of writing results to 2 registers.

I was reading up on the 68000 doing multiply somewhere. It was asked how it was done and a comment was made that it looped around and added the multiplicand up until the multiplier reached zero. Sounds CPU intensive. Another comment described it as shifts and adds. I actually wrote a custom multiplier years ago just experimenting that multiplied by shifting and adding 32 bits.

Quote:

Not likely. The 6800 is an accumulator architecture which is closer to the opposite of RISC in some ways, perhaps more so than CISC.

It was accumulator. In fact it had two. With an instruction count of 72 it would already have less instructions than the average RISC later on.

The 6502 looks like a poor mans 6800. With code similar to 6800. However the 6800 only one X index register thought it does have stack register SP. The copy example below looks more complex than it need be. On 6502 it would be simple load/store decrement/ loop. Perhaps it's made too complimented by forcing variables over registers. No wonder Peddle left!

Quote:

The Motorola 88000 borrowed from the 68k. ColdFire borrowed heavily from the 68k. MCore was "microRISC" that did not borrow much from the 68k and failed miserably.

The 88K was meant to be the 68K RISC follow up. A clean break unlike the ColdFire bastardisation. I don't know much about the MCore.

Quote:

PPC performance improved when maximizing the L1 caches like upgrading to 32kiB I+D L1 caches in the 604e. The shallow pipelines and slower access times of larger caches held PPC back until the on chip L2 cache became practical and PPC had a 2nd wind with the G3 and G4. PPC has always been cache hungry.

The PPC always had an issue with caches. This was said to be why x86 easily outperformed it. Because of the massive caches. Which PPC lacked because it supposedly didn't need it to be an efficient performer. But, it got left behind. The design didn't save it.

Quote:

IBM used CodePack and Motorola/Freescale VLE for code compression. Lack of standardized hardware played a part in killing PPC.

Yes I recall that now. Kind of like of a FLAC for PPC or a PPC LZMA XZ filter. . So hardware decompression on the fly from memory to cache. Not technically a VLE instruction set. Wouldn't want to run self modifying code on that beast!

This is the kind of idea I have for an x86/64 chip that can run PPC code. Just need a PPC to x86 translator. It would be singular to variable size decoding. So far have seen no designs for it from AMD or Intel. If they did that they would surely kill off Power in the server market. Maybe Power 10 is aiming too high but they could surely simulate Power 5 or 6 with such an approach at blistering speed. Internally it be going from a RISC to a CISC to a RISC core but there isn't much choice when the brute force method is the cheapest. PPC was merged with x86 in an early design chip.

Quote:

PPC has all those GP registers so compilers can unroll loops and inline functions. Every variable needs to be pre-loaded into registers for RISC to have good performance and this means spilling non-volatile registers to gain more registers. AmigaOS 4 needing in the order of ten times the stack space says something about the increased memory traffic to and from the PPC stack frame.

This was usual for tight 68K loops and operations as well. To pre-load registers. A simple 68K branch will only stack a long word. On PPC, unless the frame is optimised away, it's 16 bytes minimum, which is four fold. Save registers and then it's worse. It can save space by not stacking FP and vectors when not used. But it all needs 16 byte alignment from the convention. Being OS4 follows standard ABI conventions means the stack would bloat and OS would need more memory.

Quote:

Hollywood executables may contain more data than code.

That's likely true given it's all embedded in one binary.

Quote:

The 68k has efficient branch support which starts with small displacements for good code density but scales up to cover the whole 32 bit address range. Immediates are handled efficiently like this too. RISC ISAs have been slow to adapt even with variable length ISAs as Thumb and RVC don't take full advantage. Only BA2 and the load/store ISA Mitch Alsup was working on take full advantage that I am aware of.

It looks like most RISC attempts at 16 bit encodings are based mostly on code compression. In some attempt to reverse the 32 bit rigid trend. Without introducing a full on new hybrid ISA. BA2 looks closest to offering CISC code density.

Quote:

AmigaOS 4 may retain more of the 68k AmigaOS design and feel than MorphOS or AROS for better or for worse. I don't know if this is due to being more closely derived from it or a deliberate design philosophy. Perhaps it is some of both. Hypex Quote:

Well, they stayed close to it and retained most of the structures. In fact in some places a bit too close. Most alignment is at word boundaries so not efficient for PPC. It uses the same process locking methods for data protection. Even the emulated 68K interrupts run like native interrupts in super mode which I thought was too far. This is said to be for 68K compatibility. But since 68K is still emulated no matter what there could have been a level of separation. There are changes like some lists hidden while public locations remain as blanks.

Quote:

I expect many other Amiga users would have liked to have Amiga chipset compatibility on their RTG PCI cards so they didn't have to switch video outputs. The original Cybervision card has Amiga video passthrough which was more convenient making these cards very desirable today. There was no other choice for high end graphics as C= kept the Amiga chipset low end to turn the Amiga into the next C64 instead of the Next NeXT.

Having a CyberVision I can agree. While it does need the native video passed in as an input it does switch on demand. I used a PicassoIV until the RTG stopped working. The flicker fixer still worked so routed it through the CV.

What they needed which was only be added for AAA was a merging of RTG into the chipset. Which was in the plans for new packed modes. As well as extending the planar modes further for some reason. That or an idea like mine to extend the pixel width across one bitplane. The only issue with integrating with the existing is the latency chip ram had on the system if it wasn't improved.

Quote:

There is no ground breaking jaw dropping advancements in computers anymore. There is only more performance or a cheaper price for the existing technology. Features vary enough to allow for favorite computer environments while compatibility and software availability plays a key role in adoption.

Things have reached a plateau. 3d hardware slowly advances and resolution increases with increased memory. CPUs gain optimisations for speed along with increased clock rates and cores. Memory rates slowly increase. There is a gradual increase in power over time but perhaps things have become so good to the point there's not much that can be advanced.

Some exceptions would be quantum computers. Though they would lack Windows compatibility at present which may hold them back from a large software base. And AI is the current trend. Though it can use GPUs for hardware acceleration. So right now it would be different ways to run software and process data. Over the traditional CPU, graphic and sound increases of power.

Quote:

AmigaOS 4 has good gfx card support but...

1. Politics. Up until around OS4.1/FE it was built in. Later it was an add on. While I don't think the user cares about who provides it I think the user does want an all in one solution without needing to hunt down needed drivers themselves.

2. Since the A1222 is yet to be released to the public does it matter? Lol. Since Apple took desktop PPC away standards declined after the G4 so only embedded was left. Apart from the PA6T but that wasn't to last as Apple took that away as well. That leaves the X5000. With the X1000 forgotten about the X5000 remains as the top contender. But without SIMD support.

3. It's been going downhill for a while. From my perspective the X1000 was the last board that was reasonably power enough while not being overly expensive. Unfortunately it now looks bad against other PPC hardware.

Quote:

Poor quality Linux gfx card drivers are a major problem for ARM and RISC-V desktop systems. PCIe cards for the RPi 4 and 5 were a joke with all but one or two not working. Similar problems likely affect the RISC-V SiFive boards. Using integrated graphics allows for cheaper standard hardware thus avoiding the problem but SiFive doesn't have an open hardware GPU where open hardware is one of their selling points.

I would have imagined them having good support or better than on PPC since they are kept updated and don't have endian issues on little endian. I saw some video on the Raptor Power server with a gfx card. It had no trouble supporting it. Unlike big endian builds of PPC Linux with poor support for anything beyond the HD series. Even for PPC Linux builds back in the day there are guides for broken video on Macs making it look too common.

Quote:

For a 16 bit reg-mem instruction, 8 registers and 2 op instructions are the limit. With a 32 bit reg-mem instruction, 16 registers and 3 op instructions are possible (68k FPU instructions are 32 bits). It is possible to add a 16 bit prefix to access more registers and allow 3 op instructions. It normally isn't so bad if code mostly uses the lower registers which offer better code density. The x86-64 ISA uses a pre-fix to access the upper 8 of 16 GP registers resulting in a decline of code density. A 68k pre-fix adds an extra 16 bits but the 68k already has 16 registers and 16 more registers would be available as well as 3 op and even leaving a few more bits available.

The way 68K worked and in later models such as with 68020+ and CPU32 is it used postfixes. So a variable opcode with VLE. Opcode with extension codes as well as data.

Quote:

I believe the AC68080 uses a pre-fix like this with a 64 bit operation datatype size bit which I really don't like as 64 bit operations are common on a fully utilized 64 bit CPU greatly reducing code density, overriding the instruction size and length is bad for decoding and address register operations are already auto extended to 64 bit if following current 68k behavior. It may be better to have a separate 64 bit mode where size=byte, word, long or quad after cleaning up the encodings. This is natural and efficient as Gunnar wanted and even tried to do this but it is not compatible. A 68k32 high compatibility mode and 68k64 new mode likely uses more transistors and requires more design work so was rejected by Gunnar.

I wouldn't like that either as using a prefix for 68K encodings would be wrong.

An issue may be in the encoding of MOVE, as once example with size. The front nibble is 00SS with size. But SS is only 1 to 3. A logical progression to use 0 as quad. But ORI also uses 0000. However, MOVEP also uses 0000. The coding differs later in the opcode.

Now if the basic opcodes can fit a 64 bit op into 16 bits that can be built on. But, there are also 64 bit extensions to complicate it, such as DIVU/DIVS where the 64 bit wide data is split into register pairs. These would all need extending to wide registers. A possibility is 32 bit opcode which would impact code density. But the penalty wouldn't be as bad as RISC for wide data since all 64-bit size data words can be packed with a 32-bit sized opcode.

@cdimauro

Quote:

68k ha 32-bit opcodes as well...

With VLE it would yes. AFAIK the encoding is base 16 bit, that is 16 bit based so all codes are multiples of 16 bits, plus any data.

Quote:

8 vector registers is too little.

That's too bad as the core design has 8 each for address, data or floats. Though, given address and data combined would make 16 GPRs, perhaps encoding could offer 16 vectors. It's likely an SIMD extension would logically extend opcodes.

Quote:

There were some bits that were used for the SIMD (not Vector) unit. That's in F-line, of course.

F-line, with it's friend A-line, popular for extensions. And being F for Floating point. Perhaps it started with F-it, we need more space.

Quote:

AFAIR prefixes were not used for the SIMD unit, but only for extending the regular 68k instructions.

They wouldn't be regular after.

Quote:

Who defines the standard(s)? Do you know that prefixes are being proposed for the PowerPC ISA?

Whoever designed the 68K encoding scheme. It would use postfixes though really it's not exactly fixing it. It's more like parameters or operameters. But also, prefix suits x86/x64 because it's little endian, so prefixing a byte is natural. 68K is big endian, which really only affects byte ordering, but VLE is opcode first followed by any operand extension.

Quote:

agree... if there are some other solutions. And there are other solutions, of course: see below. BTW, you don't necessarily need to introduce a new execution mode for enabling new features. On my ISA I've opted for bigger opcodes, to completely avoid using prefixes.

As would be natural for any CISC design. But of course, with hindsight, it gives you an opportunity to redesign. If only the industry wasn't tied to existing designs, which seems ironic, because computer technology is always changing and previous methods become obsolete.

@matthey

Quote:

You mean its difficult to beat the RISC-V promotion and propaganda? Other than SuperH having a small advantage in code density, RV32IMC has better performance metrics despite being weak.

When compared to SuperH, RISC V has large corporate inertia and is mostly used for single-purpose embedded devices.

My GTX/RTX GPUs (GTX 1660S, RTX 3080 Ti, RTX 4080, and RTX 4090) have NVIDIA's custom RISC V. I sold my RTX 2080 and 2080 Ti.

Beyond 32-bit SH-2, SuperH is still a close source.

The SH-4 was used for walled garden Sega's Dreamcast and NAOMI game systems.

SuperH is useless for Amiga Retro.

Support for SH-5 was dropped from GCC and Linux.


Quote:

There is no ground breaking jaw dropping advancements in computers anymore. There is only more performance or a cheaper price for the existing technology. Features vary enough to allow for favorite computer environments while compatibility and software availability plays a key role in adoption.

For graphics, it's hardware-accelerated raytracing and AI denoiser, but hardware-accelerated raytracing doesn't solve artwork quality, story, and gameplay design.

Pixel-level geometry detail and subpixel culling can be done with mesh shaders, but this has artwork quality factors.

Both AMD and NVIDIA's recent GPUs have large on-board caches since the usual mainstream GDDR6 from Micron, Samsung, and Hynix have slower technology evolution.

HBM path is not mainstream, hence it didn't replace GDDR6 and GDDR6X.

Apple reuses LPDDR5 in a very wide topology for high memory bandwidth.

Last edited by Hammer on 28-Nov-2023 at 03:25 AM.
Last edited by Hammer on 28-Nov-2023 at 03:22 AM.
Last edited by Hammer on 28-Nov-2023 at 03:18 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hypex

Quote:

Some are so old like my XE that they are retro now. My X1000 is now over ten years old and for OS4 at least can still power it. And on the XE back then. It can play WB games. And OS friendly games to an extent. And I did enjoy seeing what would work. Sure you could do that with UAE. But there was a novelty in the early days of a native PPC AmigaOS running completely on RTG and seeing what Amiga gamed worked.

As an example, AmigaOS 4.1 on classic Amiga hardware with Phase 5 PPC couldn't fully run WB-friendly 68K Deluxe Music 2.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@matthey

Quote:

The x86-64 ISA uses a pre-fix to access the upper 8 of 16 GP registers resulting in a decline of code density.

The main purpose of x86-64 is the ability to access larger memory storage without PAE36's memory segmentation. If there is a low memory storage requirement, then stay with IA-32.

x86-64's Long Mode has a larger memory address range and register expansion. Legacy IA-32 is maintained as is.


When the 32-bit x86 extension came out, there were a lot of empty spaces available in the opcode space, therefore Intel chose a free byte that hadn’t been used in 16-bit mode to indicate 32-bit registers. Hence in 16-bit mode, if the CPU sees those bytes it knows that they’re 32-bit instructions and never mistreats them as 16-bit ones.

But decades later, thousands more instructions have been added and the opcode space has been filled completely. To introduce 64-bit extension some new way to encode the 64-bit instructions have to be chosen. AMD decided that they’ll remove rarely used instructions or legacy instructions that are not used at all to free up some space. Moreover, they increased the number of registers from 8 to 16, which needs some more bits to encode.

Among the removed instructions, DEC and INC are not as useful as before in modern architecture. They’re all in 0x4X format, so they are used as REX prefixes for extra bits of the register encoding and selecting between 32 or 64-bit registers.

Later to double the number of registers to 32 in AVX-512 and add some features like 3-operand instructions another encoding has to be invented that uses the VEX prefix.

The x86-64 instruction set reuses the opcodes for single-byte INC and DEC in x86 as REX prefix, therefore it’s impossible to have 64-bit instructions in 32-bit mode and it’s also impossible to have single-byte INC/DEC in x86-64.

Last edited by Hammer on 28-Nov-2023 at 03:25 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

Quote:

As an example, AmigaOS 4.1 on classic Amiga hardware with Phase 5 PPC couldn't fully run WB-friendly 68K Deluxe Music 2.

I tried DPaint back in the day but don't think I tried DMusic. I had it on a demo disk and it was one of the early OS2 programs using gadtools. I recall it included a gadtools13.library which was back ported to OS1.3 for compatibility.

Should try it out. It really depends what it's doing. I would expect DMusic would use audio.device. But don't know what else it could be poking in. For example, in the late 80's accessing Screen->BitMap was fine, but the decade after they recommended against directly accessing it since it was fixed. However, I found recently the the AHI audio.device is broken. The lock command doesn't work correctly. In fact it doesn't work at all and just returns. So that could produce faulty behaviour. The Wiki does not mention it is broken. Given it's a standard audio device command I don't consider it relevant that it isn't supported. What is relevant is that it violates the API and is therefore broken and buggy regardless. Just my negative 2 cents.

@Hammer

Quote:

As an example, AmigaOS 4.1 on classic Amiga hardware with Phase 5 PPC couldn't fully run WB-friendly 68K Deluxe Music 2.

That’s strange it does start on AmigaOS4.1 with NallePuh, a real Amiga should be more compatible than computer running with chipset software emulator. However, there is crash that’s cause by some kind of memory corruption issue. But sadly, we do not have the source code and can’t investigate what actually happens. Without a huge amount of time wasted on decompiling and reverse engineering, that’s is not going to happen. Run it in EUAE if you must run it.

We know there compatibility issues between AmigaOS4.1 and Kickstart 1.2. that also true for Kickstart 3.1/3.0 as well, also not 100% compatible with Kickstart 1.2, this way games are packed in WHDLoad, to run games with the kickstart they were designed for.

Back in the day I remember having Relokick 1.3 on a floppy disk.

Last edited by NutsAboutAmiga on 28-Nov-2023 at 04:53 PM.
Last edited by NutsAboutAmiga on 28-Nov-2023 at 04:52 PM.

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

@Hypex

Quote:

in the late 80's accessing Screen->BitMap was fine, but the decade after they recommended against directly accessing it

Not sure that apply to 68K software using fake planar screens.

Quote:

I found recently the the AHI audio.device is broken. The lock command doesn't work correctly. In fact it doesn't work at all and just returns.

that can explain some of the problems we are seeing.

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

@NutsAboutAmiga

Quote:

Not sure that apply to 68K software using fake planar screens.

Well, that would worse, since those modes were the wrong size. At the time it was just 68K and real planar. But it was also considering RTG as well since it was for expansion, the problem being the BitMap was static embedded, over a BitMap pointer which the RastPort had.

Quote:

that can explain some of the problems we are seeing.

Yes, I only discovered it last year IIRC. When I was experimenting with audio.device and found inconsistent behaviour. It was driving me nuts and I thought I had coded something wrong but just couldn't see it.

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Hammer Quote: As an example, AmigaOS 4.1 on classic Amiga hardware with Phase 5 PPC couldn't fully run WB-friendly 68K Deluxe Music 2. That’s strange it does start on AmigaOS4.1 with NallePuh, a real Amiga should be more compatible than computer running with chipset software emulator. However, there is crash that’s cause by some kind of memory corruption issue. But sadly, we do not have the source code and can’t investigate what actually happens. Without a huge amount of time wasted on decompiling and reverse engineering, that’s is not going to happen. Run it in EUAE if you must run it. We know there compatibility issues between AmigaOS4.1 and Kickstart 1.2. that also true for Kickstart 3.1/3.0 as well, also not 100% compatible with Kickstart 1.2, this way games are packed in WHDLoad, to run games with the kickstart they were designed for. Back in the day I remember having Relokick 1.3 on a floppy disk.

FYI, DMusic2 works fine on Emu68. With RTG, DMusic2's desktop notation functions are still useful.

I did have Relokick 1.3 i.e. CU Amiga Magazine Cover Disk 52's Relokick 1.3.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)