开源网址:
https://github.com/xboot/libxnes
https://gitee.com/xboot/libxnes
编译了一个windows版,可以命令行执行,或者直接将rom拖到xnes即可运行
xnes.7z
离线
放弃大好国庆,将去年写的半拉子工程,硬肝了一下。期待同志们,在各种平台各显神通,顺便检验libxnes的可移植性。
最近编辑记录 xboot (2024-10-08 11:47:34)
离线
添加对mapper 66的支持,因140跟66比较接近,也顺便一起支持了
https://gitee.com/xboot/libxnes/blob/master/src/mapper66.c
https://gitee.com/xboot/libxnes/blob/master/src/mapper140.c
离线
各种mapper是有标准的吗?还是全靠逆向分析出来的?
mapper资料网上很齐全,NES已经被研究很彻底了,现在开发有很多现成的资源可以捡。
楼上有mapper连接,这些mapper要支持全,挑战性不小,有点哭笑不得的事,不少mapper就几个游戏,甚至有些mapper就只有一个游戏,投入产出不成正比。
最近编辑记录 xboot (2024-10-09 17:58:07)
离线
关于图像拉升缩放,这个对于NES用传统的拉伸缩放算法,对于像素级游戏简直就是灾难,有很多缩放算法专门针对像素级游戏的,这些都值得深入研究。
离线
现在的实现,虽说是精确到每一个指令的准确周期,但每一条指令都是原子化的,这就意味着,要么不干活,要干就干完,但实际情况,并不是这样,比如一条指令需要多个周期,取指周期,译码周期,执行周期,访问内存周期,跨页周期,条件跳转判断周期,每个周期都需要干特别的事情,说白了点,就是现在的实现粒度不够细,(当然对于模拟器也没必要特别细,比如精确到电路的电平及时序这种级别)。之所以会思考粒度问题,就是因为测试发现,nesdev网站上的那些刁钻的测试rom,就专门针对这种情况而设计的,要想通过测试,就必须将原子化的指令拆分出各种过程,这个任务是当前的重点任务了,比起支持更多的mapper这些来说,显得更关键了点。
网上有完全精确的模拟器实现,但是效率太低,不太实用,这个粒度的细分就需要好好考究了,要分但又不能太细,需要做好折中。估计接下来一段时间会优先考虑这些问题,估计结构上会做较大变化了。
离线
为了增强代码的可读性,将卡带的读写接口进行拆分,拆分成完全独立的cpu总线读写以及完全独立的ppu总线读写,新接口如下:
uint8_t (*cpu_read)(struct xnes_ctx_t * ctx, uint16_t addr);
void (*cpu_write)(struct xnes_ctx_t * ctx, uint16_t addr, uint8_t val);
uint8_t (*ppu_read)(struct xnes_ctx_t * ctx, uint16_t addr);
void (*ppu_write)(struct xnes_ctx_t * ctx, uint16_t addr, uint8_t val);
void (*ppu_step)(struct xnes_ctx_t * ctx);
void (*apu_step)(struct xnes_ctx_t * ctx);
红白机系统里面有两条总线,一条是CPU总线,另一条是PPU总线,两者完全独立,CPU是无法直接访问PPU总线上的内容的,必须通过PPU的寄存器来间接访,因为PPU寄存器才8个,只靠这8个来通信效率肯定不太高,所有这8个寄存器里面又有个OAM DMA,可以通过DMA来提供通信效率。
顺便再导出一个ppu step接口,以及apu step接口,某些卡带里面带有音频扩展能力,虽然现在没实现,但先预留接口,增强扩展能力。
离线
Mesen比较强大的,支持CRT滤镜,反射边框等等,但上这些效果,对显卡有点要求,集成显卡的机器,开这个感觉卡卡的
离线
贴一个倒带的演示视频,默认缓存30S,现在ppu部分占用内存较多,这个地方需要优化一下,降低对内存的要求。
离线