>Date: Tue, 13 Nov 2007 11:17:41 -0600 (CST)
>From: "Jeff Walther" <trag at io.com>
>Subject: Re: How not to fix a classic mac (or: fried logic boards)
>To: cctech at classiccmp.org
>Message-ID: <123126.96.36.199.242.1194974261.squirrel at webmail.io.com>
>> Date: Mon, 12 Nov 2007 22:45:09 -0800
>> From: Josh Dersch <derschjo at msu.edu>
>> First point of business, I discharged the CRT.
>> To the main chassis. This, as I have now discovered, is not what you
>> are supposed to do to discharge the CRT unless you want to destroy the
>> logic board.
>That particular failure is documented in Larry Pina's "Macintosh Repair
>and Upgrade Secrets" and probably in "The Dead Mac Scrolls" as well. I'd
>look it up for you, but I don't have my books with me here.
Okay, I'm home, I have my books. It says on page 98 that
discharging the CRT without a big honking resistor may blow a 74LS38N
(U2) on the analog board and the LAG chip on the logic board. The
former sounds like it might be fairly standard. The latter sounds
like it may be one of the custom programmed PALs or GALs or whatever
that Tony was writing about.
I wouldn't be surprised if folks had already figured out all the
internal logic for the various Mac 128/512/Plus chips though.
Finding it might be a bit of a challenge.
OTOH, the LAG chip may be fine and it could be U2 on the analog board
that has the problem.
Sellam wants to finish the 64 c64 cluster for the next VCF. I've been
researching ideas for communicating among the machines, and the best
ideas point to using the two synchronous serial ports on the user port
(low wire count, transfers at 250kbps).
But, I have grawn a complete blank on plans for a true peer to peer
(token based or otherwise) networking protocol. Everything I see is
master/slave. RS485 material talks about the hardware layer, but there
is no detail on the protocol layer.
I would think this would be a well researched and innovated area, low
speed communication without a master node. Anyone have any pointers for
things to look into?
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
> From: Holger Veit <holger.veit at iais.fraunhofer.de>
> Date: Thu, 31 Jan 2008 09:53:03 +0100
> To: General Discussion: On-Topic Posts Only <cctech at classiccmp.org>
>>> 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.
>Termcap was very needed, but not present. Net result was that almost any
>software that required terminal control beyond backspace and CRLF had to
>be tweaked manually.
IN that sense yes. Is it requried of the OS no. Does the OS need it, no.
CP/M was minimal as it's day ram was expensive interms of cost, power
and space. Was it short sighted, yes. Would it have been implmented
right in 1975? No as terminals were just starting to have basic
intelligence and maybe 2-3 years later what would the requirements be
> I remember having written code to fit in the
>Wordstar patch area to adapt to some obscure or not so obscure terminal
>dozens of times. Termcap and terminfo under the various Unixes of the
>time was god-sent then even if some entries were plainly buggy - maybe
>just estimated from some hear-say information.
Many others too like Vedit. It was a one time task, not nice but compact.
Whats more interesting is there was nothing to prevent a termcap file
and later improved CP/M work alikes did exactly that and many more things.
The bottom line is sans BIOS where do you put termcap in a OS thats
As to unix, it was the big machine OS and was not going to run
on a 256kb floppy. It was only popular in academic and research
and far from mainstream till the mid 80s.
>The print string BDOS function was indeed an example that was almost
>immediately replaced by do-it-yourself routines, often by using the '\0'
>delimiter (which then caused trouble with slow terminals that require
>some delaying NUL bytes after a CRLF).
Or the +80H (end of line on high bit set).
>> 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.
>IO byte, besides as you correctly remarked not being implemented at all,
>was outdated soon after CP/M was released for the Altair. I haven't seen
>many paper tape readers and punches connected to CP/M systems for
>serious business work. IObyte did not take care of additional devices
>beyond the 4 standard devices; it did not deal well with additional
>serial or parallel ports for more terminals and printers. This resulted
>in unofficial BIOS extensions to get such available hardware into the
>boat, and again unportable programs to swap vectors in to BIOS to write
>output to a second printer, for instance. Needless to say that
>"well-written" software to use the IOByte failed to use these additional
>devices - there was even software that insisted that PTP is dumb and AUX
>is intelligent, so abusing these pseudo devices for two printers
>resulted in different behaviour.
Paper tape and Punch were rare in most CP/M systems and often unimplmented.
I tend to implment the console and list fields (upper and lower two bits)
completes to use the printer ports and second (and third serial if
Andy Johnson-Laird The Programmers CP/M Handbook went far to extend
and clarify both what the BIOS can do and more.
>> 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.
>Since the BIOS reduced the available space for BDOS and TPA - which
>admittedly improved with CP/M+, which, however, IMHO came too late -
>many vendors came up with a not so elaborate BIOS but rather tweaked the
>sample code from DRI. It was plainly easier to add some custom program
>to directly hack the non standard hardware than extend the BIOS with
>useful, clever and portable features. What has been the GHz mania of the
>processor later was at that time the "xxK TPA available" selling argument.
Actually I'm running system with CP/M-V2.2 that page the BIOS and
have multiple hard disks and a tpa in the 62-63k range. CP/M+ is not
required to achive that. But both approaches need some kind of memory
paging and the ram/rom and a BIOS to support it.
The otehr issue is most developers didn't have a useful system
interrupts or were time pressed enough to feel that it was worth it.
By useful interrupts I mean.. most early S100 8080 machine if you
pulled the interupt line the default was vector to 38H as that was
RST7 (11111111b) which happend as a result of pull up resistors.
that location is ued by DDT for trap. Early Z80s also did that.
later 8080/8085 and Z80 systems implmented basic vectored interrupts
so how you could use RST 2 through 6 and that meant resonable
interrupt drivers wer possible. The Z80 SBCs like Ampro and others
that used the Z80 peripherals all had the Z80 vectored system which
was powerful and a bit intimidating to those that hand not used
As you can se the whole interrupt thing was not CP/M as a limiting
factor but hardware or implementor understanding.
For those that never used a really nice bios try a VT180, it didn't
do two sided but those disks where just emerging at the time. It did
implement interrupts with ring buffers for IO.
The other thing was DMA. On S100 is was a timing and bus nightmare
and took years to almost get right. Many of the single baord systems
omitted it as it took space (8257 or later 8237 40 pin chips and a latch).
It works fine and made useful systems. However it means the CPU is locked
up for the duration of the transfer and cannot respond to interupts
making for poor latency as floppies are slow. Again CP/M doesn't care
how the transfer happens only that it does happen. So the fist system
built with DMA was a real eye opener. First it allowed background
activities to run faster and smoother like a line printer spooler.
also interrupts could be used byy the disk system to say "ready"
or "ready with error". Thats a lot of available CPU cycles.
the biggest areas of change is that modem programs werent pausing
for disk IO, they could fill a big (say 16k) circular buffer and
the cpu can be processing interrupts for IO and disk to manage
transfers rather than doing a lot of waiting in loops. It doesn't
take a lot more code but the complexity and debugging is greater
due to the near concurrent activities.
>>> 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.
>CP/M-86 and MS DOS were initially designed to allow a simple 8080->8086
>cross translator to run the whole set of already existing CP/M
>applications without reinventing the wheel. Later DOS versions added
>Xenix compatible calls (equivalents of Unix raw I/O: open, close, read,
>write, lseek, unlink) but often still the well-understood FCB crap was
>used. The call to TPA:0005 is still present in contemporary MS-DOS
>versions, as well as INT21h calls;
Thats what I believe in too for dos.
>however today the "DOS box" under Windows just prepares the environment
>for such old DOS programs and uses virtualization to fake an existing
>DOS. You can't trace an INT21h call any longer into an MSDOS.SYS or IO.SYS.
Yes thats true after NT flavored took over (NT, Win2k XP and likely vista).
for win 3.1x it was dos with gui and for Win9x dos was very much there.
I ahve Dos7 and dos8 which is extractable from win9x. Nothing worth
reporting there. :)
Recently acquired a goodly amount of DEC gear - I had put the Q-BUS
stuff aside while I got the "all in one" VAXstation/VAXservers up and
running, but I'm starting to collect information - I've no experience
whatsoever with Q-bus, but from what I've read, I understand that it
will take a bit of research to determine how to properly configure
and position the boards.
I'm hoping that I have enough material to built up at least one
(possibly 2) nice little PDP-11's, and/or a MicroVax II)
At this point, all I'm really looking for is a good "starting point".
Can anyone recomment a good document/resources for a Q-bus newbie?
Btw, this is what I've got - If there's anything I'm obviously missing,
or will have to find extra parts for, please advise me so that I can
BA-23: complete with outer shell and end caps. It bears a
"MicroVAX II" label on the console switch panel, and has a
floppy drive (dual disk) installed in it.
I don't know the model numbers for the next two:
- One looks like a BA32 but smaller, and has the "3-switch" PDP
console/display panel on it. The cards are inserted from the
front beside the panel.
- The last one is the smallest, looks much like the one above,
complete with 3-switch console/display panel, however instead
of metal side/top/bottom plates, it has a "wire cage". It also
has a second expansion chassis of similar construction with no
power supply or console panel.
I've got the following DEC Q-BUS cards:
(Descriptions taken from the "Field Guide to Q-BUS and Unbus modules"
M3106 4-line async
M7264 11/03 processor with 4-Kword RAM
M7504 Ethernet adapter (older DEQNA)
M7546 TMSCP controller for TK50
M7555 Winchester and floppy disk controller
M7606 MicroVAX II KA630
M7608 x2 2/4 MB RAM (boards are fully populated)
M7940 x2 SLU Module
M7944 x3 4-Kword RAM
M7946 x2 RX01 floppy disk controller
M8043 x2 4-SLU peripheral interface
M8044DB x2 32Kword RAM
M8044DF x2 32Kword RAM
M8047 RAM, Async, ROMs
M8186 11/23 CPU
M9047 Grant continuity
M9400YA 120-ohm terminators with refresh & floppy boot
M9400YE Headers and 250 Ohm resistors
I've also got the following third party cards - I don't know
anything about these, other than the identifying marks found
on the boards listed below - if anyone can provide more
information on these, that would be helpful: (Several of them
appear to be media controllers of one sort or another).
Andromedia Systems UDC-11 rev H (50 pin connector at front edge)
Micro Technology Inc. MSV05B (x2) (50 pin connector at front edge)
TD Systems TDL-11H/A (50 pin connwctor at front edge)
Xylogics "Wizard 1" (50 pin connector at front edge)
SDC-RXVZ1 "8202 FD Controller" (50 pin connector at front edge)
Versatec LSI-11 P/P Interface (40 pin connector at front edge)
Sigma Information Systems Assy 40100
- This board has one 40 + one 50 pin connector, and a place to
populate another 40 pin - none are at the front edge.
W951 "Flip Chip"
- This board has places for various sized chips (most of them populated)
with pins to wire-wrap connections between them - looks like some sort
of prototyping board.
+ A couple of the little grant continuity boards.
I don't expect this to be a short journy, but it should be interesting...
Thanks in advance for any advice/tips.
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
Congratulations on the selling price of the MicroAngelo board!!!
I did take a look at the bidders and it appears that at least the winning bidder
had just registered on Ebay a week ago and had a bidding war with another person
who, by their feedback, looks like they had been a member for a while. If that
bidding war had not taken place, it would have probably sold in the $30.00 range
At least you know how much someone is willing to pay for one of these if you
list another one :)!
> From: "Robert Stek" <robert.stek at gmail.com>
> No one was more surprised than me at the selling price - and I'm the one who
> sold it! I was expecting maybe $20 - $30. I think I even have another one,
> but I haven't found it yet. Anyway, it was a nice surprise and will mean
> some extra money for Xmas.
> Bob Stek
> Saver of Lost Sols
is there any way to make these visible? I'm trying to
do something funky, and for some reason XP won't
*visualize* the hidden files on a boot disk
(bootdisk.com). I tried unhiding them with attrib, but
it tells me uh uh. What to do? Yes I did change my
folder option to display hidden files, but to no avail.
Never miss a thing. Make Yahoo your home page.
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
> From: Jim Battle <frustum at pacbell.net>
> Date: Thu, 31 Jan 2008 02:01:43 -0600
> To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
>Holger Veit wrote:
>> The interrupt and DMA handling was also lousy thanks to DR abusing some
>> 8080 and even worse Z80 RST vector locations for the BDOS and CCP
>> buffers and FCBs. ...
>That is one thing I always wondered about. CP/M has "CALL 0005H" as the
>BIOS entry point. Why didn't they map it to 0008H instead? Considering
>that code space was at a premium, saving two bytes off of every BIOS
>call would have been an obvious optimization, I would have thought.
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.
Generally it's a non-issue and easy to work with.
>On the other hand, I never wrote any 8080 code that used RST, so maybe
>there is some gotcha that I don't know about.
No it's a one byte call to 8 canned locations in the bottom of ram.
RST0 is to 0000h (warm boot)
(locations 0000-0007 are used by cpm)
RST1 is to 0008h (nothing there)
RST2 is to 0010h
RST3 is to 0018h
RST4 is to 0020h
RST5 is to 0028h
RST6 is to 0030h
RST7 is to 0038h (used by DDT as trap)
None of the 8085 hardware RSTx.5 or Trap interrupt
lines conflict with anything as they fall i the nothing
Z80 NMI lands at 66h which is in the default
FCB/DMA area that goes from 005Ch to 00FFh
>Anyone have opinions why it was done with CALL 0005H instead?
It's explicit either works but only one allows coding to look like:
Call BDOS ; Bdos defined as 0005h
which reads easier than
RST5 ; call location 005
>The only thing I can come up with is that DR might have entertained,
>early on, making CP/M relocatable to different addresses (eg, some
>vendor wants an OS that lives in high memory). In the process of
>patching all the code for the high addresses, substituting "CALL 0FF05H"
>instead of "CALL 0005H" is trivial, but substituting "CALL 0FF05H" for
>"RST 1" would be a problem. Yes, one could require such systems to have
>a "ORG 0005H / JMP 0FF05H" vector. I'm grasping at straws here.
CP/M loads to the last typically 8k of high ram and sparsely uses the
first 256byte page as a system area. Everything inbetween is open land
but CP/M convention is executables start at 100H and have space that can
continue as high as the start of the BIOS (if you need cold boot) or 3.5K
lower if you need BDOS services. The CCP is considered overlayable.
> 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.
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
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.
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)
I am looking for a servicv manual for this drive, in particular
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
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.