Rocking the Adam Buxton look with that hat... BTW I have several mini SD cards. I've never used them without the mini to full-size adapter that they came with, but that's beside the point - some definitely shipped at some point.
But but, the MS-DOS disk interface could be used asynchronously. Back in the day I worked with a guy who figured out how to do it and showed me. We used it as part of a cooperative scheduler OS on a hand held device for a military communications project. I do not recall the detail but it involved making non-blocking sys call to initiate read or write. Then hooking into some interrupt that happened when the request was completed. Meanwhile our little OS could get on with doing whatever else it had to do. I have no idea if one can do that in Rust without async or not.
You could use DMA to talk to some kinds of disk controller asynchronously, and in fact some versions of Windows can do just that. But I’m pretty sure there was no MS-DOS API for it; you just bypassed MS-DOS to do it. If you’ve got the number of an int 21h service to prove me wrong though I’d really love to dig into it.
@@therealjpster I suspect you are right. My memory is hazy. Thing is we were working on a handheld military communication system that used PC-DOS. It ran on a NEC V20 processor. We had our own in-house cooperative scheduler to run tasks. So it was cool to be able to do the communication and user interface and access storage at the same time. I do remember a team leader. showing off async use of storage as I describe. However, thinking about it that hand held device had a very peculiar BIOS created by the hardware manufacturer. Being hand held and battery powered it was important that it "sleep" when idle. But the only interrupt that could wake up the device when sleeping was the Non Maskable Interrupt (NMI). That meant all interrupts from all devices went through the NMI handler. On the other hand I don't think I was shown that async demo running on that particular hardware... Sniffing around just now I find INT 15H 91H: Interrupt Finished. Which claims "This service is designed to be intercepted by a multitasking operating system. It could be used by disk or other hardware handlers so the handler can be notified when I/O is completed." www.techhelpmanual.com/226-int_15h_91h__interrupt_finished.html So, yeah, likely this was done at the BIOS level not the DOS level. Interesting.
Rocking the Adam Buxton look with that hat... BTW I have several mini SD cards. I've never used them without the mini to full-size adapter that they came with, but that's beside the point - some definitely shipped at some point.
But but, the MS-DOS disk interface could be used asynchronously. Back in the day I worked with a guy who figured out how to do it and showed me. We used it as part of a cooperative scheduler OS on a hand held device for a military communications project. I do not recall the detail but it involved making non-blocking sys call to initiate read or write. Then hooking into some interrupt that happened when the request was completed. Meanwhile our little OS could get on with doing whatever else it had to do. I have no idea if one can do that in Rust without async or not.
You could use DMA to talk to some kinds of disk controller asynchronously, and in fact some versions of Windows can do just that. But I’m pretty sure there was no MS-DOS API for it; you just bypassed MS-DOS to do it. If you’ve got the number of an int 21h service to prove me wrong though I’d really love to dig into it.
@@therealjpster I suspect you are right. My memory is hazy. Thing is we were working on a handheld military communication system that used PC-DOS. It ran on a NEC V20 processor. We had our own in-house cooperative scheduler to run tasks. So it was cool to be able to do the communication and user interface and access storage at the same time. I do remember a team leader. showing off async use of storage as I describe.
However, thinking about it that hand held device had a very peculiar BIOS created by the hardware manufacturer. Being hand held and battery powered it was important that it "sleep" when idle. But the only interrupt that could wake up the device when sleeping was the Non Maskable Interrupt (NMI). That meant all interrupts from all devices went through the NMI handler.
On the other hand I don't think I was shown that async demo running on that particular hardware...
Sniffing around just now I find INT 15H 91H: Interrupt Finished. Which claims "This service is designed to be intercepted by a multitasking operating system. It could be used by disk or other hardware handlers so the handler can be notified when I/O is completed." www.techhelpmanual.com/226-int_15h_91h__interrupt_finished.html
So, yeah, likely this was done at the BIOS level not the DOS level. Interesting.