Failed to create primary interface

Failed to create primary interface (0×88760)

Since this error only arises SOME of the time when restarting VRPC, I was wondering if it it’s possible to eliminate it!

It is a b****y nuisance I agree. When I asked Aaron years ago he said it was because of a Windows change. No fix to VRPC has been forthcoming since … though I have noticed it less recently with Win10pro (that is inviting a splurge of the things!).

For me, it occurs frequently if VRPC is minimised when Windows hibernates. If VRPC is open full-screen it occurs a lot less frequently.
Still Very annoying.

Are you sure we’re not talking about “failed to create primary surface” (buffer) error?

That’s basically caused by trying to run another copy of VA when one is already running, usually in hardware assisted mode. It can also occur when other 3D apps are running, but is mostly due to to running two copies simultaneously. In all the hundreds (thousand?) of RISCubes I’ve built, that’s the only time I see it. It is why I don’t put VRPC on the taskbar on machines (single click launch) because users have a bad habit of double-clicking which triggers the fault.

However, it may be GPU dependant too or VRPC edition. I’ve just run 3 copies of VRPC-DL (the cheap one) on my Win10pro box with a 8GB GTX1080, and all three can be switched between, and run full screen etc. This is after several days of sleep and hibernate. This isn’t usually possible, and all three are using hardware scale etc. I strongly advice unticking the “allow RISC OS to change screen mode” option. The only other change I made to that copy was to unplug “portable” which keeps it in a high power state – its wickedly fast on this PC.

he said it was because of a Windows change

Ho ho.

“Failed to create primary surface” is a DirectX error, specifically a failure to (re)initialise DirectDraw.

It can be triggered by many things, including system updates, fullscreen games, even Windows screensavers.

VirtualRPC is unfortunately not clever enough to even put itself into a suspended state until DirectDraw is available again (which it usually will be, often within a fraction of a second), which is pretty shoddy. Mind you, it won’t even start up unless you have an audio cable plugged in, silently quitting with no clue as to why it won’t work. So losing all your work because it’s Patch Tuesday is the height of sophistication in comparison. :-/

It becomes more interesting (read: frustrating) once you try to use VNC or RDP to remotely access VRPC.

VRPC seems to be stuck with whatever was created in 2002 for using DirectX with Red Squirrel. Yes, Windows changed quite a bit since then.

Does Aaron have no interest in VRPC bugfixes?

Does Aaron have no interest in VRPC bugfixes?

No idea. I provided countless bug reports over the years, I don’t think I ever got a meaningful response – the big exception was a problem with HostFS in VRPC-DL completely crashing VRPC, where Aaron reacted really fast and the problem was solved within a day.

I always had the impression that the available developer knowledge about certain parts of VRPC was very scarce, so problems with Windows integration (especially security policy and networking stuff), DirectX, ADFS emulation, ye olde Red Squirrel SDK stuff…got mostly ignored.

It’s such a shame as it’s very nearly excellent. But renaming files if it doesn’t recognise the extension (it adds ,FFF to them), the mouse handling when windowed (as previously discussed), and its ‘glass jaw’ of DirectX fragility are all really annoying and basically misdesigns, not intractable problems.

But renaming files if it doesn’t recognise the extension (it adds ,FFF to them), the mouse handling when windowed (as previously discussed), and its ‘glass jaw’ of DirectX fragility are all really annoying and basically misdesigns, not intractable problems.

That’s a nice sum-up of the biggest problems. HostFS, Windows integration, beyond that there are only a few niggles (like the braindead registration stuff (apart from VRPC-DL of course) along with its wilful (or is it “willful”?) incompatibility with RISC OS 5 and RISC OS 3.x).

On the other hand, RPCEmu would only need a few things to be a viable replacement – multi-mount HostFS possibly with MimeMap support and as-easy-as-VRPC-networking.

On the other hand, RPCEmu would only need a few things to be a viable replacement – multi-mount HostFS possibly with MimeMap support and as-easy-as-VRPC-networking.

So, “only” a small amount of development work then.

BTW. Irony isn’t a method of getting creases out of clothes.

RPCEmu would only need a few things to be a viable replacement

It needs a complete rewrite of the MMU emulation as memory writes ignore page access permissions, using the CPU privilege level instead.

I’ve asked for the RedSquirrel source on several occasions, so I can fix that primary surface error. Ironically RedSquirrel is still the most accurate A5000/RiscPC emulator.

It needs a complete rewrite of the MMU emulation as memory writes ignore page access permissions, using the CPU privilege level instead.

That would be “nice to have” in my book. It is not a problem of everyday use (at least with the software I am running under emulation).

Ironically RedSquirrel is still the most accurate A5000/RiscPC emulator.

I know you have special interests, but for a standard user, the precision of emulation of RPCEmu is good enough. IMHO of course.

And I achieved very good results with ArchiEmu for RISC OS 3.1 era software, including games.

I would be interested, long-term, in a hybrid emulation. That is to say, a RISC OS simulator, rather than an Acorn emulator. A virtual platform as a separate target for the OS, rather than a model of an ancient piece of hardware. RPCEmu may be a route to that outcome.

I would be interested, long-term, in a hybrid emulation. That is to say, a RISC OS simulator, rather than an Acorn emulator. A virtual platform as a separate target for the OS, rather than a model of an ancient piece of hardware. RPCEmu may be a route to that outcome.

I discussed that (briefly) months or even years ago with Mr. (I think Peter) Howkins. Personally, he is not interested in such a thing and thinks that RPCEmu should stay a “Risc PC emulator”.

