seth@pro-angmar.UUCP (Seth Itzkan) (08/05/89)
Hi, my Applied Ingenuity 20 meg innerdrive will not work with my laser (mac) drive which uses a Universal Disk Controller. Either drive works fine on their own, but when they are both plugged in to my Apple II/e enhansed, the machine crashes into monitor when I attempt a boot. I have tried putting the controller cards in different slots, yet the problem persists. I have a ZIP chip, yet the slot speeds have not be changed from normal. any ideas? Seth J. Itzkan seth@pro-angmar.cts.com
jlink@pro-xy.UUCP (John Link) (08/06/89)
Network Comment: to #133 by obsolete!pro-angmar!seth%bloom-beacon.mit.edu The UDC controller has a history of problems. I am using one right now, in combination with a SCSI Rev C card, two laser 3.5 drives, and a //e with a TransWarp installed. On the average the UDC/laser drive combination destroys a 3.5 disk every three weeks. other than that, it works "fine."
brianw@microsoft.UUCP (Brian Willoughby) (08/08/89)
In article <8908070320.AA19150@obsolete.UUCP> jlink@pro-xy.UUCP (John Link) writes: > >The UDC controller has a history of problems. I am using one right now, in >combination with a SCSI Rev C card, two laser 3.5 drives, and a //e with a >TransWarp installed. On the average the UDC/laser drive combination destroys >a 3.5 disk every three weeks. other than that, it works "fine." Very interesting. I have had many problems with the UDC also, and I think that I have finally figured out the source of some of them. I would like to hear from anyone with a UDC about their problems, especially if you have a 65C802 OR a TransWarp (or both). I'd like to complain to the makers of the UDC again (I've called Laser already), so I'll describe my experiences and see what any of you can add. The Universal Disk Controller uses the RDY (memory ReaDY) signal on the 65xxx. For what, I have no idea, but I think that it must be during memory writes initiated by the processor. Regardless of why the UDC uses RDY, this causes the controller not to work with all processors. The UDC only works with the 65C02 and 65C816 (or a 65C802 in 16 bit mode) for reasons described below. I now keep my logic probe hooked up to the RDY signal so I can watch any activity, and the UDC is the only peripheral that pulls RDY low. Summary constructed from the Rockwell, NCR, and Western Design Center 65xxx microprocessor product Data Book notes: When the 6502 was designed, RDY was defined as a signal which would stretch a read cycle to be longer than the usual 1 clock cycle transfer. This was intended to allow interfacing to low speed memory or Direct Memory Access, because the processor holds the current address on the bus until RDY returns active (high). For some reason, write cycles caused RDY to be ignored (part of the design). When the 65C02 was designed, the RDY description was changed to occur during all cycles *including* writes. Western Design also treats RDY the same as a 'C02 with their 65C816, but the 65C802 Emulation mode follows the 6502 RDY definition and not the 'C02's. The 'C802 is the only 16 bit processor that is pin compatible with the 6502, so I am guessing that WDC wanted to EXACTLY emulate the 6502 signals in Emulation mode, complete with RDY behaving differently than it does in Native mode. In contrast, the 'C816 always behaves like a 'C02 when responding to RDY inputs. Again, I am guessing that the lack of 'C816 pin compatibility with the 6502 removed any need for exact 6502 signal emulation (just software emulation) with the '816. My reasoning for assuming that the UDC is pulling RDY low during write cycles is based on the fact that the only difference between the RDY signal for the various processors is during a write cycle - reads are handled (or at least defined) identically. I don't have a scope, so all I can do is watch RDY toggle with a logic probe and assume that writes are occurring. After reading through all that data (and surprisingly, all three manufacturers seemed to have copied the same source - aren't they worried about plagiarizing? or is that applicable to data book text?), I understood why the UDC fails. There are still some unanswered questions: The UDC works with the R65C02 on my motherboard, but not with the WDC65C802. With the WDC65C802, I run Copy II Plus disk verify and the UDC crashes into the monitor after a few (less than twenty) block accesses. That is supported by the documentation. However, when the TransWarp is installed, the WDC65C802 mysteriously functions with the UDC, although after the computer heats up (random length of time powered up) the UDC starts returning I/O Errors more and more frequently until it stops working altogether. At that point, powering down doesn't help to reset the UDC into a working state; I have to leave the computer off for a long time before it returns to working with 3.5" disks. But I don't understand why it ever works in the first place, because the TransWarp makes no change to the RDY signal, it simply connects the bus signal directly to the microprocessor. John, I am very curious to hear if you have the 'C802 16 bit option for your TransWarp. Another strange item: the UDC used to support the Apple II Plus, but Laser Computer now claims that only Enhanced //e's and beyond are supported, even though my UDC documentation says it works on the Plus. The Laser tech support guy gave the excuse that Central Point Software designed the card and had Video Technology build them (I know someone who had one and it was a very large card with many chips). Then, after Video Techmology purchased both CPS and Laser, they decided that CPS should be software only and moved the UDC over to be a Laser product. At some point they developed a VLSI chip to handle all but a few of the chip functions. I would like to know why they changed the card in such a way that II Plus support was broken. Obviously, the Enhanced //e and beyond are all 'C02 or 'C816 machines, Apple has released no 'C802 products. Hopefully, this post has been informative to some net readers, but I would like to make a challenge to UDC owners to come up with a patched version of the peripheral ROM that might fix these errors. Upon inspection of the disassembled UDC code, I fould routines to check for a 16 bit proc and, if present, save the current state (i.e. Data Bank Register, Direct Page Pointer, etc) before switching to Bank 0 in Emulation mode. I think that this could be reversed, so that the 'C802 goes to Native mode, and therefore allow the UDC to utilize RDY. The only potential problems would be the stack overrunning into zero page (because the 256 byte stack page is no longer forced) and accidental changing of the register size bits during a PHP PLP instruction sequence. I think that register moves work work the same in 16 bit mode as long as the size bits M and X remain at 8 bit selection. The stack problem could be solved by first determining the maximum UDC stack usage, and then applying one of two fixes: The stack pointer value could be examined and then if it is too close to stack full (TSX == $0100) then either the top of the zero page could be saved and restored, or the top of the stack could be saved off and the stack pointer could be adjusted so that it wouldn't extend below $0100 during maximum stack usage. Also, I haven't been programming the 65C802 long, but I assume that a PLP could potentially set the registers to 16 bit length, which would break the UDC code very quickly, but if one were careful, this could be prevented (I think). A side effect of patching the UDC ROMs (at least for people with a TransWarp AND the Apple 3.5 Drives) could be to take advantage of 2:1 interleave. Currently, the GS SmartPort can read a 2:1 interleave disk faster, but UDC access of the same disk is painfully slow. I am assuming that this is because the GS executes the disk access routines in fast RAM, but the UDC executes from the $Cxxx slot ROM, so its code executes at 1 MHz on both the GS and the TransWarpped II's. I think that a fast RAM based driver for the UDC (which might be difficult to install on my ProDOS II+, but I assume that the driver address pointers could be changed to point to RAM instead of within the $CNxx space) would be able to execute quickly enough to catch the next sector at 2:1, instead of missing it as it does at 1 MHz and waiting for an entire disk revolution. P.S. I've finally found ONE (and only one) reason NOT to buy a WDC65C802 for your Apple II, i.e. if you plan to use a UDC. Otherwise, I highly recommend II programmers to get a 16 bit processor (and The Bytework's 16 bit ORCA Assembler) for your II, II+ or //e. Order direct from Western Design Center (602/962-4545) and support Apple compatible processor technology. Their 4 MHz (TransWarp compatible) WDC65C802 is $17.80, $50 minimum order, though. I just ordered a * 10 MHz * WDC65C802 - so I'm open to any suggestions for getting it to work with my Apple II+ at that high clock rate! Brian Willoughby UUCP: ...!{tikal, sun, uunet, elwood}!microsoft!brianw InterNet: microsoft!brianw@uunet.UU.NET or: microsoft!brianw@Sun.COM Bitnet brianw@microsoft.UUCP
jamesh@pro-colony.cts.com (James Howell) (08/08/89)
Network Comment: to #8675 by microsoft!brianw@uunet.uu.net
Brian,
Thanks for the info. This brings up an interesting question. I have
an Apple //c+. The Smartport is functionally equivelant to the GS smartport.
I have a C802 installed (rus fine at 4MHZ). The problem is with two old style
Disk II drives (actually Tava corp clone drives). These drives work fine with
my II+ through the disk controller card, but when I hang them off the //c+
smartport, I have problems. There are absolutely NO problems reading. I get
write problems about 5% of the time. Sometimes a format will trash a disk,
usually the disk will get trashed when copying a bunch of files, though. Copy
II Plus trashes more disks than the Apple utilities, but they both trash 5.25"
disks. I have been suspecting the IWM chip, but perhaps the Disk II circuitry
in the GS style (not //c style) smartport is doing the same thing as the UDC
card. This would be possible since //c+ come only with C02 parts and the GS
comes only with C816 parts and 6502 emulation is not normal. Perhaps I'll put
the original processsor back in and do some copies to verify this.
You say WDC has 10MHZ 65C802 parts available? Great, I'll need to get
one. I want to swap out the oscillator for a faster one and swap out the two
8K fast SRAMs for faster chips to get up to 10MHZ. How fast do you think the
SRAMs would have to be? Also, who would carry them? Jameco only has down to
100 or 80ns SRAMs of this type. The //c+ already has 100 ns parts. What
would I need at 10MHZ - 45ns? 35ns? Where could I find them?
- Jim (301) 882-6576 (H)
(202) 634-2478 (W)jlink@pro-xy.UUCP (John Link) (08/09/89)
Network Comment: to #203 by obsolete!microsoft!brianw%uunet.uu.net
>about problems with the Universal Drive Controller.
I would say that the UDC never really did support the ][+!! My first
experience with it was running a BBS for a local computer club, on a ][+
loaned by one of the members. We bought the UDC and Chinon drive to save
money. After trying several drives and a total of three UDC cards, and after
the dealer called the company several times, both the dealer and I gave up.
He gave the club back its money, and we got an Apple 3.5 "smart" drive and
their card. It worked flawlessly. The only good thing to come out of the
experience was that I learned how to rebuild blown disks! The combination of
][+, UDC, and Chinon drive was positively vicious. Right now, I am using an
"unenhanced" TransWarp, with an enhanced //e. I have a box of fifty 3.5 inch
disks that I use to "feed" the UDC/Chinon comlbination. I only use it to back
up my BBS hard drive, not for anything else, so it does not get much use. The
friend who loaned pro-xy that part of the setup, had a few, but not (according
to him) frequent "aw-s***ts" of the nature I am having now. I have found
something espeically unique, in that once the UDC eats a disk, it generally
can't be reformatted, by either the UDC/Chinon combination, or on my standard
3.5 'dumb' drive hooked to a //gs. This tendency to utterly destroy disks was
also noted on the ][+/UDC/Chinon combination two years ago.
Our local dealer, who is very knowledgeable, soon quit selling Chinon drives
to Apple // users. Lately, I have not noticed any Chinon drives or UDCs in
his store. He is not the type to stock stuff that gives trouble, no matter
how much money he can make on it. (CPS prices have always been attratactive.)
Rewriting the ROM sounds like a good idea. Central Point said, at the time,
that they were attempting that themselves. But it does not appear they ever
got it done, done correctly, anyway. Glad to hear I am not the only one
having these problems.paul@pro-europa.cts.com (Paul Hutmacher) (08/10/89)
Comment to message from: obsolete!pro-xy!jlink@bloom-beacon.mit.edu (John Link) > The UDC controller has a history of problems. I am using one right now, in > combination with a SCSI Rev C card, two laser 3.5 drives, and a //e with a > TransWarp installed. On the average the UDC/laser drive combination destroys > a 3.5 disk every three weeks. other than that, it works "fine." And I thought I was the only one with a weird UDC. I have tried calling for service or help on it about a year ago and got sympathy but no real help from them. The folks that market it (Video Technologies) refer you to Central Point and Central Point say something like "wow, we don't know -- ours work fine d00d." Right. ______________________________________________________________________________ paul@pro-europa.cts.com | "Open the pod bay door HAL" ...!crash!pnet01!pro-nsfmat!pro-europa!paul | "Sorry Dave, I can't do that"
seth@pro-angmar.UUCP (Seth Itzkan) (08/15/89)
Network Comment: to #2543 by obsolete!pro-xy!jlink%bloom-beacon.mit.edu What exactly do you mean by "destroys" a 3.5 disk every three weeks? I've been getting I/O bad sector errors on block 002 consistantly with almost every disk. Appleworks will still read and write its files, but Copy IIPlus wont be able to handle these bad sector disks.
jlink@pro-xy.UUCP (John Link) (08/16/89)
Network Comment: to #432 by obsolete!pro-angmar!seth%bloom-beacon.mit.edu Seth Itzkan writes: >What exactly do you mean by "destroys" a 3.5 disk (when used by the UDC/Chinon combination on a //e)? The "destruction" is rather complete. There will be at least one block (often block #2) that can't be read by anything, Block Warden, Mr. Fixit, Copy //+, etc. What is unusual (to me at least) is the I will not be able to reformat the disk. The munged block stays forever munged. But it is not "consistent" in the sense that everytime I write to the disk, I get this problem. Just occassionally.
seth@pro-angmar.UUCP (Seth Itzkan) (08/17/89)
Network Comment: to #2857 by obsolete!pro-xy!jlink%bloom-beacon.mit.edu John, I seam to having a similar problem, my laser drive with the UDC appears to be putting bad sectors on my disks. Also, it does not work with my inner drive which I just installed. Do you (or anyone), think I should just bag the whole UDC laser drive sytem for something else? Should I try to get it fixed?
jlink@pro-xy.UUCP (John Link) (08/18/89)
Network Comment: to #527 by obsolete!pro-angmar!seth%bloom-beacon.mit.edu
>Should I bag the whole UDC laser drive system for something else?
The last part of your statement, should I try to get it fixed, appears to be
impossible, as Central Point would fix it, I think, if they could. Part of
the problem is that they can't "copy" anyone else's code, so they have to do
it "on their own," so to speak. I "live" with mine because all they ever do
is back up a hard drive. Since I verify each disk as part of the backup
process, if one gets munged I just do it over on a new disk. The person who
used these drives before I did says he had only a very few problems with them,
but problems he did have...myself, I would not like being forced to use them
as my "everyday" drives. Besides, there is anohter company getting into the
3.5 drive business, and ther drives (according to the ads) work correctly with
Apple's standard interfaces, ie, the //gs serial port, and perhaps the 3.5
inch drive card (can't remember on the latter.) Yes, I would "bag" them,
unless you havef a limited use for them, where YOU can recover easily from the
occassional bad disk they will create.brianw@microsoft.UUCP (Brian Willoughby) (08/19/89)
In article <8908171728.AA27197@obsolete.UUCP> seth@pro-angmar.UUCP (Seth Itzkan) writes: >Network Comment: to #2857 by obsolete!pro-xy!jlink%bloom-beacon.mit.edu > >John, >I seam to having a similar problem, my laser drive with the UDC appears to >be putting bad sectors on my disks. Also, it does not work with my inner >drive which I just installed. In a quick summary of my problems, the UDC stops interfacing with the drive after a period of use. If you happen to be writing to the disk at that time, then what is written to the disk is garbage. If all of us are having problems, then why don't we all call Laser? (I know it costs money to call, but so does buying a new controller) Laser tried to say it was my Apple II Plus (which they "don't support"), but it seems that everyone's problems are machine independant. Laser also claimed that they don't handle the UDC design, Video Technology does. Anyone have their number? How about if everyone who is having trouble with their UDC send me mail detailing thier machine type, processor and list of peripherals used at the same time as the UDC. I'm interested in Apple, Laser and other clones, 6502, 65C02, 65C802, 65C816 procs, and cards like the TransWarp and/or other disk storage peripherals like the InnerDrive. A little data on how many errors are occurring over a period of use (try Copy II Plus disk verify) would also be welcome evidence. I think I have isolated my problems to be related to the UDC's use of the RDY signal (which perhaps the InnerDrive uses?), and its interaction with my 65C802, but I don't think the problems that everyone else is having is limited to the same conditions. > >Do you (or anyone), think I should just bag the whole UDC laser drive sytem >for something else? Should I try to get it fixed? I would like to find "something else" to replace the UDC, but I don't think anything exists. It's not that the technology is too difficult or anything. IMHO, getting the UDC fixed would have to entail a redesign of UDCs use of the Apple bus or at least a ROM re-write, followed by a warrenty fix from Laser or Video Technology. The UniDisk is unacceptable, because I already have two Apple 3.5 Drives, and besides, I wouldn't be happy upgrading to a GS with only UniDisks. Why doesn't Apple offer something like the UniDisk card for the non-GS CPUs, but which is more up to date and handles all SmartPort interface drives? I usually stick to Apple Co. products (like my drives), but they are getting beat in the interface arena. Brian Willoughby UUCP: ...!{tikal, sun, uunet, elwood}!microsoft!brianw InterNet: microsoft!brianw@uunet.UU.NET or: microsoft!brianw@Sun.COM Bitnet brianw@microsoft.UUCP