Subject: PDP-8 emulator performance

From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879)
Date: Wed, 1 Dec 1993 19:37:58 GMT

I've just done some benchmarking of my PDP-8 emulator, with some help
from Andrew Riebs at DEC ([email-masked]).   The set task
(a small FOCAL program) ran in 60 seconds on my IBM RT running AOS
(IBM's BSD) with output to an Xterm.

On my Tadpole SPARCbook I (a laptop SPARCstation), running Solaris,
with output to a remote Xterminal, the same output took about 22
seconds.

On a DECstation 3100 (ULTRIX MIPS), it took about 27 seconds, with
output to an Xterm window on the same system.

On a prototype Alpha AXP system with a CPU that is probably clocked
at 160 MHz, with display to a remote Xterm window, it took well under
5 seconds.

The benchmark we used was written in FOCAL; here's a transcript of the
session (it comes out the same on any machine you use):

% pdp8e focal
PDP-8 Emulator, type ? for help.
0000 (0000
0200g

CONGRATULATIONS!!
YOU HAVE SUCCESSFULLY LOADED 'FOCAL,1969' ON A PDP-8 COMPUTER.

SHALL I RETAIN LOG, EXP, ATN ?:NO

SHALL I RETAIN SINE, COSINE ?:NO

PROCEED.

*1.1 SET A=1      .........  the FOCAL prompt is a *
*1.2 TYPE A,!
*1.3 SET A=2*A
*1.4 GOTO 1.2
*GO               .........  here I typed in a program
=    1.0000
=    2.0000
=    4.0000
=    8.0000
      .....................  it ran for a while
= 0.11529220E+19
= 0.23058430E+19
= 0.46116900E+19
= 0.92233?01.00 @ 01.20  ..  here I typed control C
*

The benchmark is trivial (building the emulator, typing the benchmark
and running the test took less time than it's taking to type in this
report); the idea is to just time how long it takes to reach an output
of 0.46116900E+19, using whatever clock you have handy (I used my
wristwatch).  It's worth noting that the emulator was built with its
default settings in the distributed form (1200 baud, 4K of memory, no
KM8E memory manager).

An alternate benchmark is to use the fact that the Alpha got up to
0.18768820E+256 in 60 seconds.  On my SPARCbook, it took about 8 minutes
and 10 seconds to get to that point.  The output at the extreme end of
the run is clearly CPU bound (something about the way FOCAL handles
floating point output makes it take longer and longer as the exponent
grows).

In any case, it is clear that the Alpha emulation of a PDP-8/E using my
emulator is a few times faster than the original hardware!

				Doug Jones
				[email-masked]

---

From: [email-masked] (Berry Kercheval)
Date: 02 Dec 1993 17:45:12 GMT

>>>>> "Douglas" == Douglas W Jones,201H MLH,3193350740,3193382879 <jones@pyrite> writes:
In article <[email-masked]> jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes:

    Douglas> On a prototype Alpha AXP system with a CPU that is
    Douglas> probably clocked at 160 MHz, with display to a remote
    Douglas> Xterm window, it took well under 5 seconds.

On a SparcCenter 1000 running Solaris 2.3, I get to the E+19 range in
about 5.5 seconds.

--
Berry Kercheval :: [email-masked]

---

From: [email-masked] (krause)
Date: Mon, 6 Dec 1993 15:52:43 GMT

>session (it comes out the same on any machine you use):
....
>*GO               .........  here I typed in a program

Is that serious ?
On my original 8/e this focal program runs in aproximately 2 seconds.
(I have a hp 2648-terminal with 9600 baud).
With the 16K-4Word focal (ten digits accuracy) it took 4.5 seconds.

In this context another questions to the gurus:
If I would place our emulator in the public domain, which is planned to
run OS/8, whats about the copyright from DEC ?
Do I have to ask for a licence to use CCL.SV, DIRECT.SV, FOTP.SV and PAL8.SV?
I think on my personal -8 this is legal, because I bought hardware and soft-
ware from the original owner.
But what, if I copy the contents of my SYS: to an emulator?

Klemens Krause
National Centre for
Minimal- and Retrocomputing

Stuttgart
Germany

---

From: [email-masked]
Date: 6 Dec 93 13:34:14 MDT

> run OS/8, whats about the copyright from DEC ?

Since DEC has released OS/278 (the version of OS/8 for the DECmate) to DECUS,
you should be able to use at least those versions without trouble. Of course,
cjl will no doubt comment on the quality of the OS/278 code...
-- 
----------------+------------------------------------------------------
Roger Ivie      | Don't think of it as a 'new' computer, think of it as
[email-masked] |     'obsolete-ready'

---

From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879)
Date: Mon, 6 Dec 1993 22:22:26 GMT

>From article <[email-masked]>,
> (I have a hp 2648-terminal with 9600 baud).

The Benchmark is I/O bound, and most of the instructions it is timing
are the instructions in the polling loop!  You must use the same speed
I/O interface to make the benchmark into a fair comparison!

> With the 16K-4Word focal (ten digits accuracy) it took 4.5 seconds.

Can you possibly make this available over the net?  I'd love a copy, and
I do have 16K in my PDP-8/F.
> run OS/8, whats about the copyright from DEC ?

In the permission letter I have from DEC to photocopy and distribute
technical documentation, they didn't cite specific documents, instead,
they gave something of a blanket permission to duplicate and distribute
old documentation, so long as I gave proper credit to DEC.  The letter
was as ironclad in its definition of proper credit as it was loose in
specifying what I could copy.  I hope someone can get similar permission
with regard to OS/8, but since my disk is not yet up, I haven't done this.

				Doug Jones
				[email-masked]

---

From: [email-masked] (Charles Lasner)
Date: 8 Dec 1993 06:02:24 GMT

>cjl will no doubt comment on the quality of the OS/278 code...

Unlike Kibo (and his/her/its minions), I don't grep the newsgroup for my name
or initials, but I just returned from pressing matters, and noticed this one:

a)	OS/278 V2 will run on an 8/e or 8/a or DECmate.

