Anyone who's ever tried to develop a sizable application on the 128 has probably run into the same thing: it's can be a pain in the arse building something that uses more than 64K of code and data. Banking is a powerful feature, but adds an extra layer of complexity to the design process in order to manage it well. And if you want to write something which uses more than 128K, add to that the careful management of disk and/or RAM expansion resources. Moreover, there are hardly any libraries to help you bring all these things together.

Of course, better programmers than myself have an easier time of it. Heck, many of you write such tight, optimal code that even 4K feels luxurious and roomy. Besides, half the fun of developing for classic systems is the challenge of doing much with little, isn't it? I enjoy that challenge too, up to a point.

Working on my Sierra AGI interpreter, wanting to keep most of it in C for ease of development and maintenance, memory usage quickly became the biggest issue. The traditional answer has always been, "Forget C and use Assembly", but I didn't find that prospect appealing due to the size of the project. I began writing helper routines to abstract out some of the nitty gritty details of memory management, but in spite of being useful, things were still more complex than I wanted them to be. Being a lazy programmer of the 1st degree, I wanted to simply write my program and not worry where or how to fit the various pieces.

And therein was born the seed for the SLOPe (the Sloppy and Lazy Operating Platform experiment... officially pronounced "sloppy", but can be the more respectable-sounding "slope" if you prefer), the C128 operating system for sloppy, lazy programmers like me who don't like to think too much. In other words, its very premise is antithetical to every principle of developing for a small machine.

I've been working on it off and on for a while now, more so recently since being sick gave me more time to put into it.

So, what is it besides an excuse to behave badly? Here's an early screenshot:



