I think it's time for a brand new O/S
in [Commodore]
|
Prev: C64 spotto
Next: A beter C compiler, anyone?
From: AgentFriday on 2 Feb 2010 07:45 On Fri, 29 Jan 2010 06:26:13 -0800 (PST), christianlott1 <christianlott1(a)yahoo.com> wrote: >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? The solution space on the editor scenario is pretty wide open, so I'm gonna throw that one back to you. Give me a simple requirements set and how you might approach it on a stock '64. Or in GEOS for that matter. Nothing too detailed tho. That should give me a good starting point. >Three ideas also occurred to me. >1. the memory allocator is modularized and can be >entirely replaced? Hadn't formed that specific thought yet, but absolutely. (The practicality yet to be proven, of course.) >2. if relocation is so important, shouldn't the core be relocatable as >well? Maybe in version 2 or 3. A relocatable core introduces more work and overhead, and eliminates some shortcuts you might otherwise take. The OS maintains a somewhat consistant presence in memory. It's hard to predict what parts of the OS a given program may need to call at any given moment, so it mostly needs to stay accessible to all. Even if you could manage placement of OS modules such that apps could occupy the same address space as a core module that it does not need, this would be most difficult to pull off at those times when you need it most (crowded memory conditions). The #1 benefit I can see for relocating the OS would be to allow non-native code, which is statically linked, to execute under the OS. Even then, you would either need to tell the OS what locations to avoid or support expensive real-time relocation. There are other methods and scenarios where a relocatable core becomes more attractive, but I'll leave them be unless you bring them up. =) >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. Ah, but it may be rather difficult to get wide adoption of an OS that relies upon one particular memory solution. A big aspect of the compatibility and re-use I'm aiming for is to allow users to combine whatever combination of _hardware_ solutions they want or need to use. Purchasing new hardware just to use the OS will be a big deterrant, and if a hacker wants to work on a project that is not compatible with the prescribed setup, it defeats the purpose of the OS. Program and code re-use is also VERY important, but there are broad areas where the two can coexist. For example, if you have a device that gives you virtually instant page swaps, you will likely be able to run many applications, including non-native apps, simultaneously, with high responsiveness, quasi-real-time drivers/services, and frequent swaps between programs. But if you are not able to use the ideal configuration, for whatever reason, the system should do its best to work with what you have; you will be able to do most things, but you'll have to work within the constraints of your hardware. As an example, if you don't have fast page swapping and need to run non-native software, you shouldn't expect to switch in and out of that software often, and you may not be able to use real-time hardware driverrs at the same time. But yeah, if I learnt it correct, a full 64K swap should be possible in under 200 ms; this is not a bad task switch time at all. Look forward to the next round! // Steve
From: christianlott1 on 2 Feb 2010 18:15 On Feb 2, 6:45 am, AgentFriday <my_nic_h...(a)hotmail.com> wrote: > On Fri, 29 Jan 2010 06:26:13 -0800 (PST), christianlott1 > > <christianlo...(a)yahoo.com> wrote: > >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? > > The solution space on the editor scenario is pretty wide open, so I'm > gonna throw that one back to you. Give me a simple requirements set > and how you might approach it on a stock '64. Or in GEOS for that > matter. Nothing too detailed tho. That should give me a good > starting point. I imagine the allocator in two parts: the free store and the allocated. allocate (length_x, length_y) or allocate(length) But then how are the documents stored? They must be compressed. So a token per word and a dictionary file. The dictionary is either appended to the document or shared among documents (or the entire OS). So the size of the file must be allocated but we may not have enough memory. We definitely need a minimum of memory for the display. We also need a minimum for the translation. How much of the dictionary do you pull into memory or do you grab it straight from disk when you need it? Compression and translation seem to be a very important part of an OS. Files need to be looked up quickly. I remember searching for a file in XP compared to Vista. XP could take all day to find a file, as much as I hate Vista, it finds it quickly because it keeps a central catalog of where everything is. I think a good OS should be more like a database than what exists now. I should be able to run complex queries to find things and keep records and search documents or any file type for that matter. But this has turned into a rant and not a solution. And everyone knows the 6510 we have isn't up to searching and indexing a 500gb hard drive, even if it can access every file on it. A C64 equipped with an ethernet connection should have means and here I drift off the original subject.... > >Three ideas also occurred to me. > >1. the memory allocator is modularized and can be > >entirely replaced? > > Hadn't formed that specific thought yet, but absolutely. (The > practicality yet to be proven, of course.) The memory allocator is important but it's only one piece of the system. Unless you find all the pieces inextricably linked into a dynamic symbiotic and contingent model. That may bee cool too. > > >2. if relocation is so important, shouldn't the core be relocatable as > >well? > > Maybe in version 2 or 3. A relocatable core introduces more work and > overhead, and eliminates some shortcuts you might otherwise take. The > OS maintains a somewhat consistant presence in memory. It's hard to > predict what parts of the OS a given program may need to call at any > given moment, so it mostly needs to stay accessible to all. Even if > you could manage placement of OS modules such that apps could occupy > the same address space as a core module that it does not need, this > would be most difficult to pull off at those times when you need it > most (crowded memory conditions). > > The #1 benefit I can see for relocating the OS would be to allow > non-native code, which is statically linked, to execute under the OS. > Even then, you would either need to tell the OS what locations to > avoid or support expensive real-time relocation. > > There are other methods and scenarios where a relocatable core becomes > more attractive, but I'll leave them be unless you bring them up. =) I just think it unattractive to hard code any address. It sets up a bad president :) but allows others to ignore it which may be necessary for a system with a static device memory placement (vic,sid,color memory, cia) and rigid/limited displacement (vic banking system). > >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. > > Ah, but it may be rather difficult to get wide adoption of an OS that > relies upon one particular memory solution. A big aspect of the > compatibility and re-use I'm aiming for is to allow users to combine > whatever combination of _hardware_ solutions they want or need to use. > Purchasing new hardware just to use the OS will be a big deterrant, > and if a hacker wants to work on a project that is not compatible with > the prescribed setup, it defeats the purpose of the OS. Sometimes attempting to please everyone is worse than targeting those who know what they want. Since it's a bit off topic, I'll just say what I feel. Three things are important for a modern OS for the C64 in terms of hardware, in order: Internet, Snapshot, and fast disk. Since the internet will be as fast as memory can store, the fast disk is not so important - and since you can't get internet and snapshot without a cartridge connected, instant on/ instant boot OS comes for free. > Program and code re-use is also VERY important, but there are broad > areas where the two can coexist. For example, if you have a device > that gives you virtually instant page swaps, you will likely be able > to run many applications, including non-native apps, simultaneously, > with high responsiveness, quasi-real-time drivers/services, and > frequent swaps between programs. But if you are not able to use the > ideal configuration, for whatever reason, the system should do its > best to work with what you have; you will be able to do most things, > but you'll have to work within the constraints of your hardware. > > As an example, if you don't have fast page swapping and need to run > non-native software, you shouldn't expect to switch in and out of that > software often, and you may not be able to use real-time hardware > driverrs at the same time. I take fast disk access for granted now, in the age of IDE64, uIEC, 1541 Ultimate, etc. I think everyone who is serious about using their 64 and trying out a new OS has one of these. > But yeah, if I learnt it correct, a full 64K swap should be possible > in under 200 ms; this is not a bad task switch time at all. No, which should make the OS core look more like a relocatable monitor or boot loader - especially if you're looking to support many hw configurations. But this is a guess, I really don't claim to know much about OS design. > > Look forward to the next round! > // Steve :) Thanks for the replies.
From: Pheuque on 1 Mar 2010 12:42 On Jan 21, 2:34 pm, "Joel Koltner" <zapwireDASHgro...(a)yahoo.com> wrote: > <my_nick_h...(a)hotmail.com> wrote in message > You essentially want all the features of a "modern" operating system in a > machine with several orders of magnitude less CPU horsepower and memory than > what's available today. Yeah... The memory Cache on most hard drives is an order of magnitude bigger than what the average Commodore SYSTEM has to work with. You've got a better chance of teaching an Amoeba to play Chess.
From: David Murray on 5 Mar 2010 10:52 > I think everyone who is serious about using their 64 and trying out a > new OS has one of these. I don't have one, and I'm a pretty serious C64 user. Out of curiosity, might the Z80 chip in the C128 provide a better platform for a new operating system?
From: christianlott1 on 5 Mar 2010 12:21
On Mar 5, 9:52 am, David Murray <adri...(a)yahoo.com> wrote: > > I think everyone who is serious about using their 64 and trying out a > > new OS has one of these. > > I don't have one, and I'm a pretty serious C64 user. > > Out of curiosity, might the Z80 chip in the C128 provide a better > platform for a new operating system? You don't have a fast disk drive David? That was the point of the remark. "I take fast disk access for granted now, in the age of IDE64, uIEC, 1541 Ultimate, etc. I think everyone who is serious about using their 64 and trying out a new OS has one of these. " So please include the 1581, cmd hd or even a fastload cartridge. Thanks. |