b)	It is PD by virtue of its DECUS distribution.

c)	It has lame restrictions due to emasculation of the code primarily as
	a bandaid against perceived and occasionally actual restrictions of the
	Decmate hardware environment, part of which is simulated in ways that
	can be improved upon, and part of which is hopelessly incompatible with
	the standard PDP-8 environment all prior models have.  (Note: even the
	PDP-5 and PDP-8/s, while lacking in other ways that prevent virtually
	all software other than Focal from running on them, don't have the
	DECmates' problems!)

d)	The sources are incomplete and don't match the binaries.  So far as I
	have checked, the binaries are more trustworthy than the sources.
	However, there are numerous introduced bugs that just didn't exist in
	older OS/8 versions, and they seem to be related only to non-hardware
	issues.  For example, there are bugs in the SAVE command that are
	influenced by how ABSLDR was invoked, etc.  In all probability this
	is related to what some people call creeping featurism, etc., so the
	sources *and* binaries need to be checked against older versions, etc.

e)	In the process of merging in fixes derived from the original thoughts
	in the old code, as long as the newer sources are used as the basis for
	improvements, instead of the old sources, the DECUS distribution
	nullifies any claim DEC has/had on the system.  Thus, I would project
	that as OS/8 source files get modified to become input into the
	OS/8 V5 project (whereby old bugs and old model-dependancies are
	removed, etc. in preparation for changes to accomodate the *real*
	DECmate incompatibilities, etc.) the resultant sources are derivative
	of OS/278 V2, and as such are not DEC's concern as such, etc.  And
	since I intend to distribute OS/8 V5 through DECUS et al., no one
	should have a claim at that point, etc.

So, if you don't mind running a PDP-8/e according to the limitations of
DECmate-derived dementia, OS/278 V2 is the system for you (masochists!).

cjl

ps: the first "feature" that goes is the prompt goes back to "." (not "}" ugh!)

---

From: [email-masked] (Paul Repacholi)
Date: 9 Dec 93 23:22:50 +0900

> by [email-masked] (krause):
...
> with regard to OS/8, but since my disk is not yet up, I haven't done this.

About 1985 in the hardware doc catalogue, dec anounced that you where
free to copy ANY hardware docs that where not in the catalogue, or not
available.

remember when you could get decent catalogues of what was available...

~Paul

---

From: [email-masked] (David Allan Steffens)
Date: Fri, 10 Dec 1993 05:02:22 GMT

