Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

1 Neutral

1 Follower

About snes2600

  • Rank
    Space Invader

Recent Profile Visitors

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

  1. Two ideas came to mind for Libretro. 1) Create new CPU method that allows us to memcpy a new RAM block. Avoiding the 128 pokes that creates some slowdown to support achievements. Although I doubt Mappy would drop to 53 fps because of it. 2) Create a libretro option to control framebuffer size: Full, Resize. Full will always create the 568x312 or something buffer. Resize will recreate lores 256x240 (ish) or hires 568. This can greatly affect shader fps on potato graphic cards with non-blargg, as it's 256x256 vs 1024x1024 for glsl. I might try pushing for both, to close performance "loopholes" on weaker systems like Core2. Or I suppose future generations of $5 RPI Zeroes.
  2. Lots of agreement on this approach. Add me also. Ah, okay. So someone would have to be a troll and write a demo that'd CPU waste time doing that. Fixed for my build. https://github.com/snes2600/handy-fork/commit/27e855e1b343f2be585232250a3caad83d179145 Have to check where EEPROM port is being dummy read. That could be important to look into. I hate frontend / GUI stuff so I'd leave others alone.
  3. Okay. So if we make the 1st initial "core branch" commit using just the vanilla (0.95-patched core), the Keith Wilkins license will remain in good standing. And then we can safely backport the SDL additions without introducing GPL into the mix. Sounds cool. I guess when to split it off will be sage's jurisdiction. I did the libretro eeprom testing using the Flappy Bird demo, since it's easy to tinker with. And it was kinda disorienting to lose my (better) high score saves because the eeprom data wasn't part of a savestate, and I did some accidental loadstates using older, lower scores. Someone who doesn't know hex editing could get upset.
  4. Libretro had some stupid problem where it would keep zero'ing out eeprom on reset and exit. And then save this zero eeprom to disk. https://github.com/snes2600/handy-fork/commit/ba4507890de5756bfba75499f3972047687ab28d By memset(0) at constructor time only, it's done only once at cart creation. Handy then does eeprom::load afterwards to restore any previously saved data. And anytime we reset or quit, Handy will not accidentally reset the data again. There eventually could be Lynx homebrews that will use eeprom as extra "temporary ram". That would require it to be part of the savestate. Otherwise a loadstate would have some inconsistent data that would require it to be thrown away. This is more often with snes (commercial), sms + gg (translation hacks).
  5. https://github.com/snes2600/handy-fork/commit/c27c1c552e0f53dde006dcc37136ba3b705edca0 Turn back on Mikie when Susie hits VBlank. And (+100) extend the DMA penalty per hblank rendering. Roadblasters is now enjoyable for once. Less than +100 and we get less flicker but it's there. I might go back and change some older links to git commits for easier reading.
  6. Back to Ms. Pac-Man again. A diagram understanding. out susie in xxxx xxxx || xxxx || xxxx xxxx 1. Read ram. 1 penalty. xxxx xxxx || xxxx || aaaa bbbb 2. Pixel 1. xxxx xxxx || aaaa || bbbb xxxx 3. Pixel 2. xxxx aaaa || bbbb || xxxx xxxx 4. Write ram. 1 penalty. aaaa bbbb || xxxx || xxxx xxxx So that's 2 ram cycles per 2 pixels. Or average is 1 ram per pixel. We have to read every pixel, which incurs 1 ram cycle. So I'm simulating (cheating) this way. https://github.com/snes2600/handy-fork/commit/a27ee34e849e13217285af7621458baa7cb38bd5
  7. Urg. Well, snes has 40 cycles per line. Maybe experiment with a kludge (smaller ram) and see where we go. Roadblasters is still a puzzle. I'd thought that it would be Suzy going too slow, since Handy system cycles seems to revolve around Mikie MHz timing. So 4:1 Suzy to Mikie = /4 the cpu hold time. https://github.com/bspruck/handy-fork/blob/master/handy-win32src-0.95-patched/core/susie.cpp#L981 Which now HUD black flickers really badly instead. Tried blocking nested cpu irqs to slow down Mikie and we get the opposite with fun green flashing again. Guess have to try inspecting if this mystery black box is another sprite being laid on top, or that part of the hud not being drawn. Weird stuff.
  8. Does the code for 16K NOPs constantly cross page boundaries? Because I'd wonder if that'd trigger slowdowns. https://www.atariarchives.org/cfn/08/03/01.php We could have possible dram refresh penalties. As SNES uses 120ns DRAM and has refresh periods per scanline. https://github.com/bspruck/handy-fork/blob/master/handy-win32src-0.95-patched/core/c65c02.h#L1544 gSystemCycleCount+=(1+(1*CPU_RDWR_CYC)); The part about this that makes me wonder. System is a 16MHz crystal and CPU runs at 4MHz. Maybe that 1 internal cpu cycle should be raised? Suzy runs at 16MHz so I can forgive that. But the CPU too? Unsure. But gritty cycle stuff is getting above my league. And I've read here that which zaps the 2 nybble at a time idea. Still 1/1 ram r/w penalty seems reasonable for Ms. Pac-Man.
  9. Cool. I just did this: ULONG CMikie::DisplayEndOfFrame(void) { // Stop any further line rendering mLynxLineDMACounter=0; mLynxLine=mTIM_2_BKUP; if(gCPUWakeupTime) { gCPUWakeupTime = 0; ClearCPUSleep(); } .. Confused where the last flicker is coming from. It's like either Mikie doesn't have enough time to draw the last few lines or Susie isn't blitting fast enough. Some black rectangle that only shows up in-game when that condition hits; over several frames it floats upward but only affects the hud. About the license hell, all the emucore files in both branches have the same 2004 Wilkins license. Would it be possible to then do either: 1. Make an independent branch with just the core files. Say handy-core. Then have separate frontend branches (sdl, windows, libretro) all pull from handy-core. 3 different frontend licenses, with the 1 core license. If one wants to release, then bundle the files together. 2. Make a new branch. Branch = handy-bspruck - Files = license.txt, this_is_a_modified_version.txt - Folder 1 = core --- Merge the 2 branches, as the sdl one has some extras macros and formatting changes - Folder 2 = zlib-113 --- I think both branches are the same? - Folder 3 = sdl --- Files = gpl.txt, makefile, readme --- Folder 3a = src ----- Folder 3b = sdlemu - Folder 4 = windows --- Files = sln, vcproj --- Folder 4a = gui-windows - Folder 5 = libretro --- Files = libretro, misc --- Folder 5a,5b = libretro stuff which I guess is very similar to idea 1. No-intro went headerless with all their roms. I wonder how good the raw auto-detect works, if we switch to that instead of defaulting with the "needs header" message. edit: Figure worth asking. Does Lynx have any refresh period pauses? https://forums.nesdev.com/viewtopic.php?f=23&t=15261
  10. Uhm.. I have no idea. Whatever works best. :) Thanks guys for the info btw! As for Roadblasters, I've found a possibly interesting lead. Mikie goes to sleep because Susie does its drawing. It gets timer interrupted every so often. Okay. But Susie reaches the NMI VBlank. CMikie::DisplayEndOfFrame(void) Shouldn't Susie just "stop" or "abort" at this time? There's nothing left to draw because its VBlank for several lines? Because I remember reading that when Susie stops using the bus, Mikie comes back awake. Either way, I tried this and it removed a lot of the nasty flickering. Oh. I did try Ms. Pac-Man with 1/0 r/w to simulate the simultaneous 2 nybble processing idea. It runs close to 30 fps all the time. Especially if that DisplayEndOfFrame Susie CPUSleep abort is used.
  11. Rather than junk up the repo with possible wip drafts, I'll just mention here for later. Another optimization technique that maybe can go bye. https://github.com/bspruck/handy-fork/blob/master/handy-win32src-0.95-patched/core/mikie.cpp#L1747 https://github.com/bspruck/handy-fork/blob/master/handy-win32src-0.95-patched/core/mikie.cpp#L3706 Whenever mAUDIO_x_VOLUME is 0, it just skips the counter stuff. Which could be bad for handybug debugging and possibly muck up the timers and reloading. Imagine muting and later unmuting a channel for sfx purposes. Maybe when sage later clears out the PR queue, more things can be re-introduced. Less clutter to work with. Oh, btw. Is handy-sdl-master (0.98) or win32-0.95-patched considered more "master"? Because it'd be really helpful if the two could be merged together, like the libretro port pr. I'm guessing sdl-master is preferred but I'm afraid to touch anything until the pr line is sorted out.
  12. The part that bothers me about superclip is that currently it's used as an optimization technique. Throw away parts of the quad that are invisible. But this runs into corner cases that can't be easily controlled, when that tilt / rotation factor is included. Warbirds hit 1 but that can be worked around. The comment with Euro Soccer is another example. And there might be others that I could've introduced by accident or are less observable. I'd think it make more sense to just remove the speedup trick and just raw clip each pixel as it's drawn? Any system within the last 10 years should handle it plenty.
  13. Using the Ms. Pac-Man speedup Handy fix (1/1 sprite r/w), I get 60 fps. Stepped each frame to be sure; looks butter smooth.
  14. Wow. That's some missing cycles to account for. ^^ I've thought about the Warbirds superclip some more. Based on my pr: 1. We should now include the center point since it's a valid h,v coordinate. Added commit. 2. Thinking over that 0x8000 some more. It's a fudge factor to account for way-out-there sprite coords. Which only works? for 2 quads and must be sign flipped for the other 2 quads. But I'm not so sure now which is better: screen center or this extreme edge value. So edited PR with (DRAFT) title and do not merge yet. As for Ms. Pac-Man, a new thought. A pixel is a 4-bpp nybble. Can't the hardware do this then? 1. Read 2 pixels at a time. 1 i/o. 2. Internal picture math on 2 pixels. 3. Write 2 pixels back. 1 i/o. So even if no changes are done, it still writes back nybble pair anyway. 2 i/o total. That would be an improvement speedup.
  15. Out of curious, how do I compile that to a Handy lynx image for testing?
  • Create New...