Re: Bug-for-bug compatibility [was RE: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]]

[allison via cctalk]

On 03/02/2018 06:44 AM, Maciej W. Rozycki via cctalk wrote:
> On Wed, 28 Feb 2018, Paul Koning via cctalk wrote:
>
>> With the VAX, this got cleaned up to a significant extent, and ditto 
>> with Alpha.  In both cases, an internal validator tool was created to 
>> verify that, at least from the point of view of instruction execution, a 
>> new machine worked the same as an existing reference machine.  But this 
>> seems to be quite an unusual notion in the history of computer hardware 
>> development generally.  Even when standard specifications exist that 
>> appear to spell out how an architecture is supposed to work, the reality 
>> is that two implementations will in general do it differently.  That is 
>> particularly likely to happen in cases of "no one will do this" -- like 
>> shifts by more than the word size, or other oddball stuff.
Its right after the VAX that DEC engineering started thinking about
standards.
It was clear that the PDP-11 was not one fully unified system as each
variant
had its own unique quirks more so after the advent of the LSI-11 and F11
chips.
Of of the PDP-11 handbooks I have has a back page of differences in
instruction
set behavior between all of the known PDP-11s including T-11 and J11,

It was clear the VAX architecture had to have a clear definition that
was true
across all of VAXen yet to come.  This was brought about by the need to
keep
VMS consistent and also later Ultrix.   Hence the DEC STD For VAX came to
being and the test for is it a VAX as well.  Exceptions were clearly
listed and
the software impacts were defined.    Of course since Alpha had to run VMS
(by then OpenVMS) and Ultrix or its heirs it also was spec'ed out fully
and for
all expected generations.

>  That's what architecture verification programs or AVP tests are for 
> nowadays.  Everything that's not undefined in the architecture is supposed 
> to work as defined.  This includes odd corner cases.  Formal definitions 
> are included in the architecture specification.
Now we do in the world.  But a good example of variations on a theme is ARM.
Though there are some controls is an earlier ARM 16bit  a subset of an ARM
64 bit?

Allison
>   Maciej

Re: Bug-for-bug compatibility [was RE: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]]

[Maciej W. Rozycki via cctalk]

On Wed, 28 Feb 2018, Paul Koning via cctalk wrote:

> With the VAX, this got cleaned up to a significant extent, and ditto 
> with Alpha.  In both cases, an internal validator tool was created to 
> verify that, at least from the point of view of instruction execution, a 
> new machine worked the same as an existing reference machine.  But this 
> seems to be quite an unusual notion in the history of computer hardware 
> development generally.  Even when standard specifications exist that 
> appear to spell out how an architecture is supposed to work, the reality 
> is that two implementations will in general do it differently.  That is 
> particularly likely to happen in cases of "no one will do this" -- like 
> shifts by more than the word size, or other oddball stuff.

 That's what architecture verification programs or AVP tests are for 
nowadays.  Everything that's not undefined in the architecture is supposed 
to work as defined.  This includes odd corner cases.  Formal definitions 
are included in the architecture specification.

  Maciej

RE: Bug-for-bug compatibility [was RE: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]]

[Rich Alderson via cctalk]

From: Doug Ingraham
Sent: Wednesday, February 28, 2018 9:53 AM

> This is a great story!  And it probably indicates that when developing the
> Toad-1 this particular diagnostic was never run from an original DEC generated
> tape or the Toad-1 would have failed the diagnostic.  Alternatively assembling
> the diag on the restoration project would have yielded a working multiply.

As it happens, this diagnostic is KI-10 specific, so no recompilation of the
KL-10 diagnostics would have caught it.

In addition, because the XKL-1 CPU was supposed to be identical to the KL-10,
it needed to pass the diagnostics *as provided* for the KL-10.

> So is someone going to fix the multiply instruction in the 20+ year old Toad?
> 

Actually, they tried, but because they had stopped using the Toad-1 several
years earlier (and donated all the remaining spare parts to the museum), they
had no way to test in-house, and limited cycles for developing a fix.  If we
ever need to recompile diagnostics for the KI-10 (or, mirabile dictu, a KA-10!)
we'll use a Toad-2.

Rich

Re: Bug-for-bug compatibility [was RE: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]]

[Chuck Guzis via cctalk]

On 02/28/2018 10:55 AM, Paul Koning via cctalk wrote:

> In general, manuals are only a rough approximation of reality.  I
> remember an old joke that "PDP-11/x is compatible with PDP-11/y if
> and only if x == y".  And sure enough, if you look at the models
> appendix of the PDP-11 Architecture Handbook you will see cleary that
> this is true.  More precisely, it is if you ignore cases where two
> model numbers were assigned to the same thing, such as 11/35 and
> 11/40.
In general, I've always taken the manuals as saying "if you do things
the way we say they work, you'll be safe".   Where the manual says one
thing and the reality is otherwise, there's a cause for concern.

The arithmetic right-shift with sign extension always made perfect sense
to me on the 6600.  It's not so simple if all you have is a logical
right shift and want to do an arithmetic one.  The instruction mnemonic
reflects this (AX, vs. left shift LX).   If you've got the arithmetic
right shift and need a logical one with zero fill, add an MX to create a
mask and then a BX to clear the extended bits.  If you time your code,
the penalty is only 2 cycles.

I recall that we ran into trouble with trying to automatically take
advantage of the CMU option on the lower (72,73) CYBER machines (the
CYBER 74 didn't have the CMU option).  Since the CMU instructions
co-opted the no-op (46xxx) instruction, you could test for a CMU by
putting a 30 bit CMU instruction (IM) with the second parcel also being
46000 and a jump in the second two.

If there was no CMU, the first two parcels would be executed as no-ops
and the jump would be taken.  Otherwise, the CMU instruction would be
executed and no jump would occur, as CMU instructions could only be
placed in the first parcel of a word.   Clever--and I recall that it was
used in several libraries  (the lower CYBER CMU DM instruction was
faster than a CPU loop for block moves).

Then the CYBER 170 came along and someone decided that CMU instructions
attempted when there was no CMU should cause an "illegal instruction"
exception.   And then everything broke.

There, the code was playing by the book.   The reference manual shows
the lower 9 bits of the 46 instruction as shaded out; i.e., ignored. (on
the 6600, we found that they weren't exactly ignored--non-zero values
could affect the timing).

Later versions of the manual show the instruction encoding as 46000, but
that was only after CPD began taking advantage of the CMU capabilities
with the "trick".

--Chuck

Re: Bug-for-bug compatibility [was RE: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]]

[Paul Koning via cctalk]

> On Feb 28, 2018, at 1:10 PM, David Bridgham via cctalk 
>  wrote:
> 
> 
>> Imagine our chagrin when days of trying to correct the
>> problem led to the conclusion that the diagnostic was incorrect.
> 
> I may have a situation like this in working on my FPGA PDP-10.  The
> Processor Reference Manuals seem quite clear that the rotate
> instructions take E mod 256.  One of the manuals I've found even adds
> that they never move more than 255 positions.  And yet the diagnostics I
> have clearly want ROT AC,-256 to move 256 positions to the right, not
> 0.  Not having a real PDP-10 to compare against, I don't know which is
> right.

In general, manuals are only a rough approximation of reality.  I remember an 
old joke that "PDP-11/x is compatible with PDP-11/y if and only if x == y".  
And sure enough, if you look at the models appendix of the PDP-11 Architecture 
Handbook you will see cleary that this is true.  More precisely, it is if you 
ignore cases where two model numbers were assigned to the same thing, such as 
11/35 and 11/40.

With the VAX, this got cleaned up to a significant extent, and ditto with 
Alpha.  In both cases, an internal validator tool was created to verify that, 
at least from the point of view of instruction execution, a new machine worked 
the same as an existing reference machine.  But this seems to be quite an 
unusual notion in the history of computer hardware development generally.  Even 
when standard specifications exist that appear to spell out how an architecture 
is supposed to work, the reality is that two implementations will in general do 
it differently.  That is particularly likely to happen in cases of "no one will 
do this" -- like shifts by more than the word size, or other oddball stuff.  

And sometimes CPU designers do stuff that's just plain nuts, like the CDC 6600 
which has a shift instruction where some of the high order bits must be zero 
and some are ignored.  Or the way it executes a 30-bit instruction that starts 
in the last 15 bits of the instruction word.  Both are cases where there is 
additional logic involved (or at least extra wires) to do something that 
clearly serves no purpose.  And these things are definitely not documented in 
any user manual, though you can find them if you read the schematics carefully 
enough.

paul

Re: Bug-for-bug compatibility [was RE: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]]

[David Bridgham via cctalk]

> Imagine our chagrin when days of trying to correct the
> problem led to the conclusion that the diagnostic was incorrect.

I may have a situation like this in working on my FPGA PDP-10.  The
Processor Reference Manuals seem quite clear that the rotate
instructions take E mod 256.  One of the manuals I've found even adds
that they never move more than 255 positions.  And yet the diagnostics I
have clearly want ROT AC,-256 to move 256 positions to the right, not
0.  Not having a real PDP-10 to compare against, I don't know which is
right.

Doing it mod 256 would be easier; I had to add an extra rotor to my
barrel shifter to handle the -256 case to make the diagnostic pass.

Re: Bug-for-bug compatibility [was RE: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]]

[Doug Ingraham via cctalk]

