TEOS - Commodore 64 char mode OS - Status #3

[@mikekopack6441]

That is pretty damn impressive that you got multitasking working like that!

[@jda4887]

My goodness, the sheer number of talents in commodore fans is limitless... bravo !

[@judgegroovyman]

The text based aspect of this really appeals to my sensibilities. Its so clear cut and discrete and awesome. I love what you've done here.

[@alasyon]

Definitely, I was thinking the same thing with the text based approach, there really doesn’t need to be more resolution than 8x8 in moving windows around, and it has many speed/memory benefits.

[@bryanflick3793]

That is outstanding work! Very nice user interface, and the multitasking (even if portions are co-operative and not pre-emptive at the moment) is really impressive. Keep up the good work!

[@XalphYT]

You won me over the second that you opened the second Count program. I am looking forward to playing with this, whenever you are ready to share it with the public.

[@gerryrichards]

I really appreciate the design choices. I think you chose the right set of constraints that make a lot of sense for an OS on the Commodore 64!

[@64jcl]

Thanks, there are a lot of comprimises, and I might do some more as I really want applications to have more of the available characters so they can have a richer graphical expression. I have a lot of games for it in the works, each of them pushing the boundaries and need, the first one which I hope to demonstrate in the next video this coming weekend. :)

[@12w3hji123456789]

This is turning out really great!

[@mariuszbiegaj2391]

Years ago (~1990ish) I had exactly the same idea, multi-tasking character based OS on C64 with custom chars, windows etc. I did a prototype, but had a vague idea back then how to do solid relocatable code. Beginnings were promising but I never achieved so advancement. Eventually I had to sold my beloved C64 and never completed the project. Nice and impressive work of yours.

[@ieatspacemonkeys]

Nice! I wrote a co-operative multitasking OS for my own wire wrapped, ethernet connected 68K computer when I was at university. Lots of fun, aside from erasing and programming EPROMs which is an aspect of computer programming I'm glad to see the back of ;)

[@marekkarcz3946]

Impressive!

[@PaulGardnerStephen]

Very nice work. We would love to have a chat with you about porting this to the MEGA65. The MEGA65's VIC-IV has very advanced text modes, that even support kerned text, and 256-colour character cells, and of course higher resolutions.

[@64jcl]

Hi, yes the Mega65 is likely a fantastic platform for such a text based OS. One major drawback of the C64 is the lack of being able to set both foreground and background colour on one text char which I assume the C65/Mega65 would be able to do? I really want to explore fanning out into that platform as well as a C128 version but this is all just a hobby project for me so time is limited, but I will put it on the list of possible ones as I'd love to see it running with even richer abilities.

[@PaulGardnerStephen]

@@64jcl Yes, there are modes that allow setting both foreground and background in various ways. You can also use a character set with upto 8,192 characters in it, so you can effectively have custom bitmap graphics in every window, if you want. Also we have the Raster-Rewrite Buffer that allows writing multiple layers of text (with or without transparency), so that you can do the window overlapping logic mostly in hardware. Very fast DMA and SD card/D81 disk image access also would be nice for aspects of it as well. Maybe join the MEGA65 discord server (see link in navbar on mega65.org), and you can pick people's brains and generally enjoy the positive developer-rich community there. You might even find someone who is willing to help you with the port :)

[@buddyadams4781]

Absolutely amazing.

[@josephkarl2061]

This would be a great fit for the Mega 65 when it is released. Personally if you could add network file access to this (a big ask I fully realise), I'd be up for using this as my daily driver when I do get my hands on a Mega 65 👏👏👍

[@donaldklopper]

In not only responds very quickly, uses little RAM, but it looks beautiful too! Good job, can't wait to see what you come up with next. I love the fact that it's text based.

[@optikus]

Wonderful design. So much attention to detail. Please please go on.

[@warlockd]

I am more impressed with the very good multi tasking you got in there. Be interesting to see how more than one application handles file access.

[@64jcl]

Thanks. The file system code still needs a couple of rounds before I am there, but its getting better every iteration. :)

