flashjazzcat

MaxTasks = 16 (an arbitrary value, chosen to keep the process table at a reasonable size). The following processes are run at start-up: Clock Desktop Idle File manager Kernel System Two of these (clock and file manager) are classed as applications, and the rest system tasks. So it would be possible to run ten profilers. Memory usage is indeed quite high right off the bat, but the kernel immediately counts 48K ($0000-$3FFF and $8000-$FFFF) as used (by ROM, the 8K display buffer, and internal tables), and the system allocates RAM (by 256-byte page) for quite a few large resources before the desktop comes up. Note also that one page (256 bytes) of each 16K extended memory bank is reserved for memory housekeeping.

Prodatron (the SymbOS author) has been a regular participant in this thread and it was he who convinced me to abandon my mask-based window manager and replace it with a rectangle-based one similar to what he implemented in SymbOS. Indeed, it was he who convinced me to make the thing multi-tasking.

Relocatable code occupies no more memory than non-relocatable code once loaded from storage and fixed up in RAM, so the only real issue presented by the lack of an MMU seems to me to be the lack of memory protection (so random writes outside of the application's allocated RAM can be somewhat disruptive). The minimum RAM requirement is 128K, with (on that base configuration) 80KB available for resources and applications (four extended banks plus the main bank). That's ample for a handful of applications, resident resources, etc. In point of fact the system could probably run in 64K, although the limitations (16K for applications and resources) would severely impede usability. Although, since we now have a proliferation of mass storage devices which are as fast as RAM to RAM CPU block moves, it would be fairly trivial to cache an inactive process to disk if RAM was in contention. That's why the UI is one of the processes which runs entirely in banked ROM, consuming no RAM whatsoever. Applications, meanwhile, can implement a complex UI using minimal code (since they're just calling the OS instead of drawing everything themselves). Probably so, although all but a few of the most ardent coders will probably balk at the complexity of the window and dialogue descriptions and hope that someone also writes a resource editor to make application development less intimidating. Appreciated - thanks! You mean SymbOS? I had a cheeky idea the other week while making a video demoing 'Let's Emu' (Spectrum emulator for the 65C816). If we can emulate the Z80 at reasonable speed with Rapidus, would it not be feasible to emulate the CPC (with VBXE taking care of the emulated display)?

You can do this with SIDE3 as well since it not only reads and writes FAT, but provides a DOS that reads and writes FAT (something else not mentioned in the video). Totally agree regarding the convenience of RespeQt and virtual folders used by SIO2PC and Altirra, though. The ideal situation is to have both (SIO2PC and multi-cart).

That's almost as surprising as the prior response. I have no particular insight into how WUDSN works, but I assumed the code parser would collate a list of identifiers and simply sort and present them however it saw fit (since the assembler need not even be present for the outlining feature to work). I was hoping to avoid the situation of a label like 'buildLBA' effectively appearing in a separate list of lowercase identifiers after the end of the list of identifiers beginning with (or wholly comprising) uppercase letters, since a case-insensitive sorting algorithm would - for example - place 'buildLBA' right after 'BootDisk' and in front of 'CheckSwap' regardless of character case. Perhaps this is just the way Eclipse works, anyway, so I'll have to live with it (the source files being far too huge to start messing around with label names just in order to circumvent this issue). Thanks!

Yes: my supposition is that operating system language configuration has no bearing on the matter of sorting strings in WUDSN Outline view.

Really?

Not sure if I asked this already or if it was already implemented in a beta (so, apologies in advance), but would it be possible for the sorting of labels and identifiers in the Outline section to be case-insenstive? Right now, all identifiers whose names begin with a lowercase letter appear later in the list than those whose names begin with an uppercase character.

Apologies to @danwinslow (who kindly reached out to me privately). I (grumpily) completely misconstrued his remarks in my prior post (as he pointed out, he was really referring to the thread rather than the project itself or its objectives).

