SymbOS: Graphical Z80 Multitasking Operating System | Hacker News Reader

SymbOS: Graphical Z80 Multitasking Operating System

symbos.de

204 pointsPaul_S98 comments

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.

Indeed, and it makes it harder for me to port to a Kaypro II

[edit]

Actually none of the supported platforms have less than 128KB of RAM, so it might not run on that.

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.

Right. But I did specifically say 'backend'.

Just because outsiders consider something a "problem" does not make it so. I find it odd to talk about someone else's baby like that.

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?

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.

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.

>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.

What? This doesn't happen.

status in the demo scene

...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."

This

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.

Z80 OS for a 1980s micro... wouldn't be surprised if the assembly is the source.

Labels, macros and comments still help!

If the OS is open sources here are a few Machines it could be ported to with the Z80 processor:

https://en.wikipedia.org/wiki/Category:Z80-based_home_comput...

Also the Z80 was in a lot of game systems and arcade machines. Imagine Sonic and Pac Man multitasking:

http://www.z80.info/z80gm.htm

http://kmuw.org/post/z80-most-prolific-cpu-all-time

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.

What year was that?

2018 - 18 = 2000

Maybe 1999 since the fact that it's 2018 is still maybe too fresh to have imprinted on many minds.

Maybe 2001 since GP says "nearly 18 years."

I think it was my last semester of college, so it would have been the first half of 2000.

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.

Mine too, largely because it was the first computer I ever owned - the ZX Spectrum (48k), circa 1982.

One of the most popular home computers in the UK at the time, and with good reason.

It reminds me of the Contiki OS. I wish the project was still going. It seems to have slowed down to crawl.

http://www.contiki-os.org/

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...

The specs on this are kind of weird.

Z80, 1MB memory, 2TB HDD.

Is this some kind of super Z80 clocked at 50+Mhz? I tend to think of Z80 systems as having 32-128kB of memory and 400k floppies for storage.

I think it means 1024 kB of addressable virtual memory.

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.

Edit: https://news.ycombinator.com/item?id=16079674 explains how RAM banking works in Symbos.

Indeed, you could plug extra RAM in the back of the CPC, and even stack these.

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:

https://en.wikipedia.org/wiki/S1_MP3_player

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-...)

Discussed in 2015: https://news.ycombinator.com/item?id=10749206.

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.

Much of the bloat is from higher resolution graphics, and all the layers of mitigation of various security issues that comes with multitasking.

+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.

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...

> I could compile kernels.

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.

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.

I thought the ST line was all about GEM.

If you're looking for an ST, they pop up from time to time on Goodwill's auction site.

I might be mistaken and it might be GEM. There was the base os and then another window manager it would go into.

I think you probably confused GEOS (C64 OS/GUI) with the Atari ST's GEM, GEMDOS, or GDOS. Lots of similar names!

Oh wow, I'm getting Amstrad craving all over again.

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.

Also see:

https://github.com/Octoate/cpc-sdcc-rom/

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.

Ah, you probably had a PCW:

https://blog.twitter.com/official/en_us/topics/company/2017/...

Don't let the 3" drives put you off. These days SDcard based "floppy drives" make life a lot easier:

https://hackaday.com/2016/02/28/floppy-drive-hides-sd-card-r...

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.

Gah, wrong link there:

https://en.wikipedia.org/wiki/Amstrad_PCW

17 years in development! Now that's what I call a side project. It's an amazing endeavour - a kind of K2 of Z80 programming.

A bit late? ;)

So could this be ported to anything with a Z80? Like, for example, a TI-83+ graphing calc?

I think you'll need a Z80 machine with bank switched RAM, that's how the multi-tasking side of things works.

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.

Sure, but I think SymbOS specifically requires bank switching capability:

http://www.symbos.de/symmodul.htm?0

(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.

Yeah, fair enough. You could probably get it running on one of the models I mentioned above.

> you just need PIC.

Or a relocator. This can be a bit tricky but it's been done on many architectures.

Do you have any links/pointers to systems that did this?

Wrote my own for 68xx and 65xx chips in ancient times.

https://en.wikipedia.org/wiki/Relocation_(computing)

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.

https://github.com/KnightOS/kernel/blob/master/src/00/restar...

Heh, that's cool. How do you remember which ones you've modified so you don't do it twice?

It also modifies the reset (trap instruction) in place and makes it a no-op.

http://knightos.org

Where can a machine be got to run this system?

Off ebay, An Amstrad CPC 6128 will do.

Though you may want an SD Card adapter to get the files onto it.

As the banner on the site mentions, it works on Amstrad CPC, MSX, Amstrad PCW and Enterprise 64/128 (I'm not sure what this last one is).

The Enterprise was a British dream 80s computer that most people could not afford.

https://en.wikipedia.org/wiki/Enterprise_(computer)

For me this started the trend of the render being much nicer than the final product.

https://www.theregister.co.uk/2013/10/24/elan_flan_enterpris...

Ok, this project is precious and makes me wistful for the old days. Need a golang port for this.

(Sorry, I can’t resist) ... Is it vulnerable to Meltdown and Spectre?

Sadly, no. No memory protection, you see.

Back in my day, when we saw something in RAM that we liked, we just read it.

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.

You can still do that, even more so on systems with memory protection as you will not break OS's interrupt handlers by doing that.

Notably pixomatic (Rad Game Tools' SW rasterizer) compiles Direcd3D shaders into i386 code which uses ESP as general purpose register.

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.

You would rather only have men? I’m not sure what kind of anti you are.

I wouldn't mind a few shots of both, y'know?

If you need to have pictures, take landscapes.

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.

I dunno, apparently. I personally like landscapes anyway, but am not offended by pictures of people... Just naming what might please others. :)

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.

[0] https://en.wikipedia.org/wiki/Male_gaze

I still don’t get it - there are pictures of men and women in that screenshot.

Maybe if you count the demon as male, or the tiny silhouette in the bottom right.

There are not. Only women, unless you're looking at a different screenshot.

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.

It's really jarring, isn't it?

> 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.

Maybe half women and half men.

Then the political correctness warriors come out of their holes and claim that this reduces humanity to two genders.

I find it terribly stereotypical and prejudicial of you to determine their sexes based on their exterior appearances.

Why does every comment about there being only women in OS screenshots stereotype bodies?

P.S This is a joke. Serious people who care about other people don't really care about this type of gender thing at all.

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!

What part about someone's hobby OS for a 30 year old CPU, that runs 1,000 times slower than a $5 computer, is professional?

Let's keep things in perspective, there are much bigger injustices than this out there.

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.

People like to look at women? Even most other women.

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.

Show some initiative. Fork it and put some Tom of Finland wallpapers in.

Problem solved!

Reply on news.ycombinator.com