Yeah, I thought about mentioning that, but it seemed ungrateful to complain of a lack of drivers when I've never written one (but I do still wish someone would take that on as a project).
It wasn't a complaint, just a fact. Btw. instead of natively porting the Oberon system, it's also possible to just transpile the Oberon code to C and then natively (cross-)compile the C code to the target architecture. That would even work with a bare-bone system. I have two Oberon system versions based on this approach (https://github.com/rochus-keller/OberonSystem and https://github.com/rochus-keller/OberonSystem3). Replacing the PAL/SDL adapter to a plain frame buffer and serial input seems feasible. Using a framework like https://github.com/rsta2/circle would make the task even easier. Of course the Oberon compiler does still generate code for the original architecture (one could replace it by a compiler using e.g. TCC as a backend).
I made Pascal for 8080 in about a week in 1979. How is it possible you may ask?
Well son, I had Lisp and I just added Pascal translator. Only caveat was that it ignored type declarations and such useless academic shit. Because I had sort-of compiler too, it was not really bad when compared to Turbo-Pascal.
I found 50 pages manual for the Noko-Pascal. Finnish Army paid for it, because nothing comparable was available. Writing the manual was 10 times bigger task.
The army used Nokopaskal for testing radio modems. Looks like the language was heavy with low level constructs like PORT.
Hot damn, that's such a cool piece of engineering that's worth its own post. I reckon hand coding a Lisp in assembly was commonplace in the late 70s, but these days it's like seeing an artefact from a long-lost civilization, as we've mostly lost those kind of skills.
The version with external 5 x 64k memory is definitively in Osborne-1 disk drawer.
But Osborne does not work. It was so heavily modified that it will never work. The external memory was partially visible in memory space. And the display driver was improved to have 80 columns.
Now that I think about it, it might be possible that it could work in both configurations. The external memory was kinda bulky and not suitable for portable computer.
It would have been wasteful to keep the main memory empty. Or maybe it was reserved for compiled functions?
All had same type, they were pointers. VAR-section was anyways useful for testing that there was no errors in spelling of symbols. And array was a list. And strings were just list of numbers, with special symbol in front. It looked very professional, only error message were little bit incomprehensible and lispy.
Unlike competitors (whatever they were) it had garbage collector, incredibly useful in 64k machine.
Awesome. Thanks for posting. I miss my modula-2 so much I wrote a bunch of editor macros for Lazarus that allows me to write slightly modula-2 like code in the editor.
Also XDS has been freely available for a couple of years now.
What I miss is that there is no modern equivalent of formating keywords on save, I helped with one plugin for Sublime Text on Oberon, maybe need to do the same for VSCode.
Anyone with a spare Micro-SD Card and a Raspberry Pi 5 should try:
http://pascal.hansotten.com/niklaus-wirth/project-oberon/obe...
This is just an emulator which runs on Raspi Linux, not a native implementation. You can run it everywhere, even on Windows.
Yeah, I thought about mentioning that, but it seemed ungrateful to complain of a lack of drivers when I've never written one (but I do still wish someone would take that on as a project).
c.f.,
https://github.com/MGreim/ultiboberon
It wasn't a complaint, just a fact. Btw. instead of natively porting the Oberon system, it's also possible to just transpile the Oberon code to C and then natively (cross-)compile the C code to the target architecture. That would even work with a bare-bone system. I have two Oberon system versions based on this approach (https://github.com/rochus-keller/OberonSystem and https://github.com/rochus-keller/OberonSystem3). Replacing the PAL/SDL adapter to a plain frame buffer and serial input seems feasible. Using a framework like https://github.com/rsta2/circle would make the task even easier. Of course the Oberon compiler does still generate code for the original architecture (one could replace it by a compiler using e.g. TCC as a backend).
Super exciting! Thanks
I made Pascal for 8080 in about a week in 1979. How is it possible you may ask?
Well son, I had Lisp and I just added Pascal translator. Only caveat was that it ignored type declarations and such useless academic shit. Because I had sort-of compiler too, it was not really bad when compared to Turbo-Pascal.
I found 50 pages manual for the Noko-Pascal. Finnish Army paid for it, because nothing comparable was available. Writing the manual was 10 times bigger task.
The army used Nokopaskal for testing radio modems. Looks like the language was heavy with low level constructs like PORT.
I truly did not remember any of this until today.
https://photos.app.goo.gl/uibbTgCQmm4XCa9c6
Erh. What?
Here is my infamous 1976 Nokolisp-compiler at work:
https://github.com/timonoko/nokolisp
Interesting work.
Time to setup DOSBox + MASM + etc etc.... :D
Hot damn, that's such a cool piece of engineering that's worth its own post. I reckon hand coding a Lisp in assembly was commonplace in the late 70s, but these days it's like seeing an artefact from a long-lost civilization, as we've mostly lost those kind of skills.
noko.exe works at dosbox without any "etc etc".
nokolisp.exe is just a kernel without editors and macroes.
for building the interpreter from the source, of course. because... well why not? :D
Thanks for the 8088 version on Github. Any chance you still have the 8080 CP/M version?
The version with external 5 x 64k memory is definitively in Osborne-1 disk drawer.
But Osborne does not work. It was so heavily modified that it will never work. The external memory was partially visible in memory space. And the display driver was improved to have 80 columns.
But the stand-alone CP/M-version is long gone.
Now that I think about it, it might be possible that it could work in both configurations. The external memory was kinda bulky and not suitable for portable computer.
It would have been wasteful to keep the main memory empty. Or maybe it was reserved for compiled functions?
Types are academic shit to you? I despair.
All had same type, they were pointers. VAR-section was anyways useful for testing that there was no errors in spelling of symbols. And array was a list. And strings were just list of numbers, with special symbol in front. It looked very professional, only error message were little bit incomprehensible and lispy.
Unlike competitors (whatever they were) it had garbage collector, incredibly useful in 64k machine.
[flagged]
It’s a shame these type of comments exist on HN. Can’t say anything without upsetting some JS devs these days.
Awesome. Thanks for posting. I miss my modula-2 so much I wrote a bunch of editor macros for Lazarus that allows me to write slightly modula-2 like code in the editor.
Since GCC 14, that GNU Modula-2 is part of GCC.
Also XDS has been freely available for a couple of years now.
What I miss is that there is no modern equivalent of formating keywords on save, I helped with one plugin for Sublime Text on Oberon, maybe need to do the same for VSCode.
There is also an LLVM-based Modula-2 compiler written by an LLVM contributor: https://github.com/redstar/m2lang
I thought it would be Pascal for microcontrollers :) Still very nice!
Here, they are in business for decades now,
https://www.mikroe.com/compilers/compilers-pic
> Pascal for microcontrollers
It's in the making, but needs more time: https://github.com/rochus-keller/micron/
[dead]