Hi Ralph, On Wed, 24 Aug 2011, Ralph Corderoy wrote:
> Hi Jeffrey, > > Nice to see some activity on arcem. Out of interest, do you just work > on the source as one long activity or use an SCM, like Subversion or > Bazaar, locally to break up the edits? > > Cheers, Ralph. Since ArcEm is quite small I've just got a folder full of backups. If it was a bigger project I might use some kind of local SCM, or maybe just keep less backups. Anyway, new source + RISC OS build uploaded, same place as before. Changes: * X11 & Windows versions now work. - The Windows version was the easiest, since it was already using a 16bpp bitmap for the screen. The X version was a lot harder, and involved me having to restructure how the new rendering code works (more on that below). - The Windows version now supports the high-res modes available in ArcEmModes (previously it had a max resolution of 800x600). The only downside is that it briefly pops up a massive 1600x1200 window on startup, which I haven't fixed yet. - Sound support in the X version is a bit iffy. To start with I tried the initial threaded code, but found that the sound thread hardly got any CPU time. Since I'm not an expert on pthreads, and using the thread to limit/control the audio rate technically isn't needed anymore, I tried disabling the thread code and sending the data directly from the main thread. This works, but the emulator seems to have a hard time keeping the correct DMA rate and constantly either underruns or overflows the buffer. So some work is definitely needed there. * As mentioned above, the new rendering code has been restructured a bit. ArcEm now has the notion of a 'display device' which handles the VIDC register writes and screen output (see arch/displaydev.c, arch/displaydev.h). - An ArcEm build can contain multiple display device implementations and the code can select the most appropriate one at runtime. - At the moment the X frontend uses this to select from two different implementations, one for pseudocolour displays and one for truecolour displays. - What's more, it's also possible for the emulator to switch between different devices while in the middle of execution (e.g. if you wanted different code for windowed or fullscreen operation), but at the moment nothing's making use of that. - This functionality comes at almost no extra cost performance-wise, since everything external to the CPU was already being done through function pointers anyway. * The display code I had in the previous version (now in arch/stddisplaydev.c) has been modified to use the new display device system. - It's also been modified to act more like a display device template; in order to use the code you need to set up a few #defines and function prototypes and then include the source file directly. This allows the code to adapt to the host environment without impacting the performance of other platforms. The two X display devices are both instances of the standard display device. - The only downside is that the source is a bit uglier, and geting access to device-specific variables from outside the device instance is a bit tricky. If only C had template support! * I've made a few general fixes/improvements to things in the previous version: - Fixed colours in 8bpp modes not being quite right - Improved IOC & video timing accuracy. In particular my previous code seemed to be triggering Vsync one scanline too late. Now that I've fixed that Lotus II seems a lot better, with maybe 1 in 20 frames being off by 1 scanline on the palette swaps, or at least for the most noticeable area where the sky meets the road. YMMV. - Added support for the IOEB control register, which can control the VIDC source clock. I added this to see if it would fix Lotus II not working properly with "*configure monitortype 4", but it didn't fix it, and after seeing the same thing in Red Squirrel I'm tempted to say that it's just a bug with Lotus that it doesn't work properly with all monitor types. However at the moment this is the only IOEB register that's implemented, so it's possible other registers (e.g. the ID register) are needed for some things to work properly (and the current code doesn't return sensible values when reading from the IOEB registers; it falls through to the HDC code and reads a random register from there) - Updated ArcEmModes and the ModeGen BASIC file to use sensible VIDC clock dividers for the high-res modes. However I haven't updated them to specify alternate VIDC source clock rates, so the refresh rates of the high-res modes could still be improved if needed. - There's a new common function for calculating the cursor position, since doing so correctly is a bit tricky and none of the existing frontends were doing it right. - Rewrote the vertical scaling code to be much faster * Some RISC OS version polish: - New command line option --rbswap to swap the red & blue channels (since some Iyonix models have graphics cards that don't use the 'correct' RGB ordering in 16bpp modes, and there's no official/proper way of detecting those models via software). - Added code to automatically select the most appropriate screen mode based on what the emulated machine wants - New command line option --minres to specify minimum screen resolution to use. Useful for people like me who have low-res mode entries in their MDF which are OK for emergencies but unsuitable for general use (picture squashed or not fully on screen, etc.) - New command line option --lcdres to specify the native resolution of your monitor. This will limit the used modes to just those that will scale cleanly, e.g. 1x, 2x, 3x, etc., to get rid of the horrible scaling artifacts you often get from using LCD monitors at non-native resolutions. - Added a bunch more signal handlers so the sound handler should always get cleaned up on exit - Keyboard LEDs now reflect emulator state - Disabled escape & break, allowing them to be used in the emulator. However Alt-Break still works, so apart from the ArcEm_Shutdown SWI that's the only way of quitting. * GP2X & Amiga sound code should hopefully work again. * Amiga video code is half-updated, with the aim to use 16bpp output. However I'm having trouble finding any decent documentation, so I might leave the rest to you Chris, if that's OK? There's plenty of todo notes in there for the bits that need filling in. * GP2X video code hasn't been touched. Since I know the performance won't be there for it to make proper use of the new video code, I might try setting up something similar to the old DIRECT_DISPLAY code, or maybe an 8bpp version of the new code. Again I'm having trouble finding docs, although I did find one promising looking library which also has an SDL implementation to allow the code to be tested on a PC: http://sourceforge.net/projects/gp2xhwlib/ * Mac OS X code hasn't been touched, but Ian Jeffray has said he's planning on rewriting the Mac code from scratch, so that shouldn't be an issue. I might do another release after this one to fix up some more of the broken bits, but if people are happy for this version to go into CVS then I expect I'll go back to working on ROOL things. Cheers, - Jeffrey ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
