>
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
> From: Roger Ivie <rivie at ridgenet.net>
> Date: Fri, 01 Feb 2008 08:05:02 -0800 (PST)
> To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org>
>
>On Fri, 1 Feb 2008, Allison wrote:
>>
>> Done right it was portable. However I encounterd at least one system
>> where the BIOS calls were unusuable for 8bit serial because every
>> transaction in or out was masked with 07Fh..
>
>Which is consistent with the manual:
>
>"All simple character I/O operations are assumed to be performed in
>ASCII, upper- and lower-case, with high-order (parity bit) set to zero."
>
>(from the section 6 of the CP/M 2.2 manual)
It is sorta.. Parity may not be a visible bit if the terminal is
set for 8P1, the manual would imply the required serial format is
7S1 or 7S2 which may be for TTY but not always.
The manual is at best obscure on that. ;)
My implmentations had two serial drivers TTY (masked to 7bit)
and CRT not masked. Add to that printer (DEC LA100) serial 8bit
and modem 8bit I used the high and low bits of IObyte usefully.
Allison
>--
>roger ivie
>rivie at ridgenet.net
> 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).
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").
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.
Cheers,
Chuck
Have a look at:
http://www.baltissen.org/newhtm/cbmhd.htm
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).
mike
---------------------------------------------------------------------------------------------
Message: 12
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.
Thanks,
-ethan
--
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.
Cheers,
Chuck
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.
>
> Zane
>
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
do list.
Hi,
I see that you have the manual for science fair 200 in 1 from radio shack.
It would be great if I could get a copy of this manual.
I would like to use this system with my students. We have the machine,
however, the manual is missing.
Thank you,
sdenkin at bayridgeprep.org
Hey folks...I've got an otherwise-pristine Commodore 1702 monitor
that is missing the little front door that covers the controls. Does
anyone have one of those doors that they can spare, perhaps from a
junker 1702? I'd really like to make this one perfect.
Thanks,
-Dave
--
Dave McGuire
Port Charlotte, FL
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.?
Regards
Axel Harten.
> Date: Thu, 31 Jan 2008 23:04:55 +0000 (GMT)
> From: Tony
> IIRC, while the MDA card had a light pen connector, it was never really
> documented or supported by IBM, due to the fact that light pens didn't
> work properly with the very long persisnence phosphor of the 5151
> monitor. The CGA card's light pen connector was docuemtned, though
> (although I have never seen a light pen designed to work with it
I've got a light pen that was salvaged from some 60's era graphics
equipment. This is the kind with the fiber optic tip and a
microswitch that determines when the tip is depressed. Has some
discrete circuitry in it (probably an amplifier, pulse shaper, etc.)
and works just fine with the MDA/CGA/EGA cards. About the diameter
of a felt tip marker (ca. 3/4"). I once used it with a monitor with
a short-persistance white phosphor. It wasn't bad; just couldn't
think of a good application for it. I've got a VGA card here
(Paradise I think) that also has the connector, but it's hooked to an
LCD monitor, so that's not going to work very well--but does give
another reason to hang onto CRT displays.
Cheers,
Chuck