Toggle navigation
首页
问答
文章
积分商城
专家
专区
更多专区...
文档中心
返回主站
搜索
提问
会员
中心
登录
注册
RT-Thread
nes模拟器
利用rt-thread的QENU虚拟机完成NES的适配
1.00
发布于 2024-08-02 00:19:53 浏览:450
订阅该版
[tocm] # 利用rt-thread的QENU虚拟机完成NES的适配 ## **前言** rt-thread stuido所附带的QEMU是一个功能强大的工具,它模拟的VX-A9甚至带有显示屏,能够完成很多GUI功能。 任天堂娱乐系统(英文版名:Nintendo Entertainment System,NES),俗称“黑白机”,伴随很多80后度过了快乐的童年。本文详细述说NES适配到QENU的记录过程。 ## ** 正文** 源代码获取和编译: 从fork之后的git下载到packages里 ```c git clone https://gitee.com/RT-Thread-Mirror/nes.git ``` 在配置中使能NES模块: ![image.png](https://oss-club.rt-thread.org/uploads/20240801/eb6a5a3caa2e8f6150fac7c96847937e.png) 编译结果情况: ![2_AgAABUrWigLBvVfDiepM3pJbQVcn5agQ.png](https://oss-club.rt-thread.org/uploads/20240801/5ad6342084cb0dca3ada5cd600c6f734.png) 很显然,InfoNES_Mapper_00.cpp不通过,检查相应的代码内容: ![3_AgAABUrWigKbo3-uAFdHc5PlS3JpqQIx.png](https://oss-club.rt-thread.org/uploads/20240801/6d8f22815be3652389fe793609d2fb4a.png) 这个C文件没有包含任何头文件,当然不能解析MapperInit变量啦! 对比发现InfoNES_Mapper_xx.cpp都是这种不包含任何头文件的方式,那它们只能被当成头文件被别人包含了(虽然它们不是.h/.hpp类型的文件!!!) 通过搜索,可以在文件InfoNES_Mapper.c里找到证据: ![4_AgAABUrWigJ2CDRpaMtOLI0myF7vdOzy.png](https://oss-club.rt-thread.org/uploads/20240801/d872b4c2f74ec9eeefe8675a7491ff80.png) 由此可见,上述的文件根本不能单独编译,NES下的SConscript文件出问题啦! ![5_AgAABUrWigJicmC3BotCgq9p6e0htD46.png](https://oss-club.rt-thread.org/uploads/20240801/d2d87f5dd3b9ed5fcd22c5729bfb8d4e.png) 第10行的方式有问题,将Sconscript内容修改如下: ```python from building import * group = [] if not GetDepend(['PKG_USING_NES']): Return('group') cwd = GetCurrentDir() path = [cwd] src = Glob('src/*.c') src += Glob('port/nes_embed.c') src += Glob('port/nes_file_port.c') path += [cwd + '/inc'] path += [cwd + '/src'] path += [cwd + '/port'] if not GetDepend(['PKG_NES_DFS']): src += Glob('games/*.c') group = DefineGroup('nes', src, depend = ['PKG_USING_NES'], CPPPATH = path) Return('group') ``` 再次编译通过! QEMU的调试配置如下: ```python H:\RT-ThreadStudio-workspace\QEMU-VEXPRESS-A9>D:/RT-ThreadStudio/repo/Extract/Debugger_Support_Packages/RealThread/QEMU/4.2.0.4/qemu-system-arm.exe -M vexpress-a9 -sd sd.bin -S -s -kernel Debug/rtthread.elf ``` 调试执行时有如下报错: ![6_1.png](https://oss-club.rt-thread.org/uploads/20240801/8a1e24751f5aa3c35bcdb9f70d9d500c.png.webp) 这是因为系统没有声音输入设备导致的: ![7_AgAABUrWigIUwKhy1eJIUJwMcCOf-c1t.png](https://oss-club.rt-thread.org/uploads/20240801/b66c4fb49a3c54e1180f2ba5f261678a.png.webp) 现在增加一个声音输入设备(这里选蓝牙): ![8_AgAABUrWigIFX_D1ZdVDV4TjJ5uGjt-e.png](https://oss-club.rt-thread.org/uploads/20240801/9398043326cdcd06f78c6806763da791.png.webp) 再次启动QEMU,能够趟过了那些错误,不过QEMU的图形界面上没有任何内容😓 😓!! ![9_AgAABUrWigJTMbfCe3pOip0VxcYKjNtO.png](https://oss-club.rt-thread.org/uploads/20240801/0e0a42be2c8f3f3616ddaeeb755589bf.png.webp) 当然不会有任何图像啦,因为nes压根没有启动😓!而这个启动函数为nesmain位于文件nes_embed.c ![10_1.png](https://oss-club.rt-thread.org/uploads/20240801/334ab5ae9122e05efa2debf444bcee8a.png) 现在制作一个sd.bin文件,复制四个nes文件到sd.bin文件 ![11_AgAABUrWigJ0H6Ivf-1CwqZBSc7JCavb.png](https://oss-club.rt-thread.org/uploads/20240801/07bca464017b5d1ce98a8395fd47e6f4.png) ![12_AgAABUrWigKpAkLaNytO4bLJhHPptDJX.png](https://oss-club.rt-thread.org/uploads/20240801/04da65815df1489539d6f17e377f3e1e.png) 鉴于此,在nes_embed.c里增加对nesmain的调用: ![13_AgAABUrWigLm5FLRHCxPrLXs46o8cVV6.png](https://oss-club.rt-thread.org/uploads/20240801/24fa54c83c2a27edd5ef92bdd39c5eca.png) 再次编译有如下报错: ![14_AgAABUrWigKYWoCQQbBOkpzKy8F_f1Xi.png](https://oss-club.rt-thread.org/uploads/20240801/5608849fe86800178649185098885fdb.png) 通过分析,梳理出这个几个函数的信息: ![函数定义表.bmp](https://oss-club.rt-thread.org/uploads/20240801/c874418dd7b5b9faf80d42ab9817d58e.bmp.webp) 由此,修改Sconsript文件如下: ```python from building import * group = [] if not GetDepend(['PKG_USING_NES']): Return('group') cwd = GetCurrentDir() path = [cwd] src = Glob('src/*.c') src += Glob('port/nes_embed.c') src += Glob('port/nes_file_port.c') src += Glob('port/nes_lcd_port.c') src += Glob('port/nes_key_port.c') src += Glob('port/nes_sound_port.c') path += [cwd + '/inc'] path += [cwd + '/src'] path += [cwd + '/port'] if not GetDepend(['PKG_NES_DFS']): src += Glob('games/*.c') group = DefineGroup('nes', src, depend = ['PKG_USING_NES'], CPPPATH = path) Return('group') ``` 但是编译报错😬: ![15_AgAABUrWigK0iSIIKAND_aTwyimQdYd_.png](https://oss-club.rt-thread.org/uploads/20240801/2a59d0d8a1f36909f1ade315f0b7ffd0.png) ![16_AgAABUrWigLTtGyCVy9Hg46R8KUXSYqA.png](https://oss-club.rt-thread.org/uploads/20240801/13fc36e0d31136b3c89679335401b64b.png) 注释掉31行的头文件,能够编译通过😘。 但是执行时发现死机😭: ![17_AgAABUrWigLu6ymxOaJABIpYH1ussqVB.png](https://oss-club.rt-thread.org/uploads/20240801/ded17c49542ae3b15042efe3caa8a6f2.png) ![18_AgAABUrWigLfcS2jtuZA1LkCuJJQzEIm.png](https://oss-club.rt-thread.org/uploads/20240801/937c4bfc53992528a9ce8fa1c6599b75.png) ![19_AgAABUrWigLD3gwBPiNG6oqyY7_dmB9q.png](https://oss-club.rt-thread.org/uploads/20240801/d5b7c57f21bce28150bedbf42a9e0ad8.png) 很显然,lcd设备没有打开,现在去开启lcd设备,可以参考LVGL的适配过程。 使能GUI引擎: ![20_AgAABUrWigK-ePjPJupMIY0J6pJljk5p.png](https://oss-club.rt-thread.org/uploads/20240801/ad91e269124779a2d56acc9f23f405e4.png.webp) 可以看出,系统将lcd,key之类的设备也一并编译了: ![21_AgAABUrWigLlv4qR4vBOB6OgUcNo4oqS.png](https://oss-club.rt-thread.org/uploads/20240801/b4fd0515b8079ef873c61179d8d66109.png) 再次启动系统,可以发现多了lcd设备: ![22_AgAABUrWigKsVwALZbpPe6PiLdxlBCcn.png](https://oss-club.rt-thread.org/uploads/20240801/a792a6b19c8a51eefee3ee483a8bc4d9.png) 执行nes命令启动模拟器: ![23_AgAABUrWigLSMt81FUpKpYBickspkEFW.png](https://oss-club.rt-thread.org/uploads/20240801/ca0a927b7a388b019bda7788c98e0a94.png) 出现了播放的画面!! 🤞 😘 😘 😘 🤞 等等,这个画面是一个什么样的鬼玩意噢😅,表现为: 1)画面有重影 2)动画播放速度过快(此处不好展示动画) 经验分析,重影的可能原因: a) LCD驱动设定的分辨率跟NES运行的环境不一致 b) LCD驱动设定的颜色深度不合适 检查nes_lcd_port.c文件的InfoNES_LoadFrame函数,有如下的代码: ![24_AgAABUrWigKXwie21kRDP6-C7_GsmSOh.png](https://oss-club.rt-thread.org/uploads/20240801/35ebc55c90c80394f168f4a831169e22.png.webp) 在文件InforNES.h里做定义: ![25_AgAABUrWigIwTlyoTTNE9KgQvi-AvKGC.png](https://oss-club.rt-thread.org/uploads/20240801/bc087e32ce7f069409f5dab636c067c2.png) 调试跟踪,有如下发现: ![26_AgAABUrWigJ-gtJhRL9IBqx62p0_Oi6G.png](https://oss-club.rt-thread.org/uploads/20240801/77f10bd78ad95459e89396813ecd4059.png) 可以看出两层 for循环的作用: 将WorkFrame的内容(估计是NES游戏画面的像素内容)搬移到一个同等大小的矩阵区域 ![27_AgAABUrWigJRVByvaQdKg7yAdYpsYUXj.png](https://oss-club.rt-thread.org/uploads/20240801/d36abd97172d3aa161c30466776f3fb9.png) 可以看出,实际的LCD设备的颜色深度为16 !!! 这与上图54-56行的代码不对应,原有的代码将LCD当成了24bit的颜色深度,应当修改为: ![28_AgAABUrWigKQNmEuS29AKYb0kvRiiG3m.png](https://oss-club.rt-thread.org/uploads/20240801/5ae576ad3ab719bb1169e0ec9e1de39e.png) 再次执行,QENU模拟器的显示屏画面如下: ![29_AgAABUrWigL6LEcHXRBGJ5xgbtFNppbC.png](https://oss-club.rt-thread.org/uploads/20240801/4682f932fa6cd29430993e140828058d.png.webp) 可以看出,颜色明显变得真实了,还能比较清晰的辨别出画面中的文字信息!!! 好消息,这是一个不少的收获!! 断点调试发现,这个InfoNES_LoadFrame一直在运行,事实上它就是一个画面刷新函数!!!! 这个画面刷新函数的调用路线为: InfoNES_Main --> InfoNES_Cycle --> InfoNES_HSync --> InfoNES_LoadFrame 现在的问题是:显示屏(qemu的模拟器显示屏)上为什么会出现两个同样的画面?而且在图象画面上还出现了其他的内容(图中红色框内)? ![30_AgAABUrWigKAn7wBdDNLd42MVf9oQXcn.png](https://oss-club.rt-thread.org/uploads/20240801/0e2aa8c20d379400604f3c43ca7a3ceb.png) 如果仔细观察,会发现那个画面外的东西不就是游戏里的那个主角精灵的图象嘛!!!!可以打开正常的游戏画面对比一下(电脑里安装了NES模拟器,加载SuperMario.nes即可) ![31_AgAABUrWigIkVUrbmgdKx5FWAqYzg7hT.png](https://oss-club.rt-thread.org/uploads/20240801/3ce0ca6024db905bbefb04216251c54a.png.webp) 仔细对比代码,发现InfoNES.h文件的两个宏被修改了(之前排查显示分辨率所改) ![32_AgAABUrWigJIjWX0tU9H1qHZ5-6uwwAG.png](https://oss-club.rt-thread.org/uploads/20240801/573d9ed31f6fcd14a622b5b866cd08e6.png) 现在把它改回去: ![33_AgAABUrWigLaJH-3YzlNdqgQeSWm08pC.png](https://oss-club.rt-thread.org/uploads/20240801/60d374a81b9e596dae35aa0efea3c9cc.png) 再次执行之后,那个精灵画面进入到背景中了(图象中白云上就是游戏精灵)!! ![34_AgAABUrWigKSXmFG6DNKrZ4p-ph4ctdJ.png](https://oss-club.rt-thread.org/uploads/20240801/330ae3cbb45709bc24a129b9a9e04e02.png.webp) 现在,画面就剩最后一个问题:为什么有两幅一样的画面? 为此,在RTT上启动LVGL组件,通过对比来分析根源。LVGL的demo显示界面如下: ![35_AgAABUrWigJxl5BS7TdBB7PAPqCEJtEN.png](https://oss-club.rt-thread.org/uploads/20240801/c8721955ae6380214126bbfe4c2b6853.png.webp) 画面很正常,由此证明NES的双画面是NES组件本身的问题。 为便于对比分析,将显示驱动的分辨率调整为512*250: ![36_AgAABUrWigJt7hvnAxdI9JrVbF0BI0Ev.png](https://oss-club.rt-thread.org/uploads/20240801/00b22aec546f43ef6f153832faf8f337.png) 执行NES的画面(此时利用debug断点做暂停)如下: ![37_AgAABUrWigLzFlDFx2dIS5CC-UMQinEh.png](https://oss-club.rt-thread.org/uploads/20240801/7948bed7ed52f804a55558eece847505.png.webp) 对比左右两幅图片,可以发现它们还是有细微的差别(云彩的形状不相同),它们是两帧不同的画面!! 是否为NES刷新过快导致的? 为此,在函数InfoNES_LoadFrame里执行显示刷新之后立即延时20毫秒。 ![38_AgAABUrWigJpYXKMw4ZLG6hsYcV-PFMB.png](https://oss-club.rt-thread.org/uploads/20240801/ba718a988128ceeda2821c0f0f379387.png) 这里说明延时设定为20毫秒的来源: 由于技术的时代限制,当年NES产品推出时使用的为显像管显示器(CRT全称阴极射线显示管),其刷新频率为50Hz,周期为: `T = 1/50 = 0.02s = 20ms` ### 补充说明: 阴极射线管由威廉·克鲁克斯首创,他后继的很多科学家先后利用和改进了这种装置,并先后利用它完成了电子发现,晶体衍射实验等等物理学开天辟地级别的大发现。 此后,阴极射线管也在电子电气上被广泛使用。雷达出现后也是用这种特化后的阴极射线管来达成雷达波的信息判读。 二次世界大战后,由这种射线管改良后的器件被广泛应用于一个家喻户晓的民生设备------电视机(其核心元件俗称“显像管”) 再次运行测试,发现还是显示两副画面,但是游戏动作播放速度正常了!!! 由此可见通过在InfoNES_LoadFrame函数增加延时可以调整动画播放速度。 发散想一下,如果我调节这个延时时间可不是变成了一个**作弊器**? 以下是修改后的函数代码 ```cpp void InfoNES_LoadFrame() { /* * Transfer the contents of work frame on the screen * */ //#include
struct rt_device_rect_info rect_info; WORD *wColor = WorkFrame; if (!nes_lcd_is_init) { lcd_device = rt_device_find("lcd"); RT_ASSERT(lcd_device != RT_NULL); if (rt_device_open(lcd_device, RT_DEVICE_OFLAG_RDWR) == RT_EOK) rt_device_control(lcd_device, RTGRAPHIC_CTRL_GET_INFO, &info); nes_lcd_is_init = 1; } rect_info.x = 128; rect_info.y = 5; rect_info.width = NES_DISP_WIDTH; rect_info.height = NES_DISP_HEIGHT; for (int y = rect_info.y; y < rect_info.y + rect_info.height; y ++) { for (int x = rect_info.x; x < rect_info.x + rect_info.width; x ++) { wColor ++; /* Exchange 16-bit to 24-bit RGB565 to RGB888*/ #if 0 info.framebuffer[3 * (x + y * info.width)] = ((*wColor & 0xf800) >> 10) << 3; info.framebuffer[3 * (x + y * info.width) + 1] = ((*wColor & 0x07e0) >> 5) << 3; info.framebuffer[3 * (x + y * info.width) + 2] = (*wColor & 0x001f) << 3; #else /**< 如果显示屏为16bit/像素 */ info.framebuffer[(x + y * info.width)] = *wColor; #endif } } rt_device_control(lcd_device, RTGRAPHIC_CTRL_RECT_UPDATE, &rect_info); rt_thread_mdelay(40); } ``` 结构体rect_info用于显示屏的实际刷新,wColor指向了指针WorkFrame,搜索这个变量,有如下信息: ![39_AgAABUrWigIQbXWftpRKW5mVI4MaAufz.png](https://oss-club.rt-thread.org/uploads/20240801/9bef5fc15d59ac6dd1d11ce31862e5ec.png) 宏PKG_NES_DOUBLE_FRAMEBUFFER被定义在文件rtconfig.h ![40_AgAABUrWigJVUpJsJOdEQZER5L1PG2kn.png](https://oss-club.rt-thread.org/uploads/20240801/86a06fe49a2775d50b7931e1289addbd.png) 可以肯定,NES开启了双显示缓冲区模式(很多显示处理利用这种双缓存轮流刷数据的方法(可以搜索乒乓操作)来改善动画的连续性)。而在数据的刷新却没有处理好,因而导致这个现象!!! 现在取消其双显示缓冲器模式,测试一下效果。这个可以直接通过配置改变: ![41_AgAABUrWigIzJbAv7XRNvaOvwJAnbzSJ.png](https://oss-club.rt-thread.org/uploads/20240801/64462a28b49ae7136ac9c80ca35637ef.png) 编译后测试发现,还是分成了左右两幅图像!!! 给显示屏增加边缘外框作标志 ![43_AgAABUrWigKi7DCY2FpDhr4x_iGthRoO.png](https://oss-club.rt-thread.org/uploads/20240801/db8f72802b197fb64f4767738d26ba0c.png.webp) 明明只画了一根竖线,却显示了两根!!! 同时还发现,在45行加断点再单步调试时,左右两根竖线是同步向下增加的 ![44_AgAABUrWigK4pai2wnBDRKl05ufx8xvk.png](https://oss-club.rt-thread.org/uploads/20240801/02fc0988a277751096bc7e348cba1425.png.webp) 再次仔细分析InfoNES_LoadFrame函数: ![45_AgAABUrWigJcQdxZZItOuargoj7ZPQyc.png](https://oss-club.rt-thread.org/uploads/20240801/3346e3d5e688d9c68b3f80aa6472f56f.png.webp) ![46_AgAABUrWigKeJimKjzFPfrv9jDJV4H5A.png](https://oss-club.rt-thread.org/uploads/20240801/d967843c06da5551e23bacc2f52b2deb.png.webp) 赋值语句等号两端的类型不相同😬 😬,这才是显示两幅图象的根本原因!!!! 现在适当修改为: ```cpp void InfoNES_LoadFrame() { /* * Transfer the contents of work frame on the screen * */ if (!nes_lcd_is_init) { lcd_device = rt_device_find("lcd"); RT_ASSERT(lcd_device != RT_NULL); if (rt_device_open(lcd_device, RT_DEVICE_OFLAG_RDWR) == RT_EOK) rt_device_control(lcd_device, RTGRAPHIC_CTRL_GET_INFO, &info); nes_lcd_is_init = 1; } // struct rt_device_rect_info rect_info = { /**< 将显示区域移动到显示屏的中央位置 */ .x = (info.width - NES_DISP_WIDTH)/2, .y = (info.height - NES_DISP_HEIGHT)/2, .width = NES_DISP_WIDTH, .height = NES_DISP_HEIGHT, }; WORD *wFrameBuffer = (WORD*)(info.framebuffer); WORD *wColor = WorkFrame; // for (int y = rect_info.y; y < rect_info.y + rect_info.height; y ++) { for (int x = rect_info.x; x < rect_info.x + rect_info.width; x ++) { /**< 如果显示屏为16bit/像素 */ wFrameBuffer[(x + y * info.width)] = *wColor; wColor++; } } rt_device_control(lcd_device, RTGRAPHIC_CTRL_RECT_UPDATE, &rect_info); rt_thread_mdelay(lcd_flush_period); } ``` 运行之后,这个能在显示屏上显示一幅完整的画面了: ![47_AgAABUrWigLt6dZSNeBLYq2Tb0Vr-vic.png](https://oss-club.rt-thread.org/uploads/20240801/e564af235b2283dc4391719a9c9a080a.png.webp) ## 复盘: 适配过程中,这个两幅画面的bug耗费了我相当多的时间。至此回顾这种情况的原因是:由两幅画面总是联想到是不是多缓冲区处理导致的问题,进而一直将火力输出在“代码在哪里出现了多次复制像素数据了”。而一直忽略了一个细节:明明比较精细的单幅画面(可以观察PC模拟器的画面输出),这两幅画面中却变得很粗糙,要是留意这个图像被轮廓化的细节那就能很快做出正确的方向判断。* 仔细观察,可以发现其颜色不正确!!! 很明显,这是由于NES输出的颜色比特次序与显示屏自身的颜色次序不一致所致。修改显示屏的颜色跟显示屏一致即可! ![48_AgAABUrWigLxseyqQOFLbIzz3-3gpjRH.png](https://oss-club.rt-thread.org/uploads/20240801/504fc6a908a8b46537dbc114a93a8029.png) 可见函数drv_clcd_control将颜色比特次序设置为RGB565 进一步调整InfoNES_LoadFrame函数的代码,详情如下: ![48_AgAABUrWigLxseyqQOFLbIzz3-3gpjRH.png](https://oss-club.rt-thread.org/uploads/20240801/504fc6a908a8b46537dbc114a93a8029.png) 可见函数drv_clcd_control将颜色比特次序设置为RGB565 进一步调整InfoNES_LoadFrame函数的代码,详情如下: ```cpp void InfoNES_LoadFrame() { /* * Transfer the contents of work frame on the screen * */ if (!nes_lcd_is_init) { lcd_device = rt_device_find("lcd"); RT_ASSERT(lcd_device != RT_NULL); if (rt_device_open(lcd_device, RT_DEVICE_OFLAG_RDWR) == RT_EOK) rt_device_control(lcd_device, RTGRAPHIC_CTRL_GET_INFO, &info); nes_lcd_is_init = 1; } // struct rt_device_rect_info rect_info = { /**< 将显示区域移动到显示屏的中央位置 */ .x = (info.width - NES_DISP_WIDTH)/2, .y = (info.height - NES_DISP_HEIGHT)/2, .width = NES_DISP_WIDTH, .height = NES_DISP_HEIGHT, }; WORD *wFrameBuffer = (WORD*)(info.framebuffer); WORD *wColor = WorkFrame; WORD red,green,blue; // for (int y = rect_info.y; y < rect_info.y + rect_info.height; y ++) { for (int x = rect_info.x; x < rect_info.x + rect_info.width; x ++) { /**< 将NES系统的RGB565格式的像素数据转换成本地显示屏对应的格式,注意:NES颜色是RGB555,而本地显示屏却是RGB565格式的 */ red = (*wColor & 0x7C00) >> 10; green = (*wColor & 0x03E0) >> 5; blue = (*wColor & 0x001F); wFrameBuffer[(x + y * info.width)] = (red << 11) | (green << 6) | (blue); wColor++; } } rt_device_control(lcd_device, RTGRAPHIC_CTRL_RECT_UPDATE, &rect_info); rt_thread_mdelay(lcd_flush_period); } ``` 执行效果如下: ![49_AgAABUrWigILBsH-UmlHyqbfE4VpZG4y.png](https://oss-club.rt-thread.org/uploads/20240801/4c4052ca45367622f749ac828f9d1262.png.webp) 图中左边为电脑上的NES模拟器,右边是QEMU模拟器 显示部分完美解决😘 😘 😘!!! 现在去做最后一步的工作:设法将键盘响应连接到NES 找到文件drv_keyboard.c文件 ![50_AgAABUrWigJ_n7RxJ-lGvI2y_CbOwA1Z.png](https://oss-club.rt-thread.org/uploads/20240802/179b25bb72c760b5997e15b06248f96a.png) 将宏DBG_LEVL修改为DBG_LOG 程序运行后,点击键盘向上的方向键,终端有如下的打印输出 ![51_AgAABUrWigL2ZLTPejlN_IePo1gE01iG.png](https://oss-club.rt-thread.org/uploads/20240802/09879becfd593dfb17cdfbf33a7ea778.png) 对应的函数keyboard_report_event代码: ```cpp static void keyboard_report_event(void * device, rt_uint32_t flag, rt_uint8_t data, enum key_value_t press) { struct rtgui_event_kbd key_event; rt_uint16_t i = 0, mod = 0, find_key = 0; for(i = 0; i < sizeof(map)/sizeof(map[0]); i++) { if (map[i].data == data) { LOG_D("KEY info:"); if (flag & KBD_CAPS_LOCK) { LOG_D("CAPS:LOCK"); } else { LOG_D("CAPS:UNLOCK"); } if (flag & KBD_LEFT_SHIFT) { mod |= RTGUI_KMOD_LSHIFT; LOG_D("SHIFT:LEFT"); } else if (flag & KBD_RIGHT_SHIFT) { mod |= RTGUI_KMOD_RSHIFT; LOG_D("SHIFT:RIGHT"); } else { LOG_D("SHIFT:NULL"); } if (flag & KBD_LEFT_CTRL) { mod |= RTGUI_KMOD_LCTRL; LOG_D("CTRL:LEFT"); } else if (flag & KBD_RIGHT_CTRL) { mod |= RTGUI_KMOD_RCTRL; LOG_D("CTRL:RIGHT"); } else { LOG_D("CTRL:NULL"); } LOG_D("flag:0x%08x value:0x%x key:%s status:%s", \ flag, data, map[i].normal_key, press ==0 ? "UP" : "DOWN"); find_key = 1; break; } } if (find_key == 0) { LOG_D("flag:0x%08x value:0x%x key:%s status:%s", \ flag, data, "UNKNOWN", press ==0 ? "UP" : "DOWN"); return; } key_event.parent.sender = RT_NULL; key_event.parent.type = RTGUI_EVENT_KBD; key_event.type = (press == 0 ? RTGUI_KEYUP : RTGUI_KEYDOWN); key_event.key = map[i].key; key_event.mod = mod; key_event.unicode = map[i].unicode; rtgui_server_post_event(&key_event.parent, sizeof(key_event)); } ``` NES系统里,读取操纵杆(键盘)状态的函数为InfoNES_PadState,位于文件nes_key_port.c ```cpp void InfoNES_PadState(DWORD *pdwPad1, DWORD *pdwPad2, DWORD *pdwSystem) { // 低位---------------------->高位 //pdwPad1 : A键 B键 选择 开始 上 下 左 右 //pdwPad2 : A键 B键 选择 开始 上 下 左 右 //pdwSystem : 退出 确认 取消 上 下 左 右 NULL } ``` 现在要在这个函数里完成电脑按键与NES操纵杆的绑定,并且分别对pdwPad1,pdwPad2,pdwSystem进行赋值。 操纵杆1的绑定关系: ![操纵杆1.jpg](https://oss-club.rt-thread.org/uploads/20240802/27ea2d132339eaeac625e504266fb805.jpg) 操纵杆2的绑定关系: ![操纵杆2.jpg](https://oss-club.rt-thread.org/uploads/20240802/3096bcc4ee1a1beb236c57127f961fb9.jpg) 系统按键的绑定关系: ![系统按键.jpg](https://oss-club.rt-thread.org/uploads/20240802/be34215c9efef0bc6fbec49d69e41471.jpg) 以下是改动后的nes_key_port.c文件 ```cpp /* * Copyright (c) 2006-2020, RT-Thread Development Team * * SPDX-License-Identifier: Apache-2.0 * * Change Logs: * Date Author Notes * 2020-12-14 Ghazigq the first version */ #include
#include
#include
typedef struct { BYTE code; BYTE bit; BYTE status; }padConfig; static padConfig myPadState[3*8] = { /** pdwPad1 */ { .code = 0x7b, .bit = 0, .status = 0, }, { .code = 0x79, .bit = 1, .status = 0, }, { .code = 0x70, .bit = 2, .status = 0, }, { .code = 0x71, .bit = 3, .status = 0, }, { .code = 0x75, .bit = 4, .status = 0, }, { .code = 0x72, .bit = 5, .status = 0, }, { .code = 0x6b, .bit = 6, .status = 0, }, { .code = 0x74, .bit = 7, .status = 0, }, /** pdwPad2 */ { .code = 0x3c, .bit = 0, .status = 0, }, { .code = 0x43, .bit = 1, .status = 0, }, { .code = 0x3b, .bit = 2, .status = 0, }, { .code = 0x42, .bit = 3, .status = 0, }, { .code = 0x1d, .bit = 4, .status = 0, }, { .code = 0x1b, .bit = 5, .status = 0, }, { .code = 0x1c, .bit = 6, .status = 0, }, { .code = 0x23, .bit = 7, .status = 0, }, /** pdwSystem */ { .code = 0x66, .bit = 0, .status = 0, }, { .code = 0x5a, .bit = 1, .status = 0, }, { .code = 0x76, .bit = 2, .status = 0, }, { .code = 0x6c, .bit = 3, .status = 0, }, { .code = 0x69, .bit = 4, .status = 0, }, { .code = 0x71, .bit = 5, .status = 0, }, { .code = 0x7a, .bit = 6, .status = 0, }, { .code = 0x00, .bit = 7, .status = 0, }, }; void NesKeyPadFlush(uint8_t code, uint8_t pressed) { for(uint32_t i = 0; i < sizeof(myPadState)/sizeof(padConfig); i++) { if(code == myPadState[i].code) { myPadState[i].status = (pressed) ? 1 : 0; break; } } } /*===================================================================*/ /* */ /* InfoNES_PadState() : Get a joypad state */ /* */ /*===================================================================*/ void InfoNES_PadState(DWORD *pdwPad1, DWORD *pdwPad2, DWORD *pdwSystem) { // 低位---------------------->高位 //pdwPad1 : A键 B键 选择 开始 上 下 左 右 //pdwPad2 : A键 B键 选择 开始 上 下 左 右 //pdwSystem : 退出 确认 取消 上 下 左 右 NULL *pdwPad1 = (myPadState[ 0].status << 0) | (myPadState[ 1].status << 1) | (myPadState[ 2].status << 2) | (myPadState[ 3].status << 3) | (myPadState[ 4].status << 4) | (myPadState[ 5].status << 5) | (myPadState[ 6].status << 6) | (myPadState[ 7].status << 7); // *pdwPad2 = (myPadState[ 8].status << 0) | (myPadState[ 9].status << 1) | (myPadState[10].status << 2) | (myPadState[11].status << 3) | (myPadState[12].status << 4) | (myPadState[13].status << 5) | (myPadState[14].status << 6) | (myPadState[15].status << 7); // *pdwSystem = (myPadState[16].status << 0) | (myPadState[17].status << 1) | (myPadState[18].status << 2) | (myPadState[19].status << 3) | (myPadState[20].status << 4) | (myPadState[21].status << 5) | (myPadState[22].status << 6) | (myPadState[23].status << 7); } ``` 对应的,改动之后的代码能够控制精灵左右移动 却不能控制精灵做跳跃动作。 查明表面原因: 代码中1号操纵杆所绑定的键位码不能正常传递,将1,2号操纵杆互换之后就能控制NES里的精灵了,改动后的InfoNES_PadState函数的内容如下: ```cpp void InfoNES_PadState(DWORD *pdwPad1, DWORD *pdwPad2, DWORD *pdwSystem) { // 低位---------------------->高位 //pdwPad1 : A键 B键 选择 开始 上 下 左 右 //pdwPad2 : A键 B键 选择 开始 上 下 左 右 //pdwSystem : 退出 确认 取消 上 下 左 右 NULL *pdwPad2 = (myPadState[ 0].status << 0) | (myPadState[ 1].status << 1) | (myPadState[ 2].status << 2) | (myPadState[ 3].status << 3) | (myPadState[ 4].status << 4) | (myPadState[ 5].status << 5) | (myPadState[ 6].status << 6) | (myPadState[ 7].status << 7); // *pdwPad1 = (myPadState[ 8].status << 0) | (myPadState[ 9].status << 1) | (myPadState[10].status << 2) | (myPadState[11].status << 3) | (myPadState[12].status << 4) | (myPadState[13].status << 5) | (myPadState[14].status << 6) | (myPadState[15].status << 7); // *pdwSystem = (myPadState[16].status << 0) | (myPadState[17].status << 1) | (myPadState[18].status << 2) | (myPadState[19].status << 3) | (myPadState[20].status << 4) | (myPadState[21].status << 5) | (myPadState[22].status << 6) | (myPadState[23].status << 7); } ``` 至此,游戏中的精灵主角可以正常控制了!! 😘 😘 ## 附带解决的时间消耗列表: ![解决问题的时间消耗列表.jpg](https://oss-club.rt-thread.org/uploads/20240802/d96111e237857ce9fc2a80ea0cc60518.jpg.webp)
4
条评论
默认排序
按发布时间排序
登录
注册新账号
关于作者
大龄码农
这家伙很懒,什么也没写!
文章
2
回答
1
被采纳
0
关注TA
发私信
相关文章
1
RT-THREAD在STM32H747平台上移植lwip
2
正点原子miniSTM32开发板读写sdcard
3
反馈rtt串口驱动对低功耗串口lpuart1不兼容的问题
4
Keil MDK 移植 RT-Thread Nano
5
RT1061/1052 带 RTT + LWIP和LPSPI,有什么坑要注意吗?
6
RT thread HID 如何收发数据
7
求一份基于RTT系统封装好的STM32F1系列的FLASH操作程序
8
RT-Thread修改项目名称之后不能下载
9
rt-studio编译c++
10
有木有移植rt-thread(nano)到riscv 32位MCU上
推荐文章
1
RT-Thread应用项目汇总
2
玩转RT-Thread系列教程
3
国产MCU移植系列教程汇总,欢迎查看!
4
机器人操作系统 (ROS2) 和 RT-Thread 通信
5
五分钟玩转RT-Thread新社区
6
【技术三千问】之《玩转ART-Pi》,看这篇就够了!干货汇总
7
关于STM32H7开发板上使用SDIO接口驱动SD卡挂载文件系统的问题总结
8
STM32的“GPU”——DMA2D实例详解
9
RT-Thread隐藏的宝藏之completion
10
【ART-PI】RT-Thread 开启RTC 与 Alarm组件
热门标签
RT-Thread Studio
串口
Env
LWIP
SPI
AT
Bootloader
Hardfault
CAN总线
FinSH
ART-Pi
USB
DMA
文件系统
RT-Thread
SCons
RT-Thread Nano
线程
MQTT
STM32
RTC
FAL
rt-smart
ESP8266
I2C_IIC
WIZnet_W5500
UART
ota在线升级
PWM
cubemx
freemodbus
flash
packages_软件包
BSP
潘多拉开发板_Pandora
定时器
ADC
GD32
flashDB
socket
中断
Debug
编译报错
msh
SFUD
keil_MDK
rt_mq_消息队列_msg_queue
at_device
ulog
C++_cpp
本月问答贡献
踩姑娘的小蘑菇
7
个答案
3
次被采纳
a1012112796
13
个答案
2
次被采纳
张世争
9
个答案
2
次被采纳
rv666
5
个答案
2
次被采纳
用户名由3_15位
11
个答案
1
次被采纳
本月文章贡献
程序员阿伟
7
篇文章
2
次点赞
hhart
3
篇文章
4
次点赞
大龄码农
1
篇文章
3
次点赞
ThinkCode
1
篇文章
1
次点赞
Betrayer
1
篇文章
1
次点赞
回到
顶部
发布
问题
投诉
建议
回到
底部