Hi Phoebus, >One thing for sure, SMSQ/E HDD code needs to be scrapped and redone from >scratch.
One problem here will be, that the SMSQ/E IDE driver can probably not be disabled or removed from an existing SMSQ/E binary without evil hacks. A new IDE driver would be very nice, because SLAVEing could be removed, and multimedia applications could finally become possible. A low-level IDE block driver can be very simple. I wrote one myself for the Q40 UTIL ROMs, when there was no OS. If only there was more time... The SMSQ/E IDE driver is probably not very complex, too. It doesn't even use interrupts. (Otherwise Thierry's CDROM driver couldn't work with the same controller that has a harddisk attached. A block transfer must never be disrupted by accesses from another device driver to the IDE registers.) >So... once more how about that OpenSMS again? (In C....?) If highcolor drivers for QDOS Classic were possible, and joining forces between QDOS Classic and Minerva, I would see a little light in that direction. I'm sure the OS call interface always has to remain 68k assembler. The largest deviation from pure 68k I could imagine to become a little bit near feasible, would be Coldfire Version >= 4e. (This would mean, that many existing binaries couldn't be executed anymore, but after recompiling they could. And it is theoretically possible to write QDOS assembler + C programs that run on both 68k and CF, by avoiding the incompatible, non-trapable CF instructions. The calling interface to the OS could remain exactly the same on Coldfire as it is now.) Bye, Peter
