I think it's time for a brand new O/S
in [Commodore]
|
Prev: C64 spotto
Next: A beter C compiler, anyone?
From: Paul Förster on 24 Jan 2010 02:33 Hi Glenn, > +1 re. LUnix .... I was just about to suggest Lunix. Sadly, Lunix 1.1 doesn't seem to be developed anymore. I'd like to see loads of standard Unix utilities, starting with "vi" and lots of other stuff. I for one like the idea of Lunix very much. -- cul8er Paul paul.foerster(a)gmx.net
From: Peter Dassow on 24 Jan 2010 09:23 James Harris wrote: > On 21 Jan, 11:39, my_nick_h...(a)hotmail.com wrote: > >> I'm in the planning stages for a new C= O/S. Here are some features , >> goals, my reasoning, etc. (in scrambled order) ... > > ... > > ... > news:alt.os.development > http://groups.google.com/group/alt.os.development > http://aodfaq.wikispaces.com > > No one has mentioned a Commodore OS yet! > There's a alternative OS for the C64 already out: DOS/65. And software can easily ported from CP/M-80. See also here http://www.z80.eu/dos65.html Regards Peter
From: commodorejohn on 24 Jan 2010 10:38 On Jan 24, 8:23 am, Peter Dassow <z8...(a)arcor.de> wrote: > There's a alternative OS for the C64 already out: DOS/65. > And software can easily ported from CP/M-80. > See also herehttp://www.z80.eu/dos65.html DOS/65 is nice for being complete, portable, and packaged with some basic utilities (editor and assembler, for example, even though it's just a line editor.) That said, it's not even remotely a modern OS, any more than CP/M is. It has its advantages, but it's just a little dated by this point.
From: AgentFriday on 29 Jan 2010 06:14 On Thu, 21 Jan 2010 19:22:39 -0800 (PST), christianlott1 <christianlott1(a)yahoo.com> wrote: >On Jan 21, 5:39 am, my_nick_h...(a)hotmail.com wrote: >> I'm in the planning stages for a new C= O/S. Here are some features , >> goals, my reasoning, etc. (in scrambled order) ... > >What algorithm do you plan to use for memory management? Hmmmm... that could mean a number of things, so I'll pepper the field and see if I hit anything. All I have really are some strategies and guidelines; I'm not sure that any algorithm or set of algorithms could really give the overall picture very well. Worst-fit? (haha) ========================================== 1. RELOCATABLE MODULES: Multi-tasking requires that the OS has the ability to locate code and data at virtually any address. This is the limitation that has made it so difficult to combine utilities and/or hardware extensions to create something greater. So unless you just get lucky, you either have to write all your own code for every part of your application or reverse-engineer someone else's projects to make them mesh. THE PRIMARY MOTIVATION FOR THIS PROJECT IS TO MAKE SUCH SYNERGY POSSIBLE. 2. ALLOCATION: Programs may use RAM or address space only as allocated by the OS. An allocation request consistes of both the amount of memory required AND the size of window through which it is to be accessed. The source of that physical RAM need not be known outside of the OS, so long as the process is able to access it as documented. Allocation may also specify flags (or options) that tell how the memory is to be used. This helps the OS manage it better. Some planned flags: code v. data, alignment requirements, hints on patterns and frequency of access, whether or not it should be placed under ROM or I/O space, etc. You may also be able to specify the memory type as one of a set of abstract data types. The advantage of the abstract data types is that it lets OS do the heavy lifting and it can automatically access how and when the data is mapped or swapped. This helps to reduce the memory footprint of the data; many of the abstract data models won't require any address space at all, simply storing or retrieving one piece of data at a time. 3. MEMORP MAP: The general layout is actually quite similar to what GEOS did. (NOTE: I thought of it before learning how GEOS did things, I didn't copy them. ) :p Part of 0-page will be used by the OS, and the rest is set aside for allocation to programs as needed. Other global system data will likely follow, and general-use RAM begins around $400, maybe lower. VIC is banked to $8000-$C000, and memory in that range is preferential to graphics/text/sprite use. The standard ROMs and IO are banked out to maximize RAM access and switched in when needed. The O/S core is located primarily under the ROM space. 4. ADDRESS SPACE MANAGEMENT: The mantra here is to make memory available to the active task where it needs it, when it needs it. If a process makes a direct call to a driver or an API provided by another process, or access data shared then it is *dependent* on that The same region of address space could be re-used many times, as long as there is no need to accesses any of those overloaded regions at the same time. Tasks and data that are accessed often probably need to remain visible. The mem manager will do its best to handle the memory for greatest speed, but as it becomes scarce, some compromises may need to be made. It gets difficult trying to predict those at this stage, but I'm sure there are workable solutions. (... more about techniques for minimizing swapping ...) ========================================== There's a lot more, but I was afraid this post would become stale if I had try to finish them all. Some unfinished section titles are at the bottom, and I know there are a couple I missed. I'll cover them sometime soon, probably once I get my wiki set up. It's a lot of stuff that's been rattling around in my brain for some months that hadn't found their way to a keyboard yet. So... cristian... is this anything like what you had in mind? If there's interest I'll post my continuation here. \\ Agent // * THUNKS * STACK MANAGEMENT * EXPANSION RAM TYPES (REU, GEORAM, RAMLINK, KNOWN INTERNAL UPGRADES) * MY DESIGN FOR EXPANSION RAM * NON-TRADITIONAL STORAGE SPACE * MEMORY SWAPPING * MEMORY BANKING * KEY-HOLE ACCESS * VIRTUAL MEMORY * CACHING OF EXTERNAL DATA * RAM DRIVE * DATA OR CODE RELOCATION
From: christianlott1 on 29 Jan 2010 09:26
On Jan 29, 5:14 am, AgentFriday <my_nic_h...(a)hotmail.com> wrote: > So... cristian... is this anything like what you had in mind? This is actually very different than what I had in mind but this is not a bad thing :) I'd like to discuss as an example a text editor. A 40+ character line buffer and provisions to have multiple documents open and editable at the same time. What parts of the OS memory allocation api would this application use? Three ideas also occurred to me. 1. the memory allocator is modularized and can be entirely replaced? 2. if relocation is so important, shouldn't the core be relocatable as well? 3. this is last because it's off topic. with a new operating system, everything must be written from scratch. this is a great thing but what about reuse? isn't the ultimate in relocatable what amounts to a freeze and store? Extra ram or simply a fast disk, relocation isn't so important if the entire program fits in 64k. this points to a hw solution to relocation, modification and reuse through memory snapshots. Great synopsis. I look forward to learning more. Thanks! Christian |