Nasta writes:
<>
> Not really a 'BIOS' but rather a more modularized version of SMSQ. For
> instance, not every concievable platform needs a floppy drive. Try pulling
> out floppy support only from SMSQ, see how far you get. For things like
> that one should hardly need to regenerate the whole binary after they have
> searched out all the necessary source fragments and took them out!
> Next big candidate is the OS bootstraping. There is a lot that happens
> before the actual OS takes over, yet there is no way to change this
> speciffically for a platform unless the actual start-up code of SMSQ is
> changed. This should be a module. You mentioned in another email that it
Each platform version of SMSQ comes with its own platform-specific startup
code. These are implemented as modules (a program to view the module names
was published on this list some time ago) Thus, for example SMSQ/E for
GC/SGC contains the following modules:
SMSQ System Loader
Gold Card Initialisation for SMSQ
2.98 SMSQ
SMSQ Cache Handling Code
SBASIC
SMSQ Initialisation - GC
SMSQ Initialisation - SGC
SMSQ Messages
SMSQ GOLD Keyboard Tables
SMSQ GOLD ABC Keyboard Tables
SBASIC Messages
SMSQ GOLD ABC Keyboard
SMSQ GOLD Drivers
SMSQ GOLD CON Driver
SMSQ QIMI Driver
1.53 SMSQ Window Manager
3.08 SMSQ GOLD DV3 Drivers
SMSQ Net Driver - GC
SMSQ Net Driver - SGC
2.29 HOTKEY System 2
Initialise QL ROMs
SBASIC Procedures
If the module and core binaries were kept separate (as link files),
presumably all youd need to generate a platform-specific binaray would be a
linker.
No easy way to separate out the floppy driver, as you say, but the rest
appears pretty modular to me..
<>
> That may well depend on the particular case, some emulators are closer to
> the real machine than others. A way to go into native code for cases where
> this is needed would be a good idea. Candidates, aside from graphics you
> mention would for instance be floating point operations,
I believe this is what MK does with FP: The API is the same (even from
assembler!) so when you call ri.exec (qa.op) youre actually running the PC
FPU (in a suitable wrapping).
> and parts of drivers in general. Ditto the first module executed - system
The driver core, as implemented in the kernel (for lack of the proper
technical vocabulary), would only require invasive surgery if one wanted to
add the concept of layered drivers to SMSQ/E (which I believe one does! But
that sort of thing is not for your average tinkerer.) Actual driver
implementations neednt have anything to do with core SMSQ.
> initialisation, see above. This may well be non-68k native code, setting
up
> the emulator itself, before it starts the actual OS code (68k). Even some
> more complex operations which may not be part of the OS, but would need to
> be things, would need such a feature (anything to do with co-processing is
> a candidate).
<>
> Neither do I, but I don't think that work on the core OS could be called
> 'minor'.
> There are things that could prove quite demanding, for instance interrupt
> handling (multiple levels), memory management (slave block problem),
> multiple processors...
And even some of those could be handled as add-ons.
> >If someone wants to tweak specific parts of the system like SBasic or
> >write a new filesystem it could be very well done outside of the core
> >system.
>
> Assuming it is split from the current source as it is. What I'm getting at
> is that as a programmer, so far you only get to see the monolytic SMSQ.
The
> file system API as far as the OS goes is essentially the set of traps
> available, very rigid and mostly cannot be changed. There is no reason why
> this would not be a separate module. For all we know, it may be - but as I
> said, right now it's all just guesswork (and an educated guess would be
> that it's NOT a separate module).
The end-result may mean taking the Q out of SMSQ/E, but that may not
necessarily be a bad thing.. For those insisting on using their original
hardware there could now be a possibility of upgrading QL ROMs to SMSQ/E
(core in ROM, extra modules on disk (or microdives (only joking ;))
<>
> In an ideal world, 'we are all friends' and all loopholes would not need
to
> be explicitly plugged, nor would the licence have to be enforced with an
> iron hand, but if nothing else, the rather fiery digressions within this
> discussion have already shown that going throug the licence with a fine
> tooth comb, might after all be necessary. The only thing I fear is that
> everyone will loose their patience and things will go back to the way they
> were, something that could have been a very good thing will not happen at
> all.
Id be more worried that someone (possibly someone we dont even know!) may
come in and hijack SMSQ - perhaps even patent it or parts of it (eg the
Scheduler) locking everyone out because it happens to be suited for some
minor or major commercial purpose. I always put a password on my PC BIOS,
not because I need it, but just so someone else doesnt. Is this sort of
thing catered for by the license?
Per
