Multibus-I Users ??

From: Richard Erlacher <edick_at_idcomm.com>
Date: Fri May 28 08:30:04 1999

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_at_idcomm.com>
To: Discussion re-collecting of classic computers
<classiccmp_at_u.washington.edu>
Date: Thursday, May 27, 1999 11:16 PM
Subject: Re: Re[4]: Bringing up a CPM


>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_at_world.std.com>
>To: Discussion re-collecting of classic computers
><classiccmp_at_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
formal
>>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
"full-size"
>><(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
you'r
>><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
and
>>understand it the improvements will come.
>>
>>Allison
>>
>>
>
Received on Fri May 28 1999 - 08:30:04 BST