[Oberon] QEMU target implementation for Oberon RISC architecture

[Charles Perkins]

I did add pcf font loading capability in Fonts.Mod but Michael Schierl did
the work of adapting Oberon to handle Unicode and fonts with more than 128
characters in them. My changes and what I adopted from him and others can
be found in projects under the Github organization https:///
github.com/io-core where I have taken the liberty of dividing the Project
Oberon files into logical packages that could be versioned and developed
separately and combined appropriately with package management tools.

The division is notional, I don't have a finished tool yet, much yet an
Oberon native one, though there is  a prototype tool written in go in
https://github.com/io-core/Mod that illustrates where I think we could go
in having distributed Oberon package repositories with semantic versioning,
checksums, etc. without making any changes to Oberon itself and with
allowing divergent implementations of Oberon with common sub-features.

So, to answer your question, the pcf font loding is found the Fonts.Mod
file in https://io-core/Edit along with the rest of the text-specific code
in Project Oberon. The fonts I have been using can be found in
https://github.com/io-core/io/tree/master/core/fonts but that hasn't been
made into a package yet.

Packages? For Oberon? Sure!

Each package in this model is located with the files in a directory (such
as a github repo or whatever you like) and starts with a <package>.Pkg file.

A .Pkg file is a simple text lines in a csv format like this, for the
"outer core" of Oberon, which has some changes from the original Project
Oberon files, which I arbitrarily set at Version 5.0.0, and
which ''requires'  at least the original versions of the Files, Modules,
and Kernel packages (but minor version bumps are OK) but which requires at
least version 5.1.0 of the Edit package as defined in io-core because it
relies on Unicode changes introduced there, and provides four modules
(Oberon.Mod, Input.Mod, Display.Mod, Viewers.Mod and MenuViewers.Mod, each
checksummed for verification:

Oberon.Pkg:

k,v1,v2 package,Oberon,v5.1.0
from,github.com/io-core,whenever
license,PROJECTOBERON,NW JG PDR MS CP
r,[core]/Files,v5.0.0
r,[core]/Modules,v5.0.0
r,[io-core]/Edit,v5.1.0
r,[core]/Kernel,v5.0.0
p,Oberon.Mod,a427a83c7b04278a6d51ccef9a88c854656aeece870d9f8cb6bfe947400236d1
p,Input.Mod,c4add3b8d70c0ae4a77c972bb7ae7fc77e3169566cb2afb9cadeadee998a055f
p,Display.Mod,4157ff39acbdc7dcfecab8903fb8a99386ec89c6247de09e224faf6d2e4f4657
p,Viewers.Mod,68dd972188ccca1b91c0f1e26204ce2cdec73098501c0fc15db334bbfab6ffe7
p,MenuViewers.Mod,3f49849f9103be0c466df69c1c73324137416a85bb27b993e943ae6e56c89f89
Once you have individual packages the natural next step is to create an
index of them that can be queried and retrieved from and (if you have
permission) updated. A simple text file suffices:

Packages.Ndx:
package,license,version,location Edit,PROJECTOBERON,v5.1.0,
github.com/io-core/Edit
Files,PROJECTOBERON,v5.0.20130815,github.com/io-core/Files
Kernel,PROJECTOBERON,v5.0.20140204,github.com/io-core/Kernel
Mod,MIT,v0.1.0,github.com/io-core/Mod
Modules,PROJECTOBERON,v5.0.20190108,github.com/io-core/Modules
Attest,MIT,v0.1.0,github.com/io-core/Attest
Crypto,MIT,v0.1.0,github.com/io-core/Crypto
Script,MIT,v0.1.0,github.com/io-core/Script
Draw,PROJECTOBERON,v5.0.0,github.com/io-core/Draw
System,PROJECTOBERON,v5.1.0,github.com/io-core/System
Build,PROJECTOBERON,v5.0.0,github.com/io-core/Build
Oberon,PROJECTOBERON,v5.1.0,github.com/io-core/Oberon
Paint,PROJECTOBERON,v1.0.0,github.com/io-core/Paint
My Packages.Ndx is found in https://github.com/io-core/Index/ and in my
imagination other developers would publish their packages similarly, and
perhaps a package ecosystem might build on this so that Oberon can have the
equivalent of pypi or npm, etc.

All of the above is just what I am using with my own files and there is no
reason anyone else will want to adopt it other than I see a need for
package management of some kind but attuned to the specific needs of the
Oberon system, and the above is what I've come up with.

Best Regards,

Charles

On Sat, Dec 28, 2019 at 12:37 AM Joerg <joerg.straube at iaeth.ch> wrote:

> Hi Charles
>
> Nice.
> You must have changed some Oberon files like Fonts.Mod and Texts.Mod.
> Didn’t browse through all your qemu fork yet. Are your Oberon changes
> available somewhere?
>
> Jörg
>
> Am 28.12.2019 um 02:37 schrieb Charles Perkins <chuck at kuracali.com>:
>
> 
> This is to let you all know about a fork of QEMU (a very fast emulator
> with lots of features) introducing the Oberon RISC architecture.
>
> https://github.com/io-core/qemu-risc6
>
> It is unfinished and I probably should have waited to announce it but the
> new year starts soon and I just want to share some pretty (to me) pictures.
>
> As it says in the readme on the github page, the target is named risc6 to
> avoid confusion with the already existing riscv target in qemu and because
> in one communication (An Update of the RISC5 Implementation
> <https://inf.ethz.ch/personal/wirth/ProjectOberon/RISC5.Update.pdf>)
> Professor Wirth defines module RISC6 to introduce interrupts into the
> architecture.
>
> I intend to update the readme with build instructions and binaries that
> can be simply downloaded, etc.
>
> Happy Hacking,
> Chuck
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20191228/e9d74f13/attachment.html>