That doesn't come across as a killjoy comment at all. I already remarked on the open-source multitasking kernels that had been ported to the A8 long before I started the UI, let alone the multitasking kernel, and I've yet to see anyone drape a GUI on top of them, and probably for good reason (it may ultimately be a solution looking for a problem). When it comes to priorities, back in 2014, the clear need for better U1MB/SIDE/Incognito firmware far outweighed the GOS in terms of importance (and remember the primary motivation for rewriting the U1MB firmware was initially to provide the GOS with a means of booting from ROM), and as it happens, doing that eventually contributed to my turning my hobby into my self-employed occupation (I wasn't working at all for much of the time when I was working intensely on the GOS, and when I did get a full-time job in IT support - itself partily because of some firmware I had produced - I recall being too tired after work to do any large-scale coding). And - as mentioned previously - work on the SIDE2 and later the SIDE3 loaders took care of FAT drivers on the A8 (R/W in the case of SIDE3, as recently as two years ago, with long filename support, etc), filesystem drivers being one of the more intimidating obstacles to turning the GOS 'demo' into a full operating system. Shortly after I finished the R/W FAT drivers, we sold my parents' house (both of them having died in 2021/22), bought this place, and I expect to have the place fully fixed up by the end of 2024. Coding priorities include the SIDE3 Loader, Ext U1MB/Incognito Lite/Incognito 3 firmware, etc, etc. Will I start dabbling with the GOS project again? More than likely, since I have ready-written filesystem driver code now which didn't exist ten years ago. Regarding the SDX FAT drivers: I completely appreciate and support developers who wish to 'do it themselves', and I heard some gossip that the R/W version of the SDX FATFS.SYS 'exists somewhere', but who knows. I reached out to Trub about a year ago, nevertheless, offering to help add write support if it wasn't already done, but I received no response whatsoever to that offer. I would write a R/W driver myself, but unfortunately - while the SDX developer documentation is absolutely excellent - the chapter on writing filesystem drivers is still missing, so we're at a bit of an impasse there at the moment. Someone from the Americas offered me some kind of financial support scheme back in 2013 or so, but I didn't pursue it since it seemed to me at the time like making a pact with the Devil. Once you accept money (regardless of all the failed Kickstarter projects which exist), you've committed yourself to providing a product of some kind, and that's a considered responsibility, IMO. The amount of time required to complete the GOS - unless invested piecemeal over a couple of years - would be significant enough to affect my day-to-day occupation (whose backlog of work I am still struggling to manage), and if that's neglected for a year while I work full-time on the GOS, I'd risk having no job at all at the end of it. I haven't forgotten the donations I received a decade or more ago in terms of support for the GUI/GOS project, but sending tips to egg someone on to push the project further and formalising a funding scheme in order to ensure a completed project are two entirely different propositions. Couldn't really have put it better myself. It's a valid concern, and definitely something that's in the back of my mind when I wonder whether - for instance - to improve a game loader for which I get paid and which is used by hundreds of SIDE3 owners, or a graphical OS which people would probably tinker with for five minutes (imagine any recent GEOS demo on YouTube, for example), adjusting the font size in the word processor and dragging windows around the screen. And if - as it appears to some - the whole project is just about 'can it be done?', then we already know it can be done, since the GOS 'demo' works, has a ROM file system, and runs multiple processes at the same time on a 128K system, and uses a graphical front-end with proportional fonts. LOL. Reverse psychology sometimes works, I suppose, to inspire people to finish something out of spite or a sense of indignation, but this thread (which I actually have hidden because it's become such a time-drain in its own right; I'm only here because I was quoted) has been such a source of motivation and demotivation in almost equal measure, they pretty much cancel one another out now, and thus become irrelevant. Part of me wishes I had written nothing at all on the forum until the system was complete, but on the other hand, without public discussion, we wouldn't have the cool mouse pointer, nice visuals, efficient window manager, or the multitasking kernel (all of which are - directly or indirectly - a result of community discussion and participation).

We already had this discussion - laboriously and over several years - with the likes of Atari8Warez, whose assertion that the hardware wasn't up to the talk was already comprehensively debunked several times over by the time he got himself banned for harassing me off-site. Multitasking has worked smoothly since 2013 or so, with performance better than anyone expected. The impediments - if I have to list then again for the umpteenth time - are basically lack of time, lack of motivation, and fatigue over the need to constantly defend and justify the system's viability and functionality to people with no real grasp of how it works or why it's perfectly reasonable to run such an OS on an 8-bit machine (if you're happy to code everything in raw assembler, at least).

Micron DRAMs. Socket and replace as a matter of routine, and if that doesn't fix it, delve deeper.

Isn't the state of the machine to just use nothing but the OS keyboard interrupt handler until KEY ON is executed?

Have you swapped both ANTIC and GTIA at the same time? The fact behaviour changes when ANTIC is swapped is significant. CPU and thus ANTIC (and RAM and PIA to some extent) are working if the OS is able to set up the display list, and GTIA works well enough to drive the display. POKEY is don't care if you take it out. Worth having a complete set of known good DRAMs regardless, though, just in case.

But does such a facility exist in SpartaDOS 3.x? I don't seem to remember it.