Tech Spot posted a Cyrix retrospective recently...
https://www.techspot.com/article/2120-cyrix/

Not sure it adds any info to the pool of knowledge, some nice pics.

What up Cyrix appreciators,

Is there any good threads on Cyrix DX2, socket 1,2,3 Cyrix 486 register tuning, like how to force writeback maybe, any utils to poke at SMM modes, etc? Also seem unable to locate proper Cyrix 486-DX2 databook or datasheet. Any queries about registers etc, spam me out with 5x86 and 6x86 stuff and setting utils etc with 486 gets me 486slc dlc stuff.

Another thought, ppl think they've used a Cyrix FPU, in seperate chip form, or integrated, but has anyone ever really USED a Cyrix FPU ???

What do I mean? Well when Cyrix brought out a memory mapped and i/o mapped capable version of the x87, which original 83D87 didn't support, in the next iteration of the 83D87, they apparently rolled it in... and some indication they carried it through to all of their x87 class hardware thereafter...

Supposedly there's 33% performance boost just hanging there for using these modes, and they move the FPU out of lock step with the integer unit, no waiting on either end... isn't that part of what makes Quake slow? (Not saying it would close the whole gap since it's programmed very tightly to intel interleaving, but it might close the gap halfway, just by avoiding the forced way it is made to operate otherwise.)

Dear Santa for Christmas I want a pony and a TSR that translates all FPU calls to Cyrix memory mapped mode.

BitWrangler wrote on 2023-03-25, 03:32:

Supposedly there's 33% performance boost just hanging there for using these modes, and they move the FPU out of lock step with the integer unit, no waiting on either end... isn't that part of what makes Quake slow? (Not saying it would close the whole gap since it's programmed very tightly to intel interleaving, but it might close the gap halfway, just by avoiding the forced way it is made to operate otherwise.)

proper interleaving would only speed up triangle perspective correction (~30 integer cycles between FPU divides), but there are tons of places relying on Intel FPU pipelining - zero cycle fxchg and starting new fpu instructions every cycle Re: 2D Acceleration - first chipsets

BitWrangler wrote on 2023-03-25, 03:32:

Cyrix memory mapped mode.

but is it really present in later models? and how is it constructed? famed weitek is memory mapped but not the way I expected, you need to touch memory addresses to trigger individual FPU instructions https://www.geekdot.com/weitek-abacus-fpu/

BitWrangler wrote on 2023-03-25, 03:32:

What do I mean? Well when Cyrix brought out a memory mapped and i/o mapped capable version of the x87, which original 83D87 didn't support, in the next iteration of the 83D87, they apparently rolled it in... and some indication they carried it through to all of their x87 class hardware thereafter...

Supposedly there's 33% performance boost just hanging there for using these modes, and they move the FPU out of lock step with the integer unit, no waiting on either end... isn't that part of what makes Quake slow? (Not saying it would close the whole gap since it's programmed very tightly to intel interleaving, but it might close the gap halfway, just by avoiding the forced way it is made to operate otherwise.)

Dear Santa for Christmas I want a pony and a TSR that translates all FPU calls to Cyrix memory mapped mode.

I don't think you can get that TSR. You would need a hardware modification first to get the Cyrix FPU running on memory cycles. The Cyrix processor implements the 387 protocol, which includes an interface consisting of 2 ports of 32 bits each on the "local bus". These ports are the "command port" and the "data port". The 387 interface also includes some control lines to indicate unmasked exceptions (ERROR#), readyness of the processor (BUSY#) and a data transfer request line (PEREQ) which are special-purpose FPU pins and not available to MMIO devices, and thus arguably not part of the 80386 local bus. The Cyrix processor is designed in a way that it can be connected to a 386-type local bus without ERROR#, BUSY# and PEREQ in use.

This causes some loss of features, though:

• If you issue a floating point instruction while the coprocessor is unable to accept a new instruction, the standard 387 protocol allows the processor to detect that state using the BUSY# pin, and wait for readyness while the local bus is idle (and available for DMA operations) and the processor is ready to handle interrupts. Omitting the BUSY# pin, as it is done in the "memory mapped" mode causes the 387 to detect 387 bus cycles all the time, but if the 83D87 can't handle the cycle, it will stall the local bus until it can handle the cycle. In that case, neither DMA transfers nor interrupt handling is possible.
• Furthermore, the ERROR# signal would allow "properly designed" system for deterministic FPU exception reporting: The idea is that when the 286 (or any later processor) is going to issue an instruction (or executes WAIT), it will poll the ERROR# line and enter the trap handler with the return address pointing to the subsequent FPU instruction. In the IBM AT (and later) series of computers, this "proper design" is not implemented anyway (as it would collide with INT10 used for video function in the IBM BIOS), and ERROR# is managed using IRQ13 which can happen at any time, not just at an FPU instruction, so this loss is likely negligible in AT-compatible computers.
• Not using the 387 protocol renders the 386 support that is available in that protocol unavailable. This is mostly the tracking of the last executed instruction address and (if applicable) the address of the data operand used in this instruction. If a coprocessor is accessed using the 387 protocol, this data is injected by the 386 into the data stream returned from the 387 during the execution of the FSTENV instruction.
• Lastly, the PEREQ signal is used to signal readyness for data transfer in instructions that need to perform work before transferring data to the host processor. The 387 is supposed to perform this work while the 386 is still execution of further instructions. At some point, the 387 can request data transfer, which will happen completely transparent. On the other hand, in the memory mapped interface, data transfer can't be performed in the background, as the 387 is not a busmaster device. The host processor needs to perform a read of the data register at a moment the host processor sees fit. If it is too early, the 83D87 will stall the front side bus until the data is available. If it is too late, the 83D87 will idle until that read occurs.

On the other hand, disregarding the 387 protocol has the advantage that it allows more pipelining. For example the 83D87 can buffer one command write. You can submit the subsequent command to the 83D87 while it is still working on the previous command. This complicates precise exception tracking even more, because an excpetion from the previous command might not yet have occurred when the current command is transferred into the buffer. If code relies on handling stuff in an exception handler, trying to find out what exactly failed and how to fix it up will become very difficult. In normal PC/AT operation with standard consumer software/games, though, I don't know of any example that does require precise exception tracking. Furthermore, transferring data through programmed I/O instead of using the PEREQ DMA channel allows for less bus arbitration delays if the data transfer instruction is already pending (i.e. stalling the bus) when the 83D87 gets ready to transfer the data. This improves the performance of the 83D87 instruction execution (and this is one of the reasons the "basic execution time" in the Cyrix Data Sheet beats the "Intel System Time"), OTOH, it does not generally improve system performance. Furthermore, transferring data through a memory mapped interface makes the 80386 execution unit deal with operand transfer, whereas the 387 protocol allows the execution unit to execute subsequent instruction with the bus interface unit handling the data transfer.

BitWrangler wrote on 2023-03-25, 03:32:

they move the FPU out of lock step with the integer unit, no waiting on either end...

Now, that's a common misconception. While the bus interface of the 8087 ran in very tight lockstep with the bus interface 8086, and still runs in lock step with the 80387, the execution unit of the 8087 never was coupled to the execution unit of the 8086. Parallel execution of Integer and Floating Point instruction had always been possible, and parallelization works better with the 387 FPU interface (due to the PEREQ signal enabling background DMA-like transfers) than with the MMIO interface. The MMIO interface still requires the CPU to actively send FPU instructions to the FPU, and to actively transfer data between the FPU and the CPU, so I don't see it as looser coupling compared to the 387 interface. Actually, the opposite is true: The explicit data transfer makes the coupling even more tight. A possible advantage of the tight coupling: it allows sending operands (e.g. 32 bit integers) from processor registers directly to the FPU without going through memory. This is impossible using the 387 protocol. (but see footnote 1)

BitWrangler wrote on 2023-03-25, 03:32:

and some indication they carried it through to all of their x87 class hardware thereafter...

This makes little sense, though. I would consider such indications mostly fake rumors, but see below. There is no standardized memory mapped interface to the 83D87. In contrast to the Weitek processors, the 387 does not contain a sensible decoder to detect MMIO cycles destinated to it (that's why the Weitek processors need an extra row of pins). Instead, the 387 protocol uses a special signalling on the local bus that only requires minimal decoding the in 387: Intel (artificially) limited the number of I/O ports available on the 386 bus protocol to 65536. This allows I/O devices to be simpler, because they do not need to care about more than 16 address bits. This means every proper I/O cycle of a 386 processor has A16 to A31 at a low level. For 387 cycles, an I/O cycle with A31 set high is used. Furthermore, A2 is connected to CMD# of the processor to select the command or data register, so it responds to all virtual 32-bit I/O ports between 8000000 (command)/80000004 (data) up to FFFFFFF8 (command)/FFFFFFFC (data), i.e. 2GB if virtual I/O space. To operate like this, the 387 only needs to get the "I/O cycle indication" and A31 to decide whether the cycle is a 387 cycle. The pins on the 387 that are to be connected to M/IO# and A31 are called in the neutral way NPS1# (needs to be low for FPU access) and NPS2 (needs to be high for FPU access). "NPS" is an abbreviation for "numeric processor select". To access the 83D87 in MMIO mode, external logic, which is not specified by Cyrix needs to detect MMIO cycles targetting the system-specific MMIO address of the 83D87 command/data ports and provide the NPS1#/NPS2 signals. You don't have that logic on AT-compatible mainboards. Also, as the address is system-specific, Cyrix can not have carried over the MMIO way of accessing the 83D87 on some exoctic 386 systems (or even non-386 computers) to later Cyrix x86 processors.

On the other hand, with the FPU being integrated on the CPU (486DX onwards), there is no need to implement the Intel 387 communication protocol. Especially, this means that you can build a 486-class FPU/NPU combnination that ignores the synchronization required for precise exception reporting, and allows the pipelining the Intel 386 purposefully chose to not do (to enable precise exception reporting). Most likely not coincidentally, the Cyrix 5x86 processor does have an "FP_FAST" control bit, and explanation about that bit relate it to exception handling. My intuition is that enabling FP_FAST on a Cyrix 5x86 gives you the best of both worlds: 387-compatible programming interface, 387-compatible background data transfer, but MMIO-comparable pipelining by explicitly relinquishing the requirement for precise exception reporting. You might call this "they carried over the MMIO interface", but I consider this quite a stretch.

1: There actually is one instruction that allows direct data transfer between the FPU and the CPU without going through memory. This instruction has been introduced with the 286/287 chip combination. It is FSTSW AX. This instruction captures the likely most prominent case of FPU-provided data being required an a CPU register, but is obviously less powerful than being able to transfer any FPU data into/from CPU register.

Hello all,

Today I played a bit with my SS7 system to test some Winchip/2, K6 and a Cyrix MII 400 I had around...I had a MII 433 which I unfortunately sold 15 years ago! This is one I would like to get back someday 😀

This MII-400 chip runs at 3x95, but I configured it at 3x100 just like the MII-433 which was the top of the line as far as I remember. To my surprise it's not as horrible as I expected under 3DMark 2001 SE:

For comparison, this is a K6-III+ clocked at 300 and 500 MHz

My system has a GeForce 5700 LE which is very compatible and inexpensive, and is what I have on hand.

When I was young I had a Pentium 200 and my friend a Cyrix 6x86 PR166 and I remember that I took my Pentium to his house when we were playing on the PC together, made a huge difference in games back then.

So where I was coming from was that the memory mapped i/o mode debuted on the EM87, but if we look in databook for later Fasmath 83D87 https://www.ardent-tool.com/CPU/docs/Cyrix/387/83d87.pdf (I was casually flipping through links related to something else when google threw another version at me, but that's the less clean copy I can find it in now) section 4.13 is where it gets interesting and further explanation in following sections.

It does seem maybe that with the discrete 83D87 that some pin functions would have to be swapped around to address it in that mode versus i387, but I wonder if it was built into any motherboards for flexibility. If not, then yah, bodge wires only.

In case it gives us any more clues, there's a patent https://patents.google.com/patent/US5420989

Anyway, it seemed there would be considerably more flexibility to implement any interfaces they wanted to inside a 486DX and having blazed that trail and got the 387 core for it, why wouldn't they bake it into the next CPU. Unfortunately most of the hints for it being in there are rather off the cuff bits in period news articles like "includes a slightly enhanced version of Fasmath" and blurb like that about DX CPU release. But Fasmath at that time had already rolled in the EM87 stuff.

BitWrangler wrote on 2023-03-25, 22:01:

So where I was coming from was that the memory mapped i/o mode debuted on the EM87

Do you have a reference for a memory-mapped I/O mode in EM87? The only "EM87" I could find connected to coprocessors is a public-domain TSR described from example in https://www.vogonswiki.com/images/2/21/Coproc.txt . It uses INT7 as emulation trigger (i.e. on every coprocessor instruction, the processor interrupts the current program flow, breaks into the emulator and finally returns to the program flow). Nevertheless, the INT7 method is a foolproof method to catch all floating point instructions in any kind of program, even with self-modifying code and similar nastiness, so using INT7 is a wise choice for compatibility.

The use case for EM87 is to emulate an 8087 in 286-based systems that don't have an FPU at all, to enable programs that require an FPU. The INT7 method used by EM87 causes more overhead than the standard Microsoft/Boarland method using software interrupts 34-3B, so it is not the method of choice for programs intended to work on systems without an FPU, but more of a stop-gap measure. The overhead of INT7-based emulation is bigger than the gain you can obtain from better pipelining with the 83D87 using an MMIO-based interface. This means running a 80386 in FPU emulation mode, triggering INT7 on every coprocessor instruction, and then accessing the 83D87 using an MMIO interface is definitely going to be slower than just accessing the 83D87 through the standard FPU interface.

Even for newly compiled software, you must not ignore the CPU-side overhead to access the FPU: An x87 register-to-register instruction is two bytes. Hardcoded 32-bit MMIO base addresses take 4 bytes on their own. Furthermore, they are embedded in an instruction that carries at least an opcode byte, and finally, the two bytes of the FPU instruction also need to be stored somewhere, as those two bytes need to be transferred in the MMIO write. This means at least 5 bytes overhead. Considering that the 80386 can fetch one DWORD in 2 cycles (assuming an external cache hit), the 386DX needs at least 2.5 cycles more to fetch the instructions required to make a memory-mapped 83D87 perform a register-to-register operation than a 387-like interfaced 83D87. I basically see one primary use-case for a local-bus mapped (but I/O mapped in this case) 83D87 actually providing a significant speedup: If you don't care about parallelism, as the CPU is waiting for the FPU result anyway, you can perform a sequence of register-to-register operations using REP OUTSD to the 83D87 command port. This causes the CPU to stall until the execution is done (i.e. no parallelism), but on the other hand maximises the pipelining on the 83D87, so the FPU is faster in delivering the result.

BitWrangler wrote on 2023-03-25, 22:01:

but if we look in databook for later Fasmath 83D87 https://www.ardent-tool.com/CPU/docs/Cyrix/387/83d87.pdf (I was casually flipping through links related to something else when google threw another version at me, but that's the less clean copy I can find it in now) section 4.13 is where it gets interesting and further explanation in following sections.

Yes, that's the datasheet I read to come to the conclusions I wrote in this and the previous post. The datasheet clearly points out the bottlenecks of the Intel interface (which are mostly due to the Intels intention of precise exception reporting), and provides the memory-mapped mode as an alternative. On the other hand, the datasheet fails to point out the downsides of using a memory-mapped interface in a 386/387 combination. This is not surprising, as the bottleneck in the 386/387 interface is a perfect opportunity to point the finger at the competitor. To be fair, the datasheet also doesn't recommend to use the MMIO interface instead of the 387 interface in 386/387 systems, but emphasizes the possiblilty to add the 83D87 to non-Intel systems that do not implement the 386/387 protocol at all using the MMIO-based interface.

BitWrangler wrote on 2023-03-25, 22:01:

In case it gives us any more clues, there's a patent https://patents.google.com/patent/US5420989

Well, this patent clearly shows the direction Cyrix intended to go, which is more than just using the non-387 based interfacing approach to the 83D87. The primary point of that invention is a coprocessor that can receive MMIO instructions using the Weitek philosophy of encoding the instruction in the address lines and transferring data on the data lines in the same bus cycle. Using the address line to transfer the instruction is mentioned in every claim of that patent.

Using the address lines to tranfer the instruction is not what the 83D87 implements, though. The "memory-mapped" stuff described in the data sheet is just a simplified and more pipelined version of the 387 interface: You still need to first transfer the instruction using the command port, and then transfer an operand using the data port. Both the command code and the operand are transferred over the same data lines (looking at the 83D87 datasheet, the coprocessor does not even connect to address lines!). In short: The 83D87 includes an access method called "memory-mapped", but it is not the kind of memory-mapped interface claimed in the patent.

BitWrangler wrote on 2023-03-25, 22:01:

Anyway, it seemed there would be considerably more flexibility to implement any interfaces they wanted to inside a 486DX and having blazed that trail and got the 387 core for it, why wouldn't they bake it into the next CPU. Unfortunately most of the hints for it being in there are rather off the cuff bits in period news articles like "includes a slightly enhanced version of Fasmath" and blurb like that about DX CPU release. But Fasmath at that time had already rolled in the EM87 stuff.

As I understand the datasheet, the Fasmath never included the Weitek-like address/data interface claimed in the patent that would have increased perfomance. That's why I don't think there is any "hidden MMIO mode" present. The only question that makes sense in this situation is: Do Cyrix 486DX already have a FP_FAST configuration bit that sacrifices precise exception reporting to improve pipelining, or was the 5x86 the first processor to introduce it. If http://fd.lod.bz/rbil/opcode/other.html is complete in this regard, the 5x86 is the first Cyrix processor to have a configuration register CCR4 with that configuration bit.

Yes sorry I dropped a C referring to Cyrix EMC87 hardware not EM87 emulator.

edit: damn it's hard to find a full DX2 databook from either Cyrix, IBM, ST or TI ... however, this app note at least confirms FasMath ancestry https://www.ardent-tool.com/CPU/docs/IBM/486/40003.pdf and in the block diagram we see FPU has address bus access through the MMU, (Integer core access is mediated through it also)

BitWrangler wrote on 2023-03-26, 13:07:

Yes sorry I dropped a C referring to Cyrix EMC87 hardware not EM87 emulator.

Thanks. Now I found what you were talking about. The EMC87 is in fact a processor that fits the patent you quoted. That processor uses the Weitek pinout, enabling it to receive an instruction on address pins and an operand on data pins at the same time.

BitWrangler wrote on 2023-03-26, 13:07:

edit: damn it's hard to find a full DX2 databook from either Cyrix, IBM, ST or TI ... however, this app note at least confirms FasMath ancestry https://www.ardent-tool.com/CPU/docs/IBM/486/40003.pdf and in the block diagram we see FPU has address bus access through the MMU, (Integer core access is mediated through it also)

Cyrix called every of their x87 units "FasMath" at that time, so I wouldn't interpret too much into this statement. As I read the diagram in that app note, the FPU is only connected to the data bus and some control lines, not the address bus. This would point to the classic 83D87 design, or perhaps the revised 83D87 design also called "FasMath 387+", but not the EMC87 design. That design would have needed a connection from the FPU to the "data address bus". OTOH, if we are lucky, the 486 core can communicate the operation code to the FPU using the "control" lines, enabling data transfer at the same time. If the FPU and the CPU are in the same case, the primary bottleneck the EMC87 tried to solve does no longer exist: A classic 386/387 combination worked in a way that all floating point instructions were fetched by the 386 over the frontside bus, and then sent to the 387 over the same frontside bus again, i.e. the instruction needs to travel the FSB twice. Furthermore, all data transfer also is performed between the 387 and the 386 and afterwards between the 386 and actual memory, so data is also twice on the frontside bus. The 486 chip doesn't need the FSB to communicate with the 487, and the 487 can access the L1 cache even while the FSB is still busy flushing write requests from the write buffers. The idea of the EMC87 mode was to merge the instruction transfer cycle and the operand transfer cycle into a single FSB cycle. This is impossible using 387 instructions on a real 387, so you need special software support for the EMC87 (which is sparse). OTOH, the 486 can reach comparable performance using internal busses even with the software containing standard x87 instructions, so the EMC87 programming model did not provide enough benefit to software developers to keep maintaining EMC87 specific software.

I see, thanks very much for the explanations.

Minutemanqvs wrote on 2023-03-25, 12:53:

Hello all, […]
Show full quote

Hello all,

Today I played a bit with my SS7 system to test some Winchip/2, K6 and a Cyrix MII 400 I had around...I had a MII 433 which I unfortunately sold 15 years ago! This is one I would like to get back someday 😀

This MII-400 chip runs at 3x95, but I configured it at 3x100 just like the MII-433 which was the top of the line as far as I remember. To my surprise it's not as horrible as I expected under 3DMark 2001 SE:

For comparison, this is a K6-III+ clocked at 300 and 500 MHz

My system has a GeForce 5700 LE which is very compatible and inexpensive, and is what I have on hand.

When I was young I had a Pentium 200 and my friend a Cyrix 6x86 PR166 and I remember that I took my Pentium to his house when we were playing on the PC together, made a huge difference in games back then.

Nice, would probably not be far off a K6-2 at 3x100, potentially even beat it on some code that is favorable to it's massive L1 but no on die L2. Not many people have found Cyrix MIIs performing in the 300+ range, so maybe you can rustle some jimmies in the Cyrix performance thread Cyrix/ST/IBM Aiming for the stars!

I have two MII-400 CPU's in my collection. I still have never seen a 433 for sale.

Yah only seen them theoretically for sale with "CALL" next to them in the advert, but the twice I tried at two places it was "Don't have any at the moment, don't know when we'll get some." I did have eyes on one probably 17 years back. Doing a HDD and RAM upgrade for a friend of a friend and there there was a 433 in his board. I knew then that anything over 333 was hard to find. I tried a K6-2-450 in his board while I had it, but for his browsing and office use it didn't seem to be any snappier to be a convincing upgrade to offer him for straight swap. (Bear in mind that "street value" of any Cyrix MII at this point was prolly $5, even though some were hard to find, while a K6-2 was still worth $20ish.) So I sent him his machine back with the work done, with it still having it's 433 .. and making plans to find him a K6-3 or a whole duron 600 & board swap or something. Unfortunately, before this transpired, he moved provinces or something, out of touch. I mean it sounds super devious now, but back then it was only a crappy Cyrix chip I was curious about, with very little real or perceived future value, and dude would have been delighted I think.

You wonder about subsequent "takes" on deals like that... 2003: "Heh some dumbass swapped me my old voodoo for a practically new GF4MX, w00t!" 2023: "Some conniving bastard conned me out of my $150 nowadays voodoo card for a POS $20 GF4MX." etc

Jasin Natael wrote on 2022-09-08, 18:04:

Speedsys: CPU score of: 199.99 from Windows 98 command prompt. Hangs at read MSRs when ran from DOS

Jasin Natael (and everybody else having the same problem), here is the solution for the "Read MSRs"-problem of Speedsys under DOS:

-> attached in the 7z-file they are two files named "err_msr.xxx"
-> unzip them and copy both of them inside of your speedsys-directory
-> EVERYTIME before starting of speedsys, just execute the "err_msr.com" once -> and after that start Speedsys.

That's all.

I found this solution a while ago on the internet here: https://dosreloaded.de/forum/thread/5184-pc-c … yrix-mii-pr300/

The files are not mine, so I can not give any support about them.

Tested successful with a Cyrix MII.

gwb wrote on 2012-01-25, 01:17:

I love Cyrix processors, currently have a pr233. Discuss your collection or Cyrix system

My journey on PC computers started on Win95 with a IBM 6x86200MX CPU. I was pretty satisfied with it once combined with a 3Dfx Voodoo card (NFS2/3, Rogue Squadron…). Windows ran fast but when It comes with FPS shooters like quake II I had to switch to a K6-2. I get recently A super socket 7 motherboard I tried to use a Cyrix 233mx with bended pins. I managed to aligns the pins, system boot fast, except I can’t access to my hard drives/ide peripherals.

Have a bunch of Cyrix MII 400 and a MII 433 in my collection, did not get a chance to test it beyond POST - lack of time 🙁

But in the last 4-5 years since I got more interested in retro CPUs I have seen twice or three times a 433 for sale, of which one is the CPU I got. 😀

Comparatively I have seen more K5 PR200s for sale during same period than MII 433... and nearly same number of Cyrix 5x86 133

Same goes for MII 350 - seen so few of these - guess production was very limited.

Cannot help it, have to add what might be "the Unicorn of all CPU Unicorns" - an early Christmas present 😀

Wow!

EDIT: Can you benchmark it? Does it work?

mwdmeyer wrote on 2023-12-01, 01:09:

Wow!

EDIT: Can you benchmark it? Does it work?

Mech Samples are a hit and miss if they work or not, some are just thrown together to get and idea of the finished product and other are further along for testing voltages etc, I hope this one will be far enough along to actually post.

Very nice catch, I hope it does something for you.

I wouldn't have considered it quite as unicorny as the DX2 version of the UMC U5 though, but very damn rare even so.