Discussion:
Question re: Microdrive
Add Reply
Steven Hirsch
2017-09-10 13:14:16 UTC
Reply
Permalink
Raw Message
I'm helping a person who's trying to get my Applicard CP/M hard disk driver to
function with a Microdrive. It's hard to diagnose by e-mail, but my
impression is the driver fails to recognize the Microdrive slot firmware.

Is there something unusual about the signature bytes used in this product?
Does it need to be booted from or otherwise initialized before appearing as a
ProDOS block device?
Steven Hirsch
2017-09-11 01:17:28 UTC
Reply
Permalink
Raw Message
Post by Steven Hirsch
I'm helping a person who's trying to get my Applicard CP/M hard disk driver to
function with a Microdrive. It's hard to diagnose by e-mail, but my
impression is the driver fails to recognize the Microdrive slot firmware.
Is there something unusual about the signature bytes used in this product?
Does it need to be booted from or otherwise initialized before appearing as a
ProDOS block device?
Follow up to my original post:

The Microdrive turns out to ID as a SmartPort device - nothing special at all.
All SmartPort devices I've worked with in the past supported the Pascal 1.1
block device firmware API - and - the SmartPort API (entry point 3 bytes
beyond the Pascal address). My driver only tries to talk to the block device
entry at Cn00 + (offset read from CnFF) and is not able to physically read the
disk. Is it possible that the Microdrive does not support the Pascal 1.1 entry
point? Something tells me this is unlikely, since the //e firmware has to
know how to boot from it, but I'm running out of ideas.

Steve
I am Rob
2017-09-11 02:36:03 UTC
Reply
Permalink
Raw Message
Post by Steven Hirsch
Post by Steven Hirsch
I'm helping a person who's trying to get my Applicard CP/M hard disk driver to
function with a Microdrive. It's hard to diagnose by e-mail, but my
impression is the driver fails to recognize the Microdrive slot firmware.
Is there something unusual about the signature bytes used in this product?
Does it need to be booted from or otherwise initialized before appearing as a
ProDOS block device?
The Microdrive turns out to ID as a SmartPort device - nothing special at all.
All SmartPort devices I've worked with in the past supported the Pascal 1.1
block device firmware API - and - the SmartPort API (entry point 3 bytes
beyond the Pascal address). My driver only tries to talk to the block device
entry at Cn00 + (offset read from CnFF) and is not able to physically read the
disk. Is it possible that the Microdrive does not support the Pascal 1.1 entry
point? Something tells me this is unlikely, since the //e firmware has to
know how to boot from it, but I'm running out of ideas.
Steve
You could ask him to see if it mounts under Prodos and able to catalog it, and if it does, that should mean the volume index is in correct order. I believe Prodos and CPM have the same directory structure, or am I thinking of something else?
Steve Nickolas
2017-09-11 02:40:29 UTC
Reply
Permalink
Raw Message
Post by I am Rob
You could ask him to see if it mounts under Prodos and able to catalog
it, and if it does, that should mean the volume index is in correct
order. I believe Prodos and CPM have the same directory structure, or
am I thinking of something else?
Think you're confusing CP/M with SOS. CP/M has a flat directory, 8.3
filenames, etc.

-uso.
John Newcombe
2017-09-11 07:32:02 UTC
Reply
Permalink
Raw Message
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?
Steven Hirsch
2017-09-11 11:53:05 UTC
Reply
Permalink
Raw Message
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 Microdrive.
I am Rob
2017-09-11 19:33:25 UTC
Reply
Permalink
Raw Message
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 Microdrive.
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 firmware correctly.

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?
Steven Hirsch
2017-09-11 20:15:25 UTC
Reply
Permalink
Raw Message
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
Microdrive.
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
firmware correctly.
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.
John Brooks
2017-09-12 02:38:01 UTC
Reply
Permalink
Raw Message
Post by Steven Hirsch
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
Microdrive.
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
firmware correctly.
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.
If the block count at $Cs0D/$Cs0E is $0000, it means that the device has a variable configuration and needs to query & build it's device list via a status call before read/write/format calls are issued.

