|
Post by gsteemso on Nov 1, 2014 4:14:21 GMT
We all know about CP/M and GEOS. I believe that’s almost entirely because those are the ones that you could buy bundled with your Commodore. Of course, we also know about Miro’s new ACE OS that hasn’t reached its initial release yet, but that is far from all there is to discuss in this section of the forum. There were a large number of other OSes made for Commodore machines “back in the day,” most of them amateur efforts, but since most people had no realistic way of getting a copy at the time (and the commercial ones all cost far too much besides), none of them ever really caught on. Probably the most complete and useful ones, at least that ran natively in 128 mode, were (1) the original ACE OS by Craig Bruce and (2) LUnix by Daniel Dallman et al. Release #16 of ACE is still available on Craig Bruce’s website at www.csbruce.com/~csbruce/cbm/ace/. I’ve run it, it works well, but apart from the Zed text editor and maybe the native assembler that runs on it, there is little benefit to be had in doing so, because no one else seems to have written anything for it. Still, some of the underlying technologies are very impressive, even if few people seem to have made any use of them. I especially like the way binaries for that OS run unmodified on both C64 and C128. I wish more software systems allowed that. LUnix (the “Little UNIX”—see lng.sourceforge.net/) was more recently updated and is very capable in terms of RS232 communications, but has apparently stalled at version 0.21. I haven’t tried it yet, though there does seem to have been a little more software written for it than there was for ACE. Its home page is silent on whether the same program binaries will run under both the 64 and the 128 versions. There were about twice or thrice as many of these alternate OSes available for the C64 as there were for any other Commodore 8-bitter, presumably due mostly to the 64 simply outnumbering all the others—all the others combined, as I understand it, though I don’t have any hard numbers on hand to back that up. Notable examples include He-Who-Must-Not-Be-Named’s successor to GEOS, Wheels, which is supposed to have been pretty good from what I hear but required RAM expansion… pretty much a non-starter for most people, due to how hard it is to get hold of either a genuine REU or one of the modern imitations. There were several others, of course, though I am only aware of one such that was relatively complete: PROMAL. ShadowM has an entire page devoted to PROMAL over at www.lyonlabs.org/commodore/onrequest/PROMAL/index.html. It was a remarkable achievement for its time, but unfortunately only runs in 64 mode, and needs some minor tweaking to play well with multiple serial devices and/or JiffyDOS. As can be seen from the links on ShadowM’s site, jbevren has been rooting around in the guts of PROMAL to see how it works, and discovered some very clever assembly-language programming techniques in use. I harbour the faint hope that this exploratory surgery will, in time, allow PROMAL to be run on a C128 in 128 mode—even though I’ve only thus far managed to make it run in VICE and not on real hardware, I find it a very user- and programmer-friendly OS. I imagine those who have seen me mention it before will be heartily sick of its vaporous nature, but I will close with mention of my own alternate OS project, designed entirely to aid writers (whether of code or of prose). It doesn’t exist yet except as several long-winded and obnoxiously theoretical pages of notes, but I’ve had some (I think) original ideas on how to combine graphical and command-line user interface design into a harmonious whole. Would anyone out there care at all to hear more about it? I’ve not had any time to devote to it lately and it is still classified in my master project index as an “Impractical Pipe Dream” that I do not expect to ever achieve, but that could change if I start seriously bouncing ideas off people.
|
|
|
Post by VDC 8x2 on Nov 1, 2014 21:06:43 GMT
give it a go!
|
|
|
Post by gsteemso on Nov 2, 2014 5:38:13 GMT
All right. I was, in the back of my head, kind of hoping there would be more opinions or other discussion brought forward, but I guess it’s kind of hard to have an opinion on stuff no one’s really described yet.
There are a large number of notional axes along which to plot the position of an alternate OS for Commodores. They range from ostensibly simple considerations of how hardware-specific to make the thing (supporting both C64s and C128s with the same program binaries is a great idea in theory, but makes it very hard to really take advantage of the more advanced underpinnings of the C128 hardware and Kernal without crippling the programming environment on an unexpanded C64), through to the really abstract stuff like what sort of workflow it’s designed to support (user-port homebrew device control? Serial interfacing à la LUnix? WYSIWYG desktop publishing like GEOS?) and what sort of user interface experience you want.
I should expand a bit on that last point. Command-line UNIX has historically been very successful simply because it offered a good compromise between ubiquity, simplicity of UI design, and power of its command expressions… but I personally do not have a good enough memory to use it without having to keep referring back to the man pages for things like the exact syntax of command-line options, even for functions I use quite often. I can’t really say that’s the sort of user experience I want to aim for, though the example of the old A/UX “Commando” utility shows that it can be greatly mitigated (albeit with a lot of effort).
Conversely, the original Mac OS (actually a brutally reduced reincarnation of the Lisa Office System) was excellent (well, for its time anyway) at being straightforward for new users, but the decision to completely omit any sort of command line (or other system with similar functionality, like the Mac OS X Automator could be in modern times if its effectiveness were improved to match its potential) basically killed any initial hope of its effective use by power users; even Apple’s own engineers found it necessary to write a standalone command shell to get real programming done on a Mac. (It was called Macintosh Programmer’s Workbench (MPW), and at one point sold for about a thousand dollars to commercial developers. Of course, much later on, they eventually twigged to the fact that making it inaccessible to write software for their platform wasn’t doing them any favours, and gave it away free online.)
These experiences are illuminating because they make clear some of the approaches I don’t want to take. But I digress; I was listing the dimensions along which an alternate OS for Commodores may be laid out or measured. We have the whole can of worms labelled “compatibility,” in aspects of both hardware and software — for example, should we try to support the execution of programs designed for other environments, such as the popular but rather limiting GEOS, or André Fachat’s admirable cross-OS lib6502? What about all the myriad incompatible disk-drive-type devices or flavours of RAM expansion?
Then we have the issue of supporting end-user programming, or at least scripting. The stock Commodore BASIC-in-ROM doesn’t really support much else, and systems like PROMAL are almost entirely designed around it as well. Obviously, making it difficult or inconvenient would be a huge step backwards and encourage people not to use the new OS. So, we want something at least as powerful as PROMAL, and ideally even more so like in a UNIX shell; and we want it easy enough to write that you don’t have obscure punctuation errors hindering your progress for an hour while you try to track it down. Basically, something like an unholy fusion of Perl (for power) and Lua (for textual simplicity) would be a good place to start. A really powerful default command-line editor would be an obvious feature to require as well.
I suppose, having mentioned all of these dimensions of the OS design space (there are many others I can’t recall just now, too!), I should mention my preferred answers to the design questions they pose, and give some explanations as to why I settled on them.
The first thing I mentioned above was, “What hardware should it run on?” Initially my thought was to make it C128-specific, as having a minimum of 144 KiB of RAM available is far preferable to having 64 KiB or less, as all the other commonly-encountered Commodore 8-bit machines do. (I know things like the B-series, the SuperPET, and the CBM 8x96 can do better than 64 KiB, but they are relatively rare—I certainly don’t own any of them!—and it is very difficult to design to a common subset of them and the C128, especially given the others’ lack of a bitmapped display mode.) However, after recalling just how pleased I was on encountering Craig Bruce’s ACE and the notion of having a software collection that honestly didn’t care whether I ran it on a C64 or a C128, I’ve come to the opinion that I should transparently support at least those two platforms as a minimum. Others would be nice in theory, but not having a VIC-II/IIe available would severely hamper UI portability to any other device, I think (not in terms of the OS itself, but it would make it very hard to write things like cross-CBM-platform games, for example). I’d love to be proven wrong about that—anyone?
Next we have, “What sort of workflow is it to support?” This one, at least, I am quite clear on. My original motivation for writing my own OS was that I wanted a GUI text editor suitable for writing stories, but I didn’t want my creative process (such as it is) to be easily interruptible by things like IRC, email or instant messaging. A custom GEOS program was the obvious initial vehicle to provide this service, but alas, GEOS is pretty much incapable of properly supporting a 400+-raster VDC screen, such as would be most useful for serious word processing; 8-bit Y-coördinates (that can’t exceed 255) are pretty much set in stone throughout that OS. (Literally, if we consider that computer chips are made of silicon.) So, if I had to rewrite pretty much everything to do the job and knew for a fact that I had a C128 available to do it with, I might as well completely skip over a lot of aspects of GEOS that were—for example—compromises due to the limited capacity of a C64, or required for things like printers that very few people make extensive use of at home any more. Ergo, a new OS. So, to state it plainly: I want powerful facilities to create, edit, transform (e.g. by running some sort of custom programming on), and transmit (to the Internet, ideally) text-based documents of various types. A sharp eye will note that these steps to the publication of a story or article look quite startlingly congruent to the steps for compiling and then distributing a new computer program, which after all starts off as linear text in almost all programming paradigms. Ta-daa!
Third: “What sort of UI should it have?” This one is extremely subjective. After extensively reading up on OS and UI design, I came to the conclusion that I wanted the ease-of-use of a spatial GUI, and I wanted the power of a command line, and I wanted them so tightly integrated that neither would be a “subshell” (for lack of a better word) of the other. What am I talking about, you ask? Well, Windows 3.x had its GUI as just a rather limited program that executed within the DOS command line environment. The classic Mac OS required a separate, non-OS program to be run if you wanted a command line, and even then it was barely integrated with the rest of the OS at all unless you did a lot of support work yourself. Plainly, neither of these was especially useful for serious development; but the modern approach, which basically has a GUI that you get a command line in by running a much-better-integrated but still separate program, is not really all that much better, IMO. Drag-and-Drop and copy/paste functions can mitigate the disconnect somewhat, but you basically still have two completely unrelated access methods into the guts of the OS that almost completely fail to interact, much like oil and vinegar.
There is another way, and you’ve seen it before. Around 30 years ago, the microcomputer-assisted spreadsheet program was born, and either at that time or shortly thereafter, some bright spark figured out that having an editing area for the current cell that was disconnected from its displayed location on the virtual spreadsheet made a lot of things easier, especially in the days of sharply limited screen size. (That last point seems strangely relevant to programming on an 8-bit Commodore machine, doesn’t it? What a coincidence.) So, if you have suitable user interface functionality to allow manipulation of both a visual display and a command line, you can have them both active at once, switching the keyboard focus back and forth at the tap of a key or the click of a mouse button. If you’re doing something purely visual like playing a game, the command line can slide off the screen until you or your program summons it again. If you’re constructing a lengthy command line in the “outermost” shell environment, the area occupied by it on screen can grow as necessary—even with word-wrap and so forth, if you want it. Strangely, I have never seen an OS that used this approach (which, lacking a better name for, I have dubbed the “Hybrid Paradigm Interface” or HPI, by analogy to CLI and GUI), and even many spreadsheets have rather poor integration betwixt the two modes, which seems quite pathetic after 30 years of continuous development.
Fourth and fifth, “What software should it be compatible with?” and “What hardware should it be compatible with?” The former is pretty straightforward; almost no existing software fits well with the HPI model, but we could fake it if there’s a reason to. The existence and surprisingly wide adoption of lib6502 seems like a good reason to, IMO, but I don’t think there are many others I can say the same for. Native CBM programs, for example (whether assembled or in BASIC), are usually extremely platform-dependent, and also tend to consume resources that an alternative OS would normally reserve to itself. That said, the GEOS disk format has possibilities. More on that in a future post. As to the question of hardware, that one’s a no-brainer; if I can contrive a way to test with a given bit of gear, I should make it work! Memo to self, acquire a cartridge-port expander.
Sixth, “How should it support user programming?” There are a heck of a lot of ways to answer that one. It’s really two questions in one; namely, “What programming paradigm and language(s) should it be designed for?” and “What sort of editor should it have?” Even Commodore vaguely knew the editor was important, not that they actually put that much effort into it until the C128 came about.
The question about programming paradigms has as many answers as there are programmers in the world, and some of them even agree with one another. I’m inclined to postpone discussion of that one until I hear some arguments one way or another, though as a default position to be swayed from, I think a more user-tolerant version of a UNIX shell would be a good place to start.
The other question, about the nature of the editor, is pretty straightforward; basically, I want it as user-friendly as the TOPS-20 excutive (which I have seen described as “A great improvement over its successors”) and to have at least as much power, flexibility, and command support as the well-known Mac text editor, BBEdit (more accurately, its free cousin TextWrangler; I haven’t been able to afford the actual BBEdit since the 68K Mac days). Among other things, this implies multiple open editing/command sessions at a time, and the ability to scroll up to look at stuff that has already gone past. It also implies a variety of powerful hotkeys for transforming the text and moving around in it, as well as at least rudimentary extended character set (e.g. Unicode) support. (I was thinking the various Latin, math and punctuation blocks would be enough; maybe Greek and Cyrillic too, if there was spare capacity—if nothing else, Western Latin plus one user-selectable other set of blocks at a time would work, such as African or Vietnamese Latin, Korean combining jamo or Japanese kana, though I’d imagine actual kanji etc would be infeasible without both a SuperCPU and a very large storage drive. I, like most, don’t own a SuperCPU, and my µIEC is inoperative.)
So… Thoughts?
|
|
|
Post by VDC 8x2 on Nov 2, 2014 15:47:47 GMT
The amiga got the ui with shell balance right I think. something like that. Think multitasking of some sort is a must.
|
|
|
Post by gsteemso on Nov 2, 2014 16:02:41 GMT
I am embarrassed to say this, but I have never actually seen someone invoke the command line on an Amiga. (I had an Amiga 1000 for a short time, years ago, but never acquired a boot disk or a keyboard for it, so I can’t claim much experience.) What flavour of integration does the command line have with the GUI? Can you have both active at the same time such that actions in the GUI view of the filesystem define the target of the command line, and vice versa? That use case is one of the driving factors behind my UI ideas.
|
|
|
Post by gsteemso on Nov 2, 2014 16:10:02 GMT
I agree with you about multitasking, but only up to a point. I think that thread support allows much more natural program structure in some cases, which is a form of lightweight multitasking. It is annoying to be writing something in one document and have to exit the editing session in order to check something else, so at least a small degree of actual multiprogramming is desirable too. Also, of course, interrupt handling is a form of multitasking, how much so depending on design choices.
On the other hand, we are dealing with a 1MHz machine here. Context switches are expensive. I’d say as a practical limit no more than two to four programs, each having up to, say, 4-8 internal threads would make sense as a limit. Nested unitasking à la Craig Bruce’s ACE should be ample for a lot of things, and having background processes be suspended entirely until they regain the foreground would make sense except for certain types of UI widgets, like alarm clocks and the like.
|
|
|
Post by hydrophilic on Nov 4, 2014 7:42:47 GMT
Umm, previously I thought I had a monopoly on long-winded posts, but your second post, gsteemso, is an awesome contender! All I can say is that, besides CP/M and GEOS(Wheels) which you pointed out, the only alternate OS that I know is the Unix-Like C compiler / executor (umm, PowerC... oh its been awhile!). I've never USED a Mac OS, although I have repaired a few Mac laptops, so I can't comment on that aspect... I've toyed with various UIs for "alternate 128 OS's" myself but never made anything to even a beta stage (thus no releases)... but this is highly related to your Topic#3 "What sort of UI should it have?” For me (100% bias), it should be a text interface because using bitmap graphics is slow without a SUPER-CPU or at least an REU to do fast bitmap updates (REU does not help much with 80-column / VDC). Sorry this post does not address all your points... you've written a bunch of other stuff that I haven't fully digested yet
|
|
|
Post by nonefornow on Nov 5, 2014 20:53:42 GMT
Here's my thoughts. In no particular order. I really do not know of any other OS for the C128 in addition to the one you mentioned. And I have not use any other except for GEOS. But if we are discussiong, on a theoretical level, the options, features, and functionality of a new OS for the C128, I think, we should keep in mind the old DOSShell, just for reference. It is both a GUI and not. It allows for text modes and graphic modes. It sits on top of an OS (DOS) but also adds functionality for the users that do not want to always have to type commands, altought it has its own sort of CLI. It runs all the programs that can run under the OS.
In that sense GEOS had to produce not only the OS but also all the programs such as spreadsheets, wordprocessors, games etc. A DOSSHELL like OS would could sit on top of basic while running all existing programs. Use of the RAM is almost a necessity and with the Shell in RAM will not interfere with the software. Unless such software makes use of the RAM. Of that I am not sure.
In reference to the issue of "user's programming" to the extent that the user's programs run in Basic or ML the OS will support, and it does not forces the user to learn a new programming language.
Back in the days of DOS 6.22 I liked DOSSHELL better than Windows (3.1?)
|
|
|
Post by gsteemso on Nov 5, 2014 23:26:19 GMT
I hadn’t heard of DOSShell before your post. I’ll look that up.
An “interstitial” type of OS that sits between BASIC and a regular Commodore program suffers from the rather severe problem that all but the most trivial such regular programs expect to have access to every scrap of the machine, leaving no place for the interposed shell to hide. That’s why you can launch a BASIC program from GEOS but you have to reload GEOS from scratch afterwards. Otherwise, not a bad idea.
I must point out that one reason for writing a new OS is to make services available that existing programs do not have access to. Obviously, taking advantage of such services will need new software.
|
|
|
Post by nonefornow on Nov 7, 2014 1:01:44 GMT
Enter "RBOOT". RBOOT in GEOS loaded itself into the memory of the REU and allowed to rebott without losing anything stored in the REU. That's were the "shell OS" could reside while waiting for commands, since most programs to not make use of the REU.
I concurr that the OS should make services available, add functionality, but not necessarily recreate the existing services. I.E. in addition the the OS GEOS also added a wordprocessor, a spreadsheet a few other apps. That in a form or another existed running from BASIC or ML.
|
|