3 ms·

> I wrote it to be close to what the hardware does Your code is quite clean, but I'm not sure I'd say the rendering code is all that close to what the hardware

> I wrote it to be close to what the hardware does Your code is quite clean, but I'm not sure I'd say the rendering code is all that close to what the hardware does. For instance, the hardware does sprite rendering in 3 distinct phases (sprite list is scanned for sprites on the current line and the first 20/16 are recorded somewhere, the non-cached half of each of those 20/16 sprites is read and then up to 40/32 tiles worth of pixel data is drawn to the line buffer. Background layer rendering is a bit different too. The VDP actually renders an extra 2 columns worth of background data (so 42 or 34 total) to enable fine scrolling. Rendering takes place 2 columns at a time to what I believe is a 32 pixel ring buffer. The data in the ring buffer is composited with the data in the sprite line buffer as it's output to the display. The "window bug" is just a consequence of the 2 column coarse scroll granularity and the fact that it literally replaces the Plane A draws to the ring buffer. This is not intended as a criticism of your code. If you're only going for scanline granularity, most of the above is of little consequence (apart from the window bug) and would only add complexity. That said, I think my emulator, BlastEm[0], is probably a better reference for low-level VDP behavior as it has access slot granularity and mirrors the behavior above pretty closely. The code has gotten a bit messy though. There's also Exodus[1], which has a quite heavily commented VDP core (a bit too heavily for my taste, but I imagine others may disagree). [0] http://rhope.retrodev.com/files/blastem.html http://rhope.retrodev.com/files/blastem.html [1] https://bitbucket.org/exodusemulator/exodus https://bitbucket.org/exodusemulator/exodus EDIT: Fixed typo "line scrolling" should have ready "fine scrolling in the 3rd paragraph.

giovannibajo1 11y ago
> Your code is quite clean, but I'm not sure I'd say the rendering code is all that close to what the hardware does. OK you're right, what I really meant is that my code is a clear description of the basic hardware features and how they work, at the level of the detail discussed in the blog post being discussed (OP). As you noticed, I'm not emulating anything sub-scanline. If you look at the precise_dma_fifo branch, I've attempted some sub-scanline precision timing, while keeping the rendering at the scanline level. The result is encouraging: for instance, the 512C "your emulator suck" screen in Overdrive correctly works (at least in the PAL version IIRC). I think I hit a limit with the way timing was computed in the CPU cores I was using, and then dropped it for boredom. There were also a few regressions, visible in Overdrive itself (which is almost perfect on master, with the 512C screen being the big exception). > I think my emulator, BlastEm[0] Thanks for the reference, I'll have a look.
- mikepavone 11y ago
  > The result is encouraging: for instance, the 512C "your emulator suck" screen in Overdrive correctly works (at least in the PAL version IIRC). I think I hit a limit with the way timing was computed in the CPU cores I was using, and then dropped it for boredom. There were also a few regressions, visible in Overdrive itself (which is almost perfect on master, with the 512C screen being the big exception). Overdrive is tough. It has some nasty race conditions in it and of course the 512C scene requires a reasonable approximation of the reduction in sprite capacity. I don't have it working 100% myself (wanted to get some other timing related things tightened up before trying to chase down the cause of race that doesn't happen on real hardware). I commend you on getting as far as you did. The moose chase level of Mickey Mania is another good thing to check out as it also requires emulation of the sprite capacity reduction.
  - giovannibajo1 11y ago
    That works as well, with a really small glitch which I'm not sure if it's present on the real hardware as well. I think my emulation of sprite limits is correct.

giovannibajo1 11y ago

> Your code is quite clean, but I'm not sure I'd say the rendering code is all that close to what the hardware does. OK you're right, what I really meant is that my code is a clear description of the basic hardware features and how they work, at the level of the detail discussed in the blog post being discussed (OP). As you noticed, I'm not emulating anything sub-scanline. If you look at the precise_dma_fifo branch, I've attempted some sub-scanline precision timing, while keeping the rendering at the scanline level. The result is encouraging: for instance, the 512C "your emulator suck" screen in Overdrive correctly works (at least in the PAL version IIRC). I think I hit a limit with the way timing was computed in the CPU cores I was using, and then dropped it for boredom. There were also a few regressions, visible in Overdrive itself (which is almost perfect on master, with the 512C screen being the big exception). > I think my emulator, BlastEm[0] Thanks for the reference, I'll have a look.

mikepavone 11y ago
> The result is encouraging: for instance, the 512C "your emulator suck" screen in Overdrive correctly works (at least in the PAL version IIRC). I think I hit a limit with the way timing was computed in the CPU cores I was using, and then dropped it for boredom. There were also a few regressions, visible in Overdrive itself (which is almost perfect on master, with the 512C screen being the big exception). Overdrive is tough. It has some nasty race conditions in it and of course the 512C scene requires a reasonable approximation of the reduction in sprite capacity. I don't have it working 100% myself (wanted to get some other timing related things tightened up before trying to chase down the cause of race that doesn't happen on real hardware). I commend you on getting as far as you did. The moose chase level of Mickey Mania is another good thing to check out as it also requires emulation of the sprite capacity reduction.
- giovannibajo1 11y ago
  That works as well, with a really small glitch which I'm not sure if it's present on the real hardware as well. I think my emulation of sprite limits is correct.