At 01:38 μμ 8/1/2002 +0100, you wrote: >On Mon, 7 Jan 2002 00:40:01 +0100, Richard Zidlicky wrote: > > > On Sun, Jan 06, 2002 at 07:32:14AM +0100, Thierry Godefroy wrote: > > > > > > the problems are QDOS specific: > > > > - drivers can be practically written only in assembler, > > > > > > True, but as far as I am concerned (I don't want to restart the > "assembler vs > > > C" flame war), this is not a problem but a GOOD THING ! > > > > may be a good thing for you but not everyone is good enough with assembler > > to write more complex pieces of software in it and hardware drivers are the > > worst nightmare to debug if something doesn't work. > > Realistically we would probably have a few more drivers if it was possible > > to write them eg in 'c' or even SBasic. > >It looks like the "Assembler vs C" war is about to break out again... just >kidding ! ;-) > >Well, nothing prevents you to write device drivers in C for QDOS/SMS (this >will be somewhat tricky because of the limitations on stack space usage but >a possible solution is to use static variables), but you will have to do >some assembler written "glue" code (typically putting registers contents >on the stack before calling the C routine and extracting the returned >parameters from the stack on return) and the result will be very inefficient >drivers... > >As of SBASIC, you will probably appreciate that I did the very first ATA/ATAPI >protocol testing with SBASIC written routines. ;-)
Just my two cents.... (and pardon my cluelesness in many parts) Just got the QDOS/SMS reference manual and begun (thanks partly to the work of Norman with assembler and the good contributions of every savant one in the list) to understand roughly a little more on how SMS works. Based to all Thierry did with the ATAPI drivers wouldnt it be possible to go a similar way (and by reusing as much of Thierry's code - no use of reinventing the wheel!) and provide an interface for ALL devices under SMS? The way I think about it if a Device Driver API (along the lines of the Meta devices proposed by Nasta) was implemented as a thing it would be possible to trap all IOSS functions and translate them to something a device would understand and vice versa. This API (?) Thing could be linked as a module to SMSQ/E together with a UN*X-like filesystem driver written for it and provide at the same time the much needed fs update and a method of adding devices logically (I find that the UN*X like approach of devices being part of the filesystem extremely useful). Additionally it could standarise device driver creation by setting a uniform all-encompassing standard for device driver writing. These being so UN*X like would be able to be written in a high level language too :-). That API Thing being a piece of software not directly linked (and therefore non essential to SMS - try to remove IOSS routines ;-) would be able to be temporarily suspended; thus allowing some form of compatibility with older programs. The way I would see an SMSQ system's startup process with a method like that would be something like: 1. Normal SMS startup 2. Link in the API Thing 3. Attach FS Driver to the Thing 4. Link in new S*Basic commands 5. Load the drivers (if any) that exist on the FS 6. Proceed with normal boot from an SMS partition (could be shut off if we want) 7. Switch to the new fs system and use an SMS system with all the drivers. I know that probably all of the above is wrong, but as with any proposal no matter how far fetched might seem, surely this MUST contain some form of useful idea also.... Phoebus
