• Please review our updated Terms and Rules here

NEC V20 and CP/M

Ruud

Veteran Member
Joined
Nov 30, 2009
Messages
1,369
Location
Heerlen, NL
Hallo,

I own several nice CP/M machines, a Bondwell-16 and Commodore 128 and 128D. They all use a Z80 to run CP/M 3.0. I completely forgot it and was recently reminded that the NEC V20, a clone of the Intel 8088, is capable of running 8080 instructions as well. Doing some searching I found some source code that should enable me to run 8080 programs on my PC20-III in time (I hope).

My questions:
- Originally CP/M was meant to run on machines equipped with the 8080. Z80 equipped machines were able to run it as well of course. The Z80 being a better CPU, I can imagine that therefore people started to write programs for the Z80. If I can run CP/M 2 on my PC, how big is the chance that 3rd party software is "polluted" by Z80 code?
- Was anyone able to run CP/M 2 on a PC with a V20?
- Was CP/M 3 supposed to be "8080 only" as well or was it targeted to the Z80?

Many thanks for any reply!
 
Most 3rd party apps for CP/M-80 were 8080 code. Some vendor utilities might have been written for the Z80, but those generally aren't useful anywhere but that specific machine.

Note that the core CP/M-80 code, as well as MP/M, CP/NET, etc. was all written for the 8080 (contains no Z80 code). That includes CP/M 3. This applies to code originating from Digital Research. Note however that the BIOS, and other vendor-specific code, might be written for the Z80. That only matters if you are looking at other vendor's code.
 
That includes CP/M 3.
Aha, thank you very much for this information! I don't have CP/M 2 but do own CP/M 3 for the machines I mentioned earlier. So IMHO the things that I have to do are:
- copy this CP/M 3 to a floppy (for the moment) or find something more ready on the internet
- write my own CP/M BIOS
IMHO I have to write a program that copies the needed BIOS thingies into memory, switches the V20 into 8080 mode and starts up the BIOS.

We'll see..... (to be continued)
 
Yeah, you got the general idea. I'm not sure how the V20 boots, but often there is a small bootstrap "sector" (or block) that gets loaded off disk. That bootstrap code then sets up hardware and loads the rest of the OS. The bootstrap code, IMHO, sounds like the right place to switch to 8080 mode - probably immediately prior to jumping to the loaded OS image.

There are some sites where you can find pristine CP/M binary images (BDOS et al., CCP, etc.), but some of those are older, or "un-patched" versions. Read the fine print. For CP/M 3, you'll need to the *BDOS3.SPR files, and your own BNKBIOS3.SPR file, in order to build the CPM3.SYS file. That plus CCP.COM will allow you to boot. But you need GENCPM.COM in order to build CPM3.SYS. There are a lot of moving pieces to be fit together.
 
From memory (and this is going back some), the V20 boots into the x86 mode. Using whatever OS you are in (typically MSDOS or CP/M-86) you then run a program that sets up an 8080 environment and then ESCapes to emulation mode to run your 8080 code. Take a look at http://www.eolith.co.uk/mirrors/cpm86/86emulat.zip It contains VCPM emulator (source included) that I wrote many many years ago to emulate a CPM/80 session running under CP/M-86.
 
Yup, x86, then the BRKEM instruction is issued to start 8080 emulation. The operand of the instruction specifies an interrupt number whose vector contains the segment:eek:ffset where emulation is to begin. Similarly, to end, a RETEM instruction is issued in 8080 code. One feature not often employed is the CALLN (call native) which issues an 8086-type interrupt call that enables x86 code (which returns using an IRET) to be mixed in with 8080 code.

The emulation by the V-series CPUs is pretty good with only a couple of end cases causing trouble. I recall that the early versions of JRT Pascal tickled one of those by modularizing its code such that a call to a function or subroutine first loaded SP with the address of the entry point, then calling said entry point. This got mangled by the V20's BIU such that the emulation would crash. I've got a MicroNote on this somewhere, but I remember discovering the problem and calling my contact at NEC Natick with the issue--someone had reported the same problem about two days earlier.

All in all, the V-series 8080 emulation is good, but the faster 80286 machines could outrun a V20 using software emulation--and offer Z80 emulation to boot. Hardware 8080 emulator sort of fell into the dustbin of history, but it's worth noting that the V40 and V50 chips also have 8080 emulation capability.
 
