mirror of https://github.com/bsnes-emu/bsnes.git
42 Commits
Author | SHA1 | Message | Date |
---|---|---|---|
Tim Allen | 4fb8ce2821 |
Update to v104r12 release.
byuu says: Changelog: - higan: URLs updated to HTTPS - sfc/ppu/background: use hires/interlace/mosaic-adjusted X/Y coordinates for offset-per-tile mode - sfc/ppu/background: hires mosaic seems to advance pixel counter on subscreen pixels - tomoko: added “Help→Credits” menu option (currently the page does not exist; should before v105) - tomoko: reduced volume slider from {0% - 500%} to {0% - 200%}. Distortion is too intense above 200%. - technically, I've encountered distortion at 200% as well in Prince of Persia for the SNES - nall/run/invoke: use program path for working directory - allows you to choose “Library→Import ROMs” from a different directory on the command-line I don't know how to assign credit for the mosaic stuff. It's been a work-in-progress with me, Cydrak, and hex_usr. The current design should be correct, but very unpleasant. The code desperately needs to be refactored, but my recent attempt at doing so ended in spectacular failure. |
|
Tim Allen | 7022d1aa51 |
Update to v103r23 release.
byuu says: Changelog: - gb: added accelerometer X-axis, Y-Axis inputs¹ - gb: added rumble input¹ - gb/mbc5: added rumble support² - gb/mbc6: added skeleton driver, but it doesn't boot Net de Get - gb/mbc7: added mostly complete driver (only missing EEPROM), but it doesn't boot Kirby Tilt 'n' Tumble - gb/tama: added leap year assignment - tomoko: fixed macOS compilation [MerryMage] - hiro/cocoa: fix table cell redrawing on updates and automatic column resizing [ncbncb] - hiro/cocoa: fix some weird issue with clicking table view checkboxes on Retina displays [ncbncb] - icarus: enhance Game Boy heuristics³ - nall: fix three missing return statements [Jonas Quinn] - ruby: hopefully fixed all compilation errors reported by Screwtape et al⁴ ¹: because there's no concept of a controller for cartridge inputs, I'm attaching to the base platform for now. An idea I had was to make separate ports for each cartridge type ... but this would duplicate the rumble input between MBC5 and MBC7. And would also be less discoverable. But it would be more clean in that users wouldn't think the Game Boy hardware had this functionality. I'll think about it. ²: it probably won't work yet. Rumble isn't documented anywhere, but I dug through an emulator named GEST and discovered that it seems to use bit 3 of the RAM bank select to be rumble. I don't know if it sets the bit for rumbling, then clears when finished, or if it sets it and then after a few milliseconds it stops rumbling. I couldn't test on my FreeBSD box because SDL 1.2 doesn't support rumble, udev doesn't exist on FreeBSD, and nobody has ever posted any working code for how to use evdev (or whatever it's called) on FreeBSD. ³: I'm still thinking about specifying the MBC7 RAM as EEPROM, since it's not really static RAM. ⁴: if possible, please test all drivers if you can. I want to ensure they're all working. Especially let me know if the following work: macOS: input.carbon Linux: audio.pulseaudiosimple, audio.ao (libao) If I can confirm these are working, I'm going to then remove them from being included with stock higan builds. I'm also considering dropping SDL video on Linux/BSD. XShm is much faster and supports blurring. I may also drop SDL input on Linux, since udev works better. That will free a dependency on SDL 1.2 for building higan. FreeBSD is still going to need it for joypad support, however. |
|
Tim Allen | 80841deaa5 |
Update to v103r21 release.
byuu says: Changelog: - gb: added TAMA emulation [thanks to endrift for the initial notes] - gb: save RTC memory to disk (MBC3 doesn't write to said memory yet; TAMA doesn't emulate it yet) - gb: expect MMM01 boot loader to be at end of ROM instead of start - gb: store MBC2 save RAM as 256-bytes (512x4-bit) instead of 512-bytes (with padding) - gb: major cleanups to every cartridge mapper; moved to Mapper class instead of MMIO class - gb: don't serialize all mapper states with every save state; only serialize the active mapper - gb: serialize RAM even if a battery isn't present¹ - gb/cartridge: removed unnecessary code; refactored other code to eliminate duplication of functions - icarus: improve GB(C) heuristics generation to not include filenames for cartridges without battery backup - icarus: remove incorrect rearrangement of MMM01 ROM data - md/vdp: fix CRAM reads -- fixes Sonic Spinball colors [hex\_usr] - tomoko: hide the main higan window when entering fullscreen exclusive mode; helps with multi-monitor setups - tomoko: destroy ruby drivers before calling Application::quit() [Screwtape] - libco: add settings.h and defines to fiber, ucontext [Screwtape] ¹: this is one of those crystal clear indications that nobody's actually playing the higan DMG/CGB cores, or at least not with save states. This was a major mistake. Note: I can't find any official documentation that `GL_ALPHA_TEST` was removed from OpenGL 3.2. Since it's not hurting anything except showing some warnings in debug mode, I'm just going to leave it there for now. |
|
Tim Allen | 0b4e7fb5a5 |
Update to v103r17 release.
byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize. |
|
Tim Allen | f87c6b7ecb |
Update to v103r16 release.
byuu says: Changelog: - emulator/audio: added the ability to change the output frequency at run-time without emulator reset - tomoko: display video synchronize option again¹ - tomoko: Settings→Configuration expanded to Settings→{Video, Audio, Input, Hotkey, Advanced} Settings² - tomoko: fix default population of audio settings tab - ruby: Audio::frequency is a double now (to match both Emulator::Audio and ASIO)³ - tomoko: changing the audio device will repopulate the frequency and latency lists - tomoko: changing the audio frequency can now be done in real-time - ruby/audio/asio: added missing device() information, so devices can be changed now - ruby/audio/openal: ported to new API; added device selection support - ruby/audio/wasapi: ported to new API, but did not test yet (it's assuredly still broken)⁴ ¹: I'm uneasy about this ... but, I guess if people want to disable audio and just have smooth scrolling video ... so be it. With Screwtape's documentation, hopefully that'll help people understand that video synchronization always breaks audio synchronization. I may change this to a child menu that lets you pick between {no synchronization, video synchronization, audio synchronization} as a radio selection. ²: given how much more useful the video and audio tabs are now, I felt that four extra menu items were worth saving a click and going right to the tab you want. This also matches the behavior of the Tools menu displaying all tool options and taking you directly to each tab. This is kind of a hard change to get used to ... but I think it's for the better. ³: kind of stupid because I've never seen a hardware sound card where floor(frequency) != frequency, but whatever. Yay consistency. ⁴: I'm going to move it to be event-driven, and try to support 24-bit sample formats if possible. Who knows which cards that'll fix and which cards that'll break. I may end up making multiple WASAPI drivers so people can find one that actually works for them. We'll see. |
|
Tim Allen | 4129630d97 |
Update to v103r15 release.
byuu says: Changelog: - ruby: rewrote the API interfaces for Video, Audio, Input - ruby/audio: can now select the number of output channels (not useful to higan, sorry) - ruby/asio: various improvements - tomoko: audio settings panel can now select separate audio devices (for ASIO, OSS so far) - tomoko: audio settings panel frequency and latency lists are dynamically populated now Note: due to the ruby API rewrite, most drivers will not compile. Right now, the following work: - video: Direct3D, XShm - audio: ASIO, OSS - input: Windows, SDL, Xlib It takes a really long time to rewrite these (six hours to do the above), so it's going to be a while before we're back at 100% functionality again. Errata: - ASIO needs device(), setDevice() - need to call setDevice() at program startup to populate frequency/latency settings properly - changing the device and/or frequency needs to update the emulator resampler rates The really hard part is going to be the last one: the only way to change the emulator frequency is to flush all the audio streams and then recompute all the coefficients for the resamplers. If this is called during emulation, all audio streams will be erased and thus no sound will be output. I'll most likely be forced to simply ignore device/frequency changes until the user loads another game. It is at least possible to toggle the latency dynamically. |
|
Tim Allen | ed5ec58595 |
Update to v103r13 release.
byuu says: Changelog: - gb/interface: fix Game Boy Color extension to be "gbc" and not "gb" [hex\_usr] - ms/interface: move Master System hardware controls below controller ports - sfc/ppu: improve latching behavior of BGnHOFS registers (not hardware verified) [AWJ] - tomoko/input: rework port/device mapping to support non-sequential ports and devices¹ - todo: should add move() to inputDevice.mappings.append and inputPort.devices.append - note: there's a weird GCC 4.9 bug with brace initialization of InputEmulator; have to assign each field separately - tomoko: all windows sans the main presentation window can be dismissed with the escape key - icarus: the single file selection dialog ("Load ROM Image...") can be dismissed with the escape key - tomoko: do not pause emulation when FocusLoss/Pause is set during exclusive fullscreen mode - hiro/(windows,gtk,qt): implemented Window::setDismissable() function (missing from cocoa port, sorry) - nall/string: fixed printing of largest possible negative numbers (eg `INT_MIN`) [Sintendo] - only took eight months! :D ¹: When I tried to move the Master System hardware port below the controller ports, I ran into a world of pain. The input settings list expects every item in the `InputEmulator<InputPort<InputDevice<InputMapping>>>>` arrays to be populated with valid results. But these would be sparsely populated based on the port and device IDs from inside higan. And that is done so that the Interface::inputPoll can have O(1) lookup of ports and devices. This worked because all the port and device IDs were sequential (they left no gaps in the maps upon creating the lists.) Unfortunately by changing the expectation of port ID to how it appears in the list, inputs would not poll correctly. By leaving them alone and just moving Hardware to the third position, the Game Gear would be missing port IDs of 0 and 1 (the controller ports of the Master System). Even by trying to make separate MasterSystemHardware and GameGearHardware ports, things still fractured when the devices were no longer contigious. I got pretty sick of this and just decided to give up on O(1) port/device lookup, and moved to O(n) lookup. It only knocked the framerate down by maybe one frame per second, enough to be in the margin of error. Inputs aren't polled *that* often for loops that usually terminate after 1-2 cycles to be too detrimental to performance. So the new input system now allows non-sequential port and device IDs. Remember that I killed input IDs a while back. There's never any reason for those to need IDs ... it was easier to just order the inputs in the order you want to see them in the user interface. So the input lookup is still O(1). Only now, everything's safer and I return a maybe<InputMapping&>, and won't crash out the program trying to use a mapping that isn't found for some reason. Errata: the escape key isn't working on the browser/message dialogs on Windows, because of course nothing can ever just be easy and work for me. If anyone else wouldn't mind looking into that, I'd greatly appreciate it. Having the `WM_KEYDOWN` test inside the main `Application_sharedProc`, it seems to not respond to the escape key on modal dialogs. If I put the `WM_KEYDOWN` test in the main window proc, then it doesn't seem to get called for `VK_ESCAPE` at all, and doesn't get called period for modal windows. So I'm at a loss and it's past 4AM here >_> |
|
Tim Allen | 434e303ffb |
Update to v103r12 release.
byuu says: Changelog: - ruby/video: cleaned up Direct3D9 driver and fixed catastrophic memory leak - ruby/video: added fullscreen exclusive mode support to the Direct3D9 driver¹ - ruby/video: minor cosmetic code cleanups to various drivers - tomoko: added support to always allow input when in fullscreen exclusive mode - tomoko: fixed window to not remove resizability flag when exiting fullscreen mode ¹: I am assuming that exclusive mode will try to capture the primary monitor. I don't know what will happen in multi-monitor setups, however, as I don't use such a setup here. Also, I am using `D3DPRESENT_DISCARD` instead of `D3DPRESENT_FLIP`. I'm not sure if this will prove better or worse, but I've heard it will waste less memory, and having a BackBufferCount of 1 should still result in page flipping anyway. The difference is supposedly just that you can't rely on the back buffer being a valid copy of the previous frame like you can with FLIP. Lastly, if you want Vsync, you can edit the configuration file to enable that, and then turn off audio sync. Errata: "pause emulation when focus is lost" is not working with exclusive mode. I need to add a check to never auto-pause when in exclusive mode. Thanks to bun for catching that one. |
|
Tim Allen | ee982f098a |
Update to v103r11 release.
byuu says: Changelog: - tomoko: removed "Settings→Video Emulation→Overscan Mask" setting¹ - tomoko: remove a few unnecessary calls to resizeViewport on startup - tomoko: only resize main window from video settings when in adaptive or toggling adaptive mode² - hiro/windows: add `SWP_NOACTIVATE` flag to prevent focus stealing on resizing invisible windows³ - hiro/windows: suppress spurious API-generated `onSize()` callback when calling `setVisible()` ¹: it just seemed like bad design to default to overscan masking being disabled with overscan masks of 8 horizontal, 8 vertical out of the box. Users would adjust the sliders and not see anything happening. Instead, I've set the default masks to zero. If you want to turn off overscan masking, simply slide those to zero again. ²: I figure the only way we're going to be able to fairly evaluate Screwtape's suggestion is to try it both ways. And I will admit, I kind of like the way this works as well ... a lot more so than I thought I would, so I think it was a great suggestion. Still, now's the time if people have strong opinions on this. Be sure to try both r10 and r11 to compare. Barring no other feedback, I'm going to keep it this way. ³: this fixes the blinking of the main window on startup. Screwtape, thanks again for the improvement suggestions. At this point though, I am not using a tiling window manager. If you are able to patch hiro/gtk and/or hiro/qt (I mostly use GTK) to work with tiling window managers better, I wouldn't mind applying said patches, so long as they don't break things on my own Xfce desktop with xfwm4. Also, I noticed one issue with Xfce ... if the window is maximized and I try to call `Window::setSize()`, it's not actually removing the maximize flag. We'll need to look into how to add that to GTK, but I don't think it's a huge issue. A similar glitch happens on windows where the icon still reflects being maximized, but it does actually shrink, it just sticks to the top left corner of the screen. So this isn't really a critical bug, but would be extra polish. |
|
Tim Allen | cbbf5ec114 |
Update to v103r10 release.
byuu says: Changelog: - tomoko: video scaling options are now resolutions in the configuration file, eg "640x480", "960x720", "1280x960" - tomoko: main window is now always resizable instead of fixed width (also supports maximizing) - tomoko: added support for non-integral scaling in windowed mode - tomoko: made the quick/managed state messaging more consistent - tomoko: hide "Find Codes ..." button from the cheat editor window if the cheat database is not present - tomoko: per-game cheats.bml file now goes into the higan/ subfolder instead of the root folder So the way the new video system works is you have the following options on the video settings panel: Windowed mode: { Aspect correction, Integral scaling, Adaptive } Fullscreen mode: { Aspect correction, Integral scaling } (and one day, hopefully Exclusive will be added here) Whenever you adjust the overscan masking, or you change any of the windowed or fullscreen mode settings, or you choose a different video scale from the main menu, or you load a new game, or you unload a game, or you rotate the display of an emulated system, the resizeViewport logic will be invoked. This logic will remember the last option you chose for video scale, and base the new window size on that value as an upper limit of the new window size. If you are in windowed mode and have adaptive enabled, it will shrink the window to fit the contents of the emulated system's video output. Otherwise, if you are not in integral scaling mode, it will scale the video as large as possible to fit into the video scaled size you have selected. Otherwise, it will perform an integral scale and center the video inside of the viewport. If you are in fullscreen mode, it's much the same, only there is no adaptive mode. A major problem with Xorg is that it's basically impossible to change the resizability attribute of a window post-creation. You can do it, but all kinds of crazy issues start popping up. Like if you toggle fullscreen, then you'll find that the window won't grow past a certain fairly small size that it's already at, and cannot be shrunk. And the multipliers will stop expanding the window as large as they should. And sometimes the UI elements won't be placed in the correct position, or the video will draw over them. It's a big mess. So I have to keep the main window always resizable. Also, note that this is not a limitation of hiro. It's just totally broken in Xorg itself. No amount of fiddling has ever allowed this to work reliably for me on either GTK+ 2 or Qt 4. So what this means is ... the adaptive mode window is also resizable. What happens here is, whenever you drag the corners of the main window to resize it, or toggle the maximize window button, higan will bypass the video scale resizing code and instead act as though the adaptive scaling mode were disabled. So if integral scaling is checked, it'll begin scaling in integral mode. Otherwise, it'll begin scaling in non-integral mode. And because of this flexibility, it no longer made sense for the video scale menu to be a radio box. I know, it sucks to not see what the active selection is anymore, but ... say you set the scale to small, then you accidentally resized the window a little, but want it snapped back to the proper small resolution dimensions. If it were a radio item, you couldn't reselect the same option again, because it's already active and events don't propagate in said case. By turning them into regular menu options, the video scale menu can be used to restore window sizing. Errata: On Windows, the main window blinks a few times on first load. The fix for that is a safeguard in the video settings code, roughly like so ... but note you'd need to make a few other changes for this to work against v103r10: auto VideoSettings::updateViewport(bool firstRun) -> void { settings["Video/Overscan/Horizontal"].setValue(horizontalMaskSlider.position()); settings["Video/Overscan/Vertical"].setValue(verticalMaskSlider.position()); settings["Video/Windowed/AspectCorrection"].setValue(windowedModeAspectCorrection.checked()); settings["Video/Windowed/IntegralScaling"].setValue(windowedModeIntegralScaling.checked()); settings["Video/Windowed/AdaptiveSizing"].setValue(windowedModeAdaptiveSizing.checked()); settings["Video/Fullscreen/AspectCorrection"].setValue(fullscreenModeAspectCorrection.checked()); settings["Video/Fullscreen/IntegralScaling"].setValue(fullscreenModeIntegralScaling.checked()); horizontalMaskValue.setText({horizontalMaskSlider.position()}); verticalMaskValue.setText({verticalMaskSlider.position()}); if(!firstRun) presentation->resizeViewport(); } That'll get it down to one blink, as with v103 official. Not sure I can eliminate that one extra blink. I forgot to remove the setResizable toggle on fullscreen mode exit. On Windows, the main window will end up unresizable after toggling fullscreen. I missed that one because like I said, toggling resizability is totally broken on Xorg. You can fix that with the below change: auto Presentation::toggleFullScreen() -> void { if(!fullScreen()) { menuBar.setVisible(false); statusBar.setVisible(false); //setResizable(true); setFullScreen(true); if(!input->acquired()) input->acquire(); } else { if(input->acquired()) input->release(); setFullScreen(false); //setResizable(false); menuBar.setVisible(true); statusBar.setVisible(settings["UserInterface/ShowStatusBar"].boolean()); } resizeViewport(); } Windows is stealing focus on calls to resizeViewport(), so we need to deal with that somehow ... I'm not really concerned about the behavior of shrinking the viewport below the smallest multiplier for a given system. It might make sense to snap it to the window size and forego all other scaling, but honestly ... meh. I don't really care. Nobody sane is going to play like that. |
|
Tim Allen | 7af270aa59 |
Update to v103r09 release.
byuu says: Changelog: - gba/apu: fixed wave RAM nibble ordering (fixes audio in Castlevania, PocketNES) - emulator: restructured video information to just a single videoResolution() → VideoResolution function - returns "projected size" (between 160x144 and 320x240) - "internal buffer size" (up to 1280x480) - returns aspect correction multiplier that is to be applied to the width field - the value could be < 1.0 to handle systems with taller pixels; although higan doesn't emulate such a system - tomoko: all calculations for scaling and overscan masking are done by the GUI now - tomoko: aspect correction can be enabled in either windowed or fullscreen mode separately; moved to Video settings panel - tomoko: video scaling multipliers (against 320x240) can now me modified from the default (2,3,4) via the configuration file - use this as a really barebones way of supporting high DPI monitors; although the GUI elements won't scale nicely - if you set a value less than two, or greater than your resolution divided by 320x240, it's your own fault when things blow up. I'm not babysitting anyone with advanced config-file only options. - tomoko: added new adaptive windowed mode - when enabled, the window will shrink to eliminate any black borders when loading a game or changing video settings. The window will not reposition itself. - tomoko: added new adaptive fullscreen mode - when enabled, the integral scaling will be disabled for fullscreen mode, forcing the video to fill at least one direction of the video monitor completely. I expect we will be bikeshedding for the next month on how to describe the new video options, where they should appear in the GUI, changes people want, etc ... but suffice to say, I'm happy with the functionality, so I don't intend to make changes to -what- things do, but I will entertain better ways to name things. |
|
Tim Allen | 191a71b291 |
Update to v103r08 release.
byuu says: Changelog: - emulator: improved aspect correction accuracy by using floating-point calculations - emulator: added videoCrop() function, extended videoSize() to take cropping parameters¹ - tomoko: the overscan masking function will now actually resize the viewport² - gba/cpu: fixed two-cycle delay on triggering DMAs; not running DMAs when the CPU is stopped - md/vdp: center video when overscan is disabled - pce/vce: resize video output from 1140x240 to 1120x240 - tomoko: resize window scaling from 326x240 to 320x240 - tomoko: changed save slot naming and status bar messages to indicate quick states vs managed states - tomoko: added increment/decrement quick state hotkeys - tomoko: save/load quick state hotkeys now save to slots 1-5 instead of always to 0 - tomoko: increased overscan range from 0-16 to 0-24 (in case you want to mask the Master System to 240x192) ¹: the idea here was to decouple raw pixels from overscan masking. Overscan was actually horrifically broken before. The Famicom outputs at 256x240, the Super Famicom at 512x480, and the Mega Drive at 1280x480. Before, a horizontal overscan mask of 8 would not reduce the Super Famicom or Mega Drive by nearly as much as the Famicom. WIth the new videoCrop() function, the internals of pixel size distortions can be handled by each individual core. ²: furthermore, by taking optional cropping information in videoSize(), games can scale even larger into the viewport window. So for example, before the Super Famicom could only scale to 1536x1440. But by cropping the vertical resolution by 6 (228p effectively, still more than NTSC can even show), I can now scale to 1792x1596. And wiht aspect correction, that becomes a perfect 8:7 ratio of 2048x1596, giving me perfectly crisp pixels without linear interpolation being required. Errata: for some reason, when I save a new managed state with the SFC core, the default description is being set to a string of what looks to be hex numbers. I found the cause ... I'll fix this in the next release. Note: I'd also like to hide the "find codes..." button if cheats.bml isn't present, as well as update the SMP TEST register comment from smp/timing.cpp |
|
Tim Allen | 8af3e4a6e2 |
Update to v102r22 release.
byuu says: Changelog: - higan: Emulator::Interface::videoSize() renamed to videoResolution() - higan: Emulator::Interface::rtcsync() renamed to rtcSynchronize() - higan: added video display rotation support to Video - GBA: substantially improved audio mixing - fixed bug with FIFO 50%/100% volume setting - now properly using SOUNDBIAS amplitude to control output frequencies - reduced quantization noise - corrected relative volumes between PSG and FIFO channels - both PSG and FIFO values cached based on amplitude; resulting in cleaner PCM samples - treating PSG volume=3 as 200% volume instead of 0% volume now (unverified: to match mGBA) - GBA: properly initialize ALL CPU state; including the vital prefetch.wait=1 (fixes Classic NES series games) - GBA: added video rotation with automatic key translation support - PCE: reduced output resolution scalar from 285x242 to 285x240 - the extra two scanlines won't be visible on most TVs; and they make all other cores look worse - this is because all other cores output at 240p or less; so they were all receiving black bars in windowed mode - tomoko: added "Rotate Display" hotkey setting - tomoko: changed hotkey multi-key logic to OR instead of AND - left support for flipping it back inside the core; for those so inclined; by uncommenting one line in input.hpp - tomoko: when choosing Settings→Configuration, it will automatically select the currently loaded system - for instance, if you're playing a Game Gear game, it'll take you to the Game Gear input settings - if no games are loaded, it will take you to the hotkeys panel instead - WS(C): merged "Hardware-Vertical", "Hardware-Horizontal" controls into combined "Hardware" - WS(C): converted rotation support from being inside the core to using Emulator::Video - this lets WS(C) video content scale larger now that it's not bounded by a 224x224 square box - WS(C): added automatic key rotation support - WS(C): removed emulator "Rotate" key (use the general hotkey instead; I recommend F8 for this) - nall: added serializer support for nall::Boolean (boolean) types - although I will probably prefer the usage of uint1 in most cases |
|
Tim Allen | c40e9754bc |
Update to v102r01 release.
byuu says: Changelog: - MS, MD, PCE: remove controllers from scheduler in destructor [hex_usr] - PCE: no controller should return all bits set (still causing errant key presses when swapping gamepads) - PCE: emulate MDR for hardware I/O $0800-$17ff - PCE: change video resolution to 1140x242 - PCE: added tertiary background Vscroll register (secondary cache) - PCE: create classes out of VDC VRAM, SATB, CRAM for cleaner access and I/O registers - PCE: high bits of CRAM read should be set - PCE: partially emulated VCE display registers: color frequency, HDS, HDW, VDS, VDW - PCE: 32-width sprites now split to two 16-width sprites to handle overflow properly - PCE: hopefully emulated sprite zero hit correctly (it's not well documented, and not often used) - PCE: trigger line coincidence interrupts during the previous scanline's Hblank period - tomoko: raise viewport from 320x240 to 326x242 to accommodate PC Engine's max resolution - nall: workaround for Clang compilation bug that can't figure out that a char is an integral data type |
|
Tim Allen | 26bd7590ad |
Update to v101r32 release.
byuu says: Changelog: - SMS: fixed controller connection bug - SMS: fixed Z80 reset bug - PCE: emulated HuC6280 MMU - PCE: emulated HuC6280 RAM - PCE: emulated HuCard ROM reading - PCE: implemented 178 instructions - tomoko: removed "soft reset" functionality - tomoko: moved "power cycle" to just above "unload" option I'm not sure of the exact number of HuC6280 instructions, but it's less than 260. Many of the ones I skipped are HuC6280-originals that I don't know how to emulate just yet. I'm also really unsure about the zero page stuff. I believe we should be adding 0x2000 to the addresses to hit page 1, which is supposed to be mapped to the zero page (RAM). But when I look at turboEMU's source, I have no clue how the hell it could possibly be doing that. It looks to be reading from page 0, which is almost always ROM, which would be ... really weird. I also don't know if I've emulated the T mode opcodes correctly or not. The documentation on them is really confusing. |
|
Tim Allen | 4d2e17f9c0 |
Update to v101r09 release.
byuu says: Sorry, two WIPs in one day. Got excited and couldn't wait. Changelog: - ADDQ, SUBQ shouldn't update flags when targeting an address register - ADDA should sign extend effective address reads - JSR was pushing the PC too early - some improvements to 8-bit register reads on the VDP (still needs work) - added H/V counter reads to the VDP IO port region - icarus: added support for importing Master System and Game Gear ROMs - tomoko: added library sub-menus for each manufacturer - still need to sort Game Gear after Mega Drive somehow ... The sub-menu system actually isn't all that bad. It is indeed a bit more annoying, but not as annoying as I thought it was going to be. However, it looks a hell of a lot nicer now. |
|
Tim Allen | ffd150735b |
Update to v101r07 release.
byuu says: Added VDP sprite rendering. Can't get any games far enough in to see if it actually works. So in other words, it doesn't work at all and is 100% completely broken. Also added 68K exceptions and interrupts. So far only the VDP interrupt is present. It definitely seems to be firing in commercial games, so that's promising. But the implementation is almost certainly completely wrong. There is fuck all of nothing for documentation on how interrupts actually work. I had to find out the interrupt vector numbers from reading the comments from the Sonic the Hedgehog disassembly. I have literally no fucking clue what I0-I2 (3-bit integer priority value in the status register) is supposed to do. I know that Vblank=6, Hblank=4, Ext(gamepad)=2. I know that at reset, SR.I=7. I don't know if I'm supposed to block interrupts when I is >, >=, <, <= to the interrupt level. I don't know what level CPU exceptions are supposed to be. Also implemented VDP regular DMA. No idea if it works correctly since none of the commercial games run far enough to use it. So again, it's horribly broken for usre. Also improved VDP fill mode. But I don't understand how it takes byte-lengths when the bus is 16-bit. The transfer times indicate it's actually transferring at the same speed as the 68K->VDP copy, strongly suggesting it's actually doing 16-bit transfers at a time. In which case, what happens when you set an odd transfer length? Also, both DMA modes can now target VRAM, VSRAM, CRAM. Supposedly there's all kinds of weird shit going on when you target VSRAM, CRAM with VDP fill/copy modes, but whatever. Get to that later. Also implemented a very lazy preliminary wait mechanism to to stall out a processor while another processor exerts control over the bus. This one's going to be a major work in progress. For one, it totally breaks the model I use to do save states with libco. For another, I don't know if a 68K->VDP DMA instantly locks the CPU, or if it the CPU could actually keep running if it was executing out of RAM when it started the DMA transfer from ROM (eg it's a bus busy stall, not a hard chip stall.) That'll greatly change how I handle the waiting. Also, the OSS driver now supports Audio::Latency. Sound should be even lower latency now. On FreeBSD when set to 0ms, it's absolutely incredible. Cannot detect latency whatsoever. The Mario jump sound seems to happen at the very instant I hear my cherry blue keyswitch activate. |
|
Tim Allen | 427bac3011 |
Update to v101r06 release.
byuu says: I reworked the video sizing code. Ended up wasting five fucking hours fighting GTK. When you call `gtk_widget_set_size_request`, it doesn't actually happen then. This is kind of a big deal because when I then go to draw onto the viewport, the actual viewport child window is still the old size, so the image gets distorted. It recovers in a frame or so with emulation, but if we were to put a still image on there, it would stay distorted. The first thought is, `while(gtk_events_pending()) gtk_main_iteration_do(false);` right after the `set_size_request`. But nope, it tells you there's no events pending. So then you think, go deeper, use `XPending()` instead. Same thing, GTK hasn't actually issued the command to Xlib yet. So then you think, if the widget is realized, just call a blocking `gtk_main_iteration`. One call does nothing, two calls results in a deadlock on the second one ... do it before program startup, and the main window will never appear. Great. Oh, and it's not just the viewport. It's also the widget container area of the windows, as well as the window itself, as well as the fullscreen mode toggle effect. They all do this. For the latter three, I couldn't find anything that worked, so I just added 20ms loops of constantly calling `gtk_main_iteration_do(false)` after each one of those things. The downside here is toggling the status bar takes 40ms, so you'll see it and it'll feel a tiny bit sluggish. But I can't have a 20ms wait on each widget resize, that would be catastrophic to performance on windows with lots of widgets. I tried hooking configure-event and size-allocate, but they were very unreliable. So instead I ended up with a loop that waits up to a maximm of 20ms that inspects the `widget->allocation.(width,height)` values directly and waits for them to be what we asked for with `set_size_request`. There was some extreme ugliness in GTK with calling `gtk_main_iteration_do` recursively (`hiro::Widget::setGeometry` is called recursively), so I had to lock it to only happen on the top level widgets (the child ones should get resized while waiting on the top-level ones, so it should be fine in practice), and also only run it on realized widgets. Even still, I'm getting ~3 timeouts when opening the settings dialog in higan, but no other windows. But, this is the best I can do for now. And the reason for all of this pain? Yeah, updated the video code. So the Emulator::Interface now has this: struct VideoSize { uint width, height; }; //or requiem for a tuple auto videoSize() -> VideoSize; auto videoSize(uint width, uint height, bool arc) -> VideoSize; The first function, for now, is just returning the literal surface size. I may remove this ... one thing I want to allow for is cores that send different texture sizes based on interlace/hires/overscan/etc settings. The second function is more interesting. Instead of having the UI trying to figure out sizing, I figure the emulation cores can do a better job and we can customize it per-core now. So it gets the window's width and height, and whether the user asked for aspect correction, and then computes the best width/height ratio possible. For now they're all just doing multiples of a 1x scale to the UI 2x,3x,4x modes. We still need a third function, which will probably be what I repurpose videoSize() for: to return the 'effective' size for pixel shaders, to then feed into ruby, to then feed into quark, to then feed into our shaders. Since shaders use normalized coordinates for pixel fetching, this should work out just fine. The real texture size will be exposed to quark shaders as well, of course. Now for the main window ... it's just hard-coded to be 640x480, 960x720, 1280x960 for now. It works nicely for some cores on some modes, not so much for others. Work in progress I guess. I also took the opportunity to draw the about dialog box logo on the main window. Got a bit fancy and used the old spherical gradient and impose functionality of nall/image on it. Very minor highlight, nothing garish. Just something nicer than a solid black window. If you guys want to mess around with sizes, placements, and gradient styles/colors/shapes ... feel free. If you come up with something nicer, do share. That's what led to all the GTK hell ... the logo wasn't drawing right as you resized the window. But now it is, though I am not at all happy with the hacking I had to do. I also had to improve the video update code as a result of this: - when you unload a game, it blacks out the screen - if you are not quitting the emulator, it'll draw the logo; if you are, it won't - when you load a game, it black out the logo These options prevent any unsightliness from resizing the viewport with image data on it already I need to redraw the logo when toggling fullscreen with no game loaded as well for Windows, it seems. |
|
Tim Allen | 1df2549d18 |
Update to v101r04 release.
byuu says: Changelog: - pulled the (u)intN type aliases into higan instead of leaving them in nall - added 68K LINEA, LINEF hooks for illegal instructions - filled the rest of the 68K lambda table with generic instance of ILLEGAL - completed the 68K disassembler effective addressing modes - still unsure whether I should use An to decode absolute addresses or not - pro: way easier to read where accesses are taking place - con: requires An to be valid; so as a disassembler it does a poor job - making it optional: too much work; ick - added I/O decoding for the VDP command-port registers - added skeleton timing to all five processor cores - output at 1280x480 (needed for mixed 256/320 widths; and to handle interlace modes) The VDP, PSG, Z80, YM2612 are all stepping one clock at a time and syncing; which is the pathological worst case for libco. But they also have no logic inside of them. With all the above, I'm averaging around 250fps with just the 68K core actually functional, and the VDP doing a dumb "draw white pixels" loop. Still way too early to tell how this emulator is going to perform. Also, the 320x240 mode of the Genesis means that we don't need an aspect correction ratio. But we do need to ensure the output window is a multiple 320x240 so that the scale values work correctly. I was hard-coding aspect correction to stretch the window an additional \*8/7. But that won't work anymore so ... the main higan window is now 640x480, 960x720, or 1280x960. Toggling aspect correction only changes the video width inside the window. It's a bit jarring ... the window is a lot wider, more black space now for most modes. But for now, it is what it is. |
|
Tim Allen | f5e5bf1772 |
Update to v100r16 release.
byuu says: (Windows users may need to include <sys/time.h> at the top of nall/chrono.hpp, not sure.) Unchangelog: - forgot to add the Scheduler clock=0 fix because I have the memory of a goldfish Changelog: - new icarus database with nine additional games - hiro(GTK,Qt) won't constantly write its settings.bml file to disk anymore - added latency simulator for fun (settings.bml => Input/Latency in milliseconds) So the last one ... I wanted to test out nall::chrono, and I was also thinking that by polling every emulated frame, it's pretty wasteful when you are using Fast Forward and hitting 200+fps. As I've said before, calls to ruby::input::poll are not cheap. So to get around this, I added a limiter so that if you called the hardware poll function within N milliseconds, it'll return without doing any actual work. And indeed, that increases my framerate of Zelda 3 uncapped from 133fps to 142fps. Yay. But it's not a "real" speedup, as it only helps you when you exceed 100% speed (theoretically, you'd need to crack 300% speed since the game itself will poll at 16ms at 100% speed, but yet it sped up Zelda 3, so who am I to complain?) I threw the latency value into the settings file. It should be 16, but I set it to 5 since that was the lowest before it started negatively impacting uncapped speeds. You're wasting your time and CPU cycles setting it lower than 5, but if people like placebo effects it might work. Maybe I should let it be a signed integer so people can set it to -16 and think it's actually faster :P (I'm only joking. I took out the 96000hz audio placebo effect as well. Not really into psychological tricks anymore.) But yeah seriously, I didn't do this to start this discussion again for the billionth time. Please don't go there. And please don't tell me this WIP has higher/lower latency than before. I don't want to hear it. The only reason I bring it up is for the fun part that is worth discussing: put up or shut up time on how sensitive you are to latency! You can set the value above 5 to see how games feel. I personally can't really tell a difference until about 50. And I can't be 100% confident it's worse until about 75. But ... when I set it to 150, games become "extra difficult" ... the higher it goes, the worse it gets :D For this WIP, I've left no upper limit cap. I'll probably set a cap of something like 500ms or 1000ms for the official release. Need to balance user error/trolling with enjoyability. I'll think about it. [...] Now, what I worry about is stupid people seeing it and thinking it's an "added latency" setting, as if anyone would intentionally make things worse by default. This is a limiter. So if 5ms have passed since the game last polled, and that will be the case 99.9% of the time in games, the next poll will happen just in time, immediately when the game polls the inputs. Thus, a value below 1/<framerate>ms is not only pointless, if you go too low it will ruin your fast forward max speeds. I did say I didn't want to resort to placebo tricks, but I also don't want to spark up public discussion on this again either. So it might be best to default Input/Latency to 0ms, and internally have a max(5, latency) wrapper around the value. |
|
Tim Allen | ca277cd5e8 |
Update to v100r14 release.
byuu says: (Windows: compile with -fpermissive to silence an annoying error. I'll fix it in the next WIP.) I completely replaced the time management system in higan and overhauled the scheduler. Before, processor threads would have "int64 clock"; and there would be a 1:1 relationship between two threads. When thread A ran for X cycles, it'd subtract X * B.Frequency from clock; and when thread B ran for Y cycles, it'd add Y * A.Frequency from clock. This worked well and allowed perfect precision; but it doesn't work when you have more complicated relationships: eg the 68K can sync to the Z80 and PSG; the Z80 to the 68K and PSG; so the PSG needs two counters. The new system instead uses a "uint64 clock" variable that represents time in attoseconds. Every time the scheduler exits, it subtracts the smallest clock count from all threads, to prevent an overflow scenario. The only real downside is that rounding errors mean that roughly every 20 minutes, we have a rounding error of one clock cycle (one 20,000,000th of a second.) However, this only applies to systems with multiple oscillators, like the SNES. And when you're in that situation ... there's no such thing as a perfect oscillator anyway. A real SNES will be thousands of times less out of spec than 1hz per 20 minutes. The advantages are pretty immense. First, we obviously can now support more complex relationships between threads. Second, we can build a much more abstracted scheduler. All of libco is now abstracted away completely, which may permit a state-machine / coroutine version of Thread in the future. We've basically gone from this: auto SMP::step(uint clocks) -> void { clock += clocks * (uint64)cpu.frequency; dsp.clock -= clocks; if(dsp.clock < 0 && !scheduler.synchronizing()) co_switch(dsp.thread); if(clock >= 0 && !scheduler.synchronizing()) co_switch(cpu.thread); } To this: auto SMP::step(uint clocks) -> void { Thread::step(clocks); synchronize(dsp); synchronize(cpu); } As you can see, we don't have to do multiple clock adjustments anymore. This is a huge win for the SNES CPU that had to update the SMP, DSP, all peripherals and all coprocessors. Likewise, we don't have to synchronize all coprocessors when one runs, now we can just synchronize the active one to the CPU. Third, when changing the frequencies of threads (think SGB speed setting modes, GBC double-speed mode, etc), it no longer causes the "int64 clock" value to be erroneous. Fourth, this results in a fairly decent speedup, mostly across the board. Aside from the GBA being mostly a wash (for unknown reasons), it's about an 8% - 12% speedup in every other emulation core. Now, all of this said ... this was an unbelievably massive change, so ... you know what that means >_> If anyone can help test all types of SNES coprocessors, and some other system games, it'd be appreciated. ---- Lastly, we have a bitchin' new about screen. It unfortunately adds ~200KiB onto the binary size, because the PNG->C++ header file transformation doesn't compress very well, and I want to keep the original resource files in with the higan archive. I might try some things to work around this file size increase in the future, but for now ... yeah, slightly larger archive sizes, sorry. The logo's a bit busted on Windows (the Label control's background transparency and alignment settings aren't working), but works well on GTK. I'll have to fix Windows before the next official release. For now, look on my Twitter feed if you want to see what it's supposed to look like. ---- EDIT: forgot about ICD2::Enter. It's doing some weird inverse run-to-save thing that I need to implement support for somehow. So, save states on the SGB core probably won't work with this WIP. |
|
Tim Allen | 8d5cc0c35e |
Update to v099r15 release.
byuu says: Changelog: - nall::lstring -> nall::string_vector - added IntegerBitField<type, lo, hi> -- hopefully it works correctly... - Multitap 1-4 -> Super Multitap 2-5 - fixed SFC PPU CGRAM read regression - huge amounts of SFC PPU IO register cleanups -- .bits really is lovely - re-added the read/write(VRAM,OAM,CGRAM) helpers for the SFC PPU - but they're now optimized to the realities of the PPU (16-bit data sizes / no address parameter / where appropriate) - basically used to get the active-display overrides in a unified place; but also reduces duplicate code in (read,write)IO |
|
Tim Allen | 67457fade4 |
Update to v099r13 release.
byuu says: Changelog: - GB core code cleanup completed - GBA core code cleanup completed - some more cleanup on missed processor/arm functions/variables - fixed FC loading icarus bug - "Load ROM File" icarus functionality restored - minor code unification efforts all around (not perfect yet) - MMIO->IO - mmio.cpp->io.cpp - read,write->readIO,writeIO It's been a very long work in progress ... starting all the way back with v094r09, but the major part of the higan code cleanup is now completed! Of course, it's very important to note that this is only for the basic style: - under_score functions and variables are now camelCase - return-type function-name() are now auto function-name() -> return-type - Natural<T>/Integer<T> replace (u)intT_n types where possible - signed/unsigned are now int/uint - most of the x==true,x==false tests changed to x,!x A lot of spot improvements to consistency, simplicity and quality have gone in along the way, of course. But we'll probably never fully finishing beautifying every last line of code in the entire codebase. Still, this is a really great start. Going forward, WIP diffs should start being smaller and of higher quality once again. I know the joke is, "until my coding style changes again", but ... this was way too stressful, way too time consuming, and way too risky. I'm too old and tired now for extreme upheavel like this again. The only major change I'm slowly mulling over would be renaming the using Natural<T>/Integer<T> = (u)intT; shorthand to something that isn't as easily confused with the (u)int_t types ... but we'll see. I'll definitely continue to change small things all the time, but for the larger picture, I need to just accept the style I have and live with it. |
|
Tim Allen | a816998122 |
Update to v099r10 release.
byuu says: Changelog: - higan/profile/ => higan/systems/ [temporary; unless we can't think of a better base folder name] - god-damn-better-have fixed the input polling bug - re-added command-line and drag-and-drop loading - command-line loading can now load multiple folders at once (SGB+GB game; Sufami Turbo+Slot A+Slot B; etc) - if you load just the base cart, it'll present you with a dialog to optionally load slotted cart(s) - MSU1 now goes through nall/vfs instead of directly accessing the filesystem - Famicom Cartridge, PPU cores updated to newer programming style - there's countless opportunity for BitField and .bits() in the PPU ... but I'm worried about breaking things If anyone has a working MSU1 game and can test the changes out, that'd be appreciated. I still don't have a test ROM on my dev box. I wouldn't worry too much about extensively testing the Famicom PPU changes just yet ... I'm still struggling with what to name the structs inside the classes between all of my emulators, and the BitField/.bits() changes will be much more important to test at a later date. The only use case left for Emulator::Interface::path(uint id) is for 21fx emulation. This peripheral loads a DLL/SO via LoadLibrary/dlopen, which do not have any official ways to open a file in RAM. I'm very hesitant to use the portable trick of writing the memory to a temporary file, loading it, and deleting the temporary file once done ... it's a real waste of disk activity. I might make something like vfs::file::isVirtual->bool,path()->string to get around this. But even once I do, the underlying LoadLibrary/dlopen call is still going to be direct disk access. |
|
Tim Allen | 3a9c7c6843 |
Update to v099r09 release.
byuu says: Changelog: - Emulator::Interface::Medium::bootable removed - Emulator::Interface::load(bool required) argument removed [File::Required makes no sense on a folder] - Super Famicom.sys now has user-configurable properties (CPU,PPU1,PPU2 version; PPU1 VRAM size, Region override) - old nall/property removed completely - volatile flags supported on coprocessor RAM files now (still not in icarus, though) - (hopefully) fixed SNES Multitap support (needs testing) - fixed an OAM tiledata range clipping limit in 128KiB VRAM mode (doesn't fix Yoshi's Island, sadly) - (hopefully, again) fixed the input polling bug hex_usr reported - re-added dialog box for when File::Required files are missing - really cool: if you're missing a boot ROM, BIOS ROM, or IPL ROM, it warns you immediately - you don't have to select a game before seeing the error message anymore - fixed cheats.bml load/save location |
|
Tim Allen | f48b332c83 |
Update to v099r08 release.
byuu says: Changelog: - nall/vfs work 100% completed; even SGB games load now - emulation cores now call load() for the base cartridges as well - updated port/device handling; portmask is gone; device ID bug should be resolved now - SNES controller port 1 multitap option was removed - added support for 128KiB SNES PPU VRAM (for now, edit sfc/ppu/ppu.hpp VRAM::size=0x10000; to enable) Overall, nall/vfs was a huge success!! We've substantially reduced the amount of boilerplate code everywhere, while still allowing (even easier than before) support for RAM-based game loading/saving. All of nall/stream is dead and buried. I am considering removing Emulator::Interface::Medium::id and/or bootable flag. Or at least, doing something different with it. The values for the non-bootable GB/BS/ST entries duplicate the ID that is supposed to be unique. They are for GB/GBC and WS/WSC. Maybe I'll use this as the hardware revision selection ID, and then gut non-bootable options. There's really no reason for that to be there. I think at one point I was using it to generate library tabs for non-bootable systems, but we don't do that anymore anyway. Emulator::Interface::load() may not need the required flag anymore ... it doesn't really do anything right now anyway. I have a few reasons for having the cores load the base cartridge. Most importantly, it is going to enable a special mode for the WonderSwan / WonderSwan Color in the future. If we ever get the IPLROMs dumped ... it's possible to boot these systems with no games inserted to set user profile information and such. There are also other systems that may accept being booted without a cartridge. To reach this state, you would load a game and then cancel the load dialog. Right now, this results in games not loading. The second reason is this prevents nasty crashes when loading fails. So if you're missing a required manifest, the emulator won't die a violent death anymore. It's able to back out at any point. The third reason is consistency: loading the base cartridge works the same as the slot cartridges. The fourth reason is Emulator::Interface::open(uint pathID) values. Before, the GB, SB, GBC modes were IDs 1,2,3 respectively. This complicated things because you had to pass the correct ID. But now instead, Emulator::Interface::load() returns maybe<uint> that is nothing when no game is selected, and a pathID for a valid game. And now open() can take this ID to access this game's folder contents. The downside, which is temporary, is that command-line loading is currently broken. But I do intend on restoring it. In fact, I want to do better than before and allow multi-cart booting from the command-line by specifying the base cartridge and then slot cartridges. The idea should be pretty simple: keep a queue of pending filenames that we fill from the command-line and/or drag-and-drop operations on the main window, and then empty out the queue or prompt for load dialogs from the UI when booting a system. This also might be a bit more unorthodox compared to the traditional emulator design of "loadGame(filename)", but ... oh well. It's easy enough still. The port/device changes are fun. We simplified things quite a bit. The portmask stuff is gone entirely. While ports and devices keep IDs, this is really just sugar-coating so UIs can use for(auto& port : emulator->ports) and access port.id; rather than having to use for(auto n : range(emulator->ports)) { auto& port = emulator->ports[n]; ... }; but they should otherwise generally be identical to the order they appear in their respective ranges. Still, don't rely on that. Input::id is gone. There was no point since we also got rid of the nasty Input::order vector. Since I was in here, I went ahead and caved on the pedantics and renamed Input::guid to Input::userData. I removed the SNES controller port 1 multitap option. Basically, the only game that uses this is N-warp Daisakusen and, no offense to d4s, it's not really a good game anyway. It's just a quick demo to show 8-players on the SNES. But in the UI, all it does is confuse people into wasting time mapping a controller they're never going to use, and they're going to wonder which port to use. If more compelling use cases for 8-players comes about, we can reconsider this. I left all the code to support this in place, so all you have to do is uncomment one line to enable it again. We now have dsnes emulation! :D If you change PPU::VRAM::size to 0x10000 (words), then you should now have 128KiB of VRAM. Even better, it serializes the used-VRAM size, so your save states shouldn't crash on you if you swap between the two (though if you try this, you're nuts.) Note that this option does break commercial software. Yoshi's Island in particular. This game is setting A15 on some PPU register writes, but not on others. The end result of this is things break horribly in-game. Also, this option is causing a very tiny speed hit for obvious reasons with the variable masking value (I'm even using size-1 for now.) Given how niche this is, I may just leave it a compile-time constant to avoid the overhead cost. Otherwise, if we keep the option, then it'll go into Super Famicom.sys/manifest.bml ... I'll flesh that out in the near-future. ---- Finally, some fun for my OCD ... my monitor suddenly cut out on me in the middle of working on this WIP, about six hours in of non-stop work. Had to hit a bunch of ctrl+alt+fN commands (among other things) and trying to log in headless on another TTY to do issue commands, trying to recover the display. Finally power cycled the monitor and it came back up. So all my typing ended up going to who knows where. Usually this sort of thing terrifies me enough that I scrap a WIP and start over to ensure I didn't screw anything up during the crashed screen when hitting keys randomly. Obviously, everything compiles and appears to work fine. And I know it's extremely paranoid, but OCD isn't logical, so ... I'm going to go over every line of the 100KiB r07->r08 diff looking for any corruption/errors/whatever. ---- Review finished. r08 diff review notes: - fc/controller/gamepad/gamepad.cpp: use uint device = ID::Device::Gamepad; not id = ...; - gb/cartridge/cartridge.hpp: remove redundant uint _pathID; (in Information::pathID already) - gb/cartridge/cartridge.hpp: pull sha256 inside Information - sfc/cartridge/load/cpp: add " - Slot (A,B)" to interface->load("Sufami Turbo"); to be more descriptive - sfc/controller/gamepad/gamepad.cpp: use uint device = ID::Device::Gamepad; not id = ...; - sfc/interface/interface.cpp: remove n variable from the Multitap device input generation loop (now unused) - sfc/interface/interface.hpp: put struct Port above struct Device like the other classes - ui-tomoko: cheats.bml is reading from/writing to mediumPaths(0) [system folder instead of game folder] - ui-tomoko: instead of mediumPaths(1) - call emulator->metadataPathID() or something like that |
|
Tim Allen | 44a8c5a2b4 |
Update to v099r03 release.
byuu says: Changelog: - finished cleaning up the SFC core to my new coding conventions - removed sfc/controller/usart (superseded by 21fx) - hid Synchronize Video option from the menu (still in the configuration file) Pretty much the only minor detail left is some variable names in the SA-1 core that really won't look good at all if I move to camelCase, so I'll have to rethink how I handle those. It's probably a good area to attempt using BitFields, to see how it impacts performance. But I'll do that in a test branch first. But for the most part, this should be the end of the gigantic diffs (this one was 174KiB), at least for the SFC/WS cores. Still have the FC/GB/GBA cores to clean up more fully. Assuming we don't spot any new regressions, we should be ~95% out of the woods on code cleanups breaking things. |
|
Tim Allen | ae5b4c3bb3 |
Update to v099r01 release.
byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately. |
|
Tim Allen | ae5d380d06 |
Update to v098r11 release.
byuu says: Changelog: - fixed nall/path.hpp compilation issue - fixed ruby/audio/xaudio header declaration compilation issue (again) - cleaned up xaudio2.hpp file to match my coding syntax (12.5% of the file was whitespace overkill) - added null terminator entry to nall/windows/utf8.hpp argc[] array - nall/windows/guid.hpp uses the Windows API for generating the GUID - this should stop all the bug reports where two nall users were generating GUIDs at the exact same second - fixed hiro/cocoa compilation issue with uint# types - fixed major higan/sfc Super Game Boy audio latency issue - fixed higan/sfc CPU core bug with pei, [dp], [dp]+y instructions - major cleanups to higan/processor/r65816 core - merged emulation/native-mode opcodes - use camel-case naming on memory.hpp functions - simplify address masking code for memory.hpp functions - simplify a few opcodes themselves (avoid redundant copies, etc) - rename regs.* to r.* to match modern convention of other CPU cores - removed device.order<> concept from Emulator::Interface - cores will now do the translation to make the job of the UI easier - fixed plurality naming of arrays in Emulator::Interface - example: emulator.ports[p].devices[d].inputs[i] - example: vector<Medium> media - probably more surprises Major show-stoppers to the next official release: - we need to work on GB core improvements: LY=153/0 case, multiple STAT IRQs case, GBC audio output regs, etc. - we need to re-add software cursors for light guns (Super Scope, Justifier) - after the above, we need to fix the turbo button for the Super Scope I really have no idea how I want to implement the light guns. Ideally, we'd want it in higan/video, so we can support the NES Zapper with the same code. But this isn't going to be easy, because only the SNES knows when its output is interlaced, and its resolutions can vary as {256,512}x{224,240,448,480} which requires pixel doubling that was hard-coded to the SNES-specific behavior, but isn't appropriate to be exposed in higan/video. |
|
Tim Allen | 3ebc77c148 |
Update to v098r10 release.
byuu says: Changelog: - synchronized tomoko, loki, icarus with extensive changes to nall (118KiB diff) |
|
Tim Allen | e2ee6689a0 |
Update to v098r06 release.
byuu says: Changelog: - emulation cores now refresh video from host thread instead of cothreads (fix AMD crash) - SFC: fixed another bug with leap year months in SharpRTC emulation - SFC: cleaned up camelCase on function names for armdsp,epsonrtc,hitachidsp,mcc,nss,sharprtc classes - GB: added MBC1M emulation (requires manually setting mapper=MBC1M in manifest.bml for now, sorry) - audio: implemented Emulator::Audio mixer and effects processor - audio: implemented Emulator::Stream interface - it is now possible to have more than two audio streams: eg SNES + SGB + MSU1 + Voicer-Kun (eventually) - audio: added reverb delay + reverb level settings; exposed balance configuration in UI - video: reworked palette generation to re-enable saturation, gamma, luminance adjustments - higan/emulator.cpp is gone since there was nothing left in it I know you guys are going to say the color adjust/balance/reverb stuff is pointless. And indeed it mostly is. But I like the idea of allowing some fun special effects and configurability that isn't system-wide. Note: there seems to be some kind of added audio lag in the SGB emulation now, and I don't really understand why. The code should be effectively identical to what I had before. The only main thing is that I'm sampling things to 48000hz instead of 32040hz before mixing. There's no point where I'm intentionally introducing added latency though. I'm kind of stumped, so if anyone wouldn't mind taking a look at it, it'd be much appreciated :/ I don't have an MSU1 test ROM, but the latency issue may affect MSU1 as well, and that would be very bad. |
|
Tim Allen | 19e1d89f00 |
Update to v098r01 release.
byuu says: Changelog: - SFC: balanced profile removed - SFC: performance profile removed - SFC: code for handling non-threaded CPU, SMP, DSP, PPU removed - SFC: Coprocessor, Controller (and expansion port) shared Thread code merged to SFC::Cothread - Cothread here just means "Thread with CPU affinity" (couldn't think of a better name, sorry) - SFC: CPU now has vector<Thread*> coprocessors, peripherals; - this is the beginning of work to allow expansion port devices to be dynamically changed at run-time - ruby: all audio drivers default to 48000hz instead of 22050hz now if no frequency is assigned - note: the WASAPI driver can default to whatever the native frequency is; doesn't have to be 48000hz - tomoko: removed the ability to change the frequency from the UI (but it will display the frequency used) - tomoko: removed the timing settings panel - the goal is to work toward smooth video via adaptive sync - the model is broken by not being in control of the audio frequency anyway - it's further broken by PAL running at 50hz and WSC running at 75hz - it was always broken anyway by SNES interlace timing varying from progressive timing - higan: audio/ stub created (for now, it's just nall/dsp/ moved here and included as a header) - higan: video/ stub created - higan/GNUmakefile: now includes build rules for essential components (libco, emulator, audio, video) The audio changes are in preparation to merge wareya's awesome WASAPI work without the need for the nall/dsp resampler. |
|
Tim Allen | 7dc62e3a69 |
Update to v097r19 release.
byuu says: Changelog: - fixed nall/windows/guard.hpp - fixed hiro/(windows,gtk)/header.hpp - fixed Famicom PPU OAM reads (mask the correct bits when writing) [hex_usr] - removed the need for (system := system) lines from higan/GNUmakefile - added "All" option to filetype dropdown for ROM loading - allows loading GBC games in SGB mode (and technically non-GB(C) games, which will obviously fail to do anything) - loki can load and play game folders now (command-line only) (extremely unimpressive; don't waste your time :P) - the input is extremely hacked in as a quick placeholder; not sure how I'm going to do mapping yet for it |
|
Tim Allen | 0d0af39b44 |
Update to v097r14 release.
byuu says: This is a few days old, but oh well. This WIP changes nall,hiro,ruby,icarus back to (u)int(8,16,32,64)_t. I'm slowly pushing for (u)int(8,16,32,64) to use my custom Integer<Size>/Natural<Size> classes instead. But it's going to be one hell of a struggle to get that into higan. |
|
Tim Allen | 32a95a9761 |
Update to v097r12 release.
byuu says: Nothing WS-related this time. First, I fixed expansion port device mapping. On first load, it was mapping the expansion port device too late, so it ended up not taking effect. I had to spin out the logic for that into Program::connectDevices(). This was proving to be quite annoying while testing eBoot (SNES-Hook simulation.) Second, I fixed the audio->set(Frequency, Latency) functions to take (uint) parameters from the configuration file, so the weird behavior around changing settings in the audio panel should hopefully be gone now. Third, I rewrote the interface->load,unload functions to call into the (Emulator)::System::load,unload functions. And I have those call out to Cartridge::load,unload. Before, this was inverted, and Cartridge::load() was invoking System::load(), which I felt was kind of backward. The Super Game Boy really didn't like this change, however. And it took me a few hours to power through it. Before, I had the Game Boy core dummying out all the interface->(load,save)Request calls, and having the SNES core make them for it. This is because the folder paths and IDs will be different between the two cores. I've redesigned things so that ICD2's Emulator::Interface overloads loadRequest and saveRequest, and translates the requests into new requests for the SuperFamicom core. This allows the Game Boy code to do its own loading for everything without a bunch of Super Game Boy special casing, and without any awkwardness around powering on with no cartridge inserted. This also lets the SNES side of things simply call into higher-level GameBoy::interface->load,save(id, stream) functions instead of stabbing at the raw underlying state inside of various Game Boy core emulation classes. So things are a lot better abstracted now. |
|
Tim Allen | 344e63d928 |
Update to v097r02 release.
byuu says: Note: balanced/performance profiles still broken, sorry. Changelog: - added nall/GNUmakefile unique() function; used on linking phase of higan - added nall/unique_pointer - target-tomoko and {System}::Video updated to use unique_pointer<ClassName> instead of ClassName* [1] - locate() updated to search multiple paths [2] - GB: pass gekkio's if_ie_registers and boot_hwio-G test ROMs - FC, GB, GBA: merge video/ into the PPU cores - ruby: fixed ~AudioXAudio2() typo [1] I expected this to cause new crashes on exit due to changing the order of destruction of objects (and deleting things that weren't deleted before), but ... so far, so good. I guess we'll see what crops up, especially on OS X (which is already crashing for unknown reasons on exit.) [2] right now, the search paths are: programpath(), {configpath(), "higan/"}, {localpath(), "higan/"}; but we can add as many more as we want, and we can also add platform-specific versions. |
|
Tim Allen | 1fdd0582fc |
Update to v097 release.
byuu says: This release features improvements to all emulation cores, but most substantially for the Game Boy core. All of blargg's test ROMs that pass in gambatte now either pass in higan, or are off by 1-2 clocks (the actual behaviors are fully emulated.) I consider the Game Boy core to now be fairly accurate, but there's still more improvements to be had. Also, what's sure to be a major feature for some: higan now has full support for loading and playing ordinary ROM files, whether they have copier headers, weird extensions, or are inside compressed archives. You can load these games from the command-line, from the main Library menu (via Load ROM Image), or via drag-and-drop on the main higan window. Of course, fans of game folders and the library need not worry: that's still there as well. Also new, you can drop the (uncompressed) Game Boy Advance BIOS onto the higan main window to install it into the correct location with the correct file name. Lastly, this release technically restores Mac OS X support. However, it's still not very stable, so I have decided against releasing binaries at this time. I'd rather not rush this and leave a bad first impression for OS X users. Changelog (since v096): - higan: project source code hierarchy restructured; icarus directly integrated - higan: added software emulation of color-bleed, LCD-refresh, scanlines, interlacing - icarus: you can now load and import ROM files/archives from the main higan menu - NES: fixed manifest parsing for board mirroring and VRC pinouts - SNES: fixed manifest for Star Ocean - SNES: fixed manifest for Rockman X2,X3 - GB: enabling LCD restarts frame - GB: emulated extra OAM STAT IRQ quirk required for GBVideoPlayer (Shonumi) - GB: VBK, BGPI, OBPI are readable - GB: OAM DMA happens inside PPU core instead of CPU core - GB: fixed APU length and sweep operations - GB: emulated wave RAM quirks when accessing while channel is enabled - GB: improved timings of several CPU opcodes (gekkio) - GB: improved timings of OAM DMA refresh (gekkio) - GB: CPU uses open collector logic; return 0xFF for unmapped memory (gekkio) - GBA: fixed sequencer enable flags; fixes audio in Zelda - Minish Cap (Jonas Quinn) - GBA: fixed disassembler masking error (Lioncash) - hiro: Cocoa support added; higan can now be compiled on Mac OS X 10.7+ - nall: improved program path detection on Windows - higan/Windows: moved configuration data from %appdata% to %localappdata% - higan/Linux,BSD: moved configuration data from ~/.config/higan to ~/.local/higan |
|
Tim Allen | 12df278c5b |
Update to v096r08 release.
byuu says: Changelog: - FC: scanline emulation support added - SFC: balanced profile compiles again - SFC: performance profile compiles again - GB,GBC: more fixes to pass blargg's 07, 08, 11 APU tests - tomoko: added input loss { pause, allow-input } options - tomoko: refactored settings video menu options to { Video Scale, Video Emulation, Video Shader } - icarus: connected { About, Preferences, Quit } application menu options |
|
Tim Allen | cec33c1d0f |
Update to v096r07 release.
byuu says: Changelog: - configuration files are now stored in localpath() instead of configpath() - Video gamma/saturation/luminance sliders are gone now, sorry - added Video Filter->Blur Emulation [1] - added Video Filter->Scanline Emulation [2] - improvements to GBA audio emulation (fixes Minish Cap) [Jonas Quinn] [1] For the Famicom, this does nothing. For the Super Famicom, this performs horizontal blending for proper pseudo-hires translucency. For the Game Boy, Game Boy Color, and Game Boy Advance, this performs interframe blending (each frame is the average of the current and previous frame), which is important for things like the GBVideoPlayer. [2] Right now, this only applies to the Super Famicom, but it'll come to the Famicom in the future. For the Super Famicom, this option doesn't just add scanlines, it simulates the phosphor decay that's visible in interlace mode. If you observe an interlaced game like RPM Racing on a real SNES, you'll notice that even on perfectly still screens, the image appears to shake. This option emulates that effect. Note 1: the buffering right now is a little sub-optimal, so there will be a slight speed hit with this new support. Since the core is now generating native ARGB8888 colors, it might as well call out to the interface to lock/unlock/refresh the video, that way it can render directly to the screen. Although ... that might not be such a hot idea, since the GBx interframe blending reads from the target buffer, and that tends to be a catastrophic option for performance. Note 2: the balanced and performance profiles for the SNES are completely busted again. This WIP took 6 1/2 hours, and I'm exhausted. Very much not looking forward to working on those, since those two have all kinds of fucked up speedup tricks for non-interlaced and/or non-hires video modes. Note 3: if you're on Windows and you saved your system folders somewhere else, now'd be a good time to move them to %localappdata%/higan |
|
Tim Allen | 3414c8c8df |
Update to v096r06 release.
byuu says: This WIP finally achieves the vision I've had for icarus. I also fixed a mapping issue with Cx4 that, oddly enough, only caused the "2" from the Mega Man X2 title screen to disappear. [Editor's note - "the vision for icarus" was described in a separate, public forum post: http://board.byuu.org/phpbb3/viewtopic.php?p=20584 Quoting for posterity: icarus is now a full-fledged part of higan, and will be bundled with each higan WIP as well. This will ensure that in the future, the exact version of icarus you need to run higan will be included right along with it. As of this WIP, physical manifest files are now truly and entirely optional. From now on, you can associate your ROM image files with higan's main binary, or drop them directly on top of it, to load and play your games. Furthermore, there are two new menu options that appear under the library menu when icarus is present: - "Load ROM File ..." => gives you a single-file selection dialog to import (and if possible) run the game - "Import ROM Files ..." => gives you a multi-file import dialog with checkboxes to pull in multiple games at once Finally, as before, icarus can generate manifest.bml files for folders that lack them. For people who like the game folder and library system, nothing's changed. Keep using higan as you have been. For people who hate it, you can now use higan like your classic emulators. Treat the "Library->{System Name}" entries as your "favorites" list: the games you actually play. Treat the "Library->Load ROM" as your standard open file dialog in other emulators. And finally, treat "Advanced->Game Library" as your save data path for cheat codes, save states, save RAM, etc. ] |
|
Tim Allen | 4d193d7d94 |
Update to v096r02 (OS X Preview for Developers) release.
byuu says: Warning: this is not for the faint of heart. This is a very early, unpolished, buggy release. But help testing/fixing bugs would be greatly appreciated for anyone willing. Requirements: - Mac OS X 10.7+ - Xcode 7.2+ Installation Commands: cd higan gmake -j 4 gmake install cd ../icarus gmake -j 4 gmake install (gmake install is absolutely required, sorry. You'll be missing key files in key places if you don't run it, and nothing will work.) (gmake uninstall also exists, or you can just delete the .app bundles from your Applications folder, and the Dev folder on your desktop.) If you want to use the GBA emulation, then you need to drop the GBA BIOS into ~/Emulation/System/Game\ Boy\ Advance.sys\bios.rom Usage: You'll now find higan.app and icarus.app in your Applications folders. First, run icarus.app, navigate to where you keep your game ROMs. Now click the settings button at the bottom right, and check "Create Manifests", and click OK. (You'll need to do this every time you run icarus because there's some sort of bug on OSX saving the settings.) Now click "Import", and let it bring in your games into ~/Emulation. Note: "Create Manifests" is required. I don't yet have a pipe implementation on OS X for higan to invoke icarus yet. If you don't check this box, it won't create manifest.bml files, and your games won't run at all. Now you can run higan.app. The first thing you'll want to do is go to higan->Preferences... and assign inputs for your gamepads. At the very least, do it for the default controller for all the systems you want to emulate. Now this is very important ... close the application at this point so that it writes your config file to disk. There's a serious crashing bug, and if you trigger it, you'll lose your input bindings. Now the really annoying part ... go to Library->{System} and pick the game you want to play. Right now, there's a ~50% chance the application will bomb. It seems the hiro::pListView object is getting destroyed, yet somehow the internal Cocoa callbacks are being triggered anyway. I don't know how this is possible, and my attempts to debug with lldb have been a failure :( If you're unlucky, the application will crash. Restart and try again. If it crashes every single time, then you can try launching your game from the command-line instead. Example: open /Applications/higan.app \ --args ~/Emulation/Super\ Famicom/Zelda3.sfc/ Help wanted: I could really, really, really use some help with that crashing on game loading. There's a lot of rough edges, but they're all cosmetic. This one thing is pretty much the only major show-stopping issue at the moment, preventing a wider general audience pre-compiled binary preview. |
|
Tim Allen | 47d4bd4d81 |
Update to v096r01 release.
byuu says: Changelog: - restructured the project and removed a whole bunch of old/dead directives from higan/GNUmakefile - huge amounts of work on hiro/cocoa (compiles but ~70% of the functionality is commented out) - fixed a masking error in my ARM CPU disassembler [Lioncash] - SFC: decided to change board cic=(411,413) back to board region=(ntsc,pal) ... the former was too obtuse If you rename Boolean (it's a problem with an include from ruby, not from hiro) and disable all the ruby drivers, you can compile an OS X binary, but obviously it's not going to do anything. It's a boring WIP, I just wanted to push out the project structure change now at the start of this WIP cycle. |