In article <[email-masked]>
jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes:
1> I've just done some benchmarking of my PDP-8 emulator...
1> ran in 60 seconds on my IBM RT running AOS...
1> On my Tadpole SPARCbook I..., the same output took about 22 seconds.
1> On a DECstation 3100 (ULTRIX MIPS), it took about 27 seconds...
1> On a prototype Alpha AXP..., it took well under 5 seconds.
1> ...
1> The benchmark we used was written in FOCAL...
1> *1.1 SET A=1
1> *1.2 TYPE A,!
1> *1.3 SET A=2*A
1> *1.4 GOTO 1.2
1> ...

In article <[email-masked]>
[email-masked] (Berry Kercheval) writes:
2> On a SparcCenter 1000 running Solaris 2.3,... about 5.5 seconds.

In article <[email-masked]>
[email-masked] (krause) writes:
3> ... On my original 8/e this focal program runs in aproximately 2 seconds.
3> (I have a hp 2648-terminal with 9600 baud). ...

In article <[email-masked]>
jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes:
4> The Benchmark is I/O bound, and most of the instructions it is timing
4> are the instructions in the polling loop!  You must use the same speed
4> I/O interface to make the benchmark into a fair comparison! ...

Well, you know what they say about lies, d*mn lies, ... and BENCHMARKS!
So let's look _carefully_ at this "benchmark" and determine _precisely_
what it is that we are measuring.

Doug's analysis that the program is IO-bound is _not_ correct in all of the
above cases.  The "benchmark" must print about 600 characters.  At 1200 baud
(about 120 cps) this requires a _minimum_ of about 5 seconds wallclock time.
Any processor that takes _more_ time than this to finish is _not_ IO-bound,
and any _excess_ time over 5 seconds is directly attributable to computation.
For the real PDP8/e with a 9600 baud terminal, the expected time to print
600 chars is about 0.6 second.  Thus about 1.4 seconds of the time to run
the "benchmark" is directly attributable to PDP8/e computational processing.

Now I want to ask _why_ you want to benchmark the IO when you already _know_
how long that should take?  Why not try a variation of your "benchmark", e.g.

01.10 set a=1; set n=0
01.20 set a=2*a; set n=n+1
01.30 if (a-5e37) 1.2
01.40 type n,a,!

This "benchmark" only prints one line at the end and will be compute-bound
on all processors.  The number "5e37" was chosen since my version of FOCAL
does not support the full exponent range of the original version.  You may
also need to change case and reformat slightly -- my version of FOCAL is
much more forgiving in this regard than the original version.

On a DEC uVAX II (Ultrix 1.1) and a Sun 4/260 (SunOS 4.1.3) I get:
DAS.epl> time ufoc -x focal.pgm
   126.0000  8.507059173e+37
0.150u 0.120s 0:00.72 37.5% 22+43k 1+1io 16pf+0w
DAS.epl> sun time ufoc -x focal.pgm
   126.0000  8.507059173e+37
0.030u 0.030s 0:00.06 100.0% 0+31k 0+0io 0pf+0w

Of course the correct answer is:
DAS.epl> bc
2^126
85070591730234615865843651857942052864

BTW, and in case you haven't already figured it out, _my_ sweepstakes
entry is a FOCAL interpreter that runs native on UNIX !

I wrote this code back in 1983 as sort of a hack learning exercise
under UNIX v7 on a PDP11/34 and later ported it to the DEC and Sun.
It has been used for real scientific computation and simulation work
in my lab and appears to be relatively "bug-free".  The "ufoc" program
is written in C and uses lex for token analysis and yacc for the parser.
The user's FOCAL program is converted into an internal P-code representation
for fast run-time interpretation.  "Ufoc" supports full interactive program
editing using a line-at-a-time editing style similar to the original FOCAL
and the resulting programs can be saved to UNIX files and later retreived.
"Ufoc" can also read/write UNIX standard IO and files, so a "ufoc" program
can be executed as a component of a UNIX pipeline.   A UNIX-style manpage
describing "ufoc" is available on request by return email.  A formatted
version is also available for those without access to nroff.  Please send
all requests and other correspondence to:
	[email-masked]

The "ufoc" code is somewhat primitive by today's coding standards, and it
needs some clean-up before I would feel comfortable releasing it.  However,
it should be relatively easy to port to Solaris 2.X.  And I think that GNU's
bison+flex could be substituted for yacc+lex without too much trouble.

