Sunday 2 April 2017

Emulating an 8080 on the MEGA65

I must say I was very impressed to discover what LGB has been up to lately:

As the URL suggests, he has been working towards CP/M emulation on the MEGA65.

What is remarkable is that he is currently obtaining the performance of an approximately 12MHz 8080 CPU on the MEGA65, i.e., about 3x faster than many of the real CP/M computers -- but this is emulation using the 45GS10 CPU of the MEGA65 to achieve this.  Put another way: The 45GS10 can emulate an 8080 at fully 1/3 of the clock speed of the 45GS10.  

Both he and I were at first rather surprised that it could emulate at such speed.  However, on inspection, it turns out that the 45GS10 is quite friendly for emulating foreign hardware.  Specifically, the combination of a large address space, together with the ZP-indirect 32-bit addressing mode and the JMP ($nnnn,X) jump-table instruction means that an emulator can operate in its own address space, separate from the emulated system, and use ZP registers as emulated registers, with the ZP-indirect 32-bit mode allowing dereferencing of those emulated registers.


  1. Great to hear! I suppose, however, that Commodore 128 CP/M binaries are compiled for the Z80?

    By the way, it's been quite a while since the last project update. How is everything coming along, hardware-, software- and IP-wise?

    1. Hello,

      I have no idea about the C128 CP/M binaries.

      Regarding updates, there is quite a bit of activity going on behind the scenes, but we are all totally flat out, so haven't had much time to say very much. There are some good updates to the VHDL thanks primarily to Falk, for example, being able to write to D81 disk images. Hardware designs continue to move along, but not as fast as we might prefer.


    2. It depends what you call "compiled for". Basically Z80 is an "extended 8080". That is, a 8080 program can be executed by Z80 too. So the question here if they use only 8080 opcodes and not "Z80 extensions". But anyway, now I am on my way to implement Z80-only opcodes as well. :-)

    3. The C128 CP/M relies on the built-in Kernal ROM routines of the machine, so it switches over continually between the two CPU's to and fro (the 8502 and the Z80A) in the background. Since it is specifically designed for the C128, there is no reason why it would not have already been optimized for Z80.

    4. @Robert actually it's the CP/M BIOS which is coded in 65xx ASM. That is the CP/M BDOS is the same, and the custom BIOS is written for C128 in a way, that it switches back from Z80 to 8502 (I know since I've already studied C128 CBIOS in source code form already). However it's nothing to do with the CP/M apps themselves! The very essential thing about the CP/M that it's portable and only BIOS is needed to be implemented for a given platform. So while it's true that the *same* CP/M _system_ (ie original CBIOS written by CBM to support Digital Research's CP/M BDOS "kernel") written for C128 requires that environment, it's not true for the CP/M applications, they should be OK to be run on any CP/M system, that's the point of the architecture of CP/M, to be platform independent.

    5. After all it means that if anyone made a re-written or re-compiled porting of the Bios for the MEGA65, then it could be rather fast, as the 8080 (or Z80) emulation is only/mainly needed for the application code. There is also some room on the C128 yet to make it faster, as the slowliness does not only come from the Z80A itself being underclocked, but also from the screen handling routines underoptimized. I have read once before that someone had already made some patches for the VDC in this manner (I have not tried it yet), or similarly, if you install JiffyDOS, the changing of the Kernal also affects the disk handling speed e.g. on a 1541 (and makes it run much better) with the CP/M, too.

    6. I guess so. First, about BIOS: indeed, in case of C128 (and C64 with "CP/M cartridge" which is basically a Z80) the BIOS transfers the control back to machines's "main" CPU. There is huge place of optimization if you can write those routines, honestly I don't know about screen handling now. Another thing is BDOS itself, ie the "CP/M kernel" if you want to call that way. C128/C64 CP/M uses the original CP/M BDOS for this. However my approach was to move my own BDOS, so it can be native code too. Surely to do it well, it's *huge* work. But also another side of the story: if you implement FCB file functions by yourself, you can use any file system you want, don't need to stick's with CP/M's own implemented in BDOS. And you can gain speed too, and surly compatibility with non-CP/M file systems. The disadvantage: low level stuffs won't so much work, doing deep CP/M magic with file I/O or even block level I/O. But I *assume* at least, that most "regular" user apps (not system tools ...) won't exploit things like that too much. And well, for example M65, you don't want use CP?M system tools, as it's only an "emulation" anyway and you want to work with your FAT32 formatted SD-card with other tools to maintain, you want "only" to use with CP/M. In this way, for 8080 (or maybe Z80 ...) code is only for the application but not for the "CP/M system" itself (BIOS and BDOS). But it's also possible that I have too big mouth, and it will turn out, it's too big work for me to write a CP/M BDOS which is at least works with considerable number of CP/M apps well enough ...

  2. Hi, thanks for mentioning my work. I would like to add, that the exact timing of 8080 - of course - it's not emulated at all (the emulation runs as fast as it can be always, no control over it). The initial and very rudimentary "benchmark" only measures the average speed of op-codes MBASIC-80 used to interpret that little BASIC program, so it can varies a lot depending on the actual 8080 code. However, I guess, with M65 speed we may won't hit the situation that it goes extra slow compared to a typical "real" CP/M system, which is good! For CP/M software, I doubt it's a problem that it contains timing critical part when exact 8080 timing is required, in contrast of an emulation need of a whole computer hardware where software (especially games and demos) may exploit tricks like that or even more.