On Fri, 10 Sep 1999, Hans Franke wrote:
> > But does anyone have a good way to differentiate between 386SX and 386DX?
> Well, check at startup the DX register - if DH is 3 it is a DX,
> if 23 it's a SX (DL is the stepping).
And then the POST (Power On Self Test) IMMEDIATELY wipes it. It's easy to
bypass some parts of the POST, but how do you suggest checking the value
in that register before the computer has booted enough to even have video?
Replacing the ROMs in the computer doesn't seem like a suitable way for a
program to identify the CPU.
> > Possibilities that come to mind include brute force speed comparison?
> > Compare speed of moving data that is word v doubleword aligned?
> > SX has 24 bit address bus, DX has 32 bits. Any easy way to test?
>
> No idea about if the moving thing is a possible test, only the
> difference in the results is quite low - you have to compare
> speed differences between instruction timings of known instruction
> sequences.
REP MOVSD can be used to move up to 64K in real mod, thereby providing
enough occurences to do it. The difference in time between an aligned v
misaligned move (1 v 2 32 bit moves) should be more of a difference than
any other differenvces in the instruction set.
> The biggest Backdraft on the early SX was, if I remember
> correctly, that the BIU did always do 32 bit transfers, no matter
> if the requestes data was 8, 16 or 32 Bit and a worst case miss
> alignd 16 bit access (i.e. on address ...11) would result in two
> 32 Bit accesses which eventualy became 4 16 Bit data transfers.
> But as I said, this applied AFAIR only to early SXes - and of course
> not to all second source SX. So the only test I can imagine right
> now is the weak test thru using the Memory space - Switch the CPU
> to Flat addressing, and check for example if the BIOS ROM is
> mirrored every 16 MB (or if it is only mirrored every 64 MB,
> which gives you a CX CPU). Just if the board designer did only
> include 24 (or 26) address lines, your test will still fails,
> even on a DX :(.
So, a bad board design of a DX would render the "mirroring" test unusable?
> I cant think of another 'legal' way other than
> pushing Reset and checking DH (and later on checking the Type
> instruction of the CX core)
But, when I press Reset, unless I change the ROMs, I can not regain access
until te POST has thoroughly wiped all traces of that startup code.
> Anyways - maybe check also a nice Dr.Dobbs article about AP485
> and some blockheads at Intel (I may add that in the 286 Manual
> they described safer tests :)
Thanks!
Many years ago, an author in MicroCornucopia mentioned that he used some
"intel approved tests". Unfortunately, he immediately left the country,
and was unreachable in Turkey. I called intel, and wandered the voice
maze for a few days. I finally reached somebody who UNDERSTOOD what I was
looking for! (after literally dozens of responses on the order of "ask the
manufacturer of the computer what's in it") But, then he said that if I
ever found those tests, would I please send him a copy.
--
Fred Cisin cisin_at_xenosoft.com
XenoSoft http://www.xenosoft.com
2210 Sixth St. (510) 644-9366
Berkeley, CA 94710-2219
Received on Fri Sep 10 1999 - 14:54:20 BST