On Tue, Feb 27, 2018 at 2:46 PM, Rich Alderson via cctalk <
cctalk@classiccmp.org> wrote:
>
> Fast forward 20 years, to Living Computer Museum, where a KI-10 based
> DEC-1070
> was undergoing restoration.  Diagnostics were needed, so the resident
> TOPS-20
> programmer laid hands on the MAINDEC sources for the KI-10 and proceeded to
> compile them all and generate paper tapes of the results.  All went
> smashingly
> well until the multiplication test.
>
> The diagnostic source for this test uses a macro to build a set of test
> values
> for X**2 where X is a power of 2.  Internally, Macro-20 uses the IMULM
> instruction to build the results.  In the KA-10 manual, IMULx of 2**35 *
> 2**35
> is supposed to store the high order part of the result into the 36 bit word
> addressed by the instruction, and set the overflow bit.
>
> On the Toad-1 (and on the Toad-2 prior to our discovery of this bug), a
> zero is
> stored instead.  Since we compiled the KI-10 diagnostics on the Toad-1,
> this
> incorrect result was placed on the diagnostic paper tape, and the KI-10
> seemed
> to fail the diagnostic.  Imagine our chagrin when days of trying to
> correct the
> problem led to the conclusion that the diagnostic was incorrect.
>
> Rich
>

This is a great story!  And it probably indicates that when developing the
Toad-1 this particular
diagnostic was never run from an original DEC generated tape or the Toad-1
would have failed
the diagnostic.  Alternatively assembling the diag on the restoration
project would have yielded
a working multiply.

So is someone going to fix the multiply instruction in the 20+ year old
Toad? 

-- 
Doug Ingraham
PDP-8 SN 1175

Bug-for-bug compatibility [was RE: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]]

[Rich Alderson via cctalk]

From: Paul Koning
Sent: Monday, February 26, 2018 12:19 PM

>> On Feb 26, 2018, at 12:06 PM, Doug Ingraham via cctalk
>> > wrote:

>> The purpose of an emulator is to accurately pretend to be the original
>> hardware.  It doesn't matter that the original OS runs on a particular
>> emulator.  If a program can be written that runs on the original hardware
>> but fails on the emulator then there is a flaw in that emulator.

> That's true.  But it is unfortunately also true that creating a bug for bug
> accurate model of an existing machine is extremely hard.

This is true even in real hardware (or "real" hardware, if you prefer), whether
bug-for-bug or simply correct results for corner cases.

The XKL Toad-1 System was designed to be a superset clone of the KL-10 based
DECSYSTEM-2065 from Digital Equipment Corporation.  It implements the full
30-bit extended addressing introduced with TOPS-20 v4, of which the KL-10
provided a 23-bit subset, and provides native support for 10Mbit Ethernet and
FASTWIDE differential SCSI2 (both state of the art in 1991 when the design was
frozen).

As a better DEC-20, the Toad-1 was a success.  (We will leave aside the issue
of its market failure, which is irrelevant to the story.)

Fast forward 20 years, to Living Computer Museum, where a KI-10 based DEC-1070
was undergoing restoration.  Diagnostics were needed, so the resident TOPS-20
programmer laid hands on the MAINDEC sources for the KI-10 and proceeded to
compile them all and generate paper tapes of the results.  All went smashingly
well until the multiplication test.

The diagnostic source for this test uses a macro to build a set of test values
for X**2 where X is a power of 2.  Internally, Macro-20 uses the IMULM
instruction to build the results.  In the KA-10 manual, IMULx of 2**35 * 2**35
is supposed to store the high order part of the result into the 36 bit word
addressed by the instruction, and set the overflow bit.

On the Toad-1 (and on the Toad-2 prior to our discovery of this bug), a zero is
stored instead.  Since we compiled the KI-10 diagnostics on the Toad-1, this
incorrect result was placed on the diagnostic paper tape, and the KI-10 seemed
to fail the diagnostic.  Imagine our chagrin when days of trying to correct the
problem led to the conclusion that the diagnostic was incorrect.

Rich


Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computers: Museum + Labs
2245 1st Avenue S
Seattle, WA 98134

mailto:ri...@livingcomputers.org

http://www.LivingComputers.org/

Writing emulators (Was: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]

[Fred Cisin via cctalk]

The purpose of an emulator is to accurately pretend to be the original
hardware.  It doesn't matter that the original OS runs on a particular
emulator.  If a program can be written that runs on the original hardware
but fails on the emulator then there is a flaw in that emulator.


On Mon, 26 Feb 2018, Paul Koning via cctalk wrote:
That's true.  But it is unfortunately also true that creating a bug for 
bug accurate model of an existing machine is extremely hard.


There is always a decision to be made, whether to mimic the behavior, or 
mimic how it is supposed to behave.  If you are aware of a bug in the 
original, do you emulate that bug?There was once a New Yorker cartoon, 
where a mechanic told a customer, "For $300 we can get it to run like new. 
For $600 we can get it to run like it should."


Emulation of the bugs can not simply be ignored.
Surely, you could get away with not emulating the truncated mantissa FDIV 
bug?  Not necessarily.


Sometimes timing can be important.  Using a do-nothing loop for a time 
delay was never a good idea (and optimizers would remove it), but it did 
happen, ranging from crude amateur programs, to crude copy protection.


I remember when it was sometimes necessary for MS-DOS code to determine 
what processor it was running on.  Since not all processors provided an 
"Identify yourself" command, it was done through checking for bugs, 
obscure differences, etc.  Such as checking the size of the pre-fetch 
buffer, or whether a double prefix was maintained after an interrupt (REP 
ES:MOVSW).  There was no offical method for identification.  I remember 
an article in Microcornucopia that mentioned an Intel sanctioned 
set of methods; the author couldn't remember where he got it; I called 
Intel, and after many transfers reached somebody who understood the 
question; he had no idea, but asked me to forward him a copy if I did 
ever find it.



So, it becomes necessary to have massive configuration settings, to be 
able to emulate as spec'ed, or as which set of the variant bugs.


It's hard enough just getting it to work!
When the first software based PC emulator for the Amiga came out, it 
worked [well enough to run XenoCopy on some formats].  But, people 
griped because it wasn't faster than their current PC.
Geez!  They got an elephant to fly, and people gripe about the speed and 
payload capacity!



--
Grumpy Ol' Fred ci...@xenosoft.com

Re: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]

[Glen Slick via cctalk]

On Mon, Feb 26, 2018 at 12:19 PM, Paul Koning via cctalk
 wrote:
>
> Another example is the work pdp2011 had to do in order to make RSTS boot on 
> that FPGA based PDP-11 emulation, because RSTS was doing some CPU-specific 
> hackery to test for an obscure CPU (or FPU?) bug that had been corrected in 
> some ECO that it wanted to require.  The only way to figure out how to do 
> that is to reverse engineer that particular bit of code, which isn't normally 
> available in source form.
>

I have one M8190 KDJ11-B that caused an RSTS/E 10.1 installation
failure. I forget what the error message was. Looking at an
installation tape message maybe it was one of these strings.
Unfortunately I could not contact field service to correct the
problem.

ECOs are missing from this FPJ11.
This DCJ11 cannot be used in conjunction with an FPJ11 accelerator.
Contact Field Service for FCO kit EQ-01440-02 to correct the problem.
The floating exception ECO is missing from this FPJ11.

Re: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]

[Paul Koning via cctalk]

> On Feb 26, 2018, at 12:06 PM, Doug Ingraham via cctalk 
>  wrote:
> 
> The purpose of an emulator is to accurately pretend to be the original
> hardware.  It doesn't matter that the original OS runs on a particular
> emulator.  If a program can be written that runs on the original hardware
> but fails on the emulator then there is a flaw in that emulator.

That's true.  But it is unfortunately also true that creating a bug for bug 
accurate model of an existing machine is extremely hard.  Building an 
OS-compatible version is not nearly as hard, but still hard enough.  Passing 
diagnostics is yet another hurdle; in some cases that isn't feasible without an 
entirely different design.  For example, in the CDC 6600 there is the "exchange 
jump" test, which at some point depends on the execution time of a divide 
instruction and the timing of exchange instructions.  It is very hard for an 
emulator to  mimic that (and an utter waste of effort for every other bit of 
software available for that machine).

Another example is the work pdp2011 had to do in order to make RSTS boot on 
that FPGA based PDP-11 emulation, because RSTS was doing some CPU-specific 
hackery to test for an obscure CPU (or FPU?) bug that had been corrected in 
some ECO that it wanted to require.  The only way to figure out how to do that 
is to reverse engineer that particular bit of code, which isn't normally 
available in source form.

paul

Re: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]

[Doug Ingraham via cctalk]

On Fri, Feb 23, 2018 at 2:49 PM, Rick Murphy via cctalk <
cctalk@classiccmp.org> wrote:

> On 2/21/2018 5:14 PM, Paul Koning via cctalk wrote:
>
>> Ok, then it could be for VMS, which also does this (via Andy's
>> unsupported driver).  I don't know of PDP-11 or other minicomputer systems
>> that do DECtape overlapped seek.  I suppose it could be for artistic
>> verisimilitude...
>>
>
> TSS/8. It was a wonderful thing to witness. Start the drive spinning,
> deselect it, go start up another, then reselect the first one as it
> approached the right part of the tape.
> -Rick
>

The purpose of an emulator is to accurately pretend to be the original
hardware.  It doesn't matter that the original OS runs on a particular
emulator.  If a program can be written that runs on the original hardware
but fails on the emulator then there is a flaw in that emulator.

I've been slowly working on a PDP-8 emulator since the mid 1980's.  It was
able to run code a couple of days after I started working on it.  FOCAL in
about a week.  The Teletype emulation timing was added early on so a
program could not tell it was running on the emulator by timing the TTY
instructions.  About 10 years ago I added acceleration curves to the high
speed paper tape reader timing.  Within the last year I have added DF-32
support and am working towards fixing the timing so a program could not
be written to tell.  I need to add a randomness factor to the inter platter
timing.  At the moment it looks like all the drives are in optimum lockstep
which makes transfers run a little faster but isn't reality.  Probably add
a 50 hz option for those in 50 hz countries since the drive motors run
slower there and thus transfers were slower.

