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
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!
The world’s only gsteemso
Agitator-in-chief for the Seattle Retro-Computing Society
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.
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?
The world’s only gsteemso
Agitator-in-chief for the Seattle Retro-Computing Society
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 !