• Please review our updated Terms and Rules here

NEC V20 and CP/M

This is an really interesting thread, I must admit. I always have been fascinated by that 8080 emulation mode of the V-Series chips.
However, there's one important thing to keep in mind - While the original CP/M-80 was strictly using 8080 instructions only,
that's not exactly true for the application software. Due to other interesting features, such as a single supply voltage (+5v) and an integrated RAM refresher,
the i8080 did fell out of favour quite quickly due to the Z80. The Zilog 80 was much more advanced, had got hardwired functions and an extended instructions set.
So please don't expect too much of the later software releases to run on the archaic 8080. If there's any other chip that comes even the close to the Z80,
then it would be the i8085. It's the embedded form of the 8080, with single supply voltage support (hence the 85) and a few other enhancements.
In one way or another, the 8080 is like the 808x of the x86 world, with Z80 beeing the 80286 and the 8085 beeing the 8018x.. ;)
 
Embedded? The 8085 was used as the main CPU in several early microcomputer systems.

But there was, right up until 1982 or so, plenty of 8080 software. There was still enough market share with the 8080/85 to make it profitable--at least in commercial software. I don't know about the hobbyist stuff and games--a look through the CP/MUG and other interest group archives will show that.

The added-yet-undocumented instructions of the 8085 has been discussed here several times over the years.

Yet almost nobody pays attention to the NSC800--basically a Z80 with an 8085 bus. I wonder why.
 
Thanks a lot for the tip with the NSC800, I didn't know this before! :)
By "embedded", I meant that the i8085 was quite popular for single-board computers (SBCs), on controllers on ISA/S-100 cards
and among engineers (microcontroller test boards). At least here in my place. Speaking of the CP/M software, I don't mean to disagree.
It's just that the Z80 was very popular both in literature and physical form. Various CP/M programming books and PC magazines targeted
for computer enthusiasts included ASM samples that did include some Z80 specific instructions here and there and therefore didn't run on plain 8080 machines anymore.
In most cases, that wasn't even on purpose, I think. The authors simply assumed a Z80 silently, without even spending a thought on the i8080.
Commercial software, of course, was originally tested on a wider selection of computers than Public Domain software tested within a circle of friends.
In case of emulation though, this might be no real problem, I suppose, since the few extra instructions (Z80/i8085) that the NEC V misses could be emulated.
 
The problem with trying to emulate unimplemented instructions in the the V series native mode is that there's no trap for illegal/unrecognized instructions. So not an option in emulation. At any rate, after the 80286, the V-series emulation could be performed faster in software.