NEC V20 and NEC V30 boot and run in x86 mode, exactly as an Intel 8088/8086 would do.

The 8080 emulation mode is enabled later on, e.g. from an MS-DOS application. That application should also provide the I/O and other services for the 8080 emulation.

NEC V20/V30 provides several instructions to enable and facilitate the emulation:

  • From x86 mode:
    • BRKEM imm8 (0x0F 0xFF imm8) - Switches to 8080 mode. It behaves similarly to an INT imm8 instruction, that is it saves the return address, segment and PSW to the stack, when it loads the CS and IP from the imm8 index of the interrupt table. It also sets the MD flag (bit 15 of PSW) to 0, which enables the emulation.
    • RETI - Will switch to the 8080 emulation mode if the PSW it restores from the stack has MD flag set to 0.
    • Hardware interrupts INT/NMI and RESET will also switch V20/V30 to x86 mode.
  • From 8080 mode:
    • CALLN imm8 (0xED 0xED imm8) - Basically an INT imm8 version for 8080 emulation mode. It will switch the CPU to x86 mode and call the interrupt specified by imm8
    • RETEM (0xED 0xFD) - Very similar to x86's RETI, it restores CS, IP, and PSW from the stack, and since PSW stored in the stack has MD flag set to 1 (presumably previously saved by BRKEM), it will also switch to x86 mode.

In 8080 emulation mode most of x86 registers map to the corresponding 8080 registers:
  • AL to A
  • BX to HL
  • CX to BC
  • DX to DE
  • Lower 8-bit of PSW to FLAGS
  • x86's BP to 8080 SP - This allows having separate stacks for x86 and 8080 modes.

Note that 8080 emulation mode does not provide I/O virtualization. That is any 8080 I/O instructions will access the hardware directly. Since most of the IBM PC peripherals I/O ports are located out of 0x0 - 0xFF area (remember, 8080 has 8-bit I/O addresses), they will not be accessible from 8080 emulation mode. This probably not a big issue. CP/M applications rarely access I/O ports directly, and the I/O can be done through the 8080 BIOS, which can use CALLN to access the I/O functions through an x86 mode wrapper.

It must be a CP/M emulation application for V20/V30 somewhere... Otherwise it would be an interesting exercise to write one. Using both x86 and 8080 assembly to program an obscure feature. Sounds like tons of fun!
 
Ever hear of 22NICE? If you can find an earlier version, it has V-series support. But then it functions not to run CP/M per se, but to provide CP/M functionality by translating the CP/M function references to calls to native x86 code routines. The idea was to make x80 applications transparently executable like x86 DOS applications. So, for instance, CP/M ED and PIP have a few interesting features not duplicated in stock MSDOS.

I uploaded another CP/M V-series emulator here about a year or so ago. It operated much the same way.

The V-series 8080 emulation was an interesting dead end back in the day, but software emulation is so much more flexible. I recall that the V20 emulation heyday, if one can call it that, ran from about 1986-1990. After that, XT's were toast.
 
HI Guys, You can still register SYDEX 22NICE. I was a bit shocked.

22NICE actually bulds a wrapper executable around the CPM.COM file.

The wrapper provides the BIOS/BDOS functions as well as the terminal emulation type.

Then you execute the converted file which launches in x86 mode, then flips to x80 mode and runs the code. (Pretty Cool Actually)

JA
 
Thanks for all these info!
I'm starting to design an SBC board using a V20 (uPD70108HCZ, the "full static CMOS" version) for both CP/M 80 and CP/M 86, trying to use the same approach of my previous Z80 board, the Z80-MBC2, using a cheap Atmega MCU as EEPROM and universal I/O emulator.
I'm at the early beginning stage, so I've a lot to study...

32680355387_571e4d75a2_z.jpg
 
First for all sho replied: thank you very much!

Ever hear of 22NICE? If you can find an earlier version, it has V-series support.
Interesting. Looking for 22NICE on the internet to see if there is more to find, I ran into an old thread that mentions an expansion card that offers 8080/Z80 support. I did some Google of course but nothing found. Another challenge would be to build one my self.
 
First for all sho replied: thank you very much!


Interesting. Looking for 22NICE on the internet to see if there is more to find, I ran into an old thread that mentions an expansion card that offers 8080/Z80 support. I did some Google of course but nothing found. Another challenge would be to build one my self.

