>
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
> From: Fred Cisin <cisin at xenosoft.com>
> Date: Sat, 02 Feb 2008 17:25:27 -0800 (PST)
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>> > I asked Gary Kildall, "Now that most commercial machines are going to
>> > 5.25 inch disks, what is the STANDARD format for 5.25?"
>> > He answered, "8 inch single sided single density."
>
>On Sat, 2 Feb 2008, Roy J. Tellason wrote:
>> Can you do that on a 5.25" disk? What is that, 77 tracks, I forget how many
>> sectors...
26
>IF your disk controller is "cooperative". The "1.2M" drive is almost the
>same as an 8" drive. 'course, his remark was during the days of 48 tpi 35
>track 5.25", . . .
Therein lies the problem. I'd asked the same question in 78 IE: are you
ever going to consider a different disk format? No, there ae so many and
none compatable, some too small and a few limited to a specific vendor.
Until there was a viable and better standard 8" SSSD was it. I think
that standard emerged around 1983 with 360K (40tracks two sides DD)
soft sector and again with 1.44MB 3.5". Other than those what other
wide spread and not limited to a specific vendor and those two were
standard only for PCs.
Allison
> From: "Joshua Alexander Dersch":
> Were there similar problems in the CP/M world? That is, was it
> commonplace for there to be CP/M programs that bypassed CP/M BDOS calls
> and wrote directly to a specific machine's hardware? Seems like CP/M
> developers were more disciplined in this fashion, but maybe it's just
> because in the CP/M arena there were so many different pieces of hardware
> it was the only way to do it? (Whereas with IBM, the PC was seen as more
> of a reference standard, even if it wasn't really that way in the
> beginning?)
The great thing about CP/M (and I'm talking about the 8-bit version
here) was that it imposed a file system and made disk I/O uniform--
128 byte sectors, regardless of how the information was actually
formatted onto a drive. CP/M was really primitive when it came to
console I/O, giving only about 3 functions for output and input each.
No cursor positioning or screen control; basic TTY style I/O. And,
while there was an IOBYTE facility to redirect I/O, implementation
was very nonuniform between vendors.
As a result, for other than simple command-line utility programs and
compilers/assemblers and the like with minimal I/O requirements, most
productivity and comms programs had to go to the hardware directly
for display and communications.
And that, I think was the innovation of programs such as WordStar and
SuperCalc, and, to a lesser extent MODEM7 and Kermit--that you were
running on an operating system that was basically designed for TTY
I/O with no connectivity and the majority of systems were using CRTs
and had modems. The problem became then how to make a single program
work for everyone--and that was done with custom patch overlays.
DRI, for its part, seemed to remain blissfully ignorant of both of
these aspects.
Likewise, it wasn't MS-DOS that was the great advance for the IBM PC
platform, but rather the well-documented BIOS and I/O interfaces.
Heck, PC-DOS 1.0 wasn't that different from CP/M-86--you still had to
do your disk I/O through FCBs, just like CP/M. I believe, to this
day, you can still issue your DOS calls by loading (CL) with the
request number and calling TPA:0005.
Cheers,
Chuck
There is currently an HP9826 in bits on my bench, this machine
incorporates a single 5.25" floppy drive. Now must such machines used
Tandon TM100-2As (slightly modified to HP spec), but this one has a
different tye of drive. A label on it says :
Magnetic Peripheals Inc
(A Control Data Company)
P/N 77711807
I am looking for a servicv manual for this drive, in particular
_mechanical_ information.
Looking at the drive, all the electronics (inclduing the spindle motor
speed cotnrol) is on one PCB on top. The spindle motor is the normal
motor + tachogenerator at the rear left corner, driving the spindle by a
blet on the underside. The head postiioner stepper motor is at the rear
right corner, shaft vertical with a taut-band mechanism to move the
heads. To the right of the stepper motor drum, attached to extensions of
the head carriage, is some sort of damper unit.
The PCB might be HP special. In particualr there is a header connector to
link up an external drive in-use LED. But I susepct it's closely related
to a standard MPI drive.
I need to know how to dismantle the band mechnaism to remove the heads,
and als what to do about the damper which is leaking grease onto the
chassis (!).
Does anyone recognise that drive mechanism and know where I could find a
service manual. I've not found anything on-line yet.
Also, does anyone have a proper data sheet for the MC3470 (disk read
amplifier etc). The only one I can find on the web is the NTE one which
doesn't have that much information in it.
-tony
>
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
> From: Dave Mabry <dmabry at mich.com>
> Date: Sat, 02 Feb 2008 13:39:09 -0500
> To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
>
>Roger Ivie said the following on 2/2/2008 1:16 PM:
>>
>> I did a small amount of work with ISIS, but after I had used CP/M. I
>> used an Intel PDS development system for the 8051 to debug some
>> firmware; I think it was for DEC's SCSI floppy controller.
>>
>> The PDS was interesting in that it was a portable system about the size
>> of a Kaypro and had *two* 8085s. ISIS gave you an A> or B> prompt, but
>> it indicated to which processor you were speaking rather than which
>> drive was the default.
>
>
>Now *that* was multiprocessing! I remember it well. In fact I still
>have a working one. With ISIS-PDS there was a logical locking so that
>you could have both processors (actually *two* complete computers, each
>with its own 64KB of RAM) doing disk i/o concurrently and they wouldn't
>scramble each other's files.
Interesting. Before I'd seen a PDS I experimented with S100 boards of
my own design with the goal of getting 3 z80s complete with local ram
and public ram to do mutiprocessing. By time I was done I'd achieved
that and more. All the disks had their own CPU and DMA to public ram
as well as the IO system having it's own CPU to manage buffers and
pending IO. Each Z80 had it's own boot and 64K ram plus a mapper to
page out any 4k portion to public ram or make any 4k pag of public ram
part of the 64k private space. Public ram was initially 256k
and grew to 512k. The 3 Z80 has doorbell interrupts and used public
ram for data and status passing. It ran CP/M2.2. The mostbizare hack
was one cpu running CCP attached to console, the second running the
BDOS nad dispatch bios and the third running the application (any cpm app).
Since the disks and IO was smart they acutally ran the Bios abstraction
so the dispatch bios really only routed calls and data pointers for
the DMA.
Learned some things.
3 cpus can be fast, and takes nine times longer to program
and 9times that to debug.
Keeping everyone from killing each other is hard.
One really fast cpu with smart peripherls is faster.
Smart peripherals that can DMA to public memory are
a a definate win.
You end up adding time slice and process management
in some form to keep everyone doing the right thing
in the right order.
CP/M is not safely recusive.
Hardware for prioritizing bus access is complex for S100.
S100 bus will make you crazy.
I learned a huge amount about multitasking, multiprocessing
and process management in real time.
It was successful but I would later pull two two of the three
4mhz cpus and upgrade one to a 10mhz Z80 to far greater advantage.
I still used that highly modified NS* Horizon running a 10mhz z80
and a smart controller for floppy, HDC and IOP board with an 8085
to handle the two serial ports, parallel printer and RTC.
Years later I would get a Compupro MPX1 (8085 system IO MUX).
It was much like what I did for the IOP save for the IOP use
real DMA (8257A) where the MPX1 does PIO.
File locking: You can lock CP/M files by marking them system or RO
so other cpus/processes can crunch them. The real trick is getting the
"owner to" not recognize the lock.
>It came with a single full-height floppy drive. I changed mine to have
>two half-height ones and if I was careful I could run ISIS-PDS on one of
>the processors and CP/M-80 or CP/M Plus on the other. ISIS-PDS would
>boot from the internal bubble memory (128KB) and CP/M would boot from
>the floppy. I would do my Intel development work on the ISIS side and
I still have a pair of BPK72s working with spare bubbles.
>document it in Wordstar on the CP/M side as I was developing. it.
>There was no mechanism to keep one side from clobbering the other side's
>files on floppies, so I had to keep that straight in my head. At the
>time it was not hard to do, but today I am probably too lazy to keep it
>all straight. ;)
It's still a cool thing to see "lowly" 8085 doing fancy stuff.
Allison
>
>Dave
>
Looks like this feature of WWIV will be important in a patent lawsuit by
Trend Micro. Trend Micro claims to have a valid 1995 patent for doing virus
scanning on email servers, and many of their claims appear to be well-known
capabilities that WWIV had well before 1995
For mor information on this please look at this article:
http://www.groklaw.net/article.php?story=20080125135544713
-RZ
>
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Fri, 01 Feb 2008 13:06:58 -0800
> To: cctalk at classiccmp.org
>
>> Date: Thu, 31 Jan 2008 09:21:58 -0500
>> From: Allison
>
>> If one takes a moment some of that was INTEL MDS artifact that were
>> programmed around. Also there are plenty of unused RST vectors.
>> For the later systems the 8259 was available and it inserted a
>> CALL XXXX where XXXX was anywere in addressable memory. The Z80
>> in mode2 interrupt also could vector anywhere in ram. DMA
>> is not impacted by how the low page is used.
>
>
>IIRC, in ISIS-II, programs were loaded somewhere above 3000H,
>depending on the buffer requirements of the program, but always above
>the ISIS resident, which always occupied the same space, regardless
>of memory size.
>
>On some early 8080 implementations, an 8259 wasn't used (expensive!)
>and a simpler circuit using a priority encoder and a latch to stuff
>111iii11 onto the bus in response to an interrupt acknowledge. CP/M
>could get in the way of this scheme, if it was desired to use the
>RST0 vector for an interrupt. Otherwise, there was no problem,
>except for the RST vector (usually 7) used for DDT--but that's local
>to DDT and easily patchable (it's done for the Amstrad PCW, for
>example).
That scheme also work for Z80 mode2 where I is XX and the inserted
low byte comes from the commonly 74148 and a pair of 74175s.
>After having used ISIS before CP/M, I was happy to see the "lean and
>mean" CP/M. ISIS was verbose, clumsy and slow (e.g., :F0: instead of
>A: for the first floppy drive; "DELETE" instead of "ERA").
Also an ISIS user. The usual OS used on the shop MDS was not ISIS
but instead CP/M!
>Of course, had CP/M simply shifted the TPA up 256 bytes and used the
>area between 0100h and 01FFh for command-line storage, system request
>vectors and FCBs, that would have solved the problem, but for the DDT
>RST vector.
Having the RST0 vector already used wasn't too bad as it's also RESET
but the DDT one was harder as the cheap pullup resistor address
(RST7) was easy. Most of the z80 boards had vectored interrupt
logic and that made it easy as most systems only needed maybe two
or three ints to do the job and 6 were unused. It was only the early
8080 S100 machines that were impacted and some did have interrupt
hardware that was more than RST7 by pullup. By time CP/M-2 was
available Z80 was almost universal and the few that werent were
either 8085 or 8080 with ints. Whats interesting is the 8085
interrupt pins were all usable including trap in a CP/M environment,
thats potentially four interrupt inputs.
Now if you are doing low memory banking those interrupts locked in page
zero were a pain. Z80 mode 2 or other hardware was needed to get
out of that hole.
Allison
>Cheers,
>Chuck
>
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
> From: Roger Ivie <rivie at ridgenet.net>
> Date: Sat, 02 Feb 2008 10:16:28 -0800 (PST)
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On Fri, 1 Feb 2008, Allison wrote:
>>> From: "Chuck Guzis" <cclist at sydex.com>
>>> After having used ISIS before CP/M, I was happy to see the "lean and
>>> mean" CP/M. ISIS was verbose, clumsy and slow (e.g., :F0: instead of
>>> A: for the first floppy drive; "DELETE" instead of "ERA").
>>
>> Also an ISIS user. The usual OS used on the shop MDS was not ISIS
>> but instead CP/M!
>
>I did a small amount of work with ISIS, but after I had used CP/M. I
>used an Intel PDS development system for the 8051 to debug some
>firmware; I think it was for DEC's SCSI floppy controller.
Use a MDS to bring up CP/M2.2 on a NEC PDA-80 an 8080 based FP machine
that had a remex tape punch reader. Yep configured CP/M, bolted on a
bios and punched it to PT!
>The PDS was interesting in that it was a portable system about the size
>of a Kaypro and had *two* 8085s. ISIS gave you an A> or B> prompt, but
>it indicated to which processor you were speaking rather than which
>drive was the default.
It was a bizzare little box.
Allison
>--
>roger ivie
>rivie at ridgenet.net
Smallish grey booklets, AV-D827C-TE, entitled "VAX-11 Programming
Card". I have two of these available.
If you want one, drop me a mail off-list please.
Ed.
I think this is a great idea:
We should all put in our travel notes. I forgot who entered the bay area surplus shops and hamfests, but thank you!
If you are stuck in Denver, you may need some fuel, and I recommend the Tortilla Flat mexican restaurant in lLittleton; The Blue Parrot Italian in Louisville.
It all my travels, the best surplus place I have ever been to is Mendelssohn Electronics in Dayton, Ohio. A huge old building downtown, loaded with things you never see anywhere else. I got a IBM plug board there, I think it belonged to a card reader sorter. It was still all wired up with the last program and I spent many hours trying to figure out what it did.
In Albuquerque there is a place called the Black Hole, I have not been there yet, but I have herd so much about this place and its eccentric owner. He gets all kinds of weird things from the Los Alamos lab and sometimes to their embarrassment when somebody later figures out what the item was, or was used for. Im headed back through in a month, and I'll be sure to write it up.
On the way, I plan to stop at the aircraft boneyard and Titian missle silo in Tucson:
http://www.pimaair.org/index.php
Let us know what other cool stuff you have found!
Randy
> From: evan at snarc.net
> To: cctalk at classiccmp.org
> Date: Fri, 1 Feb 2008 23:45:25 -0500
> Subject: Stuff to see in Denver area?
>
> Business is leading me to Denver for a few days at the end of February.
> Might have a spare day to play tourist. What should I do or see there? Any
> collectors out there want to meet up?
_________________________________________________________________
Connect and share in new ways with Windows Live.
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008
Hello vintage microcomputer fans.
I recently bought an Interact Model One computer on ebay
(#150208636366). It was in good shape and it went relatively cheaply.
This beastie is 8080 based, and has very coarse color graphics. Mine is
unusual in that it has a white housing and a real keyboard, not the ash
gray case and tiny rubber keys of all the other interacts I've seen. It
has an integrated cassette deck, and no ROM BASIC -- that has to be
loaded from tape. By all measures is was really a miserable little
runt. :-)
Well, the seller put it in a box that was exactly as wide as the
computer, such that there was no padding in that axis, other than the
cardboard of the box. The rest was just stuffed with foam peanuts, and
a small sheet of bubble wrap that was floating in the box.
As you might guess, it didn't fare well. The space bar popped off and
peanuts got jammed inside the machine. Luckily, it was easy to put
back. Three of the five buttons of the integrated cassette deck broke
off. The plastic buttons are OK; it was just the glue that broke, and
the keys can be glued back on. Worst, a corner of the case shattered
into pieces, and left a large crack along the top rear. Being out $68
isn't so painful as the idea that this thing found its way through the
world for 30 years in decent condition and then got ravaged due to
simple carelessness.
Still, I crossed my fingers and plugged it in. At first I thought it
was dead, but then realized it is putting out modulated video. After
swapping my in nice Sony color monitor for a TV and tuning in channel 3,
I get a "DEPRESS L TO LOAD TAPE" message. Hooray for that. All isn't
well, though, as pressing the "READ" button doesn't cause the tape
mechanism to turn, even after pressing L. It is kind of moot, though,
as the plastic cover doesn't pop up when I press eject.
A web search hasn't turned up any useful information on the machine --
scans of manuals, in particular. A short time ago, a much more
complete system, including manuals, sold on ebay (#220191106456), to
"hokinfan". I attempted to contact the buyer to see if he could help me
out, but ebay rejected my attempts because they didn't see any trading
history between us. (please, no ebay rants)
So, does anybody on the list happen to have any form of technical
documents that I might be able to use to help troubleshoot this? Beside
wanting the information just to have it in case, I do have an immediate
need to figure out the tape deck, and to rig up some replacement
joysticks, since the machine didn't come with them.
Thanks