Oberon at Voyager Closest Approach
This image of Oberon, Uranus outermost moon, was captured by NASA Voyager 2 on Jan. 24, 1986. Clearly visible are several large impact craters in Oberon icy surface surrounded by bright rays. http://photojournal.jpl.nasa.gov/catalog/PIA00034
More: https://images.nasa.gov/details/PIA00034
Credit: NASA/JPL
#oberon #voyager #astrodon #astronomy #astrophotography #astrophysics
This weekends light reading will include catching up on past few months of W0rldtr33 (comic book) and reading some #oberon sources from Project Oberon https://people.inf.ethz.ch/wirth/ProjectOberon/index.html
In addition, I'm deep diving Lola-2 (Wirth's Logic Description Language for FPGAs) to see if it still compiles...
#KnowledgeByte: #Voyager 2 caught #Uranus during a rare solar wind event that crushed its magnetosphere and stripped its plasma.
Re-analysis shows its magnetic field isn't uniquely dead, significantly raising the odds that moons #Titania and #Oberon hide subsurface oceans.
https://knowledgezone.co.in/posts/New-Findings-about-Uranus-6800a19b8a59135b1641ad53
Uranus - Montage of Uranus Five Largest Satellites
Montage of Uranus five largest satellites taken by NASA Voyager 2. From to right to left in order of decreasing distance from Uranus are Oberon, Titania, Umbriel, Ariel, and Miranda.
More: https://images.nasa.gov/details/PIA01361
Credit: NASA/JPL
#oberon #voyager #astrodon #astronomy #astrophotography #astrophysics
"The first decision was to build an entirely new system on a single board. As
processor I chose a Strong ARM (DEC 1035), a RISC architecture delivering the computing power of (at least) the two Intel 486s with a power consumption of little more than 1W. The next decision was to eliminate the RT-OS, as it seemed possible to do essentially without concurrent processes in the form of threads. The third decision was to program the entire software in Oberon [2], which is very suitable for “programming close to the hardware”.
- Niklaus Wirth, Embedded Systems and Real-Time Programming 2001
"The designer of embedded systems should be a mechanical, electrical, and software engineer all in one."
- Niklaus Wirth, Embedded Systems and Real-Time Programming 2001
@trcwm
In all of the above, I've could have said #Forth (instead of #Oberon) but of course without the interactivity.
But, I do the same in pure/plain Forth: No magic, no sophisticated compiler doing optimizations.
It's refreshing. I've got a portable oberon compiler that emits portable ANSI C. I have no primary/basic data types but BOOLEAN, CHAR and INTEGER (the lack of "unsigned" is definitely a hinderance, but I have some runtime stuff, in C, including bit operations, that mostly fixes those omissions)
@trcwm
I'm doing some bare metal AVR (8 bit MCU) in #oberon (using an Oberon to C transpiler and hand coded register addresses from spec docs) as well as some (BSD/Linux/MacOSX) server side companion (over serial USB) to the AVR.
I would normally do this in #C99 (or believe it or not #Ada) but Oberon is forcing me to think about what I want to do vs figuring out compiler/language tricks to optimize what I want to do.
For example -- I have a simple comms protocol full of little endian values.
In C (or even in Ada) I would be tempted to slam a packed little endian oriented data structure over top of a transferred binary blob and call that a protocol vs having to explicitly byte by byte walk the data... I C I can do this easily. In Ada I can tell the compiler the endianness I want and it magically does the translation.
Oberon simply doesn't have the facility for such optimization tricks.
And you know? I feel more like I'm writing elegant code than "hacks" that need copious documentation.
astropic
marocddot
Knowledge Zone