[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emulating a Z80, and, So that's why CP/M 3.1 is so slow...
Dosius wrote:
> Well, interestingly enough, while running CP/M-80 3.1 on EMU][, there
> was visibly a lot of alternating between the 6502 and the Z80, and, as
> with Apple Oasis, it ran like molasses.
>
> That would explain it...the frequent CPU switching probably slowed the
> system down to a crawl. No wonder it dragged.
CP/M 3.0 used some very slow 8080 code for screen output (lots of loops,
no advantage taken of Z80) in the original DRI-supplied BIOS core, as I
found out when hacking around in the C128 version and trying to make a
faster version.
Basically for every character being output it runs a great big loop with
lots of bit-shifting checking all the 16 theoretically possible output
devices and looking if they should get the character, then it does a bit
of bank switching, then the terminal emulation kicks in and it checks
for all(!) of its control codes, and finally then the character is
delivered to the screen output routine which still has to decide where
to POKE it into the only indirectly and slowly accessibly screen RAM,
whether to scroll, etc. On the C128 this whole mess is being run on a
Z80 which runs at ca. 88% of 2Mhz. and also has to serve 300 Interrupts
per second. Of course the application itself also has to do a bit of
houskeeping for every character. After cutting a bunch of shortcuts
through, for example only running the loops if the output device
assignment is non-standard, the code the frustration factor went way down.
At least those useless loops might also be there in the Apple CP/M 3 code.
--
Linards Ticmanis
The Master said, "The business of laying on the colors follows the
preparation of the plain ground."