Young lion knew a lot about sector access on the 1541 but not anymore.  There were undelete tools & disk editors in Compute magazine.

There are some bits about raw sector reads.

https://codebase64.org/doku.php?id=base:reading_a_sector_from_disk

https://wpguru.co.uk/2016/01/how-to-use-direct-block-access-commands-in-commodore-dos/

https://www.lemon64.com/forum/viewtopic.php?t=55010

I/O doesn't get as much love as graphics & sound, probably because the mane focus of retro computing is games & much I/O has been replaced with RAM expanders or custom hardware. 

You have to specify the track & sector.  The tracks start on 1.  Sectors start on 0.  Track 1 sector 0 is byte 0 of the .d64 file.  The last sector on track 1 is 20.  The number of sectors changes based on track.  The world table of contents thus needs to define tracks & sectors instead of monolithic sectors.

track       # sectors
1 – 17      21     
18 – 24     19     
25 – 30     18     
31 – 35     17     

-------------------------------------------------------------------------------------------------------------

It's highly desirable to have the world map on drive 9 & the mane program on drive 8.  The mane problem for animals is lockups after calling CHKIN for drive 9.  You have to read a status register $90.  If bit 8 is 1, no device is attached. 

~/.vice/vicerc needs to have a line enabling drive 9 to get around the lockup

Drive9Type=1541

Then x64 needs a -9 argument to attach a disk.   Noted the -attach commands don't work.  Only -9 works.

-----------------------------------------------------------------------------------------------------------------------------

There are some long delays when calling OPEN.  Some of the internet notes it's waiting for the device to assert a clock signal.  It also has a hard time printing to the printer while accessing  a disk.

Noted in the asm version of opening the data channel

open 5,9,5,"#"

You have to call SETNAM to set "#" as the filename.

The only way to read a sector was to call OPEN for the control channel with "u1 2 0 1 0" as the filename.  With the CHKOUT API, it's not possible to read consecutive sectors without calling OPEN & CLOSE for each sector & having a long delay.  A lower level API is required to have any hope of asynchronous reads.  The big challenge with what young lion envisioned was the simultaneous loading of tiles in the background while scrolling the world map.

It seems the serial API only goes 1 way at a time.  You can't CHKOUT & CHKIN simultaneously to print to a debug port while reading from a disk port.   It would be easier if the screen could be used for debug output.  Then CHROUT could simultaneously write to the screen while CHRIN read from a serial port.

https://www.pagetable.com/?p=1031

https://retro-bobbel.de/zimmers/cbm/programming/serial-bus.pdf

There are some notes about using a lower level talk/listen API instead of the CHKIN/CHKOUT API but no examples.

There's a reference manual for the 1541

https://www.mocagh.org/cbm/c1541II-manual.pdf

The kernal source code is

https://github.com/mist64/c64rom/tree/master

Inspecting the kernal source code & peeking addresses revealed how to use the talk/listen API. Basically call LISTEN with 9 to access drive 9.  Call SECOND with (15 | 0x60) to specify the secondary address for the control channel. Call CIOUT to send the u1 command to the control channel. Call UNLSN to execute the command. The mane trick is the secondary address sent to SECOND has to be ored with 0x60. The OPEN workflow is still necessary to open the drive but it's only needed once in the program lifecycle.  Then, the talk API can send consecutive "u1" commands to read sectors.

This API was able to read all 256 bytes from each sector.  Some sources say only 255 bytes per sector are accessible.

Also noted UNLSN is only required once to execute the u1 command.  No other I/O operations need to call UNLSN or UNTLK.

The key development is going to be a polling mechanism for drive communication & a state machine which can be interleaved inside the drawing routines. It seems to bit bang the serial port.  It's a synchronous serial port but it also requires disabling IRQ's.  This could limit the granularity of multitasking.