Post by I am Rob Post by Steven Hirsch Post by John Newcombe
Hi, I am the guy Steve is helping. The Microdrive is normally in slot
6 with Floppy in slot 5 however to test the catalog I booted ProDOS
2.4.1 from a Floppy from slot 6 with Microdrive in slot 5 and can see
the catalogue on 5,1 5,2 OK. Is that what you were meaning?
The problem we're running into is that my software is either unable to
identify the Microdrive firmware by probing the slot page or identifies
it, but is then unable to access the drive via the Pascal 1.1 block
device entry point.
Many folks have successfully used my code over the past 30 years on
dozens of block devices, so whatever is going on is particular to the
Right. When the slot is set manually by the Prefix command or ,Slot
parameter doesn't prove your software is identifying the bytes for that
There are 2 versions of the Microdrive, Microdrive and Microdrive Turbo.
Could it be that one of the bytes you are using as an identifier is
different between the two devices?
Rob, I think we're talking about two unrelated issues. I do not care about
Prefix (a ProDOS filesystem concept) and do not understand your reference to
setting "Slot" parameter manually. The code in question is 6502 assembly
language in a PCPI Applicard CP/M device driver. There is no ProDOS context
in existence when this executes, just "bare metal".
I look at bytes 1, 3 and 5 in the Cn00 page for each slot - starting at C700
and working downward. If I find $20, $00 and $03 at those locations, I lookup
the offset to the Pascal 1.1 firmware entry point at location CnFF and make a
read call to the drive to read a specific data block on the disk. This call
is made for drive 1 and drive 2 in sequence.
These bytes are the defined standard for a ProDOS block device driver. In the
case of the Microdrive, it also reports $00 at offset 7 to indicate that it's
a SmartPort device. HOWEVER, I do not try to make any SmartPort related
firmware calls. In the past, this has never been necessary with any product
if I'm interested only in the first two attached volumes.
In this case, even though the user has confirmed those id bytes are present,
my code is seemingly either not seeing them at all, or sees them and calls the
firmware entry to no effect.
That's about all I can determine when debugging via e-mail messages.
I was hoping that someone who has coded against the Microdrive in assembly
language could tell me whether there's something unusual or state dependent
about the firmware slot-page behavior. It occurred to me that perhaps a
SmartPort status call is required to setup the controller, but that
requirement would not be met when the card is booted (PR#n) so doesn't make
sense it would be needed to init firmware.