PERQemu Resurected

[tpear]

Very interested to see this resurected - many thanks to Skeezicsb for picking up the baton. I have never used a real PERQ myself, although the first project I worked on in the 80s did have one to run one particular application, so it’s interesting to see how it would’ve behaved had I been one of the 'chosen' who could touch it.

Have so far tried the emulator on Mac and Fedora - although Visual Studio for Mac (Monodevelop in disguise) still exhibits the keyboard issue mentioned in the readme and I found Fedora monodevelop needs both the revision control to be offed (to prevent a Monodevelop ide crash) and the targetframeworkversion dependency removed from the PERQemu.csproj file to build (no c# knowledge here, so no idea if that’s valid to do or what the consequences are :-) )

[Skeezics]

On Tuesday, August 21, 2018 at 5:27:44 AM UTC-7, tpear wrote:
> Very interested to see this resurected - many thanks to Skeezicsb for picking up the baton. I have never used a real PERQ myself, although the first project I worked on in the 80s did have one to run one particular application, so it’s interesting to see how it would’ve behaved had I been one of the 'chosen' who could touch it.
>

Thanks! I've been working with Josh, the original author, on some other PERQ-related projects too, like filling in some of the gaps in the library of floppy disk images that aren't (yet) on Bitsavers. Lately I've been focused on getting the display thread to run more efficiently so that the current emulator will run better on older platforms too -- and to regulate the speed on more modern machines. I'm hoping to maybe knock out a new update soon.

> Have so far tried the emulator on Mac and Fedora - although Visual Studio for Mac (Monodevelop in disguise) still exhibits the keyboard issue mentioned in the readme and I found Fedora monodevelop needs both the revision control to be offed (to prevent a Monodevelop ide crash) and the targetframeworkversion dependency removed from the PERQemu.csproj file to build (no c# knowledge here, so no idea if that’s valid to do or what the consequences are :-) )

The Mac keyboard thing is annoying, but it looks like moving away from Windows.Forms and using SDL instead may solve both that and the display refresh issue. I'd been hoping to avoid adding dependencies on external libraries like SDL or Pcap (for Ethernet support) but it may be inevitable. I'm glad to hear you've had some success on Linux, too. I don't do as much testing there as I should, given one old Ubuntu laptop and a CentOS VM that I haven't patched in a while...

I've had this irrational (or maybe just naive) desire to target the older .NET version so that older machines could still run it, but there's no harm in changing that setting to a newer version (to match whatever is on your system). I've been developing and testing on Mono 4.6.1, which is the last version I recompiled to include the keyboard patch. It should run on Mono 5.x as well. Thanks for the feedback, though, and I'll make a note of that in future updates to the readme.

Out of curiosity, what was the application that was running on that PERQ back in the '80s? :-)

[tpear]

Not entirely sure what the application would have been - but in the depths of my memory I have the feeling it was something to do with writing specifications in the Z formal specification language. Whether this was because there was a suitable editor with the myriad of special maths symbols or something more sophisticated that actually understood the Z notation, I couldn't say.

[Nigel Williams]

Thanks to Skeezics from me too for continuing development of the PERQ emulator.

Sounding like a broken record could I ask yet again if anyone has come
across a demo version of the Pascal-based (?) PERQ operating system
that had the various animations?

The two examples I recall when I encountered a PERQ in our Physics
department back in the 1980s were:

1. A bumblebee that flew around the screen when the machine was busy
2. A tiny animated figure who ran in from the edge of the screen and
pushed the window off the screen when it was closed. The window was
animated and slid off the screen as it was pushed.

I guess it was a piece of whimsy added for demonstration machines, but
it stuck with me all these years.

[Skeezics]

On Sunday, January 20, 2019 at 2:47:50 AM UTC-8, Nigel Williams wrote:
> Thanks to Skeezics from me too for continuing development of the PERQ emulator.
>

I'm thrilled that there are folks out there still interested in it. :-) Josh and I have been busy with other things, but I am still poking at it in my spare time. I'm working on some of the performance issues, trying to get it to run more quickly on "slow" machines and to regulate the speed on fast ones. I've been making progress but am not sure when a new release will be ready...

> Sounding like a broken record could I ask yet again if anyone has come
> across a demo version of the Pascal-based (?) PERQ operating system
> that had the various animations?
>
> The two examples I recall when I encountered a PERQ in our Physics
> department back in the 1980s were:
>
> 1. A bumblebee that flew around the screen when the machine was busy

Yep! The "busy bee" cursor was used to indicate "random progress" - like the spinning beachball, wristwatch or hourglass icons of later OSes.

> 2. A tiny animated figure who ran in from the edge of the screen and
> pushed the window off the screen when it was closed. The window was
> animated and slid off the screen as it was pushed.
>

I just banged out a Perl script to convert the PERQ .cursor and .animate files to PBM, and just for fun imported the little guy into Photoshop and spit out an animated GIF: https:/gph.is/2RNW7SM

> I guess it was a piece of whimsy added for demonstration machines, but
> it stuck with me all these years.

You can run the full demo if you load the POS F.1 or POS F.15 hard disk images... it's easy!

Run PERQemu.exe:
double click the icon on Windows, or
cd to the perqemu0.44 directory and type "mono PERQemu.exe" on Unix

When the console/debugger starts up, issue these commands:
"load harddisk Disks\f1.phd" (use / on Unix, obviously)
"go"

After POS boots up and announces itself, type these commands:
hit ENTER twice for time and username; you'll login as "guest"
"path :user>demo"
"@initdemo"
"@demo"

Away you go! The little pusher animation comes pretty early on, and he reappears at the end to light the bomb that ends the demo. :-)

Enjoy...

[tpear]

As a matter of interest, is there any rough idea as to how well the emulator performs compared to a real PERQ? So long since I saw one (and then only briefly) I’ve no idea lol

I wonder if the various PERQ OSs have much in the way of dependencies on the real PERQ timings - whether a fast emulation makes it have better performance or if the altered timing might make it unusable.

BTW - is there a simple way to turn the floppy images on bitsavers into something readable by the emuloator? Otherwise that’ll be another little personal project for my backlog lol

[Nigel Williams]

On 2019-01-23 10:25:36 +0000, Skeezics said:
> Yep! The "busy bee" cursor was used to indicate "random progress" -
> like the spinning beachball, wristwatch or hourglass icons of later
> OSes.

Ahh! there it is. Having run through the demo, I am wondering if the
emulator is not showing it often enough though? I recall on the
original that the busy-bee appeared fairly often?

> Away you go! The little pusher animation comes pretty early on, and he
> reappears at the end to light the bomb that ends the demo. :-)

