Jump to content

JetSetIlly

Members
  • Content Count

    219
  • Joined

  • Last visited

Community Reputation

205 Excellent

1 Follower

About JetSetIlly

  • Rank
    Chopper Commander

Contact / Social Media

Profile Information

  • Custom Status
    https://github.com/JetSetIlly/Gopher2600

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. This is a lot more effective than I was expecting. Well done.
  2. Quite a lot has changed in the few weeks so I've packaged up another release. Windows and Linux binaries (AMD64) on the github page. https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.13 Full change log in the link but the most significant changes are: 1) Better ARM/Thumb cycle counting. This still isn't 100% but I've managed to improve the accuracy considerably after chatting things through with @Thomas Jentzsch and getting some valuable feedback from @Andrew Davie. More significant than cycle-counting, Andrew identified an issue that turned out to be a subtle but serious bug in the LDMIA instruction. This is now fixed along with a bug in the format 15 CMP instruction. 2) Support for the STM32F407VGT6 memory map. This is the ARM chip that is found in the PlusCart. This should help when developing CDFJ games that can run on that cartridge. I know @Al_Nafuur has been trying this out and has had some success. 3) Better ghosting effect on the TV screen. My previous bilinear filter was applied horizontally and vertically. This is wrong and created ugly artefacts, more noticeable on some ROMs that others. Using Zookeeper as an example, this is from the new version. And a close up from Hack'Em Hangly Man If the ghosting effect is too strong, there is a slider in the CRT Preferences window (F10 in playmode) for you to adjust. 4) Also added is a screen roll sensitivity slider. This controls how tolerant the screen is of unsynced TV frames. Related to this is how aggressive screen "resizing" is. By this I mean the process of deciding how many scanlines are required to be displayed but no more than necessary (and it's not as easy as looking for the VBLANK signal). I've tried several strategies over the last year or so and I'm now finally satisfied with it. As part of these improvements the FPS indicator (F7 in playmode) now shows more information. In addition to current FPS it will now show basic TV information including whether the screen in "unsynced". 5) Better static disassembly and fixed symbols usage. Figuring out what bytes in a ROM is an instruction is not always straightforward without actually executing the ROM. This is now a lot better I feel but as ever I welcome feedback on this and any other issue. Enjoy.
  3. A few months ago I was talking about techniques for capturing screenshots of games that use flicker kernels. Today when I was implementing a pause feature for play-mode I was reminded that similar problems exist for the paused screen. My solution is to assume that a display is interlaced on a two-frame cycle and to continue the flicker through inference. I think the results are pretty good (video below) Of course, the same problems that arise when creating screenshots also apply here. So, displays that flicker on a three frame cycle or have elements that flicker at different rates will have suboptimal results. Also, displays that have no flicker but have moving objects will "shimmer" when paused. But IMO, this is better than showing a single frame which to the eye looks to have missing elements. Ideally, we would be able to detect what kind of kernel the ROM is using and use the appropriate method. However, this would involve an analysis of the pixels being pushed by the TIA I think and isn't at all trivial. But it is something to keep in mind I think. output.mp4 Game is Zookeeper from @johnnywc
  4. I've used the data and ROMs Thomas has posted and used them to improve the cycle counting in Gopher2600. There are a couple of problem areas but on the whole it seems fairly consistent in all combinations. Certainly, all real-world ROMs that I have been using for testing (Turbo, Draconian, Zaxxon, etc.) continue to perform as expected (causing screen roll or not depending on the MAM settings). If nothing else it shows that 100% accuracy is within reach.
  5. This is really useful data. For what it's worth, Gopher2600 is close in some areas and not in others. If we look at MAM-0 for example O0 and Os are pretty around 100% but O2 and O3 are less than 100% so something is happening in the optimised code which is upsetting the emulation. I'll take a closer look to see what the differences are.
  6. Oh I see what you mean. Yes. I've been working on the assumption that SRAM has no waiting.
  7. It affects peripherals. So, anything with an address in the range 0xE0000000 to 0xEFFFFFFF is on the peripheral bus. SRAM is not on that bus so is not affected by the APB divider.
  8. Do we know if the Harmony driver sets the APB divider to 1 or if it has been left at the default rate of 1/4. I'm guessing it's set to 1 but I don't know.
  9. Does the Encore have a 70MHz processor like the original Harmony?
  10. Yes. I was thinking from an emulation point of about why this works without any change to the driver. And it's because these functions are copied from ROM to RAM as part of the .data section, which is already emulated (in Stella, etc.). Very nice solution for time critical code.
  11. This is incredibly useful. PrepAreaBuffers() appears top be at 0x000011b0 while RAM_PrepAreaBuffers() appears to be at 0x4000185c. There's no copying of the custom program to somewhere in RAM, it's just the variable block. Interesting.
  12. The changes I've made today around cycle accuracy and how the MAM works is worth packaging up I think. Summary: - MAM now differentiates between mode 1 and 2 - MAM set according to cartridge mapper (ie. DPC+ or CDF*) [thanks @SpiceWare] - Counting of conditional branches corrected [thanks @Thomas Jentzsch] https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.12.1 And thanks to @Al_Nafuur for help with the Windows binary.
  13. Good point. Currently the assumption that access to SRAM is only made in the case of PUSH, POP and LDMIA and STMIA, which I think is reasonable. All other loads and stores are stretched for Flash memory. The current MAM mode alters that but in principle most read/writes are stretched for Flash. But as you said in a previous post, the available documentation for cycle usage isn't very good, so I'm making a lot of assumptions 😕 At the moment, I'm happy if the timings work out so that (a) existing ROMs work (or don't work) as expected and (b) that it's helpful for developing new ROMs. Which for me, means causing a screen roll or running past the end of memory if the Thumb program runs too long.
  14. It's definitely running ARM code. So we can assume that it just so happens not to trigger the bug. I'm assuming that the PC will never jump from one area to the other and that data read/writes are always from SRAM. I'm already measuring if the read/write is from RAM or Flash. Right. That's probably enough information to have a linting check in the emulator. (Probably not needed now that CDF* is availble but it's a nice feature). Thanks @SpiceWare and @Thomas Jentzsch for the info and helping me think things through.
×
×
  • Create New...