[Oberon] QEMU target implementation for Oberon RISC architecture

Jörg joerg.straube at iaeth.ch
Wed Jan 1 09:15:35 CET 2020

Hi Michael

I see. It was just an idea. If we could agree on using the second byte to identify the emulator, we at least agreed on something (
Then we could at least say "SYSTEM.H(2019) DIV 100H MOD 100H = 0" means "no emulator".

Perhaps we'll find another numbering scheme for this second byte without generating too much coordination between the emulator authors.
Perhaps I'm overshooting and only one bit is enough to say "I'm an emulator". Happy to hear your views.


Am 31.12.19, 18:08 schrieb "Oberon im Auftrag von Michael Schierl" <oberon-bounces at lists.inf.ethz.ch im Auftrag von schierlm at gmx.de>:

    Am 31.12.2019 um 10:31 schrieb Jörg:
    > Just to refine my idea. The *second* byte of the MOV’ instruction could
    > identify the emulator as follows:
    >   * *P*eter de Wachter’s emulator could return     50H (ASCII “P”)
    >   * *A*ndreas Pirklbauer’s emulator could return  41H (ASCII “A”)
    >   * *C*huck Perkin’s emulator could return             43H (ASCII “C”)
    >   * *M*ichael Schier’s emulator could return          4DH (ASCII “M”)
    >   * *R*oel de Jong’s emulator could return             52H (ASCII “R”)
    I don't think this will work out to identify emulators in a sensible way
    (e.g. their feature set).
    Chuck has done one Emulator in Go and now he is working on QEMU.
    I have done one desktop emulator (in Java), and then one
    feature-incompatible Web emulator in JavaScript (which I later ported to
    Webassembly/AssemblyScript). And last but not least I also maintain a
    fork of pdewacht's emulator (adding 16 color support, host filesystem,
    rtc, and drag&drop for PCLink).
    At least my 3 emulators have different feature sets, so I could not
    think of any good reason why they should get identified the same way.
    Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems

More information about the Oberon mailing list