Terrific! thank you for finding this and solving my multi-decade
mental-itch to see it again.

[Skeezics]

On Friday, January 25, 2019 at 3:38:54 AM UTC-8, tpear wrote:
> As a matter of interest, is there any rough idea as to how well the emulator performs compared to a real PERQ? So long since I saw one (and then only briefly) I’ve no idea lol
>

While focusing on emulation accuracy, I haven't done any real measurements of performance. Because there's no speed regulation in the current emulator, the easiest way to gauge your particular computer's performance is by booting POS and watching it update the clock in the main window's title bar. If the clock ticks once per second, you're golden! :-)

The wristwatch/eyeball test shows that my 8-core, 2.8Ghz Xeon (Mac w/Mono 4.6.1) runs the emulated PERQ at around 66-75% of the real hardware. But my 3.06Ghz dual-core iMac (Mono 5.0.x) doesn't appear to be appreciably faster. On my son's overclocked 5.1Ghz gaming rig under Windows 10, the emulator runs at about 120-150% faster than the baseline 5.89Mhz PERQ. I had to give up on my PowerMac G5 and Solaris/SPARC machines because Mono support really dried up after 2.10.x, and it's hopeless to bother running on any non-x86/x64 CPU at this point. "Cross-platform. You keep using that word. I don't think it means what you think it means..."

I've spent a few months looking at ways to increase performance, reduce GC overhead, and effectively rate-limit the emulator to match the 170ns microcycle time of the original hardware. Without rendering the display, the emulated microengine can run at around 48ns up to around 139ns, depending on Debug flags, optimizations and the weird behavior of the various Stopwatch/Timer functions in C# introducing odd delays of their own. So even on my 2009 Mac, there's more than enough headroom to run the PERQ CPU at speed. Nearly all the sluggishness comes from Mono/WinForms being painfully slow at drawing the PERQ's display at 60fps.