[@paranormalnpdc6209]

this TeOs remember me windows 1.0 on his beginning. GREAT JOB bro

[@ThomasChristensen]

It also resembles IBM's TopView :) played around with that on a PC XT back in the days...

[@moribundtoot8183]

It does look a lot like Windows 1.0 only that Teos seems to support overlapping windows which Win 1 didn't (if I remember it correctly). Very impressive work.

[@gertachimrenel595]

You should do a C128 version with VDC support. It would be much more useful.

[@Magnumi]

Highly impressive! Can't wait to see how it comes along. :)

[@painkillergko]

I'm impressed!!!:)

[@stephanevermette145]

Incredible!

[@francescofiorentini6700]

Awesome work! Just discovered this project but I'm already a fan of it. Looking forward to hear more news.

[@helmutzollner5496]

Well done. That was more than.overdue.

[@painkillergko]

If A. Savona says that you are doing the right thing, my amazement only increased :)

[@pi4630]

Keep up this fantastic work!!!

[@hstrinzel]

WOW absolutely BRILLIANT WORK! Keep right on going with this! I'd love to run it myself some time when ready...

[@Pwtz]

Phenomenal work

[@Wil162]

Great work, looks awesome! I think the decision to make it work in character mode is very sound, saving memory and processing time. Does the loader support SD2IEC? Is it possible to save files with the loader activated?

[@64jcl]

Thanks. Yes the performance and lesser memory use in text mode was the main reason for starting the project. Its still very early days so I dont even have save capabilities in yet except some experiments using the Kernal. I am still working out the file core as I need them, one baby step at a time. :) At the moment only one app can grab the IO at a time so a file loading from disk will lock e.g. the ability to start a program from the memory drive (not real REU support yet). I plan to change that though and at least allow both of those as there really is no conflicts between them. As for other devices I have not tried any yet (and actually dont have any myself yet). If they support Kernal calls then that driver would work fine for that kind of access. Otherwise for the fast loader it would have to emulate a full 1541 ofc for that to work, but I guess with an sd2iec there is no need for fast loading anyway.

[@RazzFazz-Race]

Great Work maybe it could be a good thing for the Commander X16 Project from the 8bit-Guy.

[@64jcl]

Yes no doubt it would fit the X16 as well and I have been tinkering a bit with developing for that so who knows. If time permits I will do a port. :) - But there are many others too, like the standard C128 and the MEGA65.

[@andydepressivum8808]

masterpiece.

[@stevedegeorge726]

Very cool. Amazing work.

[@LoftBits]

A beauty!

[@mad_circuits]

Really nice. It is the correct decision to use text (character) based windows. Memory usage is a big concern. Go on! Don‘t stop there!

[@AS-ly3jp]

This looks freakin' awesome! Imagine a C128 Version supporting the 512kb Memory Expansion and supporting the 1581, backbit tool, kungfuflash, Final Cartridge and so on. Are there any plans in that directions?

[@64jcl]

There are plans to both support REU's in different variantions as well as a C128 port as that alone has a built in REU sort of. :) - But I have a lot I want to do before I start on any porting projects.

[@claudiusraphael9423]

Astonishing! Some questions: A) I wonder if you could optionally offer to not display window content, similar to Windows where just the frame is shown on moving, resizing. B) Regarding the frame mentioned in A - Would the use of sprites for the corners of the window to move be feasible? I think this would prevent eating resources only for movement and resize. C) Since you haven't yet implemented a DOS: I remember the possibility to store some data in the Floppy-Drive - could that be used for the DOS, so it kinda works autark? If so, and if there would still be ram left in the drive, could you implement autark preloading, for example a description-file saved along with a file on disk? This description-file could have graphics for a Logo or screenshots alongside optionally, rendering it as sprites - compare to classical mac-os

[@64jcl]

