Unfortunely moving past UNIX clones and C seems a task only to be fulfiled by the true hero that is yet to come as per the old prophecy, routinely told by village elders on cold Winter nights around a warm fireplace to keep children entertained.
In the meantime they are busy making more elaborate versions of C.
«C syntax is magical programmer catnip. You sprinkle it on anything and it suddenly becomes "practical" and "readable".»
Or better C versions which look like Oberon: https://github.com/micron-language/specification
Nice work...
Since Oberon is as much a compiler as it's a complete system, a big part of the work is to integrate that system into its host. It seems they've done it for files and stdin/stdout, but not for the graphical system yet (through SDL or something). I wonder if it's on their roadmap.
As a shameless plug, I'm in the process of doing something very similar[1] for Dusk OS[2].
[1]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/co...
[2]: http://duskos.org
The system and the language are two different things (even if they unfortunately share the same name); the language itself doesn't depend on the system. Instead there is a standard library defined in the Oakwood guidelines; the guidelines even define a (primitive) drawing window (XYPlane). The Oberon+ compiler (see https://github.com/rochus-keller/oberon/) includes a foreign function interface and a binding to e.g. the NAppGUI library which is a powerfull cross-platform user interface framework, but also an SDL binding, which is e.g. used by https://github.com/rochus-keller/OberonSystem3/.
PROCEDURE -fstat(fd: LONGINT): INTEGER "fstat(fd, &s)";
Other libraries are mostly scattered all over the internet, and there are often compatibility issues between compilers, even though they target the same standards.
[1]:https://github.com/vishapoberon/compiler/tree/master/src/lib...
[2]:https://github.com/norayr/http/
[3]:https://github.com/vishapoberon/vipack
> very similar[1] for Dusk OS[2]
wow this is cool
I may be missing something but don't all versions of Oberon compile to native code?
Or is what you are getting at code that's native to the underlying OS and not the Oberon environment?
Classic Oberon compiles to RISC5 (not RISC-V), which is a "made up" CPU. Unless you have a FPGA, Oberon is always going to be emulated on a regular machine.
Here is the 386 PC version, which loads from MS-DOS.
https://sourceforge.net/projects/dosoberon/files/DOS%20Obero...
Other versions run or ran on ARM, 68000, PowerPC, x86-64 and other platforms.
I wonder why the Project Oberon website doesn't link to those ports.
I wrote about it a decade ago:
https://www.theregister.com/2015/12/02/pi_versus_oberton/
That's one source reflecting one particular project, which Prof Wirth came out of retirement to help with. It is not representative of the broader use and adoption of Oberon at all. Once there was commodity 32-bit hardware, Oberon researchers adopted it with enthusiasm and it has at various times run on most 32-bit CPUs.
These days, the work I'm aware of is mostly on x86, though. For example, this commercial offshoot, Blackbox Component Pascal:
But this stuff (well, Forth in general) requires such a big shift in mindset as to how we approach computing that I understand why it stays niche. Kind of like Lisp but, IMO, deeper.
Most modern hardware is way too complex. Dusk uses a fraction of it, but still has to deal with spurious complexity.
Personally, my favorite 32-bit SBC so far is PC Engine's Alix board[1]. Sure, it has the ugly BIOS legacy, but is otherwise a very nice no-frills SBC. I just wish I bought one with a VGA adapter before it closed shop.
I am actually thinking about custom hardware at the moment. Or maybe FPGA emulation of custom hardware. I actually would prefer a smaller machine but most of them are too impaired (eg 6502 is just a bit too weird)
so probably 68k-based. which you support! (is there a boot image somewhere? i wonder if it would run in an emulator)
right now my thought is an FPGA board is probably for the best...
I've never tried Dusk OS m68k port in emulation because of the "dogfooding doctrine" I began enforcing with that port: no other tools than Dusk's. So it only ever ran on a Powerbook 520 (unless people have tried it elsewhere without telling me).
I don't know if it runs on the basilisk emulator. I suspect it's likely that it doesn't because my booting method is highly unorthodox. I don't push the same "buttons" as system7 at all, so it would probably confuse the emulator.
That being said, if the I/Os of your machine are simple, porting to it should be easy. Reach to me if you need help, I'd love to have a second m68k machine to run on.
But after a vintage buying spree a few years ago, I told myself that I wouldn't buy hardware anymore (unless it was really really cool or really really needed), so I'm on a strict "make do with what you have on hand" discipline :)
But that SBC looks nice.
Oh, I see that they don't sell kits anymore, you have to do the sourcing yourself. Maybe it's a bit more complicated.
i saw somewhere that people were able to emulate a 68k mac just barely on an esp32 so maybe that's the way to go. it's cheap and sorta connected, at least.