1 Sep
1999
1 Sep
'99
2:45 p.m.
whilst browsing thousands of LPs at a thrift store I came across an
interesting computer related item. Its made by radio shack and it's called a
microcomputer trainer. basically ,its a rudimentary computer with one cpu
chip, a hex keypad, some LEDs and one hex LED display and speaker. the
included book shows how to load and run simple programs as well as how to do
math functions in binary and hex. It's complete and works and is probably
from around 1982 time period. Also found an apple
monitor /// so my
profile-equipped apple /// is now complete and correct.
d
1 Sep
1 Sep
3:26 p.m.
New subject: Newbie member saying something!!!
hello everyone.
Hey all, just this weekend I went to a flea market and bought my 2nd "classic'
computer. It is the original Compaq, to my knowledge. I paid $10 for it. I would
like to find out more info about this thing, all I know its a 8088 machine (WP
says so) and it has a internal drive thats about 10MB in size and its got 2 5
1/4 drives, which are useless to me (my other 4 computers are macs) If you know
or know a site about this thing I would be thrilled. OH yeah, I also have a nice
Mac Plus system, decked in platinum, and all I need is that dern 20MB drive that
sits under it..but I tink I found one, unless one of you know where I could find
one for cheap
TIA
<center>Hermz
^^^^^^^^
Is da man!!</center>
6 Sep
6 Sep
5:05 a.m.
New subject: Newbie member saying something!!!
Hermz,
When you say that this is the original Compaq, do you mean that it is the
Compaq Portable (suitcase-sized, 9" monitor) or the Compaq Deskpro
(standard CPU box and external monitor)?
If the latter, it's actually an 8086 box. It's scrupulously
IBM-compatible, and will run any software than ran on the IBM PC.
Performance is a little better than the original PC.
The floppy disk drives are double-sided, double-density, and can hold 360K
of data each.
There is quite literally a mountain of DOS software that will run on this
beastie. You can also run CP/M-86, UCDS P-System, and even Xenix (if you
can find it).
You can find more info on Compaq's web site. Here's the URL for the
Deskpro: http://www.compaq.com/support/techpubs/qrg/Deskpro.html
Enjoy!
-- Bill
On Wed, 1 Sep 1999, Hermz wrote:
hello everyone.
Hey all, just this weekend I went to a flea market and bought my 2nd "classic'
computer. It is the original Compaq, to my knowledge. I paid $10 for it. I would
like to find out more info about this thing, all I know its a 8088 machine (WP
says so) and it has a internal drive thats about 10MB in size and its got 2 5
1/4 drives, which are useless to me (my other 4 computers are macs) If you know
or know a site about this thing I would be thrilled. OH yeah, I also have a nice
Mac Plus system, decked in platinum, and all I need is that dern 20MB drive that
sits under it..but I tink I found one, unless one of you know where I could find
one for cheap
TIA
<center>Hermz
^^^^^^^^
Is da man!!</center>
2:38 p.m.
New subject: Newbie member saying something!!!
Nope, it is the siutcase style machine, with a 8088 processor (I checked in
wpinfo) Know where I can get any info on that??
On 9/6/99 at 10:05 AM, sheehan(a)switchboardmail.com (Bill Sheehan) wrote:
Hermz,
When you say that this is the original Compaq, do you mean that it is the
Compaq Portable (suitcase-sized, 9" monitor) or the Compaq Deskpro
(standard CPU box and external monitor)?
If the latter, it's actually an 8086 box. It's scrupulously
IBM-compatible, and will run any software than ran on the IBM PC.
Performance is a little better than the original PC.
The floppy disk drives are double-sided, double-density, and can hold 360K
of data each.
There is quite literally a mountain of DOS software that will run on this
beastie. You can also run CP/M-86, UCDS P-System, and even Xenix (if you
can find it).
You can find more info on Compaq's web site. Here's the URL for the
Deskpro: http://www.compaq.com/support/techpubs/qrg/Deskpro.html
Enjoy!
-- Bill
<center>Hermz
^^^^^^^^
Is da man!!</center>
7 Sep
7 Sep
8:32 a.m.
New subject: Newbie member saying something!!!
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 658 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/19990907/75652b5a/at…
10:51 a.m.
New subject: Newbie member saying something!!!
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 2432 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/19990907/c6162297/at…
11:49 a.m.
New subject: Differentiating chips (Was: Newbie member saying something!!!
On Tue, 7 Sep 1999, Sean 'Captain Napalm' Conner wrote about using
self-modifying code to check the size of the prefetch buffer to
differentiate between 8086 and 8088.
But does anyone have a good way to differentiate between 386SX and 386DX?
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?
11:55 a.m.
New subject: Differentiating chips (Was: Newbie member saying something!!!
On Tue, 7 Sep 1999, Sean 'Captain Napalm' Conner wrote about using
self-modifying code to check the size of the prefetch buffer to
differentiate between 8086 and 8088.
But does anyone have a good way to differentiate between 386SX and 386DX?
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?
How about trying to select or write to memory addresses higher than 16mb,
which was the maximum the 386sx could address? Or would that give you
false positives for 386sx if you don't actually have more than 16 megs of RAM?
--
Jim Strickland
jim(a)DIESPAMMERSCUMcalico.litterbox.com
-----------------------------------------------------------------------
BeOS Powered!
-----------------------------------------------------------------------
10 Sep
10 Sep
10:19 a.m.
New subject: Differentiating chips (Was: Newbie member saying something!!!
On Tue, 7 Sep 1999, Sean 'Captain Napalm'
Conner wrote about using
self-modifying code to check the size of the prefetch buffer to
differentiate between 8086 and 8088.
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).
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. 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 :(. 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)
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 :)
http://www.ddj.com/articles/1996/9609/9609o/9609o.htm
Gruss
H.
--
Stimm gegen SPAM: http://www.politik-digital.de/spam/de/
Vote against SPAM: http://www.politik-digital.de/spam/en/
Votez contre le SPAM: http://www.politik-digital.de/spam/fr/
Ich denke, also bin ich, also gut
HRK
10:54 a.m.
New subject: Differentiating chips (Was: Newbie member saying something!!!
On Fri, 10 Sep 1999, Hans Franke wrote:
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.
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.
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). 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. 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(a)xenosoft.com
XenoSoft http://www.xenosoft.com
2210 Sixth St. (510) 644-9366
Berkeley, CA 94710-2219
7 Sep
7 Sep
11:58 a.m.
New subject: Newbie member saying something!!!
I don't think that works as the prefetch is coherent. To my experience
the que was nearly transparent to programs and I never allowed for it
presence not incurred any difficulty for that offense. It's fuzzy but
branches and several other events dump the queue.
Allison
On Tue, 7 Sep 1999, Sean 'Captain Napalm' Conner wrote:
It was thus said that the Great Tony Duell once
stated:
8086 has a 6-byte prefetch queue while the 8088 has a 4-byte prefetch
queue. I did a *lot* of 8088 assembly programming years ago. Possibly too
much 8-)
Nope, it is the siutcase style machine, with a 8088 processor (I checked in
The 8088 and 8086 are actually very similar processors. The main
difference is the external data bus width -- the 8086 has a 16 bit
external bus and the 8088 has an 8 bit external bus. I seem to remember
that the internal instruction queue is a different size on the 2 chips
but I would have to check. It is therefore difficult to tell the chips apart
in software and a lot
of 'machine info' type utilities report finding an 8088 even on
8086-based machines.
I don't think it's that difficult.
org 0100h
mov al,0 ;[1]
mov bx,offset jmp_point + 1
mov [bx],al ;[2]
nop ;[3]
nop
nop ;[5]
nop
jmp_point: jmps x86_chip ;[4]
mov dx,offset t88_chip
jmps display
x86_chip: mov dx,offset t86_chip
display: mov ah,9
int 21h
t88_chip db 'Hi, we're an 8088!',13,10,'$'
t86_chip db 'Hi, we're an 8086!',13,10,'$'
[1] We're going to change the offset of the jump at point [3] to
0. On an 8088, this will take effect since the instruction will
not have been read in by the time we write the modification at
point [2]. On an 8086, the instruction at point [4] will already
be in the pre-fetch queue and won't be modified (well, it will be
modified in memory, but not in the pre-fetch queue).
[2] This is a two byte instruction. After the primary byte is read, the
8086 will be fetching the first byte of the instruction at point
[4], while on an 8088, it will be reading in the instruction at
point [5]. On the second byte, the 8086 will have finished reading
the JMP instruction, while the 8088 will read the next NOP. The
write back will happen at JMP_POINT+1, which the 8086 has already
read, while the 8088 has yet to read.
[3] Filler space for the 8088 4-byte prefetch queue.
[4] The instruction we're going to modify to determine if we're on an
8086 or 8088.
[5] See note [2].
IMHO the only reliable way to know what CPU you
have is to read the
markings on the chip package.
Ah, but a program will have a problem doing that.
-spc (Note: this is untested code. Theoretically, it should work, but I
don't have an 8086 to test it on)
12:22 p.m.
New subject: Newbie member saying something!!!
On Tue, 7 Sep 1999 allisonp(a)world.std.com wrote:
I don't think that works as the prefetch is
coherent. To my experience
the que was nearly transparent to programs and I never allowed for it
presence not incurred any difficulty for that offense. It's fuzzy but
branches and several other events dump the queue.
A variant of that code DOES work.
Early versions of Xeno-Copy would run on 8088, but would NOT run on 8086.
Inserting a few irrelevant or NOP instructions into the middle of the
self-modifying code lenghtened the distance to work with the 8086 larger
prefetch buffer. But a full fix can be done by putting in a JMP $+2 in
between. Jumping to the next instruction wouldn't seem to do anything,
but ANY jump flushes the prefetch buffer.
Rather than a raw speed test, how about COMPARING the speed for moving a
block of data that is word aligned v one that is not? On the 8088 (8
bit), there is no difference. But on the 8086 (16 bit), there is a quite
measurable performance inmprovement for word aligned data.
11:37 a.m.
New subject: Newbie member saying something!!!
The 8088 and 8086 are actually very similar
processors. The main
difference is the external data bus width -- the 8086 has a 16 bit
external bus and the 8088 has an 8 bit external bus. I seem to remember
that the internal instruction queue is a different size on the 2 chips
but I would have to check.
The 8086 prefetch que is 6 bytes and the 8088 is 4 bytes, this is to keep
it from beating up the bus.
It is therefore difficult to tell the chips apart in
software and a lot
of 'machine info' type utilities report finding an 8088 even on
8086-based machines.
Nearly impossible. the only test I know is to compare transfer speed to
known clock. the 8086 comes up about 10-20% faster for a given clock
and memory speed. Plugging in a V20 can fool that test (you can test for
V20 instuction extensions for that).
IMHO the only reliable way to know what CPU you have
is to read the
markings on the chip package.
If they havent been sanded off or they are v20/V30s!
Allison
9078
days inactive
9087
days old
12 comments
9 participants
participants (9)
-
allisonp＠world.std.com -
ard＠p850ug1.demon.co.uk -
cisin＠xenosoft.com -
Hans.Franke＠mch20.sbs.de -
hermz1＠earthlink.net -
jim＠calico.litterbox.com -
sheehan＠switchboardmail.com -
spc＠armigeron.com -
SUPRDAVE＠aol.com