If there is sufficient interest, I might be persuaded to undertake
the effort needed to get "ufoc" into shape for release.  I'd probably
want to copyleft the source, although I might want to reserve the right
to charge a small shareware fee, especially if there appears to be some
hot _commercial_ interest out there! :-)
-- 
David Allan Steffens       | I believe in learning from past mistakes...
Eaton-Peabody Laboratory   | but why does a good education require so many?
Mass. Eye & Ear Infirmary, 243 Charles Street, Boston, MA 02114
[email-masked]    Tel (617) 573-3748    Fax (617) 720-4408

---

From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879)
Date: Fri, 10 Dec 1993 16:22:19 GMT

>From article <[email-masked]>,
by [email-masked] (David Allan Steffens):

> how long that should take?

Because my emulator emulates I/O timing faithfully.  That is, if you "jumper"
the console port on the emulator to run at an emulated 1200 baud, then a
PDP-8 program with a timing loop to measure how long the terminal is busy
between outputs of, for example, null characters, will be unable to tell if
it is running on an emulated PDP-8/E or a real one.  My emulator faithfully
measures all instruction and memory access times, to the clock cycle, and it
emulates I/O latency with similar accuracy, but without any of the random
clock jitter that might be present in a real system.  Thus, the emulator
is not as fast as it could be (because of overhead of accurate timing), but
it will be difficult to write software which distinguishes between the
emulator and the real CPU.

---

From: [email-masked] (krause)
Date: Tue, 14 Dec 1993 08:05:31 GMT

>emulator and the real CPU.

This is another approach to an emulator. My intention was primarily a little
bit other:
I said to the guys who are writing the emulator:
1. Compatibility:
   All paper tape software (.BN-files) have to tun without patches, so the
   M6850 (KL8-8) instructions are to be emulated bit by bit, including inter-
   rupt behaviour.
   OS/8 must be bootable from an octal-dump of my SYS: (RK8E + RK05) with
   the instructions:
   0030 6743
   0031 5031

   I want then to compile a 180K-Fortran IV programm and run the KERMITs from
   CJL and JBQ.
2. Speed:
   Make it as fast as ever possible. The result is, that the programm is fully
   written in assembler.
   There is a table with 4096 entries and a pdp8 instruction is taken as offset
   to this table. An instruction fetch takes 3 machine instructions. These three
   instructions are part of every emulated pdp8 instruction. So a CLA IAC RTL
   consists of 4 machine instructions (all pdp8 registers are held in 80x86
   registers).
	
If required for compatibility reasons, it is naturally possible to slow down
the emulated M6850 to 1200 bauds. But what would Doug Jones' compatibility test
say on a machine like mine, where the M6850 is strapped to 9600 baud?

For measuring execution speed of single machine instructions I wrote
a little programm. It consists of two nested loops, with 2500 and 4000
repetitions, so that the inner loop is executed 10 000 000 times.
The instructions to be tested are between labels LOOP2 and RETURN.
If there is nothing between them, you get the time for the basic looping
overhead. I then filled in one or two instruction (i.e. removed one
comment / at a time and stopped the time now). The difference between
the empty loop and the one - or two instruction loop divided by ten
is the time in microseconds for each instruction.

For those who are not familiar with PAL8-assembler:
If you make an off-page memory reference, then PAL8 makes automatically
an indirect access and deposes a litteral with the off-page address at
the end of the current page. Also zero-page accesses are made automatically
without explicit indication by the programmer.

       *0017                             PAL8-VB0  10-DEC-93 PAGE 1

        0017          *0017
000017  0000  AUTOX,  0
        0160          *160
000160  0000  ZPAGE,  0
              /
              /
              /
        1000          *1000
              /       HLT
001000  7200          CLA
                      DECIMAL