(My apologies to the Butterfield family and the Commodore community for using Jim's picture, but it was the first thing I ever loaded and displayed with SLOPeView. In contrast to myself, Jim knew how to do much with little, and was wonderfully gifted at teaching other people to do the same. He used to say that he tried to explain things well enough that even a stupid person could understand. But I'm both stupid AND lazy -- a terrible combination! Again, I'm sorry to associate a truly great man with a messy project like this, even indirectly.)

There wasn't anything to take a screenshot of until recently. The bulk of the code has to do with memory management, program relocation and task servicing. The basic idea underlying all of it is that banked memory, REU and disk are managed as much as possible by the OS so that things are easier on the developer and user. The chief development platform is CC65 and CA65 for now, with LD65 modified to produce a header with extra information that's used by the program loader. The development side does require some help from the programmer, however it's very simple to work with. On the user end, no special accomodation needs to be made.

Every program can have its own stack and zero page, though programs with lesser needs can share. Multitasking is preemptive. Time is allotted based on priority level and idle state and ultimately should be adjustable by the user (but I haven't put together a means to do that yet).

Otherwise, the OS is pretty simple and limited at the moment. The GUI's visual aesthetic is a mix of classic Mac OS + BeOS + whatever else I feel like throwing in. Rounded corners optional.

Bad stuff:

* Doesn't use the overscan area
* No interlace support
* No color
* Windows always aligned to horizontal cell boundaries
* Cruddy default font is hard to read
* Mixing different font heights messes things up
* Mouse pointer is freakishly huge
* No VIC support
* No sound support
* No harddrive support
* No printer support
* Twenty years too late


Good stuff:

* No interlace support!
* Windows can be positioned freely in the vertical direction, no cell boundary crap
* Proportional and fixed font support works... as long as font size doesn't change
* Bold, italic and underline support seem to work okay, though not seen in the screen above
* Fonts can be pretty easily converted from TrueType (this is done on a PC, not the 128... Mac users, any way to completely disable font antialiasing in OS X? If not, you won't be able to convert fonts)
* The OS supports Unicode, so with the appropriate font any language can be viewed
* As seen above, desktop can be larger than the screen (SLOPePad is extending into virtual screen area), scrolling via the mouse, joystick or keyboard controls
* Background images
* Scrolling is fast
* SLOPeView uses nifty Atkinson dithering just like in the old Mac HyperScan program
* Swap current SLOPe memory state to REU or disk, run BASIC or other programs, then come back to SLOPe right where you left off... and vice versa


Planned stuff:

* Harddrive support
* Sound
* VIC support (as a second display)
* Printing
* New system font
* Facility to convert GEOS fonts, and GeoPaint and GeoWrite documents
* Networking support (sort of works now under emulation, but relies on the conjecture that Retro Replay + RR-Net should work on a real 128 in 128 mode)
* Apps based on a client/server model, with the client on the 128 and server running on a modern machine (example would be a modified Gecko engine on a PC converting web pages to a lighterweight format for display on a C128 web browser; I'd also like to do a PDF viewer the same way)
* Mount networked disk images, folders, print to networked printers
* Other cool stuff
* Finish my AGI interpreter, since that was the whole point of doing this anyway

Haven't decided on licensing yet, so there won't be any release until I do. I've avoided including any GPLed code in the OS itself so that I'm not forced to use the GPL, which I think is too restrictive for what I want. Probably something like the BSD license is more what I'm looking for, though I need to look at it more closely to make sure. Some apps or tools may use GPL code, so they will be GPLed, but the OS being a separate entity will have its own license.

I might separate out the memory and disk stuff as an alternate package for people not interested in developing for the GUI.

Anyway, I'm hoping that by the time I have a real 128 I'll have a useful if inelegant new OS to run on it.

Wow! This is fantastic :buga:

Keep up the good work. :hurra:

Omigod!

Well, we can't let those SymbOS people have all the fun, right?

I need some advice about interlace support. Is it important to have it? From what I've read over the years, VDC interlace flicker seems to be almost as reviled as the Amiga's for the strain it causes on the eyes. Does anyone here use it comfortably (perhaps using Zed with interlaced text)?

The main problem with supporting it from the OS side is how to handle the change in aspect ratio it introduces. The easiest thing would be to ignore it and let everything look smushed, which is probably not ideal for the user. Or every font and GUI element could have an interlaced and non-interlaced version. Personally I'm inclined not to support interlace in-desktop since I already allow desktops larger than the visible screen area. SLOPe does allow programs to take over the screen, so if someone wants to support interlace in a fullscreen app, they can do so, though GUI routines wouldn't work properly. I guess I should build in at least the basic interlace framework so that if someone wants to build on that they can do so without starting from zero. Color is complicated too. Due to allowing proportional fonts of varying widths and heights, it's impossible to support color use freely because of clashes within color cells. However, if someone wants to take over the screen, they can work it out for themselves.

Of course, VIC support adds many of the same issues, but I was thinking of the VIC as more a supplement to rather than extension of the GUI. Eg. using it for viewing color images. However, if people really want to be able to drag windows from the main desktop to the VIC screen, similar aspect ratio issues come into play as with supporting VDC interlace.

If I can do an informal survey here, how many of you have some sort of RAM expansion for your 128(s)? If you do, what kind and how much RAM? Anyone ever done an internal expansion?

And how many of you have harddrives that you use from 128 mode? What models?

By the way, what sort of performance can one expect from the hard drive options available for the 128? I imagine the 128 itself is the only limiter there?

Nice project!  Can you do a video of it running and put it on Youtube for us all to admire ?

My contribution to the Survey:

RAM = Standard C128 with 512K 1750 REU
Hard drive = Nope ... only thing close is the MMC64+RR-NET+Retro-Reply

Regards!

Quote from: nikonikoIf I can do an informal survey here, how many of you have some sort of RAM expansion for your 128(s)?

I do.

Quote from: nikonikoIf you do, what kind and how much RAM?

Up to 2 megs on a 17xx expander, and I have RAMLink at 16 megs.

Quote from: nikonikoAnyone ever done an internal expansion?

Not me.

Quote from: nikonikoAnd how many of you have harddrives that you use from 128 mode?

I do.

Quote from: nikonikoWhat models?

CMD hard drive

Quote from: nikonikoBy the way, what sort of performance can one expect from the hard drive options available for the 128?

Faster loading and saving... even faster with support for JiffyDOS.

Quote from: nikonikoI imagine the 128 itself is the only limiter there?

I would think so.

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/

At the moment I have a 512KB 1750, a 512KB GeoRAM, a 16MB RAMLink and a SuperCPU128 with 16MB.
The hard drive I use is based on 64HDDPro.

Quote from: nikonikoIf I can do an informal survey here, how many of you have some sort of RAM expansion for your 128(s)? If you do, what kind and how much RAM? Anyone ever done an internal expansion?

I have a non-funtional 1750 that needs some love, but that's it.  If I can get my hands on one for less than $100 then I will do so.

Quote from: nikonikoAnd how many of you have harddrives that you use from 128 mode? What models?

I have a RAMLink with 16MB and a 4GB CMD HD.  I also have a very kick-ass 64HDD system.

Quote from: nikonikoBy the way, what sort of performance can one expect from the hard drive options available for the 128? I imagine the 128 itself is the only limiter there?

The RAMLink is exceptionally fast, nearly instantaneous most of the time.  The CMD HD is still very fast, even if you don't have JiffyDOS as it does support burst mode.  With JiffyDOS it's about twice as fast as with Burst Mode since Jiffy sends two bits at a time instead of one.

Thanks for all the responses! I'm envious of all the great hardware you guys have. I pretty much expected that anyone still running a 128 after all these years is a pretty serious user and would have some serious accessories to go along with it.

I'll post a YouTube link here once I get a video up. I've also invited someone from the 128 community here to be the first beta tester if he's brave enough and not too busy with other things.

Sorry to any of the c.s.c. people who followed Lance's link looking for something interesting, but there probably won't be any release outside of the C128 Alive community for a while. Trust me, you don't want to see it in this early state of crapitude anyway. You have much better, non-sloppy OSes to enjoy with OS/A65 (is it still called that?) and ACE. However, I will be putting together a document explaining the memory system, how to develop for the OS, and what changes are necessary to the CC65/CA65/LD65 toolchain to support it. Modified versions of those tools will be released in accordance with the licensing.

I've got a standard flat C128 w/64k VDC RAM expansion, 256K 1764 REU, and 64HDD based serial hard drive. 64HDD runs just a little faster than a 1541, though I hope to change that soon with 64HDD Pro (fast serial support) and a parallel cable. That will make it faster than a CMD, they say.

True preemptive multitasking and client/server preprocessing support with a PC? Let me have it!

I like the idea of supporting both monitors, especially in a multitasking environment.

Great work so far! Thanks for sharing.

Quote from: airshipTrue preemptive multitasking and client/server preprocessing support with a PC? Let me have it!

Cool! I'm glad people are open to the idea. Though doing everything on the 128 side has an awesomeness to it that will never be surpassed, I think it's reasonable to consider modern computers as hardware accessories which true purpose in this world should be to serve the 128.

Standard flat 128 with JiffyDOS, 512MB 1750 REU, and Retro Replay/RR-Net.

Quote from: nikonikoI'm envious of all the great hardware you guys have. I pretty much expected that anyone still running a 128 after all these years is a pretty serious user and would have some serious accessories to go along with it.

I actually didn't get a 128 until five years ago, after being without a Commodore 8-bit since 1987.

Quote from: baconI actually didn't get a 128 until five years ago, after being without a Commodore 8-bit since 1987.

I think that's pretty common too. Commodore 8-bit Withdrawal can get to be a serious condition, and the only viable treatment is to acquire another machine to fill the void.

I'm trying to fix my font rendering problem before I put a video up, but if anyone wants to subscribe to my Youtube channel, my username there is 8502inside.

Mine is currently acting flaky, so I've got to dig out my chip reserve - er, I mean my fine collection of quality vintage commodore 64 computers - and see if I can find a working CIA in there somewhere. I'm sure that's what it is. That's what it ALWAYS is. My backup C128 is flaky, too, so I might as well pop chips in and out of it until lit works, as well.

I don't have any fancy-schmancy accelerator plugged into mine. While that would be fun, I'm more interested in what you can do with a standard machine. Of course this doesn't keep me from speculating about what can be done by supercharging one. And maybe, someday, if I get the resources,  who knows?

I do like having my little PC acting as a 64HDD server for my C128. As you say, that only seems natural. Having one serve up web pages and PDFs would be uber-cool, too.

Quote from: airshipThat's what it ALWAYS is.

What is with those CIA chips anyway? Why are they such a common failure point?

Quote from: airshipI don't have any fancy-schmancy accelerator plugged into mine. While that would be fun, I'm more interested in what you can do with a standard machine.

It would be interesting to see how many more tasks a SuperCPU would be able to handle, but I'm really more interested in unaccelerated machines. I'm not planning any special SuperCPU enhancements for SLOPe, though if something breaks when running with it I'll try to make some accomodation. I'm still trying to balance the task system for 2Mhz, and VIC support will open up a whole new can of worms.

Quote from: airshipI do like having my little PC acting as a 64HDD server for my C128. As you say, that only seems natural. Having one serve up web pages and PDFs would be uber-cool, too.

Yeah, that's been the main thing bugging me about the PDF library -- no way to view the PDFs on a 128. Ideally I'd love for people to be able to visit the site with their 128, download what they want (to a shared folder on the PC), pull it up in the PDF viewer, then drop back to the standard system, switching back to SLOPe to reference the PDF when needed. Or pop into the forums for a few minutes without leaving the 128.

RE: Color Support - How about allowing definition of colors for a window? You're already limited to character blocks for width, so if a window also stuck to vertical blocks it could easily be changed to a different color scheme than the background. I just think it would liven up the screen a lot, rather than being stuck with monochrome. You could make this not only a tool for programmers, but someone could write a widget that would allow the user to change the colors in any window. Is the API object-oriented? Are the windows named objects? If so, it should be relatively easy to create such a widget. Needless to say, the same thing applies to screen colors.

RE: Sound - Are you going to have system sounds? I've always thought that aural feedback was an overlooked item way back when. I like my PC system beeps and boinks. Especially since I can customize them.

See? You should have kept quiet. Now you're already being asked for 'feature creep'.

Quote from: nikonikoYeah, that's been the main thing bugging me about the PDF library -- no way to view the PDFs on a 128. Ideally I'd love for people to be able to visit the site with their 128, download what they want (to a shared folder on the PC), pull it up in the PDF viewer, then drop back to the standard system, switching back to SLOPe to reference the PDF when needed. Or pop into the forums for a few minutes without leaving the 128.

There are programs around to turn a PDF into a series of images.  It shouldn't be hard to convert the PDF library to a series of 640x200 images that could be viewed full screen.

Quote from: plbyrdThere are programs around to turn a PDF into a series of images.  It shouldn't be hard to convert the PDF library to a series of 640x200 images that could be viewed full screen.

Yeah, that's the basic idea behind the PDF viewer, except that for our few scanned books which do have OCRed text I want to be able to send the text also so that it can be copied, pasted and edited in other SLOPe apps. Of course, the quality of the OCR isn't always the best, so viewing the bitmap should always be an option regardless of whether there's a text layer. Also, my idea for supporting printing over a network would be that the printed output from the 128 would be rendered into a PDF, when possible substituting appropriate vector fonts available on the server. Maybe someone else can do that, though, since I've got more than enough to keep me busy the next year or two.

Quote from: airshipRE: Color Support - How about allowing definition of colors for a window? You're already limited to character blocks for width, so if a window also stuck to vertical blocks it could easily be changed to a different color scheme than the background.

Right now I just have it so that you can change the foreground and background of the whole screen, but having different window colors would definitely be nice.

Quote from: airshipAre the windows named objects?

Every program instance has a process ID assigned by the system from which the name can be retrieved, and every window opened by that process likewise has an ID which can be used to reference the associated window name. If a programmer doesn't set the window name, the name will be empty and the OS window routines will only display the application name. Right now there isn't a facility to turn a name into an ID (or list of matching IDs for duplicate names), but that could be added if necessary. My overall strategy is that only frequently used functions are loaded initially, and then additional modules are pulled in as necessary from disk or RAM expansion.

QuoteRE: Sound - Are you going to have system sounds? I've always thought that aural feedback was an overlooked item way back when. I like my PC system beeps and boinks. Especially since I can customize them.

I'd like to have system sounds. If I didn't put sound on my to-do list, it should be there. It'd be a shame for any OS to ignore the great SID chip. (And yeah, I mean any OS! Windows, Mac OS and every other OS big or small should have built-in support for the SID, too. )

Been working on some preliminary color support which you'll hopefully see in the video I'll be putting up, allowing window borders to be any two colors, and interior to have its own colors. Color within the window can either be a single two color scheme, or developers can set color of any cell however they want, which would require some care on their part. I have color in place, but the title bar and window borders need reworking to accomodate it.

Color completely screws up the mouse cursor, but there's not much I can do about that. The least ugly approach I could think of is a block cursor moving over the desktop and window elements, switching to a precision cursor over areas such as text that need fine selection control. Except for the block cursor bit, that's what happens anyway. Presumably most programs will have large areas of consistent color within their windows, so there shouldn't be too much ugliness as the precision cursor moves around in the window. Of course, if it does cross a color boundary it won't be pretty, but those are color cells for you when you don't have any hardware sprites to overcome their limitations. Spectrum users put up with it for years without complaint, so I guess we ought to be able to find a little forgiveness in our hearts for VDC hardware limitations. At least we have better resolution.

By the way, I'm sorry to 16K VDC users, but I hope you like mono. If you really want color, it could be added, but you'd have to sacrifice some screen resolution for it. If you end up liking SLOPe, I'd recommend doing the 64K upgrade.

Color cell size is another can of worms. I'd like offer flexibility, being able to trade off performance for more color freedom, but I also don't want developers to be forced to write their programs to work at all the different color cell sizes. For now I'm just doing 8x8, but here's what I'm thinking for a future revision:

Available cell sizes will be 8x8, 8x4 and 8x2. Developers can choose either to support all three color options, or just one or two. Let's say the desktop runs at 8x8 by default, but the user launches an app which only supports 8x4 or 8x2. The screen will switch to that color cell size, and any apps using larger cells have their color replicated to multiple cells. So if we switch to 8x4, an 8x8 app will actually have its color written to two 8x4 cells to make one virtual 8x8 cell. In the case of switching to 8x2, an 8x8 cell would actually be 4 8x2 cells stacked together. An 8x4 would be 2 8x2 cells. When that 8x2 app ends, if no other 8x2 apps are running, the color cells would be switched to a larger size for better performance.

Example:

We launch an 8x2 app.
Cell size changes to 8x2.
Then we launch an 8x4 app.
Cell size remains 8x2.
We close the 8x2 app.
Cell size changes to 8x4.
We close the 8x4 app.
Cell size goes back to 8x8.

Having color will reduce the available virtual desktop size, but for what it adds to the user experience it will probably be worth it. However, mono mode will always be available for those who want it. Developers could either offer explicit support for mono, or opt to let the system handle it. In mono, text will always be in the system's foreground color, and graphics can either be dithered or just have the color information thrown away (which in many cases will still look okay).

My, the VDC sure can be a pain in the posterior....

Now, Airship, if you decide you want color interlace added to this mess too, you're gonna have to implement it yourself. I may be willing to tackle mono interlace, but that's it.

Ooo!  Ooo! Me want Interlaces! Me want Interlaces!  

Non-interlace is fine. I couldn't stand it on the Amiga. The only thing it's good for is video output, which the VDC won't do gracefully anyway.

And the color cell size limitation is fine, I think. There are still a lot of opportunities there, especially combined with the multitasking. Heck, when I did a 3-window demo using the 'n-progs' thing that what's-his-name* came up with, knowing they were running in different program spaces I was entranced just watching them print and scroll in sequence. If they do so simultaneously, I'll be absolutely mesmerized. :förvånad:

*Fame is so fleeting...

Quote from: airshipHeck, when I did a 3-window demo using the 'n-progs' thing that what's-his-name* came up with, knowing they were running in different program spaces I was entranced just watching them print and scroll in sequence. If they do so simultaneously, I'll be absolutely mesmerized. :förvånad:

I'm kinda hoping someone will put together a BASIC interpreter for SLOPe. Preferably it would have a fair degree of BASIC 7.0 compatibility so that it wouldn't be difficult to adapt existing programs, but I'd also like to see it have the option to use labels rather than line numbers.

There's also a project called PyMite which implements a tiny Python (subset) interpreter in C, which I have hopes of someday seeing running on SLOPe. Then there's that little Java VM that someone ported to the C64 a few months ago...

I don't really care if these things crawl due to the extra weight of running under SLOPe and having to share time with other processes, but just to be able to write something up real quick and have it plugging away in the background would be really neat.

I think the micro Java VM is the most interesting.  It would be great to have a C= Basic-like environment for authoring and writing code for it.

I think the point with having the little Java VM and micro-Python and any other 'standard' languages you could cross over would be not in trying to use them to do giant applications, but to be able to use them as scripting languages for small, relatively quick system utilities.

Java is by no means a scripting language; all code must be compiled, including for the Micro Java VM.  Someone would actually have to write a compiler and linker that runs natively under SLOPe to create code on the 128.  Using it as scripting language would be very, very difficult.  What would be a lot easier (and more useful) is a BASH-style shell.