A lot of questions. I'll try to reply the best I can: A) Yes I am considering several ways to improve the performance of window movement. One is that I actually delete the whole window now which is unecessary, I am going to make it so that it only deletes the necessary chars. Another is that I need to code the window resize thing and that will not be repainting the whole window but only a frame, so I might very well make it so that the same routine can be used for moving a window around as well for those who prefer that over the repaint. I might even experiment with a mix of both so that when you move the window it shows only a frame being moved, then when you linger for a second it draws the whole window on that spot. We'll see. :) B) Yes sprites has been one I have considered although that would likely be a flickering rotating frame thingy then (one or more sprites). It would grealy reduce the need for messing up the char screen although with a char frame drawn I can possibly get away with only drawing and restoring the chars and not have to touch the colour screen or window/object screen. C) I have parts of a DOS, I install a fast loader onto the disk on detection screen and use that for any loading now, I will extend that to also support saving. But yes I will use the standard Kernal DOS for saving first as I already have a driver for that too for loading. Also, I have on the todolist a metafile footer that can be added to the end of a file to add stuff like title/author/year so that apps can show that for images at least (and possibly app info), but I have also extended the default DOS file system to use more of the 32 bytes of each file entry which are unused today. So the icons you see in the file browser comes from directly from that file structure. Ofc if you write files witout TEOS then that data is lost so TEOS has to work without that as well. D) I want the SID to be an exclusive device that can be used at all frames by one app, and if more apps want it I would likely have to make it so that only the app in focus gets to use the SID. I am still going over the options to best use the SID. The bootup sfx was just a fun little thing I wanted to try out. Its actually a Goattracker SID playing and is terminated after about 3 seconds to free it up (using the same system as an app would to play a SID). E / F) Joystick will be supported once I have abstracted the input device layer. :) - The has layers of the view, one is the window and within the window there are controls. It should be easy to both add keyboard support for switching views and tabbing through contents. More on this when I have the full controls demo running. G) Hehe, yes I see the char based videos are in the wind now. I am sure we can do some fun stuff in the future and I have a few I want to try out. H) A mix of sprites and chars is one I want to demonstrate too in the future as I have some experiments on that. I) I do not not want to distribute the code or anything at this point. Its not yet mature enough for that and as it is a hobby project I cant really spend time communicating with everyone wanting this and that. You know time is limited so I want to keep this private until I feel its ready to reduce this kind of stress/friction and be more free in what I experiment with. I certainly dont want to lock down stuff so that people who e.g. develop for it would have to constantly recompile stuff every version I put out of the core. On that note, the window manager is a simple order of windows drawn top to bottom as I also have a object screen that tells which window each char belongs to. Not only does this enable me to draw the unobscured chars of a background window, it also greatly simplifies figuring out what the mouse is pointing at. I also have different drawing routines so any window in focus is always drawn much faster as it can always replace data (and does not have to draw on the object screen). I am soon expanding this to also use this for any unobscured window as well. And I hope to finish an even more important feature for the next video too.

[@claudiusraphael9423]

@@64jcl Wow and thx for taking the time! You use backface-culling than basically (if i understood correctly), which is neat as coupling topmost graphics to the focus makes event-bubbling obsolete. Regarding the code, i totally understand - it wasn't meant as a "Yo GPL dis!", merely an indirect question if for example combining funding and say MIT/BSD-licensed Non-Disclosure-Agreement based peeks into the code. Whereas in my case the question was related specifically to the structure of the window-manager, e.g. in Pseudo-Code/UML. For example i wonder if the Window-Menu and -Buttons for Close/Minimize/Maximize could be configurable in your model meaning allowing disabling buttons, reposition them, etc. similar to classic window-managers or how KDE/Plasma handles it. I, myself, am trying to figure out a structure for such a window manager, for use in CLI and GUI and meant to be stored in CPU-Caches. Can you recommend a site/page/tutorial/documented-code that might teach me the basics of the task in question? Again, astonishing - thank you very much for sharing insights!

[@64jcl]

