The NEC V20 is an Intel 8088-compatible processor that features the same use of microcode, though with its own characteristics. This makes it important to use this same microcode if your goal is to create a cycle-accurate emulator of this processor, as [GloriousCow]’s goal is. Cue decoding the microcode ROM in a die shot of this CPU, in order to create a usable ROM image.
As with any fabricated ROM you can technically do it by hand, the ROM section in the die shot contained 29,928 bits which even at a pretty zippy pace would take up a considerable amount of time to parse. Here you can divide-and-conquer by handing parts of the ROM off to good friends, or you can use automation and some machine vision and theoretically get an answer as soon as you have finished writing and testing the tool.
Although [Travis Goodspeed]’s MaskRomTool exists exactly to automate bit detection, it was found that there wasn’t enough contrast in the die shot for it to work reliably. What it did provide were the locations of the bits and from it 42×42 pixel PNG files of each bit.
Next a convolutional neural network (CNN) was trained to determine the difference between a 0 and 1 bit. This still took the manual classifying of 1,000 images, but seemed to work fairly well. Although some bits were marked as ambiguous, it was easy enough to use Mark 1 eyeballs to run a classification on these handful of images than to tweak the CNN model.
With this microcode in hand it was then possible to match it against the V20’s internal architecture to fully determine what each part does. Although not quite finished yet, there’s a GitHub repository containing the progress so far.
The V20’s microcode has been the focal point of much legal fighting back when NEC and Intel were still duking it out in how far one could make a CPU compatible with that of a competitor.
Isn’t Ken Shiriff doing the same thing with the original 8086 microcode ROM? I think Intel’s patents and the court documents from their lawsuits with NEC guide his efforts.
He’s currently working on decoding the 8087 microcode, which I also did the ROM extraction for.
Brilliant.
Looking forward for computer vision and AI tools to soon be able to completely reverse-engineer boards, from PCB pictures, X-ray scans, and die shots. Combined with a CNC-like probing machine for actual on-board measurements.
This might sound ambitious, but it would have seem totally out of reach few years ago. Now it looks like it could happen within a couple of years.
Maybe they will also figure out the 8080 timings, which AFAIK were never published (8088 timings were ~15% faster on average). Yes, in case you didn’t know, this processor had an 8080 mode!
Meant you could run CP/M or at least CP/M programs on a V20 before the PC version was ready, If I remember right.
While old CP/M 2.2 would run, many commercial software packages would not, because they required a Z80. When the V20 became available in 1984, the 8080 was already a thing of the distant past. I guess NEC included the 8080 mode and the 80186 opcodes just because they could – and as a digitus impudicus towards Intel.
NEC had its own PC line at the time, too.
The PC-8801 was Z80 based, while the PC-9801 was i8086 based.
Later models used other CPUs, such as V30 (aka μPD70116).
The NEC PC-88VA had used NEC μPD9002, which is said to had used an V30/V50 core with full Z80 compatibility.
The 80186 opcodes were part of the second, updated version of 8086 ISA.
Things like ENTER/LEAVE, PUSHA/POPA, INS/OUTS.
It was called “8086-2”, I think. Not to be confused with the “-something” speed ratings (8086-2 also was 8 MHz model).
Info: https://tinyurl.com/2xf88fmz
I think the PC was ready by 1985 or so. There were Z80MU, 22NICE etc.
These emulators for DOS had a Z80 core (emulation) and could run Turbo Pascal and TP programs.
The CP/M emulators with support for V20/V30’s 8080 emulation mode were quicker, of course (v2080.com)..
Example: https://www.youtube.com/watch?v=RVjVQ_L11Vc
Sophisticated CP/M fans would have perhaps considered to use a full software emulation of the Z80 on an PC/AT or compatible instead.
Or something similar (the Tandy 2000 had a fast 80186)..
Yes, the 8080 timings are quite clear from the microcode.
Great! And…how do they compare to the original??
They’re completely different. The V20 is still prefetching and doing 4-cycle bus cycles while executing 8080 code. There’s no attempt to match the 8080 clock for clock.
Way back when, I worked at a company that assembled and sold IBM clones, and I found something interesting about the NEC V20. At that point the clone Motherboard manufacturers had extended the IBM XT architecture such that they had both 8 mhz and 10 mhz XT clone motherboards. In testing a number of NEC V20 CPUs, I found that the 8 mhz part actually ran a measurably faster without appreciable heating in 10 mhz motherboard than the actual 10 mhz V20. The combo of the 8 mhz V20 and 10 mhz motherboard benchmarked faster than an 8 mhz 286 AT clone. I chatted about this to a friend who worked designing chips, and they suggested that they might have had problems getting the 10 mhz V20 working reliably, and may have put in wait states to slow it down to work consistently. Based upon this, I do claim to be one of the earlier CPU “overlockers”.
Hi, that’s very interesting! Thank you for sharing your experience here! 😎
Um, this was before my time but there are some things that come to mind.
the duty cycle of V20/30 and i8088/86 are different (V20: 50% or 1/2, i8088: 33% or 1/3).
Thus, the V20 runs a little bit out of spec on a bog standard 8088 motherboard/PC BIOS that’s not V20 aware.
So it also depends on the system if the V20 CPU runs stable or not.
Later Turbo XT boards like the Juko XT had been made with some V20 support in mind (jumpers, V20 BIOS etc).
early 80286 CPUs were quicker than their motherboard/RAM, so wait states had to be added.
The IBM AT had very slow RAM and was only available in 6 and 8 MHz.
At one point, IBM’s AT BIOS had a speed test built-in, to prevent running past 8 MHz.
IBM didn’t want the AT to be “too good”, it seems.
Third-party AT BIOSes such as AMI, Award or Quadtel didn’t have that limitation and could be used as a drop-in substitute here.
The less popular IBM XT 286 (basically modern AT board in an PC XT chassis) had better timings than the IBM AT.
I think since the NEC V20/V30 were quite modern for its time,
it might well be possible that it’s faster in certain situation than an 80286 system at similar clock-speed.
Some instructions, such as the string operations may require fewer cycles on the NECs, maybe.
But again, the XT era was a bit before my time. I’m just a layman here.
“I think since the NEC V20/V30 were quite modern for its time,”
Maybe, if your view had been limited to IBM PCs and compatibles. The V20 was introduced six years after the 8086 in 1984, and six years were half an eternity in that fast-paced business. The same year brought us much more powerful CPUs like 68020 and NS32032.
Yes, I see it like you said (wrote). :)
Compared to the i8088 the V20 was quite an improvement.
The i8088 (and i8086) had a slow bus unit interface, used complicated bus multiplexing and had to do address calculation via its arithmetic logic unit.
The i8086 was equally limited in principle, but the 16-Bit i/o made it sort of bearable.
At about 5 MHz clock, the i8088 was slower than an 1 MHz 6502.
The V20/V30 had a dedicated adder, I think, that caused less overhead to the arithmetic logic unit.
Too bad it didn’t also have an internal 128 Byte cache or something (like a big serial port FiFo)..
Personally, I think that the V20 relates similar to the i8088 as the i8080 does to the Z80 (or i8085 at very least).
Other way round, of course.
Cool stuff. The V20 definitely was a big thing when it came out. I’m glad to share some of the crazy things I did over the years from my first computer job assembling memory boards for an aerial survey computer.
I confess I’m a bit skeptical any V20 system benchmarked close to an AT. The 286 not only has a larger bus, prefetch and instruction queue, but critically its bus cycle is half that of a V20 at only two nominal cycles.
That’s plausible if you compare an 8 MHz V20 in a well designed XT clone with an 8 MHz 80286 in an original IBM PC AT using the same OS and benchmark software compiled for 8086 – which is what also happened in real life. My guesstimate ist that 99% of all ‘286 desktop machines were used with inadequate software and thus couldn’t leverage the processing power of the newer CPU.