|
Post by gsteemso on Apr 17, 2015 20:22:34 GMT
any more progress on this? Not really, no. I’ve been short of time, not that that really excuses anything. I think part of the trouble is that I keep thinking of new features that would be nifty but are not actually necessary. I still think of this project fairly often, I just haven’t pulled together any thoughts coherent enough to share just yet. All in good time, eh?
|
|
|
Post by hydrophilic on Apr 18, 2015 10:40:46 GMT
I know what you mean... VDC8x2 is still working on his game, I'm still trying to finish my PC compiler of C128 videos, and still I still need to send Mirkosoft an updated version of VIC-IIe Interlaced Text Mode... so many projects, so little time
|
|
|
Post by gsteemso on Feb 20, 2016 1:12:17 GMT
I have just run across this newly developed OS (C64 only, it appears—drat!), which attempts to adapt some UI concepts of iOS to our beloved Commodores. Not sure how useful it is absent the hardware mod to add a touch screen, but this illustrates how much room there still is to experiment in this realm!
|
|
|
Post by robertb on Feb 20, 2016 3:44:55 GMT
I have just run across this newly developed OS (C64 only, it appears—drat!), which attempts to adapt some UI concepts of iOS to our beloved Commodores. Yes, we saw this at a FCUG meeting a few months ago. Many months ago, gsteemso said: > ...and the commercial ones all cost far too much besides), none of them ever really caught on. Wheels 64 and Wheels 128 were commercial and inexpensive... just in the mid-$20. Wheels had the slew of GEOS apps which it could use. For free, there was MegaPatch 64 and MegaPatch 128, along with enhancements, TopDesk v4.1 and WinDesk v1.0. Both needed RAM expansion, and both used GEOS apps, too. Then there was WiNGs, which needed a SuperCPU in order to operate, because it was a 16-bit O.S.. It was limited by the few apps that were developed for it -- Ajirc , Fileman , Mail , MovieTools , Ned , SpiffyPaint , and telnet. > ...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. Well, if I could get that Silicon Valley engineer to get past his prototype, there might be a new RAM expansion for C64's and C128's. I haven't heard from him in months, though I was available to meet with him during my 3-week Christmas vacation. I hold out hope that I will see him again at Maker Faire 2016 in May. Truly, Robert Bernardo Fresno Commodore User Group www.dickestel.com/fcug.htm
|
|
|
Post by gsteemso on Mar 1, 2017 8:23:51 GMT
Well, it’s certainly been a while since I had anything to add to this discussion! I am finally getting more or less acclimated to full-time employment (which had not been a sustainable option in the past due to long-term health issues), and so I now have a few minutes per week that I can spend on retrocomputing.
I still intend to move forward with many of the concepts that have been touched upon in this thread; though, as naturally happens when you get several people brainstorming at once, some of them are either implementation details better addressed later on (e.g. VDC raster interrupts), and others might be better served as parts of other projects entirely (such as implementing recently-developed programming languages on 8-bit Commodores).
Having allowed this whole business to percolate through my mind over the past several years, I have reached a few pertinent conclusions:
• I’m confident that it would most likely be possible to keep most or all of the OS in RAM even on an unexpanded 128 — but doing it would leave so little free space for user programs as to be utterly impractical. Thus, using the same kinds of workarounds that contemporaneous OSes used to be lumbered with will be unavoidable. Briefly, the OS will need to be carefully modularized so that only the most often-needed functions are permanently resident, and the remainder are divided up in such a way that most programs can remain fairly performant with only a few of them in context at a time (i.e., the vast majority of user programs MUST be able to perform their core functions without needing to constantly swap OS modules back into view; more specialized operations would normally be infrequent enough that the added swap time wouldn’t really be noticeable to the user).
• With the benefit of several years’ perspective, I can see that the potential project of mine which initiated this whole discussion (a comprehensive system for creating, manipulating, processing, and transmitting streams of Unicoded text files) would be of roughly the same complexity regardless of whether I did it as an integrated suite of programs, or as a full-blown OS. There are surprisingly few factors involved which would lead me, or anyone else for that matter, to choose one path over the other! Here are the most meaningful few I’ve come up with so far:
- Reusability. I’d like to think that I’ve come up with some genuinely innovative details in the course of all this, even if the vast majority of it is merely a judicious assemblage of very bright individual ideas that others have perfected over the past 30-odd years. Framing it all in terms of an OS would make it much easier for me to add new uses to the whole mess in the future, and relatively easy for other people to benefit from the technology base. The latter point is a lot less meaningful than it sounds, though. It looks to me like very few people indeed ever bother to write stuff that runs on someone else’s aftermarket OS. I think the only reason GEOS managed to be an exception was that it was bundled with thousands of C64s right from the factory, and so was not actually an aftermarket product.
- Rigour of specification. If this kind of project is developed in terms of an OS, it HAS to be much more rigorously defined, so it can be usefully factored into relatively orthogonal-of-purpose modules. A standalone suite of programs has no constraints but its own, so if part of the design ends up being a bit less than well-organized, no ill effects would initially be felt… but future attempts to improve that part of the system could easily be so inconvenienced as to end up bogged down in a boring design-cleanup project, so uninteresting to work on that it never got done. In my specific case, this is a point of extreme and terrifying relevance!
• The components needed for this system to be operable _at all_ are:
- The editor.
- A way to define some sort of filter programs.
- A way to apply said filters to random sequential files.
• The enhancements required to lift the system from merely “usable” to actively “useful” are:
- Unicode support, no matter how sharply limited.
- The filters being definable as simple, textual scripts (i.e., not requiring further user actions before being applicable), in a preëxisting computer language widely deployed enough that some users might reasonably be found to already know it, and the editor being able to apply them to data files directly (i.e., without requiring use of an external utility program).
- The editor being able to comfortably handle more than one open file at a time.
- Some means, beyond Sneakernet, of moving random working files to and from other computers. In other words, network access! Because so few users that own network interfaces own the _same_ network interface, this would pretty much HAVE to be done via some sort of plug-in device driver mechanism.
• The further enhancements required to make the system pleasant enough to use that people actually _will_ are:
- A proper file-manipulation interface. This could benefit from also including a proper disk- and drive-manipulation interface, as well as the use of various minor filesystem enhancements that were introduced by GEOS, but neither of those is essential.
- A customizable display. At a minimum, being able to set the colours, and ideally the typeface as well. Being able to adjust the specific limitations of the Unicode feature would also be extremely useful.
- Mouse support.
- While probably less essential than the foregoing, I firmly believe that designing the whole works around what I described in an earlier post as an HPI (a user interface with both graphical and command-line features, harmoniously blended) would greatly enhance its usability.
• The less well-known underlying technologies I would want to make use of are:
- The concept of “resources,” first introduced by Apple in the early 1980s.
- Half a century of advancements in OS shell design. Functionally, this would draw elements from the TOPS-20 executive, the various UNIX-ish command shells, spreadsheets, pseudo-GUIs implemented on a character-cell display by means of modifiable character definitions (what Commodore developers seem to have begun calling a TUI), and a great variety of other things.
- A well-thought-through device driver architecture.
- As mentioned earlier in this thread, a memory-pointer model based on the excellent work of Craig Bruce, possibly expanded upon to accommodate subsequent hardware developments around the world. Memory management in this system would also benefit from concepts I personally first encountered in the classic Mac OS (if, probably, improved quite a lot based on later innovations!) — these were discussed at length in earlier posts in this thread.
- Relatively recent formalizations of software fault-tolerance.
- Likewise recent work that improves data-packet handling through zero-copy techniques.
There are probably more things I could include in these lists, but it’s after midnight and the household are retiring for the night. Any thoughts on this rambling mess?
|
|
|
Post by jmpff3d on Oct 26, 2018 16:36:10 GMT
gsteemso wrote at start of thread, years ago:
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. Sorry for the NecroThreadBump, but I need to state that nullmodem FX transfers on ACE were the fastest way I had (then) to get data in/out of C-128 to PC universe. I used FX ........alooooooooooot....... Thanks, Craig Bruce !
|
|
|
Post by gsteemso on Mar 1, 2023 20:03:44 GMT
Hi all! It's been a little while, hasn't it? (Losing five years down the back of the sofa cushions could happen to anyone, I'm sure...)
Over that time, I've managed very few further moments to work on this (or indeed much of anything interesting), but I have had a few more thoughts:
• Ideally, I'd like it useable enough to catch the interest of potential users the moment they first tried to run it:
- Supporting a bare, totally stock, system is explicitly required -- both by the stated design parameters and by about half of my _own_ hardware not having any upgrades installed.
- Entry-grade storage drives can only use the horribly slow C= serial bus ("CSB"). Obviously a fastloader would help -- thank you, PiffyDOS! (I think that was the name? I'm thinking of the software-only JiffyDOS package somebody put together a few years ago.)
- Even with a fastloader, I think the best strategy is to simply keep the file size very, very small, at least insofar as is in fact possible. Once a minimally useable user shell has been set up, further code can continue to load; in other words, the lost time while the OS gets _its_ act together can be made less obvious by overlapping it with the time the user takes to get _their_ act together.
• That leads to an obvious question: Just what does need to be present to constitute a minimally but interestingly useable environment?
- It's normal, these days, for an OS to boot directly into its file manager. On a modern-style system, that makes a lot of sense; on an 8-bit Commodore, not necessarily so much. That's a lot of resources to load at a stage when you might not even need them.
- However one chooses to stack the facts, this OS is overtly special-purpose; while there's no reason it couldn't support any task you want it to, it's not going to include more than a handful of things "out of the box". This is especially true given the unlikelihood of more than a handful of people seriously using it, this many decades after the underlying hardware passed into obsolescence.
- With so few resources initially available, and so few things a bare install could do with them, a plain and simple menu interface is the obvious choice. There's no reason at all the user couldn't, later on, effortlessly customize it to suit their tastes.
(Note for those under the age of 45 or so: You've probably never encountered any computer-related thing called a "menu" that wasn't some variation of, specifically, a _pull-down_ menu. That's not the only kind, and it wasn't even invented until a very long time after menu-style user interfaces in general were. Fundamentally, a computer menu is, and looks, exactly like a restaurant menu: It lists the meals (activities) available to you, usually across multiple columns, and you pick one. Originally, you stated your choice by typing; nowadays you'd normally click it like a button.)
• Knowing what the user will encounter, they need to be able to do something with it once they have. I once ran a program on my SX-64, called "DOS 5.0", that we got off of a user-group disk back when those were a thing. It naturally took something like 10 minutes to load, given its size; once it had, it looked very good... but there was smeg-all you could actually DO with it once you had.
- The fundamental purpose of this system is to write stuff. You should be able to pop straight into the editor; and ideally, straight into the script-runner thingummy instead, once you've already written a few things.
- You should also be able to go straight to the file manager, or to some kind of integrated reference/tutorial/user-help system, or to the system settings.
• As I stated in earlier posts, a very long time ago now, ideally I'd want an editor as powerful and (relatively) easy to use as the superlative Mac program "BBEdit", or at least its former free version "Textwrangler". (Nowadays the free version is just the regular version when it hasn't been bought yet, so the more powerful features are simply not visible to the user.)
- TextWrangler's level of functionality is superlative in itself, and far better than anything else I've encountered even on modern Linux or Windows (and believe me, I have searched extensively!). To my limited knowledge, no Commodore or Amiga has ever had anything even within telescope distance of it.
- For obvious reasons, implementing anything that even leads towards software that good is a MAJOR project in its own right; in the near term, I could probably co-opt the 128's screen editor for large parts of a stand-in. That editor is actually surprisingly featureful, for a rush-job Commodore utility; it's just that no one can really tell, because it's so direly under-documented.
• I suspect the user-scripting system would be the most fun part to make, as far as I personally am concerned; that too could easily become a very complex bit of software, even if I managed to rein in the urge for creeping featurism. Once again, it _might_ prove fairly straightforward to co-opt some fraction of BASIC 7 -- which in many ways is already set up conveniently for so doing, given the stock system's careful design which has BASIC and the Kernal abstract everything out as a file, and treat all files pretty equally.
• The help/reference/tutorial subsystem should be relatively straightforward to integrate closely with all other software written for the OS; more than 50 years of UI research has led to a staggering amount of knowledge on the subject being freely available.
• The file manager is potentially a big, hairy point of contention, because absolutely _everybody_ has their own, quite irreconcileable, opinion on how one ought to look and act. The easiest solution I can see is to make that part as modular as possible, so that people can drop in their own preferred software (once suitably modified).
• The system settings wouldn't have much in them, at first; basically, the file manager, the editor, and the splash-screen menu, in descending order, would be the only parts needing much flexibility. As the system became more complete, options for storage-drive, Commodore-bus, WAN, and LAN management would also show up (probably at the front of the priority list, and in that order), but I can't think of all that many more. Leaving it flexible isn't hard and should cover all bases.
If anyone's still following this... opinions?
|
|
|
Post by robertb on Mar 3, 2023 8:30:44 GMT
- Supporting a bare, totally stock, system is explicitly required -- both by the stated design parameters and by about half of my _own_ hardware not having any upgrades installed. O.K. (big snip) Sounds like CBM FileBrowser v1.6 with files to a 128 screen editor and other apps. Splash-screen not in CBM FileBrowser, Robert Bernardo Fresno Commodore User Group - www.dickestel.com/fcug.htmSouthern California Commodore & Amiga Network - www.portcommodore.com/sccanApril 15-16 Commodore Los Angeles Super Show 2023 - www.portcommodore.com/class
|
|
|
Post by gsteemso on Mar 4, 2023 0:27:02 GMT
Sounds like CBM FileBrowser v1.6 with files to a 128 screen editor and other apps. Splash-screen not in CBM FileBrowser Well, you're not exactly _wrong_... I wasn't familiar with that specific program, but the whole idea is that it shouldn't much matter which file manager you use, as it is only there to manage your files; unless of course it can run one of said files as part of its feature set. Regardless, such a program would need modifying in order to (a) not stomp on anything the OS is using, and (b) take advantage of the OS's features. (I should clarify that by "splash screen", I meant the "Outermost Menu" screen you'd see upon loading the OS.) The "OS's features" part is pretty important, because why else would anyone bother?
|
|
|
Post by robertb on Mar 4, 2023 20:40:05 GMT
|
|