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.