Hi guys, As you've seen there are quite a few bits which need fixing up in order to get the OS X port to work again. I would have done most of it myself, but then Ian said he was planning on redoing the OS X port from scratch, so I decided to leave the tidying up to him (especially since I don't have a Mac to test with).
I'd recommend taking a look at win/DispKbd.c for a simple example of how things work with the new display drivers. Here's an overview of the file, and a rough guide for what's needed to get OS X working again: The display device ------------------ First we have the implementation of the "standard display device". The standard display device is used by platforms that have true-colour output available. (There's also a palettised display device, which is useful for platforms without true-colour displays, or with limited horsepower) There are two parts to the display device implementation: there's the cross-platform core in arch/stddisplaydev.c, and then there's the host-specific parts, which are contained in the SDD_Name(Host_GetColour), SDD_Name(Host_ChangeMode), etc. functions in win/DispKbd.c. The core code is respnsible for deciding which bits of the screen need redrawing and when. It also handles palette lookups, converting pixels to 12bit RGB values. The host-specific code handles converting those 12bit colours to whatever native format the host supports, and responds to redraw requests that the core generates in order to write host-format pixels to the hosts display. The SDD_Name() macro is used to wrap all the function names so that you can have multiple implementations of the same device. E.g. you might want one implementation for 16bpp output and one for 32bpp output. If ArcEm was written in C++ this would probably all be done using templates or virtual classes. Since the Windows port doesn't need to know which areas of the screen are being updated, the implementation of the display device is very straightforward. Host_BeginRow returns a pointer to a pixel within the 16bpp bitmap, and the Host_WritePixel/Host_WritePixels functions just write one or more pixels to the pointer and increments the address. Other platforms may have more complex implementations (e.g. X/true.c). I can see that the OS X port already supports the use of 24bpp true colour displays, so it would probably make sense to use the Windows implementation as a basis for the new Mac one: 1. Delete the existing DoPixelMap_* and RefreshDisplay_* functions from macosx/DispKbd.c 2. Copy over the Windows display device (up to the big ---- comment) 3. Change SDD_HostColour to be a uint32_t (or maybe an array/struct of three uint8_t's; this would probably be the best choice if you know the compiler won't pad the size out to four bytes. Or I guess you could change the code in ArcemController.m to create a 32bpp bitmap instead of 24bpp) 4. Change SDD_Row to be a uint8_t * (or leave it as a SDD_HostColour * if SDD_HostColour is a three byte array/struct) 5. Change Host_GetColour to convert the extracted RGB values to an appropriate colour 6. Change Host_BeginRow to return a pointer within screenbmp instead of dibbmp 7. Make sure that Host_SkipPixels, Host_WritePixel and Host_WritePixels are OK. E.g. if screenbmp is remaining as a simple char array then you'll have to handle unpacking the SDD_HostColour and writing each byte in turn. Note that the 'HD' structure that Host_ChangeMode is accessing corresponds to the SDD_Name(DisplayInfo) struct that gets defined in arch/stddisplaydev.c. So functions that are dependent on the structure (like Host_ChangeMode) need to have their body after the stddisplaydev #include. Keyboard/Mouse handling ----------------------- Compared to the Windows version, the RefreshMouse function in macosx/DisplayDev.c needs a few changes making: 1. Use DisplayDev_GetCursorPos to get the position of the cursor. A common function is used for this because the position is slightly different depending on the colour depth of the screen mode the Arc is using. 2. It also needs to modify the returned coordinates by HD.XScale, HD.YScale, HD.XOffset and HD.YOffset in the samw way as the Windows code, to take into account display centering & scaling. 3. The code which looks up the palette entries in HD.cursorPixelMap needs to be changed to use VIDC.CursorPalette. VIDC.CursorPalette contains the colours in the same 12bit RGB format that's passed to the display Host_GetColour function, so they'll need converting to the format used for the cursor image. 4. The code which clamps the minimum height to 1 row is wrong! You'll end up with one row of the cursor being left visible when RISC OS has turned it off. 5. If you want the cursor scale to match the screen scale then the cursor height and the main bitmap update loop will need to take into account HD.XScale & HD.YScale. However you can probably ignore that for now. 6. The references to HD.CursorImageData can be removed. That variable is completely missing in the new code, and the old code didn't make use of it anyway! The curent MouseMoved, ProcessKey and ProcessButton functions looks OK. Other bits ---------- The RefreshDisplay function hidden under RefreshMouse can be deleted if you missed it earlier. DisplayKbd_InitHost can be greatly simplified; basically just delete it all and replace it with DisplayDev_Init from win/DispKbd.c. The VIDC_PutVal function can be deleted; the core display device code handles VIDC register writes itself. You'll need a couple of new functions adding - SDD_Name(Host_PollDisplay), and Kbd_PollHostKbd. Host_PollDisplay just needs to call RefreshMouse and updateDisplay. For now I guess you can always refresh the entire display, then add more intelligent refresh code later on. For Kbd_PollHostKbd it looks like you just need to rename the existing DisplayKbd_PollHost function. I think that's about it. Let me know if you're still running into difficulty getting it up and running. Cheers, - Jeffrey ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