I have delayed adding DECTape support for years because of the difficulty
of doing this correctly.  You need to support so much stuff to do this
right from a timing standpoint.  At least on the TC01 controller you can
read in the reverse direction as well as the normal forward direction.  Do
you need to support reverse reads?  Almost no software took advantage of
this.  Every drive runs a little different and the emulator could (should)
reflect this.

If you can't have a real machine the least you can have is a correct as
possible emulator.  It is a lot easier to be lazy and think you are done
when the OS boots or an interpreter appears to run or it passes
diagnostics.  In reality you have barely begun.


-- 
Doug Ingraham
PDP-8 SN 1175

Re: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]

[Rick Murphy via cctalk]

On 2/21/2018 5:14 PM, Paul Koning via cctalk wrote:

Ok, then it could be for VMS, which also does this (via Andy's unsupported 
driver).  I don't know of PDP-11 or other minicomputer systems that do DECtape 
overlapped seek.  I suppose it could be for artistic verisimilitude...


TSS/8. It was a wonderful thing to witness. Start the drive spinning, 
deselect it, go start up another, then reselect the first one as it 
approached the right part of the tape.

    -Rick

Re: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

[Paul Koning via cctalk]

> On Feb 22, 2018, at 3:09 AM, Chris Hanson via cctalk  
> wrote:
> 
> On Feb 21, 2018, at 11:09 AM, Al Kossow via cctalk  
> wrote:
>> 
>> That is tricky to cleanly and efficiently implement where each component is 
>> modeled independently and
>> glued together with a higher-level framework.
> 
> This is why I wonder if multithreaded emulation might be a reasonable future 
> approach: Model more components of a system as operating independently as 
> they produce and react to signals, have them block when not reacting (either 
> to a clock pulse or a signal), and let the operating system manage scheduling.

It depends on the machine being emulated.  In some cases, multiple components 
that seem to be independent actually have tightly coupled timing, and software 
relies on that.

For example, a CDC 6000 series mainframe has 10 or 20 PPUs plus one or two 
CPUs.  With a bit of care, you can model the two CPUs using two threads.  But 
all the PPUs have to be done in one thread because they run in lockstep.  If 
you make them each a thread, the OS won't boot.  I tried it and gave up.  It 
would have been nice, it might have opened a path to a power-efficient 
emulation, but it didn't appear doable.

Processors vs. I/O devices might work, but again the devil is in the details.

paul

Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Peter Coghlan via cctalk]

Guy Sotomayor Jr wrote:
>
>> On Feb 21, 2018, at 12:19 PM, Rich Alderson via cctalk 
>>  wrote:
>> 
>> From: Guy Sotomayor Jr
>> Sent: Wednesday, February 21, 2018 11:24 AM
>> 
 On Feb 21, 2018, at 10:59 AM, Paul Koning via cctalk 
 
 wrote:
>> 
 Typically you'd emulate the I/O device functionality, regardless of whether
 that is implemented in gates or in co-processor firmware.  That's the
 approach taken with the MSCP I/O device emulation in SIMH, or the disk
 controller emulation in the CDC 6000 emulator DtCyber.
>> 
>>> It’s also what’s done in Hercules (S/370, 370/XA, 390, Z simulator) and the
>>> mainframe I/O is complex to say the least.
>> 
>> Also the method used by the KLH10 emulator (KS-10, KS-10/ITS microcode, 
>> KL-10).
>> There, each device type runs in a separate fork, using System V style memory
>> mapping.  This of course means that it only runs under certain Unix variants.
>
> I haven’t looked at KLH10 in a long time, but Hercules runs on a lot of 
> different platforms
> including Windows (and I would not call that a Unix variant by any stretch of 
> the imagination).
>

Hercules uses posix threads, not forks, however, each device does not 
necessarily
get it's own thread.  It's pretty portable stuff though.  With very few tweaks,
I run it on VMS.

Regards,
Peter Coghlan.

>
> TTFN - Guy
> 

Re: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

[Chris Hanson via cctalk]

On Feb 21, 2018, at 11:09 AM, Al Kossow via cctalk  
wrote:
> 
> That is tricky to cleanly and efficiently implement where each component is 
> modeled independently and
> glued together with a higher-level framework.

This is why I wonder if multithreaded emulation might be a reasonable future 
approach: Model more components of a system as operating independently as they 
produce and react to signals, have them block when not reacting (either to a 
clock pulse or a signal), and let the operating system manage scheduling.

  -- Chris

Re: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]

[Lars Brinkhoff via cctalk]

Rich Alderson wrote:
> It's not for Tops-10.  SimH only provides the KS-10 processor[1], so
> DECtape is not a possible peripheral.
> [1] Although there is a KA-10 in the works.

Also KI-10 in its current state.  Maybe PDP-6 in the future.

Re: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

[Chris Elmquist via cctalk]

> On Feb 21, 2018, at 3:52 PM, Chuck Guzis via cctalk  
> wrote:
> 
>> On 02/21/2018 12:28 PM, Al Kossow via cctalk wrote:
>> That actually just came up for discussion in a donation review meeting this 
>> week at
>> CHM.
>> 
>> I don't know if they're that interesting w/o the software and documentation, 
>> and even
>> then, these things were all locked down with licenses, except for the really 
>> early ones
>> like Daisy and Valid.
>> 
>>> On 2/21/18 11:37 AM, Chuck Guzis via cctalk wrote:
>>> 
>>> Speaking of emulation, does anyone here collect old ZyCAD or Cadence
>>> hardware emulation rigs?
> 
> Definitely lots of proprietary stuff.  I had a couple of friends who
> worked for ZyCAD back in the day.  I got the impression that they were
> only exposed to a piece of the puzzle.
> 
> Also, expensive as hell.
> 
> --Chuck

We had a lot of ZyCAD stuff at ETA because we just had to drive a couple miles 
up the road to get it ;-)  Lots of the ETA brass were buddies with the ZyCAD 
brass because they all came from ADL.

We used it to simulate the ALSI 20K gate arrays before they were built.  The 
gear we had was usually plugged into some Apollo headless nodes, which I think 
were Multibus backplanes?? and then accessed over the Domain network.

Chris

Re: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]

[Paul Koning via cctalk]

> On Feb 21, 2018, at 3:25 PM, Rich Alderson via cctalk  
> wrote:
> 
> From: Paul Koning
> Sent: Wednesday, February 21, 2018 6:41 AM
> 
>> And while there is roughly-accurate simulation of DECtape in SIMH (presumably
>> for TOPS-10 overlapped seek to work?)
> 
> It's not for Tops-10.  SimH only provides the KS-10 processor[1], so DECtape 
> is
> not a possible peripheral.

Ok, then it could be for VMS, which also does this (via Andy's unsupported 
driver).  I don't know of PDP-11 or other minicomputer systems that do DECtape 
overlapped seek.  I suppose it could be for artistic verisimilitude...

paul

Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Guy Sotomayor Jr via cctalk]

> On Feb 21, 2018, at 12:19 PM, Rich Alderson via cctalk 
>  wrote:
> 
> From: Guy Sotomayor Jr
> Sent: Wednesday, February 21, 2018 11:24 AM
> 
>>> On Feb 21, 2018, at 10:59 AM, Paul Koning via cctalk 
>>> wrote:
> 
>>> Typically you'd emulate the I/O device functionality, regardless of whether
>>> that is implemented in gates or in co-processor firmware.  That's the
>>> approach taken with the MSCP I/O device emulation in SIMH, or the disk
>>> controller emulation in the CDC 6000 emulator DtCyber.
> 
>> It’s also what’s done in Hercules (S/370, 370/XA, 390, Z simulator) and the
>> mainframe I/O is complex to say the least.
> 
> Also the method used by the KLH10 emulator (KS-10, KS-10/ITS microcode, 
> KL-10).
> There, each device type runs in a separate fork, using System V style memory
> mapping.  This of course means that it only runs under certain Unix variants.

I haven’t looked at KLH10 in a long time, but Hercules runs on a lot of 
different platforms
including Windows (and I would not call that a Unix variant by any stretch of 
the imagination).

TTFN - Guy

RE: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Henk Gooijen via cctalk]

Van: Al Kossow via cctalk<mailto:cctalk@classiccmp.org>
Verzonden: woensdag 21 februari 2018 20:11
Aan: cctalk@classiccmp.org<mailto:cctalk@classiccmp.org>
Onderwerp: Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)



On 2/21/18 10:59 AM, Paul Koning via cctalk wrote:

> The absence of that emulation isn't a big deal, unless you want to run the 
> Richy Lary PDP-8 emulator on that emulated 11/60.  (Has it been preserved?)
>

People have been searching for it for a while now, but it appears to have been 
lost.


I have a WCS module for the 11/60 (and an 11/60 to go with it), but I have 
never seen the required software.
I even forgot the names, something like “microcode assembler” and linker. Are 
the assembler, etc tools available?
The 11/60 microcode for the PDP8 emulation is not helping much either if the 
required tools are gone.
Crazy idea … I am repairing a dead 11/40 and learning a lot of how the CPU 
works. There are 256 microde instructions
all 56 bits (IIRC, too lazy to check now). If you install the EIS or FIS, you 
get new microcode instructions on top of the standard 256. “Copying” how EIS 
and FIS add their micro instructions could be the basis of an 11/40 “PDP-8” 
add-on, just like EIS and FIS 
Yeah, I know, I started the paragraph with “crazy idea” …

Re: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

[Chuck Guzis via cctalk]

On 02/21/2018 12:28 PM, Al Kossow via cctalk wrote:
> That actually just came up for discussion in a donation review meeting this 
> week at
> CHM.
> 
> I don't know if they're that interesting w/o the software and documentation, 
> and even
> then, these things were all locked down with licenses, except for the really 
> early ones
> like Daisy and Valid.
> 
> On 2/21/18 11:37 AM, Chuck Guzis via cctalk wrote:
> 
>> Speaking of emulation, does anyone here collect old ZyCAD or Cadence
>> hardware emulation rigs?

Definitely lots of proprietary stuff.  I had a couple of friends who
worked for ZyCAD back in the day.  I got the impression that they were
only exposed to a piece of the puzzle.

Also, expensive as hell.

--Chuck

Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Charles Anthony via cctalk]

On Wed, Feb 21, 2018 at 11:24 AM, Guy Sotomayor Jr via cctalk <
cctalk@classiccmp.org> wrote:

>
>
> > On Feb 21, 2018, at 10:59 AM, Paul Koning via cctalk <
> cctalk@classiccmp.org> wrote:
> >
> >
> > Caching doesn't change user-visible functionality, so I can't imagine
> wanting to emulate that.  The same goes for certain error handling.  I've
> seen an emulator that included support for bad parity and the instructions
> that control wrong-parity writing.  So you could run the diagnostic that
> handles memory parity errors.  But that's a pretty uncommon thing to do and
> I wouldn't bother.
>
> I disagree, especially if you’re using an emulator for development.
> Caching is one of those things that can go
> horribly wrong and not having them emulated properly (or at all) can lead
> to bugs/behaviors that are significantly
> different from real HW.  The same goes for error reporting/handling.
> There are cases where errors may be expected
> and not having them can cause the SW to behave differently.
>
>
dps8m caught a lucky break here; neither the memory or page table caches
are needed for Multics to run correctly. (To some extent due to the
existence of cache disabling switches on the configuration panel.)

The diagnostics do extensive testing of the caches, and (unusually for the
project) they are well documented; the cache emulation code is a build-time
configuration option, and passes the diagnostics tests albeit with a
significant performance hit.

-- Charles

Re: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

[Ethan Dicks via cctalk]

On Wed, Feb 21, 2018 at 2:11 PM, Chuck Guzis via cctalk
 wrote:
> For what it's worth, I differentiate "cycle correct" from "real time".

Agreed.  I've been testing Z-80 emulators over the past year because a
CP/M game (Scott Adams' Adventures) depends on the R register being
refreshed as the cycles tick on because it's used as a cheap source of
entropy for the RNG.  It doesn't happen to matter if it's 100% cycle
exact for the game to work (though a less thorough implementation
_does_ affect the RNG) and it doesn't matter at all how many
real-world microseconds have elapsed.

The issue comes about because some simple Z-80 implementations
(including the version of the Altair emulator that came out with SIMH
3.9) didn't bother to implement the R register because in a real Z-80
the primary purpose of it is to generate 7-bit refresh timing for 16K
(and some 64K) DRAMs.  With no need to refresh emulated RAM, R wasn't
ever incremented.

A 100% cycle-correct implementation of R is slightly complicated
because of the circumstances of which exact part of a complicated
cycle sequence do and do not increment R.  I made some non-functional
code work just by hacking emulators to blindly increment R once for
every instruction.  Not 100% correct, but correct enough.

> Putting it another way, one can maintain a cycle counter in an emulator
> whose contents are updated when certain tasks have been accomplished.

Yes.  The 100% cycle-correct R implementation just has to track the
amount to increment R for each specific class of instruction to attain
the original behavior.

Altair for SIMH has been fixed, and I can say that the Z-80 emulation
for the Commodore 128 in VICE has been correct for quite some time (I
didn't do a lot of regression testing there - every version I tried,
worked.)

So, yeah... there is code out there that depends on buried features
specific to hardware implementation of cycles - but time-correct
emulation is not often required.

-ethan

SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]

[Rich Alderson via cctalk]

From: Paul Koning
Sent: Wednesday, February 21, 2018 6:41 AM

> And while there is roughly-accurate simulation of DECtape in SIMH (presumably
> for TOPS-10 overlapped seek to work?)

It's not for Tops-10.  SimH only provides the KS-10 processor[1], so DECtape is
not a possible peripheral.

Rich

[1] Although there is a KA-10 in the works.

RE: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Rich Alderson via cctalk]

From: Guy Sotomayor Jr
Sent: Wednesday, February 21, 2018 11:24 AM

>> On Feb 21, 2018, at 10:59 AM, Paul Koning via cctalk 
>> wrote:

>> Typically you'd emulate the I/O device functionality, regardless of whether
>> that is implemented in gates or in co-processor firmware.  That's the
>> approach taken with the MSCP I/O device emulation in SIMH, or the disk
>> controller emulation in the CDC 6000 emulator DtCyber.

> It’s also what’s done in Hercules (S/370, 370/XA, 390, Z simulator) and the
> mainframe I/O is complex to say the least.

Also the method used by the KLH10 emulator (KS-10, KS-10/ITS microcode, KL-10).
There, each device type runs in a separate fork, using System V style memory
mapping.  This of course means that it only runs under certain Unix variants.

Rich

Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Seth J. Morabito via cctalk]

Guy Sotomayor Jr via cctalk writes:

>> On Feb 21, 2018, at 10:59 AM, Paul Koning via cctalk  
>> wrote:
>>
>>
>> Caching doesn't change user-visible functionality, so I can't imagine
>> wanting to emulate that.  The same goes for certain error handling.
>> I've seen an emulator that included support for bad parity and the
>> instructions that control wrong-parity writing.  So you could run the
>> diagnostic that handles memory parity errors.  But that's a pretty
>> uncommon thing to do and I wouldn't bother.
>
> I disagree, especially if you’re using an emulator for development.
> Caching is one of those things that can go horribly wrong and not
> having them emulated properly (or at all) can lead to bugs/behaviors
> that are significantly different from real HW.

I'd like to echo this, depending on the caching and the behavior of the
system. In writing the 3B2/400 emulator, I was at first reluctant to
write an accurate emulation of the MMU cache, feeling it unnecessary.  I
very quickly learned that it was not only necessary, but essential to a
correctly running system. Moreover, it had to have the same caching
algorithm as the real hardware to get UNIX SVR3 running happily.

> TTFN - Guy

-Seth
--
Seth Morabito
https://loomcom.com/
w...@loomcom.com

Re: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

[Charles Anthony via cctalk]

On Wed, Feb 21, 2018 at 8:52 AM, Ray Arachelian via cctalk <
cctalk@classiccmp.org> wrote:

> Now, you don't want to run your emulated guest CPU(s) at full speed on
> the host machine, because you'll overheat it, and typically, it'll run a
> multi-process OS anyway and you don't want to starve the GUI, network
> stack, and daemons of CPU cycles, so once you reach your goal MHz in
> your guest CPU, you'd sleep and yield to the host OS for a bit, or maybe
> do some background stuff like see if any I/Os or IRQs are pending (such
> as maybe a keystroke from the user, or an incoming network packet, or
> maybe the disk sector or tape sector your guest OS requested has
> arrived), and handle those.
>
> For the case of Multics on the DPS8/M, the idle loop is implemented with
the "DIS" instruction -- Delay until Interrupt -- which stalls the DPS8/M
CPU until an interrupt or the Timer Register runs out. The Timer Register
is set for 1/4 second. The emulator implements the DIS instruction by
sleeping for 10 milliseconds, checking for I/O events, decrementing the
Timer Register by 10 ms and checking for runout, otherwise repeat. The host
CPU shows <1% usage for a idling Multics system.

This configuration was arrived at through an iterative process of
understanding how Multics uses the Timer Register and trying to figure out
how to implement a 512KHz countdown register in software without excessive
overhead.

Writing an good emulation can require more then understanding the hardware
-- the way the software uses the hardware can help make design decisions.
Because Multics only uses the Timer Register for process scheduling, and
the quantum is always 1/4 second, having a low-resolution timer was
perfectly acceptable and easily implementable.

-- Charles

Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Adrian Stoness via cctalk]

i dont think there is any physical hardware to test from left sept for
maybe part of the front panel and a tape drive sitting in europe in  museum
and a couple random bit in some private collections

drawings theres some but not allot. most of the known documentation is in
dutch and from what i understand i have the largest chunk of surviving
documents in english

https://imageshack.com/a/img924/4649/oyprpu.jpg
https://imageshack.com/a/img922/9277/19TwCI.jpg
https://imageshack.com/a/img922/9277/19TwCI.jpg

managed to aquire unused core sheets with this stuff was a nice bonus have
to get them framed at some point
https://imageshack.com/a/img922/841/kTGEiY.jpg

ill give those sites a look

On Wed, Feb 21, 2018 at 11:44 AM, Eric Christopherson via cctalk <
cctalk@classiccmp.org> wrote:

> On Wed, Feb 21, 2018 at 10:19 AM, Ray Arachelian via cctalk <
> cctalk@classiccmp.org> wrote:
>
> > On 02/19/18 19:36, Adrian Stoness via cctalk wrote:
> > > whats invovled in makin an emulator?
> > > i have a chunk of stuff for the phillips p1000
> >
> > Quite a lot actually.  A single CPU system is difficult enough, but a
> > mainframe might be much, much harder.  The idea to use an existing
> > emulator framework, such as SIMH, is a great one.
> >
>
> Ray, you've provided a few really excellent messages here.
>
> [snip]
>
> > Are you planning on emulating the whole machine, or just the userland?
> > Might be easier to create a simulation of the OS in software on the host
> > side the way that Executor did with MacOS - Cliff implemented his own
> > version of MacOS 7.x, enough to be able to run most applications of that
> > era, but not all.  see: https://github.com/ctm/executor.git and
> > https://github.com/ctm/executor.git - some of this is called "High Level
> > Emulation" and is sort of what WINE does (though wine isn't an emulator).
> >
>
> You put the same URL in twice there; did you intend for another URL?
>
> I was quite a fan of Executor. It's cool to see that it's open source now.
>
>
> > Be careful
> > as there's a lot of "emu scene" folks out there with tons of free time,
> > more than you might have, who will happily promise to help, but instead
> > take your documentation, firmware, OS images, etc. and compete with you
> > behind your back just to get there first, instead of actually helping
> > you with your project.  On this latter point, I sadly speak from
> > experience.
> >
>
> Wow, I didn't know about that. Good to know.
>
> --
> Eric Christopherson
>

RE: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Henk Gooijen via cctalk]

Van: Ethan Dicks via cctalk<mailto:cctalk@classiccmp.org>
Verzonden: woensdag 21 februari 2018 20:44
Aan: Paul Koning<mailto:paulkon...@comcast.net>; General Discussion: On-Topic 
and Off-Topic Posts<mailto:cctalk@classiccmp.org>
Onderwerp: Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

On Wed, Feb 21, 2018 at 1:59 PM, Paul Koning via cctalk
<cctalk@classiccmp.org> wrote:
> If microcode is not user-changeable, or if that capability is not a core 
> feature, then you can easily omit it.  That tends to make the job much 
> easier.  For example, I don't know that anyone emulates the PDP-11/60 WCS.  
> The absence of that emulation isn't a big deal, unless you want to run the 
> Richy Lary PDP-8 emulator on that emulated 11/60.  (Has it been preserved?)

I have long heard of the PDP-8 emulator that depends on the 11/60 WCS
but every time it comes up, it's always been said to be lost.

Feel free to prove me wrong, anyone.  I'd love to stare at it.

-ethan

Tekst on my website:

The only other PDP-11 that has a WCS option (KUV11, M8018) is the PDP-11/03, 
KD11-F processor.
Ritchie Lary wrote the micro-code for the PDP-11/60 to emulate the PDP-8 
instruction set, making it the "fastest PDP-8 ever".
It is a pity that the source code seems to be lost. Even Ritchie Lary, the 
author, no longer had the source when Eric Smith inquired some years back 
(~2011 - 2012), and Ritchie did not think that anyone else was likely to have 
it. So, it appears to be lost forever.

☹

Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Al Kossow via cctalk]

On 2/21/18 10:59 AM, Paul Koning via cctalk wrote:

> The absence of that emulation isn't a big deal, unless you want to run the 
> Richy Lary PDP-8 emulator on that emulated 11/60.  (Has it been preserved?)
> 
>

People have been searching for it for a while now, but it appears to have been 
lost.

Re: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

[Al Kossow via cctalk]

On 2/21/18 11:11 AM, Chuck Guzis via cctalk wrote:

> Putting it another way, one can maintain a cycle counter in an emulator
> whose contents are updated when certain tasks have been accomplished.

Synchronization at start of instruction fetch, DMA complete, and firing of an 
interrupt
can hide a lot of timing inaccuracies.

Finding idle loops can help with host processor CPU resource consumption.

RE: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Henk Gooijen via cctalk]

Van: Paul Koning via cctalk<mailto:cctalk@classiccmp.org>
Verzonden: woensdag 21 februari 2018 20:37
Aan: Guy Sotomayor Jr<mailto:g...@shiresoft.com>
CC: General Discussion: On-Topic and Off-Topic 
Posts<mailto:cctalk@classiccmp.org>
Onderwerp: Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)


> However, it is my belief (and I think others have also stated) that assuming 
> infinitely fast I/O (e.g. no delays what so ever) can cause issues because in 
> many cases the SW expects to be able to do some work between the time that 
> the I/O is started and when it completes.

True, that is unfortunately a fairly common type of software bug.  And because 
it is, emulators have to work around those bugs.  I make it a point to call it 
a bug, though, because I don't want anyone to get the impression that OS 
programmers who wrote such things were doing the right thing.

paul

Yeah, I found that out when I was working on the PDP8/e emulation running on a 
6809. OS/8 does that as well. After issueing the disk I/O it executes a few 
more instructions, because it “knows” that the requested disk data cannot yet 
have been loaded into memory. I solved that problem with a counter that can be 
preset to some TBD value. The value defines the number of extra emulated 
instructions before it jumps to the (now) loaded data from disk – at least, 
that is how I remember it doing over 10 years ago. I have an extensive webpage 
on pdp8 emulation on 6809. I succeeded in finishing it: booting OS/8 and 
running spacewr on it!
Don’t ask how “fast” it ran …

Re: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

[Al Kossow via cctalk]

That actually just came up for discussion in a donation review meeting this 
week at
CHM.

I don't know if they're that interesting w/o the software and documentation, 
and even
then, these things were all locked down with licenses, except for the really 
early ones
like Daisy and Valid.

On 2/21/18 11:37 AM, Chuck Guzis via cctalk wrote:

> Speaking of emulation, does anyone here collect old ZyCAD or Cadence
> hardware emulation rigs?

Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Paul Koning via cctalk]

> On Feb 21, 2018, at 2:47 PM, Henk Gooijen via cctalk  
> wrote:
> 
> ...
> Tekst on my website:
> 
> The only other PDP-11 that has a WCS option (KUV11, M8018) is the PDP-11/03, 
> KD11-F processor.
> Ritchie Lary wrote the micro-code for the PDP-11/60 to emulate the PDP-8 
> instruction set, making it the "fastest PDP-8 ever".

A few more snippets of information: it was used by the WPS-8 development group 
in Merrimack, NH (a few cubes over from my first office at DEC).  The host ran 
RSTS/E, and there was a RSTS "Runtime System" as part of the machinery.

I've never seen any of the code; the brief description above is all I know.

paul

Re: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

[Al Kossow via cctalk]

On 2/21/18 6:41 AM, Paul Koning via cctalk wrote:

> SIMH in principle allows the writing of cycle-accurate CPU simulators, but I 
> don't believe anyone has bothered.

Atari 2600 requires it.
Any simulation of an embedded system that did cycle counting for timing
would require it as well.

One situation that isn't handled correctly in MAME right now is where a CPU is 
stalled by holding /WAIT
or /DTACK off to wait for a peripheral to acquire data, the way that the 
Tarbell floppy interface works,
for example.

That is tricky to cleanly and efficiently implement where each component is 
modeled independently and
glued together with a higher-level framework.

Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Pontus Pihlgren via cctalk]

On Wed, Feb 21, 2018 at 07:44:33PM +, Henk Gooijen via cctalk wrote:
> 
> Van: Paul Koning via cctalk<mailto:cctalk@classiccmp.org>
> Verzonden: woensdag 21 februari 2018 20:37
> Aan: Guy Sotomayor Jr<mailto:g...@shiresoft.com>
> CC: General Discussion: On-Topic and Off-Topic 
> Posts<mailto:cctalk@classiccmp.org>
> Onderwerp: Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)
> 
> 
> > However, it is my belief (and I think others have also stated) that 
> > assuming infinitely fast I/O (e.g. no delays what so ever) can cause issues 
> > because in many cases the SW expects to be able to do some work between the 
> > time that the I/O is started and when it completes.
> 
> True, that is unfortunately a fairly common type of software bug.  And 
> because it is, emulators have to work around those bugs.  I make it a point 
> to call it a bug, though, because I don't want anyone to get the impression 
> that OS programmers who wrote such things were doing the right thing.
> 
> paul
> 
> Yeah, I found that out when I was working on the PDP8/e emulation running on 
> a 6809. OS/8 does that as well. After issueing the disk I/O it executes a few 
> more instructions, because it “knows” that the requested disk data cannot yet 
> have been loaded into memory. I solved that problem with a counter that can 
> be preset to some TBD value. The value defines the number of extra emulated 
> instructions before it jumps to the (now) loaded data from disk – at least, 
> that is how I remember it doing over 10 years ago. I have an extensive 
> webpage on pdp8 emulation on 6809. I succeeded in finishing it: booting OS/8 
> and running spacewr on it!
> Don’t ask how “fast” it ran …


While I too might consider it a bug and bad style. The OS/8 guys knew 
exactly what hardware they would support and probably gained some 
performance by doing it "wrong"

Do you have a link to your work?

/P

Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Ray Arachelian via cctalk]

On 02/21/18 13:49, Ray Arachelian via cctalk wrote:
> https://en.wikipedia.org/wiki/Executor_(software)
>
One more, I point to this because it addresses quite a lot of stuff
that's needed to emulate a CPU, though you don't need to implement it
this way at all.

https://web.archive.org/web/20070609200435/http://www.ardi.com/synpaper.php

Generally these days, it doesn't pay to create a JIT, writing in C (or
even javascript in some instances) is enough of a portable "assembly"
language.
But yeah, do mind the endianness, integer sizes, etc.

Also Ferris Writes Emulators series is pretty good:
https://www.youtube.com/watch?v=Fsi9HPcyrU8=PL-sXmdrqqYYcL2Pvx9j7dwmdLqY7Mx8VY
(He's got a few more emulator related playlists in his channel beyond
this one that are worth a watch.)

Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Ray Arachelian via cctalk]

On 02/21/18 12:44, Eric Christopherson wrote:
>
> era, but not all.  see: https://github.com/ctm/executor.git
>  and
> https://github.com/ctm/executor.git
>  - some of this is called
> "High Level
> Emulation" and is sort of what WINE does (though wine isn't an
> emulator).
>
>
> You put the same URL in twice there; did you intend for another URL?
D'oh!  Meant to point to the wikipedia article about it that describes
how it works.  Sorry about that.  I guess I didn't hit Control-C in the
browser hard enough. :)

https://en.wikipedia.org/wiki/Executor_(software)

Re: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

[Chuck Guzis via cctalk]

For what it's worth, I differentiate "cycle correct" from "real time".

That is, if you're talking about emulating non-mechanical devices,
"cycle correct" emulation should be fairly straightforward, but making
it "real time" (i.e. implementing an emulator such that it's
indistinguishable by an observer from the real thing) is considerably
more difficult.

Putting it another way, one can maintain a cycle counter in an emulator
whose contents are updated when certain tasks have been accomplished.
The real time needed to accomplish those tasks can vary widely, yet the
cycle count will still be quite accurate.


My .02 only
Chuck

Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Paul Koning via cctalk]

> On Feb 21, 2018, at 1:36 PM, Adrian Stoness via cctalk 
>  wrote:
> 
> i dont think there is any physical hardware to test from left sept for
> maybe part of the front panel and a tape drive sitting in europe in  museum
> and a couple random bit in some private collections
> 
> drawings theres some but not allot. most of the known documentation is in
> dutch  ...

There are some people around who speak Dutch and are interested in classic 
computers.  I've done a bunch, but my interest is Electrologica so I don't want 
to divert to other architectures.

I wonder if Google Translate, or analogous services, would do a tolerable job 
on techical documents of this sort.

paul

RE: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Henk Gooijen via cctalk]

Van: Pontus Pihlgren<mailto:pon...@update.uu.se>
Verzonden: woensdag 21 februari 2018 21:15
Aan: Henk Gooijen<mailto:henk.gooi...@hotmail.com>; General Discussion: 
On-Topic and Off-Topic Posts<mailto:cctalk@classiccmp.org>
CC: Paul Koning<mailto:paulkon...@comcast.net>
Onderwerp: Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

On Wed, Feb 21, 2018 at 07:44:33PM +, Henk Gooijen via cctalk wrote:
>
> Van: Paul Koning via cctalk<mailto:cctalk@classiccmp.org>
> Verzonden: woensdag 21 februari 2018 20:37
> Aan: Guy Sotomayor Jr<mailto:g...@shiresoft.com>
> CC: General Discussion: On-Topic and Off-Topic 
> Posts<mailto:cctalk@classiccmp.org>
> Onderwerp: Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)
>
>
> > However, it is my belief (and I think others have also stated) that 
> > assuming infinitely fast I/O (e.g. no delays what so ever) can cause issues 
> > because in many cases the SW expects to be able to do some work between the 
> > time that the I/O is started and when it completes.
>
> True, that is unfortunately a fairly common type of software bug.  And 
> because it is, emulators have to work around those bugs.  I make it a point 
> to call it a bug, though, because I don't want anyone to get the impression 
> that OS programmers who wrote such things were doing the right thing.
>
> paul
>
> Yeah, I found that out when I was working on the PDP8/e emulation running on 
> a 6809. OS/8 does that as well. After issueing the disk I/O it executes a few 
> more instructions, because it “knows” that the requested disk data cannot yet 
> have been loaded into memory. I solved that problem with a counter that can 
> be preset to some TBD value. The value defines the number of extra emulated 
> instructions before it jumps to the (now) loaded data from disk – at least, 
> that is how I remember it doing over 10 years ago. I have an extensive 
> webpage on pdp8 emulation on 6809. I succeeded in finishing it: booting OS/8 
> and running spacewr on it!
> Don’t ask how “fast” it ran …


While I too might consider it a bug and bad style. The OS/8 guys knew
exactly what hardware they would support and probably gained some
performance by doing it "wrong"

Do you have a link to your work?

/P


Direct link: 
www.pdp-11/nl/homebrew/pdp8/pdp8startpage.html<http://www.pdp-11/nl/homebrew/pdp8/pdp8startpage.html>
It is a long story! From the start to a working emulation with lots of debug 
facilities (as found on HP64000 development systems). But this emulation runs 
the pdp8 diagnostics without errors.

RE: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Henk Gooijen via cctalk]

Van: Henk Gooijen via cctalk<mailto:cctalk@classiccmp.org>
Verzonden: woensdag 21 februari 2018 21:20
Aan: Pontus Pihlgren<mailto:pon...@update.uu.se>; General Discussion: On-Topic 
and Off-Topic Posts<mailto:cctalk@classiccmp.org>
Onderwerp: RE: Writing emulators (was Re: VCF PNW 2018: Pictures!)



Van: Pontus Pihlgren<mailto:pon...@update.uu.se>
Verzonden: woensdag 21 februari 2018 21:15
Aan: Henk Gooijen<mailto:henk.gooi...@hotmail.com>; General Discussion: 
On-Topic and Off-Topic Posts<mailto:cctalk@classiccmp.org>
CC: Paul Koning<mailto:paulkon...@comcast.net>
Onderwerp: Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

On Wed, Feb 21, 2018 at 07:44:33PM +, Henk Gooijen via cctalk wrote:
>
> Van: Paul Koning via cctalk<mailto:cctalk@classiccmp.org>
> Verzonden: woensdag 21 februari 2018 20:37
> Aan: Guy Sotomayor Jr<mailto:g...@shiresoft.com>
> CC: General Discussion: On-Topic and Off-Topic 
> Posts<mailto:cctalk@classiccmp.org>
> Onderwerp: Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)
>
>
> > However, it is my belief (and I think others have also stated) that 
> > assuming infinitely fast I/O (e.g. no delays what so ever) can cause issues 
> > because in many cases the SW expects to be able to do some work between the 
> > time that the I/O is started and when it completes.
>
> True, that is unfortunately a fairly common type of software bug.  And 
> because it is, emulators have to work around those bugs.  I make it a point 
> to call it a bug, though, because I don't want anyone to get the impression 
> that OS programmers who wrote such things were doing the right thing.
>
> paul
>
> Yeah, I found that out when I was working on the PDP8/e emulation running on 
> a 6809. OS/8 does that as well. After issueing the disk I/O it executes a few 
> more instructions, because it “knows” that the requested disk data cannot yet 
> have been loaded into memory. I solved that problem with a counter that can 
> be preset to some TBD value. The value defines the number of extra emulated 
> instructions before it jumps to the (now) loaded data from disk – at least, 
> that is how I remember it doing over 10 years ago. I have an extensive 
> webpage on pdp8 emulation on 6809. I succeeded in finishing it: booting OS/8 
> and running spacewr on it!
> Don’t ask how “fast” it ran …


While I too might consider it a bug and bad style. The OS/8 guys knew
exactly what hardware they would support and probably gained some
performance by doing it "wrong"

Do you have a link to your work?

/P


Direct link: 
www.pdp-11/nl/homebrew/pdp8/pdp8startpage.html<http://www.pdp-11/nl/homebrew/pdp8/pdp8startpage.html<http://www.pdp-11/nl/homebrew/pdp8/pdp8startpage.html%3chttp:/www.pdp-11/nl/homebrew/pdp8/pdp8startpage.html>>
It is a long story! From the start to a working emulation with lots of debug 
facilities (as found on HP64000 development systems). But this emulation runs 
the pdp8 diagnostics without errors.
Oops, typo.
Change /nl to .nl
www.pdp-11.nl/homebrew/pdp8/pdp8startpage.html<http://www.pdp-11.nl/homebrew/pdp8/pdp8startpage.html>

Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Ethan Dicks via cctalk]

On Wed, Feb 21, 2018 at 1:59 PM, Paul Koning via cctalk
 wrote:
> If microcode is not user-changeable, or if that capability is not a core 
> feature, then you can easily omit it.  That tends to make the job much 
> easier.  For example, I don't know that anyone emulates the PDP-11/60 WCS.  
> The absence of that emulation isn't a big deal, unless you want to run the 
> Richy Lary PDP-8 emulator on that emulated 11/60.  (Has it been preserved?)

I have long heard of the PDP-8 emulator that depends on the 11/60 WCS
but every time it comes up, it's always been said to be lost.

Feel free to prove me wrong, anyone.  I'd love to stare at it.

-ethan

Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Paul Koning via cctalk]

> On Feb 21, 2018, at 2:24 PM, Guy Sotomayor Jr  wrote:
> 
> 
> 
>> On Feb 21, 2018, at 10:59 AM, Paul Koning via cctalk  
>> wrote:
>> 
>> 
>> Caching doesn't change user-visible functionality, so I can't imagine 
>> wanting to emulate that.  The same goes for certain error handling.  I've 
>> seen an emulator that included support for bad parity and the instructions 
>> that control wrong-parity writing.  So you could run the diagnostic that 
>> handles memory parity errors.  But that's a pretty uncommon thing to do and 
>> I wouldn't bother.
> 
> I disagree, especially if you’re using an emulator for development.  Caching 
> is one of those things that can go
> horribly wrong and not having them emulated properly (or at all) can lead to 
> bugs/behaviors that are significantly
> different from real HW.  The same goes for error reporting/handling.  There 
> are cases where errors may be expected
> and not having them can cause the SW to behave differently.

Yes, there may be cases where errors are expected.  For example, out of range 
address errors, which are used by memory size probing.  But wrong-parity errors 
are far less likely.

I saw it emulated on Dick Gruene's EL-X8 emulator, and tested by the associated 
test program he wrote (which compared bare-metal execution of the test program 
with execution of that same program on the emulator, just like what Ray 
suggested).  There is a CWI report that describes this, its pretty neat.  But 
apart from testing the compleness of his understanding and the emulation of the 
"write wrong parity" instruction, it didn't really add anything useful to any 
other software.  No OS or application I have found depends on that capability, 
so our SIMH based emulator omits this and no harm is done by that omission.

>>> ...
> 
> However, it is my belief (and I think others have also stated) that assuming 
> infinitely fast I/O (e.g. no delays what so ever) can cause issues because in 
> many cases the SW expects to be able to do some work between the time that 
> the I/O is started and when it completes.

True, that is unfortunately a fairly common type of software bug.  And because 
it is, emulators have to work around those bugs.  I make it a point to call it 
a bug, though, because I don't want anyone to get the impression that OS 
programmers who wrote such things were doing the right thing.

paul

Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Guy Sotomayor Jr via cctalk]

> On Feb 21, 2018, at 10:59 AM, Paul Koning via cctalk  
> wrote:
> 
> 
> Caching doesn't change user-visible functionality, so I can't imagine wanting 
> to emulate that.  The same goes for certain error handling.  I've seen an 
> emulator that included support for bad parity and the instructions that 
> control wrong-parity writing.  So you could run the diagnostic that handles 
> memory parity errors.  But that's a pretty uncommon thing to do and I 
> wouldn't bother.

I disagree, especially if you’re using an emulator for development.  Caching is 
one of those things that can go
horribly wrong and not having them emulated properly (or at all) can lead to 
bugs/behaviors that are significantly
different from real HW.  The same goes for error reporting/handling.  There are 
cases where errors may be expected
and not having them can cause the SW to behave differently.

> 
>> There's a lot to consider.  The CPU(s), any co-processors, I/O
>> devices/busses, peripherals/terminals, etc.  Are you going to emulate
>> every co-processor in software, or is the system documented enough so
>> you can emulate just the protocols that the main CPU(s) use to talk to
>> those devices?  For example, many systems have some sort of storage
>> processors.  You could emulate everything 100% in software, but for that
>> you'd need disk and firmware dumps of everything.  Or, if the firmware
>> on those is fairly fixed, just emulate the functionality.
> 
> Typically you'd emulate the I/O device functionality, regardless of whether 
> that is implemented in gates or in co-processor firmware.  That's the 
> approach taken with the MSCP I/O device emulation in SIMH, or the disk 
> controller emulation in the CDC 6000 emulator DtCyber.  All those use 
> coprocessors, but the internals of those engines are much more obscure and 
> much less documented than the APIs of the I/O devices, and finding executable 
> code may also be very hard (never mind source code and assemblers).  For 
> example, I have only seen UDA50 firmware once, on a listing on a desk in CXO 
> back around 1981.

It’s also what’s done in Hercules (S/370, 370/XA, 390, Z simulator) and the 
mainframe I/O is complex to say the least.

However, it is my belief (and I think others have also stated) that assuming 
infinitely fast I/O (e.g. no delays what so ever) can cause issues because in 
many cases the SW expects to be able to do some work between the time that the 
I/O is started and when it completes.

TTFN - Guy

Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Paul Koning via cctalk]

> On Feb 21, 2018, at 11:19 AM, Ray Arachelian via cctalk 
>  wrote:
> 
> On 02/19/18 19:36, Adrian Stoness via cctalk wrote:
>> whats invovled in makin an emulator?
>> i have a chunk of stuff for the phillips p1000
> 
> Quite a lot actually.  A single CPU system is difficult enough, but a
> mainframe might be much, much harder.  The idea to use an existing
> emulator framework, such as SIMH, is a great one.
> 
> An easy implementation is to implement an interpretive CPU emulation at
> first, and then later on add other things such as JITs or caching.
> Does this machine implement microcode?  Do you want to emulate it all
> the way down to the microcode level?  Is microcode changeable by the
> OS/applications?  If not maybe implement the higher level (assuming
> CISC) CPU layer.

If microcode is not user-changeable, or if that capability is not a core 
feature, then you can easily omit it.  That tends to make the job much easier.  
For example, I don't know that anyone emulates the PDP-11/60 WCS.  The absence 
of that emulation isn't a big deal, unless you want to run the Richy Lary PDP-8 
emulator on that emulated 11/60.  (Has it been preserved?)

Caching doesn't change user-visible functionality, so I can't imagine wanting 
to emulate that.  The same goes for certain error handling.  I've seen an 
emulator that included support for bad parity and the instructions that control 
wrong-parity writing.  So you could run the diagnostic that handles memory 
parity errors.  But that's a pretty uncommon thing to do and I wouldn't bother.

> There's a lot to consider.  The CPU(s), any co-processors, I/O
> devices/busses, peripherals/terminals, etc.  Are you going to emulate
> every co-processor in software, or is the system documented enough so
> you can emulate just the protocols that the main CPU(s) use to talk to
> those devices?  For example, many systems have some sort of storage
> processors.  You could emulate everything 100% in software, but for that
> you'd need disk and firmware dumps of everything.  Or, if the firmware
> on those is fairly fixed, just emulate the functionality.

Typically you'd emulate the I/O device functionality, regardless of whether 
that is implemented in gates or in co-processor firmware.  That's the approach 
taken with the MSCP I/O device emulation in SIMH, or the disk controller 
emulation in the CDC 6000 emulator DtCyber.  All those use coprocessors, but 
the internals of those engines are much more obscure and much less documented 
than the APIs of the I/O devices, and finding executable code may also be very 
hard (never mind source code and assemblers).  For example, I have only seen 
UDA50 firmware once, on a listing on a desk in CXO back around 1981.

> .
> You'll need to fully understand all aspects of the hardware of that
> machine, every detail.  If you have schematics and can read them, they
> can be an absolute gold mine as documentation sometimes is vague, and
> looking at the schematics and resolve what actually happens.  If you
> have source code for an OS, that too can be a great resource to help
> understand what happens and how.

Exact emulation is ideal, but often not necessary.  What's required is 
emulation that delivers what the OS and drivers rely on.  Devices may have 
undocumented features, and bugs, that aren't touched by the software that you 
care about.  Just the documented features (from the programmer manuals) can 
often be sufficient, especially in well documented machines (DEC machines are 
examples of such, most of the time).  Sometimes you get surprised by some OS.  
RSTS/E occasionally pokes at strange internals, perhaps to complain about a 
missing ECO that needs to be installed for the OS to be happy.

> ...
> You'll have to implement more than 90% of a working emulator before
> you'll even be able to see progress and know you're on the right track,

Handwritten short test sequences are very helpful for this.  While you'll need 
90% or so for an OS to boot, you might need only 5% to test a few instructions 
entered via deposit commands.

paul

Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

[Eric Christopherson via cctalk]

On Wed, Feb 21, 2018 at 10:19 AM, Ray Arachelian via cctalk <
cctalk@classiccmp.org> wrote:

> On 02/19/18 19:36, Adrian Stoness via cctalk wrote:
> > whats invovled in makin an emulator?
> > i have a chunk of stuff for the phillips p1000
>
> Quite a lot actually.  A single CPU system is difficult enough, but a
> mainframe might be much, much harder.  The idea to use an existing
> emulator framework, such as SIMH, is a great one.
>

Ray, you've provided a few really excellent messages here.

[snip]

> Are you planning on emulating the whole machine, or just the userland?
> Might be easier to create a simulation of the OS in software on the host
> side the way that Executor did with MacOS - Cliff implemented his own
> version of MacOS 7.x, enough to be able to run most applications of that
> era, but not all.  see: https://github.com/ctm/executor.git and
> https://github.com/ctm/executor.git - some of this is called "High Level
> Emulation" and is sort of what WINE does (though wine isn't an emulator).
>

You put the same URL in twice there; did you intend for another URL?

I was quite a fan of Executor. It's cool to see that it's open source now.


> Be careful
> as there's a lot of "emu scene" folks out there with tons of free time,
> more than you might have, who will happily promise to help, but instead
> take your documentation, firmware, OS images, etc. and compete with you
> behind your back just to get there first, instead of actually helping
> you with your project.  On this latter point, I sadly speak from
> experience.
>

Wow, I didn't know about that. Good to know.

-- 
Eric Christopherson

Re: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

[Ray Arachelian via cctalk]

On 02/21/18 09:41, Paul Koning via cctalk wrote:
>
> SIMH in principle allows the writing of cycle-accurate CPU simulators, but I 
> don't believe anyone has bothered.  It's hard to see why that would be all 
> that interesting.  For some CPUs, the full definition of how long 
> instructions take is extremely complex.  Take a look at the instruction 
> timing appendix in a PDP-11 processor handbook, for example; there are dozens 
> of possibilities even for simple instructions like MOV, and things get more 
> interesting still on machines that have caches.
It's not really that hard to get cycle accurate counts (well, outside of
things like caching), typically you wouldn't emulate a CPU by doing a
big giant case statement, rather, you'd do something that has a lot of
in memory tables, and your instruction decode process will use those to
pick a pointer to a function call.  One of those fields in that big
array can be a set of cycles based on which kind of opcode and what its
operands are.  And then the function at the end of that function pointer
would update a global variable called maybe cycle_count with that
value.  It won't be perfect, but it will be close enough for most
situations, even those that track the position of a raster beam on a CRT
(which isn't likely to be the case in this particular thread.)

You'd also likely have some main loop that executes a certain number of
cycles - that's say linked to one frame of a CRT - to continue down that
metaphor (and marks any overflow which is subtracted from the next
frame), then allows other things to run, and then returns back to the
CPU.  So you'd also update the virtual clock based on CPU cycles and set
a throttle that limits the CPU to a certain MHz.  After a few of these
frames, you'd reach homeostasis and your emulator will run very close to
a machine of that MHz.  Usually you'll want the frames to be some
fraction of a second, in the CRT example 60Hz is ok, but maybe on a
mainframe, I don't know, maybe 1/100th of a second is better, etc.

It will likely never be perfectly cycle accurate without a ton of work,
but you only need that for video games where the CPU is used to draw on
a moving raster beam CRT, anyway.

Now, you don't want to run your emulated guest CPU(s) at full speed on
the host machine, because you'll overheat it, and typically, it'll run a
multi-process OS anyway and you don't want to starve the GUI, network
stack, and daemons of CPU cycles, so once you reach your goal MHz in
your guest CPU, you'd sleep and yield to the host OS for a bit, or maybe
do some background stuff like see if any I/Os or IRQs are pending (such
as maybe a keystroke from the user, or an incoming network packet, or
maybe the disk sector or tape sector your guest OS requested has
arrived), and handle those.

RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

[Dave Wade via cctalk]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Paul
> Koning via cctalk
> Sent: 21 February 2018 14:41
> To: Sean Conner <s...@conman.org>; General Discussion: On-Topic and Off-
> Topic Posts <cctalk@classiccmp.org>
> Subject: Re: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]
> 
> 
> 
> > On Feb 20, 2018, at 8:18 PM, Sean Conner via cctalk
> <cctalk@classiccmp.org> wrote:
> >
> > It was thus said that the Great Eric Christopherson via cctalk once
stated:
> >> On Tue, Feb 20, 2018 at 5:30 PM, dwight via cctalk
> >> <cctalk@classiccmp.org>
> >> wrote:
> >>
> >>> In order to connect to the outside world, you need a way to queue
> >>> event based on cycle counts, execution of particular address or
> >>> particular instructions. This allows you to connect to the outside
> >>> world. Other than that it is just looking up instructions in an
instruction
> table.
> >>>
> >>> Dwight
> >>>
> >>
> >> What I've always wondered about was how the heck cycle-accurate
> >> emulation is done. In the past I've always felt overwhelmed looking
> >> in the sources of emulators like that to see how they do it, but
> >> maybe it's time I tried again.
> >
> >  It depends upon how cycle accurate you want.  My own MC6809 emulator
> > [1] keeps track of cycles on a per-instruction basis, so it's easy to
> > figure out how many cycles have passed.
> 
> SIMH in principle allows the writing of cycle-accurate CPU simulators, but
I
> don't believe anyone has bothered.  It's hard to see why that would be all
> that interesting.  For some CPUs, the full definition of how long
instructions
> take is extremely complex.  Take a look at the instruction timing appendix
in a
> PDP-11 processor handbook, for example; there are dozens of possibilities
> even for simple instructions like MOV, and things get more interesting
still on
> machines that have caches.
> 

