test-drb January 2008

test-drb@ccmp.vtda.org

221 participants
430 discussions

How not to fix a classic mac (or: fried logic boards)

by trag＠io.com

>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: <12318.209.163.133.242.1194974261.squirrel at webmail.io.com> >Content-Type: text/plain;charset=iso-8859-1 > >> 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. Jeff Walther

16 years, 10 months

MC3470

by aek＠bitsavers.org

> Also, does anyone have a proper data sheet for the MC3470 (disk read > amplifier etc). A reasonable description appears in the Semens FD100 service manual. The best analysis of a floppy read channel I have ever read appears here: http://bitsavers.org/pdf/shugart/SA850_450_Read_Channel_Analysis_Dec79.pdf

16 years, 10 months

Simple peer to peer network?

by brain＠jbrain.com

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? Jim

16 years, 10 months

"CP/M compatible" vs. "MS-DOS Compatible" machines?

by ajp166＠bellatlantic.net

> >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> > >Allison schrieb: >>> 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 like? > 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 only 5.5KB? 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 available). 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 them before. 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. :) Allison > >-- >Holger >

16 years, 10 months

Q-BUS primer?

by dave06a＠dunfield.com

Hi Guys, 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 start looking... Three chassis: 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. Regards, Dave -- dave06a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.classiccmp.org/dunfield/index.html

16 years, 10 months

Graphics for S-100 machines (MicroAngelo S-100 Graphics

by marvin＠west.net

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 or so. 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

16 years, 10 months

never knew DOS system files were resettable

by chrism3667＠yahoo.com

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. http://www.yahoo.com/r/hs

16 years, 10 months

"CP/M compatible" vs. "MS-DOS Compatible" machines?

by ajp166＠bellatlantic.net

> >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 there range. 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. Yes straws. 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. Allison

16 years, 10 months

"CP/M compatible" vs. "MS-DOS Compatible" machines?

by cclist＠sydex.com

> 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

16 years, 10 months

MPI floppy drive service manual

by ard＠p850ug1.demon.co.uk

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

16 years, 10 months

← Newer
1
2
3
4
5
6
7
8
...
43
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb January 2008