@@claudiusraphael9423 , np, always interesting to reply to technical questions (a future video might be one where I talk about these things). I am pondering whether to go full open source when I do decide I can let it loose although a part of me wants to hold the reins a bit as it could end up being a forking-nightmare for users so you need one specific version of TEOS to run that and another for that etc. The few times I have dabbled with Linux and other OS's I feel lost and just waste days trying to get stuff running at times so I highly doubt that is what benefits the community really although a peer review and suggestion of changes to the code would likely be welcome. I dont have a good pseudo-code/UML of the window manager, it has been an iterative development, I started in fact with some windows with a lot of custom code everywhere for this and that, gradually making the contols pattern and I am about to rewrite the whole window stuff into being a control in itself. So it really ends up becoming a classic GUI component system like any other. The reason why I didnt start with that was that it was just an experiment that has gradually grown. At times I thought about ditching all and starting all over but as of now it has a fine mix of rather poor code and good stuff. :) And yes the controls are full "objects" (codewise) that can be modified at runtime and having the rendering respond to that, I am working out some details with this regards as you will see in my latest video (#4) where e.g. setting the colour of the control is not reflected until you mouse over it at leave again. With CPU-cache I assume you mean the actual cache within a modern CPU, it must be hard to write code that doesnt cause a cache wipe but I know people like Jonathan Blow (who made Braid and The Witness and is developing his own language) is very focused on making code that works well with the cache. It is unfortunately an area of expertise I do not have at all, my only Intel x86 cpu knowledge was back in the 90s when I did some 3D rendereres that tried to use both pipelines in the CPU of a pentium processor and I can still recall the challenge and the feeling of excitement when the code ran almost twice as fast in the inner rendering loops. :) - If anything the 6502 sort of begs you to think carefully about how you use registers and the fact that you e.g. only have indirect adressing with only one register (Y) and not the other (X) sometimes makes the code a bit messy where one have to resort to selfmodifying code to use the X register as good as possible. It is if anything vital for the speed as there are limits to what an 1 MHz CPU can do. :)

[@joejoseph00]

Wow great work! Impressive!

[@rdoetjes]

Super Cool and very impressive!

[@load_accumulator]

This is awesome. Will it support SD2IEC?

[@diegodonofrio]

Impressive! Awesome work, thanks for sharing 👍

[@just2ous]

Very Impressive 👍

[@jimwright1971]

Looks great! Looking forward to seeing future progress!

[@mule1991]

Excellent! Where do I buy a Copy?

[@hmoazed]

Wow, impressive!!!

[@mwittmann2710]

That's cool stuff! Great work

[@DocMacLovin]

Incredible programming!

[@michaellosh1851]

Excellent work! I subscribed to follow future progress!

[@TomaszWiszkowski]

Fantastic work! This is a perfect thing for the old good c64! I imagine this uses the RAM expansion?

[@CaptainDangeax]

great job considering the low power of the computer, specially to implement a kind of multitasking

[@perraymondgrnnestad8187]

Fantastic work😊 I’m very impressed

[@ojkolsrud1]

Norsk? This looks incredible! When it becomes more mature, I hope people like 8bitguy will take a look at it. The UI reminds me of i3, so in my eyes it looks really modern and nice to use.

[@64jcl]

Ja jeg er norsk. :) - Some people from the Commander X16 sphere has hinted at it being a good platform for this so I might consider that although there are other platforms as well to consider. If anything it can bring another level of abtraction to how I organize the code to have more than one compile target which should be a fun challenge too.

[@ojkolsrud1]

@@64jcl Du er god i engelsk tale, altså, men jeg hørte med en gang at du var norsk;) Aha, that's cool! I see that a lot of people are asking for easy ways to write their own programs, which just proves how good everyone thinks TEOS appears to be. I don't have a C64 myself (A500 guy here), but I love watching videos of people talking about it. I hope to see more TEOS in the future - and you got a sub.

[@pden]

It's the most beautiful thing I have seen in a while. Other than for your own intellectual pleasure, experience and your CV, what can this be used for?

[@dannyshortwave]

Very impressive.

[@superviewer]

Wow great job. Not that I know too much about programming but I would have loved a gui for my C64 back in 1987. Could I suggest to you a way the user can deactivate functions that are not crucial (customizability through a control panel). I love UX that gives me the chance to make things more snappy. Anyway, really cool project!! And it looks good :)

