Article 42104 of comp.sys.cbm: Xref: undergrad.math.uwaterloo.ca comp.sys.cbm:42104 Newsgroups: comp.sys.cbm Path: undergrad.math.uwaterloo.ca!csbruce From: csbruce@ccnga.uwaterloo.ca (Craig Bruce) Subject: Re: Thoughts about alternative OS's for Commodore Sender: news@undergrad.math.uwaterloo.ca (news spool owner) Message-ID: Date: Mon, 11 Sep 1995 17:38:13 GMT Nntp-Posting-Host: ccnga.uwaterloo.ca Organization: University of Waterloo, Canada (eh!) hermit@cats.UCSC.EDU (William R. Ward) writes: >Now I haven't looked closely at ACE. I have read a few things about >it here, but I got the impression that it is a single-tasking OS that >basically just provides an alternate shell interface. Am I wrong? ACE is that, plus some custom device drivers and a few applications. It's also well designed and very fast. >How do you multitask on a machine with no memory protection and very >little interrupts? Well we would have to take the raster and/or CIA >interrupts for the OS, and in return the OS would provide timers and >other such like interrupts for applications that wish. As long as >applications are written in such a way as to not try to usurp memory >they don't own or interrupts they aren't entitled to, I think it would >work. Comments? Has anyone out there successfully implemented >multitasking on a Commodore? If so how did you do it? Issue #10 of C= Hacking magazine has an article entitled "Design and Implementation of a 'Real' Operating System for the 128: Part II" by some guy named "Craig S. Bruce". It gives a code listing and full explanation of a prototype multitasking kernel... that actually works! The article is also available directly from URL: http://ccnga.uwaterloo.ca/~csbruce/bos2.txt You don't need memory protection to implement a multitasking OS. >Does the 8502 let you relocate the stack? I think I remember that it >can, which would make life a LOT easier for multitasking. Otherwise a >context switch would require copying the entire stack page... Yes, the C128 lets you relocate both the stack and zeropage (although it's the MMU that actually does it). However, on systems that don't do this (like the C64), you only need to copy the portion of the stack that is IN USE (i.e., from the stack pointer to $1ff in memory). The context switching in the prototype implementation is very light-weight, so the active process is switched 60 times a second (more if anyone blocks). >Context switching may require copying memory out to a swap space (REU >or disk) for processes that are not active. This can get complicated >awfully fast. If you're talking about doing this on every context switch, then the cost can become prohibitive. This would only be needed if you're going to have non-relocatable binaries. >I am beginning to REALLY regret not taking an O/S >course in college--I stuck to the theory track. :-( On the other hand, I'm an operating system specialist. I've taken five university courses on operating systems, including my Master's Thesis, and I've written three multitasking operating systems and one uni-tasking one (ACE). I've also been a teaching assistant for two of the OS courses that I have taken. My Ph.D. isn't about operating systems, but it's not too far away from that on the subject spectrum. >With an assembler that's designed to enforce this, it shouldn't be too >bad. Any labels in the code or data are translated into indirect >jumps or cause an error in assembly, period. It'll still be possible >to cheat, but then if you cheat the program won't work right anyway. >Never having written an assembler I hope others will have more to >comment on this than I. It is indeed possible to do what you are saying. It can even be done outside of an assembler. >A compiler would be easier in some ways from >this point of view, since you can design it to never generate absolute >addressing (except for system calls). I don't see any practical alternative to using absolute addressing. >BASIC is a quick way to knock out programs, but it's a pretty lame >user interface. MS-DOS or Unix type command line systems are awfully >primitive. GEOS is painful. Mac or Windows is too idiot-oriented. >X-windows is kind of nice but has some of the problems of the Unix >command line and is monstrously large. So everything's bad and the universe should just give up? >So I'm not sure what I would like for a user interface, but something >that's neither a CLI nor a GUI in the normal sense would be >interesting. I don't want to rely on a mouse (and keyboard shortcuts >like Windows uses aren't much better), but I want to have the mouse be >an option. I want to have the keyboard be the main input device. >Support for joysticks, etc. should also be present. Are you hinting at menus or something? >The keyboard handler should be intelligent. I'd like to separate away >the character typed from the modifier keys (Ctrl, C=, two Shift keys, >Alt, Shift Lock, Caps Lock...). I think this is doable based on what >I know of the way the keyboard is handled. This would allow lots of >"bucky bits" for clever user interface things (yes, I am an Emacs >user, does it show?). It's very doable. The C128 Kernal allows you to take over the function that converts from scan codes to characters and fills the keyboard buffer. Or, you could completely take over the keyboard scanning, like ACE does, and do it all yourself. >Take the first block of the file and use it as a list of pointers to >the blocks used by the file. It would consist of: > > Byte Meaning > 0 Track of next block (as usual) > 1 Sector of next block (as usual) > 2 Track of first data block > 3 Sector of " " " > 4 Track of second data block > 5 Sector of " " " > ... ... > 254 Track of next *index* block (or 0 if none) > 255 Sector of " " " " > >If there were more than (256-4)/2=126 data blocks, then a second index >block would be included. You might find it a little more convenient to keep the index separate from the file, and to keep forward and _backward_ pointers to index blocks, in case that gets you to your destination faster. Of course, having an index means that you have to update it whenever you append a block to the file. >COPYRIGHT(C) 1995 William Ward. Not for distribution via Microsoft Network. I like this! You should add that "by allowing this message to be distributed via Microsoft Network, Microsoft Corporation agrees to pay $1000.00 a penalty to the author for each offence." Keep on Hackin'! -Craig Bruce csbruce@ccnga.uwaterloo.ca "Insight don't come cheap."