Personally, I would also like a “RISC OS simulator” which presents an abstracted hypothetical RISC OS-running machine to the world, because this would have a lot of interesting potential for non-retro usage. However, I am in no position at all to provide any meaningful amount of time in reaching such a goal. Other than a lot of good advice of course :-)

;-) There might be a number of conflicting requirements here, including the creation of a new thread.

What’s the requirement? A virtual machine environment for testing apps with different version of the OS, application virtualisation for running older apps like !Sibelius on newer hardware, …

What’s the requirement?

Running RISC OS on a powerful desktop computer without being constrained by pretending to be 25-year-old hardware. It’s the difference between a BBC Micro and a 6502 2nd processor – one has the hardware of a BBC Micro, the other only has the API of the Beeb. I’d prefer a thinner kernel (or Hal) that spoke directly to the emulator, rather than thinking it was talking to ancient hardware and the emulator having to pretend to be that hardware.

There’s no reason why a RISC OS simulator has to pass every SWI to the SWI handler, for example.

Porting RISC OS to the latest and greatest Pi, set-top-box or greetings card can only be a temporary measure – all these platforms will become obsolete, and at some point 32b ARMs will be a memory. Do we think we’ll move on to PiEmu at that point?

A RISC OS virtual machine is a better solution. Then you don’t have to worry about WiFi, security protocols, or even HTML rendering – it could all be done by the host OS. As if you’re running in an ARM second processor in the Win/Mac/Linux PC.

Just agreeing with Nemo and Steffen. I always felt that the future of VRPC was in creating a virtual ARM machine with as many of the underlying “host OS” APIs abstracted through to RISC OS via modules – 3D, audio in/out, MIDI, etc. Indeed, when RISC OS Six launched, I could understand why there weren’t “host” video drivers for VRPC, and indeed why OS Six development wasn’t driven by VRPC since by that time it must surely have been the main market. They effectively had software-control over both sides of the equation – virtual hardware and OS.

We’d end up with a virtual ARM CPU running a version of RISC OS with effectively virtual “hardware” rather than emulations of RPC hardware. As long as software compatibility was maintained, the sky would (almost) be the limit.

But there’s the tricky bit. Just yesterday, I saw how Artworks 1.7 wouldn’t load properly when RAM exceeded 128MB. That’s obviously been superseded by Artworks 2, but equally, it demonstrates how the more you change, the more you risk breaking software, which is why RISC OS is being used in the first place. ARGH!

Maybe qemu could be adapted to the purpose of virtualizing the interfaces to the hardware and making it modular. I’m reminded of this article: Running RISCOS on QEMU

Didn’t Microsoft get involved and add Pi emulation to QEMU? I know they were fixing issues with the USB stack when I was testing it many years ago. As I recall I had RISCOS running under it at the time, just missing sound.

If QEMU does now emulate a Pi sufficiently, is that not a suitable target platform?

Andrew recalled

when RAM exceeded 128MB

I had to tweak PhotoDesk the other day because it couldn’t resize images if you had too much RAM – a signed comparison thought I had a negative amount of RAM.

We’d end up with a virtual ARM CPU running a version of RISC OS with effectively virtual “hardware” rather than emulations of RPC hardware. As long as software compatibility was maintained, the sky would (almost) be the limit.

Very much this. Once some/all WindowManager is in the host, one could envisage RISC OS apps running alongside native apps on your host OS of choice. And this has triggered an ancient memory of someone doing the reverse a very long time ago – PC Emulator windows running in the RO desktop. Was that an Aleph One experiment? A Wookie special? Long time ago.

To be honest, I rather convert the kernel to C and port to x86-64.
I think that riscos will die quicker if only used virtualised.

But I think the other way around, run Linux apps on riscos would be cool.

nemo – well remembered. It wasn’t Aleph1 though – it was a new one-man company that pretty much only had the one product. IIRC it ran horrifically slowly, and only sort-of worked. But it did sort-of work, which was key. It was called WinRisc or Win, Risc. Seems to be by a chap called Chris Claydon. CJE sold some copies at some point.

To be honest, I rather convert the kernel to C and port to x86-64.
I think that riscos will die quicker if only used virtualised.

I may be misunderstanding your point, but there’s only four scenarios I can think of:

• 32bit ARM systems will be available for the rest of time, as will developers to continue porting RISC OS to them
• convert the entire OS and all software ever released to high-level languages or some other processor platform
• emulate a specific piece of ARM hardware and stick with it forever
• create a virtual platform that can have some of the OS running natively on the host, and emulate the rest

The last is the only sensible long-term plan IMHO.

Seems to be by a chap called Chris Claydon

He emigrated, I think.

nemo

I can only speak from the knowledge of Amiga systems. MorphOS have reconstructed amigos from scratch and ported to powerpc. Some people seems to think that just by using ppc made it a simple thing to do! I can tell you that it wasn’t. On top of the native fully compatible system there is a fast m68k jit emulation. All this because m68k was a dead end at that time. Recently there has been some attempts at doing fast fpga implementation of m68k systems. The vampire board has extended 68060 , and it runs pretty fast. Regarding x86. There is also AROS allthou a much older project, but it is so I compatible and runs on most cpus including x86 64 and 32bit arm. So my idea with bringing the kernel to c is to have some features emulated. Even if we look at arm64, it needs to be done. A example is swi’s as we use them today. So this is what I meant , a fully compatible (as far as possible) host system and a JIT emulation in the mix. Fuly transparent system.