It's been a while, but... going mostly from memory, in a cassette boot situation:
Motor control should already be on so no need to worry about it. Due to a bug in the OS, you should turn the motor off via PACTL once the tape boot is complete.
A call to SIOV $E459 should be made for each block to be read.
Prerequisite setup of the DCB:
DDEVIC $300 should be set to $60 for cassette, this only needs to be done once, in the case of a tape boot/continuation code it should already have been set.
DUNIT $301 unit number for cassette is ignored so don't worry about this one.
DCOMND $302 command, we want "R" for Read operation, set to $52
DSTATS $303 this is important. On return this has the status code but before calling SIOV the top 2 bits are used to indicate whether an input or output operation is taking place. So, we need $40 to indicate input, if we were writing a block it'd be $80.
DBUF $304-5 Points to our buffer address.
DTIMLO $306 and DUNUSE $307 Not used for tape.
DBYT $308-9 Byte count - this is the number of bytes for the operation - data payload only, this doesn't include sync leader bytes or checksum, SIO takes care of those things.
DAUX1/2 $30A-B DAUX1 ignored (?) DAUX2 should = $80 to force short inter-record gaps (in a boot situation should already be set as such)
For a multistage boot, a few things to note:
You can use a short leader between the EOF block of the booter and the remainder of the program, 4-5 seconds should be plenty.
Probably best to have a delay of about 1 second before attempting to start read operations, allows for pause between recording of the 1st/2nd stage of the boot and any unwanted noise that might be on that section of tape.
Note that if you have intro screen or any possible extra delay beyond a couple of seconds it's probably a good idea to stop the tape. Note that when you restart the tape you should allow about 1.5-2 seconds before calling SIO, allow the tape to get up to speed.
Most important - a binary loader by tape can potentially be too slow such that the next block is played before the SIO call has a chance to start reading it. Efficient programming becomes a must. In most cases it'd probably never happen but e.g. a section of binary file with a lot of 1-2 byte segments could potentially cause overrun.
And of course, INIT sections where title screens or user intervention is needed to continue loading - you'd need to cater for this by motor off, then extra long leader before the next block.
Edited by Rybags, Wed Apr 5, 2017 10:22 AM.