Since last week’s post, more information about the Chips and Technologies C&T has come to light.
It now appears that at least some 38605DX processors were made. Whether there is any surviving working system is still an open question (since a special motherboard would be required as well). On the other hand, there is still is no evidence that any of the SX variants existed beyond samples.
There is more on the sort-of-SMM in the Super386, called SuperState V. The U.S. Patent 5,455,909 provides an overview of the feature. The caveat is that the patent’s existence does not necessarily imply a specific implementation. The F8680 PC/CHIP is better documented but its SuperState R (R for Real, V for Virtual?) is not necessarily the same as the Super386’s SuperState V.
Last but not least, thanks to a reader suggestion and a kind stranger, an unfinished manuscript of the Super386 Programmer’s Reference Manual has been located. While it is very incomplete, it sheds some light on the one mysterious undocumented Super386 instruction.
SuperState V
The SuperState V is likely similar to SuperState R. It shares many similarities with System Management Mode (SMM) of Intel and other processors. It is a “hidden” CPU mode which executes below and without the knowledge of an OS.
The SuperState V was probably more powerful than SMM. It could intercept I/O port accesses, but it could also be triggered by software and hardware interrupts and by memory accesses. That would make it possible to emulate various devices (AT keyboard controller and IDE are given as examples in the F8680 documentation), but also use SuperState V for debugging and perhaps even as a hypervisor of sorts.
On the 38605DX, there is a hardware pin to trigger an entry into SuperState V. The pin carries the ANMI signal, or Alternate NMI. The 38605DX also has an AADS or Alternate Address Space pin to indicate to hardware that a bus cycle was directed to “SuperSpace”, special memory reserved for SuperState V use.
SuperState V uses a special descriptor with a format similar to that of a regular GDT/LDT descriptor. This points at the beginning of the SuperState memory region which then starts with a special data structure. This data structure contains a SuperState IDT, stack, and areas which control interrupt intercepts. The exact format of these structures is unknown.
There is no information on special SuperSpace V instructions, but there almost certainly are some.
What is most vexing is that it’s very unclear whether SuperState V only exists in the 38605DX or on all Super386 processors. It’s clear that with additional pins, SuperState V would be more useful, but it’s also clear that it could be quite useful even without them.
The available documentation (which is in a rough draft form) is somewhat self-contradictory and in some cases indicates that SuperState V is specific to 38605DX, yet elsewhere suggests that any Super386 should support it.
SCALL
The undocumented instruction is SCALL (SuperState CALL) and its encoding is 0F 18 r/m. It takes a 32-bit operand (register or memory) which contains the SuperState function on entry and may be written with a result code when SCALL completes. CF is set on failure, cleared on success.
SCALL is used for identifying the CPU, setting up SuperState V, cache control, and invoking SuperState V routines.
The bad news is that none of the actual SuperState related functions seems to be accepted on a 38600DX. That could be because the 38600DX does not support SuperState V, or it could be because SuperState V needs to be set up correctly but not enough information is available. The good news is that the CPU identification does work.
It should thus be a reliable way of identifying a C&T Super386. A 386-class CPU which does not cause an #UD fault on the SCALL instruction must be a Super386. The CPU identification function is safe to call and does not have any ill side effects (as most of the other functions do).
Identifying a C&T Super386
Armed with this information, it is trivial to identify a Super386 processor. A sample program can be found here. It is intended to be compiled as a 16-bit DOS program with Watcom C. It should be easy to modify it to support other compilers and environments. Adapting the program to not crash on non-C&T processors is left as an exercise for the reader.
The output of this program on the OS/2 Museum’s 38600DX specimen is as follows:
C&T Super386: 38600DX microcode stepping 1, processor stepping 0
It is a mystery why identification based on the SCALL instruction isn’t part of any known processor identification package (or is it?). Perhaps that simply reflects how widespread the Super386s were (not).
Cache
The cache on the 38605DX is unusual. It is 512 bytes of instruction-only cache. Restricting the cache to code only probably saved C&T many headaches with implementing coherency with regard to bus masters/DMA and the horrors of the A20 gate.
The processor did however handle self-modifying (or dynamically generated) code. A write to memory which was held in the cache or in the pipeline automatically invalidated the cache line and/or flushed the pipeline and prefetch queue.
In this respect, the Super386 behaves like a Pentium Pro and the size of its prefetch queue cannot be easily determined programmatically. The “invisible” prefetch queue is common to both the 38605DX and the 38600DX.
Open Questions
Does the 38600DX support SuperState V? Was the 38605DX produced in any kind of volume? Was either of the SX variants actually available on the market? Who knows, but maybe more information will surface.
I have been curious about the C&T chips ever since hearing about them so thanks for giving them an evaluation.
Don’t know about volume but ComputerLand sold 38605DX systems under the Trion house label. http://www.fundinguniverse.com/company-histories/chips-and-technologies-inc-history/ ComputerLand sold a 386SX Trion system at the same time but I don’t know if C&T made the CPU used in it.
Latest version of IDA (6.9) and Hiew aren’t recognizing this instruction encoding. So much about popularity of this CPU.
I have never seen any tool recognizing the instruction and I couldn’t find any mention if it in any programming document. Yep, the Super386 was clearly tremendously popular 🙂
The Trion thing is odd. Compare with this — no mention of C&T CPUs, just “C&T-designed”.
Richard, a tangentially related question: Were UMC CPUs (U5S) available/widespread in the U.S. at all? They were pretty common in Europe circa 1994-1995 (esp. Eastern Europe) but of course weren’t supposed to be sold in the U.S. at all. I’m now doing a bit of research into the U5S; it’s a rather interesting piece of hardware and vastly easier to get than a C&T 386.
I wrote another simple tool for safely testing scall using FASM (Yes, I know using TASM or MASM would be more oldschool and therefore more appropriate). The only thing is… I can’t test it on actual hardware 😉 Let me know if anyone is interested.
I’m interested 🙂 I’m not worried about the tools, there’s no reason not to use something more modern. I used Open Watcom 1.9 on the actual Super386 system for development and testing. Not terribly fast at 25 MHz, but at least with 20MB RAM and a disk cache it was bearable.
Ok, just let me know how I can contact you and I’ll send you both asm and exe file. I don’t want to publish it before testing on actual hardware. On the other hand there is no magic involved: I’ve took a peek at your example code to learn scall encoding. The rest is simple test for 286 and 386 CPU plus own int 6 handler for catching exception when scall isn’t supported (99,999% cases).
TMi0SDGL has a general C&T 38600 detection routine based on the absence of the AMD/Intel POPAD bug, so perhaps no-one saw the need for another way of detecting the chips…
You can’t positively identify any chip by failing to find specific bugs, you can only say that it’s not one of the buggy chips. The code assumes that anything that looks like a 386 and doesn’t have the POPAD bug must be a C&T 386. That is probably not a bad assumption in practice, but can anyone guarantee that Intel/AMD never made a 386 with the POPAD bug fixed, or that there isn’t some other chip (or software emulation) which looks like a 386 but isn’t either an Intel/AMD or a C&T 386?
Anyway, the TMi0SDGL code can’t distinguish between a 38600 and a 38605, it can’t distinguish between the SX and DX variants, and can’t print the processor and microcode revisions. So I’d say there was a need, but there were no means. Which isn’t to say that checking for the POPAD bug presence/absence isn’t clever.
Just for reference I’ve found this tiny piece of info regarding SuperState in great Ralf Brow Int List: http://www.ctyme.com/intr/rb-2448.htm
I don’t know if all Intel and AMD 386 CPUs have the POPAD bug, but in addition to C&T there are also 386 CPUs and microcontrollers made by DMP, GiK, Maxwell and SEI. If they are the same (or more) scarce than the C&T, how to know which ones have the POPAD bug and which ones doesn’t have it?
I would say that the only option is to test code on particular CPU as even if you find documentation, and assuming that documentation is actually addressing this particular issue, I would bet on it. My code failed so many times due to bugs in documentation that I don’t believe it any longer unless I can test it and confirm it.
A bit late: UMC CPUs were scarce. I think I saw a few complaints from US users who discovered problems with UMC CPUs so it would seem a few complete systems with UMC CPUs snuck in. I don’t have information whether those systems were purchased out of the country or an entire shipment of systems with UMC CPUs was delivered.
I never saw one. I believe one of the lesser cloners did a press release indicating plans to use UMC CPUs but I can’t locate a reference in any of the online trade magazine archives.
That is… so not helpful 🙂 I do wonder where the information came from.
Thanks. It’s clear that UMC didn’t want the CPUs to be sold in the US, but they probably couldn’t entirely prevent it either. So it sounds like they were largely successful, although it ultimately didn’t help them much.
I’m totally unfamiliar with those microcontrollers. Do you know anything about the 386 cores they use? Something licensed or a completely custom development?
Interestingly, C&T was to my knowledge the only 386 core other than Intel’s on the market. All the other independently developed x86 cores were 486 and later (Cyrix, NexGen, UMC, AMD K5, WinChip, etc.), especially in terms of architecture if not the instruction set.
Was bored so looked at the Intel 386EX manual. The 386EX lacks a (listed) POPAD instruction and the POPA instruction is followed by extra 1-4 clocks so the POPAD bug seems unlikely to be a useful identifier for it.
The ALi M6117C and D documentation I have found has nothing on differences between the embedded 386SX core and an actual 386SX as to how instructions are handled.
I have at least one document for each one. Some could be datasheets and others product briefings, but I think have something for any one. If you can’t find them in one of my document batches, send me a “PM”.
Okay, GiK seems to use an Intel 386EX. The SEI 80386DXRP looks like an Intel 386DX in a radiation hardening shield. I haven’t found anything on DMP and Maxwell so far.
DM&P licensed the ALi M6117 design which used Acer Labs M1386SX as the base. These have at least one difference from other 386SXs. They support 32MB of RAM.
See an OpenBSD thread from Nov. 2003 titled “Status of FPU emulation?”.
Thanks to Michal help here is my code for detecting C&T Super386 CPU:
https://corexor.wordpress.com/2015/12/05/calling-ct-scall-safely/
Thank you for this article. I’m in the process of rewriting and updating my CPUID code, and the SCALL instruction will make the C&T detection code smaller, faster and more accurate.
Nice! I have used your CPU detection code as a reference in the past, so it’s only fair 🙂
I don’t know the Watcom C calling convention, so please tell me if my understanding of the return parameters from SCALL is correct. What I think I see is:
[EAX:23-16] = microcode stepping
[EAX:15-08] = CPU stepping
[EAX:07-00] = CPU type
It would save a couple of bytes in my nasm code (and a microsecond at run time) if bits 23-16 contain CPU type. Every byte counts when I code in nasm 🙂
It’s pretty straightforward, ‘value [dx ax]’ means a 32-bit value is returned with high word in DX and low word in AX. So yes, what you guessed is correct. The high 8 bits are reserved.
Note that the SCALL encoding is 0F 18 r/m, with the operand being used as both input and output.
Thanks
I wonder if Intel bought C&T less for the video portfolio, and more for the patents on stuff like SuperState. SMM has a lot of prior art on that, after all…
I would think that 1997, when Intel acquired C&T, was sort of late for SMM patents. Then again I’m sure C&T did have a patent portfolio that Intel did not mind owning.
As far as anyone can tell, Intel was really interested in graphics. C&T was a leader in flat panel support which was an up and coming technology for desktops in the late 1990s. I would imagine that some of the C&T technology went into the 810/815 chipset graphics (1999) which did support digital video output. Or maybe the C&T tech ended up in the Intel 830M/830MG chipsets (2001), which as far as I know were Intel’s first mobile chipsets with integrated graphics.