| |
Oswald
Registered: Apr 2002
Posts: 5086 |
device independent IO
how good is the kernal in this regard? what has to be done to support mmc / hdd / etc and still being compatible ? |
|
| |
yago
Registered: May 2002
Posts: 333 |
The Commodore-kernal is pretty modern and device-independent, as it offers the same routines for screen,keyboard,rs232,datasette,disk,printer etc..
However, mmc and (non-iec) hdds have been invented after the kernal has been written, and dont use the protocols the kernel knows.
So you need to patch the kernel, or complement it with a cartridge, to get device-independant access to these Devices.
Fortunately, the kernel even provides Vectors for patching, so if the new devices also have clever Software, you wont notice that the original Kernel does not support them.
|
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
so there's no "driver" concept at all ? |
| |
Scout
Registered: Dec 2002
Posts: 1570 |
Quote: so there's no "driver" concept at all ?
There is a driver concept possible, if you look at the Contiki OS for instance.
It's possible, for example, to choose for the RR-NET and the TFE ethernet cards.
One of those drivers are loaded into the OS when chosen in the configuration. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
@Oswald:
http://codebase64.org/doku.php?id=sourcecode:dos_examples
If you do your IO like this, it is device independent. You can also call the kernal IEC routines directly, but those are not device independent, since they assume that the device is connected to the serial bus. |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
how are the device nrs associated with the real diveces?
ie. #1 is always tape, 8-9-? are always disk, etc ? is it possible to add a 'new' device nr with the handler (driver) for it?
ps,
scout, sigh, thats nowhere close to what Ive asked :) |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
0 is "default IO" which is keyboard for input and screen for output.
1 is a tape drive.
2 is RS232
4 to 7 is normally used by printers (serial)
8 to 30 is any other serial device
It doesn't really matter though. A driver can easily redirect any device number to another device. For example, TFR can redirect device numbers 8 to 11 to ethernet. |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
how does this redirection work? |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
$031A Vector: Kernal OPEN Routine
$031C Vector: Kernal CLOSE Routine
$031E Vector: Kernal CHKIN Routine
$0320 Vector: Kernal CHKOUT Routine
$0322 Vector: Kernal CLRCHN Routine
$0324 Vector: Kernal CHRIN Routine
$0326 Vector: Kernal CHROUT Routine
$032A Vector: Kernal GETIN Routine
$032C Vector: Kernal CLALL Routine
$0330 Vector: Kernal LOAD Routine
$0332 Vector: Kernal SAVE Routine |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
okay, so there's no driver concept at all in the kernal.. |
| |
Scout
Registered: Dec 2002
Posts: 1570 |
Quote: how are the device nrs associated with the real diveces?
ie. #1 is always tape, 8-9-? are always disk, etc ? is it possible to add a 'new' device nr with the handler (driver) for it?
ps,
scout, sigh, thats nowhere close to what Ive asked :)
Yes, i concluded that too :P
Anyway, free info which you can use elsewhere :D |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Huh? Ofcourse there is... A cartridge can easily redirect those vectors to own routines which look at the device number and also may continue with the normal kernal routines. |
