The code has some 386 things implemented but not protected mode 286 stuff.
Seems to be written by somebody who writes fairly neat and clean code, but hasn't discovered structs yet.
Definitely not cycle accurate. Video emulation only covers simple standard modes, not the undocumented ones, not proper hardware programming.
Does have a decent handling of (real-mode) interrupts. The AT keyboard interface (+ keyboard itself) is handled poorly on Windows/Linux -- the code for handling bytes sent to the keyboard is missing + there is no emulation of the receive queue in the keyboard controller. The code for the Raspberry Pi PICO is different: it actually bit bangs some pins to support a PS/2 interface (basically an AT interface). Still doesn't handle any buffering as far as I can see.
There is an 8K PC XT(?) BIOS included with no mention of where it comes from. The code there handles hardware interrupts. The software interrupt BIOS API is handled in C code (intcall86() in src/emulator/cpu.c).
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.
My first neural net code (very very bad) was on a 286/287 back in the early 90s. 286 is kind of a forgotten chip since 386 32 bit changed the game but give a kid (ie teenage me) a 286, a 40mb hard drive, and Turbo Pascal and I felt like I could build anything!
Anyone else instantly turned away by the LLM emoji bullet points?
This project could be the work of an enthusiastic developer with a deep understanding/love of the 80286 or LLM slop based on regurgitated code stolen from years of hard work by dedicated retro emulator developers. Unfair or not, emoji bullet points do not give confidence it's the first.
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.
Not sure if it's 100% slop, but as someone knowledgeable about older x86 processors, I can say after a casual look through "src/emulator/cpu.c" that the code is pretty terrible and often wrong.
For example, "subtract with carry" simply adds the carry to the second operand before doing the subtraction, which will wrap around to zero if it's 0xffff; this doesn't affect the result, but the carry out will be incorrectly cleared. Shift with a count of zero updates the flags, which it doesn't on real hardware. Probably many more subtle bugs with the flags as well.
It can't really be called a 286 emulator either, because it only runs in real mode! For some reason there is already code in there to handle the 32-bit addressing of the 386, but it can't have been written by someone who actually understands how the address size override works - it changes both the size and the encoding of the address register(s), "AX+BX" is never a thing, nor is "EBX+ESI" (etc) used if there is only an operand size override. Also what looks like a (human?) copy-paste mistake with "EBX" in a place where it should be "EAX". At least all that code is #ifdef'd out.
And rather than running a real BIOS, it appears to handle its functions in the INT emulation code, but what is there looks too incomplete to support any real software.
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.
Code is also LLMed + no screenshots, no videos, no software compatibility listed, no github issues/error reports and nobody on the googlable internet ever ran this. No idea whats going on.
The idea reminds me of the fact that truly old-ass Intel clones are the foundation of many a microcontroller design [1]. Searching for the 8051, the most popular family, here on HN will lead you to some very deep rabbit holes [2].
The code has some 386 things implemented but not protected mode 286 stuff.
Seems to be written by somebody who writes fairly neat and clean code, but hasn't discovered structs yet.
Definitely not cycle accurate. Video emulation only covers simple standard modes, not the undocumented ones, not proper hardware programming.
Does have a decent handling of (real-mode) interrupts. The AT keyboard interface (+ keyboard itself) is handled poorly on Windows/Linux -- the code for handling bytes sent to the keyboard is missing + there is no emulation of the receive queue in the keyboard controller. The code for the Raspberry Pi PICO is different: it actually bit bangs some pins to support a PS/2 interface (basically an AT interface). Still doesn't handle any buffering as far as I can see.
There is an 8K PC XT(?) BIOS included with no mention of where it comes from. The code there handles hardware interrupts. The software interrupt BIOS API is handled in C code (intcall86() in src/emulator/cpu.c).
> Seems to be written by somebody who writes fairly neat and clean code, but hasn't discovered structs yet.
So Claude, given the CLAUDE.md file in the repo?
Pretty sure Claude knows about structs.
Well, then Xenix 286 is out of the question ...
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.
My first neural net code (very very bad) was on a 286/287 back in the early 90s. 286 is kind of a forgotten chip since 386 32 bit changed the game but give a kid (ie teenage me) a 286, a 40mb hard drive, and Turbo Pascal and I felt like I could build anything!
Did you run TP in the '87 mode?
Anyone else instantly turned away by the LLM emoji bullet points?
This project could be the work of an enthusiastic developer with a deep understanding/love of the 80286 or LLM slop based on regurgitated code stolen from years of hard work by dedicated retro emulator developers. Unfair or not, emoji bullet points do not give confidence it's the first.
Looking at the commits, for me it seems to be LLM generated. Claude is even mentioned in one of them [0].
[0] https://github.com/xrip/pico-286/commit/d7fd03193fa3f406758a...
At a first glance, it looks cleaner than a lot of real emulator code I've seen.
What would you do if you only spoke English and Russian was the global language?
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.
If this is LLM translated then I'm very impressed!
https://github.com/xrip/pico-286/issues/28
Not sure if it's 100% slop, but as someone knowledgeable about older x86 processors, I can say after a casual look through "src/emulator/cpu.c" that the code is pretty terrible and often wrong.
For example, "subtract with carry" simply adds the carry to the second operand before doing the subtraction, which will wrap around to zero if it's 0xffff; this doesn't affect the result, but the carry out will be incorrectly cleared. Shift with a count of zero updates the flags, which it doesn't on real hardware. Probably many more subtle bugs with the flags as well.
It can't really be called a 286 emulator either, because it only runs in real mode! For some reason there is already code in there to handle the 32-bit addressing of the 386, but it can't have been written by someone who actually understands how the address size override works - it changes both the size and the encoding of the address register(s), "AX+BX" is never a thing, nor is "EBX+ESI" (etc) used if there is only an operand size override. Also what looks like a (human?) copy-paste mistake with "EBX" in a place where it should be "EAX". At least all that code is #ifdef'd out.
And rather than running a real BIOS, it appears to handle its functions in the INT emulation code, but what is there looks too incomplete to support any real software.
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.
Since it's 286, can it run the cursed Xenix 286? Do hacked GDTs work?
Code is also LLMed + no screenshots, no videos, no software compatibility listed, no github issues/error reports and nobody on the googlable internet ever ran this. No idea whats going on.
Russian site, fwiw.
The idea reminds me of the fact that truly old-ass Intel clones are the foundation of many a microcontroller design [1]. Searching for the 8051, the most popular family, here on HN will lead you to some very deep rabbit holes [2].
[1] https://en.wikipedia.org/wiki/Intel_MCS-51
[2] https://hn.algolia.com/?q=8051&utm_source=opensearch&utm_med...
xrip (Ilya), if you read this -- please post a write up of your emulator(s) on vogons.org!
be warned: LLM slop with mucho bugs (i, immediately, see a few serious correctness issues)