[@soggybaguette8457]

Just a few weeks ago I was exprirementing with an old UNIX port made for the C64, so this is much more exciting.

[@adymode]

Magical

[@armin.hierstetter]

Very cool project - keep it up!

[@megaflops3860]

I love this stuff!!

[@TekWit]

great job!! That is dedication. I love it

[@Hexagonaal]

From a user perspective nothing that a FCIII can't do, but imagine having a good, modern BASIC editor in there!

[@Mr_ToR]

wow that is such a good idea. If he adds the save function and implements a Basic, I would actually use it.

[@jameschamplin1742]

Download soon?

[@deadsi]

That's really amazing

[@DD-jk3nf]

Man this is very cool :D This would make me dig out my C64

[@cybermaus]

Impressive. Small icons is good. But I wonder if you need borders. Maybe just colors, like in demo1? But impressive anyway.

[@stefanweilhartner4415]

great stuff

[@cpu_UP]

Awesome.

[@joecan]

Fantastic work. Well done!

[@charliejimenez5020]

Very impressive!!

[@janikangas6552]

This just blew my mind. For some (highly skilled, talented) people 64k is just enough.

[@JohnDlugosz]

You should make that available for the Commander X-16 computer project.

[@64jcl]

Yes I have been asked about this and I have played a bit with dev for the X16. I will likely take a look at this at one point too to figure out how easy it would be to port to other 6502 based systems as it would likely require some good separation at places where I dont have it now.

[@jayk806]

This is amazing!! Nice work!

[@xlar54]

Excellent. id be interesting in writing apps for this. What is that font size though? Have you considered a smaller font?

[@64jcl]

Thanks, well its nowhere near any kind of release I am afraid. :) - The whole OS is built upon normal text mode because its much faster/more responsive that way unlike GEOS which uses bitmap mode which is rather slow. So the character set is 8x8 pixels always. I have drawn a couple of variants to the standard font sets as I want the user to be able to change that if they want. The fonts are made so they are only 6 pixels tall though as I want to keep a space above and below it so it looks nicer within the bounds of a row. I have not decided if I will keep the inverted variant used on the bottom (and in the console which I have not demonstrated yet) as it takes a lot of the 256 chars available. Perhaps have that as an optional charset an app can try to load, reverting to the standard if there isnt enough char space. Any app can install their own custom chars you see, which will be freed up again when you close the application. I have a number of games in the works which will demonstrate this a lot although I have to find a balance between enhancing the core/window system vs making new apps/games for it. :)

[@nialltracey2599]

@@64jcl "I have not decided if I will keep the inverted variant used on the bottom (and in the console which I have not demonstrated yet) as it takes a lot of the 256 chars available." Here's a suggestion: if you make sure all of the characters needed for the task bar are in the first 64 slots, you could switch to extended colour mode for the last 8 scanlines. The 4 background colours are enough to achieve what you have here: blue for the C= button, grey for background tabs, cyan for focused tab and yellow for clock. If you later decide you need an additional colour, you could convert the C= logo to a button, using the grey background and having the blue as a foreground colour. That would also win you back one extra character on the taskbar, as you wouldn't need a dotted separator any more to keep the C= separated from the first window label.

[@64jcl]

@@nialltracey2599 , yep I have thought about switching the bottom yes, extended mode is also one I have been playing a bit with, even for the whole OS although that totally parks any custom chars for apps which makes it rather dull/useless. :) - But for only the taskbar that is a good idea.

[@TheHorus2013]

Very Impressive... Great Work !!! Seeing multitask on a C64 seems impossible.

[@richardkimes7810]

Very nice!

[@RandomInsano2]

Once this is closer to done I’d enjoy it if there were a cartridge physical release with RAM expansion. 😃

[@64jcl]

