On Wed, Mar 29, 2006 at 10:39:46PM +0100, Chris Young wrote: > > Ask away and I'll do my best to answer them. There might be a few more > > changes coming to the code related to platform porting (with the intention > > of reducing the amount of duplicate code in each platform even more). > > Watch the list for announcements about that sort of thing. > > I guess the first thing I need is a run down of which functions I need > in DispKbd.c and what they are supposed to do - I can only glean so > much from the source code, and the variable names are a bit cryptic > (to me, anyway). What is the minimum I need for opening a window and > pushing the screen data into it? >
OK, hope this helps - DisplayKbd_InitHost() Called once on program startup, this is where you should put your host specific stuff including. - Opening a GUI window of some sort - Creating an 800x600 RGB buffer of some sort [1] - Plugging that buffer into the window - RefreshDisplay(ARMul_State *state) [2] - RefreshDisplay_TrueColor_1bpp(ARMul_State *state, int Width, int Height) - RefreshDisplay_TrueColor_2bpp(ARMul_State *state, int Width, int Height) - RefreshDisplay_TrueColor_4bpp(ARMul_State *state, int Width, int Height) - RefreshDisplay_TrueColor_8bpp(ARMul_State *state, int Width, int Height) These functions actually copy the contents of the emulated video ram into the RGB buffer you setup in DisplayKbd_InitHost(). Given a pointer to the begining of the RGB buffer, with the width and height you should be able to write to the correct pixels. Hopefully you'll be able to reuse the maths from one of the other platforms, as it's "tricky". - DisplayKbd_PollHost(ARMul_State *state) Probably not strictly needed for display, it's a function that's called back 'every so often' that platforms use to read in keyboard and mouse events from the host operating system. You *might* need to use it to 'flush' the display, if the writes in the RefreshDiplay_* calls didn't do it automatically. This isn't ideal and I don't think you'll need it. That should be what you need to craete a display (not tested as I've not actually ported to a platform :) ). The other parts of DispKbd.c deal with keyboard and mouse input, and the VIDC_PutVal() function [3]. Peter [1] The X platform supports sizes up to VeryLarge by VeryLarge and resizes the graphics buffer on mode changes in the resizeWindow() callback from VIDC_PutVal() instead of being limited to 800x600. This is the ideal solution but to get started with you don't need to worry about it. [2] RefreshDisplay() is an ideal candidate to be refactored into the shared code, but don't worry about that for the moment. Possibly have each platform setup a table of function pointers for the 1,2,4,8,16,24 bit redraw functions that additionally take in a pointer to the vram to write from (vidc20 support in theory, if vidc20 video data for 1,2,4, and 8 is in the same format as vidc1/2). [3] VIDC_PutVal() can be refactored to shared code too, once there's a single function name on all platforms for the resizeWindow() callback that happens on screensize change. -- Peter Howkins [EMAIL PROTECTED] ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
