[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Apple II 3.5" Controller and SuperDrive problems...
In article <1d5hs41.1qhkp6x1jclplvN@dempson.actrix.gen.nz>,
dempson@actrix.gen.nz (David Empson) writes:
> <mkelsey@spam.eecs.wsu.edu> wrote:
>
> This might work, but I haven't investigated closely, so I can't be sure.
I intend to test this theory out. I believe this would be a safe means
for Apple to have ensured that a //e user's disk wouldn't be trapped in
the drive and force the user to eject the disk manually. It would make
sense as to why the "Apple 3.5" Drive" pin was needed.
I'm just guessing at this, but I believe that the mainboard on the inside
of the drive housing is actually a bridge between the 800K or SuperDrive
to enable drive eject and designate the drive as an Apple II viable
drive. Again, this is just a theory that I hope to prove correct
later on.
One thing that Apple II 3.5" Drive controller states in the manual is
that it is equipped with a 6502 and the SIWM chipset. The Macintosh
(older models) had at least the SIWM chipset on board. Granted, the
operating system handled disk inject/eject sequences, but it leads me
to believe that in all reality, the mainboard underlying the drive in
the IIgs housing is a "friendly" interface designed to facilitate older
equipment.
> You will probably find that Apple II Desktop _is_ polling the drives,
> but the poll is so short you cannot see it. The UDC might be spinning
> the drive up just to read the disk changed detector.
Ummm. I will have to look at this. I know the CPS UDC "disabled" the
eject button the IIgs drives. When Apple II Desktop wasn't running I could
eject the disks with the button. It was almost like with Linux, where
after mounting a CD-ROM, it activates the "lock" function, keeping the
CD-ROM disc in the drive until the device is unmounted.
The IIgs drives connected through the Apple II 3.5 Drive controller always
allow for the disk to be ejcted.
> The IIgs Finder does poll Apple 3.5 drives, but the light blink is so
> short you have to look very closely to see it.
I remember using Apple II Desktop on a IIgs and when it polled the drives
you did have to look very closely at drive lights. You could certainly
see them flash. I have looked closely when my //e is running Apple II
Desktop and there isn't an obvious flicker like with the IIgs or when
my CPS UDC was being polled.
I am beginning to think the 32K of SRAM cache on the Apple II 3.5" Drive
controller keeps the 3.5" from being accessed during frequent polling.
>> Next, if I drag the disk onto the trash, it treats it just like a 5.25"
>> and re-reads the disk without ejecting. With the Central Point UDC, I
>> could drag disks onto the trash and they would eject. This worked very
>> nicely with my Macintosh External 400K and 800K drives, as they don't have
>> an eject button.
>
> Hm, not sure about that one. Possibly a compatibility problem, as Apple
> II Desktop predates Apple's newer controller card, and might not
> recognise it properly.
That would make me think that the Apple II Desktop would treat the disks
just as it treats my QRAM //e volume, with a "hard drive" icon. Instead
it places a 3.5" icon for any of the disks. Perhaps Apple II Desktop
identifies the controller as a smart port, but doesn't know quite what
to do beyond that. I know for a fact that Apple II Desktop on a IIgs
would eject the disks when dragged onto the trash. Therefore, it leads
me to believe that Apple II 3.5" Drive controller is identified as a
smart port, but not as a smart port that Apple II Desktop recognizes.
> I had limited success getting the SuperDrive card to reliably format
> 720K disks. I suspect it has a firmware bug. The only way that
> appeared to work was to format a 720K disk immediately after another one
> was inserted. I actually got machine crashes in some cases.
The only way I have found to format 720K disks on my //e is to take a
blank MS-DOS 720K disk, copy blocks over from any other ProDOS volume
to make an identifiable "ProDOS" volume, and then erase (not format)
the volume with Copy II+. Somehow when Copy II+ erases the disk, it
queries the device as to the size and writes the appropriate table.
Note that an erase of the disks will only erase the first few blocks
on the disk and leaves the remaining sectors unscathed.
> The ProDOS format call is not flexible enough to let the application
> choose the format. You have to use the SmartPort calls, and the
> SuperDrive card implements a new call that was introduced with the ROM 3
> IIgs. The 'SetFormatOptions' call is documented in the ROM 3 supplement
> to the IIgs Firmware Reference.
So essentially I'd have to "detect" the firmware by scanning and then
program the controller to format 720K. After that I would make a ProDOS
format call and all my request should be carried out?
-/\/\ichael-
replyto: mkelsey at eecs.wsu.edu