This protocol was created because the Apple SCSI card has to check for connected drives, mount partitions, and then assign them to the controller's smartport drive numbers before doing reads or writes.

The status call 'query' is only needed for ProDOS & Smartport driver entry-point calls. Booting goes through $Cs00 which contains it's own query machinery prior to booting.

-JB
@JBrooksBSI
Steven Hirsch
2017-09-12 11:58:24 UTC
Reply
Permalink
Raw Message
Post by John Brooks
If the block count at $Cs0D/$Cs0E is $0000, it means that the device has a
variable configuration and needs to query & build it's device list via a
status call before read/write/format calls are issued.
This protocol was created because the Apple SCSI card has to check for
connected drives, mount partitions, and then assign them to the
controller's smartport drive numbers before doing reads or writes.
The status call 'query' is only needed for ProDOS & Smartport driver
entry-point calls. Booting goes through $Cs00 which contains it's own query
machinery prior to booting.
Thanks very much, John. The light has finally illuminated here :-).

I was confusing $Cs00 entry with firmware entry and didn't take into account
the fact that cold-boot is very likely to be doing init under the covers.

If John Newcombe first boots from the Microdrive then subsequently boots the
CP/M floppy with PR#6 rather than hardware reset, would that not leave the
Microdrive initialized?

I think that experiment is worth a try. In the longer term it sounds like I
need to extend my slot probing code to make a status call against any
SmartPort device it sees before trying to read the disk.
John Newcombe
2017-09-12 12:11:42 UTC
Reply
Permalink
Raw Message
Post by Steven Hirsch
Post by John Brooks
If the block count at $Cs0D/$Cs0E is $0000, it means that the device has a
variable configuration and needs to query & build it's device list via a
status call before read/write/format calls are issued.
This protocol was created because the Apple SCSI card has to check for
connected drives, mount partitions, and then assign them to the
controller's smartport drive numbers before doing reads or writes.
The status call 'query' is only needed for ProDOS & Smartport driver
entry-point calls. Booting goes through $Cs00 which contains it's own query
machinery prior to booting.
Thanks very much, John. The light has finally illuminated here :-).
I was confusing $Cs00 entry with firmware entry and didn't take into account
the fact that cold-boot is very likely to be doing init under the covers.
If John Newcombe first boots from the Microdrive then subsequently boots the
CP/M floppy with PR#6 rather than hardware reset, would that not leave the
Microdrive initialized?
I think that experiment is worth a try. In the longer term it sounds like I
need to extend my slot probing code to make a status call against any
SmartPort device it sees before trying to read the disk.
Hi, Just so I am clear, I have (up until now) been booting the microdrive to Prodos and using Bitsy Boot to boot the floppy in 5. Are you saying that I should boot the floppy using PR#5?
John Newcombe
2017-09-12 12:41:26 UTC
Reply
Permalink
Raw Message
Post by John Newcombe
Post by Steven Hirsch
Post by John Brooks
If the block count at $Cs0D/$Cs0E is $0000, it means that the device has a
variable configuration and needs to query & build it's device list via a
status call before read/write/format calls are issued.
This protocol was created because the Apple SCSI card has to check for
connected drives, mount partitions, and then assign them to the
controller's smartport drive numbers before doing reads or writes.
The status call 'query' is only needed for ProDOS & Smartport driver
entry-point calls. Booting goes through $Cs00 which contains it's own query
machinery prior to booting.
Thanks very much, John. The light has finally illuminated here :-).
I was confusing $Cs00 entry with firmware entry and didn't take into account
the fact that cold-boot is very likely to be doing init under the covers.
If John Newcombe first boots from the Microdrive then subsequently boots the
CP/M floppy with PR#6 rather than hardware reset, would that not leave the
Microdrive initialized?
I think that experiment is worth a try. In the longer term it sounds like I
need to extend my slot probing code to make a status call against any
SmartPort device it sees before trying to read the disk.
Hi, Just so I am clear, I have (up until now) been booting the microdrive to Prodos and using Bitsy Boot to boot the floppy in 5. Are you saying that I should boot the floppy using PR#5?
Just to summarise:

