Oberon-2 was my entry point into the Oberon ecosystem, the world of systems programming with automatic resource management languages, and all the cool ideas that are routinely explored on that parallel computing universe where the whole OS stack is mostly safe.
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.
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].
> Since Oberon is as much a compiler as it's a complete system,
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/.
Actually it's transpiling to C (but the other way around would make more sense so existing code can be ported to project oberon os). For example there's an X11 wrapper [1], or http library [2], a package manager [3], etc, and calling external C code is easy, e.g.
Other libraries are mostly scattered all over the internet, and there are often compatibility issues between compilers, even though they target the same standards.
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.
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:
Thanks. While I'm fully self-motivated (when you feel you're in uncharted waters, it's hard to stop exploring), I still appreciate some sort of external validation that I'm not delusional.
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.
i have been thinking about how to build a machine that is smaller and easier to understand and looking for an OS that is smaller and easier to understand to go with it. yours is probably one of the closest i’ve looked at…
Let me know when you find the matching hardware! I'll make it my official "canonical Dusk machine" :)
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.
conveniently i have several alixes but none with video output.
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.
i wonder if there is an easily available 68k board. not a lot out there that i could easily find. the fpga board that MiSTeR seems like a good candidate though
Before I began the m68k port, I was eyeing the rosco_m68k[1] as an initial m68k port, which would have been easier than going straight for the Powerbook 520.
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.
yeah, unfortunately. i've been on a hunt to design a sort of video terminal system (local machine speaks VT100 or NAPLPS or some other videotext plus a way to run bits of code) and i was looking at the rosco + xosera video card as a way to build it, but discovered it's no longer made.
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.
Oberon-2 was my entry point into the Oberon ecosystem, the world of systems programming with automatic resource management languages, and all the cool ideas that are routinely explored on that parallel computing universe where the whole OS stack is mostly safe.
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.
Absolutely.
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".»
https://x.com/smdiehl/status/855827759872045056
> In the meantime they are busy making more elaborate versions of C.
Or better C versions which look like Oberon: https://github.com/micron-language/specification
:-D
Nice work...
Compiling Oberon to native code, nice!
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
> Since Oberon is as much a compiler as it's a complete system,
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/.
Actually it's transpiling to C (but the other way around would make more sense so existing code can be ported to project oberon os). For example there's an X11 wrapper [1], or http library [2], a package manager [3], etc, and calling external C code is easy, e.g.
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
> Compiling Oberon to native code, nice!
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?
Yes, that's what I mean.
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.
Not really, no.
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.
Interesting, I didn't know about that!
I wonder why the Project Oberon website doesn't link to those ports.
Because it's an updated version of Prof Wirth's original in-house project from ETH, once an inexpensive FPGA became viable.
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:
https://blackboxframework.org/
check out this version as well. Seems to run on 64-bit computers. https://gitlab.inf.ethz.ch/felixf/oberon
I love what you’re doing with duskos! have been watching for a while.
Thanks. While I'm fully self-motivated (when you feel you're in uncharted waters, it's hard to stop exploring), I still appreciate some sort of external validation that I'm not delusional.
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.
i have been thinking about how to build a machine that is smaller and easier to understand and looking for an OS that is smaller and easier to understand to go with it. yours is probably one of the closest i’ve looked at…
Let me know when you find the matching hardware! I'll make it my official "canonical Dusk machine" :)
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.
[1]: https://pcengines.ch/alix.htm
conveniently i have several alixes but none with video output.
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...
m68k is nice to work with.
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.
i wonder if there is an easily available 68k board. not a lot out there that i could easily find. the fpga board that MiSTeR seems like a good candidate though
Before I began the m68k port, I was eyeing the rosco_m68k[1] as an initial m68k port, which would have been easier than going straight for the Powerbook 520.
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.
[1]: https://rosco-m68k.com/
yeah, unfortunately. i've been on a hunt to design a sort of video terminal system (local machine speaks VT100 or NAPLPS or some other videotext plus a way to run bits of code) and i was looking at the rosco + xosera video card as a way to build it, but discovered it's no longer made.
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.