Close
0%
0%

V20-MBC: a V20 (8088 + 8080) CPU homebrew computer

An easy to build homemade single board computer with a V20HL aka uPD70108H (8088 + 8080) or 80C88 CPU. CP/M-80, CP/M-86 and MSDOS supported.

Similar projects worth following
The V20-MBC is an easy to build V20HL (full static CMOS version) or 80C88 CPU SBC (Single Board Computer). It follows the same "concept" of the Z80-MBC2 (https://hackaday.io/project/159973), with an SD as "disk emulator" and up to 1024KB RAM.

It has an optional on board 16x GPIO expander, and uses common cheap add-on modules for the SD and the RTC options.

It has an "Arduino heart" using an Atmega32A as EEPROM and "universal" I/O emulator (so a "legacy" EPROM programmer is not needed) programmed with Arduino IDE.

It is compatible with the uTerm (https://hackaday.io/project/165325) and uCom (https://hackaday.io/project/165709) boards.

* * PREFACE * *

Luckily I have enough electronic stuff "to survive" these days, so I decided to start the design of a new "retro" board, this time using a V20HL CPU. Of course my way...


* * THE PROTOTYPE * *

In the first phase of the design I've used a prototype on a breadboard to check the basic "concepts".

To make things easier I've used as "companion" MCU a STM32F030R8 on a custom board (ARMando) I previously made and that it is directly pluggable on breadboards, and with onboard microSD card and USB-serial adapter.:

To make the firmware for the STM32F030R8 I've used Arduino IDE with the core made by ST. In this way the "porting" to the Atmega32 used in the final board would have been simpler.
Here some screenshots of some tests using the 8080 mode to run the Altair Basic and the IMSAI Basic:





* * HARDWARE OVERVIEW * *

Here the V20-MBC hardware main specs:

- V20HL full static CMOS CPU (uPD70108H)

- can be used an 80C88 (CMOS version) too;

- RAM can be configured as 128/512/1024KB;

- optional RTC and microSD modules (the same used in the Z80-MBC2);

- optional 16x GPIO port;

- I2C expansion port;

- serial port;

- User led and key:

- ISP connector (for the Atmega32);

- clock can be configured at 4/8MHz (by software).

The CPU is used in "minimum mode" to limit the BOM.

The layout allows to "plug in" a uTerm or a uCom board as in the Z80-MBC2 (vertically or horizontally) using the same 3D printed brackets (the following screenshot could change due to IOS updates).

The following images show a V20-MBC attached to a uTerm board to form an "autonomous" unit with a PS/2 keyboard and a VGA monitor (mounted vertically and horizontally):




Because it is a "two flavors" board (8088/8080), I've used a two flavors ice cream as logo... ☺

(the following screenshot could change due to IOS updates)


Please remember that a CMOS full static CPU is required here, so the only V20 CPU that can be used is the V20HL (uPD7108H, see the "H" at the end of the part code that makes the difference...).

Only this CMOS full static version allows to use a clock rate from DC and, under some conditions, guaranties that the logic levels are compatible with the Atmega32A ones (the Atmega logic input levels are not TTL compliant)

Another aspect of the V20-MBC is that the well known 8284 clock oscillator chip (normally used to generate the 8088/8086 clock with the required 33% duty cycle) is not used here. Reading  the V20HL datasheet you can see that the -12 and -16 speed grades have a symmetrical clock requirement, and the -10 speed grade clock requirement can be met using a little lower clock with a 50% duty cycle (not greater than about 9MHz, so using a maximum 8MHz clock there is a good margin).

In the Files section you can find the V20HL Datasheet.


RAM CONFIGURATION

The V20-MBC allows three different RAM configurations:

  • 128KB (1x128KB)
  • 512KB (1x512KB)
  • 1024KB (2x512KB)

To set the proper RAM configuration two jumpers (JP1/A19 and JP2/A17) must be set. This operation must be done when the board is not powered, and before the first power on with the RAM chips installed.

Please note that using a 128KB SRAM only the single SRAM chip configuration is supported (the 2x128KB is not supported).

The following table shows how to set jumpers JP1 and JP2 for the three RAM configurations:


CONSIDERATIONS USING AN 80C88 CPU

The V20-MBC can use an 80C88 CMOS CPU too.

Of course when using an 80C88 CPU you loose the 8080 mode specific of the V20HL CPU.

Please consider that when using an 80C88 a speed grade -2 is required (80C88-2) to meet the 80C88 specifications. If we see at the datasheet the clock requirements are:

So a 8MHz clock with a 50% duty cycle will no meet both the 80C88 and 80C88-2 specifications, but a 4MHz clock with a 50% duty cycle will meet the 80C88-2 specs.

So you have to use an 80C88-2 CMOS CPU setting the clock at 4MHz...

Read more »

S260320-R241023_IOS_V20-MBC.zip

The sketch for the IOS (with the needed libraries). Unzip into a folder and open the .ino file (with Arduino IDE). IOS must be uploaded into the Atmega32A flash. Added MSDOS support. See the Changelog in the .ino file. The Serial port default speed is 115200 bps (8N1).

Zip Archive - 42.94 kB - 11/04/2023 at 12:35

Download

S260320-R241023.ino.with_bootloader_atmega32_16000000L.hex

The sketch for the IOS in executable format (.HEX) with the bootloader. This executable file is intended for use with a programmer as the Atmel Ice or AVRISPmkII or others (Fuse bits: High Byte 0xD6, Low Byte 0xAF, Lock Byte 0xCF)

x-hex - 62.91 kB - 11/04/2023 at 12:36

Download

SD-S260320-R241023-v1.zip

The content of the microSD for IOS S260320-R241023. Added the SPP Adapter board support for CP/M 2.2 and CP/M-86. See ChangeLog.txt inside the SD image.

Zip Archive - 5.07 MB - 11/04/2023 at 12:35

Download

A250220 - SCH.pdf

Schematic.

Adobe Portable Document Format - 221.90 kB - 04/21/2020 at 11:27

Preview

A250220 - Gerber.zip

PCB gerber files.

Zip Archive - 481.69 kB - 04/21/2020 at 16:10

Download

View all 10 files

  • How use the ISP port with the USBasp programmer under linux to burn the bootloader

    Just4Fun04/28/2024 at 16:18 0 comments

    A cheap and easy way to burn the Arduino bootloader is to use an USBasp programmer that is commonly available:

    The USBasp is also capable to give the power to the "target" using the VCC pin, but remember to check that the JP1 jumper is set to provide 5V to the target (as shown in the photo).

    Please note that the pinout of the USBasp is a little different from the "standard" ISP pinout:

    In the previous picture it is possible see that pins 4 (TXD) and 6 (RXD) are not at GND as expected  by the standard ISP port, and pin 3 is not NC.

    See the following picture showing the standard 10 pin ISP pinout:

    So you must consider this when connecting the USBasp to the 6 pins ISP port (J2) on the V20-MBC (see the schematic):

    To avoid problems I suggest to use as GND pin 10 of the USBasp connector, and connect the other pins (VCC, MISO, MOSI,SCK, RST) accordingly. An handy way to connect the USBasp to the 6 pin ISP port (J2) of the V20-MBC could be to use a commonly available "10pin to 6pin" adapter like this:

    but I suggest not to use it "as is" because its internal connections are done for a "standard" ISP port, and we have seen that the USBasp connector differs from the standard one. The schematic of the adapter shows that isn't compatible "as is" with the UABasp connector:

    To use it is a good idea isolate the pins 4, 5 and 6 cutting the trace on the PCB of the adapter that connects those pins together, and then check with a tester. In the following photo are shown the three cuts (thin red lines inside the green "circle") to do:

    BURNING THE BOOTLOADER FROM ARDUINO IDE:

    To easily burn the bootloader follow these "quick and dirty" steps (tested on a linux Mint OS with Arduino IDE 1.8.5):

    STEP 1: Connect the 10 pins connector of the USBasp programmer to the 6 pins ISP port (J2) of the V20-MBC (using wires or a modified adapter as discussed before);

    STEP 2: Verify carefully that any other connector of the V20-MBC is not used, and verify that both the SD and RTC modules (if present) are removed from the board;.

    STEP 3: Only at this point connect the USB side of the USBasp programmer to an USB port of your workstation;

    STEP 4: Open a "terminal" window on your workstation and go to the directory where there are the Arduino IDE executables, and get the root privileges with the command:

    sudo su

    then run the Arduino IDE with the command:

    ./arduino

    STEP 5: Because Arduino IDE is running as the root user it is necessary re-install the "core" for the Atmega32. Open the Board Manager as you already did (anyway  the guide is here). Note that you must do this step only the first time you execute the Arduino IDE as root;

    STEP 6: Now from the Tools menu of Arduino IDE select "Atmega32" as "Board", "16 MHz external" as "Clock", and "USBasp" as "Programmer". Then you can burn the right bootloader (without playing with the FUSE setting) selecting "Burn Bootloader" from the same "Tools" menu.

    All done!

View project log

Enjoy this project?

Share

Discussions

villaromba wrote 05/21/2020 at 15:45 point

CP/M loaded up fine and running well. Without PCGET and or Xmodem I've got to revise my cpmtools GUI usage !!

On my 2nd board I am going to fit 2 x 40pin ZIFs, may need some re-positioning. I bought a little while ago 8x M80C88A so will try them out. The other ZIF for the ATMega for ease of programming it. Yes, I still use the TL866 !!!

  Are you sure? yes | no

Just4Fun wrote 05/21/2020 at 16:01 point

The XMODEM used in the Z80-MBC2 uses Z80 machine code as far I remember. If you know an 8080 working version let me know...

BTW I don't know PCGET. It can be used on 8080 CPU?

ABOUT CPMtoolGUI: You can use the format settings for CP/M 2.2 on the Z80-MBC2 (one for disk 0, the other for disks 1-15).

EDIT: It seems that I've learned a new thing today :-)

Just found this:

https://github.com/glitchwrks/pcget_pcput

  Are you sure? yes | no

Just4Fun wrote 05/21/2020 at 17:06 point

BTW: I was wrong... The XMODEM used (and adapted by me) for the Z80-MBC2 uses 8080 assembler mnemonics... :-)

  Are you sure? yes | no

villaromba wrote 05/21/2020 at 17:56 point

Thank you .... sounds good to me. I will do some 'experiments' over the weekend.

  Are you sure? yes | no

Just4Fun wrote 05/07/2020 at 17:21 point

Just joined the #TechAtHome contest!  ( https://twitter.com/Just4Fun_J4Fun/status/1258440867477704704?s=20 )

  Are you sure? yes | no

villaromba wrote 05/06/2020 at 16:45 point

Completed my build day today with the V20 and all seems to be working perfectly. Will let it run  a  basic prog overnight and do further tests with Forth  etc. tomorrow. BTW the Z8 also working great as well. Happy days!!! Thanks again for a further 2 boards. 

  Are you sure? yes | no

Just4Fun wrote 05/06/2020 at 17:01 point

Great!

Let me know...

  Are you sure? yes | no

villaromba wrote 05/07/2020 at 11:12 point

V20 still churning out data from the Basic8k78  this a.m. Checked out all the  .hex files in the 2 basics and forth. All working great. Running with 512k memory. My RTC should arrive tomorrow to complete the build. Probably won't add the expander IC as not necessary for me on this build. All MENU functions are good. 

I shall continue to 'watch this space' !!

  Are you sure? yes | no

Just4Fun wrote 05/09/2020 at 09:34 point

When testing the RTC remember to apply the patch...

  Are you sure? yes | no

Dave's Dev Lab wrote 04/22/2020 at 15:12 point

lovely build! i was looking at doing something with the V40!

  Are you sure? yes | no

Ken Yap wrote 04/22/2020 at 12:36 point

It's a pity I cannot use the V20 chips in my spares box as they are not static although I understand the reason for that in your design, and previous ones. Anyway nice work.

  Are you sure? yes | no

MS-BOSS wrote 05/01/2020 at 18:29 point

That's not entirely correct. You could design the board in such a way that when entering "idle" or "single-step" mode, the processor would execute until next instruction after requesting it to pause. Then, by decoding the memory access IO, you could detect it is going to load next instruction and supply it either with the WAIT instruction or the HLT instruction. Both are single-byte so it should be quite straight-forward.
WAIT instruction serves usually for communication with 8087, however it can probably be misused to pause the processor and then unpause it by its BUSY# signal. I am not sure, however, if that works in minimal mode (8087 was meant to be connected only in maximum mode). It seems this method may be broken by any interrupt that gets triggered when the processor is waiting.
HLT instruction should pause the processor until any event happens - debug session or interrupt. This may be broken by interrupt, again.
There may be another method which involves abusing the LOCK# signal to fool the processor into thinking it is runing in dual-processor computer which makes it wait until the second (fictitious) processor releases the bus. However, that probably won't work in minimal mode.
A last method which comes to mind is to use the RQ/GT pins to request/grant access to bus which should also pause the processor (I hope so).
As always, remember that even the lowly 8088 may start to behave funny since it has 6-byte FIFO for parsing instructions. This means that if you pause the processor, read the RAM, inject some code into RAM which would allow you to probe the context of the processor and then expect it to run properly - no way. It still has several instructions stuck inside which are going to be executed after you unpause the processor (it could jump out to some other part of code). A proper solution would be to stuff the processor (no matter what part of memory it tries to access) with some safe instructions (JMP $, HLT, WAIT, NOP, ...), then unpause it, let it crunch the safe instructions, pause again, then send your code to RAM and unpause again. OTOH, maybe an interrupt/jump/branch flushes the cache?

  Are you sure? yes | no

Ken Yap wrote 05/01/2020 at 22:30 point

Can it be done with the current board design?

  Are you sure? yes | no

Just4Fun wrote 05/02/2020 at 09:25 point

There is another constraint to be kept... Only the CMOS versions under "light" load conditions (see datasheet) have logic levels compatible with the Atmega ones (the Atmega are not strictly TTL compliant).
So no CMOS CPU no party (at least with the Atmega).

BTW: the STM32F030R8 I used for the breadboarded prototype has TTL levels, so it could work with non-CMOS CPU too, but the requirement here was to use THP only...

  Are you sure? yes | no

villaromba wrote 04/17/2020 at 19:24 point

My boards are being fabbed at JLCPCB - most parts waiting to go in !!

  Are you sure? yes | no

Peabody1929 wrote 04/12/2020 at 18:21 point

Can't wait to build one!

  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