MicroDrive/Turbo in Slot 6, Floppy in 5.

Booted to MicroDrive (ProDOS 2.4.1) into BASIC and used PR#5 to boot the Applicard CP/M boot disk with PDOSHD driver. System still reports No PRO_PARTITION found.

I hope I have understood correctly what you were asking.
Steven Hirsch
2017-09-12 13:19:18 UTC
Reply
Permalink
Raw Message
Post by John Newcombe
Post by John Newcombe
Post by Steven Hirsch
I was confusing $Cs00 entry with firmware entry and didn't take into
account the fact that cold-boot is very likely to be doing init under
the covers.
If John Newcombe first boots from the Microdrive then subsequently
boots the CP/M floppy with PR#6 rather than hardware reset, would that
not leave the Microdrive initialized?
I think that experiment is worth a try. In the longer term it sounds
like I need to extend my slot probing code to make a status call
against any SmartPort device it sees before trying to read the disk.
Hi, Just so I am clear, I have (up until now) been booting the microdrive
to Prodos and using Bitsy Boot to boot the floppy in 5. Are you saying
that I should boot the floppy using PR#5?
MicroDrive/Turbo in Slot 6, Floppy in 5.
Booted to MicroDrive (ProDOS 2.4.1) into BASIC and used PR#5 to boot the
Applicard CP/M boot disk with PDOSHD driver. System still reports No
PRO_PARTITION found.
I hope I have understood correctly what you were asking.
No, that's what I was suggesting. It was worth a try. I'm having trouble
understanding why that procedure would not be finding an initialized
Microdrive. There's something I'm continuing to misunderstand about the
Microdrive. It is _physically_ in Slot 6, correct? Are you using any
remapping of volumes to other slots? If the Microdrive volume with the
partition was not natively drive 1 or 2, I would expect it not to be found.
But I recall you mentioning it was drive 1, correct?

If I can find time in the next week I'll work on building a driver that prints
debugging output at every step so we can see what it's doing during probe.
John Newcombe
2017-09-12 13:49:39 UTC
Reply
Permalink
Raw Message
Post by Steven Hirsch
Post by John Newcombe
Post by John Newcombe
Post by Steven Hirsch
I was confusing $Cs00 entry with firmware entry and didn't take into
account the fact that cold-boot is very likely to be doing init under
the covers.
If John Newcombe first boots from the Microdrive then subsequently
boots the CP/M floppy with PR#6 rather than hardware reset, would that
not leave the Microdrive initialized?
I think that experiment is worth a try. In the longer term it sounds
like I need to extend my slot probing code to make a status call
against any SmartPort device it sees before trying to read the disk.
Hi, Just so I am clear, I have (up until now) been booting the microdrive
to Prodos and using Bitsy Boot to boot the floppy in 5. Are you saying
that I should boot the floppy using PR#5?
MicroDrive/Turbo in Slot 6, Floppy in 5.
Booted to MicroDrive (ProDOS 2.4.1) into BASIC and used PR#5 to boot the
Applicard CP/M boot disk with PDOSHD driver. System still reports No
PRO_PARTITION found.
I hope I have understood correctly what you were asking.
No, that's what I was suggesting. It was worth a try. I'm having trouble
understanding why that procedure would not be finding an initialized
Microdrive. There's something I'm continuing to misunderstand about the
Microdrive. It is _physically_ in Slot 6, correct? Are you using any
remapping of volumes to other slots? If the Microdrive volume with the
partition was not natively drive 1 or 2, I would expect it not to be found.
But I recall you mentioning it was drive 1, correct?
If I can find time in the next week I'll work on building a driver that prints
debugging output at every step so we can see what it's doing during probe.
Yes, Microdrive in slot 6 with drives 1 and 2. The partition created with PART.COM is on S6D1. I am not remapping any drives as such but I suspect that something clever happens as I can, through the Microdrive Utility, swap D1 to D2 and visa versa when I change the boot volume from Microdrive partition 1 to Microdrive partition 2.

I hope that makes sense.

J
John Brooks
2017-09-12 20:07:51 UTC
Reply
Permalink
Raw Message
Post by Steven Hirsch
Post by John Newcombe
Post by John Newcombe
Post by Steven Hirsch
I was confusing $Cs00 entry with firmware entry and didn't take into
account the fact that cold-boot is very likely to be doing init under
the covers.
If John Newcombe first boots from the Microdrive then subsequently
boots the CP/M floppy with PR#6 rather than hardware reset, would that
not leave the Microdrive initialized?
I think that experiment is worth a try. In the longer term it sounds
like I need to extend my slot probing code to make a status call
against any SmartPort device it sees before trying to read the disk.
Hi, Just so I am clear, I have (up until now) been booting the microdrive
to Prodos and using Bitsy Boot to boot the floppy in 5. Are you saying
that I should boot the floppy using PR#5?
MicroDrive/Turbo in Slot 6, Floppy in 5.
Booted to MicroDrive (ProDOS 2.4.1) into BASIC and used PR#5 to boot the
Applicard CP/M boot disk with PDOSHD driver. System still reports No
PRO_PARTITION found.
I hope I have understood correctly what you were asking.
No, that's what I was suggesting. It was worth a try. I'm having trouble
understanding why that procedure would not be finding an initialized
Microdrive. There's something I'm continuing to misunderstand about the
Microdrive. It is _physically_ in Slot 6, correct? Are you using any
remapping of volumes to other slots? If the Microdrive volume with the
partition was not natively drive 1 or 2, I would expect it not to be found.
But I recall you mentioning it was drive 1, correct?
If I can find time in the next week I'll work on building a driver that prints
debugging output at every step so we can see what it's doing during probe.
- I'm having trouble understanding why that procedure would not be finding an initialized Microdrive.

Device card firmware often has to construct internal-state using both the attached devices and the active OS which will be calling the firmware. This is often stored in text page screen holes and reset each boot.

For example, AE firmware reads $BF00 at boot to determine if the OS is ProDOS, DOS 3.3, Pascal, or CP/M. It can then decide if the OS needs to be patched and whether data transfers will be 512-byte blocks (ProDOS & Pascal), or 256-byte pages (DOS33 & CP/M).

From a best-practices standpoint, I recommend that any OS driver start by issuing a status call to the card firmware after OS boot. ProDOS does this during the device scan while building the device list at $BF31.

I'm not sure if this will fix the problem you are seeing with the Microdrive, but there's a chance.

