On Fri, 5 Jun 2020, Finn Thain wrote:
On Thu, 4 Jun 2020, Brad Boyer wrote:
I have a list of structures and one of them appears to be the bypass
command. The outbound message is 3 bytes (the command code:4, a byte
for a flag with 0 meaning off and 1 meaning on, and an ID byte). The
reply is a byte of error (0 is success) followed by extra bytes
depending on the error value.
One of the listed error values is "driver in use", so it's possible it
will reject the request. We are just taking advantage of the existing
drivers, so probably both the SWIM and ADB drivers are still running
on the IOP.
It looks like shutting down a driver is another command. The command
byte for that is 2, and the second byte is which driver to stop (0/1).
I'm not sure if there's a way to restart the driver after that other
than reloading everything.
I think we need to be able to restart the IOP's internal ADB driver.
Otherwise it's impossible to have ADB input resume when the floppy
drives go idle for a while or when the swim module exits.
The alternative is to revive swip_iop.c, and the downside there is that
the block layer API has completely changed, meaning that the driver
needs a rewrite on the block layer side, as well as needing more work on
the IOP protocol side.
I should also mention that swim.c has some pretty serious limitations: no
write support and no GCR support. These features could be added much more
easily to swim_iop.c than swim.c because the IOP supports them internally.
