Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!microsoft!brianw
From: brianw@microsoft.UUCP (Brian Willoughby)
Newsgroups: comp.sys.apple
Subject: Re: UDC problems
Summary: Still I have problems
Message-ID: <7500@microsoft.UUCP>
Date: 25 Aug 89 05:02:23 GMT
References: <8908220011.aa16711@SMOKE.BRL.MIL>
Reply-To: brianw@microsoft.UUCP (Brian Willoughby)
Organization: Microsoft Corp., Redmond WA
Lines: 123

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