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:
A note to all 2.11bsd users:
Some time ago I looked into running 2.11bsd on systems without
floating point unit. The release notes state that this is untested
and unsupported, and indeed it didn't work.
Robin Birch some time ago fixed part of the issues, see patch 434,
but still the kernel paniced when the very first program was started.
I managed to localize and fix the problem in sys/pdp/mch_fpsim.s.
Steven Schultz right away issued 2.11BSD patch #445. All patches
up to and including 445 are provided by Steven under
A patch level 445 system will now boot on simh for example on a
set cpu 11/70 nofpp 4m
configuration and work just fine, albeit a little slower.
It should thus also work on a real 11/70 without FPP. I heard
of some 11/70 with non-working FPP's, so this maybe good news
for the owners.
With best regards,
Dr. Walter F.J. M?ller Mail: W.F.J.Mueller at gsi.de
GSI, Abteilung KP3 Phone: +49-6159-71-2766
D-64291 Darmstadt FAX: +49-6159-71-3762
I am trying to ID a chip from a SFD-1001 motor control board. This
is printed on the chip:
It looks like a normal DIP, except for the middle pins which
look to be twice as wide. Is this for heat sinking? I have tried
searching for this chip but so far have found nothing. The board has
Which also has not turned up anything useful.. The 5 1/4"
drive mech this board is connected to was made by Matsushita and its
model # is JU-570-2.
From reading the SFD-1001 technical manual, the 5 1/4"
mech is just listed as a part so it does not have any detailed
information for this board. :(
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Wed, 30 Jan 2008 10:57:15 -0800
> To: cctalk at classiccmp.org
>> 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
>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.
Things like Termcap and the lise were not needed. However the console
IO was not so good. Try printing a string containing $ using the print
string call. The other was passing 8bit data when needed.
IObyte was mostly uniform, the problem was often it wasnt even
implemented. This was a problem of allowing the BIOS spec to be
minimal and it usually was.
>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
Ignorant, I think no, they gave the hooks and basic requirements. It
was up to the BIOS developer to do a good job or just enough. I've
repeatedly posted that if anything CP/M prevents little and you can
do a great deal at the bios level to really deliver a better system.
The best way to illustrate this is try a system with basic IO and one
with a full interrupt drive IO. The first thing you notice is the
ability to type ahead and the system feels more responsive.
>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.
Well it was patterned (so say copied) after CP/M so.. No surpize
Have a look at:
Ruud's the main guy behind the 1541 IDE project I mentioned to you,
(and is on the CBM hacker's list I also mentioned) but he does have
an IEEE <> PC project on his site as well.
I've been meaning to look at the IEEE version myself; if you try
it out, share your experience (as will I if I get to it first).
Date: Wed, 30 Jan 2008 02:19:23 +0000
From: Ethan Dicks <ethan.dicks at usap.gov>
Subject: Has anyone ever written a standalone Commodore disk drive
To: cctalk at classiccmp.org
Message-ID: <20080130021923.GA7074 at usap.gov>
Content-Type: text/plain; charset=us-ascii
Hi, Commodore folks,
I have just tracked down an ISA IEEE-488 card and was thinking that it might
be interesting to use it to build an older PC into a Commodore diskette
drive emulator - I recall there are various projects to interface modern
hardware to PETs (like the C2N232 I have with me), but the idea in this case
is to allow existing apps to work as if there were a real C= drive hanging
off the PET's IEEE port. Essentially, the PC would act as closely to, say
a 4040, as possible. My thought was that if I had a real IEEE-488 interface,
it could handle the physical-layer protocol, and the emulator would only have
to handle sending and receiving command strings and data.
The virtual diskettes would be, of course, image files. I'm not really as
worried about RELative files - more along the lines of "direct access"
files where the code running on the PET wants to read and write individual
sectors, ignoring the C= DOS filesystem. That is, in fact, the major
reason for trying to emulate drives in the first place - if it was just a
case of loading and saving streams of data as files, the C2N232 does a fine
job of that (and costs on the order of $10 to breadboard).
There seem to be a number of ways to emulate C= IEC-bus devices (such as
the 1541-III), but not for the IEEE-488. If anyone can point me at any
existing projects, even if they are incomplete, it would be a big help.
Ethan Dicks, A-333-S Current South Pole Weather at 30-Jan-2008 at 02:00 Z
South Pole Station
PSC 468 Box 400 Temp -34.8 F (-37.1 C) Windchill -57.9 F (-50.0 C)
APO AP 96598 Wind 7.9 kts Grid 45 Barometer 674.7 mb (10829 ft)
Ethan.Dicks at usap.govhttp://penguincentral.com/penguincentral.html
> Date: Wed, 30 Jan 2008 13:07:48 -0600
> From: Jim Leonard
> Was there ever a *vanilla* MS-DOS?
Short answer--yes. It was called an "OEM Kit". Basically, you got
the binaries and instructions on how and what I/O drivers to write
and you linked the whole mess together to form two files, IO.SYS and
MSDOS.SYS, though you weren't confined to those names. Many
utilities, such as MODE and FORMAT were provided in skeleton form
with the vendor filling out the details. This lead to a some
interesting variations on MODE. For example, the Grid MS-DOS version
of MODE allows one to control the power status of the peripherals and
a whole bunch of other things.
I may even still have the OEM documentation wandering around
somewhere, printed up on fading tractor-feed paper.
A key difference between the two OEM arrangements was that you agreed
to serialize the copies of DRI products that were sold, while
Microsoft didn't require that. I think that MS simply charged you on
the basis of the number of systems shipped--I'd have to go back to my
files to make sure.
When you get that "Synchronization error" message from MOVCPM, it
means that MOVCPM has compared the serial number of the copy of CP/M
that it contains with the one of the system on which it's running and
the two don't match. Easy to patch out, however--but beware if you
"fill out" your CP/M disk with another's files.
On Jan 30, 2008 11:53 PM, Zane H. Healy <healyzh at aracnet.com> wrote:
> Has anyone ever made an up-to-date install tape that doesn't require
> you to apply all the patches? I've got a chicken/egg situation going
> on, my PDP-11 uses a Viking QDT SCSI board, which requires one of the
> very last patches in order to be supported.
I have an MTI QTS-30 (aka CMD CQD-200/Ts) and TTi QTS-1 / QTS-3 SCSI
tape controllers which I can use to boot a 2.11BSD install tape, but
the install process hangs up while trying to restore the files from
the tape to the hard drive. Anyone know for certain if the latest
patches might help that with these TMSCP controllers?
With the same SCSI tape drive and a CQD-220/TM I can complete the
2.11BSD tape install process to a hard drive attached to the
CQD-220/TM, but then it won't cold boot from the hard drive attached
to the CQD-220/TM. One of the MSCP boot loader patches is supposed to
fix that, but I haven't built and verified myself yet. It's on the to
I slipped off the belt from the motor pulley. Now the motor
can turn without moving the carriage. I tried to turn the motor
by hand (power off) and it can be turned easily.
On power up the motor starts to turn for about one second and
then stopps with the bell continously beeping (till power off).
I observed the signals -carry-, -borrow- and -inc- with an oscilloscope.
They are there when the motor turns but are the timings o.k.?
I'm a Computer collector from Germany and the last 3 years i spend a lot
of time in reconstructing and repairing my PDP11/05 along with its
peripheral devices (2x RK05,RX02,BA11ES).
Noe that these things are working im trying to repair my LA180-PD printer,
that was in no good condition.
With a copy of the logic-prints i was able to find some faulty IC's on
th logic board- but there must be at least one more.
On Power-Up the carriage starts to move back to left edge but stopps before
reaching the left end then the bell is turned on permanently.
There is no reaction on any button pressed or switched over.
Unfortunately i have no Maintenance Manual or Logic description, maybe there
is a person out on this list who can help me with a copy of the documents.
> Date: Wed, 30 Jan 2008 15:44:40 +0100
> From: Holger Veit <holger.veit at iais.fraunhofer.de>
> MSDOS was much better in abstracting hardware, because it had a loadable
> driver concept.
Loadable drivers didn't come along until MS/PC DOS 2.0. Before that,
adding another device, say an extra disk drive, was a brutal
patchwork affair. CP/M 86 was far more advanced (for that matter,
CP/M Plus was too) than MS DOS 1.x. As a matter of fact, the DOS 1.1
reference material included information not only on commands, but
system table layout, .EXE file structure and system requests. ONE
disk buffer for blocking/deblocking. Read and write transferred one
record to and from the DTA. Flat file structure; file I/O done with
FCBs. As a matter of fact, if you didn't know any better, you'd have
sworn that someone took CP/M 2.2 and ported it to the 8086.
MS-DOS 2.0 was a huge advance over 1.1; by Microsoft's own admission,
the goal was to get closer to Xenix in operability.
> Point is there in both cases: the hardware designers did not foresee how
> their hardware could or should be used by software, so they basically
> implanted the bare chips, not even respecting IRQ and DMA requirements;
> the OS developers did not foresee usable and extensible interfaces to
> access and abstract various hardware and just hacked something that it
> would somehow work; and finally the application designers found the whole
> base OS functions where plain unusable and reinvented, each one
> differently, the wheel, leaving burnt ground for others that somehow
> required similar functions - "thou shall not use the printer port for your
> dongle, I have it already."
20-20 hindsight is great, but let's take it from the viewpoint of the
times. There were very many CP/M systems around at the time with
*no* interrupt or DMA support. Remember that the 5150 made extensive
use of peripheral chips that were from the 8-bit world (8237, 8253,
8259, 8255, not to mention the NS8250), so the fact that DMA and an
interrupt controller (with 8 interrupt levels yet) and a timer was
somewhat remarkable considering the competition.
Although the BIOS functions came a long way as the PC evolved, MS-DOS
still ran on a 5150, so the added BIOS functionality couldn't be
The parallel port was designed as a printer port; the fact that it
was used for other things can hardly be blamed on MS-DOS. The
printer port does what it was designed to do extremely well. The
fact that a dongle designer was so short-sighted as to not provide
printer pass-through functionality can hardly be laid on the
designers of the PC.
Personally, I'm surprised the light pen interface wasn't used for