I'm currently writing a program for the Apple IIe that requires reading/writing files from disk. In reading the books I've found archived online about assembly language for the Apple II I've come across the $C060 subroutine which is for accessing the cassette port, but I can't seem to find a subroutine that will access the disk drive. Is there such a monitor command? If not, what would I do to read/write a file to/from disk during the program?
CodePudding user response：
It's possible to read and write a floppy disk without loading in DOS. DOS is useful if you want to read/write disks that are usable by other programs, and making things work reliably using DOS is apt to be easier than using raw I/O, but raw I/O can be faster than DOS and allow more information to be stored on a disk, especially if you never need to read or write less than a track at a time.
When using track-at-a-time I/O, writing and reading a disk is conceptually simple:
To write a disk track, build a buffer holding about 6K of suitably-formatted data, turn on the motor, move the head to the desired track, turn on the write signal, write the pattern 0x92 $A4 about 500 times, followed by $9F then output the contents of the buffer and turn off the write signal. Bytes must be sent to the drive controller precisely once every 32 clock cycles. Slipping by even one cycle will cause the controller to output garbage.
To read a disk track, turn on the motor, move the head to the desired track, and read bytes of data from the disk until one sees a the byte sequence $92 $A4 $9F, and then read the rest of the data. Data will arrive at a rate of about 32 cycles/byte, and each byte must be read within a 7 cycle window.
The data read back should precisely match the data written provided every byte in the buffer upholds three restrictions:
Every byte must have the most significant bit set.
No byte may contain more than two consecutive 0 bits.
Every byte must contain at least one pair of consecutive 1 bits.
There are 64 possible byte values that meet those criteria. Encoding arbitrary data to fit that limitation before storing it, and decoding information that is written in that fashion can be a nuisance, but that's part of the "fun" of writing one's own disk routines. Many disk routines read data into a buffer without decoding it, and then decode it later, but if one chooses a suitable encoding it's possible to decode information in real time as it's received from the disk.