Re: [Rpcemu] Fw: RPCEmu licence and other topics
On Thu, Aug 26, 2021 at 06:59:25AM +, Sarah wrote: > On Wednesday, 25 August 2021, 23:36:53 BST, Theo Markettos > wrote: > > >Changing RISC OS to use the documented interface for USB power control, > >which is the one I found, is a small change. The timer issue is a more > >substantial roadblock, and that's a hard peripheral that QEMU doesn't > >implement because other OSes use the ARM's own timer instead. > > So why is RO different to everyone else? The timer issue is a more complicated one. Essentially RISC OS assumes timers work just the same as they did on the Archimedes. There's one timer, you configure it to give you an interrupt at 100Hz, job done. So what happens when someone ports RISC OS to a new platform is they scour the datasheet for a timer that behaves just like the one in the IOC on the Archimedes (and RiscPC). And that's what happened on the Pi - there's a timer that's specific to the Pi SoC. That approach is running out of road. It made sense in a world of an 8MHz/4MIPS CPU, where you got 40,000 instructions between interrupts. Now CPUs are 2GHz it's less good to have a 100Hz timer with 20 million instructions between interrupts. Lots of I/O things depend on microsecond timing, for example. Nowadays you want multiple sources of arbitrary different time granularity too, and be able to read the timer counter without consistency risks. Every Arm core has a timer block as part of the core, which means it doesn't depend on the hardware the SoC vendor decided to slap around it. So you don't need to worry about writing a timer implementation for every single SoC. Unfortunately the timers have changed between generations, so an ARM11 timer is different from a Cortex A53 timer, so you need a handful of drivers for those. Also, cores are subject to powersaving - you need to adjust if the core that is clocking the timer gets downclocked from 2GHz to 857MHz to save power. Linux, FreeBSD, etc have modern timer subsystems that use the Arm core's timers, with code to implement generic timers on top of what the hardware provides, with drivers for the various Arm cores. Therefore QEMU doesn't implement the Pi-SoC timer because no other OS uses it - if you select the raspi2 emulation you get a Cortex A7 CPU and its timers, if you select raspi4 you get a Cortex A72 with timers. You can boot quite happily on a new SoC with a Cortex A72 without any tailoring the new hardware, because you're using generic timer (and interrupt controller and UART) drivers. RISC OS doesn't do any of this, it just clings to the idea that a single 100Hz timer is good enough - and it isn't in this day and age. So in this space it's not wrong to say QEMU should implement the Pi-specific timer - it would make QEMU's implementation more complete. But, all things being equal, instead of investing the effort in distributing a fork of QEMU, looking at the bigger picture it could make more sense to invest effort in modernising RISC OS' use of timers, which would make it easier to port to new platforms and down the line improve the performance and capability of RISC OS on all platforms. Making it less weird and work more like other OSes, in an area that doesn't have any benefits to being different, makes it easier to work with down the line - booting on emulators or on new silicon. But all things aren't equal, so it really depends on who has time and skills and what they want to work on. > Bending your side to meet the quirks of a current inaccurate > implementation of something else leaves you screwed if said other side > becomes more accurate. Which is quite likely to happen; QEMU is aiming to > emulate a Pi, not "something like a Pi", and they are quite likely to make > changes to bring their emulation closer to a real Pi. At which point RO > has _more_ costs having to readjust. In systems typically there is 'core' behaviour, that is the well trodden path that every platform uses regularly. And then there are the depths of the weeds, where they rarely go. RISC OS exercises unusual parts of the weeds that others don't. You can fix the emulator's implementation of the weeds, or you can make RISC OS more mainstream and less surprising. In this instance I see more benefit to modernising RISC OS to make it more mainstream (in this particular area) than I do than in improving the weedy parts of the emulation, not that that is a bad goal of itself. > If you just want something for virtualisation that doesn't want to look > like a Pi, QEMU has the 'virt' platform for that, and there's no reason RO > couldn't port to that. Porting specifically to "the current state of the > Pi emulation" rather than fixing the problematic elements of said Pi > emulation is just asking for trouble. Agreed, but the 'virt' platform would require the timer modernisation above. I'd suggest it's better to invest in that kind o
Re: [Rpcemu] Fw: RPCEmu licence and other topics
On Wed, Aug 25, 2021 at 02:38:16PM +, Sarah wrote: > On Wednesday, 25 August 2021, 14:20:47 BST, Theo Markettos > wrote: > > >RISC OS currently uses some undocumented firmware interfaces > > Please tell me this is a joke. That code needs to come out ASAP, and > should never have been checked in. It's not a joke, it's because the RISC OS port and the firmware have co-evolved. Originally there were no documented firmware interfaces, because there was no documentation - there were simply emails to the firmware developers. Later on some bits got documented, but it turned out not the ones RISC OS implemented. (This is how a lot of stuff gets developed, when the software and hardware teams are working together you can save a lot on documentation when you can just go and ask, or go look at the chip design source code. Which are things people outside the company don't have access to, but then don't need to according to the target market) > The best approach I can see at this point, is to fork QEMU, fix the > firmware simulation at the FW version RO5 is using (I'm assuming the > binary blob for this is loaded by RO; if not you've got some issues in > general anyway), and add the convenience features like HostFS. Then > feedback any relevant changes/fixes to mainline and let them go up > whatever upstreaming process is in use there at their leisure. The firmware is loaded before the OS boots, so you don't get to control what firmware you're running on. On Pi 0-3 the GPU firmware boots first and brings up the ARM later on; Pi 4 has more of a traditional boot process that involve the firmware being an ARM 'BIOS' to load up the OS. Changing RISC OS to use the documented interface for USB power control, which is the one I found, is a small change. The timer issue is a more substantial roadblock, and that's a hard peripheral that QEMU doesn't implement because other OSes use the ARM's own timer instead. But I raise this as more of a philosophical point: modern systems are complex and change over time - they are not fixed at a point in the past like older hardware was. Emulating them therefore may need a different approach. Particularly when you can bend both sides to meet each other, it's then a question of which side is easier to bend, and which incurs you the least costs. > This would give you a reasonable emulation of a more modern platform more > suitable for new software, and is a hell of a lot better than the idea of > forking RPCemu (since the relevant changes would never be mainlined) to > weld in ARMv7 and the like. I agree: RPCEmu is designed to be a fixed emulation of a fixed piece of hardware from a historical period. If what you want is a way to run modern RISC OS on modern hardware, there are other ways to go about it. Theo ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
On Wed, Aug 25, 2021 at 08:06:05AM +, Sarah wrote: > On Wednesday, 25 August 2021, 08:56:07 BST, David Feugey > wrote: > >The other way would be also to correct Qemu to provide a better Raspberry Pi > >emulation. > > This is by far the correct option. Apply the fix where the bug is - if RO > is running correctly on a real Pi, then bugs need fixing in QEMU's Pi > emulation. I'm sure the QEMU maintainers would be very happy for any > patches to improve things on their end. The raspi2 emulation in QEMU is not a full emulation - it emulates just about enough to get Linux going. The reason is that the Pi is not just hardware - a large part of the platform is the GPU firmware providing services to the ARM-side OS (through mailboxes). These services have evolved over time - the firmware is part of the SD card image, so you have to synchronise your OS with the API provided by your firmware. While it is possible to extend QEMU to implement more firmware services, it's a perpetual game of catchup and you risk affecting your ability to boot older/newer Linux/BSD/etc images. RISC OS currently uses some undocumented firmware interfaces - the particular one I found is easy to change in RISC OS to use a documented interface which is hopefully more stable. Further down the line it is arguable whether RISC OS should be modified to be less tightly fitted to Pi-specific peculiarities, or QEMU modified to implement more Pi peculiarities. These are not bugs, but more questions about emulation philosophy. They are also ones of development process - how easy is it to get updates into RISC OS or QEMU, how long do they take until they trickle through to the places people install them from, how to test it doesn't cause breakage with other OSes QEMU might boot. IMHO I view the RISC OS development process as relatively lightweight, whereas upstreaming patches into QEMU and distributions potentially less so. More generally, better performance can be achieved by the emulation departing from exactly modelling the hardware - emulating every single register in a complicated I/O chip is a lot more work than an interface like HostFS where you slim it down to just what you need. So it may be something 'good enough' to boot RISC OS is better than a perfect emulation. Theo ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu licence and other topics
On Mon, Aug 23, 2021 at 02:07:29PM +0100, A Rawnsley wrote: > > I just wanted to post a "thankyou" to Theo for such an excellent and > researched email. Really appreciated. Hi Andrew, Some further thoughts below... > Personally I always felt that the evolution of a virtual system (be it > VRPC, RPCemu or something else) into a system where you could control both > sides of the emulation equation (the virtual hardware presented *and* the > open source OS/HAL) offered perhaps the most interesting future direction > for such products, but perhaps independent of their current incarnations. I agree, there are plenty of interesting things involving putting layers underneath RISC OS. However there is an advantage being able to run things 'stock' - ie boot an image in a hypervisor/emulator/whatever without modifying the emulation environment. That means you don't have to worry about maintaining and distributing that platform, you just tell people 'download ', and it's probably already in their store/package manager. There is no reason why RISC OS can't boot in a mainstream ARM emulation environment, it's just that RISC OS has a habit of doing things its own way that have historically been tailored to the specific platforms it runs on. Which is why RPCEmu has to emulate a Risc PC, including all the limitations of that platform, and not a generic ARM system with parts taken from a standard bin. It's why we can't just swap out the CPU emulation in RPCEmu to ARMv7 and expect RISC OS to work. Other ARM platforms have largely coalesced around Device Tree, which is a way to specify what hardware a system has and so the OS can configure itself appropriately, which means you don't need to compile the OS for every single variation of the hardware. This is not something RISC OS supports - many decisions are baked in at compile time. > In thinking about this, my intention is not to belittle VRPC or RPCemu > (which both excellently fulfill the role of emulation of my favourite > Acorn machines) but rather to see how emulation could take us forwards in > interesting directions with suitable HALs etc, perhaps exposing new > technologies without the need to fully implement hardware drivers on the > RISC OS end. Particularly in light of ARM's move to 64bit exclusivity, > and RISC OS' lack of readiness for such a move. I think this could be a two-stage process: put an emulation/hypervisor layer underneath so RISC OS isn't so wedded to the physical hardware any more, and then think about what RISC OS could run on top of inside the emulator - for example that could be some kind of microkernel. This is easier to do when the microkernel doesn't need drivers for umpteen hardware platforms out there, and it avoids such a tight tie to the underlying architecture. > I must admit, I've never spent much time with qemu (beyond knowing of its > existance and purpose) because I didn't think it offered enough of a > system emulation to allow RISC OS to run, but this is probably my > ignorance, and I think perhaps the "RISC OS for Linux" guys offer > interesting approaches there. > > I was also under the impression that Qemu was a less efficient form of ARM > emulation compared to the JIT approach of RPCemu/VRPC. Is this an > incorrect assumption? (From Theo's email, it does sound like it). QEMU is a full system emulator - it emulates the CPU, memory and a huge range of peripherals across many architectures. We are using it as a system emulator to bring up OSes on new ARM silicon before it comes out of the fab, for example. The main difference in instruction emulation is that RPCEmu has a hand-coded JIT for 32- and 64-bit Intel CPUs. QEMU uses the compiler to generate fragments of code for whatever CPU it's compiled for (which is many platforms), and then stitches them together. It's difficult to compare them (would need to boot Linux on RPCEmu and run some benchmarks[1]), but elsewhere I've run QEMU emulating a 64-bit MIPS CPU and got ~500 MIPS on a ~2013 server. So I would expect emulation performance to be broadly comparable. A useful feature of QEMU is that it hooks into native KVM hypervisor support on 64-bit ARM on Linux which, assuming your CPU supports 32-bit instructions, gets you native performance. If you don't have 32-bit instructions, or are on a non-ARM platform, it has to emulate them (sadly Apple's ARM cores don't support 32 bit). ([1] If anyone has a recent-ish Linux distro available on RPCEmu I could probably run some benchmarks on various hardware to compare RPCEmu and QEMU. Russell King, the Linux/arm maintainer and original porter of Linux to the A5000, still maintains the RPC support in mainline Linux so in theory it still works, but distros supporting ARMv4 (not ARMv4T) are trickier.) The main thing you don't get with QEMU is the RISC OS integration with things like HostFS, networking and shared clipboards. Or rather, QEMU has its own implementations of those, so no work
Re: [Rpcemu] RPCEmu licence and other topics
On Fri, Aug 20, 2021 at 04:57:22PM +0100, Peter Howkins wrote: > RPCEmu doesn't support ARMv7 and is not likely to in the future for several > technical and practical reasons. > > 1) Going from ARMv4 to ARMv7 does not offer any speed benefits when being >emulated. The more complex instructions in v7 would need roughly the same >number of host-cpu cycles to emulate as multiple simpler ARMv4 > instructions > > 2) The number of new instructions in ARMv7 vs ARMv4 is more than 500. >It is roughly 6 times the number we currently emulate (This number >includes Thumb instructions, but does not include NEON or VFP). >This is a massive job to complete. > > 3) There is no Operating System for this. There is no RISC OS available that >targets an ARMv7 CPU on top of IOMD (Risc PC) hardware. As such you'd > have >to compile up custom OSes for this hardware *or* emulate the rest of the >system of an existing platform such as the Beagleboard or the Raspberry > Pi >(this is an even larger job than updating the CPU emulation). > > 4) There is hardly any RISC OS software that actually uses ARMv7, the most >important of which is a web Browser. On an emulated system people will >use the browser on windows/linux/mac as it will run considerably faster. > > The balance of 'work' versus 'benefit' will not be reached for me. However > as > this is an open project, anyone is welcome to work on any feature that they > want to. FWIW I agree with most of what Peter says here. The moment you change RPCEmu to not model the Risc PC hardware you now need a fork of the OS. The more you graft in, the less it's a Risc PC - essentially all you are sharing is the GUI. No.4 is a bit of chicken and egg: VFP hardware floating point is worth having and supported in GCC 10, but it's not available because of the need to support ARMv3/4 (RPCEmu), v5 (Iyonix) and v6 (RPi 1 and Zero - only older VFP). It would not be infeasible to build ARMv3 and ARMv7 packages to satisfy both audiences. > RPCEmu is an emulation of a 27 year old computer, its main purpose is to > allow users to run obsolete software. Whether you consider RISC OS 3, 4, 5 > or 6 is obsolete, is left as a personal choice. +1 I did have a go at running RISC OS 5 on QEMU's raspi2 emulation and I immediately ran into some problems. QEMU provides a gdb interface which makes it relatively rapid to drill down into where things are going wrong (the main annoyance is that it can't understand RISC OS' debug symbols) A trivial problem was this one: https://www.riscosopen.org/forum/forums/3/topics/16552 - the Pi uses an undocumented power control interface that isn't implemented in QEMU and causes RISC OS to hang waiting for an answer that never comes - it's straightforward to switch to the documented interface. but more troubling is this one: https://www.riscosopen.org/forum/forums/3/topics/11109 - the RISC OS timer code uses a Pi-specific timer, which is not supported in QEMU. The Cortex cores have their own timer internally, that it would be better for RISC OS to use across all its platforms, but that requires substantial refactoring of the timer subsystem. That's a task that will have to be done sooner or later and would benefit RISC OS as a whole. It would be less work to modify QEMU, but that makes host side things much more painful (need a custom build, can't use a stock download, needs to be signed on Mac, etc etc). I think a more fruitful avenue for someone with more time than me would be to sort out some of these issues in porting RISC OS to ARMv7 QEMU, which would then make use of all the good stuff QEMU has (fast recompilers, native hypervisor support, GUIs, etc). I respect Peter et al's opinions on the direction of RPCEmu, so perhaps Stefan might think about this as an alternative direction. Theo ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Sound Settings - RPCEmu 0.9.3 & RISC OS 3.50
On Thu, May 14, 2020 at 07:33:33PM +0100, Bryan Hogan wrote: > It was a long time ago, but I think I had the 16bit sound upgrade with > RISC OS 3.5, but did need to soft load new sound modules to make it work. > > No idea which modules they were though! It was probably SoundDMA - so extracting the SoundDMA module from a later RISC OS version might be worth a try? Theo ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Sound Settings - RPCEmu 0.9.3 & RISC OS 3.50
On Thu, May 14, 2020 at 10:40:14AM +0100, Rob Heaton wrote: > I'm using RPCEmu 0.9.3 on Windows 10, with a RISC OS 3.50 ROM. > I'm having trouble getting sound working, the sound output seems to be > garbled mess. > > Are there some settings that need changing in RISC OS for this? > I've tried setting the option for 16 bit sound in the RISC OS > Configuration, but this has made no difference. > (Using a newer RISC OS ROM, the audio is fine, tested with RISC OS 3.71) >From a glance at the source it looks like RPCEmu only supports 16 bit sound. I'm not sure if RISC OS 3.5 supports it. I think originally machines shipped with 8 bit sound and upgrading to 16 bit sound required RISC OS 3.6. Could you try with RISC OS 3.6? Theo ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] (no subject)
On Thu, May 14, 2020 at 08:01:17AM +0200, dfeu...@ascinfo.fr wrote: > Le 2020-05-13 22:59, Peter Howkins a écrit : > It seems as if a large number of these suggestions are "It would be > better if I could pretend the Host OS wasn't there". RPCEmu is about > running RISC OS and its applications on the Host, not running Host > applications under RISC OS, there's such a ludicrous amount of work > there for so little benefit that I'm not not interested in pursuing > it. > > This subject is going really to far. > That was just - at first - a suggestion. > > CallWin32 did exist and was quite funny. With better security (selected API, > selected calls, user confirmation, or just a big warning) it could help. ISTM that these are the kind of things that are traditionally performed by 'integrations' in hypervisors. You install the 'guest additions' in the guest OS which provides some drivers that hook into the hypervisor and allow things like seamless mixing of windows between the host and guest desktops. Such a process has host and a guest components. I don't see a problem if the interface between host and guest is an API that is clear and well-defined. For example, HostFS and networking are examples of such an API. Being bounded, the API would not be able to make arbitrary OS calls (as CallWin32), and the host side of the API would vet the requests it gets from the guests to check if they're sensible. Obviously, opening up any interface offers another attack surface. But a user could decide whether to open up, say, the 'host printing' interface if they decide they want to take that risk. The host side of things would be naturally implemented inside RPCEmu - the guest side would likely be more of a stub. I assume by Peter not wanting to define an API he means an API that allow host-side RPCEmu to interface to other closed-source host-side code. This problem wouldn't arise if the host-side code was simply integrated into RPCEmu (being open source), and the patch was rejected if the guest-side code wasn't also open source. > Now, it's your project. Your choices. > I did not suggest that to bother you. > Working around RISC OSs lack of applications in a system emulator of a > 26 year old piece of hardware is pretty ridiculous. > > This time, since RISC OS is used for my business: my choices ;) > But perhaps I'm ridiculous to use it after all. I think it depends on your use cases. If your use case is you have some piece of RISC OS software that you want to run but want to integrate better with host facilities (eg printing), that's different to if you want to run (for instance) a game as if the world stopped in 1994. The existence of such integrations in VRPC suggest that there are people who are interested in the former. As ever, this is moot until someone builds such a thing :) Theo ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Chocks Away emulation a little speedy
On Thu, May 14, 2020 at 11:22:35AM +0200, Peter Moore wrote: > Hi guys, > > I recently imported my old RISC PC hard drive and am successfully > emulating it in RPCEmu. Some apps run a little faster that on the > original hardware, one example is Chocks Away: > > https://www.youtube.com/watch?v=9AZIwgOzE1k (note, I made this a private > video on youtube only available via a direct link) > > I'm happy to enable some debug output etc to help diagnose the issue. I’m > also happy to get involved in making a fix, if anyone can provide some > guidance/pointers to get me started on how the timings are managed. ISTR having a similiar problem with Chocks Away on a SARPC and having to turn off the cache to make it playable. What version are you using? Mine was from an Acorn User cover disc. It may be that either Chocks doesn't support proper timing moderation at all, or that it needs a later version that does. Theo ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu 0.9.2
On Sat, Oct 26, 2019 at 06:28:58PM +0100, Timothy Coltman wrote: > However, compiling with the "dynarec" option turned on gives an access > denied error when you run the emulator (the "mprotect" line in > "set_memory_executable" of "ArmDynarec.c"). This is OS X 10.14.6, with > the latest software updates. This looks like an Apple change or > something, as previous versions of the emulator did work with dynamic > compilation turned on. It seems to object to PROT_EXEC - no idea why, > though reading around suggests it may be something to do with sandboxing. Apple is tightening up the use of code generated at runtime, since code injection is a common attack pathway. It's not possible to do it at all on iOS, for example. For macOS, it appears you need to pass MAP_JIT to mmap() and also have the feature enabled at code signing time: https://github.com/dotnet/coreclr/issues/18617 I think you also need pages RW or RX - macOS has almost no pages that are RWX and I suspect they want to keep it that way. Theo ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Config-free networking work-in-progress (was: Patch for 0.9.1 - Mac keyboard support)
On Thu, Nov 22, 2018 at 07:32:32PM +, Matthew Howkins wrote: > I have previously done some work integrating Slirp with RPCEmu, and got > further than you, because I can send and receive network packets :) That's good to know. I'm sure your proof-of-concept is better than mine :) (I have previously dug out the QEMU networking code on another project, but quite a lot of QEMU came with it. We should be releasing this in a few weeks, but I don't think the codebase will necessarily be helpful here) > I expect that there's still a lot to do on networking, but the long-term > plan is definitely to go with Slirp (or if not Slirp, something > equivalent). This would become the recommended networking option, and the > most portable option. That sounds like a good plan. It would seem to make more sense to work on that rather than platform-specific TUN/TAP code. Theo ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Config-free networking work-in-progress (was: Patch for 0.9.1 - Mac keyboard support)
On Wed, Nov 21, 2018 at 02:07:11PM +, David Gee wrote: > The Mac emulator BasiliskII uses slirp for networking. It doesn't require > setting up. It's open source so it may be easier than QEMU (or it may > just use the same code). Thanks. It appears to use an earlier fork of the same code, without the library-ification. Theo ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Config-free networking work-in-progress (was: Patch for 0.9.1 - Mac keyboard support)
On Tue, Nov 20, 2018 at 10:08:40PM +, Theo Markettos wrote: > There are also things like: https://github.com/zhuhaow/NEKit that build on > top of NETunnelProvider and handle the entitlement, like you do with > Tunnelblick. Shortly after writing that post, I had a better idea. QEMU uses a library called SLIRP, which contains its own ethernet stack, including servers to do DHCP, DNS, etc. When a QEMU VM wants to use the network, the default mode is to push packets into SLIRP which will NAT them and emit them from the QEMU app as if they were native connections. This enables no-setup networking for QEMU VMs, and it's the default way that QEMU uses. In principle, doing the same for RPCEmu would allow no-setup networking across all the platforms it supports. QEMU's source code is not pleasant to work with (I have the scars), but somebody has done libslirp, which is the SLIRP code ripped out into a separate library with an easy-to-use interface: https://github.com/rd235/libslirp (it's mostly GPL as RPCEmu is) Since I had a spare couple of hours, I plugged libslirp into RPCEmu as a new 'NAT' networking type, just in the Linux code for now as a proof of concept. Currently it doesn't work - transmitted packets go into libslirp but none are received from it as network_plt_rx() is never called to fetch them, probably because I need to understand how the RPCEmu network card does interrupts. libslirp can either do a synchronous receive call, or a file descriptor via poll() or select(). As I don't know when I'll next get time to work on this, I've put the code up here: https://bitbucket.org/caliston/rpcemu-libslirp/ in case anyone gets around to taking a look before me. Theo ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Patch for 0.9.1 - Mac keyboard support
On Tue, Nov 20, 2018 at 09:38:56PM +, li...@maemagel.com wrote: > My hacked version would have been pretty awful, even if it had worked. > Kernel extensions need to be signed in newer versions of OS X and I'm > not a registered developer, so I ended up downloading an application > called "Tunnelblick" and borrowing its Tun/Tap kernel extensions, which > were signed. The emulator would randomly stall during !Boot when > setting up networking, so I decided to cut my losses and gave it up as a > bad job. I'll have a look at "networkextension", just to see, though > I'm not too experienced when it comes to OS X development. Using Tunnelblick's TUN/TAP was what I did - it worked, but it wasn't exactly user friendly. I don't think I've tried it on anything post Mavericks, though. Apple does say: The com.apple.developer.networking.networkextension entitlement is required in order to use the NETunnelProvider class. Enable this entitlement when creating an App ID in your developer account. but according to StackOverflow (which must be true) that's no longer the case. (It may still apply to iOS). There are also things like: https://github.com/zhuhaow/NEKit that build on top of NETunnelProvider and handle the entitlement, like you do with Tunnelblick. > Peter did ask me whether I'd be prepared to create Mac binaries when I > emailed him previously off-list, and I "umm"ed and "ah"ed about it. It > really depends on how much work there is, and whether there are any > other oddities thrown up by OS X that need to be worked around (such as > the keyboard and networking). It would be nice to have a proper > installer as well (there is an installer builder in QT apparently, > though I've not investigated in any detail). I don't think there's much to do beyond putting the files in a .app bundle inside a .dmg archive? I don't think there's any need for an installer, users open the .dmg and just drag RPCEmu.app to /Applications. You'd probably put the Qt libraries inside the .app so there's no system dependencies, or even statically link. Looks like this is the tool to make a bundle including Qt libraries: http://doc.qt.io/qt-5/osx-deployment.html A wizard that's roughly 'what ROM image do you want', 'where do you want your hostfs to go' etc would be nice, but not critical. My Allegro binaries were pretty much fire-and-forget - I got a few people asking about stuff, but not a lot. Theo ___ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Patch for 0.9.1 - Mac keyboard support
On Mon, Nov 19, 2018 at 07:43:18PM +, Timothy Coltman wrote:
> Hello all
>
> Please find attached a ZIP archive (169K) containing a patch for RPCEmu
> 0.9.1 that implements keyboard support for OS X/macOS. The file contains
> a patch in unified diff format ("rpcemu-0.9.1-mac-v1.patch") plus a folder
> ("macosx") containing the icons for the Mac's dock. This should be
> unpacked in the "src" folder and the patch applied from there.
That's great. It looked so good until I came across the Qt keyboard
problem, so fixing that should improve the RPCEmu Mac experience a lot.
> 4. The patch uses virtual key codes and assumes a UK keyboard layout.
> There is support for other keyboard layouts, but needs these to be defined
> in the "keyboard_macosx.c" file (there is a very basic French layout
> defined that swaps "Y" and "Z").
I've had no end of problems with things getting keyboard layouts wrong on
MacOS (usually with remote connections to other machines where the other end
is set differently) so it wouldn't be the first time.
Does your layout handle US keyboards (it's usually \|~`#@" that get
into trouble)?
I usually use the 'British PC' layout on a Macbook Pro which is additional
fun because the keys are now moved around compared to the Apple layout.
> Please note that there is no networking support. I did try and get it up
> and running, using some of the code from the "Caliston" builds of Francis
> Devereux and whilst it did look promising at one point (I could ping from
> one end), I wasn't able to get it to work fully.
Those are my builds, and I never got networking to play nicely.
I wonder whether, instead of using TUN/TAP, on MacOS it might be worth
investigating NETunnelProvider as a native API for networking?
https://developer.apple.com/documentation/networkextension
That would make a much nicer user experience.
> Any comments and suggestions would be appreciated. If anyone wants
> binaries (so they don't have to compile), please let me know and I'll make
> some available in due course.
Peter may have other opinions, but AIUI he doesn't have any means of
producing Mac builds. It sounds like you're set up to do that, so you could
take over producing them from me - I didn't have any special infrastructure
for that beyond a very hacked up Xcode with Snow Leopard libraries - I was
just making random builds on my laptop from time to time. (and running any
kind of CI with MacOS is a pain, so they're not straightforward to automate)
Theo
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] PATCH: Implement OS_Reset "0x0ff"
On Wed, Oct 31, 2018 at 11:49:00AM +, Ralph Corderoy wrote:
> Hi Reuben,
>
> Couple of minor comments.
>
> > + /* Intercept OS_Reset to check for turning off
> > + https://www.riscosopen.org/wiki/documentation/show/OS_Reset
> > + */
> > + if (swinum == SWI_OS_Reset) {
> > + if (arm.reg[0] == 0x46464F26) { /* 0x0ff */
>
> It's "&0ff", not 0x0ff.
I think it's a bug in the webpage, but the hex spells ""
(letter oh not number zero, all capitalised).
PRM 5a doesn't mention any parameters to OS_Reset - can anyone confirm the
above hex number is correct for power off?
Theo
___
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPC Emu 0.8.14 on OS X High Sierra
On Thu, Oct 04, 2018 at 09:23:54PM +0100, Gerald Holdsworth wrote: > Hi Theo, > > I did have a read through that thread prior to posting this email - at the > moment I’m not into compiling the binaries, mainly due to my MacBook Air > only having 128GB storage (of which nearly half is used, through constant > removal of unneeded data every month). However, I should be getting > myself a second hand Pro with a 500GB hard drive, so these problems will > magically go away (to be replaced with a slower data access speed). Oh, I thought in that forest of links they had released a binary - my mistake. Maybe they can be prodded into doing so? (there isn't an official release process for the Mac versions of RPCEmu, because Peter and Matthew don't have a Mac, and the Allegro version of RPCEmu needed some horribleness done to add the ancient Carbon to XCode to make it build. It should be a lot easier with Qt, but at the end of the day it still needs someone with a Mac to push builds out the door) Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPC Emu 0.8.14 on OS X High Sierra
On Wed, Oct 03, 2018 at 01:16:11PM +0100, Gerald Holdsworth wrote: > Aha - using the Alt and Ctrl keys work. For what it's worth, it might be worth trying the new Qt version of RPCEmu, for which someone has fixed the keyboard issues on MacOS: https://stardot.org.uk/forums/viewtopic.php?f=30=15360 I haven't tried it, but I would expect a lot of the problems caused by the old RPCEmu using ancient Carbon APIs to be improved. (for the record, that thread says someone submitted a patch to the mailing list which was waiting for approval. So it's presumably stuck in the moderation queue, if moderators haven't yet dealt with it) Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Emulate other ARM processors?
On Thu, Mar 01, 2018 at 05:16:16PM +, J Percival wrote: > I asked the same thing a while back. I was under the impression that the > hardware was similar. As I understand it, ARM2 code will run fine on a > StrongARM for instance (although needing to turn off the cache if the code > is self-modifying). Back in the day, there was the 'GameOn' utility - apart > from the cache control (and better support for old-style screenmodes > maybe?) I'm not sure what it did to achieve compatibility with many games - > possibly patching them - but I think the differences weren't too > significant - usually in these cases it's software that assumes a very > specific environment that fail. It's possible that Arthur/RO2/RO3 would run > on a Risc PC - don't know if anyone has tried it. It would be nice to have > accurate emulation of older systems though as things like tech-demos are > particularly sensitive to the configuration of the underlying (emulated) > hardware. There are several thing to de-conflate here: 1. The user-level instruction set. ARMv4 (StrongARM) is largely a superset of ARMv2 (ARM2/3) so minimal changes are required here (see 'StrongARM compatibility' notes of old) 2. The system-level CPU model. Exception modes and the MMU changed quite a lot between ARM3 and ARM6, and the caches changed between ARM3, ARM6/7 and StrongARM. 3. System I/O, for instance video, timers, keyboards, interrupt sources, motherboard chips. Some effort was put into making IOMD and VIDC20 be a superset of IOC and VIDC1, but there are enough changes to make them incompatible. #2 is the big one. Arthur/RO2/RO3.1 would not work on a Risc PC without a lot of code changes - the result of those changes is called RO3.5. So best stick to Arculator if that's what you need. Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu pre release test version 0.8.99
On Fri, Oct 20, 2017 at 11:56:56PM +0100, Chris Gransden wrote: > Due to there being a port of Qt5 available for RISC OS RPCEmu now runs on > RISC OS. :-) I've only tried RISC OS 5 so far but everything seems to work > OK apart from keyboard input, sound and networking. I think this is a > limitation of the RISC OS port of Qt5. It was also straightforward to compile for Mac, and it boots and sound works. Keyboard doesn't work, because macOS doesn't provide QKeyEvent::nativeScanCode() I think it might be possible to cobble up something from guesswork based on other fields provided by QKeyEvent:: but it won't be perfect. In particular it can't distinguish left/right Shift, and caps-lock-off doesn't generate events. I think the numeric keypad might be unavailable too. It also may not play nicely with different Mac-side keyboard layouts. My guess would be RISC OS Qt would need something similar - either an implementation of nativeScanCode() and a keyboard_riscos.c translation to PS/2 codes, or a fudge as above. Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu and MacOSX
On Thu, Apr 21, 2016 at 03:37:12PM +0100, Martin wrote: > In article <20160421123610.gd11...@chiark.greenend.org.uk>, >Theo Markettos <t...@markettos.org.uk> wrote: > > How about something like: > > > #!/bin/sh > > PARENT_DIR=$(dirname $0) > > HOSTFS_DIR=$HOME/Library/Application\ Support/RPCEmu/hostfs > > cp -a $PARENT_DIR/source $HOSTFS_DIR/target > > open /Applications/RPCEmu.app > > Thanks Theo, I think I can sort of follow what that is doing. > The last two lines are pretty obvious - I hope the middle two lines work > as the syntax is not (yet) obvious to me. I'm just setting a couple of variables that we can use later on. That's not strictly necessary, but just being tidy rather than using them in-place. $(dirname $0) calls the 'dirname' command on $0 and returns the output as a string. $0 gives the filename of our script so 'dirname $0' is the parent of our script, like <Obey$Dir> > Is the # a comment line? Yes, and no. It's called the 'shebang', and must be the first line of the file. It tells the OS the location of the program that will interpret the script. In this case it's /bin/sh (the Bourne shell), but it could be /usr/bin/python or /usr/local/bin/brandy or whatever. You can alternatively do: #!/usr/bin/env python to find python anywhere (it'll be in different places on different systems) [None of this is Mac specific, it's standard Unix shell scripting] > Is the 'obey' file just a text file, called anything, with no suffix? Suffix doesn't matter - though it's conventional to add .sh - but you'll need to make it executable. You can do that from the Finder, or at a terminal: chmod +x my-script > Yes indeed - I tried to follow your excellent instructions to the letter! > The RPCEmu application is in Applications, and the data directory in > Documents. Not my instructions, but they are indeed very handy. Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] RPCEmu Mac OS X test build of 0.8.14
I've made a test build of 0.8.14 for Mac, which you can find at: https://bitbucket.org/caliston/rpcemu-spoon-caliston/downloads I've also applied a patch from Sprow to support 4GB files. I have only done the minimal amount of testing, but it seems to work for me. Other than rebuilding, outstanding problems (eg lack of Retina support) will remain. Please let me know if there are any new bugs this has introduced. Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] This geriatric is confused...
On Mon, Jan 04, 2016 at 08:27:20AM +, Robert Sprowson wrote: > In article <20160103232353.gs17...@chiark.greenend.org.uk>, >Theo Markettos <t...@markettos.org.uk> wrote: > > That sounds like a good idea. It would probably want adding to the RISC OS > > makefile - worth asking the ROOL folks what would be required. > > If by "natively" Richard means a sprite file gets called "!Sprites,ff9" then > I don't think changing the makefiles that ROOL runs will help since they run > on a RISC OS box which makes ZIP files without HostFS extensions. > > You need something that ZIPs from outside of RISC OS (Windows/Linux/Mac) view > of the image, There's two parts: 1. Putting the files in the right places (including EtherRPCEm bits etc) 2. Converting zipfile filetypes to ,xxx 1. is perhaps best done in the RISC OS makefile 2. is do-able on Linux with a simple: unzip -F old-harddisc4.zip zip -rv9 new-harddisc4.zip * unzip's -F flag already knows how to deal convert RISC OS filetypes to ,xxx if you compile it with the ACORN_FTYPE_NFS option enabled - some Linux distros already do that, others need it enabling in a special build. The native-unzip package in GCCSDK builds it like that. This is not hard to do server-side, it's just a case of working out which server to run it on. Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] This geriatric is confused...
On Sun, Jan 03, 2016 at 04:55:43PM +, Richard Walker wrote: > What would be nice would be a ready-to-go version of HardDisc4 from ROOL > in a ‘ready to extract into the HostFS directory natively’ mode. I guess > it should be reasonably trivial to set up something like that which tracks > the nightly HardDisc4 builds, come to think of it. That sounds like a good idea. It would probably want adding to the RISC OS makefile - worth asking the ROOL folks what would be required. Alternatively, if someone feels like writing a shell script to put bits in the relevant places, we can plug that into the riscos.info autobuilder infrastructure - http://gccsdk.riscos.info/ and http://ci.riscos.info/ Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCEmu 0.8.13
On Fri, Oct 23, 2015 at 11:49:14AM +0100, Theo Markettos wrote: > On Fri, Oct 23, 2015 at 10:17:07AM +0100, Gerald Holdsworth wrote: > > >A new version of RPCEmu is available, 0.8.13 > > > > Nice, well done - but not for the Mac. > > > > Would it be worth putting the 0.8.12 Mac build on the 'contributed > > builds' on the page? > > https://bitbucket.org/caliston/rpcemu-spoon-caliston/downloads > > Let me do a test version, and if it hasn't broken anything that can be a > 'proper' 0.8.13. I have now built 0.8.13, that was straightforward. It's now on the above download page. It has received very little testing - it boots RISC OS 5 and seems to work for me. I believe it's still subject to the usual UI bugs - in particular there's no change on (lack of) Retina support. Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] HostFS problem
On Fri, Aug 07, 2015 at 03:25:38PM +0100, Sprow wrote: You could ask Theo nicely to try applying this patch to his Mac build: The underlying problem is that RISC OS has no concept of character encoding of filenames. So change your alphabet and your filenames will change, and there's no way to find out what encoding they're supposed to be. This is a bit of a headache because RISC OS 5 can use Unicode (UTF8) filenames, which is what Mac or Linux are probably using, while Windows probably uses UTF16. 0xA0 is not a valid character in UTF8 or UTF16, hence lots of fun ensues. Because most RISC OS users are in Western Europe their encoding is probably ISO8859-1, but not necessarily. Anyway, in the interests of perpetuating the status quo and not fixing the underlying problem (it /is/ Friday afternoon), I've applied Sprow's patch. That almost worked - I had to bodge it to use unsigned chars (which it should be doing throughout, but I wasn't minded to change). New zipfile 0.8.12-caliston-dev2: https://bitbucket.org/caliston/rpcemu-spoon-caliston/downloads I haven't given this more than a minute of testing, so feedback appreciated. Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Mounting arbitrary ADFS images?
On Thu, Jul 23, 2015 at 10:07:12AM -0700, David Glover-Aoki wrote: Is there any way to mount them inside RPCEmu? I tried renaming one to “hd5.hdf”, but trying to open it just results in a Disc Error. You probably need to set the LBA flag in the image: https://www.riscosopen.org/forum/forums/10/topics/2032 Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] A serial device?
On Thu, Feb 04, 2010 at 11:02:51AM +, Johann Myrkraverk Oskarsson wrote: I've already begun to look at the docs for FDC37C665GT as well as superio.c, curtesy of filth on #playpen, freenode. The '665 is pretty much exactly a 16C550 clone in the serial port department, so there is plenty of other documentation out there. Right now I have only one question: What happens when the real UART doesn't support the same baud rates as the chip we're emulating? I just checked, and according to the OpenSolaris driver sources, my UART does not have all the speeds listed in the hw docs. It is safe to assume this will be the care for many real serial ports/UARTS out there. It depends on how low level access you have. Assuming the serial hardware is roughly similar, the divisor registers on 16Cxxx devices (which form most PC serial ports) can set up a wide range of baud rates, not just 1200, 2400, 4800, 9600 etc etc. But you may not have access to the raw divisor values - the OS may only allow you to pick from a fixed list. I'm not sure of the best way to handle rates that don't fit. 99% of people will just use the standard rates, so it probably isn't a big problem. The only use I can think of strange rates is ancient 1200/75 modems (which connected to online services that no longer exist). Certainly emit a warning. Maybe set the FDC37C665 divisor 'registers' to the closest you can do, which will be apparent if something tries to read them back (but I don't think this helps much, since I assume RISC OS keeps its own copy of the baud rate it previously set) I think you just have to emit a warning and carry on as best you can. The wierd rates will probably never get used for real anyway. Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] An idle loop?
On Sun, Jan 31, 2010 at 05:35:57AM +, Johann Myrkraverk Oskarsson wrote: On Sat, Jan 30, 2010 at 11:40 PM, Theo Markettos rpc...@markettos.org.uk wrote: [Sleep] Thank you. It seems to work fine here. I have not noticed any disturbance yet. Perhaps better granularity can be achieved by calling nanosleep where available? I'm not sure that's the problem... the problem is something to do with mouse/button presses getting lost while the emulator is sleeping. RISC OS only has a centisecond timer, so it shouldn't be affected by microsecond-scale sleeps. It stalls for IO, so they should be expected anyway. I think it's a problem with the emulator missing things rather than the OS. RISC OS also calls the SWI Portable_Idle when it is idle, so that's a potential mechanism to release some of the CPU. I can't remember if RPCEmu makes use of that. If you point me in the right direction I *may* look into it, depeding on time and other constraints. If you do, keep in mind I have zero exp. points (rpg talk) in risc os programming. OK, here goes. The RISC OS 3 Programmer's Reference Manual is here: http://foundation.riscos.com/Private/manuals/ (There isn't really a RO4/5/6 PRM, only supplementary volumes for new features) Google reminds me that I got my facts slightly wrong, and it's Portable_Speed that may be of use. Have a read of this thread: http://www.riscos.info/pipermail/rpcemu/2009-April/000569.html A bit of background... the A4 laptop had a 24MHz CPU clock which could be reduced to 6MHz when the CPU was idle. Portable_Speed is the call used to do that, which is why it's such a blunt interface. It appears it's still called from modern OS code, unless RISC OS Ltd have tidied it away in their sources. The Portable module is documented on page 4-205, in other words page 205 of PRM4.pdf The simplest way might be to receive the calls to Portable_Speed in the emulator and convert them to cause more or fewer sleep calls. The emulator already traps some SWIs for its own purpose, so in the emulator core you can see where it calls some routine rather than the emulated ARM SWI handler. See line 2744 and following of arm.c: http://home.marutan.net/hg/rpcemu/file/fe24032a009b/src/arm.c The JIT version of that code is in opSWI() in ArmDynarec.c That would be a less clumsy way of doing things than the Sleep program, though it needs to not miss UI input. Possibly running variable amounts of system load might be one way to simulate this problem. [Note to mailing list folks: I'm a bit out of date, so feel free to point out where I've gone horribly wrong] Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Alternative to HostFS, EmulFS
On Tue, Nov 10, 2009 at 10:05:45AM +0100, Timmermans, Andre wrote: I wonder if another filing system could be written that would allow access to folders on the PC side while RISC OS file types from the RISC OS side with the help of Mimemap in a LanManFS style? This would allow the RISC OS side to access mp3, jpegs, videos, etc collections without having to copy them into a specific folder nor having to fiddle with their filenames to insert the RISC OS type. That should be a relatively small change to EmuFS, to just alter the filetype algorithm slightly for particular shares/folders. I'm not sure on the current state of multiple EmuFS drives, but it's certainly possible to do symbolic links to different filesystems on Linux, and NTFS has a roughly-similar feature. This could be indicated at least two ways: From a configuration file on the host side Or using the RISC OS filesystem special field, eg HostFS#mime::DriveD.$ Would you want Mimemap to happen on RISC OS rather than the host? It gets a bit more complex because then you couldn't boot from such a filesystem, since you need to tell Mimemap where its configuration file lives first. I suppose that could be done from an emulated podule ROM. For speed it might be quicker to use the same Mimemap file as RISC OS, but interpret it on the host side. Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Improving CPU usage when idle
On Sun, Apr 05, 2009 at 07:23:43PM +0100, Jake Waskett wrote: What we *ought* to do is to record (and queue) the event whenever we're notified that the button state changes. We can then pass these state changes to RISC OS through simulated interrupts. Fortunately the exact timing of the events doesn't matter too much, as long as the relative timing is preserved. This shouldn't be too hard to do if we tag each queue entry with a timestamp. Most GUIs give us these events (as well as keyboard events, which should be dealt with in a similar way) through their event queue -- X11 and Win32 both work this way -- but Allegro is hiding this behind a sub-optimal abstraction which can lose information. It's possible that we can make use of Allegro's mouse_callback (and keyboard_callback, I guess), however. So I wonder if it would be feasible to have a separate user input and timer thread? This queues up mouse and keyboard events, and runs the timers. Each mouse/key event is supplied with a timestamp, which is delivered to the emulator as an interrupt. We have to be a bit careful, because in the real hardware there's no timestamp supplied with events: the OS just reads the central timer sometime after the interrupt is received. So presumably we can cause the timer to jump forward to the time of the click, but we have to keep on incrementing it afterwards. This means that things that check whether a long enough period has elapsed between events (eg key auto-repeat) may fail if the timer keeps getting incremented by the thread but the interrupt service routine on the emulator hasn't got run because the machine is so busy that the CPU thread hasn't got run yet. First, create a fairly simple thread-safe queue implementation. Each entry needs to contain: an event type (initially mousebuttonup or mousebuttondown), some associated data (eventually keycode, mouse position, etc), and a timestamp. Second, install a callback for mouse (and eventually keyboard). These simply create an event and append them to our queue. Third, modify pollmouse() to process the queue instead of polling the mouse directly. (It'll also need to take account of the timestamps.) Finally, the semantics of nanosleep() should be changed to something like: * if our event queue is not empty, do nothing. * else, sleep until an event is posted to the queue, or a timeout occurs (simplification: treat a timeout as a special kind of queued event). (This requires a small amount of platform-specific thread sync code, unfortunately.) * as long as callbacks are invoked from a separate thread (as I think they must be), then this should work. That's a similar idea... but better thought out! Looks feasible. What do emulators of other hardware do regarding UI timing? It must be a common problem. It's not all that great: sleeping for a microsecond doesn't give the host's kernel much of a chance to do anything. It can switch to another process, but it's too short an interval for it to be worth entering a power-saving state. True, I hadn't thought about putting the CPU into idle, I was more assuming that if the CPU load was reduced the (Centrino/whatever) CPU clock would be reduced. The system load would increase, but it would still get the jobs done under the lower clock. It's not *exactly* what the Sleep program does. The Sleep program polls the Wimp for messages, and invokes the NANOSLEEP SWI whenever the reason code is 0 (idle). But I think this is a bit too aggressive, and I would expect it to interfere with the performance of other tasks (eg taskwindows) that use idle to perform background processing. What we really want to know is if a) the Wimp is idle, *and* b) no other tasks are performing idle processing. Most tasks will mask out reason code 0 if they don't intend to use it, so the Wimp should be able to detect this state. Whether this helps us is of course another matter! That's true. Probably a Wimp filter would return you that information... (Pity we can't access the Wimp's idle loop directly) The simplest method for guessing the system load is to measure elapsed time between Wimp_Polls that return reason code 0. If the period is very small, then it's likely that not much else is happening in the system. So, for example, if Wimp_Poll returns reason 0 ten times in a row, and each time is less than a millisecond after the previous event, we can probably assume that it's safe to nanosleep(). These figures are obviously guesses, and better values could probably be obtained through testing. Sounds plausible. Now here's an interesting thing. According to the documentation for the Portable module, there is a Portable_Idle SWI (0x42fc6), which is defined to basically stop the CPU until something interesting occurs. In other words, exactly the same semantics as a select() on an XLib socket (or MsgWaitForMultipleObjects in Win32).
Re: [Rpcemu] Risc OS 4.39 hangs on networking
On Thu, Mar 26, 2009 at 10:53:11PM +0100, Gillian Seed wrote: Good news everybody. What? AppleTalk! Yes off course RISC OS 4.39 has AppleTalk in ROM and 4.02 hasn't. So I unplugged the damn thing and EtherRPCEm works fine! I successfully connected to internet with it without any problems. That's excellent news! It looks like that AppleTalk doesn't behave itself or that EtherRPCEm isn't robust enough. So I suppose the question is... does the TUN/TAP stuff do anything different with non-IP protocols? I wouldn't have thought it would, but you never know. It looks like AppleTalk multicast might be the problem. Apparently it uses it extensively for naming and advertising services, issuing up to 20 requests at startup. I found some old (2001) stuff about Linux TAP only supporting AppleTalk if the multicast flag is enabled in tap.c (which I assume is therefore a kernel compilation option). It's not quite clear what the current situation is, but I've found a plenty of comments that suggest people are having possibly multicast-related problems with random software. Such as this: http://openvpn.net/archive/openvpn-devel/2004-04/msg00032.html https://lists.linux-foundation.org/pipermail/virtualization/2008-July/011289.html However, it's quite possible that what it needs is multicast support in RPCEmu's TAP code. Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Risc OS 4.39 hangs on networking
On Tue, Mar 17, 2009 at 03:39:48PM +0100, jan rinze wrote: Ok, so you have the same results. Does anyone here know why the module hangs? or where? I've looked into it. EtherRPCEm (IIRC) hangs on a real RO4.39 RPC, so I'm fairly sure the problem is in the module. First I thought it was the callback veneers, but replacing with those in the EtherY module (from which EtherRPCEm is derived, and runs OK on RPCEmu/RO4.39 even if there's no Castle Ethernet hardware) shows it doesn't make any difference. Then I thought there was something up with the service call handler, but service calls seem to be despatching OK. AFAIK it's something happening /after/ a service call is received, but given the DCI4 startup process is replete with service calls this doesn't help that much. What I don't understand is what's changed since 4.02 (and couldn't see anything notable in the logs). Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] RPCemu problem with Windows Shortcut
On Thu, Feb 05, 2009 at 08:07:12AM +, Bernard Veasey wrote: When I then double-click the RPCemu icon on the desktop, instead of it looking for the cmos.ram and hd4.hdf files in the 'Program Files\RPCemu' folder, it looks for them on the desktop and as it can't find any, it creates new ones there. Right click over the shortcut, choose Properties. 'Start here' is the directory in which the program is started, so set it to C:\Program Files\RPCemu or whatever. Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Networking questions - 0.8.1
On Tue, Jan 27, 2009 at 11:23:33PM +, Timothy Coltman wrote: Using 4.02 I get exactly the same error. I've had a look at the source for the module and there looks to be an error: cmhg.ModHdr says swi-chunk-base-number: 0x58cc0. Presumably this means that any SWIs issued by the module will start from this number. However, the code in s.intveneer is issuing 56ac4. If this is an EtherRPCEm SWI, shouldn't it be a 58cc0 number? No: EtherRPCEm_ SWIs start at 58CC0. These are mostly DCI4 functions called by the Internet stack, involved in getting the driver chain established (along with various service calls, because the modules can be started in any order). ArcEm_ SWIs begin at 56AC0. There isn't a module that implements them, the emulated hardware SWI vector intercepts them and sends them off to the native Linux/Windows/etc (networking/HostFS/etc) code. It should then return to the ARM code caller in a manner that looks like the SWI dispatched correctly. The RISC OS SWI dispatcher should never see these SWIs being called. (And thus the SWI names probably don't exist as far as RISC OS is concerned) In effect EtherRPCEm is translating calls from the Internet module (the EtherRPCEm_ SWIs are fairly incidental here - most of the work is done by direct function calls by Internet into EtherRPCEm) into ArcEm_ SWIs which call the emulator. In this case EtherRPCEm is a fairly thin translation layer - all of the interesting networking stuff happens in the emulator's native code. I don't know why RPCEmu isn't intercepting the 56AC4 SWI, but that's the problem: RISC OS is bouncing it because it hasn't been intercepted by the emulator. That would be where to look. Are you sure your emulator has networking enabled? In the code (in arm.c or ArmDynarec.c, search for ARCEM) the Linux network support would seem to be #ifdefed on RPCEMU_LINUX. Are you trying to run the EtherRPCEm module on a platform that isn't Linux? Tom's Windows networking code works differently: http://www.riscos.info/pipermail/rpcemu/2007-November/60.html but I don't know where it fits in with the current sources. Unfortunately I can't recompile it to try it out as the 1996-vintage C/C++ suite I've got doesn't like some of the assembly code. See attached for a copy of the output from objasm. Warning: MRS/MSR invalid in 26-bit PC configurations at line 114 in macro ToSVCEAll You can build 32 bit stuff with Acorn C v5, but I think you need some extra options. A quick Google suggests you may want '-apcs 3/32bit'. But I don't think you want to be changing the SWI called :-) Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] how to emulate the middle mouse button
On Fri, Jan 02, 2009 at 11:13:01PM +, Paul Stewart wrote: Hi, I have RPCEmu installed. The keyboard/mouse I am using is a combined unit that only has the two mouse buttons. Is there anyway in RPCEmu to emulate the middle button? I'm not sure about RPCEmu, but see if pressing both buttons together works as the middle button. That's what happens on my laptop in both Linux and Windows. Which OS are you running RPCEmu on? Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
[Rpcemu] Path-searching specification
I've been having a look at my patch to split up the RPCEmu directory tree
into different paths, for ease of packaging. I've made most of the changes
as various people have suggested, but I thought before I go any further it
was worth discussing the design. So I've put together a basic specification
below. Comments would be welcome.
The outline is that users should be able to configure their own RPCEmu as
they wish, and the configuration file lives at ~/.rpcemu/rpc.cfg. If they
don't do that, RPCEmu should look for files in their home directory at
~/.rpcemu/ If they can't be found there, it should look system-wide in
various directories whose position depends on the distribution, and is
determined by the parameters supplied to ./configure
Old-style installs, being those compiled without autoconf (ie on Windows) or
that are configured with --enable-portableinstall, should find all the files
in the executable's directory. They'll still look in ~/.rpcemu/* but if
they don't find what they need (which is likely) they'll drop back to the
executable's directory.
Specification is below. One thing I'm not yet happy with is the naming of
ARMCODE_DIR and similar - it's not very obvious and I'd prefer ROM_DIR. The
trouble is that 'roms' currently doesn't cover all ROMs. Perhaps we could
have a hierarchy that looks something like this:
roms/
roms/systemroms/
roms/systemroms/riscos402
roms/poduleroms/
roms/poduleroms/EtherRPCEm,ffa
And then define ROM_DIR to be the top level roms/
How does that sound?
I'm probably not going to have much of a chance to work on this between now
and February, so if anyone wants to work on this I can post a patch of where
I am right now.
Theo
RPCEmu filesystem specification
---
Notation a bit vague, roughly:
$FOO = Unix environment variable 'FOO'
%FOO% = Windows environment variable 'FOO' (these two are both read with
getenv())
--foo = Result of defining --foo on autoconf ./configure command line, or
inherited
from other ./configure settings. If we supplied --foo=/bar/baz on the
command line, here --foo/joe denotes /bar/baz/joe
FOO = C preprocessor definition passed in on compiler command line from
./configure
@foo = C language variable (just for this algorithm)
{
If we didn't configure with autoconfed paths
define all the autoconfed paths
CONFIG_DIR/ARMCODE_DIR/CMOS_DIR/LOG_DIR/DRIVES_DIR
to point to the executable's directory
Configuration file search:
try @configfile=$HOME/.rpcemu/rpc.cfg
if @configfile doesn't exist
{
try @configfile=%HOMEPATH%/.rpcemu/rpc.cfg
if @configfile doesn't exist
{
@configfile=CONFIG_DIR/rpc.cfg
(CONFIG_DIR comes from autoconf, --sysconfdir/rpcemu)
}
}
if @configfile exists
@configdir=~/.rpcemu
if @configfile doesn't exist (ie nothing in CONFIG_DIR)
we can't read the configuration file, so assume the autoconfed defaults
(last resorts below)
else
{
we try to read the following tags:
try @armcodedir=value of armcode_dir tag
if tag exists, read all armcode files from @armcode dir
else
try to read armcode files from @configdir/
if that fails, on last resort:
read from @armcodedir = ARMCODE_DIR from autoconf, --datadir/rpcemu
The same for:
try @cmosdir=value of cmos_dir tag
last resort, @cmosdir = CMOS_DIR from autoconf,
--localstatedir/lib/rpcemu
try @drivesdir=value of drives_dir tag
last resort, @drivesdir = DRIVES_DIR from autoconf,
--localstatedir/lib/rpcemu
try @logdir=value of log_dir tag
last resort, @logdir = LOG_DIR from autoconf, --localstatedir/log/rpcemu
}
}
___
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] [Fwd: Re: HostFS and multiple discs]
On Sat, Nov 29, 2008 at 01:14:33PM +, James Woodcock wrote: Sounds like a good starting point. I'll probably add a third option to specify read-only or read-write. I may split it up into 3 lines (for readability, and for Windows/MacOS which is more likely to have spaces in the path): hostfsname0 = Boot hostfspath0 = ~/hostfs hostfsperm0 = read,write Good idea. I don't know if you want to tweak the naming slightly so it's more readable? How about: hostfs.drive0.name = Boot hostfs.drive0.path = ~/hostfs Or: [hostfs.drive0] name = Boot path = ~/hostfs (Allegro supports sections in config files like this) hostfsperm(n) would default to read-only, I think. I see potential for confusion here. If you do that, this should perhaps be made obvious to the user in some way. You could give a message on startup: HostFS drive name mounted read-only at path: to change, add 'hostfs.drive3.path = rw' to rpc.cfg (but are users going to read that, if rpcemu's started from a menu?) Or make sure some very obvious comments are output into rpc.cfg? (I've forgotten if rpcemu actually saves that file at any point - if it does the comments would need to be rewritten) Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] HostFS and multiple discs
On Thu, Nov 20, 2008 at 08:59:17PM +, James Woodcock wrote: Hi, I have attached a patch that enables support for multiple discs in HostFS. I haven't looked at the code in detail, but it looks like a sensible idea. A question: how does HostFS know which drive to boot from? If you *Configure FileSystem HostFS you can boot from a HostFS share. But it's not a FileCore filing system so *Configure Drive has no effect. Might it be possible to configure this in some way? Is it worth arranging for mounts to be configured in rpc.cfg? Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Networking help?
On Fri, Sep 19, 2008 at 03:57:50PM +0200, Gillian Seed wrote: Doesn't work. I guess it's only used by ifup/ifdown to (de)configure the interface. And now I also get an error when I start up the machine that it can't configure interface tap0 as it's not there. Yes, that's right. I see there could be a problem if the device doesn't exist at boot time. Is the problem that rpcemu creates the tap0 device and it immediately is configured for IPv6, which clashes with how rpcemu sets it up. Or does the tap0 device need configuring in any case? I've had a quick Google... try installing the uml-utilities package and playing with tunctl. Sure. Just tell me were and how to do this. I also would like to write a small manual how to download/compile/configure rpcemu to get it fully working. The best place would be the wiki page: http://www.riscos.info/index.php/RPCEmu If you don't already have an account, the registration system is currently broken. But you can write the wiki markup on your favourite MediaWiki system, like the sandbox in wikipedia: http://en.wikipedia.org/wiki/Wikipedia:Sandbox and email it to me and I'll put it up. Or even just mail me text and I'll format it. For how to edit riscos.info, read: http://www.riscos.info/index.php/How_to_edit Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Patch to 'make install' - configurable file paths
On Sun, Aug 31, 2008 at 09:11:18AM +0100, Ned Abell wrote: I like the suggestion of putting the drives in a more rational path than the the executable but is there a reason for not using /media or /mnt ?. Im new at this so please humour me:-) Simply that Debian decrees where particular bits should go in the filesystem: very roughly /media is for dynamically mounted devices (like USB sticks) and /mnt is for manually mounted devices (like hard drive partitions). Part of my idea was that you have a drives directory somewhere, but you don't have to have any files in it. You can then create symbolic links to whereever the files actually are. So I'd envisage something like: /var/lib/rpcemu/drives/ containing symbolic links like: /var/lib/rpcemu/drives/hd4.hdf /var/lib/rpcemu/drives/hostfs where the actual files can be wherever you like. But this place (/var/lib/rpcemu) needs to be defined by default so that users know where to look in the first place. My patch also allows this location to be configured in rpc.cfg so you don't actually have to have anythingin /var/lib if you don't want to. That's where it would go on Debian, but not on Windows and probably other places on other systems. Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Patch to 'make install' - configurable file paths
On Sat, Aug 16, 2008 at 10:33:18PM +0100, Theo Markettos wrote: As part of a push towards making RPCEmu packageable, I've spent today tidying up its use of paths. The patch below still has a few rough edges, but it makes RPCEmu much more compliant with things like the Debian Filesystem Hierarchy Guidelines. Opinions anyone? I don't mind if anyone wants to disagree with the patch or thinks it needs revising, but some feedback would be good :) Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Just starting
On Wed, Aug 06, 2008 at 07:03:14PM +0100, P.J.G. Long wrote: I hope you won't mind some silly questions I have compiled rpcemu on effectively a debian etch system, using 3.7 roms 1) It seems to start very quickly, giving mips readings 110 all the time Good :) 3) However at start up I get a) a message in the terminal window saying updatewindowsize: 640 256 updatewindowsize: 640 480 That's just some debugging output - RISC OS has changed screen mode and that's the emulator noticing. b) a Warning window Invalid shut down state detected in CMOS Your emulated CMOS RAM checksums don't match - that'll be because the default CMOS image isn't for RO3.7. Boot rpcemu with Delete held down (simulating a power-on-Delete in RISC OS) and RISC OS should reset its CMOS. 4) Any attempt to increase the screen resolution from 16 cols 640x480 is met with greyed out menus, is there a way around this? Screensize seems to be 320K, vram=2M Do you have a boot sequence on the emulator? Until a modefile is loaded you won't be able to select modes other than numbered one (eg mode 32, 800x600x256 cols). Either install a full boot sequence, or put a modefile on the emulator and do *LoadModeFile path to modefile 5) How is HOSTFS started, I seem to have tried all possibilities of *configure filesystem hostfs Is the HostFS module getting loaded? It should be - check it shows up under *Modules. You'll need a directory called 'hostfs' at the same level as the rpcemu executable. Put your files in there. Normally HostFS is run from the emulated ADFS image (in !Boot.Choices somewhere), so you can't configure it as the default FS. But if you copy the module into a 'podulerom' directory then RPCEmu will build a fake podule ROM to load the module at startup, and you should be able to *Configure Filesystem it. (I haven't tried this). Hope that covers everything :) Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
Re: [Rpcemu] Clock on RPCemu
On Fri, Jun 13, 2008 at 11:43:11AM +0200, Steffen Huber wrote: Fact #1: during startup, RISC OS asks via IIC its hardware realtime clock for the date and time and takes a soft copy of it. SWIs in RISC OS which deal with asking for date and time always work on the soft copy. Fact #2: after startup, the soft copy is incremented by a Timer (I think it is Timer 0, but I'm not sure). The hardware realtime clock is not used anymore (only if the time is set, the hardware clock is also adjusted). Yup, that's right. In fact it's how most OSs do it - but some Linuxes writes back the soft-copy of the RTC to the hardware clock (especially if the soft copy has been adjusted by NTP etc). Talking to hardware devices is too slow to be done frequently, which is why it keeps a soft copy. You're right in that it's IOC/IOMD Timer 0 - I once fiddled with the reload value of the timer to make my system 'hundreds of times faster'. All it did was make the system time increase at a very rapid speed :) So RPCemu should - if it detects a restart from hibernate (don't even know if this is easily possible...) - probably sync the PC clock with the RISC OS clock again. Then, everything should work fine. In RISC OS there's the RTCAdjust module which will try to keep the soft-copy in line with the hardware copy. The reason is to ensure applications aren't confused. Imagine if you discover the hardware clock is running a minute behind the soft clock - for apps time would either go backwards or stand still. RTCAdjust smooths the transition so time is still increasing but at a slower rate. FWIW the same problem happens on Virtual Risc PC. What might be easier than trying to detect a 'restart from hibernate' (which is different for every platform) is to periodically write the correct system time values into the emulated CMOS 'registers' ready for RTCAdjust to pick up. If you repeat this on the basis of 'if over a minute of real time has elapsed since the previous time we did it' then it should pick up hibernation periods longer than a minute, and also correct any drift due to RPCEmu's emulated IOMD Timer 0 being slightly out. It might require a bit of re-engineering of RTCAdjust - I don't know if it can cope with multi-day delays. But if necessary someone could ask ROOL to release the sources to it if it isn't already. Theo ___ Rpcemu mailing list Rpcemu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