I've got test programs that run like a bat out of hell but leak like a sieve and crash if you try to actually do any work besides just blasting frames to the display. I've tried about a hundred different approaches and have ended up utterly dismayed by the state of the .NET/Mono UI world. There are 50 options and all of them are incompatible, already obsolete, not cross-platform, or just flat out broken. But this week I possibly found a suitable cross-platform solution that will seemingly let the display run at 60fps without swamping the host computer, and still let me use generic WinForms controls to expand the GUI (even on Mono) to include a new debugger, a dynamic configuration tool (so you can adjust memory, display, IO options, etc) and some other fun features. So maybe approach #51 will do the trick? I'll post updates as "real life" allows...

In the meantime, the amazing Josh Dersch has released both his excellent Xerox Alto emulator (see: ContrAlto on Github) and now his latest Xerox Star emulator (see: Darkstar on Github). LOTS of excellent stuff in there -- like Ethernet support! -- that will find its way back into PERQemu in time. :-)

> I wonder if the various PERQ OSs have much in the way of dependencies on the real PERQ timings - whether a fast emulation makes it have better performance or if the altered timing might make it unusable.

There aren't too many places in the PERQ code that were timing dependent as far as I can tell. There were a few hardware cases where the microcode would have to wait a few cycles for specific setup/hold times, or rely on index pulses from the disk to initiate track formatting, and stuff like that. Right now I don't really have a machine that's too fast to test on, but if I did it'd be to test the rate-limiting code and try to lock it in at 5.89Mhz! Of course, it might be fun to allow a configuration option to allow overclocking your virtual PERQ. :-)

That would also be handy for when I need to do a "build world" for recompiling POS (about 10 hours real-time), or bootstrapping a new disk image from scratch... and that's with the emulated Shugart disks running much faster than the actual drives...

> BTW - is there a simple way to turn the floppy images on bitsavers into something readable by the emuloator? Otherwise that’ll be another little personal project for my backlog lol

Ah, yes. I've been working with Josh to archive the rest of my floppies that aren't on Bitsavers, and to convert the older .raw and .dmk/.imd format floppy images to PERQemu's format. In the coming weeks I'll try to expand on the PERQmedia archive on Github with a whole slew of floppy images and the programs to convert 'em. This would all go a lot faster if I wasn't getting dragged away for weeks at a time on remodelling jobs, but an extra $6/month raised through Patreon probably wouldn't be enough to let me devote more time to PERQ stuff and still pay the mortgage, or eat something now and then. Sigh. :-/

-- c

[Skeezics]

On Tuesday, January 29, 2019 at 7:03:36 PM UTC-8, Nigel Williams wrote:
> On 2019-01-23 10:25:36 +0000, Skeezics said:
> > Yep! The "busy bee" cursor was used to indicate "random progress" -
> > like the spinning beachball, wristwatch or hourglass icons of later
> > OSes.
>
> Ahh! there it is. Having run through the demo, I am wondering if the
> emulator is not showing it often enough though? I recall on the
> original that the busy-bee appeared fairly often?
>

It mostly depended on the application to turn it on or off; things like the compiler showed the busy bee, or the "dirtree" program which did a bunch of disk accesses. The "scavenger" utility had a whole series of funny little cursors -- a vulture, a pair of eyeglasses, a hand holding a pencil -- and of course people would go in and change the images with the cursor editor all the time. :-)

>
> > Away you go! The little pusher animation comes pretty early on, and he
> > reappears at the end to light the bomb that ends the demo. :-)
>
> Terrific! thank you for finding this and solving my multi-decade
> mental-itch to see it again.

Glad to finally oblige. :-)

-- c

[tpear]

Golly, I didn’t expect so much detail lol

I must see if I can get my head around C# - I can follow the code easily enough, but that’s not the same as being able to write it lol It’s not something I’ve had to dabble with professionally. Sounds like the .net/mono environment is a bit - erm - lacking and creating a bottle neck in virtualising the display. I guess a 'cheat' like only actually displaying every other frame would be a bit crass lol

I must lookout the keyboard patches to mono to get the emulator working on my Mac - even proper Microsoft visual studio for OS X is just rebadged mono and suffers the same way. As you say, their idea of what 'cross platform' means is somewhat different to ours. At least I can run on my Linux NUC - although there the problem is using a (perfectly serviceable) older monitor without sufficient screen real-estate.

Won’t be too long before G5 powermacs and SPARC Suns become just as much a subject for computer archeology as PERQs and Xeroxes :-)

Thanks for the effort that goes into this - it’s fascinating to see the emulated PERQ in action and be able to follow the POS sources to see how it was originally put together.