-JB
@JBrooksBSI
Steven Hirsch
2017-09-12 20:31:11 UTC
Reply
Permalink
Raw Message
Post by John Brooks
- I'm having trouble understanding why that procedure would not be finding
an initialized Microdrive.
Device card firmware often has to construct internal-state using both the
attached devices and the active OS which will be calling the firmware. This
is often stored in text page screen holes and reset each boot.
For example, AE firmware reads $BF00 at boot to determine if the OS is
ProDOS, DOS 3.3, Pascal, or CP/M. It can then decide if the OS needs to be
patched and whether data transfers will be 512-byte blocks (ProDOS &
Pascal), or 256-byte pages (DOS33 & CP/M).
From a best-practices standpoint, I recommend that any OS driver start by
issuing a status call to the card firmware after OS boot. ProDOS does this
during the device scan while building the device list at $BF31.
I'm not sure if this will fix the problem you are seeing with the
Microdrive, but there's a chance.
That sounds quite reasonable. I'll blow the cobwebs out of my head, pull my
dog-eared Roger Wagner Apple assembly book off the shelf and code in a
smartport status call. I'm embarrassed to admit how atrophied my Apple 2
coding skills are...
Steven Hirsch
2017-09-12 20:52:26 UTC
Reply
Permalink
Raw Message
Post by John Brooks
From a best-practices standpoint, I recommend that any OS driver start by
issuing a status call to the card firmware after OS boot. ProDOS does this
during the device scan while building the device list at $BF31.
It appears that I can make a status call to the SmartPort device itself (Code
0) or to specific devices (1..n). Should the simple approach of calling code
0 be sufficient?
John Brooks
2017-09-13 03:49:05 UTC
Reply
Permalink
Raw Message
Post by Steven Hirsch
Post by John Brooks
From a best-practices standpoint, I recommend that any OS driver start by
issuing a status call to the card firmware after OS boot. ProDOS does this
during the device scan while building the device list at $BF31.
It appears that I can make a status call to the SmartPort device itself (Code
0) or to specific devices (1..n). Should the simple approach of calling code
0 be sufficient?
When ProDOS sees a smartport card it checks $CsFB for bit 1 (AND #2) to see if the card is a SCSI controller. If it is SCSI, ProDOS then makes a status call to device 2 to alert the firmware that it wants more than just drive 0 & 1.

ProDOS then makes a status call to the SmartPort device itself to get the number of attached drives.

-JB
@JBrooksBSI
Steven Hirsch
2017-09-13 11:57:34 UTC
Reply
Permalink
Raw Message
Post by John Brooks
Post by Steven Hirsch
Post by John Brooks
From a best-practices standpoint, I recommend that any OS driver start
by issuing a status call to the card firmware after OS boot. ProDOS
does this during the device scan while building the device list at
$BF31.
It appears that I can make a status call to the SmartPort device itself
(Code 0) or to specific devices (1..n). Should the simple approach of
calling code 0 be sufficient?
When ProDOS sees a smartport card it checks $CsFB for bit 1 (AND #2) to see
if the card is a SCSI controller. If it is SCSI, ProDOS then makes a status
call to device 2 to alert the firmware that it wants more than just drive 0
& 1.
ProDOS then makes a status call to the SmartPort device itself to get the
number of attached drives.
Great, thanks. Since I don't care about anything other than drive 0 or 1, it
sounds as if a simple status call with code 0 will do the trick. At some
point, I'll consider extending my CP/M partition program to support higher
drives, but that's for the future.

I am Rob
2017-09-12 04:01:22 UTC
Reply
Permalink
Raw Message
Post by Steven Hirsch
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
Microdrive.
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
firmware correctly.
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.
don't worry we are on the same page. I was more thinking out loud than anything. I brought up the "prefix and slot" because John was able to catalog the microdrive. That is when I realized "prefix and slot" doesn't have to verify that the firmware is present or the device is readable before making the call. I usually go in a round-about way to prove or disprove things.

The idea I was trying to bring up had more to do with the way the IIe searches the slots at boot-up. It searches from the highest slot down to the lowest, which should mean it has to identify the firmware in a slot to be a bootable device.

I am trying to remember where I saw the search code, at first I thought it was with Prodos, and the first things that came to mind was "prefix and slot" parameters.

So, the idea is if Prodos can find and identify the smartport device, and the bytes are correct and your code is correct, then the fault should be with CPM, which is looking for something extra other than those 3 ID bytes.

Or is this too logical?
James Davis
2017-09-13 01:09:47 UTC
Reply
Permalink
Raw Message
Post by I am Rob
The idea I was trying to bring up had more to do with the way the IIe searches the slots at boot-up. It searches from the highest slot down to the lowest, which should mean it has to identify the firmware in a slot to be a bootable device.
I am trying to remember where I saw the search code,
The search code must be in the Monitor, since that is what gets everything going at boot-up. Look at the RESET routine first, then keep going from there.

You might find more about this in the Apple IIx {Technical} Reference Manuals and Understanding the Apple IIx manuals [x is the model; e.g., +/e/c/c+/gs].
Loading...