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.
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.
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).
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.
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.