BeGirl wrote:
> >> it, which is a concern for me as I run BeOS.
> >Is there a (Turbo) Pascal compiler for BeOS? If so, may be Joe could
> be
> >pesuaded to make a BeOS version.
>
> There's Free Pascal:
Brrr! Don't say such evil things! ;)
But that won't really help, I guess. StarCommander has two things to it:
the actual device interfacing, and the userinterface. The userinterface
probably needs to be severely hacked to run on anything except Turbo
Pascal (Allthough a friend of mine, who just happens to be part of the
core development team of FreePascal, claims that their TurboVision
implementation is fairly good).
However, the device interfacing probably needs to be entirely rewritten.
SC relies on the fact that it's running in a single-tasking environment.
There are quite a few timing issues here; the serial bus demands next
to real-time behaviour of the devices. Under DOS, this isn't much of
a problem, since there *is* only one task. Under Win95, the OS can
be compromised in such a way that a process is granted all the CPU time
it wants. Should Macs have parallel ports, it would certainly be possible
to port SC to MacOS prior to OS X, since MacOS used cooperative multitasking,
meaning that every program can steal as much CPU time as it wants, as
long as it avoids certain system calls.
Quite frankly, I don't know BeOS that well, but IIRC it is a modern OS
using pre-emptive multitasking, which is the main culprit. In a pre-emptive
system, processes don't *yield* control, they *loose* it. If a program
has exceeded its timeslice, it is interrupted wherever it just happened
to be. This means that you can't just use a ported version of StarCommander
just like that. The program would be interrupted at random places, and
isn't even really aware of it. The Commodore serial bus doesn't support
this; it uses no handshaking when the transfer is in progress.
cbm4linux uses a different idea. It is a kernel module IIRC, which means
that it runs within the kernel. While a userland-process cannot disable
multitasking (Thus guaranteeing real-time behaviour), a kernel module
can. Unless I'm mistaken, it disables multitasking for a while, uploads
a custom fastloader (which uses a completely different bus protocol,
thus lifting the real-time request), and enables multitasking back again.
After that, userland processes can talk to the serial bus at their leisure;
if a context switch arrives, it won't hurt.
Unfortunately, this means that it isn't portable as-is. The used protocol
would surely be portable to BeOS, but the method of temporary disabling
multitasking is very linux-specific. However, I think that the major
idea isn't that bad. The only issue is: Can multitasking be disabled
for a brief period of time?
Kind regards,
Martijn
--
Martijn van Buul - Pino@dohd.org - http://www.stack.nl/~martijnb/
Geek code: G-- - Visit OuterSpace: mud.stack.nl 3333
Kees J. Bot: The sum of CPU power and user brain power is a constant.
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail 2.1.1.