Path: utzoo!utgpu!watmath!att!dptg!rutgers!cs.utexas.edu!uunet!microsoft!brianw From: brianw@microsoft.UUCP (Brian Willoughby) Newsgroups: comp.sys.apple Subject: Re: Using innerdrive with a laser UDC drive (long) Summary: Call for report of UDC problems, and suggested fixes Keywords: UDC TransWarp RDY 65C802 CPS Video Technology Message-ID: <7283@microsoft.UUCP> Date: 8 Aug 89 04:11:05 GMT References: <8908070320.AA19150@obsolete.UUCP> Reply-To: brianw@microsoft.UUCP (Brian Willoughby) Organization: Microsoft Corp., Redmond WA Lines: 132 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