From: Gábor Lénárt (lgb_at_lgb.hu)
Date: 2005-04-21 15:46:06
hello!
On Thu, Apr 21, 2005 at 03:18:24PM +0200, Baltissen, GJPAA (Ruud) wrote:
> Hallo Gabor,
Errr, what is your forename? Ruud or Baltissen? Sorry but it always a
problem for me, because in Hungarian I would write my name as "Lénárt
Gábor", however eg English uses the opposite order "Gábor Lénárt", but
scheme like "Lénárt, Gábor" is also used eg in English which is exactly the
same order as the Hungarian and we even don't need comma here :-)
> > I was writing about a theoretical system not a C64 ;-)
>
> I know, I only used it as an example to emphasize the need of saving the
> contents of various registers. And the I/O port is a good example IMHO.
> Saving the contents of the SID or VIC in a multi-tasking enviroment is less
> obvious.
Yep. For a hardware like Commodore 64 it would be simply to complicated to
share eg SID between multiple processes (like allocate one channel for a
process ;-), but we can also declare, that using eg SID can be done only by
one process at a time. Eg if we virtualize SID access via a file, like
/dev/sid ;-) than opening it by a process make /dev/sid unopenable ("file is
busy" or something) by other processes. In this way, there is no direct hw
access for processes just for the kernel! Communication can be done with
standard file interface - no direct hw access -. This was the UNIX way:
virtualize everyting as "file" at least from the view point of user
programs. In this way the communication only means file operations.
Sure, for slow systems it can be dangerous since the overhead of this
'virtualization' (I mean, file operation should be done it should be processed
by the kernel etc, while - let's say - for real it would be only some LDA/STA
pair to set some registers in SID). So care must be taken!
> > I mean if a memory area is write protected, ....
>
> Ah, good idea!
>
>
> > Even the read can be denied by simply eg read always
> > zero if page is not readable by a process.
>
> Even better! And zero is the code code for BRK which means that even an
> illegal jump is intercepted. I really learned some nice things today :)
Nice, however we can't do nice tricks can be done eg with an i386 CPU: on
page fault, OS would emit segmenation fault signal to the process. Without
installed signal handler it simply kill the process. However if process have
installed handler, it can get detailed information about the fault and it
can even react to it. It is because the 6502 has not support to abort the
processing of a single opcode ... Btw what about 65816?
- Gábor
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.