Description
Hi there,
I’ve recently been exploring porting some modern GUI environments to classic 8MHz B&W Macintosh machines using the Retro68 toolchain (https://github.com/autc04/Retro68).
So far I’ve explored:
- https://github.com/CamHenlin/nuklear-quickdraw - nuklear
- https://github.com/CamHenlin/microui-quickdraw - microui
- https://github.com/CamHenlin/UGUIQuickDraw - ugui
I’m interested in porting LVGL to these systems now as I think I can squeeze better performance out of it than nuklear or microui as I’ve been able to get ugui working relatively well by directly manipulating video memory, but ugui doesn’t have enough widgets to enable a lot of meaningful app development.
Anyways, I’ve started an LVGL-based Mac project at https://github.com/CamHenlin/LVGLQuickDraw using a similar memory manipulation strategy and am now at the point where I have it compiling, running, attempting to flush the display buffer, etc., but have been unable to get anything in LVGL’s display buffer.
How I got started on the LVGL project
I think it’s probably useful to chat about how I got the project started. I started by mashing up this tutorial around the linux framebuffer: https://blog.lvgl.io/2018-01-03/linux_fb and my previous ugui work at https://github.com/CamHenlin/UGUIQuickDraw. I also followed this forum post: Using LV_USE_THEME_MONO to set up my config file. I am using the exact lvgl and lv_driver versions from the linux_fb blog post and had to modify the libraries so upgrading is slightly non-trivial
Here you can see where I put the initialization code from the linux_fb blog post: https://github.com/CamHenlin/LVGLQuickDraw/blob/main/Sample.c#L99 and here you can see where I call the lv_task_handler which does result in a call through to the fbdev_flush function: https://github.com/CamHenlin/LVGLQuickDraw/blob/main/Sample.c#L159, but when flushing, no pixels appear to have any color but white
What did I do to the LVGL codebases?
As you might note in https://github.com/CamHenlin/LVGLQuickDraw if you look around, I had to modify LVGL a bit to get it running on the Mac. Firstly, I had to rip out #include <stdbool.h> references and replace them with #include <MacTypes.h>, and replace every bool reference with Boolean which should behave the same as the previous bool types (and is something MacTypes implements). I’m not sure that I can use stdbool on the Mac system at all (because it causes conflicts with MacTypes) and have had luck following this strategy on other projects
Next, you’re probably saying to yourself “this is setup to use the linux_fb, of course that’s not going to work!!!” and you’d be right, except I also modified the fbdev.c driver heavily: https://github.com/CamHenlin/LVGLQuickDraw/blob/main/lv_drivers/display/fbdev.c. Of note here, everything linux-related has been ripped out, and fbdev_flush is modified to use another function putpixel to modify the Mac’s video memory directly. This is where I am seeing problems but I’m not entirely sure this is where my problem lies.
As you can see here: https://github.com/CamHenlin/LVGLQuickDraw/blob/main/lv_drivers/display/fbdev.c#L138, I’m attempting to log out every non-white pixel. The trouble is, this never logs anything at all. I would expect this to produce logging on the pixels making up “Hello world!”. I am confident putpixel works because it is used in the aforementioned ugui project and because if I manually set the final parameter (where color_p->full is being used) to 1, I will successfully black out the screen.
My question
If I’m not seeing anything but white pixels, when I am expecting to be seeing at least a few black pixels making up “Hello world!”… Where should I be looking? I have good logging capabilities via serial port output (as you probably noticed with the writeSerialPort function calls), but I don’t have any type of debugging capabilities.
What MCU/Processor/Board and compiler are you using?
Motorola 68000@8MHz, 4MB memory, running GCC and the Retro68 toolchain (https://github.com/autc04/Retro68)
Thank you for reading!
