Let's experiment: NEC V20 + FPGA

What happens when you connect a NEC V20 to an FPGA? Let's find out!

Similar projects worth following
I have an NEC V20 and an unused Intel Cyclone II FPGA board lying in the drawers. How would these two interact together to become a functional, simple and primitive x86 mini-computer? Let's find out!

This experiment is an attempt to connect an NEC V20 chip to an FPGA board.  This is inspired by a few of the webpages I've read :

Initially, I had planned to connect the V20 to the supporting logic chips for memory decoding and etc., but it could be an extremely difficult approach as many things could go wrong in between. In order to save time, I directly connect this V20 to the FPGA board I have. Lucky for me, this FPGA board has a 32MB SDRAM which I could load up a small BIOS inside and as a frame buffer for the video generator.

As a start, some of the experiment will be done in SignalTap II to verify the operations of the decoders are correct or not.


NIOS 2 SDRAM Template for ASK2CB.

RAR Archive - 13.42 MB - 06/02/2019 at 13:16


  • 1 × NEC V20
  • 1 × FPGA board with SDRAM with many I/Os too!

  • Moving the project to Digilent Cmod-A7!

    NYH-workshop08/13/2019 at 12:52 0 comments

    Whew! Apologies for the long delay - I was working on this on-and-off, and struggled on the new Digilent Cmod-A7 I got in a cheap price from a local store (they are doing stock clearence).

    Unfortunately, I had been also wrestling on the Xilinx Vivado toolchain, and it looks like it hasn't been quite nice to me. I've asked around in Digilent, and lucky me they are helpful enough to get a simple project to be compiled:

    Also, unlike the Intel  Quartus ones, I couldn't add 74 logic blocks inside their system board, and had to fabricate my own 74245 + 74373 glue logic in Verilog instead.

    Even compiling it could be painful - 5 minutes and I ended up simulating on the most part of the design. Finally, I got this to catch the lower address without using 74373 and 74245! (all inside the FPGA)

    All is not done yet, and I'm doing my best to make it run a simple program. As usual, the logic analyzer output shows the 8088 reading 0x90 (NOP) from FPGA and the FPGA latches the bottom half of the address each strobe.

    Note: For the previous log, I had found out that Cyclone 2 doesn't have libraries or Nios part to directly connect the SDRAM to some other peripherals. This only exists in newer Cyclone models, so I had to use the Digilent Cmod-A7 I got from a stock clearance sale instead.

  • Cyclone 2 Nios 2 - A little diversion!

    NYH-workshop06/02/2019 at 13:16 0 comments

    Whew! I have got the chip select to work finally - all I need to do is to put the address in the "always" block:

    always @(A0_19) begin
    	if(A0_19 >= 20'hffff0 && A0_19 <= 20'hfffff)
    		CS_IO_1 <= 1;
    		CS_IO_1 <= 0;

     At the least, when it resets, it goes back to the same address and the same instructions instead of going everywhere in the last experiment:

    Since I can get it to be selected, what if I try to connect this to an SDRAM? Sounds like I'm wrestling with a grizzly bear. Or maybe not. Hmm, I can try to dump some stuff into the SDRAM as a start. Fortuntately, I still have the old copies of the sample codes when I purchased the ASK2CB. However, I got into a big roadblock - getting this to compile, and even getting this to be programmed into the SDRAM is a big issue too! That old codes which have the NIOS only worked in Quartus II 12 and below, and I'm using the last version 13, so I have to port that whole project into Qsys.

    And that's isn't fun, I admit. I couldn't even convert the thing without getting errors during compilation and etc. I have to create that project again, and used these SDRAM values I got from the old codes:

    It is extremely tedious! After a whole evening, I got this to work finally:

    Of course, that doesn't end here. I'm writing a simple loader program that loads stuff from the PC to the SDRAM on that board. And here are the updated NIOS 2 project template too, if you do not feel like creating the whole project again. (The project template is in the files section: nios_sdram_ASK2CB)  

  • Running short fragment of program - but needs a lot of fixing!

    NYH-workshop05/26/2019 at 14:42 0 comments

    I have squeezed some simple instructions into a 16-byte ROM that writes 0x04 into the I/O address 0x00, and repeats (

    MOV AL, 04
    OUT 00, AL
    JMP A

    This is then converted into machine code  (, and I write this in the *.mem file that the Quartus 2 can deploy into the array (

    module storageReadOnly(output [7:0] data, input [19:0] addr, input RD);
    reg [7:0] memory16bytes [16:0]; 
    initial $readmemh("rom_image.mem", memory16bytes);
    assign data = memory16bytes[addr & 20'h0000f];

    The "rom_image.mem":

    B0 04 E6 00 EB FA

     And here it runs:

    However, the decoding part isn't the most straightforward thing to write in Verilog. I'm not even sure if my version of decoding could work:

    always @(negedge ASTB) begin
    	if(A0_19 >= 20'hffff0 && A0_19 <= 20'hfffff)
    		CS_IO_1 <= 1'b1;
    		CS_IO_1 <= 1'b0;

     This CS_IO_1 is a temporary chip-select to select an I/O address which I will connect these to the LEDs later to verify the operation. I'll expand on the V20 writing to the FPGA after this.

  • A8-19: Can be seen too!

    NYH-workshop05/25/2019 at 15:48 0 comments

    After connecting all these wires from the V20's A8-19 to the FPGA and quickly turn on the SignalTap, it's already known that it is starting from the reset vector 0xF_FFF0.

    My next step is to have these connected to a simple, small 16-byte memory block and run a short piece of code there.

  • AD0-7: Address grabbed.

    NYH-workshop05/22/2019 at 13:45 0 comments

    I have added a 74373 into the Quartus 2 BDF on the inputs of the 74245. And yes - it grabs the first 8 bits of the address.

    I have even placed a 0x90 opcode for the processor to read - and at least, it looks like it now starts from the reset vector.

    The top bits of the address - gonna connect these afterwards. Hopefully it's the 0xFFFF0. :)

  • AD0-7: Me trying to grab its address first!

    NYH-workshop05/20/2019 at 15:08 0 comments

    Lucky me I have a bit of a long holiday here and I managed to have the FPGA to grab the address from the AD0-7 first. The bad news is, the FPGA couldn't grab anything on the address. Going back to the basics and to further understand how this 8088 works, I wired up the extra 74373 on top of the 74245,  with reference to

    And when I connected the first four bits on the 373's Q0-Q3, I'm getting this:

    I'm suspecting that it's working alright, since the address is counting upwards (the 8088 starts at address FFFF0).

    The more tough part is I do not have enough pins on the FPGA board's connector to even connect that latched address A0-A7, so I'm cooking up some method on how I could effectively make this run properly without adding even more stuff on top of it!

  • Back to the drawing board!

    NYH-workshop05/12/2019 at 14:03 0 comments

    After another weekend on fumbling on why the ASTB that wasn't strobing, I had to take apart the FPGA and the V20, and did some research on it. 

    Referring to the page:, seems that to get the ASTB to strobe, I had to connect this to a 74LS245. The other port of the 74LS245 is a bit pattern 0b10010000 (x86 NOP instruction). Without the ASTB strobing, the rest of it will not work even if I connect the FPGA to it (this schematic is made using EasyEDA):

    With all the trial-and-error again, I breadboarded everything and connected the clock to the Analog DIscovery 2's waveform generator. Also, the supply is +3.3V because I wanted it to be compatible with the FPGA board.

    And there's the ASTB strobing! Unfortunately, the noise was terrible and I'm planning to get rid of it as much as possible!

    Well, it's at least working, but the challenge is to put this back into that FPGA! No easy task, I'm expecting a lot of roadblocks ahead! :)

  • Oscillator!

    NYH-workshop04/28/2019 at 15:06 0 comments

    As the title said. Here we are trying to write up a simple oscillator for the V20. It looks like the V20 allows a square wave with 50% duty cycle, as long as you exceed these minimum values:

    (NEC V20 Datasheet)

    Here is a simple Verilog code for the oscillator:

    module oscillatorV20(input clk, output reg clkV20);
    reg [31:0] counter = 0;
    always @(posedge clk) begin
    	if (counter == 8'd5) begin
    		counter <= 0;
    		clkV20 <= !clkV20;
    	else begin
    		counter <= counter + 1;

     And using SignalTap 2, we see this as an output (this is an example 1 MHz square wave, and I'll tune to the 2 MHz after this):

    The problem with the little time bar was, I have to manually key in the "Time Units" (right click on the time bar, and click "Time Units"). Enter 100ns inside:

    As this is working, my next step will be wiring the thing up to the FPGA board (ASK2CB) and check whether the ALE pin are pulsing or not.

View all 8 project logs

Enjoy this project?



NYH-workshop wrote 05/20/2019 at 15:15 point

Yes, on-chip resources for latch are available on any FPGA - however, trying to write it in Verilog is an extremely tricky task. I couldn't have this FPGA grabbing that lower address from AD0-7 at the first cycle despite following the "inout" examples online. I might have left out something, or I might need to look harder! 

So to have all the basic stuff working, I will have to add that 373 on top of it, and fully isolate all the address and the data so that the FPGA can work on its decoding and mapping (which is my main intention) to different peripherals and the memory.

  Are you sure? yes | no

K.C. Lee wrote 05/20/2019 at 17:28 point

You could use a D F/F to replace the transparent latch.  D F/F is essentially free at the I/O pin.  The clock needs to be inverted (i.e. /ALE) and you'll lose a bit of timing because of the differences but FPGA is fast enough to make up for that.

Transparent latch can't be that difficult to write though.  It is essentially a MUX with data input on one and output feedback on other with select from LE.

FPGA people prefer to use D F/F.

  Are you sure? yes | no

Ken Yap wrote 05/12/2019 at 14:55 point

👍 because I have six V20 chips which should be good, providing I didn't damage them when I pulled them out of PCs years ago. Plus quite a few 8088 and 8086 chips. I came to the conclusion some time ago that a CPLD or FPGA would be the way to interface to them and still retain my sanity.

But even after you have shown the way, what can I do with them afterwards? Making any real use of them would cost more than using a modern MCU.

Anyway I'll enjoy the journey vicariously through your project for now.

  Are you sure? yes | no

NYH-workshop wrote 05/16/2019 at 14:56 point

Hello Ken Yap,

Thanks for the compliment! :) 

I must admit that working with these cost more than a modern MCU. As I had worked with 32-bit systems a lot nowadays, these can outrun any of those x86s without much effort! However, since I kept a lot of old stuff at home, I plan to use whatever available and try to get it working. 

One of the motivations of building this was to write my own BIOS. Yes - many would think it's much more easier getting an emulator and just run the binaries on it. But here's also another motivation - I want to see what happened when something that old (Intel 8088/V20) mixes with something that is new (Intel Cyclone 2). It could be an amusing journey as I will mess it up one by one, and eventually, I'll get it to run a simple program. This whole project is just for me to learn more about Verilog and the x86 and I'm gonna document it here.

As a start, directly connecting the 8088 to the FPGA didn't work that well. It could be something I have missed out inside the Verilog code, or I really need that transceiver for that ALE to strobe. :)

  Are you sure? yes | no

Ken Yap wrote 05/16/2019 at 15:15 point

I saw that log. I think like other Intel CPUs and MCUs with muxed buses, the strobe lines are important for the recipient to know when the bits on the bus are the right ones (address/data). Surely a Cyclone 2 would have on-chip resources for a latch?

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates