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: Seeking RL02K cartridge

[Aaron Jackson via cctalk]

> > I am wondering if anyone would be willing to sell me an RL02K cartridge
> > for a sensible price?
>
> There are a bunch listed on eBait for not wholly unrealistic prices; I
> wouldn't buy a bunch there, but it you only need one, for testing... Not sure
> if any of the ones for sale there are the moment are in the UK, though. (I
> recall some a few months ago, so it's not impossible, and worth a check.)
>
>   Noel

Hi Noel,

I ended up ordering an RL02K-DC today from Lightning Systems in the
UK. I've bought stuff from them before, not overly expensive, but not
overly cheap either. At least I know that it has been tested and works.

I just *really* hope nothing goes wrong when I load it. If it does, I
will give up on RL02 completely. I don't want to be responsible for
crashing another pack, so this will be my last attempt. Given that I am
able to load a clean pack without any bad noises, just not able to read
it because of lost servo data on the first track, I think it might be
okay. I hope...

Thanks,
Aaron.

Re: Seeking RL02K cartridge

[Noel Chiappa via cctalk]

> From: Aaron Jackson

> I am wondering if anyone would be willing to sell me an RL02K cartridge
> for a sensible price?

There are a bunch listed on eBait for not wholly unrealistic prices; I
wouldn't buy a bunch there, but it you only need one, for testing... Not sure
if any of the ones for sale there are the moment are in the UK, though. (I
recall some a few months ago, so it's not impossible, and worth a check.)

Noel

Re: Why don't you respect the mail threads?!

[Grant Taylor via cctalk]

On 02/21/2018 03:50 PM, Noel Chiappa via cctalk wrote:

That's me, I expect.


I'm not naming any names.

I have sent an email to the person directly with a polite inquiry.  I 
see no point in pointing fingers.


I used to use a TOPS-20 email reader called MM, and when I moved my 
email to a Unix machine, there was a version of MM I used there, then 
something happened (I forget what) and I couldn't use that any more.


Intriguing.

I find it amazing the number of things that I can learn by reading TUHS 
and CCTalk.


Granted, I do miss some things when threads I'm ignoring fork without 
actually starting threads.  Oops!


I do have access to a more modern email reader (Eudora), but don't like 
it; I just stick with old, simple stuff I know how to use. I don't have 
the spare brain cells / energy to switch.


I think that everybody should have the option to choose what ever 
software / hardware they want to use.  If you want to flip switches on 
the front of an Altair to ""type an email, after reading 5-bit punched 
paper tape, then by all means, more power to you.


Read:  I know how I would react if someone told me how I should do 
something, so far be it for me to try to tell someone else how they 
should do something.


That being said, I may inquire how / why someone is doing something, 
along with what prompted me to ask the question.  -  My intention is to 
(hopefully) alleviate my ignorance of a situation and to make the other 
party aware of something.  -  What said other party does with said 
information is /their/ prerogative.


After going through I've-forgotten-how-many editors (starting with TECO, 
then 'ed'), text formatting systems, operating systems, email readers, 
etc, etc I have a very simple rule about switching software: is the old 
stuff I'm using utterly, irretrievably unusable? If not, ignore the new 
stuff. Eventually it'll be obsolete too. And in the meantime, I'll have 
saved countless cycles by not going through the hassle of switching to 
it. Life's too short.


I see the logic in what you're saying.

If it works for you….  Far be it for me….



--
Grant. . . .
unix || die

Re: Why don't you respect the mail threads?!

[Noel Chiappa via cctalk]

> From: Grant Taylor

> I'm on a list where it seems as if a frequent contributer uses an MUA
> that does not send In-Reply-To or References headers at all. It doesn't
> even send a User-Agent header. *sigh*

That's me, I expect.

I used to use a TOPS-20 email reader called MM, and when I moved my email to a
Unix machine, there was a version of MM I used there, then something happened
(I forget what) and I couldn't use that any more.

I do have access to a more modern email reader (Eudora), but don't like it; I
just stick with old, simple stuff I know how to use. I don't have the spare
brain cells / energy to switch.

After going through I've-forgotten-how-many editors (starting with TECO, then
'ed'), text formatting systems, operating systems, email readers, etc, etc I
have a _very_ simple rule about switching software: is the old stuff I'm using
utterly, irretrievably unusable? If not, ignore the new stuff. Eventually
it'll be obsolete too. And in the meantime, I'll have saved countless cycles
by not going through the hassle of switching to it. Life's too short.

Noel

Re: Why don't you respect the mail threads?!

[Grant Taylor via cctalk]

On 02/21/2018 02:05 PM, Fred Cisin via cctalk wrote:

Not likely to be related to Oumuamua


Well….  Not exactly.

I could see how a loose connection could be made.

Mail User Agents are often used to reach out and make first contact with 
people.


I could see how a new MUA could justify using the name ʻOmuamua. 
(Including the ʻOkina.)




--
Grant. . . .
unix || die

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: VCF PNW 2018: Pictures!

[Charles Anthony via cctalk]

On Wed, Feb 21, 2018 at 4:28 AM, Philipp Hachtmann via cctalk <
cctalk@classiccmp.org> wrote:

>
> On 19.02.2018 02:52, Zane Healy via cctalk wrote:
>
>> What do they have up there for Honeywell?
>>
>
> I was looking through the pics and saw - nothing... But I also would be
> VERY interested about if and what Honeywell stuff they have.
>
> A search through the LCM+L online catalog shows:

  Honeywell 58 minicomputer
  6180 maintenance panel
  Various tape and disk drives
  Xerox Sigma 9 w/Honeywell serial number stickers

http://opac.libraryworld.com/opac/advanced.php

Googling the '58':
  http://www.feb-patrimoine.com/histoire/english/chronoa6.htm
  "12 Sep 1971 First shipment of model 58, a derivative of GE-55"

Apparently a http://www.technikum29.de/en/computer/gamma55.

-- Charles

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
Verzonden: woensdag 21 februari 2018 20:11
Aan: 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: qd32 trouble

[Jay Jaeger via cctalk]

I *might* be able to help, *if* you also have a MicroVax you can plug
this controller into - eventually (months).  I have a pair of MicroVaxen
with Emulex QD32 SMD controllers in my collection.  (My inventory shows
them as QD325, but I expect that is a misnomer; my notes indicate QD32).

With those machines I also got an Emulex Diagnostic tape, VX9962004 Rev
J.  My notes indicate it has these diagnostics:

FQD01M MSCP Formatter:  QD01, QD32, SC03
FVD03M: UCxx Host Adapter Format
FVD32M MSCP Formatter: QD01, QD32, SC41, SC03
IQC02: DHV11 Option of CS02/H Diagnostic
IQT12: TS11 Compatible QT12/TC03 Diagnostic
IVC23E: CS23/CS04 Diagnostic

I have not used that tape in several years, though, I don't seem to have
made an image of that tape at this point (shame on me).  (Now on my ToDo
list - but it will probably be a couple of months).

On 2/20/2018 5:49 PM, Jacob Ritorto via cctalk wrote:
> Hi all,
>   Would anyone here be able to help me troubleshoot my qd32 controller?  I
> have a pdp11/73 that's mostly working, boots 2.11bsd from rl02 okay, but I
> need my big disk to work so I can load the rest of the distro.
>   I've been following the manual for the qd32 to enter the geometry of my
> real working Fuji m2333 (jumpered correctly according to the manuals), but
> when I load the special command into the qd32's SP register that's supposed
> to load the geometry table I entered in pdp11 memory to the qd32's novram,
> I get a bad status value from the qd32's SP register and it remains
> unresponsive when I try to store the geometry.  If I go ahead and try the
> built-in qd32 format command, it responds similarly.  When I pull in mkfs
> from tape (vtserver) and try anyway, despite the failures, to run mkfs on
> the m2333, I get an !online error from the standalone unix mkfs.  The disk
> does respond (the select light flashes and I can hear heads actuating), but
> without geometry and format, I'm obviously dead in the water.
> 
>   I understand that there used to exist some Emulex qd32/pdp11 diagnostics
> that could help the situation, but my previous attempts to find copies have
> come up short.
> 
>   Any suggestions on how to proceed?
> 
> thx
> jake
> 

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: Why don't you respect the mail threads?!

[Fred Cisin via cctalk]

mua?


Mail User Agent
I.e. email client.


Not likely to be related to Oumuamua

Re: VCF PNW 2018: Pictures!

[Charles Anthony via cctalk]

On Wed, Feb 21, 2018 at 6:45 AM, Zane Healy via cctalk <
cctalk@classiccmp.org> wrote:

>
> > On Feb 19, 2018, at 6:51 AM, Noel Chiappa via cctalk <
> cctalk@classiccmp.org> wrote:
>
> Really the H6180 looks a lot more like the DPS-8 I remember.  We had a
> single CPU Dev system, and a 4 CPU Production system running GCOS-8.  I
> thought I might have some drawings of the panels, but if I do they’re in
> the garage somewhere.  Another site, had a DPS-8000, our site was pretty
> old, and had been upgraded over time.  For example the memory cabinets were
> mostly empty, due to upgrades.
>
>
The DPS8 and DPS8/M did away with the blinking light panels. However, it
was possible to mix 6080 and DPS8 CPUs in a system; you may be remembering
a 6080 that was the original CPU in a system that had acquired DPS8 CPU and
SCU upgrades?

-- 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
Verzonden: woensdag 21 februari 2018 20:44
Aan: Paul Koning; General Discussion: On-Topic 
and Off-Topic Posts
Onderwerp: Re: Writing emulators (was Re: VCF PNW 2018: Pictures!)

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

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
Verzonden: woensdag 21 februari 2018 20:37
Aan: Guy Sotomayor Jr
CC: General Discussion: On-Topic and Off-Topic 
Posts
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
> Verzonden: woensdag 21 februari 2018 20:37
> Aan: Guy Sotomayor Jr
> CC: General Discussion: On-Topic and Off-Topic 
> Posts
> 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
Verzonden: woensdag 21 februari 2018 21:15
Aan: Henk Gooijen; General Discussion: 
On-Topic and Off-Topic Posts
CC: Paul Koning
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
> Verzonden: woensdag 21 februari 2018 20:37
> Aan: Guy Sotomayor Jr
> CC: General Discussion: On-Topic and Off-Topic 
> Posts
> 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
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
Verzonden: woensdag 21 februari 2018 21:20
Aan: Pontus Pihlgren; General Discussion: On-Topic 
and Off-Topic Posts
Onderwerp: RE: Writing emulators (was Re: VCF PNW 2018: Pictures!)



Van: Pontus Pihlgren
Verzonden: woensdag 21 februari 2018 21:15
Aan: Henk Gooijen; General Discussion: 
On-Topic and Off-Topic Posts
CC: Paul Koning
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
> Verzonden: woensdag 21 februari 2018 20:37
> Aan: Guy Sotomayor Jr
> CC: General Discussion: On-Topic and Off-Topic 
> Posts
> 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>
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

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: Why don't you respect the mail threads?!

[Adrian Stoness via cctalk]

because its not something i think of when asking a question

On Wed, Feb 21, 2018 at 6:26 AM, Philipp Hachtmann via cctalk <
cctalk@classiccmp.org> wrote:

> I have to say that I hate this email thread abuse so much...!
> Is it so difficult to leave the thread about PICTURES (fill in whatever
> topic it was about) intact? It would be so much better to start a new
> thread instead:
>
> - Does not disturb original discussion.
> - Can be found and identified easily: Do you think that you will find the
>  easily in a few years if it's
> discussed under the caption "VCF PNW 2018: Picture!"?
>
> And on the other hand there are those people who seem to be unable to
> create a prober reply to the list and therefore make threads appear
> scattered and broken into many many pieces...
>
> Sorry for ranting, but I enjoyed the pictures and following discussion so
> much and now encountering that dumb emulator discussion in this place
> annoys me so much...!
> And yes, I know that I sent this message as a reply to another message.
>
> Kind regards
>
> Philipp
>
> On 19.02.2018 15:44, geneb via cctalk wrote:
>
>> On Sun, 18 Feb 2018, Zane Healy via cctalk wrote:
>>
>> What do they have up there for Honeywell?  Any DPS-8’s?  I know they
>>> should have at least a box of GCOS-8 manuals (in hindsight, the only
>>> manuals I regret sending up there).
>>>
>>
>> Zane, they've got a DPS-8 maintenance/operator/? panel sitting right out
>> front.  It's fully operational and is connected via some magic hardware to
>> a Raspberry Pi running a Multics emulator. The guy that wrote the emulator
>> gave a talk that should be the first one you watch once Erik has a chance
>> to get the video posted.
>>
>
>

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: Why don't you respect the mail threads?!

[Grant Taylor via cctalk]

On 02/21/2018 11:06 AM, Adrian Stoness wrote:

mua?


Mail User Agent

I.e. email client.



--
Grant. . . .
unix || die

Re: Why don't you respect the mail threads?!

[Adrian Stoness via cctalk]

mua?



On Wed, Feb 21, 2018 at 10:45 AM, Grant Taylor via cctalk <
cctalk@classiccmp.org> wrote:

> On 02/21/2018 05:26 AM, Philipp Hachtmann via cctalk wrote:
>
>> I have to say that I hate this email thread abuse so much...!
>>
>
> ;-)
>
> Is it so difficult to leave the thread about PICTURES (fill in whatever
>> topic it was about) intact?
>>
>
> I suspect it's either people that don't know they are breaking threading
> or MUAs that behave badly.
>
> I'm on a list where it seems as if a frequent contributer uses an MUA that
> does not send In-Reply-To or References headers at all.  It doesn't even
> send a User-Agent header.  *sigh*
>
> And on the other hand there are those people who seem to be unable to
>> create a prober reply to the list and therefore make threads appear
>> scattered and broken into many many pieces...
>>
>
> I've taken to leveraging Mutt's ability to "link-threads" (&) and
> "break-thread" (#) to ""fix things and make the thread appear like I want
> in Thunderbird.
>
> And yes, I know that I sent this message as a reply to another message.
>>
>
> I think your reply is in direct response to the message that it is
> replying to.  So … I think you're on the lighter side of gray here.  :-)
>
>
>
>
> --
> Grant. . . .
> unix || die
>

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: VCF PNW 2018: Pictures!

[Ray Arachelian via cctalk]

On 02/21/18 08:16, Peter Corlett via cctalk wrote:
>
> A programmer of modest ability should be able to knock up a simple
> switch()-based step-by-step CPU emulation in a few hours. This is analogous to
> a simple microcoded CPU and the performance will suck.
Yeah, please don't code this way.  Big huge case statements really suck.

Build a function that can decode opcodes and then dispatches to an array
of functions via pointers instead.
Build tables in the emulator that both help the opcode decoder (and
accelerate it), and also have fields in it that hold opcode cycle
timings, opcode sizes (so you can increment the IR - instruction
Register/Program Counter by the size of the opcode).

You could also cache the results of the opcode decoder, but you'll need
to do a bunch of memory management for that, and detect when a certain
place in memory has been overwritten with new code.
However, this can yield very useful information if you also add a bunch
of extra fields to your instruction cache such as what register values
were used before, what CPU cycle the last time it ran, whether that
opcode accessed I/O or RAM, what MMU context it was in, etc.

These extra bits of recoded "flight data" are gold when debugging or
reverse engineering the running OS/apps later.  For example on CPUs
which access I/O via memory space, if you see a MOVE to a register in a
disassembly, you don't really know what it's doing unless you see the
value in that register at the time it ran, and then you can think, Aha! 
0xfc0020 - that's this I/O register on this specific device here on this
bus, so it can help you locate I/O drivers in the kernel.

Now, you can also do something else that's interesting, if you reverse
engineer the driver a bit and find it's entry and exit points, basically
how it's called, and what it returns, you can trap that in your
emulator, so when your emulator's CPU calls that block of code, you
don't execute that native code, and rather, do whatever that driver does
natively and return the right values on the stack/registers/target
memory/etc.  And this can speed up your emulator quite a bit.  i.e. say
you have some code that loads a file from disk. Rather than emulating
several thousand opcodes, you can replace the whole thing with a block
read from a file and return back to the caller and skip all the
bit-banging.  (But do update the CPU cycle count).

If say, the firmware insists on checking the RAM by writing thousands of
different patterns over many megs of memory, you can detect that in your
emulator and skip it.  No need to make the user wait 5 minutes for the
machine to warm up.  Speed up the boot process.  (Well you can make
these things optional "hacks" that the user can enable or disable.)

> Making it *cycle-accurate* involves deep understanding of the emulated CPU's
> internal architecture. If part of the platform requires cycle-accurate timing
> for bit-banging some hardware device, you're going to need this.
Hopefully this is already documented, if not, having schematics might
help here, but would need lots of work.  (Assuming a multi IC CPU as
opposed to discrete CPU which would likely have great docs already.)

>
> Making it *fast* also involves being an expert in compiler backends for the
> target architecture, because this requires decompiling and then recompiling 
> the
> code on the fly.
>
> ... and that's the easy bit. Now you get to emulate the hardware.
>
>
Yeah, it's a huge job, but I think in the end, it's totally worth it. 
Just takes a lot of commitment and free time, and a love for the machine
you're trying to emulate.

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: Why don't you respect the mail threads?!

[Grant Taylor via cctalk]

On 02/21/2018 05:26 AM, Philipp Hachtmann via cctalk wrote:

I have to say that I hate this email thread abuse so much...!


;-)

Is it so difficult to leave the thread about PICTURES (fill in whatever 
topic it was about) intact?


I suspect it's either people that don't know they are breaking threading 
or MUAs that behave badly.


I'm on a list where it seems as if a frequent contributer uses an MUA 
that does not send In-Reply-To or References headers at all.  It doesn't 
even send a User-Agent header.  *sigh*


And on the other hand there are those people who seem to be unable to 
create a prober reply to the list and therefore make threads appear 
scattered and broken into many many pieces...


I've taken to leveraging Mutt's ability to "link-threads" (&) and 
"break-thread" (#) to ""fix things and make the thread appear like I 
want in Thunderbird.



And yes, I know that I sent this message as a reply to another message.


I think your reply is in direct response to the message that it is 
replying to.  So … I think you're on the lighter side of gray here.  :-)




--
Grant. . . .
unix || die

Re: Why don't you respect the mail threads?!

[Grant Taylor via cctalk]

On 02/21/2018 08:57 AM, Tapley, Mark via cctalk wrote:
I was one of the offenders. A list member politely pointed out to me 
(in private mail) the existence of the of the in-reply-to header which my 
client isn’t set to use. I had no idea! I’d been diligently changing 
subject: headers when I hijacked threads, but to no avail. So, apologies 
for my past bad behavior and I’ll try to do better in the future.


Thank you for your efforts Tapley.  :-)

We all have to strive to play well with others.  -  I think that was on 
one of my report cards decades ago.


I would encourage you though, rather than give up, just politely be more 
explicit about what is needed - it was ignorance rather than laziness 
in my case which was the problem.


Hanlon's razor - Never attribute to malice that which is adequately 
explained by ignorance.


IMHO ignorance can be addressed with polite constructive feedback.

Willful ignorance … well that's a different story.  And it might not be 
ignorance when it becomes willful.




--
Grant. . . .
unix || die

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

[Ray Arachelian via cctalk]

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.

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.

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'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.

In terms of I/O. you'll be writing the reverse of what a driver will do
- so if you have docs on how to write drivers for that machine, you're
going to implement the hardware itself, in software, to match or connect
to drivers on the system.

Sometimes timing matters, sometimes it doesn't.  Where it doesn't, you
have the opportunity to improve execution speed by running at full speed
on the host.

You'll have to do lots of experimenting.  Queues tagged with future
events (i.e. at CPU_CYCLES+ONE_TENTH_THOUSANDTH_OF_A_SECOND, trigger IRQ
# 3 ), are a good way to go, or you could go the hard way and implement
a multi-process/thread emulator.

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,
because more than likely you won't get far enough to get anything
starting to boot until that point.  Once you get there, you should
implement a debugger for yourself and write trace log mechanisms
throughout your code so you can turn on tracing at specific points to
see what your code is doing, then sit there and read megs and megs of
those logs until you figure out where it's going wrong vs actual hardware.

If it's possible to write a CPU tester (and device testers) on the real
thing, do that.  Run every CPU instruction through various edge cases,
look at the resulting status flags and log all registers in/out to a
database.  (This will easily be multi-gigabyte output).
For example. say you have a shift instruction on a 16 bit word.  What
happens when the register is 32 bits, and the carry flags are set and
you do a shift left by 18 times?  Yes, that doesn't make sense, I know. 
But an intel chip and 68000, and a SPARC, and a PPC, and ARM chip and a
POWER4 chip all produce totallly different results with such inputs, so
you can't assume it will just be handled by your host's CPU without a
lot of extra work.

And your emulator, if it's designed to be portable, must implement all
those weird edge cases.  And if you don't implement a portable emulator,
if it only runs on a current OS with a current chip, it will soon be
obsolete in a few years

After you've built your test suite, run your emulated CPU against this
test frame, and flag any results that differ from what the physical
hardware generated.  Repeat that process with device hardware such as
tape drives, disk drives, etc.  Likely terminal emulation won't be too
hard if standard stuff like vt100 are supported as you can use existing
terminal emulators.  But other stuff will be hard.  Some, really, really
hard.  Other things will be easy.

Hopefully the documentation you have is complete enough to write a full
OS from scratch on that machine, if it isn't, then you may have to do a
lot of black box reverse engineering which is only possible if you have
access to working hardware and lots of time.

Re: Why don't you respect the mail threads?!

[Tapley, Mark via cctalk]

On Feb 21, 2018, at 9:39 AM, Pontus Pihlgren via cctalk  
wrote:

> Which part is it that bothers you? That the subject is not changed 
> (which I did) or that the In-Reply-To: header is preserved which 
> mucks up threading in my client.
> 
> anyway, this has been up for discussion before with little 
> improvements..so I have given up and accept status quo.

I was one of the offenders. A list member politely pointed out to me 
(in private mail) the existence of the of the in-reply-to header which my 
client isn’t set to use. I had no idea! I’d been diligently changing subject: 
headers when I hijacked threads, but to no avail. So, apologies for my past bad 
behavior and I’ll try to do better in the future. 

I would encourage you though, rather than give up, just politely be 
more explicit about what is needed - it was ignorance rather than laziness in 
my case which was the problem.

- Mark

Re: Why don't you respect the mail threads?!

[Pontus Pihlgren via cctalk]

Which part is it that bothers you? That the subject is not changed 
(which I did) or that the In-Reply-To: header is preserved which 
mucks up threading in my client.

anyway, this has been up for discussion before with little 
improvements..so I have given up and accept status quo.

/P

P.S. sorry if my emulator mail was booring. D.S.

On Wed, Feb 21, 2018 at 01:26:57PM +0100, Philipp Hachtmann via cctalk wrote:
> I have to say that I hate this email thread abuse so much...!
> Is it so difficult to leave the thread about PICTURES (fill in whatever
> topic it was about) intact? It would be so much better to start a new
> thread instead:
> 
> - Does not disturb original discussion.
> - Can be found and identified easily: Do you think that you will find the
>  easily in a few years if it's
> discussed under the caption "VCF PNW 2018: Picture!"?
> 
> And on the other hand there are those people who seem to be unable to
> create a prober reply to the list and therefore make threads appear
> scattered and broken into many many pieces...
> 
> Sorry for ranting, but I enjoyed the pictures and following discussion so
> much and now encountering that dumb emulator discussion in this place
> annoys me so much...!
> And yes, I know that I sent this message as a reply to another message.
> 
> Kind regards
> 
> Philipp
> 
> On 19.02.2018 15:44, geneb via cctalk wrote:
> >On Sun, 18 Feb 2018, Zane Healy via cctalk wrote:
> >
> >>What do they have up there for Honeywell?  Any DPS-8’s?  I know they
> >>should have at least a box of GCOS-8 manuals (in hindsight, the only
> >>manuals I regret sending up there).
> >
> >Zane, they've got a DPS-8 maintenance/operator/? panel sitting right out
> >front.  It's fully operational and is connected via some magic hardware
> >to a Raspberry Pi running a Multics emulator. The guy that wrote the
> >emulator gave a talk that should be the first one you watch once Erik has
> >a chance to get the video posted.
> 

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 ; General Discussion: On-Topic and Off-
> Topic Posts 
> Subject: Re: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]
> 
> 
> 
> > On Feb 20, 2018, at 8:18 PM, Sean Conner via cctalk
>  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
> >> 
> >> 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: VCF PNW 2018: Pictures!

[Zane Healy via cctalk]

> On Feb 19, 2018, at 6:51 AM, Noel Chiappa via cctalk  
> wrote:
> 
>> From: geneb
> 
>> they've got a DPS-8 maintenance/operator/? panel ... It's fully
>> operational and is connected via some magic hardware to a Raspberry Pi
>> running a Multics emulator.
> 
> Technically it's an H6180; the DPS-8 is a later generation of hardware in the
> same family. More here:
> 
>  http://www.chiappa.net/~jnc/tech/multics/MulticsPanels.html
> 
> Alas, as can be seen there, the DPS-8's don't have those wonderful panels
> with a zillion lights and switches; just boring modern machines! :-)
> 
>   Noel

Really the H6180 looks a lot more like the DPS-8 I remember.  We had a single 
CPU Dev system, and a 4 CPU Production system running GCOS-8.  I thought I 
might have some drawings of the panels, but if I do they’re in the garage 
somewhere.  Another site, had a DPS-8000, our site was pretty old, and had been 
upgraded over time.  For example the memory cabinets were mostly empty, due to 
upgrades.

Zane

Re: VCF PNW 2018: Pictures!

[Peter Corlett via cctalk]

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

That depends on how accurate you want the emulation to be.

A programmer of modest ability should be able to knock up a simple
switch()-based step-by-step CPU emulation in a few hours. This is analogous to
a simple microcoded CPU and the performance will suck.

Making it *cycle-accurate* involves deep understanding of the emulated CPU's
internal architecture. If part of the platform requires cycle-accurate timing
for bit-banging some hardware device, you're going to need this.

Making it *fast* also involves being an expert in compiler backends for the
target architecture, because this requires decompiling and then recompiling the
code on the fly.

... and that's the easy bit. Now you get to emulate the hardware.

Re: VCF PNW 2018: Pictures!

[Philipp Hachtmann via cctalk]

On 19.02.2018 02:52, Zane Healy via cctalk wrote:

What do they have up there for Honeywell?


I was looking through the pics and saw - nothing... But I also would be 
VERY interested about if and what Honeywell stuff they have.

Why don't you respect the mail threads?!

[Philipp Hachtmann via cctalk]

I have to say that I hate this email thread abuse so much...!
Is it so difficult to leave the thread about PICTURES (fill in whatever 
topic it was about) intact? It would be so much better to start a new 
thread instead:


- Does not disturb original discussion.
- Can be found and identified easily: Do you think that you will find 
the  easily in a few years if it's 
discussed under the caption "VCF PNW 2018: Picture!"?


And on the other hand there are those people who seem to be unable to 
create a prober reply to the list and therefore make threads appear 
scattered and broken into many many pieces...


Sorry for ranting, but I enjoyed the pictures and following discussion 
so much and now encountering that dumb emulator discussion in this place 
annoys me so much...!

And yes, I know that I sent this message as a reply to another message.

Kind regards

Philipp

On 19.02.2018 15:44, geneb via cctalk wrote:

On Sun, 18 Feb 2018, Zane Healy via cctalk wrote:

What do they have up there for Honeywell?  Any DPS-8’s?  I know they 
should have at least a box of GCOS-8 manuals (in hindsight, the only 
manuals I regret sending up there).


Zane, they've got a DPS-8 maintenance/operator/? panel sitting right out 
front.  It's fully operational and is connected via some magic hardware 
to a Raspberry Pi running a Multics emulator. The guy that wrote the 
emulator gave a talk that should be the first one you watch once Erik 
has a chance to get the video posted.