Symbos is pretty cool but it's a crying shame that it's closed source. A lot of people in the z80 community don't understand the value of open source, but will give away binaries for free.
I have asked many times for the source from author, Podatron, but he doesn't seem to like the idea. I use Symbos on the MSX-2 and with a disassembler under an emulator you get quite far without the sourecode, especially if you start by studying the source code to the apps on the system. Luckily the system is very small (as is the memory on these machines), so with a few weekends of tinkering you can find your way around in it.
MenuetOS also suffers this problem. The 64 bit version is closed-source/non-Free, but available free of charge. Great way to limit wider interest in the project, and they're not even making bank. They get to spite the people who'd want to fork the project, I guess.
The D programming language also had this problem for a long time (closed-source/non-Free compiler backend), but thankfully no longer.
Tiny correction: the reference D compiler's source code was available, but its backend was not Free Software (it was non-redistributable). This was not by choice of its authors, but due to a historical IP/licensing snag. Today it is fully open-source.
Certainly in the case of D, adoption and real-world usage was/is a goal. Perhaps less so for MenuetOS and SymbOS, but even 'pure' hobby projects tend to enjoy public interest. They don't just live on someone's hard-drive in a basement somewhere.
That D's licensing issues are now gone, certainly benefits D.
Even if adoption isn't the goal, making it FOSS might still make good sense. Suppose the goals are novelty and technical achievement. More interest means more support in developing their novelty OS, no?
A lot of people in the z80 community don't understand
Don't be so patronizing. Of course they understand it, but what they want is something different from what you want: status in the demo scene. If they open source it they're likely to end up as a footnote in their own projects rather than basking on difficult-to-scale peaks among their peers.
It's not like open-sourcing it is going to enrich them in some more concrete fashion than social currency; in fact, authors of very popular open-source projects regularly find themselves in the humiliating position of having to beg for money.
...and since the demoscene is closely associated with the cracking/warez scene, the implicit message is always "if you want to know how it works, get a disassembler and figure it out yourself."
Agree with all this. Lots of demogroups have started releasing open source these days, which is heartening. There's definitely a feeling that the scene is getting older, so possibly passing on knowledge may be a motivator.
>If they open source it they're likely to end up as a footnote in their own projects rather than basking on difficult-to-scale peaks among their peers.
The Z80 will always have a place in my heart. Mostly because we used it in college to build a computer from scratch on a wire board.
That was an awesome project, and one of the classes that I remember fondly from nearly 18 years ago.
We did a similar thing with an 8086 processors around the same time. I only wish we did more of coding firmware rather than all the time designing the wireboard and circuits.
Adam Dunkels, the main guy behind contiki (and just an awesome dude, all around), went on to found thingsquare. I guess that's probably where new development is happening...
Z80s are still found in embedded systems, sometimes even in consumer electronics; these, for example, are based on a SoC with a Z80 core at (software-configurable) 24~60MHz, a few hundred KB of bankswitched RAM, and up to several GB of flash storage:
2TB disk? If you use a real Z80, you can probably run that in append-only mode for the rest of your life. Writing full time at 100kB/s would produce about 9GB/day, filling up that disk in about 6 years. Producing and writing 100kB/s isn’t realistic for a Z80 at <10MHz, though (10 cycles/byte seems to be the best for memcpy, and you would need to generate data, and drive that disk, too. See https://retrocomputing.stackexchange.com/questions/4744/how-...)
The Amstrad CPC had 64K or 128K of RAM + 32K of ROM (in a total addressable space of 64K) using "RAM banking". The Amstrad PCW was the same but with even more RAM (up to 512K). This worked very differently from what we now think of as virtual memory.
On the CPC it worked as follows: There were two 16K ROMs, located at 0-16K and 48K-64K. The 16K-48K middle area contained 32K of fixed RAM.
The upper and lower ROM areas were shadowed by RAM. By writing to an IO port you could switch in either the ROM or a 16K bank of RAM individually into each of those two 16K areas. There was an elaborate system of trampolines to allow the ROM functions to be called, or for the ROMs to read/write to the bank of RAM "hidden" under them.
Cool! Why exactly did it take so long BTW? (not complaining, just curious about the hard parts). Although the first computer I've used was a ZX Spectrum I was too young to program it at the time and have never had time to actually revisit it later. About a decade later (that was the epoch of Windows XP and Ubuntu already) I had a dream of running Visual Basic 1.0 for DOS on it, developing text-mode pseudographical winforms-like apps (clones of Total Commander and Excel :-)). Ever since then I have been passively curious about whether it actually is hard or not and why nobody actually tries this (isn't the GUI alone actually a fairly easy thing every computer can manage as long as we give up all the eye-candy effects and accept the fact actual calculations on data are going to be fairly slow?). Cool to see people have implemented something like this actually and have even done it in graphics rather than in just pseudo. Also, why can't we use modern languages like Python or their subsets to write Z80 programs, at least very simple ones?
These sorts of things are great reminders of just how bloated modern software is and what is possible if you can avoid the bloat. These systems are less powerful than a typical modern washing machine or refrigerator.
But orders of magnitude more bloat? I had full multitasking in the late 80's, on an Amiga 500 with 512K of RAM. There was no memory protection, but there was a GUI.
I remember running Linux (kernel 1.0 and earlier) with X11, in 8 megs of RAM or less, back on an old 486. I could compile kernels. Running emacs was a bit painful, however.
What we have today is more bloated than I could have possibly imagined 20 years ago...
Compiler bloat is definitely an issue. There has been a lot of work that goes into intermediate representations and all sorts of optimizations that results in very diminishing or no returns for many use cases.
Runtime bloat is a much bigger issue. You have multi-stage runtimes that have an interpreter, a bytecode compiler, and a JIT. Huge amounts of RAM use and very CPU intensive. This makes sense for webGL games, but totally pointless for the common case of running tracking adware on websites whose only real content is a page or two of text.
The main problem are applications with poorly written event loops and memory leaks. That is why modern computing feels bloated. Slightly better compiler output or another 5% improvement in JS runtimes cannot solve this problem. It is a type of induced demand - the more RAM and CPU you have, the more accessible computer programming becomes to people who have very little idea of what they are doing and how to do it properly.
+1, and add theming and dynamic resizing of GUI elements to that. In the old days a window was not much more than a rectangle buffered in some structure in memory, nowadays a hell of complexity and CPU cycles are required to deal with different fonts, themes, widget sets etc.
Nice to see GEOS referenced in this article - it also was the underpinning for the Atari ST line of computers that did well Europe and swung well above their weight.
If only I could find an ST 1040 again to appreciate Revenge of the Mutant Camels on a machine that was as good at desktop publishing, animating, creating sprite based games and and making music.
They're still around. I've put one together over the course of years, a) for nostalgia value, and b) for my children to at least be able to use the system I learned to program on.
Mine is a 464 w/ DDI interface, 64KiB RAM expansion, SDcard based "floppy" drive, mouse, and RS232 serial port. Still only a green screen, though, and I've yet to make a ROM box.
I had one of those Amstrad with green screen in the US. Sold mainly as a word processing system. My dad bought it since we couldn't afford a PC at that time. It did its job as a word processor well plus I had a great time digging into the guts of the CP/M operating system. What I really hated was that it had a 3" floppy which were hard to find.
I have one for my CPC. Note that in the particular case of the CPC464 (not the 664 or 6128) you'll still need the Amstrad DDI disk interface unit, as the base 464 has no disk controller built in.
Yeah that is the one. It eventually failed after many years. I remember typing up the Eliza program in BASIC for it and one of our neighbors kids still has fond memories of playing with it.
The TI-83+ does not have bank switched RAM, but it's sister products the 83+ SE, 84+, and 84+ SE do. Regardless, you can achieve preemptive multitasking on z80 without banked RAM, you just need PIC.
(relevant sections passed through google translate de->en)
Memory Management
SymbOS supports up to 1024 KB of RAM, depending on what was connected to a memory expansion. The memory manager splits the entire RAM into individual blocks of 256 bytes, which can be assigned completely dynamically.
A big feature here is the fact that SymbOS applications are always executed in a secondary 64K ram bank. Thus, each program is allowed to allocate and address up to 63KB in one piece. Screen memories and operating system routines are all in the first, severed ram bank. They are virtually invisible and do not stand in the way of the application. Of course, an application can also reserve more than 63KB for itself.
Banking Management
If an 8-bit CPU is to manage a memory of up to one megabyte (which is theoretically at least 20 bits for the address bus), then it can possibly become very complicated. This is where the bank switching administration of SymbOS comes in, which regulates everything independently and transparently. Completely unaffected, e.g. System routines located in a completely different bank are called by programs as if they were in the same 16-bit address range. Using the so-called transfer ram area (the top 16KB of a ram bank) both the operating system and the application can access the same memory from two different 64K banks. Copying memory areas between any two RAM banks is also possible without any problems.
If you have access to the symbol table it is an easy problem to solve, if you don't it can get quite difficult all the way to impossible if the original code makes use of tricks such as jumping into the middle of an instruction. But if the code is 'well behaved' then it can usually be done.
Many games used tricks like this to relocate themselves to memory that was otherwise not usable for programs, for instance to live in secondary screen space. This ensured the game would be wiped on reset. Crude but effective.
For fun, I took a "happy medium" approach in KnightOS. Programs are written with RSTs (basically the z80 version of traps) next to each instruction with a relative address, then the kernel looks up the return address on the stack, partially decodes the next instruction, and then modifies the code in RAM to update the address to the correct one. It's basically just-in-time PIC.
My BBC Micro (6502) even had a memory viewer in ROM that ran at ~50fps and I remember the fun looking at running timers and keyboard/joystick ports getting activated and such.
Years ago I wanted to do that on windows and found out that there was something called protected memory, now it finally looks like I can experience that fun again, although at a slower pace it seams ;-)
Which also meant you could do a lot of optimisations - like moving the stack pointer to point to the display memory area and using 'push' to blit a chunk of image data to screen which was quicker than using an 'ld' loop.
Also having polymorphic functions where you could write over a couple of bytes to make the function behave differently at runtime - saving code memory space - and learning the hex for most of the common opcodes at same time.
Uh, it has (at least, by conventional stereotypes; I don't know the actual gender identity of the individuals involved, at least some of whom are fictional) women’s headshots, a man (though this might not be apparent in the actual image without being familiar with the source image), a male demonic figure, and a reptilian beast that doesn't particularly have strong gender indications.
So, is your complaint that it I closed female-appearing figures at all, or...what, exactly?
The screen cap is dominated by three glamour shots of women. It's not like it just happens to contain a woman getting on a train or ordering a coffee, among other images.
While it would be more accurate to say that it contains “only figures that conform to female body stereotypes” rather than “only women”, to the extent the latter is an issue of any kind, the former is an issue of the same general class (in fact, I don't think the people complaining about the former would actually be concerned at all if it was the former but not the latter); further, in the case of images where he individuals aren't known to the speaker, the only way the latter can sensibly be interpreted is as a reference to the former, so the objection itself seems to me to be rather context-blind pointless pedantic distraction from any substance.
Thanks, I'll try to be mindful when I'm stereotyping and joking about upset gender people and remember this to improve the quality of the joke the next time!
In this particular case it feels like a throwback to 80s-style tech marketing. I think the low resolution bitmap images look cool and associate beauty with the OS in a way. I understand your point but I say keep them!
In this case it's arguably tied to 80s home computer nostalgia, but that itself rests on a bedrock of 'computers are boys' toys' sexism that gave us booth babes and all sorts of other nonsense. Magazines of the period had small ads for 'graphics collections' (soft porn) you could order on disk and of course much BBS culture was a way of accessing porn for boys either too young or too shy to buy it in magazine form.
> Why does every OS screenshot (not from a big company) always have to have a few pictures of women in it?
> It's ridiculously unprofessional in my book.
If it were pictures of men, people would complain that there are no women included in the pictures people (i.e. women are discriminated against). You can't be everybody's darling.
It reinforces the idea of the IT industry as a place for men, and the male gaze[0], as well as injecting sexuality into an entirely asexual domain for no reason. If we want computing to be inclusive, and I personally do, then we should make representations of computing inclusive.
That is diametrically opposed from being "anti" anything.
I thought the two on the left were women and the one on the right was a hair band rocker (man).
I think if anything this is confirming your individual biases about what men and women should look like, which is part of the problem with our tech community. Even if I'm wrong about the rocker (likely), the problem isn't the picture - it's all of us.
Is this really where we are at now? Don't demonstrate any software using pictures of people, even in a niche hobbyist OS for a retro CPU architecture, just in case someone gets offended.