001001  1377          TAD (-2500
001002  3220          DCA CNT1
              LOOP1,
001003  7200          CLA
001004  1376          TAD (-4000
001005  3221          DCA CNT2
                      OCTAL
              LOOP2,
001006  7000  /       NOP /EXACTLY ONE OF THESE INSTRUCTIONS	/
              /            IS NOT COMMENTED OUT (EXCEPT B0.BN) 	/
              /       TAD     CPAGE   /CURRENT PAGE		/
              /       TAD     ZPAGE   /ZERO PAGE		/
              /       TAD     OPAGE   /OTHER PAGE		/
              /       TAD I   AUTOX   /AUTOINDEX		/
              /       DCA     CPAGE   /CURRENT PAGE		/
              /       DCA     OPAGE   /OTHER PAGE		/
              /       CLA CMA IAC				/
              /       JMS     CSRT    /SUBROUTINE CURRENT PAGE	/
              /       JMS     OSRT    /SUBROUT. OTHER PAGE	/
              /       JMP     CDEST   /JMP CURRENT PAGE		/
              /       JMP     ODEST   /JMP OTHER PAGE		/
              RETURN,
001007  2221          ISZ CNT2
001010  5206          JMP LOOP2
001011  2220          ISZ CNT1
001012  5203          JMP LOOP1

              /       HLT
001013  5775'         JMP 7600
              /
001014  0000  CPAGE,  0
001015  0000  CSRT,   0
001016  5615          JMP I   CSRT
001017  5207  CDEST,  JMP     RETURN
001020  0000  CNT1,   0
001021  0000  CNT2,   0
              /
001175  7600
001176  0140
001177  3074
        1200          *1200
001200  0000  OPAGE,  0
001201  0000  OSRT,   0
001202  5601          JMP I   OSRT
001203  5777' ODEST,  JMP     RETURN
              /
001377  1007
              $

Here is a table with execution times:

   	            	386	386	486	486
              pdp8/e	25Mc	40Mc	33Mc	50Mc
_____________________________________________________
B0.BN  empty   38.4	37.6	24.0	12.8	7.7

B1.BN  NOP     50.4	47.3	30.7	16.5	9.7
   		1.2us	 		  .37us  .2us

B2.BN  TAD CP	64.4	56.1	35.7	19.1	11.5
  		 2.6us    	   	  .63us   .38us

B3.BN  TAD ZP	64.3	53.6	34.35	18.6	 -
   		 2.6us     		  .58us

B4.BN  TAD OP	76.3	63.7	40.3	21.6	12.9
   		 3.8us     		  .88us  0.52us

B5.BN  TAD AIX	78.4	63.82	40.72	25.5     -
   		 4.0us    		 1.27us

B6.BN  DCA CP	64.0	57.1	34.26	18.6     -
   		 2.6us     		  .58us

B7.BN  DCA OP	76.4	60.9	39.03	20.7	12.8
   		 3.8us     		  .79us   .51us

B8.BN  CLA ...	50.4	50.7	31.79	17.4	9.9 
   		 1.2us     		  .46us   .22us

>From here two Instructions, one JMx and an adequate
return:
B9.BN  JMS CP	88.3	82.7	53.5	27.1     -
   		 5.0us    		 1.42us

B10.BN JMS OP  100.5	90.5	58.6	29.4     -
   		 6.2us    		 1.66us

B11.BN JMP CP	62.5	71.8	47.16	32.19    -
   		 2.4us    		 1.94us

B12.BN JMP OP	86.4	87.1	56.6	28.6     -
   		 4.8us    		 1.58us 

Please no discussion about percents and hundreds of micro-
seconds. I took the times with my wrist watch, and there may by some
translation errors, but the tendency is clear:
The emulator on a '386 with 25 Mc has approximately the same speed as
a pdp8/e, and the '486 with eiza bus is a little bit more than three
times faster as the original.
Another item is the speed of the RK05. I couldn't test this till now,
but as soon as it is possible I'll post this too.
If the emulator runs stable, I'll make it available to the public.

Klemens Krause
National Centre for
Minimal- and Retro- computing
Stuttgart / Germany

---

From: [email-masked] (Charles Lasner)
Date: 15 Dec 1993 16:30:43 GMT

In article <[email-masked]>,

>   M6850 (KL8-8) instructions are to be emulated bit by bit, including inter-

Yes, this is most necessary.  It's all too easy to wind up with an emulator
that doesn't emulate the timing of interrupt-driven code.  The net result
is code that has all the overhead and none of the advantages of using
interrupts, a situation largely the case on the DECmates :-(.  Also, note
that this also means that all of the diagnostic paper tapes have to run as
well.  (You may copout and not implement the time-share trap :-).)

>   OS/8 must be bootable from an octal-dump of my SYS: (RK8E + RK05) with

As you are aware, OS/8 doesn't run materially different from different devices
since it runs without interrupts on the disk always, and always on all other
devices except when the FORTRAN IV run-time is executing.  (Little else about
OS/8 cares about interrupts.)  So, the only driving parameter here is the
fastest emulation.

While the RX01/02 is probably the worst standard device to emulate, the RK8E
is not the best one.  Clearly, the best standard device to emulate is the
RF08 since it's able to sustain a DMA transfer of an entire field and has
minimal protocol to emulate in terms of emulated handler code to get the
handler calls accomplished.  You cannot claim the advantage of being
dismounted, since the emulated device will not be data-transferable to the
real media, rather just the ability to eventually get an image of it there.
Incidentally, my PDP-8 ENCODE utilities allow image transfers of devices
between systems, assuming Kermit is available to send the data.  Thus, you
could send a copy of your RK data to the emulated -8 :-).

The best overall device to emulate is the MDC8.  The SCSI devices can be a 
mix of emulated devices and also real ones.  For example, if the PC has an
SCSI port already, such as for a CD-ROM, you could also hang a SyQuest
drive on the SCSI buss.  That SyQuest drive could be a bootable 45 MByte or
larger drive (they come now in three sizes, up to 105 MByte) that contains
MENU-8, under which could be running (multiple) copies of P?S/8 and/or OS/8.

If you emulate the OMTI 5400 controller (or hang a real one on!) you can
also have MFM drives (real or emulated) and also high-density floppies.  The
most minimal configuration (assuming a PC or Mac as the base of the emulator)
would be a pair of high-density floppies.  (I have a pair of 1.2 MByte HD 
drives on my -8/e-a, but could easily change to 1.44 MByte 3.5" drives.)  If
only floppies are to be emulated, a PC can do 1.2 MB and 1.44 MB, while a Mac
must be new enough to support 1.44 MB at all.  Note that this level of
emulation requires no hardware at all, since all of these machines have what
it takes built-in.  (I don't want to hear about PDP-8 emulators run from
XT's with 360K-only disks :-).)

This kind of emulation achieves something you were only hoping for:  actual
media compatibility between a PDP-8 and the machine it's emulated on!  The
bootable HD diskettes of P?S/8 and OS/8 for the MDC8 w/5400 and HD diskette
drives will boot on the -8, and also on the emulator directly!  Further, they
can be turned into MS-DOS files using TELEDISK, and shipped around the net in
uuencoded files, etc.  (The DECmates already have this, as we routinely send
RX50 images just about anywhere :-).)

Emulation of the MDC8 is superior to all other devices:  Consider the RK8E.
The RK8E requires PDP-8 code to setup a single sector transfer.  Then you
have so accomplish the equivalent of the DMA for that sector, then run the
emulated code that diddles around setting up the next transfer, etc.  The
emulated handler calls chew up a lot of emulated PDP-8 cycles.  The MDC8
works by issuing two IOT's that point to an SCSI command in memory that the
handler sets up.  The command is carried out by DMA, and then typically implies
a DMA transfer to read or write the block data, etc.  But unlike the RK8E, the
DMA transfer is done in one operation.  Maximum transfer is 256 sectors, but
in practice is limited to 32K at a time.  OS/8 and P?S/8 handlers will limit
this further to 4K at a time, but this is a far cry from the .25K at a time
the RK8E transfers!  Furthermore, the MDC8 is not size-limited like the RF08,
which has a maximum size of just one large OS/8 device.  (Note: the RK8E is
typically implemented as two logical devices - RKA0: and RKB0: on the first
drive.  But each is *smaller* than the RF08 or MDC8 logical drives.  Due to
the size of most MDC8 SCSI devices, OS/8 is mapped into several logical
devices, all of which are the size of an RF08.)

Since most of the MDC8 operation is done by DMA and another processor, it's the
ideal choice for an emulated device.  The total number of emulated PDP-8
cycles is minimal, which makes for the fastest possible emulation, etc.

Note that even a PDP-8 RAM disk would be slower to emulate, since all transfer
operations are carried out by IOT's.

>   I want then to compile a 180K-Fortran IV programm and run the KERMITs from

Agreed.  Also, this brings up a fine point of emulation.  Strictly speaking,
PDP-8's are ignorant of their baud rate speeds.  In theory, the interface
could be clocked against something else, such as CPU speed or a DK8E, but in
practice the rate is just ignored.  However, support for the baud rate
selection can be added ala the VT-78 and newer machines.  But this would be
limited in the standard version to 19200 baud and lower.

>   Make it as fast as ever possible. The result is, that the programm is fully

Agreed.  Thus don't support mediocre I/O devices like the RK8E.

Most of the software is disk-i/o-bound, not CPU bound, so put a lot of effort
into improving the performance of the disk emulation.

cjl