28 May
1999
28 May
'99
4:25 a.m.
Dick,
I don't have any catalogs that show the single board computers but I
found something in the '85 Intel product guide. It lists an iSBC 186/03
that has an 80186 and that they classify as both a CPU card and Mass
Storage Controller. There is only a one line description for each so I
don't know if it has 8042 or not. Here's the info that the CPU section
gives: CPU = 80186, RAM = 0 to 64K EPROM or EEPROM = 0-512K, iSBX expansion
connectors = 2, MultiMode Expansion = iSBC 341, Operating System Software =
iRMX. Here's what the mass storage section says: No. of boards = 1,
Interface Supported ="SCSI-single host environment (transfer rate 1.2
Mbyte/sec asynchrous)", No. of drives supported = "single targer
environment", S/W Support = RMX 86. There is also a chart showing the year
of introduction and relatve performance. It was introduced in 1984 and it's
performace is a 5.
Joe
At 07:30 AM 5/28/99 -0600, you wrote:
Are there any users of the old Multibus-I out there?
I'm having difficulty
identifying a board that is so "busy" that there was no room on which to put
an identifier in the silkscreen. It's a FD/HD controller with a '186 and an
8042 on it. Sound familiar?
Dick
-----Original Message-----
From: Richard Erlacher <edick(a)idcomm.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Thursday, May 27, 1999 11:16 PM
Subject: Re: Re[4]: Bringing up a CPM
formal
"full-size"
you'r
and
Yes, '81 was pretty late . . . CP/M-86 came
out then, as did PC-DOS.
Within a few years, nobody wanted to be limited by the same systems they
coveted only a few years earlier. By '81, the Apple][ could be equipped
with a Z80 board, a "real" FDC (Sorrento Valley Associates ?) an 80x24
display, and a hard disk if you could afford it. I recently sold the
prototype of the original Apple HDC I made up in the spring of '81 together
with my first ST-506.
Those were the days . . . <sigh>
Today I can still run CP/M but at an effective clock rate of 83MHz on my
notebook . . . designing hardware involves thousands of lines of HDL, weeks
in front of a simulation, and when it's done, I can't even hook up an
instrument small and fast enough to inspect it because even our government
can't afford one. One has to design circuits with 25% overhead so they can
be inspected. Oh, well . . .
Dick
-----Original Message-----
From: Allison J Parent <allisonp(a)world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Thursday, May 27, 1999 8:54 PM
Subject: Re: Re[4]: Bringing up a CPM
><If you're writing your own, it might be well to keep in mind that the
BIOS
<used
in several late-generation CP/M systems used device drivers which
coul
>
>It was late generation in 1981! I started doing it then. CPM had a product
called CP/M+ (CP/M3.0) to extend that idea.
<California Computer Systems (CCS) had a pretty nice boot process in which
<they loaded a skeletal BIOS in a 32K CP/M, since 32K was the smallest
memor
><in which they claimed they could run. It wrote that to the boot blocks,
>
>Actualy it was 20k for cpm2.2, as it was distributed as a 20k system that
>you would run movcpm on to get the xxK version you wanted.
>
><then, under the control of that skeletal system, they loaded a
><(you get to define that!) CP/M and
transfer control to it. It's pretty
><solid and makes the preparation of a bootable disk a straightforward if
no
><a quick process.
>
>Yes and they were doing it a long time back, Compupro too. Kaypro was one
>of the few "boxed" system that had the rom mapped to get a large TPA.
>
><IIRC, the XEROX 820 used a swapped-in BIOS which lived in PROM and was
><mapped into the TPA during file transfers, or something on that order.
If
Classic.
<your machine can handle that, it saves on BIOS size, especially tables,
etc
><and, generally speaking, if the READ operations from the TPA are from
><temprorarily mapped-in PROMs, you can overwrite the TPA in the event
<loading overlays, with complete impunity. That way your
blocking/deblockin
><buffer space can still reside in high memory.
>
>An IMSAI can neither handle that nor not handle that. The basic design
>had no rom! To do that you need a prom card with a little bit of hardware
>to map it with an IO port.
>
>The key here is to get a working system in whatever space... Why, it's the
>development platfrom for itself. Once you have it running and can poke understand
it the improvements will come.
Allison