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:
(http://img408.imageshack.us/img408/7718/slopefg3.gif)
(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? :P
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 (http://www.youtube.com/profile?user=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. :D)
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. :P I may be willing to tackle mono interlace, but that's it.
Ooo! Ooo! Me want Interlaces! Me want Interlaces! :D
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.
Fonts size problems are fixed and color's more or less operational now, so I should be able to get a video up tonight or tomorrow morning. The display system was one of the least flexible parts of the project, being written according to the conviction that mono was the best way to go for performance reasons, but color does add something even if it comes with a cost.
Quote from: plbyrdJava 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.
While that would be pretty cool, I expect it's more likely that people would have to compile on a PC, handing the 128 the resulting bytecode. With 64HDD or networking support, that could be done pretty conveniently, but worst case would be having to transfer the files by floppy.
That is a massive project! As long as it gets the AGI interpeter games released, that all that matters :)
I wanted to comment on interlace to say that although the flicker can be annoying, I always like the text better. In normal mode, text seems too tall and skinny. And also 'light weight' (the gaps between rasters). With interlace mode they look 'perfect' (except for the flicker). This must be a personal bias from years of the 40 column screen...
So... it's been a couple of days now. Is it done yet? :D
Sorry, but haven't had much luck with video. My computer seems to be too slow to catch more than a frame every now and then, and half the time it's during a screen update so anything moving gets split.
Anyway, since the video effort was a bomb, here's a screenshot I took yesterday. In it you can see the new color support (obviously), as well as mixed font sizes and several font styles, disk icons, the Swirling Vortex of Doom (stand-in until I feel like drawing a trash can) and an early attempt at a file manager. The font seen in SLOPePad was auto-converted from Arial and has some kerning issues (if that's the right terminology), but should look better after I update the converter to compensate. Window style had to change in order to use full color cells and isn't as slick as the earlier mono-only version, but a more capable person will probably be able to improve the appearance over the crud I put together. Currently GUI controls are pretty limited -- no minimizing or maximizing of windows, no toolbars (hence, a Font menu for SLOPePad instead) -- though eventually things will be more full-featured. There's a bug in my scrollbar implementation, so they aren't seen here. The active window is distinguished from others by having a drop shadow. Should probably do something more than that, though, as it's possible the drop shadow could be offscreen in the case of virtual desktop being turned on. Files have extra information associated with them, which among other things can indicate filetype in the absense of an extension. Need to fix the "/" character in the system font as it's ugly and introduces extraneous spacing into the file manager display. Also need to add more info to the display, particularly file sizes and free space for the volume. Actually, free space can be gotten by clicking on a disk icon and hitting C= I, and file size by doing C= I on a filename, but they should be available more readily in the manager as well.
(http://img523.imageshack.us/img523/9741/slope110507nb3.gif)
By the way, Lance, considering the overwhelming response from the c.s.c. crowd, might as well save your posting energy until I make a public download available. :)
Quote from: nikonikoBy the way, Lance, considering the overwhelming response from the c.s.c. crowd, might as well save your posting energy until I make a public download available. :)
Actually, check the topic views, you'll be surprised :)
Dude, I'm astounded with what you've accomplished here. How much time has gone into this? When did you start it?
Looks great! Keep up the good work.
QuoteHow much time has gone into this? When did you start it?
Well, some pieces date back to soon after I started on the AGI interpreter, which was almost a year ago, but didn't gain much momentum until couple of months ago, with more focused time in the last three weeks or so. Even as sloppy as it may be, I'm pretty happy with how it's coming along.
Two words: Holy and macaroni.
Looking VERY sharp, nikoniko! I LOVE the color windows!
Do you have 64HDD so you can check it out with that? I'd be happy to beta test it for you.
Thanks, I'll definitely need some 64HDD help as things progress. The only direct support for its extended features now is for reading the clock, however I'd like to do more.
Glad you like the new windows! Currently colors are decided by the application or GUI defaults, but eventually I'll put together user control.
BTW, I like the 'Swirling Vortex of Doom'. :)
Well, as GUI elements go, at least the Swirling Vortex of Doom probably isn't covered by any trademarks. :D
Looks great!
Are you including the 128 fastloader code for 64HDD? I think Nick Coplin allows it to be reused without paying royalties.
Quote from: plbyrdAre you including the 128 fastloader code for 64HDD? I think Nick Coplin allows it to be reused without paying royalties.
Haven't got very far with drive and disk handling yet, but I'll look into it.
I just did a little research on AGI. I'm surprised at how many fan-created games there are out there! I've found 26 so far.
Indeed! Once the format was documented, editors were created, and soon a trickle of new games began to appear. Not a lot of people still develop for it due to the 16-color limitation, but ages ago I came across a site which had more than 50 homebrew games, and even a few utilities written in AGI script as well.
It's late in the discussion, but me, I have WinVICE can you do something for that too? :gråta: I want one of all that listed here too darn it!!! lol
Hey, great to see you again! It definitely runs on WinVICE, in fact has to since that's my own development platform. There are also some advantages to that since I've added some SLOPe-specific debugging features to VICE.
Just realized my screenshots are gone since furthervoyages.com is out of commission. I'll upload them elsewhere and repost them along with some newer ones.
it's been a hectic 3 motnhs involving a weird and mandatory unplanned move . but now things are good. so I'm back ;-).
Quote from: mystikshadows, it's been a hectic 3 motnhs involving a weird and mandatory unplanned move .
Yes occasionaly my life of crime catches up with me as well ;-)
Mark
Quote from: mystikshadowsbut now things are good. so I'm back ;-).
Glad things have settled down enough to get you back here. You've definitely been missed. Any longer, and we might have sent out a search party for you. :P
it would have been easy to find me. just tell the search party to flash a C-128 up in the air as they walk the sttreets, I'd pop up like a rat going after the cheese in a maze. ;-) I'd find them, twice as fast if it includes a 64hdd, a monitor, floppy drives and the likes ;-).
and LOL@Mark's life of crime hehe. from the foreclosure papers, it's my ex-landlord's life of crime. ;-).
Just a quick note: ordered a copy of the Geos Programmers Reference Guide with a view toward some degree of Geos support. At a minimum, transferring Write and Paint documents and fonts, but depending on the Geos API and architecture, possibly a facility to run some apps or desk accessories under SLOPe.
GEOS emulation... talk about feature creep! LOL
As I recall, the Paint format is quite straight forward, an array of bitmap 'blocks' each 80 columns / 640 pixels wide and 8 pixels tall in the VIC standard bitmap/char fashion. The height (number of blocks) is variable and each block is pointed to (track/sector) in the VLIR sector (so I guess it's limited to 127 blocks). Dunno about Write or Fonts. I liked the GeoFont editor but that's another topic...
I dunno about the APIs either but most data is passed through zero page variables as I understand it. You said earlier that SLOPe uses dynamic page 0 and 1 allocation. Which brings me to my question.
How do you handle page 1 switching? I always thought about using that feature, but since interrupts (especially NMI) can occur durring switching stack pages I never thought it would be reliable. Thinking about it more now I have a few ideas, but was just curious what your solution is.
Also what about stack overflow? Since there is no hardware support for detecting this it was another reason I nevered used page 1 switching. My only ideas were to constantly check the SP which is just wasteful or perhaps check it during an IRQ. The IRQ is more effecient but not reliable at all.
Anyway, have fun!
Niko - Ive missed out on all the screenshots and videos, but would like to check this out - is there somewhere I can see what you have done so far?
Hi xlar, screenshots are fixed above, though now they're very out of date since I've been doing a complete rewrite of SLOPe from the bottom up. I didn't like that there wasn't better integration with the 128's usual mode of operation, so I started over from the view of making SLOPe a system extension rather than a complete replacement. After I get caught up on the two weeks of posts I've missed while sick, I'll write more about it and post some new media.
QuoteGEOS emulation... talk about feature creep! LOL
After studying the GEOS architecture with my book, I've now set that idea in the "probably never" pile. Initially I thought it might by feasible by redirecting the API calls to SLOPe routines, but there are just too many differences for that to work. However, I think something could maybe be worked out so that GEOS and SLOPe can coexist -- sending one into hibernation and running the other, then switching back.
Fonts, Paint and Write files will definitely be supported, though.
QuoteHow do you handle page 1 switching? I always thought about using that feature, but since interrupts (especially NMI) can occur durring switching stack pages I never thought it would be reliable. Thinking about it more now I have a few ideas, but was just curious what your solution is.
Two ways. The first is deliberately triggering an NMI via CIA2 right before the swap, but not touching the interrupt control register until after swapping the page. The second method is if there's an REU attached, store all the page 1s in expansion RAM and swap them when needed. That's a nice solution because 1) the actual RAM location of page 1 can remain static and we don't need to mess with relocation, and 2) the processor is halted, so NMIs will leave us alone until we're done. But my redesign also reduces stack usage significantly, enough so that I think ultimately I'll be able to dispense with giving programs their own page 1 altogether. (EDIT:
Actually, userland programs no longer use the hardware stack at all.)
Aside from those options or disabling NMI completely, what other ways can you think of to safely handle such switching?
QuoteAlso what about stack overflow? Since there is no hardware support for detecting this it was another reason I nevered used page 1 switching. My only ideas were to constantly check the SP which is just wasteful or perhaps check it during an IRQ. The IRQ is more effecient but not reliable at all.
Well, "sloppy" is the name, so I haven't been that worried about wasteful. :P But I think the changes I'm working on will reduce the possibility of stack overflow significantly, pretty much eliminating the need for constant checking, though once you see how it's done you might want to revoke my license to develop for the 65/85xx architecture...
QuoteAnyway, have fun!
I have been. Working on SLOPe with VICE on my laptop kept me from going stir-crazy the last couple of weeks.
I like the REU idea to the NMI problem! The CIA triggered NMI seems wasteful but the fact you bothered to code for that shows you're good 'nuf for 6502 coding :)
My recent idea for page 1 flipping (never tested mind you) is to have a 'dummy' page 1 and use it during swap. Something like this...
LDY mmu_p1 ;old stack page
TSX
TXA
STA sp_table,Y ;save SP for old stack
LDA #dummy ;temp stack page
STA mmu_p1
LDY #new_p1 ;new stack page
LDX sp_table,Y ;SP for new stack stored in memory
TXS
;an inerrupt here would kill old_stack
;that's why have dummy stack
STY mmu_p1
;interrupts ok in new_stack
The idea is the entire 'dummy' page can be written by interrupts, should they occur, without the SP being set properly yet. Once the SP for the 'new' stack is correct we can switch in the correct page.
That is, the 'dummy' page takes care of any interrupt between TXS and STY mmu_p1 opcodes.
The main problems I see with this method are you'd need to use self-modifying code (to set the LDY #nn) or a fixed address (LDY $zz or LDY $aaaa). In other words I don't think it could be used recursively.
Ahhh. How to explain? The main code could set up multiple stacks in a recursive fashion but the problem I mention would be the interrupt routines couldn't use that same code to setup a dynamic stack page.
The interrupt code can easily setup a constant stack page for itself if no other interrupts are possible. So I guess IRQs couldn't do it but NMIs could. Assuming we don't trigger an artificial NMI just to avoid them.
Now that I've confused everyone (myself included), I'll shut up.
The C128 MMU allows multiple page 0 locations, but I don't think anyone has used that feature much. I don't suppose that code could be stolen and reworked to allow multiple page 1 (stack) locations? Just a thought...
Just wondering three things ;-)>
1. Any new development to report? a fixed bug, an addition to the todo list? ;-)>
2. What are the 2008 goals with it?
3. Early 2008 imeans what to get your site up and running? ;-). ehe.. I can't wait to go play in your PDF background ;-).
1. Most significant is probably that CC65 has been taken out of the development process. I was having to spend more time rewriting CC65 to support SLOPe than I was getting to work on SLOPe itself, so using C wasn't really supporting my plan of making things easier. In some cases I'm still working with code that was previously compiled, but all new code is being written in assembly and eventually the legacy code will be redone from scratch. I suppose I should mention that the GUI system is no longer functional. :( However, now there's a working TUI where there hardly was one before, and VIC support.
2. Besides support for operating together with the 128's normal environment, continuing the overhaul of the memory management and task system to be simpler and faster. Most of that work is already completed, but further supporting those and several other goals (eg. memory protection, unburdening the hardware stack), user applications are changing to a p-code style system. As slow as that may sound, remember that most (if not all?) of the BASIC compilers for the 64/128 machines compile to p-code and end up with performance better than the BASIC interpreter. Simple tests I've done bear out the same for SLOPe, which frankly surprised me since I've done absolutely zero optimization on the p-code interpreter. Critical code like drivers can still run natively, but generally I think keeping as much as possible within the p-machine will be better overall. Currently the only means of generating the p-code is a very limited BASIC compiler. I think BASIC is a good way to go since it provides an easy upgrade path for many existing programs. Other important goals: reintroducing GUI support.
3. I enlisted the help of a friend to do the frontend since I stink at design. Visually it's something along the lines of Alibris, but with support for downloads, user tags, and online PDF viewing. It's no longer just a PDF library but a catalog of Commodore-related books and links to places where they can be bought.
Wow! The PDF library is going to run at a full 2 Mhz? :)
Yep, and not a Mhz more! 2Mhz ought to be enough for anybody, don't you think? :D