For early machines like the Manchester baby AKA the SSEM and the Ferranti
Pegasus its almost essential.
Many of programs for these early machines rely on cycle times to produce
predictable delays.
So the SSEM noodle timer only works because the machine runs at 110Khz..

> Another consideration is that you don't get accurate system timing unless
the
> whole system, not just the CPU emulation, is cycle-accurate.  And while
> there is roughly-accurate simulation of DECtape in SIMH (presumably for
> TOPS-10 overlapped seek to work?) in general it is somewhere between
> impractical and impossible to accurately model the timing of moving media
> storage devices.  You'd have to deal not just with seek timing but with
the
> current sector position -- yes, I can imagine how in theory that would be
> done but it would be amazingly hard, and for what purpose?
> 
> If you have a machine with just trivial I/O devices like a serial port or
a
> typewriter, then things get a bit more manageable.
> 
> SIMH certainly has event queueing to deal with I/O.  For correctly written
> operating systems that is extremely non-critical; if an I/O completes in a
few
> cycles the OS doesn't care, it just has a fast I/O device.  Poorly written
> operating systems may have unstated dependencies on interrupts occurring
> "slow enough".  So a common practice is for the CPU emulation just to
count
> instructions (not cycles or nanoseconds) and for the I/O events to be
> scheduled in terms of a nominal delay expressed in average instruction
> times.  I haven't yet run into trouble with that (but then again, I've
been
> working with well-built operating systems).
> 
>   paul
> 

Davd

Re: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

[Adrian Stoness via cctalk]

interesting

Re: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

[Sean Conner via cctalk]

It was thus said that the Great Eric Christopherson via cctalk once stated:
> On Tue, Feb 20, 2018 at 5:30 PM, dwight via cctalk 
> wrote:
> 
> > In order to connect to the outside world, you need a way to queue event
> > based on cycle counts, execution of particular address or particular
> > instructions. This allows you to connect to the outside world. Other than
> > that it is just looking up instructions in an instruction table.
> >
> > Dwight
> >
> 
> What I've always wondered about was how the heck cycle-accurate emulation
> is done. In the past I've always felt overwhelmed looking in the sources of
> emulators like that to see how they do it, but maybe it's time I tried
> again.

  It depends upon how cycle accurate you want.  My own MC6809 emulator [1]
keeps track of cycles on a per-instruction basis, so it's easy to figure out
how many cycles have passed.  Hardware emulation can be done between
instructions by updating per the number of cycles passed (if required).  I
don't have the code for the MC6840 (a timer chip) in my MC6809 emulator
repository (it's still somewhat under construction) but I do update the
timer based upon the elapsed cycle count of the previous instruction [2].

  -spc (Code available upon request if you want to look at it)

[1] https://github.com/spc476/mc6809

[2] It's not emulating any existing machine.  Rather, I'm emulating a
system with a few serial ports (MC6850) and a few timer chips
(MC6840).  I have plans on adding a few floppy controllers (MC6843)
and a DMA chip (6844).

Re: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

[Charles Anthony via cctalk]

On Tue, Feb 20, 2018 at 4:01 PM, Eric Christopherson via cctalk <
cctalk@classiccmp.org> wrote:

> On Tue, Feb 20, 2018 at 5:30 PM, dwight via cctalk 
> wrote:
>
> > In order to connect to the outside world, you need a way to queue event
> > based on cycle counts, execution of particular address or particular
> > instructions. This allows you to connect to the outside world. Other than
> > that it is just looking up instructions in an instruction table.
> >
> > Dwight
> >
>
> What I've always wondered about was how the heck cycle-accurate emulation
> is done. In the past I've always felt overwhelmed looking in the sources of
> emulators like that to see how they do it, but maybe it's time I tried
> again.
>
>
An emulator does not necessarily need to be cycle accurate. Some
architectures have overlapping instruction execution, memory caches, I/O
memory contention --  calculating cycles can be very complex. Other
architectures, such as the DPS8/M do not seem to have left any
documentation about cycle timing. The dps8/m emulator is coded for
performance, not timing accuracy.

-- Charles

Re: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

[Eric Christopherson via cctalk]

On Tue, Feb 20, 2018 at 5:30 PM, dwight via cctalk <cctalk@classiccmp.org>
wrote:

> In order to connect to the outside world, you need a way to queue event
> based on cycle counts, execution of particular address or particular
> instructions. This allows you to connect to the outside world. Other than
> that it is just looking up instructions in an instruction table.
>
> Dwight
>

What I've always wondered about was how the heck cycle-accurate emulation
is done. In the past I've always felt overwhelmed looking in the sources of
emulators like that to see how they do it, but maybe it's time I tried
again.

Another more-complex thing done by some emulators is compiling, on the fly,
a series of emulated machine instructions into native host machine code, to
boost performance. That's also what the Java virtual machine does.


>
>
> 
> From: cctalk <cctalk-boun...@classiccmp.org> on behalf of Pontus Pihlgren
> via cctalk <cctalk@classiccmp.org>
> Sent: Tuesday, February 20, 2018 11:22:32 AM
> To: Adrian Stoness; General Discussion: On-Topic and Off-Topic Posts
> Subject: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]
>
> On Mon, Feb 19, 2018 at 06:36:13PM -0600, Adrian Stoness via cctalk wrote:
> > whats invovled in makin an emulator?
> > i have a chunk of stuff for the phillips p1000
>
> I would say it depends a lot on how complex your target machine is. But
> in essense you will have to write code for each device you wish to
> emulate mapping their functionality over to your host machine, the one
> running the emulator.
>
> As a minimum you will write code for the CPU and some sort of output
> device, such as a serial console. For some machines you might need
> images of ROM code in order to be fully compatible with existing
> software.
>
> I wrote a PDP-8 emulator for fun. The basic CPU and serial was done in a
> few hours. I then hardcoded the paper tape loader in memory and allowed
> input to be read from an image file.
>
> Adding extended memory support and running conformance tests has taken
> the bulk of the time.
>
> /P
>



-- 
Eric Christopherson

Re: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

[dwight via cctalk]

In order to connect to the outside world, you need a way to queue event based 
on cycle counts, execution of particular address or particular instructions. 
This allows you to connect to the outside world. Other than that it is just 
looking up instructions in an instruction table.

Dwight



From: cctalk <cctalk-boun...@classiccmp.org> on behalf of Pontus Pihlgren via 
cctalk <cctalk@classiccmp.org>
Sent: Tuesday, February 20, 2018 11:22:32 AM
To: Adrian Stoness; General Discussion: On-Topic and Off-Topic Posts
Subject: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

On Mon, Feb 19, 2018 at 06:36:13PM -0600, Adrian Stoness via cctalk wrote:
> whats invovled in makin an emulator?
> i have a chunk of stuff for the phillips p1000

I would say it depends a lot on how complex your target machine is. But
in essense you will have to write code for each device you wish to
emulate mapping their functionality over to your host machine, the one
running the emulator.

As a minimum you will write code for the CPU and some sort of output
device, such as a serial console. For some machines you might need
images of ROM code in order to be fully compatible with existing
software.

I wrote a PDP-8 emulator for fun. The basic CPU and serial was done in a
few hours. I then hardcoded the paper tape loader in memory and allowed
input to be read from an image file.

Adding extended memory support and running conformance tests has taken
the bulk of the time.

/P

Re: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

[Paul Koning via cctalk]

> On Feb 20, 2018, at 2:22 PM, Pontus Pihlgren via cctalk 
>  wrote:
> 
> On Mon, Feb 19, 2018 at 06:36:13PM -0600, Adrian Stoness via cctalk wrote:
>> whats invovled in makin an emulator?
>> i have a chunk of stuff for the phillips p1000
> 
> I would say it depends a lot on how complex your target machine is. But 
> in essense you will have to write code for each device you wish to 
> emulate mapping their functionality over to your host machine, the one 
> running the emulator.
> 
> As a minimum you will write code for the CPU and some sort of output 
> device, such as a serial console. 

I would add: unless you have a very strange situation (which is unlikely with a 
Philips machine), SIMH is the foundation to use.  There are other simulators 
out there built on other foundations, and they work fine.  But SIMH has an 
excellent structure and takes care of a whole lot of work, allowing you to 
concentrate on the actual technical substance of emulating a specific machine.

paul