22nice used to have (and may still--I can't recall) a "test" mode in software emulation where 8080 ISA is assumed until a Z80 instruction is attempted. The user is then notified that the subject program is not 8080-compliant.

One advantage of the 8085 was the wide range of 8080 peripheral support available. You could cobble up interface using those chips with the Z80, but the 8259 interrupt support wasn't available, nor was the 8257-type DMA. Z80 when it started, had CTC, PIO and SIO and that was pretty much it. You could build a complete 8085 system with CRT and floppy support using nothing but Intel peripheral chips. At the same time, the same 8085 could work as a 2-chip embedded controller.

The lack of embedded features was a real puzzler with Zilog--true, they had the Z8, but it's a different architecture. Motorola had the very successful 68xx controllers; MOS had a similar thing for the 650x, and Intel had not only the 8085, but the 8048 and 8051 chips. If you want to state that a particular vendor's CPU family was almost exclusively embedded, that would have to be the 6800 derivatives, which remained popular for many years.
 
Krille said:
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.
Click to expand...

I take that back. Yesterday I actually found a use for the ROL4 instruction. See this.
 
sergey said:
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.
Click to expand...

You need to use BRKEM to enter emulation mode, because the mode flag is normally "locked". Some 8086 software (including BIOS code) modifies this bit, which would cause an unintended mode switch if it were always writable. I found this out years ago when writing a simple CP/M emulator on a Tidalwave palmtop, it would hang on reboot if the emulation mode was still unlocked.

RETEM sets the mode flag to read-only again, which is why you can't nest 8080 -> 8086 -> 8080.
The reason why these instructions use interrupt vectors is likely because it made the microcode simpler.

As Chuck mentioned, there is no invalid opcode trap (even in native mode, despite being otherwise compatible with the 80186 instruction set!), and a lot of CP/M software uses Z80 opcodes.
 
Krille said:
That's too bad. It would have been nice to be able to enter emulation mode without using an interrupt.
Click to expand...

Really, I can't see what purpose would be served by this. The interrupt scheme is pretty clean--you're really changing context; the interrupt scheme saves the x86 flags and flushes the instruction queue (there was an issue with this when an 8087 was installed. In a way, it's remarkable that it works as well as it does.
 
Chuck(G) said:
The problem with trying to emulate unimplemented instructions in the the V series native mode is that there's no trap for illegal/unrecognized instructions. So not an option in emulation. At any rate, after the 80286, the V-series emulation could be performed faster in software.

22nice used to have (and may still--I can't recall) a "test" mode in software emulation where 8080 ISA is assumed until a Z80 instruction is attempted. The user is then notified that the subject program is not 8080-compliant.

One advantage of the 8085 was the wide range of 8080 peripheral support available. You could cobble up interface using those chips with the Z80, but the 8259 interrupt support wasn't available, nor was the 8257-type DMA. Z80 when it started, had CTC, PIO and SIO and that was pretty much it. You could build a complete 8085 system with CRT and floppy support using nothing but Intel peripheral chips. At the same time, the same 8085 could work as a 2-chip embedded controller.
Click to expand...

Ah, I see. Thank your very much for the explanation! :)
While I "grew up" with the Z80 (one of my first PCs was a Sharp MZ-700), I also valuable its relatives. Both have the same parents, after all.
Also, I didn't know that the NECs had no exception handling (if I may call it that way) for that special case.
I assumed they were similar advanced as the 80286 in that respect, since they share some of the newer 80286 real-mode instructions (as found on 80186, too).

Speaking of CP/M emulators, my father used to run Z80MU, an Public Domain CP/M emulator from ~85 or so.
Back in these days, he used it to continue development of some stuff (simulation of fluids ?) that he wrote for university.
If I did understand correctly, he was "moving" from a Sharp MZ-80K with 8" floppies to a modern Amstrad PC-1512, which he later equipped with a NEC V30.
But since he used to perform a lot of Turbo Pascal programming (among M-BASIC and Forth/Fortran) the NEC's 8080 mode wouldn't have helped that much, I guess.
On the other hand, though, there's nothing prevending in using two CP/M emulators for each use case.


Chuck(G) said:
The lack of embedded features was a real puzzler with Zilog--true, they had the Z8, but it's a different architecture. Motorola had the very successful 68xx controllers; MOS had a similar thing for the 650x, and Intel had not only the 8085, but the 8048 and 8051 chips. If you want to state that a particular vendor's CPU family was almost exclusively embedded, that would have to be the 6800 derivatives, which remained popular for many years.
Click to expand...
Now that you speaking of the Z8 and the MCS line, there used to be special versions with built-in programming language.
Intel offered the 8052AH-BASIC with a built-in powerful BASIC interpreter for embedded use,
while Zilog had got a Z8 model (Z8671 ?) with some sort of Tiny BASIC and another one with Forth (by Micromint ?).
Unusual for Intel, the company decided to even release the source code for the MCS-52 BASIC later on.
Version 1.3, I believe, enhanced by some individuals, also runs on 8031/32/51 compatible controllers.
Astonishingly, these interpreters could be remote controlled by a simple glass terminal.

Some of the competing 8-Bit CPUs are mentioned in Ciarcia's Circuit Cellar, Volume 6.
Google books has a few pages for display that also cover the NSC800 and the lesser known HD64180.
The latter had a built-in MMU, a 512KB address space and a Z80 superset.

I wonder how CP/M 3.0 or MP/M with their advanced memory support had performed on
such a beast (why are CP/M emulators so focused on CP/M 2.2, btw. ?).
 
Last edited:
Why? Because there's comparatively little software that requires CP/M Plus or MP/M. You pick the low-hanging fruit first.

The 64180 (I have one in the 64 pin DIP 0.050" pin spacing package, which was a problem; the PLCC Z180 version was easier to work with) simply came along too late, as did the NSC800; much of the world had moved on to the 16-bit world. Also, note the Rabbit Semiconductor offerings of the 90s.
 
Chuck(G) said:
Why? Because there's comparatively little software that requires CP/M Plus or MP/M. You pick the low-hanging fruit first.
Click to expand...

Hm. So there was no interest in actually making use of the huge amount of features and fallow memory available on the IBM PC (32-64KiB vs. 256-704KiB) ?
That's a bummer. :shocked: I assumed the writers of emulators were usually very ambitious in their doing.
(Where people at least running multiple instaces of Nice22 and friends ? By using PC-MOS or DESQView, maybe ?)

From what I read online, some interesting MP/M software was out there (file/printer servers etc.) that could have enriched ordinary CP/M 2.2 clients/terminals.
CP/M Plus, on the other hand, was available on popular platforms, such as C128 or Schneider Joyce (PCW), so there must have been some textmode software that made use of that. Maybe some sort of enhanced dBase III or Lotus 1-2-3 or Wordstar, were lots of data had to be processed.

That's why I wonder why geeks/professional users apparently had no interest in a "full version" of CP/M.
I mean, in comparison to the classic CP/M-80 computers, the IBM PC, Acorn Archimedes and Amiga were like
powerful workstations that cost like nothing (in comparison to the older native CP/M machines, IMSA 8080, Altair 8800 etc).

When I read the Wikipedia article, it made me wonder why the usual emulators apparently lack support for common hardware standards, like ANSI or VT100 terminals.
With all these resources at hand, why didn't the programmers support multiple terminal types, in order to provide large compatibility to other CP/M computers ?
There were hundreds of terminal programs in the forms of Public Domain programs (w/ sources) floating around that had them.
Or why did't these emulators simulate directories, in order to make elegant use of the huge storage capabilities the HDD-equipped 16-Bit PCs of their time ?

I mean, CP/M Plus was released in '83, about two years before most emulators were even written (there are later ones dated up to the late 90s).
To me, that's as if someone did write a stripped-down Windows 3.0 emulator in '96 when Windows 3.1 was out there for several years. ;)

Anyway, these are just my thoughts. I guess I have to slowly stop now, else the thread goes too off-topic, I'm afraid. ::nervous:
I really like to thank you for all the the information so far, though! I hope I didn't get you on the nerves too much. :)
 
Last edited:
At the time of the 5150's debut, a complete Morrow Micro-Decision package was cheaper than a bare-bones PC setup. You have to remember that there was nearly a nine-year gap between the 5150 and the IMSAI 8080. A lot of technology progress was made in that time. So you have to compare apples-to-apples in this case.

I know of at least one customer who's still running his CP/M application under 22Nice under VDos under Win10. So there's your multitasking.

Recall also, that CP/M was a general-purpose/generic operating system--and that was the beauty. You could run it on little more than a 20K 8080 system with a single disk drive and dumb terminal. When CP/M 1.4 came out, few people had 64KB of memory available. Graphics and networking were beyond the pale of imagination, strictly the province of larger machines. Even when the first 16K-64K 5150 came out, networking was sort of a fuzzy proposition. DOS had no support for graphics. Floppy-only systems were common.

As they say, 20-20 hindsight is easy.
 
Last edited:
A lot of Amstrad games did take advantage of the 128 kB RAM*. DR DRAW in its Amstrad incarnation required 128kB** and I suspect other Amstrad applications did as well. VisiCalc Advanced used 128 kB RAM on the Apple III and IBM PC but the CP/M versions did not get the same upgrade. UCSD Pascal was designed to take advantage of the 128 kB of the PDP-11 as did the IBM PC versions but I believe none of the 6502 or Z80 versions took advantage of extra banks of RAM.

There was the craziness of SymbOS which need lots of extra memory and was designed to run with up to a megabyte but that didn't arrive until after 2000 so not representative of Z-80 design trends.

* http://www.cpcwiki.eu/forum/games/games-using-128k-ram/

** GSX plus CP/M Plus is memory hungry
 
Thank you everyone! I do now understand why CP/M 1.x and 2.2 were such a great break-trough on early micros from the 1970s. :)
Tiny requirements and flexibility (CP/M was among the first portable and hardware-independable OS) and support for floppy disks.
Meanwhile, the real, physical releases of the CP/M OS stopped being updated on most niche-PCs, so people settled for CP/M 2.2 finally.

Though there's still one thing that I'm curious - why didn't later emulators releases catch up and continued to improve (in general) ?
Adding CP/M Plus calls and other useful features neither harmed any compatbility, nor did it cost a cent, since these emulators were "synthetic".
Ie. not using any physical parts or code from Digital Research. They merely implemented conventions and software APIs (or ABIs) that were compatible to CP/M-80.

That's what puzzles me. In 1983, writing a barebone CP/M 2.2 emulator surely made sense, but by 1985 to 1989 things could have become more sophisticated.
I mean to say, as time went on, legacy hardware was fading away, simultanously, Personal Computers became more powerful.
Wouldn't it had made sense to allow CP/M applications to use these featues, maybe by adding a virtual CRT device and/or multiple TTY devices
or by mapping the 16 user channels to sepparate directories on the fixed disks ?
 
They did. Somewhat. http://www.z80.eu/myz80cpm.html handles of number of post-2.2 calls and implements a few terminals if the documentation is to be trusted.

I suspect it got a lot harder to emulate later versions since calls didn't have a matching MSDOS call to build around.
 
22Nice, I suppose, could add as many CP/M 3.0 calls as desired, since the resident part is just a stub with a few tables. The "meat" is all x86 code. But I've never been asked to do this in (2019-1987) = 32 years. For all I know, I may have implemented a few extra calls--I haven't looked at the code in 20+ years, when I added the "user-defined code" feature.
 
You must log in or register to reply here.
Back
Top