Do a search for Xedex Baby Blue. You will find a number of articles explaining how it works and also why it failed. $600 for the card and $100 per disk to be converted from the CP/M original format to the Baby Blue on IBM PC format made it easy to justify buying new IBM PC versions of software instead. A major auction site lists one as being available from Hungary at a price of almost $200 plus all the RAM looks to have been stripped from it.

I thought I once saw a DIY Z80 ISA card but I can't find a link right now.
 
If I dig into my old product index from PC Tech Journal, there were several such cards. I can make a list if anyone's interested.

Got a call from a fellow a couple of months back who's still running some CP/M application on his Win10 x64 system using 22Nice (he installed VDos). I'll confess to using it occasionally on my Ubuntu AMD64 machine.
 
Just4Fun;568336 [URL="https://hackaday.io/project/159973-z80-mbc2-4ics-homemade-z80-computer" said:
Z80-MBC2[/URL]
Wow, why haven't I noticed before? Looks great!
 
RETI - Will switch to the 8080 emulation mode if the PSW it restores from the stack has MD flag set to 0.

RETEM (0xED 0xFD) - Very similar to x86's RETI, it restores CS, IP, and PSW from the stack, and since PSW stored in the stack has MD flag set to 1 (presumably previously saved by BRKEM), it will also switch to x86 mode.

So if I understand correctly this code should be able to switch in to and out of 8080 emulation mode without hooking any interrupts? I've never understood why the people at NEC didn't just use a single instruction to toggle the MD bit to switch in and out of emulation mode.
Code:
	pushf
	push	cs
	push	ReturnToX86
	pushf
	push	cs
	push	Go8080
	push	bp
	mov	bp, sp
	or	BYTE [bp+13], 1 << 7	; Set MD bit
	and	BYTE [bp+7], ~(1 << 7)	; Clear MD bit
	pop	bp
	iret				; Enter 8080 emulation mode
Go8080:
	; 8080 code goes here
	retem
ReturnToX86:
A lot of overhead but at least no interrupts wasted.

On a sidenote, I made macros to implement all the NEC V-specific instructions with the hope to use them to save ROM space in XUB but I have yet to find any real use for them. See this.
 
I think part of the reason was needing to flush the instruction queue. I recall a MicroNote that called out certain issues with the 8087 being falsely triggered by certain instruction sequences before a native-to-8080 mode switch. In any case, it doesn't really matter--8080 instructions are duplicated functionally by x86 native ones. For executing stretches of x86 code, you have the CALLN instruction.

Some of the v20 instructions are useful, such as the bit-field operations and, if you're of the right need, the BCD string ones. The problem is that the 8086 gives you no way to trap them if it encounters them, so you'd have to duplicate whole routines in 8086 code to emulate the V20 instructions, if you used them.

Chalk it up as a curiosity. I recall that NEC had early versions of the 8080 that didn't work quite the same way that the Intel parts did.
 
So if I understand correctly this code should be able to switch in to and out of 8080 emulation mode without hooking any interrupts? I've never understood why the people at NEC didn't just use a single instruction to toggle the MD bit to switch in and out of emulation mode.
Code:
	pushf
	push	cs
	push	ReturnToX86
	pushf
	push	cs
	push	Go8080
	push	bp
	mov	bp, sp
	or	BYTE [bp+13], 1 << 7	; Set MD bit
	and	BYTE [bp+7], ~(1 << 7)	; Clear MD bit
	pop	bp
	iret				; Enter 8080 emulation mode
Go8080:
	; 8080 code goes here
	retem
ReturnToX86:

I am wondering if there is more stuff going on behind the scenes other than MD flag change. This note particularly looks interesting (page 8-5 here):

EMULATION NESTING
In a native mode called by CALLN or an NMI or INT interrupt from emulation mode, emulation mode cannot be called again by a BRKEM instruction. If this nesting is attempted, MD won't work normally, and normal operation cannot be expected.


This is kind of weird... you'd think that one can use 8080 emulation similar to vm86 in 386, and have several 8080 virtual machines running in parallel.
 
From my understanding, it's a matter of register saving--in particular, the MD register, which isn't part of the 8080 PSW.

Personally, if I were building something from scratch, I'd use the V40 or V50 and save myself some work. The integrated peripherals are pretty much compatible with the standard PC set (well, almost--you get a 8251A-type UART, instead of the 8250).
 
Back
Top