CPU 仿真并锁定到特定时钟速度
如果您阅读过我的其他问题,您就会知道我这个周末已经组装了 6502 CPU 模拟器作为编程练习。
CPU 模拟器已经基本完成,从我有限的测试来看似乎相当准确,但是它运行得非常快,我想将其降低到机器的实际时钟速度。
我当前的测试循环是这样的:
// Just loop infinitely.
while (1 == 1)
{
CPU.ClockCyclesBeforeNext--;
if (CPU.ClockCyclesBeforeNext <= 0)
{
// Find out how many clock cycles this instruction will take
CPU.ClockCyclesBeforeNext = CPU.OpcodeMapper.Map[CPU.Memory[CPU.PC]].CpuCycles;
// Run the instruction
CPU.ExecuteInstruction(CPU.Memory[CPU.PC]);
// Debugging Info
CPU.DumpDebug();
Console.WriteLine(CPU.OpcodeMapper.Map[CPU.Memory[CPU.PC]].ArgumentLength);
// Move to next instruction
CPU.PC += 1 + CPU.OpcodeMapper.Map[CPU.Memory[CPU.PC]].ArgumentLength;
}
}
如您所知,每个操作码都需要一定的时间才能完成,因此在对 CPU 周期时钟进行倒计时之前,我不会运行下一条指令。 这提供了操作码之间的正确计时,只是整个过程运行得很快。
目标 CPU 速度是 1.79mhz,但是我希望任何时钟问题的解决方案都能将速度保持在 1.79mhz,即使我增加了复杂性,这样我就不必调整它。
有任何想法吗?
If you had read my other question, you'll know I've spent this weekend putting together a 6502 CPU emulator as a programming exercise.
The CPU emulator is mostly complete, and seems to be fairly accurate from my limited testing, however it is running incredibly fast, and I want to throttle it down to the actual clock speed of the machine.
My current test loop is this:
// Just loop infinitely.
while (1 == 1)
{
CPU.ClockCyclesBeforeNext--;
if (CPU.ClockCyclesBeforeNext <= 0)
{
// Find out how many clock cycles this instruction will take
CPU.ClockCyclesBeforeNext = CPU.OpcodeMapper.Map[CPU.Memory[CPU.PC]].CpuCycles;
// Run the instruction
CPU.ExecuteInstruction(CPU.Memory[CPU.PC]);
// Debugging Info
CPU.DumpDebug();
Console.WriteLine(CPU.OpcodeMapper.Map[CPU.Memory[CPU.PC]].ArgumentLength);
// Move to next instruction
CPU.PC += 1 + CPU.OpcodeMapper.Map[CPU.Memory[CPU.PC]].ArgumentLength;
}
}
As you can tell, each opcode takes a specific amount of time to complete, so I do not run the next instruction until I count down the CPU Cycle clock. This provides proper timing between opcodes, its just that the entire thing runs way to fast.
The targeted CPU speed is 1.79mhz, however I'd like whatever solution to the clock issue to keep the speed at 1.79mhz even as I add complexity, so I don't have to adjust it up.
Any ideas?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(7)
许多年前,我编写了一个 Z80 模拟器,为了实现周期精确执行,我将时钟速率划分为许多小块,并让核心执行那么多时钟周期。 就我而言,我将其与我正在模拟的游戏系统的帧速率联系起来。 每个操作码都知道执行需要多少个周期,并且核心将继续运行操作码,直到执行了指定的周期数。 我有一个外部运行循环,它将运行 cpu 核心,并运行模拟系统的其他部分,然后休眠直到下一次迭代的开始时间。
编辑:添加运行循环的示例。
希望这可以帮助。
I wrote a Z80 emulator many years ago, and to do cycle accurate execution, I divided the clock rate into a number of small blocks and had the core execute that many clock cycles. In my case, I tied it to the frame rate of the game system I was emulating. Each opcode knew how many cycles it took to execute and the core would keep running opcodes until the specified number of cycles had been executed. I had an outer run loop that would run the cpu core, and run other parts of the emulated system and then sleep until the start time of the next iteration.
EDIT: Adding example of run loop.
Hope this helps.
查看原始的 Quicktime 文档以获取灵感。
它是很久以前写的,当时显示视频意味着只需以足够高的速度交换静止帧,但苹果公司的人决定他们需要一个完整的时间管理框架。 该设计乍一看似乎过度设计,但它让它们能够处理截然不同的速度要求并保持它们紧密同步。
你很幸运,6502 具有确定性的时间行为,每条指令所需的确切时间都有详细记录; 但它不是恒定的。 有些指令需要 2 个周期,其他则需要 3 个周期。就像 QuickTime 中的帧一样,视频没有“每秒帧数”参数,每个帧都会告诉它要在屏幕上显示多长时间。
由于现代 CPU 的不确定性非常大,而且多任务操作系统甚至可能会冻结几毫秒(虚拟内存!),因此如果您落后于计划,或者如果您可以小睡几微秒,则应该留意。
Take a look at the original quicktime documentation for inspiration.
It was written a long time ago, when displaying video meant just swapping still frames at high enough speed, but the Apple guys decided they needed a full time-management framework. The design at first looks overengineered, but it let them deal with widely different speed requirements and keep them tightly synchronized.
you're fortunate that 6502 has deterministic time behaviour, the exact time each instruction takes is well documented; but it's not constant. some instructions take 2 cycles, other 3. Just like frames in QuickTime, a video doesn't have a 'frames per second' parameter, each frame tells how long it wants to be in screen.
Since modern CPU's are so non-deterministic, and multitasking OS's can even freeze for a few miliseconds (virtual memory!), you should keep a tab if you're behind schedule, or if you can take a few microseconds nap.
正如 jfk 所说,最常见的方法是将 CPU 速度与(模拟)视频输出的垂直刷新联系起来。
选择每个视频帧运行的周期数。 这通常是特定于机器的,但您可以通过以下方式计算它:
然后您还可以进行睡眠,直到视频更新完成,此时您开始下一个 CPU 模拟周期。
如果您正在模拟某些特定的东西,那么您只需要查找 fps 速率和处理器速度即可获得大致正确的结果。
编辑:如果您没有任何外部时序要求,那么模拟器尽可能快地运行是正常的。 有时这是预期的效果,有时则不是:)
As jfk says, the most common way to do this is tie the cpu speed to the vertical refresh of the (emulated) video output.
Pick a number of cycles to run per video frame. This will often be machine-specific but you can calculate it by something like :
Then you also get to do a sleep until the video update is hit, at which point you start the next n cycles of CPU emulation.
If you're emulating something in particular then you just need to look up the fps rate and processor speed to get this approximately right.
EDIT: If you don't have any external timing requirements then it is normal for an emulator to just run as fast as it possibly can. Sometimes this is a desired effect and sometimes not :)
我会使用时钟周期来计算时间,然后让它们睡眠时间差。 当然,要做到这一点,你需要一个高分辨率的时钟。 他们这样做会在旋转循环中使 CPU 达到峰值。
I would use the clock cycles to calculate time and them sleep the difference in time. Of course, to do this, you need a high-resolution clock. They way you are doing it is going to spike the CPU in spinning loops.
是的,正如之前所说,大多数时候您不需要 CPU 模拟器来以与真实设备相同的速度模拟指令。 用户感知的是计算的输出(即音频和视频输出),因此您只需与此类输出同步,这并不意味着您必须具有精确的 CPU 模拟速度。
换句话说,如果视频输入的帧速率是 50Hz,那么让 CPU 模拟器尽可能快地运行来绘制屏幕,但一定要以正确的速率 (50Hz) 输出屏幕帧。 从外部角度来看,您的模拟器正在以正确的速度进行模拟。
在像 Windows 或 Linux 这样的多任务操作系统上,即使在执行时间上也试图做到周期精确是没有意义的,因为模拟器指令时间(对于老式 80 年代的 CPU 通常为 1uS)和现代操作系统的调度时隙是可比的。
尝试以 50Hz 的速率输出内容是一项简单得多的任务,您可以在任何现代机器上做得很好
Yes, as said before most of the time you don't need a CPU emulator to emulate instructions at the same speed of the real thing. What user perceive is the output of the computation (i.e. audio and video outputs) so you only need to be in sync with such outputs which doesn't mean you must have necessarily an exact CPU emulation speed.
In other words, if the frame rate of the video input is, let's say, 50Hz, then let the CPU emulator run as fast as it can to draw the screen but be sure to output the screen frames at the correct rate (50Hz). From an external point of view your emulator is emulating at the correct speed.
Trying to be cycle exact even in the execution time is a non-sense on a multi-tasking OS like Windows or Linux because the emulator instruction time (tipically 1uS for vintage 80s CPUs) and the scheduling time slot of the modern OS are comparable.
Trying to output something at a 50Hz rate is a much simpler task you can do very good on any modern machine
如果实现了音频仿真,并且音频输出与系统/CPU 时钟相关,则可以使用另一种选择。 我尤其知道 8 位 Apple ][ 计算机就是这种情况。
通常声音是在固定大小(固定时间)的缓冲区中生成的,因此这些缓冲区的操作(数据生成等)可以通过同步原语与 CPU 吞吐量相关联。
Another option is available if audio emulation is implemented, and if audio output is tied to the system/CPU clock. In particular I know that this is the case with the 8-bit Apple ][ computers.
Usually sound is generated in buffers of a fixed size (which is a fixed time), so operation (generation of data etc) of these buffers can be tied to CPU throughput via synchronization primitives.
我正在制作一些更通用的基于用例的东西,例如将时间转换为估计指令量的能力,反之亦然。
项目主页是@ http://net7mma.codeplex.com
代码开头是这样的:(我认为)
Once你有某种类型的外行时钟实现,你可以升级到像计时器这样的东西
然后你可以使用类似的东西真正复制一些逻辑
最后,创建一些半有用的东西,例如总线,然后可能是一个虚拟屏幕来发出数据到公交车...
这是我测试
StopWatch
的方法I am in the process of making something a little more general use case based, such as the ability to convert time to an estimated amount of instructions and vice versa.
The project homepage is @ http://net7mma.codeplex.com
The code starts like this: (I think)
Once you have some type of layman clock implementation you advance to something like a
Timer
Then you can really replicate some logic using something like
Finally, create something semi useful e.g. a Bus and then perhaps a virtual screen to emit data to the bus...
Here is how I tested the
StopWatch