CMDSENPG@UIAMVS.BITNET (Steven Nelson) (08/22/89)
Several messages have commented on problems with the Universal Disk controller (UDC) and 3.5" drives. As I currently use 3 UDC's on three different Apple computers, I want to share my observations. I have learned one important fact about the UDC which is NOT mentioned in its scant documentation. The UDC does NOT initialize correctly unless booted , or at least attempted to be booted. On one of my systems, I prefer to boot from my Sider (slot 7) into ProDOS and Davex command shell. Then I 'boot -s5' to init the UDC in slot five (no disks in either Laser drive). Failure to boot will cause the UDC to return to the Applesoft basic prompt. I call -151 to get into the monitor, then ctrl-Y to return to Davex. After that I seem to be able to use the UDC reliably, but if I forget to 'boot' it, I'll most certainly destroy a block on occasion. However, properly init'ing seems to make the UDC behave 99%+ of the time. Old 400k drives from the Mac also seem to work if I boot from them, but will fail very often if I access them without trying to boot the UDC. Incidently, I use the 400k drives and UDC with a Apple II+. My other 2 UDC's and Laser 800k drives are used in enhanced IIe's - one with a Zip chip. The UDC slot MUST be set to 1Mhz (normal) speed. The UDC will read at the fast chip speed but will not write correctly. I don't know what to think about the claims that the UDC does not work with the Apple II+. I'm quite satisfied with my UDC's now that I know how to 'boot' them! At least on II+'s and IIe's.
brianw@microsoft.UUCP (Brian Willoughby) (08/25/89)
In article <8908220011.aa16711@SMOKE.BRL.MIL> CMDSENPG@UIAMVS.BITNET (Steven Nelson) writes: >Several messages have commented on problems with the Universal Disk controller >(UDC) and 3.5" drives. As I currently use 3 UDC's on three different >Apple computers, I want to share my observations. I have learned one >important fact about the UDC which is NOT mentioned in its scant >documentation. The UDC does NOT initialize correctly unless booted >, or at least attempted to be booted. First of all, in my version of the UDC ROM code (yours may be older), the init code is called the first time the UDC is used - whether by booting or through ProDOS or SmartPort accesses. They use a "power-up" flag, similar to the Monitor's PWREDUP bytes at $3F2-$3F4. They store the slot*16 at address $CABC and EOR #$A5 (er somethin') and store that byte at $CABD. Every call to the UDC checks for this, and runs some init code if it hasn't yet. Learning this has helped me a great deal, because when it acts up, I can usually zero those locations (after enabling the $C800 space for that slot) and "re-init" the drive on the next call. Sometimes it won't boot unless I do that, or I have to power down long enough for the CMOS to die. But... I always boot from the UDC when I use it. The whole reason I got the 3.5 drives was to support ORCA/M and their Small C. An 800K disk is the only thing (short of a hard disk) that allows all the libraries to be online at the same time. Also, now that I know I will get write errors, I take advantage of the fact that system files are read-only and place them on the 3.5 boot disk. I don't doubt that you have better results when the UDC is booted, but I always boot the UDC and STILL have mondo problemo. Maybe Video Technology added some code, which isn't fully debugged yet. See desciption of different drive types below. > if I forget to 'boot' it, I'll most certainly >destroy a block on occasion. However, properly init'ing seems to >make the UDC behave 99%+ of the time. It's that 1% that bothers me. Actually, I get 0% bahavior after my CPU heats up. I tried replacing all my motherboard 74LS138 chips which decode the slot address space (thamks to AE for that suggestion, I had called them because I also use their TransWarp, 65C802 option, with the UDC), but that had no effect. All my debugging of this problem seems to be in vain, now that I've read the docs for the 6502, C02 and C802 and find that RDY is not responded to in the same manner by all those chips, and the UDC utilizes RDY for transferring disk sector info to the Apple. Just hook a logic probe up to the slot bus and watch RDY. I don't see how the NEW UDC (the old UDC was much different, and DID support the II+) can work with a 6502 or 65C802 in Emulation mode (which the UDC forces every time you use the drive). A side note: when I plug my W65C802 directly into the motherboard (which is where it lived before I bought the TransWarp), the UDC crashes without fail, even when the computer hasn't "warmed up". This is supported by the documentation of how the C802 Emulates the 6502 in ignoring RDY during a write. My question is: why does it work when plugged into the TransWarp? The RDY line is just directly connected to the C802, no intervening logic to change the signal. This is where my problems show up. Something about the TransWarp (perhaps that it makes a II+ look almost like a //e from software?) allows the UDC to work with the C802, but only until the computer warms up (and then powering down won't help revive the UDC, unless I leave it off an hour or more). I must admit that I haven't dusted off the original 6502 and tried it, but judging from the data sheets on the 6502, it shouldn't work any better than the C802 on the motherboard. At least not with a version of the UDC which utilizes the RDY signal. > Old 400k drives from the Mac >also seem to work if I boot from them, but will fail very often if >I access them without trying to boot the UDC. Incidently, I use the >400k drives and UDC with a Apple II+. My other 2 UDC's and Laser 800k >drives are used in enhanced IIe's - one with a Zip chip. The UDC slot >MUST be set to 1Mhz (normal) speed. The UDC will read at the fast >chip speed but will not write correctly. > I think the difference in performance in due to the drives used. I use Apple 3.5 Drives, and they transfer data much faster than the old Apple Macintosh 800L External drive that I used to use. I'm making a guess here, but I would assume that the difference in access between the drives means that different code is being executed. Perhaps there are bugs in the code when handling newer SmartPort drives like the Apple 3.5, but the old Mac 400K access code is fine. The only problem with this theory is that I also had problems with the Mac 800K that were identical to the Apple 3.5 troubles. >I don't know what to think about the claims that the UDC does not work >with the Apple II+. I'm quite satisfied with my UDC's now that I know >how to 'boot' them! At least on II+'s and IIe's. Do you have a 65C02 in your II+? What version of the UDC card do you have? My UDC uses the RDY signal which is not consistent between the different versions of the 6502 (i.e. writes are not supported on the 6502 or W65C802 Emulation mode). Does anyone have an Apple 3.5 Drive on a II+ with a UDC? There are a lot of intelligent folks on this net, and if any of you are having the same problems I am, then maybe we can figure this one out. Actually, I doubt that many of you have a II+, UDC AND a TransWarp WITH the 65C802 exaclty like my setup, but if you've read this far then maybe I'm in luck. If you have the newer UDC, print out the ROM code and see if you can figure out where these errors are occurring. I have been scanning it for weeks myself, and the only errors I found were due my lack of experience with the 65C802 (i.e. they weren't bugs, I was reading the code wrong). Here's a hint for the diehards, the UDC has 8 banks of ROM, and here is how to select one: Action: From Monitor: Read $C088+SLOT*16 *C0D8 Read $C08D+SLOT*16 *C0DD Write to $C08D+SLOT*16 *C0DD:n0 where n is the Bank number, three bits of the command byte written to C08D of the form 0bbb0000, where 'b' is the binary Bank number You can directly print the Bank data (if you can disassemble 65C802 code to the printer), or just copy the Bank to disk for later viewing/printing. I don't really expect anyone to do this, but if I'm not the only one having troubles, then several people stand to gain from some kind of solution. Brian Willoughby UUCP: ...!{tikal, sun, uunet, elwood}!microsoft!brianw InterNet: microsoft!brianw@uunet.UU.NET or: microsoft!brianw@Sun.COM Bitnet brianw@microsoft.UUCP
jac@paul.rutgers.edu (Jonathan A. Chandross) (08/26/89)
brianw@microsoft.UUCP (Brian Willoughby) describes his experience with the UDC: > It's that 1% that bothers me. Actually, I get 0% bahavior after my CPU > heats up. I tried replacing all my motherboard 74LS138 chips which > .... > and the UDC utilizes RDY for transferring disk sector info to the Apple. > Just hook a logic probe up to the slot bus and watch RDY. I don't see > how the NEW UDC (the old UDC was much different, and DID support the II+) > can work with a 6502 or 65C802 in Emulation mode (which the UDC forces > every time you use the drive). I don't have a UDC, but from your description I think I know what might be causing the problem. If I understand correctly, the UDC disables the on-board 6502 using RDY and uses DMA to store the result of a disk operation directly into memory. The problem might be slow motherboard DRAM. I've run into this problem on other computers. As the DRAM warms up, it's access speed slows down. If the speed was marginal before (ie the DRAM was just fast enough to work) you will start seeing some flakiness. Don't forget that you lose some memory bandwidth to the refresh circuitry. This couple with slow chips might just be enough to cause the strange behavior you cite. Jonathan A. Chandross Internet: jac@paul.rutgers.edu UUCP: rutgers!paul.rutgers.edu!jac
kodali@portia.Stanford.EDU (VAS KODALI) (08/26/89)
In article brianw@microsoft.UUCP (Brian Willoughby) writes: >In article CMDSENPG@UIAMVS.BITNET (Steven Nelson) writes: ]Several messages have commented on problems with the Universal Disk controller Okay, here is my experiences with the UDC I currently possess: I have a Unidisk 3.5, a Central Point (Laser) 3.5, a disk ][, and a half height 5.25, and a ][+ o I can't boot off of the laser 3.5, but it does recognize it if it is in drive 2 o I can boot off the Unidisk, and it likes it as drive 2 also. o With either the laser 3.5 or either one of the 5.25 daisy chained off of the unidisk, it takes the unidisk out of the chain (doesn't recognize it) but it does see what is 'behind' the unidisk. o I tried dropping a 65C02 into the ][+, but it didn't like it (cps multi card, SSC, UDC, floppy controller, EPROM burner, I would have been surprised if it did work.) o It doesn't work in my clone //e, but that's hardly suprising as it dislikes parallel cards as well. o If I boot from either the floppy controller card or the hard disk into Prodos, prodos will recognize everything on the UDC. It hasn't eaten disks yet, but I haven't used it that much. o I have no idea as to the version of the UDC, as there are no version #'s on the card, and the EPROM is uncovered. (c) is 1986, if that helps. Well, these be my observations. --Chan kodali@portia.stanford.edu (Brian, what happened to the FP code you were sending me??)
brianw@microsoft.UUCP (Brian Willoughby) (08/28/89)
In article <Aug.25.16.37.14.1989.11832@paul.rutgers.edu> jac@paul.rutgers.edu (Jonathan A. Chandross) writes: >I don't have a UDC, but from your description I think I know what >might be causing the problem. If I understand correctly, the UDC >disables the on-board 6502 using RDY and uses DMA to store the >result of a disk operation directly into memory. > Small correction: the DMA signal is not used - I have monitored the bus and it doesn't go active (low). Of course, it isn't incorrect to refer to the use of RDY as "DMA", because Direct Memory Access is what is happening, but I just didn't want any confusion about the actual DMA signal on the Apple Bus. Besides, I have a TransWarp, and I can't seem to get Applied Engineering to say whether or not it supports DMA accesses to its on-board RAM. I also haven't gotten any response on whether the TransWarp uses DMA when it is writing to motherboard video RAM. But, from observation, none of my peripherals use DMA. >The problem might be slow motherboard DRAM. I've run into this >problem on other computers. As the DRAM warms up, it's access >speed slows down. If the speed was marginal before (ie the DRAM >was just fast enough to work) you will start seeing some flakiness. > Thanks, that's a good idea. But, for me, I'll have to check on the speed of the TransWarp card RAM, because my problems occur whenever the TransWarp is active. Again (and I'm only re-iterating this in the hopes that someone else might have a few ideas), the W65C802 *ignores* RDY during a write when it is executing in Emulation mode. This "feature" causes the UDC to crash in a very repeatable way when I place the C802 on my II Plus motherboard (without the TransWarp active), because the UDC makes sure that the C802 is in Emulation mode. I've basically accepted that it is impossible to use a 6502 or W65C802 on the II Plus motherboard with the UDC (although reports from this net seem to indicate that some versions of the UDC function with this configuration), because this behavior matches the documentation on the processors. The TransWarp, however, throws a monkey wrench into my theories. Somehow, the UDC works with the W65C802 on my TransWarp card, but only until the computer heats up (I know I'm repeating myself, but bear with me :-). For this combination to function, the UDC *must* be switching the C802 into Native mode, where RDY *is* functional during a write. The only difference I can find between the C802 crashing (on the II Plus motherboard) and executing properly (on the TransWarp) is that the TransWarp adds a few //e features to my II Plus that aren't available without the TransWarp. This includes 128K of RAM (main and aux) and the alternate zero page and stack features. I *assume* that the UDC ROM code is recognising the differences with the TransWarp active, and deciding to put the C802 in Native mode before using the RDY signal. To make my point (finally, you're saying :-) I HAVE NOT FOUND THE LOCATION IN THE UDC ROM CODE WHICH ALLOWS THE C802 TO FUNCTION WITH RDY. I also have not figured out why this magical feature disappears after extended use. Any ideas at all are welcome, and if any UDC owner is fatally curious enough to read through all the ROM code, then let me know what you find. >Don't forget that you lose some memory bandwidth to the refresh >circuitry. This couple with slow chips might just be enough to >cause the strange behavior you cite. > We're talking about a II Plus here: motherboard RAM is not slowed by refresh, because video accesses accomplish refresh, and DMA is only allowed during CPU cycles (can't conflict with video). Refresh may be a problem with the TransWarp card RAM, however. Too bad AE or Video Technology doesn't have anyone listening to this group (and responding, that is). > >Jonathan A. Chandross Brian Willoughby UUCP: ...!{tikal, sun, uunet, elwood}!microsoft!brianw InterNet: microsoft!brianw@uunet.UU.NET or: microsoft!brianw@Sun.COM Bitnet brianw@microsoft.UUCP
brisinda@cpsc.ucalgary.ca (Dale Brisinda) (08/29/89)
Reply-To: brianw@microsoft.UUCP (Brian Willoughby) >again (and I'm only re-iterating this in the hopes that someone else >might have a few ideas), the W65C802 *ignores* RDY during a write when it >is executing in Emulation mode. This "feature" causes the UDC to crash >in a very repeatable way when I place the C802 on my II Plus motherboard >(without the TransWarp active), because the UDC makes sure that the C802 >is in Emulation mode. I've basically accepted that it is impossible to >use a 6502 or W65C802 on the II Plus motherboard with the UDC (although >reports from this net seem to indicate that some versions of the UDC Brian i have a //e and and udc and a laser 3.5. I was thinking of installing a 65802 in my computer, but after reading your message i'm not sure if i should bother. It seems that if your //+ works when the 802 is in the transwarp that it will work on my //e pluged in the motherboard. What do you think???