I will likely pursue a GMod2 cartridge build as my first cart build, that has a nice 512 kb flash and 2kb eeprom so that I can store e.g. OS and app settings there. Since the cart has quite a lot of memory I'd likely create some sort of cart disk that is auto mounted and a user can flash the cart with apps although I am told GMod2 flashing is only reliable on some C64 boards unfortunately. If anything it will be a stepping stone for the OS to work in ROM which requires quite a lot of rewrites since I rely heavily on selfmod code now and would have to to find smart ways to store temp variables without them gobbling up a lot of space (especially zero page space which is limited).

[@RandomInsano2]

@@64jcl I’m currently using an EasyFlash3 that also supports self-updating. Not sure if that’s reliable across revisions but it also pricey and slow to update. I think just saving RAM would be helpful, increasing it would be nice. You may be able to implement a copy-on-write into memory as they do for live CDs.

[@michaelcarey]

This is amazing!

[@ikeyasector]

Very impressive. Have you considered possibly putting this on a cartridge with it's own RAM in the future? Either way, I'm already liking this much better than GEOS.

[@64jcl]

I will likely experiment with different devices yes, atm playing a bit with IDE64 support, but the REU as a ram disk is also one coming up soon.

[@tommyb.6064]

Wow. Imagine what our computers could do with proper programming. Geez.

[@rancidbeef582]

I just stumbled across this. Impressive! Subscribed...

[@AlexanderKurtz]

very interesting project, i wish u the best of luck to gezt it finished .

[@strassenbahntk]

Brilliant!

[@jackbauer9901]

Will you be able to run games?

[@Mr_ToR]

This is very impressive. Awesome job. Do you think would it be possible for TEOS to support IDE64? There is also an IEEE488 interface for the C64, which would be very cool to support as well.

[@64jcl]

I am quite sure most devices can be supported actually and those that already work with a C64 Kernal will likely do that already as any device can have that as the default driver. The biggest hurdle would likely be to find a good way of detecting the presence of them. Atm I only detect the standard stuff to the best of my current knowledge as I do not have a lot of these other devices personally. I guess I should try getting a few of them to get support, many of them would indeed be amazing for the OS. My fist task is to support the REU as a ram drive which shouldnt be that hard.

[@c128stuff]

@@64jcl I have quite a bit of experience with things like drive probing and type detection on the 64 and 128, including recognizing things like the sd2iec, all CMD drives etc. I use this for a 128 function rom I developed and maintain (www.bartsplace.net/content/publications/devicemanager128.shtml) There is some very usefull example code for drive type detection on codebase64 which can serve as a starting point for this. The 'big' deal however is to avoid having to send an UI command to drives, as in many cases, especially with 15xx drives, that causes havoc whenever someone decided to 'soft change' the ID of a drive, so the 'proper' way is to first determine if there is anything at all present on an ID (bypassing the kernel to avoid its infinite loop), and after that try to read some of the rom of the device to determine what it is, and only fallback to sending the drive an UI command and reading its response when a memory read fails (as that basicly means you are dealing with an sd2iec or similar device, which are far less likely to cause havoc as a result).

[@iljaliepelt9597]

very cool

[@tomaszc4]

GEOS war gestern, heute ist TEOS, very nice

[@JamesSpeiser]

awesome man!

[@izkuipers]

Didn't think that a C64 could run such advanced programs, I think it is better than GEOS!

[@cedynski]

wow!

[@lexitivium]

Now, that's darn impressive. Thumbs up from an old fart, that hasn't coded on that piece of heaven for more than 35 years ;-)

[@jarnailbrar6732]

Great work!!!

[@meneerjansen00]

Will it *ever* be available?

[@inuyaksa2]

How such a great project! Your work is awesome! You search for app menus, I suggest you to use the some format apple used. A main menu in the upper of the screen, it change at foreground app. Autohiding menu could be an option to preserve all screen rows. Please release a sdk beta soon, I need to code for it. ;)

[@64jcl]

