At 10:44 �� 7/2/2002 +0100, you wrote: >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.
Well I see nothing wrong with evil hacks! Minerva (at least very early versions) could be considered an "evil hack" but it works damn fine if you ask me! Hacking into the kernel is many Linux developers favourite way of doing things .... (Hi Richard!) So there's really no problem... Anyway we need to hack into the official OS to solve its bugs (Hi Richard!) and on top of that Qx0 SMSQ/E is really incompatible with QXL SMSQ and QPC SMSQ and so on and so forth... >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... Why don't you send that to other good fellas like Wolfgang for example... I am sure they would love to get their hands on it! >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 do believe that "High Colour" is possible on QDOS Classic or Minerva. Hell I've done it with regular QDOS on my Aurora... Granted compatibility goes out of the window but the same happened with many programs a long, long time ago... Why do we salute something if it comes from TT and condemn anybody else which might do the same? It's really beyond my understanding. Anyway the whole discussion re: backwards compatibility, f systems etc is essentially IMHO moot... Just scrap the thing and do it all over again... RIGHT this time :-) >I'm sure the OS call interface always has to remain 68k assembler. Not necessary if you do agree with my opinion (see previously)... C programs will be able to be recompiled anyways and S*Basic will work with no problems... For the rest well..... RIP! :-) >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.) The mechanism yes, the coding no... because the main problem I see is that after the Dragonball MX-1, Motorola will be moving (slowly or fast I don't know) away from M*Core architecture. What's going to happen when the only processors we have left are essentially ARM-7 series CPUs or PowerPCs? A C oriented (or other higher level language) QDOS clone will be portable enough but QDOS...? Then emulation won't be an option but a necessity if you know what I mean! My proposal is as follows: Grab the best parts of QDOS Classic, pair them together with the best features of Minerva and translate the lot to a higher level language... C is ideal for this job since it could be regarded as a high-end macro assembler in a way.. :-) Hack into SMSQ/E to see how it does things that it does and repackage the lot as an OpenQDOS or OpenSMS or whatever you want to call it! That's all, Phoebus
