Hi, I've completely broken the other frontends, but here's the results of another week of working on ArcEm:
* Source: http://www.phlamethrower.co.uk/misc2/arcem-src.zip * RISC OS build: http://www.phlamethrower.co.uk/misc2/arcem.zip Changes (or at least as much as I can remember): * Made various minor tweaks/optimisations to the ARM emulator core. I think they only resulted in around a 16% net performance gain on an Iyonix. * Tidied up the source code a bit by ripping out the remnants of the RDI code and the unused/broken ARM assembler files * Added some very hacky profiling code to the main loop, which I used for the performance optimisations. It'll only work on Iyonix or Cortex-A8 hosts running RISC OS, but gives some nice (if somewhat inaccurate) stats on how much time is spent in each part of the core, and in each instruction execution function. Unfortunately having it enabled also cripples the performance, and it probably won't work at all now that I've made some of my other changes * Enabled extension ROM & HostFS support for the RISC OS frontend (I know that the binary on riscos.info has these enabled, but that uses the X frontend instead of the single-tasking RISC OS one) * Added an alternate HostFS implementation (riscos-single/hostfs.c) for when the host OS is RISC OS. Basically just to bypass all the filename translation stuff and to allow file attributes to be set properly. * Replaced the existing primitive event scheduling code with a simple priority queue implementation, and updated all the existing events (sound, video, keyboard, HDC/FDC, IOC, etc.) to use it. Events are scheduled using ARMul_Time (i.e. the main cycle counter) as the time base. See the eventq.c & eventq.h files, and the event dispatch code in ARMul_Emulate26) * Added sound support to the RISC OS frontend (riscos-single/sound.c, riscos-single/soundbuf.s), and rewrote the core sound code (arch/newsound.c). The existing core sound code was rather broken (1 channel output worked, but 2+ would mostly be garbage) and didn't seem to be structured too well from the perspective of delivering data at a consistent rate. At the moment I've only updated the RISC OS frontend to use the new sound system, but updating the other frontends shouldn't be too hard. * Some notes about the RISC OS sound support - initially I tried just using the existing X/Linux code (which would end up going via the DigitalRenderer module), but ran into problems because DigitalRenderer seemed to (a) be clamping sample rates to be between 5kHz and 50kHz, and possibly (b) didn't seem to be doing any sample rate conversion at all. So instead I fell back on some simple code I wrote a while ago which uses SharedSound. However the way UnixLib's environment handlers work seems to differ from the SharedCLibrary, so the code which should clean up the sound handler if the emulator crashes currently isn't getting called. So until I fix that (probably just register a few extra signal handlers, similar to the one I needed to get it to clean up on Escape) try not to make the emulator crash or your whole machine will go down. * I wanted the new sound code to perform DMA fetches at intervals that are approximately correct, or at least as far as the host clock is concerned. Since the only existing time base (ARMul_Time) is based around the number of emulated clock cycles, I added code to calculate the ARMul_EmuRate value, which measures the (approximate) number of ARMul_Time cycles per second. By combining this with the event queue it's possible to get events triggering at fairly accurate real time intervals. * However since ARMul_EmuRate isn't perfect (especially if there's a sudden change in performance) the sound code also has a Sound_FudgeRate value which the frontend code can use to fine-tune the DMA rate (since in the new system, the core is in charge of when the frontend receives new data). The RISC OS sound code uses this fudge rate to try and keep the SharedSound buffer at a healthy level. * Rewrote the video code. The old DIRECT_DISPLAY code, and the non-DIRECT_DISPLAY code is gone. Instead there's a new system designed solely around using the event queue to trigger one event each scanline (or every N scanlines) and updating the correspodning scanline in the host display buffer. At the moment it assumes that the host doesn't need to be told which parts of the buffer have been updated, but it shouldn't be too hard to add that feedback. As each scanline is processed it's depalettised, producing true-colour output. The RISC OS frontend currently uses a 16bpp display buffer, but a couple of source tweaks are all that's needed to get it to use 32bpp (although that'd be a bit overkill considering that VIDC1/2 is only 12bpp). This palette conversion, combined with using the event queue to schedule the row copies at roughly the right time, seems to be good enough for some games which make heavy use of mid-frame palette swaps to work. So far I've only tried Lotus Turbo Challenge II, but on a BeagleBoard-xM it seems to be accurate enough to get the palette swaps to within +/-1 scanline of where they should be. The new video code also has fairly primitive support for display scaling; 1X or 2X horizontal scaling is supported, and any (integer) vertical scale factor is supported (although the code for that isn't particularly optimal). * Updated the IOC timers to use ARMul_EmuRate. This means they should run at roughly the right real-time rates. Apart from the video changes, this was another thing that was neeeded for Lotus II to run properly (since it uses the IOC timers to judge when to palette swap). On a BeagleBoard-xM, performance seems to be around the 8MHz mark when running most games, which is about right for an ARM2. On an Iyonix performance is about half that, so expect games to be a bit sluggish or not work at all (Lotus II doesn't like it much at all). In the next couple of weeks I'll try and tidy up a few of the loose ends and get the X & Windows versions working again. I can also have a stab at fixing the other versions, but I don't have any way of testing them. If anyone is aware of any big problems in the way the new sound/video code works which means that it'll be hard/impossible/impractical to get it working on a certain platform then let me know. It shouldn't be too hard to adjust things to work in a similar way to how they did in the past, without breaking the platforms which want to take advantage of the new features. Cheers, - Jeffrey ------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
