> > > > > > Well, usualy this doesn't work, because of the different CPUs
> > > > > > (I assume we are talking about CP/M80 - CP/M86 will of course
> > > > > > boot on most classic PCs). The only way beside Emulators under
> > > > > > DOS/Win, and rare coprocessor boards is of course the NEC V20.
> > > > > > A V20 is for all PC/PC-XT machines a must, because of about
> > > > > > 10% faster execution (the V20 core is build like the 186/286).
> My first PC had a 10 MHz 80186 as its CPU, though it was an XT architecture.
> It easily outperformed the early (6 MHz) PC/AT types, though I'm not sure why.
Of course it should. The 186 core is exactly the same core as the
real mode pert of a 286. CPI (clock per instruction) numbers are
exactly the same. So a 8 MHz 186 (as used in the PC-D) outperforms
a 6 MHz 286 as used in the original AT by 25% - in fact, when the
idiots at SIEMENS switched for standard PC architecture, their first
machine was a 8MHz 286 ... and they had quite a problem to explain
to their customers why they should buy the new machine ... so the
ver next (within just a few weeks) was a 10 and then a 12 MHz
version :)
> > > there's a BIOS call. All the CP/M BIOS has to do is call the code that
> > > switches to native mode before interpreting the parameters of the call.
> > Jep. that kind of stub code is needed. But wheren't there some problems
> > when switching back ? It wasn't all easy.
> True, but though it wasn't easy, once accomplished, the time penalty for it
> would be made up in increased performance in the BIOS.
Hmm. as long as we talk floppies and other regular I/O there is almost
no difference between an 8080 BIOS, and a 8088 BIOS. Transferrates
are the same. at 4.77 MHz the CPU is waiting anyway for the disk
to turn. To me the real advantage is to use all kinds of standard
MS-DOS drivers for various hardware and present them so the CP/M
programm as standard devices. Of course including the usage of
features where CP/M has no idea of - like sub directories.
> > > I've looked long and hard at this, having wanted to use a V50 (16-bits,
> > > enhanced execution unit, integrated peripherals, DMAC, PIC, UART)
> > As for the enhanced execution parts, the V20 and V50 are the same. Both
> > are from the CPU part like the 186 - or like the 286 sans virtual adressing.
> The '286 didn't inherently support VM as did the '386, BTW. It did have
> memory management, but only in a primitive way. It wasn't as primitive as the
> already clumsy segmented architecture of the 8086 family.
Now here I have to disagree in any way.
First, the 8086 segmented architecture was anything but clumsy. I'd
rather considere it a real handy way to extend the addressing range
of a 16 Bit CPU. I always liked the segemt registers for the clean
and simple design. Shure, one could have whished for a processor
with more general purpose registers, where every register could have
been used as base (segment) register, but this would have bloathed
the RISCish architecture of the 8086.
Second, the 286 had virtual memory. I don't know what other considere
criterias to define virtual memory. To me there are two basic functions:
a) Each process gets an adress space starting at address zero and growing
up to some more or less logical upper limit.
b) The system enables some kind of swaping or pageing to share a
limited amout of RAM, so the sum of all memory needed for the system
to perform may be larger than the real installed memory.
To form a VM system both functions have to be provided in a manner
which is invisible to a regular user programm.
(sometimes there is a third function named, memory protection - which
means one programm should not be allowed to access memory outside
of it's process due a faulty instruction - I'd considere this only a
nice to have feature).
Criteria a is already matched with the basic 8086 design. Manipulation
of segment registers is only valid for the OS or with values provided
by the OS. Just the 8086 doesent provide any help for function b.
The 286 introduced not only segment fault processing to provide
function b, but also added memory protection.
The 386 added anoter mode of segmentation and finaly a mode for
page orientated virtual memory, still, VM was already there with
the 286 (and just remember all the Unixes on 286 machines).
Of course page orientated virtual memory is far better suited to
random applications and way simplier to use than segment based,
nonetheless both are here to fulfill the same need.
I never thought I have to defend swaping, which I considere inferior
(Sorry, I'm grown up in a /370 environment)
> > > in the same
> > > way. Mounting a couple of 8-bit ISA cards on an S-100 board is quite
> > > straightforward, and the signals seem to work out quite well, too. The
> > > combination I'd use would be an 8-bit monochrome display board and an
> > > 8-bit HDC.
> > See, where is the idea of using an S100 bus system and then adding ISA
> > cards ? I'd rather take a XT clone, plug in a V20 and let the hardware
> > be standard (8 Bit) PC hardware
> I wouldn't do that to cook up a replica of an old system, but I would to
> create a development tool with which to work up software for an Imsai or other
> old-timer. and, speaking of old-timers, do you know whether the V20 does the
> "address mirror" thing common to 8080's, where the low address byte appears on
> the high address bus during I/O cycles? I've got a couple of old S-100 boards
> that rely on that for some of their functions.
Nop, it doesn't. The V20 bus is a strict 8088 inplementation, and as such
in no way related to the 8080 Bus. Also when building a new old system,
I'd use a V30 or V50 (as you suggested) which offers a 16 Bit bus - and
then of course use 16 Bit I/O cards (HD etc.) to speed up operation (we
had a lightning 8080 in mind, hadn't we ?). This is especialy true when
useing a ATA Disk drive - 16 Bit data transfer is quite a runner. Since
_classic_ S100 is an 8 Bit bus, connectng anny Hardware, beside some
maybe serial is quite useless - One exception is eventualy to drive some
hardware where you are just developing 8080 rivers for (to use in your
classic target system).
Again, the last feature can still be acomplishend by a ISA to S100
interface. So no special hardware but a XT (maybe a fast, 10 MHz XT :)
and the S100 Interface.
> > and MS-DOS as superior BIOS (Well, in
> > fact I belive MS-DOS is still one of the best, if not the best bootloader
> > available).
> I personally never learned to like CP/M-86, so it doesn't interest me. I do,
> however, like the notion of running the very fast 8080 internal to the V50 at
> 8-16 MHz, with its 16-bit data bus, just to hot-rod the OS. What's more,
> interfacing an IDE drive would suddenly become utterly trivial. It wouldn't
> even interest me a little bit to run CP/M 86 on the same platform.
> I won't wander off into the argument over whether MSDOS is actually "better"
> than CP/M. However, if you're running a PC, then I think MSDOS, which was
> designed for it is the OS you should use. If you want to run CP/M on a PC, I
> still favor CP/M-80 via an emulator over running CP/M 86 on a PC. For one
> thing, it offends me that the "better" hardware running the "better" software
> was actually slower than comparable Z80 hardware running the CP/M-80. That's
> why it took so long for me to move to a PC. I couldn't justify spending
> nearly $5k (which was what a PC/XT with a 50 MB hard disk cost back then) only
> to have it run at 75% or less the speed of my already familiar and functional
> CP/M box with that size hard disk.
I guess we are just talking without listening. My point was jsut that
MS-DOS makes a great base for whatever project - like a bootloader.
Gruss
H.
--
VCF Europa 3.0 am 27./28. April 2002 in Muenchen
http://www.vcfe.org/
Received on Thu Apr 11 2002 - 11:21:44 BST