[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.
br
Jörg
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>:
Hello,
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.
Regards,
Micahel
--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon
More information about the Oberon
mailing list