Thanks. Personally I have never been a big fan of the top-menu depending on what app is in focus. I can understand it from a space-saving view considering we are only dealing with a 1000 character screen here. I have to add standard popup menus anyway so I will likely explore those as menus first on the actual application perhaps with an option to hide them. Remember that a lot of the early OS'es were not really multitasking, they just allowed you to swap been applications as you'd likely use the whole screen for each one and hence only need to use screen estate for that one, almost like a tab-panel. My main goal for this project was to see how far I could take the standard multi window thing on our now soon 40 years old 8bit computer. :)

[@inuyaksa2]

@@64jcl create a multitasking os on a cpu without MMU it's very a big deal, and with a fixed pointer stack (Z80 have a dynamic pointer stack). Your video seems very good, I know there is a lot of limitations, but it's a breadbin with 64k (a less than 64k)! Popup menu seems a good solution, like the C= menu you have done, I presume. Do you use char mode or hires?

[@sketter1969]

very good

[@samcoupe4608KB]

80 colum n super cpu support?

[@KymyA74]

Time slice multitasking on C=64? The scheduler can recognize an hanged process or not? In every case, it's a good work man! WINDOWS can start to tremble! :D

[@64jcl]

Yes the core will detect that a process called is non-responsive and kill it as well as showing a system error. An application that does not consume its events is also a candidate for takedown. I will likely demonstrate some of these things in a future video when I feel the core is more mature as I am doing rewrites to it all the time.

[@KymyA74]

@@64jcl and we are all here waiting to see your next video! VERY GOOD WORKS!

[@androteve3887]

BRAAAAVOOOOOOOOOO !!!!!

[@ronaldboulder308]

Well done!

[@marekkarcz3946]

Did you use assembly to code your OS or did you write some portions in high-level language? How do you implement task switching? Did you virtualize CPU? How did you implement context switching scheme? This part I imagine can be real memory hog. Unless each process has own memory on the heap and you are juggling the pointers. Did you virtualize memory? (swapping?).

[@64jcl]

Yes all is coded in assembly using KickAssembler. No high level language although I use macros to simplify especially application writing as instead of loading registers and all kinds of things before calling an OS function. A macro sort of looks like a function call with parameters then. I use task switching for two major threads in the OS for now, one is the IO thread that does disk access and the other is the drawing thread. They each have on their own part of the tiny 256 bytes stack of the C64. The actual applications is not using this for now but I have a prototype of the core doing this, each having their own little bit of the stack. Atm the apps are just called from a raster IRQ and is expected to return within reasonable time, the app in focus getting called every frame refresh with the others round robin after that. Plan is to dynamically adjust the time used for apps execution vs drawing vs io depending on need. There is no virualization, there is no protection, any application can totally mess up everything now although I can check a bit when apps are instanciated when I do the code relocation. I can then detect if an app would be adressing outside its memory but not during runtime if it does selfmod code or uses zp indirect adressing. I might add severe limitation to ZP adressing though only allowing an app to use certain ZP addresses in context of execution as well as any writes only possible in the data area of the application. But all of this can very quickly make the OS huge and there wouldnt be any ram left for applications. The plan is really to just have fun with it and see how far I can get it and still have it somewhat usable and reduce the chance of apps messing things up by convention during coding. There is no memory swapping either, that would just take too much CPU time even with a REU although I can see it being possible with idle processes that can be temporarily parked to free up memory, for example the screen buffer of a window when it is minimized can easily be moved to the REU and put back again anywhere on the heap after, so that might be one case I will experiment with just for fun.

[@c128stuff]

@@64jcl if you plan on supporting the REU, you can make ram copies fast enough to swap in/out part of the stack for each application, and create a bit more room there. The 'real' solution would be to move to the c128 instead, as its mmu lets you use any 256 byte page as stack, and hence you can give every task its own complete 256 byte stack, (and zeropage) if desired.. but well.. doing this on a 64 has its own appeal.

[@yorgle]

Awesome! Very nice work! :D

[@paolobesser3382]

amazing!

[@Ziplock9000]

Is it multitasking or time slicing/yielding?

[@64jcl]

So its both, and "time slicing" is likely the word I should have been using instead of "thread" which is the wrong word. See my reply to Arnarson.