Intel 80286 emulator for Raspberry Pico

Bios is lightly modified https://github.com/virtualxt/pcxtbios (https://www.phatcode.net/downloads.php?id=101)

Pretty sure Claude knows about structs.

Any code that treats the machine like an opponent in a full contact sport is out, not just code that relies on a 286. There should still be lots of tame code that kinda, sorta almost works.

It's useless as a real emulator, it's impressive as a hobby project.

Probably release it in English, and not blindly trust an LLM to accurately translate something I am about to post online if I am unable to verify it for accuracy.

There is emulation code for the PIC (interrupt controller) and PIT (timer) + various other stuff. The intcall86() filters out and handles INT 10h/13h/etc but everything else is emulated "for real": ip/cs/flags are pushed, new cs:ip set, etc.

There is an 8KB BIOS of some sort defined as a big array which should handle boot and hardware interrupts.

> Probably many more subtle bugs with the flags as well.

Sure. And lots of subtle bugs in general. Which is fine for someone's personal fun side project.

Russian site, fwiw.

[dead]

Another trick that might work:

https://gcc.gnu.org/onlinedocs/gcc/Global-Register-Variables...

As the docs say, it isn't easy to use it in a safe way but it might speed up your CPU emulator.

This trick used to be common in VMs that were compiler targets. It was also sometimes used by compilers that compiled to C (for portability). There would be some preprocessor magic that enabled it on certain common targets so the C code would compile to faster code.

The implementation strategy here would be something like:

  - keep the x86 registers (8 GPRs + PC + flags) in a struct somewhere when executing outside the CPU code

  - on entry to the CPU core, copy from the struct into global register variables

  - on exit from the CPU core, copy them back

  - everything inside the CPU core then uses the global register variables => no load/store code needed, no code for calculating memory addresses of the x86 registers needed

  - the way operand read/write works in the CPU emulator would have to be changed (probably)

  - the entire structure of the CPU emulator would have to be changed (probably), so each opcode value would have its own C code, and each modrm byte value would also have its own C code

  - you might need to use some compiler magic to force the CPU core to use tail calls and to avoid tail merging

Computed gotos to help with the tail calls: https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

Disable tail merging: -fno-tree-tail-merge

If you want to go really crazy, you can have a faster handling of prefixes:

  - instruction interpretation doesn't look for prefixes, it just uses a jump table

  - in case of REP/REPNE/CS/ES/SS, set a flag + use a jump table on the next byte.  The code jumped to is general enough to read the override flags and access memory properly

  - the normal code does not look at the segment override flags and does not have that flexibility

You can use the same C code for both, you just need to put it in an include file and include it twice (and set some #define's before each include).

There is zero reason to have a slow CPU emulation, especially as you are not doing cycle accuracy.

Again, this is something you can play around with and prototype for a few x86 instructions first.

Even if you don't want to change your emulator in these directions, you could still learn some practical C tricks by writing the prototype code.

If it helps, the word is "pidgin".

* https://ru.wiktionary.org/wiki/pidgin#%D0%90%D0%BD%D0%B3%D0%...

> My english is pretty bad, its take time to write post in not sort of a 'pigeon English' :)

Why not work on it? Isn't there a fairly substantial return on investment for someone in Russia who does that? This is not meant as a put down or an insult. Just general befuddlement because it seems like a no-brainer to me.

---

So cpu.[ch] are from fake86 -- via faux86 or straight from fake86? What version did you fork? That is something that would be good to put in the readme.

You wrote the files in the drivers/ directory? And LinuxMiniFB.c, WinMiniFB.c, {linux|win}-main.cpp, pico-main.c? And the audio code?

Tell people what you wrote. You get better feedback that way.

> Sometimes, when code looks rought or stupid (why no struct, folks?) -- keep in mind it's target on very limited cpu power and MUCH more limited RAM of RP2040.

This is what Wikipedia says about the RP2040:

    Dual ARM Cortex-M0+ cores (ARMv6-M instruction set), Originally run at 133 MHz,[2] but later certified at 200 MHz[16]
    Each core has an integer divider peripheral and two interpolators
    264 KB SRAM in six independent banks (four 64 KB, two 4 KB)

It has never been the structs that slowed my code down. structs are free. Passing them into functions with or without pointers is usually free (or cheaper than free!) with modern C compilers -- but that was not the case until 5-10 years ago, I think.

I haven't checked if Mike Chamber's original cpu emulator was "struct free". Maybe it was and you just inherited that "feature" ;)

> Also, code mess of .inl.c cause we need maximize functions inlineing, each funciton call on pico took abonrmal amout of CPU cycles.

Doesn't link-time optimization (LTO) solve that for you? It looks like you use it in CMakeLists.txt:

    add_link_options(-flto -fwhole-program)
    # -frename-registers -fno-tree-vectorize
    add_compile_options(-flto=auto -frename-registers -fomit-frame-pointer -fwhole-program -ffreestanding -ffast-math -ffunction-sections -fdata-sections -fms-extensions -O2)

How do you profile code on a Raspberry Pi Pico?

Btw, the redirector interface comes in slightly different versions (different struct sizes in different DOS versions). Which DOS versions do your redirector work with?

Getting "some things" to run is 0.001% of work of writing an emulator. Reaching "50% of the software corpus for the system" is 1% if the work, reaching "90% of the software corpus" is 10% of the work, reaching "99% of the software corpus" is 20% of the work, and so on...

The long tail is long, and for older, more esoteric systems, it is veeeeeeeeery long. You'd be surprised how far a 286 emulator will get with broken implementation of carry out sometimes.

Source: wrote more emulators than I can count