mirror of https://github.com/bsnes-emu/bsnes.git
93 Commits
Author | SHA1 | Message | Date |
---|---|---|---|
Tim Allen | 393c2395bb |
Update to v106r48 release.
byuu says: The problems with the Windows and Qt4 ports have all been resolved, although there's a fairly gross hack on a few Qt widgets to not destruct once Application::quit() is called to avoid a double free crash (I'm unsure where Qt is destructing the widgets internally.) The Cocoa port compiles again at least, though it's bound to have endless problems. I improved the Label painting in the GTK ports, which fixes the background color on labels inside TabFrame widgets. I've optimized the Makefile system even further. I added a "redo state" command to bsnes, which is created whenever you load the undo state. There are also hotkeys for both now, although I don't think they're really something you want to map hotkeys to. I moved the nall::Locale object inside hiro::Application, so that it can be used to translate the BrowserDialog and MessageDialog window strings. I improved the Super Game Boy emulation of `MLT_REQ`, fixing Pokemon Yellow's custom border and probably more stuff. Lots of other small fixes and improvements. Things are finally stable once again after the harrowing layout redesign catastrophe. Errata: - ICD::joypID should be set to 3 on reset(). joypWrite() may as well take uint1 instead of bool. - hiro/Qt: remove pWindow::setMaximumSize() comment; found a workaround for it - nall/GNUmakefile: don't set object.path if it's already set (allow overrides before including the file) |
|
Tim Allen | 6090c63958 |
Update to v106r47 release.
byuu says: This is probably the largest code-change diff I've done in years. I spent four days working 10-16 hours a day reworking layouts in hiro completely. The result is we now have TableLayout, which will allow for better horizontal+vertical combined alignment. Windows, GTK2, and now GTK3 are fully supported. Windows is getting the initial window geometry wrong by a bit. GTK2 and GTK3 work perfectly. I basically abandoned trying to detect resize signals, and instead keep a list of all hiro windows that are allocated, and every time the main loop runs, it will query all of them to see if they've been resized. I'm disgusted that I have to do this, but after fighting with GTK for years, I'm about sick of it. GTK was doing this crazy thing where it would trigger another size-allocate inside of a previous size-allocate, and so my layouts would be halfway through resizing all the widgets, and then the size-allocate would kick off another one. That would end up leaving the rest of the first layout loop with bad widget sizes. And if I detected a second re-entry and blocked it, then the entire window would end up with the older geometry. I started trying to build a message queue system to allow the second layout resize to occur after the first one completed, but this was just too much madness, so I went with the simpler solution. Qt4 has some geometry problems, and doesn't show tab frame layouts properly yet. Qt5 causes an ICE error and tanks my entire Xorg display server, so ... something is seriously wrong there, and it's not hiro's fault. Creating a dummy Qt5 application without even using hiro, just int main() { TestObject object; } with object performing a dynamic\_cast to a derived type segfaults. Memory is getting corrupted where GCC allocates the vtables for classes, just by linking in Qt. Could be somehow related to the -fPIC requirement that only Qt5 has ... could just be that FreeBSD 10.1 has a buggy implementation of Qt5. I don't know. It's beyond my ability to debug, so this one's going to stay broken. The Cocoa port is busted. I'll fix it up to compile again, but that's about all I'm going to do. Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both resize windows very quickly now. higan crashes when you load a game, so that's not good. bsnes works though. bsnes also has the start of a localization engine now. Still a long way to go. The makefiles received a rather substantial restructuring. Including the ruby and hiro makefiles will add the necessary compilation rules for you, which also means that moc will run for the qt4 and qt5 targets, and windres will run for the Windows targets. |
|
Tim Allen | 0c55796060 |
Update to v106r46 release.
byuu says: Changelog: - bsnes, higan: simplified make output; reordered rules - hiro: added Window::set(Minimum,Maximum)Size() [only implemented in GTK+ so far] - bsnes: only allow the window to be shrunk to the 1x multiplier size - bsnes: refactored Integral Scaling checkbox to {Center, Scale, Stretch} radio selection - nall: call fflush() after nall::print() to stdout or stderr [needed for msys2/bash] - bsnes, higan: program/interface.cpp renamed to program/platform.cpp - bsnes: trim ".shader/" from names in Settings→Shader menu - bsnes: Settings→Shader menu updated on video driver changes - bsnes: remove missing games from recent files list each time it is updated - bsnes: video multiplier menu generated dynamically based on largest monitor size at program startup - bsnes: added shrink window and center window function to video multiplier menu - bsnes: de-minimize presentation window when exiting fullscreen mode or changing video multiplier - bsnes: center the load game dialog against the presentation window (important for multi-monitor setups) - bsnes: screenshots are not immediate instead of delayed one frame - bsnes: added frame advance menu option and hotkey - bsnes: added enable cheats checkbox and hotkey; can be used to quickly enable/disable all active cheats Errata: - hiro/Windows: `SW_MINIMIZED`, `SW_MAXIMIZED `=> `SW_MINIMIZE`, `SW_MAXIMIZE` - hiro/Windows: add pMonitor::workspace() - hiro/Windows: add setMaximized(), setMinimized() in pWindow::construct() - bsnes: call setCentered() after setMaximized(false) |
|
Tim Allen | 372e9ef42b |
Update to v106r45 release.
byuu says: Changelog: - sfc/ppu-fast: added hires mode 7 option (doubles the sampling rate of mode 7 pixels to reduce aliasing) - sfc/ppu-fast: fixed mode 7 horizontal screen flip [hex_usr] - bsnes: added capture screenshot function and path selection - for now, it saves as BMP. I need a deflate implementation that won't add an external dependency for PNG - the output resolution is from the emulator: (256 or 512)x(240 or 480 minus overscan cropping if enabled) - it captures the NEXT output frame, not the current one ... but it may be wise to change this behavior - it'd be a problem if the core were to exit and an image was captured halfway through frame rendering - bsnes: recovery state renamed to undo state - bsnes: added manifest viewer tool - bsnes: mention if game has been verified or not on the status bar message at load time - bsnes, nall: fixed a few missing function return values [SuperMikeMan] - bsnes: guard more strongly against failure to load games to avoid crashes - hiro, ruby: various fixes for macOS [Sintendo] - hiro/Windows: paint on `WM_ERASEBKGND` to prevent status bar flickering at startup - icarus: SPC7110 heuristics fixes [hex_usr] Errata: - sfc/ppu-fast: remove debug hires mode7 force disable comment from PPU::power() [The `WM_ERASEBKGND` fix was already present in the 106r44 public beta -Ed.] |
|
Tim Allen | 40a5fbe605 |
Update to v106r44 public beta release:
byuu says (in the public announcement): I'm releasing a beta version of bsnes, for the purpose of gathering feedback and ensuring that the first official release of bsnes is as solid as possible. With the exception of dynamic rate control for automatic audio/video sync, and no pack-in video shaders or cheat code database, it is mostly feature complete. However, please do not form a lasting opinion of bsnes based on this beta. |
|
Tim Allen | ec960c5172 |
Update to v106r44 release.
byuu says: Changelog: - hiro/Windows: use `WS_CLIPSIBLINGS` on Label to prevent resize drawing issues - bsnes: correct viewport resizing - bsnes: speed up window resizing a little bit - bsnes: fix the cheat editor list enable checkbox - bsnes: fix the state manager filename display in game ROM mode - bsnes: fix the state manager save/rename/remove functionality in game ROM mode - bsnes: correct path searching for IPS and BPS patches in game ROM mode - bsnes: patch BS-X town cartridge to disable play limits - bsnes: do not load (program,data,expansion).(rom,flash) from disk in game pak mode - this is required to support soft-patching and ROM hacks - bsnes: added speed mode selection (50%, 75%, 100%, 150%, 200%); maintains proper pitch - bsnes: added icons to the menubar - this is particularly useful to tell game ROMs from game paks in the load recent game menu - bsnes: added emblem at bottom left of status bar to indicate if a game is verified or not - verified means it is in the icarus verified game dump database - the verified diamond is orange; the unverified diamond is blue - bsnes: added an option (which defaults to off) to warn when loading unverified games - working around a bug in GTK, I have to use the uglier MessageWindow instead of MessageDialog - bsnes: added (non-functional) link to <https://doc.byuu.org/bsnes/> to the help menu - bsnes: added GUI setting to toggle memory auto-save feature - bsnes: added GUI setting to toggle capturing a backup save state when closing the emulator - bsnes: made auto-saving states on exit an option - bsnes: added an option to auto-load the auto-saved state on load - basically, the two combined implements auto-resume - bsnes: when firmware is missing, offer to take the user to the online help documentation - bsnes: added fast PPU option to disable the sprite limit - increase from 32 items/line + 34 tiles/line to 128 items/line + 128 tiles/line - technically, 1024 tiles/line are possible with 128 sprites at 64-width - but this is just a waste of cache locality and worst-case performance; it'll never happen Errata: - hiro/Windows: fallthrough on Canvas `WM_ERASEBKGND` to prevent startup flicker |
|
Tim Allen | 5b97fa2415 |
Update to v106r42 release.
byuu says: Changelog: - emulator: added `Thread::setHandle(cothread_t)` - icarus: added special heuristics support for the Tengai Maykou Zero fan translation - board identifier is: EXSPC7110-RAM-EPSONRTC (match on SPC7110 + ROM size=56mbit) - board ROM contents are: 8mbit program, 40mbit data, 8mbit expansion (sizes are fixed) - bsnes: show messages on game load, unload, and reset - bsnes: added support for BS Memory and Sufami Turbo games - bsnes: added support for region selection (Auto [default], NTSC, PAL) - bsnes: correct presentation window size from 223/239 to 224/240 - bsnes: add SA-1 internal RAM on cartridges with BS Memory slot - bsnes: fixed recovery state to store inside .bsz archive - bsnes: added support for custom manifests in both game pak and game ROM modes - bsnes: added icarus game database support (manifest → database → heuristics) - bsnes: added flexible SuperFX overclocking - bsnes: added IPS and BPS soft-patching support to all ROM types (sfc,smc,gb,gbc,bs,st) - can load patches inside of ZIP archives (matches first “.ips” or “.bps” file) - bsnes/ppu: cache interlace/overscan/vdisp (277 → 291fps with fast PPU) - hiro/Windows: faster painting of Label widget on expose - hiro/Windows: immediately apply LineEdit::setBackgroundColor changes - hiro/Qt: inherit Window backgroundColor when one is not assigned to Label Errata: - sfc/ppu-fast: remove `renderMode7Hires()` function (the body isn't in the codebase) - bsnes: advanced note label should probably use a lighter text color and/or smaller font size instead of italics I didn't test the soft-patching at all, as I don't have any patches on my dev box. If anyone wants to test, that'd be great. The Tengai Makyou Zero fan translation would be a great test case. |
|
Tim Allen | f70a20bc42 |
Update to v106r41 release.
byuu says: Changelog: - hiro: added Label::set(Background,Foreground)Color (not implemented on Cocoa backend) - hiro: added (Horizontal,Vertical)Layout::setPadding() - setMargin(m) is now an alias to setPadding({m, m, m, m}) - hiro/Windows: update Label rendering to draw to an offscreen canvas to prevent flickering - sfc: reverted back to 224/240-line height (from 223/239-line height in earlier v106 WIPs) - bsnes: new multi-segment status bar added - bsnes: exiting fullscreen mode will resize and recenter window - this is required; the window geometry gets all scrambled when toggling fullscreen mode - bsnes: updated to a new logo [Ange Albertini] Errata: - hiro/Windows: try to paint Label backgroundColor quicker to avoid startup flicker - `WM_ERASEBKGND` fallthrough to `WM_PAINT` seems to work - hiro/Qt: use Window backgroundColor for Label when no Label backgroundColor set - bsnes: update size multipliers in presentation.cpp to 224/240 (main window size is off in this WIP) |
|
Tim Allen | 5a8c814e25 |
Update to v106r40 release.
byuu says: Changelog: - hiro: added BrowserDialog::openObject() [match file *or* folder by filters] - hiro: BrowserDialog accept button is now disabled when it would otherwise do nothing - eg openFile without a folder to enter or file to open selected - eg saveFile without a file name or with a file name that matches a folder name - bsnes: added support for gamepaks (game folders) - bsnes: store all save states inside per-game .bsz (ZIP) archives instead of .bst/ folders - this reduces the number of state files from 10+ to 1; without having folders sort before files - hiro: both gtk2 and gtk3 now use cairo to render Canvas; supports sx,sy [BearOso] - higan, bsnes: fast PPU/DSP are now run-time options instead of compile-time options - bsnes: disable fast PPU when loading Air Strike Patrol / Desert Fighter - bsnes: disable fast DSP when loading Koushien 2 - bsnes: added options to advanced panel to disable fast PPU and/or fast DSP |
|
Tim Allen | 91bb781b73 |
Update to v106r39 release.
byuu says: Changelog: - ruby/video: implement onUpdate() callback to signal when redraws are necessary - ruby/video/GLX,GLX2,XVideo,XShm: implement onUpdate() support - bsnes: implement Video::onUpdate() support to redraw Viewport icon as needed - bsnes: save RAM before ruby driver changes - sfc/sa1: clip signed multiplication to 32-bit [Jonas Quinn] - sfc/sa1: handle negative dividends in division [Jonas Quinn] - hiro/gtk3: a few improvements - bsnes: added empty stub video and audio settings panels - bsnes: restructured advanced settings panel - bsnes: experiment: input/hotkeys name column bolded and colored for increased visual distinction - bsnes: added save button to state manager |
|
Tim Allen | 15b67922b3 |
Update to v106r38 release.
byuu says: Changelog: - hiro: added Qt5 support - hiro: added GTK3 support (currently runs very poorly) - bsnes: number of recent games and quick state slots can be changed programmatically now - I may expose this as a configuration file setting, but probably not within the GUI - nall: use -Wno-everything when compiling with Clang - sorry, Clang's meaningless warning messages are just endless ... |
|
Tim Allen | 173a5d67bc |
Update to v106r37 release.
byuu says: Changelog: - bsnes: cheat code “enabled” option changed to “enable” - bsnes: connected “Cancel” action on add/edit cheat code window - hiro: improved BrowserDialog::selectFolder() behavior - can choose “Select” inside of a target folder when no items are selected - bsnes: implemented state manager - bsnes: save a recovery state before loading a state, quitting, or changing drivers - bsnes: input settings, hotkey settings, cheat editor, state manager entries are now batchable - this allows bulk clearing/deleting of entries - bsnes: cheat code list now auto-sorts alphabetically instead of using up/down move arrows I know most people will probably prefer to order cheat codes the way they want, but the issue is that the state manager can't really work this way. Each state is a file on disk. So yes, we could store a states-manifest.bml to track the order of the states, or try to insert numbers into the filenames and do bulk filesystem rename operations on sorting, but then we would run into oddities when users delete state files manually. And really, manual sorting is just clumsy. If you really want a specific ordering, you can prefix cheats/states with numeric indices instead. |
|
Tim Allen | ec9729a9e1 |
Update to v106r36 release.
byuu says: Changelog: - nall: renamed array to adaptive_array; marked it as deprecated - nall: created new array class; which is properly static (ala std::array) with optional bounds-checking - sfc/ppu-fast: converted unmanaged arrays to use nall/array (no speed penalty) - bsnes: rewrote the cheat code editor to a new design - nall: string class can stringify pointer types directly now, so pointer() was removed - nall: added array_view and pointer types (still unsure if/how I'll use pointer) |
|
Tim Allen | 5d29700fa1 |
Update to v106r33 release.
byuu says: Changelog: - nall/GNUmakefile: added `openmp=(true,false)` option; can be toggled when building higan/bsnes - defaults to disabled on macOS, because Xcode doesn't stupidly doesn't ship with support for it - higan/GNUmakefile: forgot to switch target,profile back from bsnes,fast to higan,accurate - this is just gonna happen from time to time, sorry - sfc/dsp: when using the fast profile, the DSP syncs per sample instead of per clock - should only negatively impact Koushien 2, but is a fairly significant speedup otherwise - sfc/ppc,ppu-fast: optimized the code a bit (ppu 130fps to 133fps) - sfc/ppu-fast: basic vertical mosaic support (not accurate, but should look okay hopefully) - sfc/ppu-fast: added missing mode7 hflip support - sfc/ppu-fast: added support to render at 256-width and/or 240-height - gives a decent speed boost, and also allows all of the older quark shaders to work nicely again - it does violate the contract of Emulator::Interface, but oh well, it works fine in the bsnes GUI - sfc/ppu-fast: use cached CGRAM values for mode7 and sprites - sfc/ppu-fast: use global range/time over flags in object rendering - may not actually work as we intended since it's a race condition even if it's only ORing the flags - really don't want to have to make those variables atomic if I don't have to - sfc/ppu-fast: should fully support interlace and overscan modes now - hiro/cocoa: updated macOS Gatekeeper disable support to work on 10.13+ - ruby: forgot to fix macOS input driver, sorry - nall/GNUmakefile: if uname is present, then just default to rm instead of del (fixes Msys) Note: blur emulation option will break pretty badly in 256x240 output mode. I'll fix it later. |
|
Tim Allen | 685cec6583 |
Update to v106r30 release.
byuu says: Changelog: - nall/GNUmakefile: fixed findstring parameter arguments [Screwtape] - nall/Windows: always include -mthreads -lpthread for all applications - nall/memory: code restructuring I really wanted to work on the new PPU today, but I thought I'd spend a few minutes making some minor improvements to nall::memory, that was five and a half hours ago. Now I have a 67KiB diff of changes. Sigh. |
|
Tim Allen | 2b8df2e70e |
Update to v106r27 release.
byuu says: Changelog: - nall: merged Path::config() and Path::local() to Path::userData() - ~/.local/share or %appdata or ~/Library/ApplicationSupport - higan, bsnes: render main window icon onto viewport instead of canvas - should hopefully fix a brief flickering glitch that appears on Windows - icarus: improved Super Famicom heuristics for Starfox / Starwing RAM - ruby/Direct3D: handle viewport size changes in lock() instead of output() - fixes icon disappearing when resizing main window - hiro/Windows: remove WS_DISABLED from StatusBar to fix window resize grip - this is experimental: I initially used WS_DISABLED to work around a focus bug - yet trying things now, said bug seems(?) to have gone away at some point ... - bsnes: added advanced settings panel with real-time driver change support I'd like feedback on the real-time driver change, for possible consideration into adding this to higan as well. Some drivers just crash, it's a fact of life. The ASIO driver in particular likes to crash inside the driver itself, without any error messages ever returned to try and catch. When you try to change a driver with a game loaded, it gives you a scary warning, asking if you want to proceed. When you change a driver, it sets a crash flag, and if the driver crashes while initializing, then restarting bsnes will disable the errant driver. If it fails in a recoverable way, then it sets the driver to “None” and warns you that the driver cannot be used. What I'm thinking of further adding is to call emulator→save() to write out the save RAM contents beforehand (although the periodic auto-saving RAM will handle this anyway when it's enabled), and possibly it might be wise to capture an emulator save state, although those can't be taken without advancing the emulator to the next frame, so that might not be a good idea. I'm also thinking we should show some kind of message somewhere when a driver is set to “None”. The status bar can be hidden, so perhaps on the title bar? Or maybe just a warning on startup that a driver is set to “None”. |
|
Tim Allen | 5961ea9c03 |
Update to v106r26 release.
byuu says: Changelog: - nall: added -static-libgcc -static-libstdc++ to Windows/GCC link flags - bsnes, higan: added program icons to main window when game isn't loaded - bsnes: improved recent games menu sorting - bsnes: fixed multi-game recent game loading on Windows - bsnes: completed path override support - bsnes, higan: added screensaver suppression on Windows - icarus: add 32K volatile RAM to SuperFX boards that report no RAM (fixes Starfox) - bsnes, higan: added automatic dependency generation [Talarubi] - hiro/GTK: appending actions to menus restores enabled() state - higan: use board node inside manifest.bml if it exists - bsnes: added blur emulation and color emulation options to view menu - ruby: upgraded input.sdl to SDL 2.0 (though it makes no functional difference sadly) - ruby: removed video.sdl (due to deprecating SDL 1.2) - nall, ruby: improvements to HID class (generic vendor and product IDs) Errata: - bsnes, higan: on Windows, Application::Windows::onScreenSaver needs `[&]` lambda capture, not `[]` - find it in presentation/presentation.cpp |
|
Tim Allen | 8bbbc5e737 |
Update to v106r21 release.
byuu says: Changelog: - higan: target-tomoko has been renamed to target-higan - Super Famicom: event has been renamed to processor(architecture=uPD78214) - Super Famicom: SNES-EVENT supported once more; under board IDs EVENT-CC92 and EVENT-PF94 - Super Famicom: SNES-EVENT preliminarily set up to use DIP switch settings ala the Nintendo Super System (incomplete) - Super Famicom: MCC PSRAM moved inside the MCU, as it is remappable - Super Famicom: MCC emulation rewritten from scratch; it is now vastly more accurate than before - Super Famicom: added BSC-1A5B9P-01 board definition to database; corrected BS-MCC-RAM board definition - Super Famicom: moved SHVC-LN3B-01 RAM outside of processor(identifier=SDD1) - higan: when selecting a default game to load for a new system entry, it will change the system option to match the media type - higan: the load text box on the system entry window is now editable; can be used to erase entries - icarus: fixed bug in Famicom importing - icarus: importing unappended SNES coprocessor firmware will now rename the firmware properly - hiro/GTK,Qt: WM_CLASS is now set correctly in `argv[0]`, so applications should show “higan”, “icarus” instead of “hiro” now Note: if you wish to run the BS-X town cartridge, the database currently lists the download RAM as type “PSRAM”. This needs to be changed to “RAM” in order to load properly. Otherwise, the emulator will bomb out on the load window, because BSC-1A5B9P-01 expects PSRAM to always be present, but it won't find it with the wrong memory type. I'll correct this in the database in a later release. For now, you can copy the game portion of the manifest to a new manifest.bml file and drop it into the gamepak folder until I fix the database. |
|
Tim Allen | 8023d9cbe8 |
Update to v106r15 release.
byuu says: Changelog: - main menu renamed again (Library→System→Systems) - the 'Hidden' checkbox on system properties was moved to the main list as a 'Show' checkbox instead - the move up/move down buttons on the systems panel now function - added icons to indicate 'system' versus 'game boot' entries in the systems list I still didn't add ComboEdit to the Windows hiro port, so once again this will be Linux/BSD only. I polished the browse button for selecting a boot game. It'll use a list of all bootable media file extensions, so that if you double-click any supported game, it'll select it instead of going inside the folder. If you pick a non-bootable folder, like say a Sufami Turbo cartridge, it will go inside the folder instead, because it will treat it like any other regular folder. Having a checkbox next to text in the same cell doesn't work so well on lists that have an onActivate action. Say you tried to double-click the “Name” field on the Systems tab, it would toggle the checkbox twice before popping open the system properties editor window. So because of this, I made the show checkbox its own column. And for consistency, I did the same for the slot# on the cheat editor window. As a bit of really pedantic polish: if there are no systems enabled, then the main menu won't show the separator before the “Load ROM Image” option anymore. I think something is wrong with the Markup::Node::insert syntax, but I realized I have Markup::Node::swap, and just used that for the up/down arrows on the systems panel for now. But we should probably fix insert() at some point ... sigh. |
|
Tim Allen | 0ea17abfea |
Update to v106r15 release.
byuu says: Changelog: - Super Game Boy: fixed loading of boot ROM - hiro: added ComboEdit::setEditable(bool = true); - tomoko: added new systems settings panel Note!!: this release will not compile on Windows or macOS due to the missing ComboEdit control! I'll try to merge in hex's implementation for the Windows release here soon. macOS users will probably be out of luck for a while, sorry. The new systems panel is an idea I've been meaning to implement for quite a while, but finally got around to starting on it. It's still fairly unpolished, but the basic idea is there for Linux/BSD users to try out now. So imagine the Super Game Boy, BS-X Satellaview, Sufami Turbo, and the associated BS Memory Pack-slotted SNES cartridges. To play any of those, you needed to choose Nintendo→Super Famicom, and then select the relevant cartridge, and then select any slotted cartridges to play with it. This was acceptable-ish, if not ideal. But now imagine in the future if we wanted to support the Famicom Disk System, which is technically a cartridge that plugs into the Famicom deck. Or the PC Engine CD, which has one of three special HuCards that must be inserted (ignoring the Turbo Duo where it's built-in—I'm going to be emulating the Super CD as if you're using a stock PCE CD.) Or the Mega CD, where there are probably a half dozen or more BIOS + hardware revisions that are region-specific, which connect to an expansion port that is identical to the cartridge port save for the Mega Drive seeing an I/O register bit toggled here. In all of these cases, it's going to be a real pain to have to choose the 'BIOS' every time you want to play a game for them. I can't distribute these BIOSes with higan due to copyright restrictions, and trying to ship dummy folders for every possible combination would become quite odious, and difficult for people to use (compare to setting up the Game Boy Advance system BIOS.) And so I've created the new systems settings panel. Here, you can manage a list of systems that show up under the higan library menu (now renamed to “System”), where each entry contains name, boot, and hidden parameters. The name parameter is what shows up in the system menu. You can call any system higan emulates whatever you like here. Don't like “Super Famicom”? Change it to “SNES”, then. The boot parameter is a combo edit with a dropdown for all of the systems higan emulates. If you choose one of these, then the higan system menu option will work exactly like in previous releases, and prompt you for a cartridge. But if you choose the browse button next to the combo edit control, you'll get to pick any gamepak from the higan library of your choosing. So you could choose the SGB2 BIOS, and name the menu option “Super Game Boy 2”, and when you choose the menu option, it will load the SFC core, load the SGB2 BIOS, and only prompt you for the Game Boy game you wish to play on it. The same deal goes for the FDS, PCE-CD, Mega CD, Mega Drive Sonic & Knuckles lock-on cartridge, BS-X Satellaview, SD Gundam G-Next, etc. Whatever you want to be in the menu, you can put in there by pointing higan at the appropriate 'BIOS' gamepak to load. Astute readers have probably already noticed, but you can technically use this on non-slotted games as well, thus creating instant boot options for your absolute favorite games, if you so wanted. Point it at Zelda 3, and you can boot it instantly from the main menu, without any need for file selection. The hidden option is a way to hide the system entries from the system menu. Primarily this would be a fast way for users to disable emulation cores they never use in higan, without having to remove the options. The major concession with this change is the collapsing of the per-manufacturer submenus. What this means is you will now have all twelve higan emulated systems in the main menu by default. This makes the list rather long, but ... oh well. I may try to offer some form of grouping in the future, but the grouping defeats the “list order = display order” design, and I'm not willing to auto-sort the list. I want people to be able to control the ordering of the system menu, and have added (as yet non-functional) sorting arrows for that purpose. I also don't have a combined tree+table view widget in higan to try to and group things. But ... we'll see how things go in the future. Another idea is to add a specialty load option that opens up the user's Emulation library path, and lets you pick a gamepak for any system, which would boot the same way as when you drop a gamepak onto the higan executable or main window. So say you almost never play Wonderswan games, this would be a way to play them without them cluttering your system menu list. The “import ROM files” option has been removed. All it does is launch icarus directly. I would rather users become familiar with using icarus. The “load ROM file” option remains. Anyway, this is all still a work in progress, so please give it time and don't overload me with too many suggested changes right now, thanks :3 |
|
Tim Allen | 2dd35f984d |
Update to v106r10 release.
byuu says: Changelog: - manifest: memory/battery now resides under type at memory/type/battery - genius: volatile option changed to battery; auto-disables when not RAM or RTC type - higan: added new Emulator::Game class to parse manifests for all emulated systems consistently - Super Famicom: board manifest appended to manifest viewer now - Super Famicom: cartridge class updated to use Emulator::Game objects - hiro: improve suppression of userland callbacks once Application::quit() is called - this fixes a crash in genius when closing the window with a tree view item selected My intention is to remove Emulator::Interface::sha256(), as it's not really useful. They'll be removed from save states as well. I never bothered validating the SHA256 within them, because that'd be really annoying for ROM hackers. I also intend to rename Emulator::Interface::title() to label() instead. Most everything is still broken. The SNES still needs all the board definitions updated, all the other cores need to move to using Emulator::Game. |
|
Tim Allen | e216912ca3 |
Update to v106r09 release.
byuu says: Changelog: - higan, icarus, genius: new manifest syntax (work in progress) Pretty much only LoROM and HiROM SNES games will load right now, and RAM will only work right if the save.ram file already exists to pull its file size from (a temporary cheap hack was used.) Basically, I'm just getting this out there for evaluation. One minor errata is that I switched icarus to using “memory/battery” to indicate battery-backed RAM, whereas genius still uses “memory/volatile” to indicate non-battery-backed RAM. I intend to make it “memory/battery” in genius, and have the field auto-enable when RAM or RTC is selected for type (obviously allowing it to be unchecked for volatile memory.) I need to update all 64 production boards, and 25 of 29 generic boards, to use the new slot syntax; and I also need to update every single core in higan to use the new manifest game syntax. I want to build out a generic manifest game parser that all emulation cores will use. Once I finish this, I'll also need to write a database converter to update all of my licensed game dumps to the new database syntax. I also need to write up something for doc.byuu.org explaining the new manifest game syntax. The manifest board syntax will still be “internal” and subject to revisions, but once v107 is out, the gamepak manifest format will be set in stone sans extensions. |
|
Tim Allen | 2f81b5a3e7 |
Update to v106r2 release.
byuu says: Changelog: - Super Famicom: added support for loading manifests without embedded mapping information¹ - genius: initial commit - various Makefile cleanups ¹: so the idea here is to try and aim for a stable manifest format, and to allow direct transposition of icarus/genius database entries into manifest files. The exact mechanics of how this is going to work is currently in flux, but we'll get there. For right now, `Super Famicom.sys` gains `boards.bml`, which is the raw database from my board-editor tool, and higan itself tries to load `boards.bml`, match an entry to game/board from the game's `manifest.bml` file, and then transform it into the format currently used by higan. It does this only when the game's `manifest.bml` file lacks a board node. When such a board node exists, it works as previous versions of higan did. The only incompatible change right now is information/title is now located at game/label. I may transition window title display to just use the filenames instead. Longer term, some thought is going to need to go into the format of the `boards.bml` database itself, and at which point in the process I should be transforming things. Give it time, we'll refine this into something nicer. |
|
Tim Allen | f8e71b50d0 |
Update to v105 release.
byuu says: This release provides several major improvements to Mega Drive emulation which enhances compatibility a good deal. It also includes important Super Famicom mosaic emulation improvements, plus a much-needed SuperFX save state issue fix. Changelog (since v104): - higan: many improvements to Emulator::Interface to support forks/frontends - higan: refreshed program icon - icarus: new program icon - Game Boy Advance: slight emulation speedup over v104 - Game Boy Advance: synchronize APU FIFO updates better - Mega Drive: added automatic region detection [hex_usr] - Mega Drive: support 8-bit SRAM - Game Boy Advance: fixed bug when changing to THUMB mode via MSR [MerryMage] - Master System: fix bug in backdrop color and background 0 priority [hex_usr] - Mega Drive: backgrounds always update output priority bit [Cydrak] - Mega Drive: emulated interlaced video output - Mega Drive: emulated shadow/highlight mode [Cydrak] - Super Famicom: auto joypad polling clears the shift register when starting - Super Famicom: added new low-entropy RAM initialization mode to more closely match hardware - Game Boy Advance: rumble will now time out after being left on for 500ms - ruby: improved rumble support in udev input driver [ma_rysia] - M68K: `move.b (a7)[+/-]` adjust a7 by two - M68K: illegal/lineA/lineF opcodes do not modify the stack register - Mega Drive: emulate VIP status bit - uPD7725: improved emulation of OV1/S1 flags [byuu, AWJ, Lord Nightmare] - uPD7725: improved handling of DP, RP updates [Jonas Quinn] - Super Famicom: improved emulation of mosaic effects in hires, interlace, and offset-per-tile modes [byuu, Cydrak] - ruby: improved Direct3D exclusive mode monitor selection [Cydrak] - Super Famicom: fixed save state bug affecting SuperFX games [Cydrak] - Mega Drive: added workaround for Clang compiler bug; allowing this core to work on macOS [Cydrak, Sintendo] - higan: hotkeys now also trigger when the main window lacks focus yet higan is set to allow input on focus loss - higan: fixed an edge case where `int16_t` ↔ `double` audio conversion could possibly result in overflows - higan: fixed a crash on macOS when choosing quit from the application menu [ncbncb] Changelog (since the previous WIP): - higan: restored `make console=true` - tomoko: if you allow input when main window focus is lost, hotkeys can now be triggered without focus as well - hiro/cocoa: fix crash on exit from menu [ncbncb] - ruby: smarter `double` → `int16_t` conversion to prevent underflow/overflow |
|
Tim Allen | 6524a7181d |
Update to v104r15 release.
byuu says: Changelog: - processor/huc6280,mos6502,wdc65816: replaced abbreviated opcode names with descriptive names - nall: replaced `PLATFORM_MACOSX` define with `PLATFORM_MACOS` - icarus: added `Icarus::missing() -> string_vector` to list missing appended firmware files by name - ruby, hiro: fix macosx→macos references The processor instruction renaming was really about consistency with the other processor cores. I may still need to do this for one or two more processors. The icarus change should allow a future release of the icarus application to import games with external SNES coprocessor firmware once again. It will also allow this to be possible when used in library mode. |
|
Tim Allen | fbc58c70ae |
Update to v104r14 release.
byuu says: Changelog: - Emulator::Interface::videoResolution() -\> VideoResolution renamed to videoInformation() -\> VideoInformation - added double VideoInformation::refreshRate - higan: added `binary := (application|library)` — set this to `library` to produce a dynamic link library - higan: removed `-march=native` for macOS application builds; and for all library builds - higan: removed `console` build flag; uncomment `link += -mwindows` instead - nall/GNUmakefile: `macosx` platform renamed `macos` - still need to do this for nall/intrinsics.hpp - Game Gear: return region=NTSC as the only option, so that the system frequency is always set correctly - hiro/cocoa: fixed typo [Sintendo] - hiro/Windows: removed GetDpiForMonitor, as it's Windows 8+ only; DPI is no longer per-monitor aware - icarus: core Icarus class now has virtual functions for directory::create, <file::exists>, <file::copy>, <file::write> - icarus: Sufami Turbo can import save RAM files now - icarus: setting `ICARUS_LIBRARY` define will compile icarus without main(), GUI components - ruby/video/Direct3D: choose the current monitor instead of top-left monitor for fullscreen exclusive [Cydrak] - ruby/video/Direct3D: do not set `WS_EX_TOPMOST` on fullscreen exclusive window [Cydrak] - this isn't necessary for exclusive mode, and it just makes getting out of the application more difficult |
|
Tim Allen | 1ff315838e |
Update to v104r13 release.
byuu says: Changelog: - nall/GNUmakefile: build=release changed to -O2, build=optimize is now -O3 - hiro: added Monitor::dpi(uint index) → Position [returns logical DPI for x, y] - Position is a bad name, but dpi(monitor).(x,y)() make more sense than .(width,height)() - hiro: Position, Size, Geometry, Font changed from using signed int to float - hiro: Alignment changed from using double to float - hiro: added skeleton (unused) Application::scale(), setScale() functions Errata: - hiro/cocoa's Monitor::dpi() is untested. Probably will cause issues with macOS' automatic scaling. - hiro/gtk lacks a way to get both per-monitor and per-axis (x,y) DPI scaling - hiro/qt lacks a way to get per-monitor DPI scaling (Qt 5.x has this, but I still use Qt 4.x) - and just to get global DPI, hiro/qt's DPI retrieval has to use undocumented functions ... fun The goal with this WIP was basically to prepare hiro for potential automatic scaling. It'll be extremely difficult, but I'm convinced that it must be possible if macOS can do it. By moving from signed integers to floats for coordinates, we can now scale and unscale without losing precision. That of course isn't the hard part, though. The hard part is where and how to do the scaling. In the ideal application, hiro/core and hiro/extension will handle 100% of this, and the per-platform hiro/(cocoa,gtk,qt,windows) will not be aware of what's going on, but ... to even make that possible, things will need to change in every per-platform core, eg the per-platform code will have to call a core function to change geometry, which will know about the scaling and unscale the values back down again. Gonna be a lot of work, but ... it's a start. |
|
Tim Allen | 0b6f1df987 |
Update to v103r27 release.
byuu says: Changelog: - hiro/windows: set dpiAware=false, fixes icarus window sizes relative to higan window sizes - higan, icarus, hiro, ruby: add support for high resolution displays on macOS [ncbncb] - processor/lr35902-legacy: removed - processor/arm7tdmi: new processor core started; intended to one day be a replacement for processor/arm It will probably take several WIPs to get the new ARM core up and running. It's the last processor rewrite. After this, all processor cores will be up to date with all my current programming conventions. |
|
Tim Allen | 571760c747 |
Update to v103r24 release.
byuu says: Changelog: - gb/mbc6: mapper is now functional, but Net de Get has some text corruption¹ - gb/mbc7: mapper is now functional² - gb/cpu: HDMA syncs other components after each byte transfer now - gb/ppu: LY,LX forced to zero when LCDC.d7 is lowered (eg disabled), not when it's raised (eg enabled) - gb/ppu: the LCD does not run at all when LCDC.d7 is clear³ - fixes graphical corruption between scene transitions in Legend of Zelda - Oracle of Ages - thanks to Cydrak, Shonumi, gekkio for their input on the cause of this issue - md/controller: renamed "Gamepad" to "Control Pad" per official terminology - md/controller: added "Fighting Pad" (6-button controller) emulation [hex\_usr] - processor/m68k: fixed TAS to set data.d7 when EA.mode==DataRegisterDirect; fixes Asterix - hiro/windows: removed carriage returns from mouse.cpp and desktop.cpp - ruby/audio/alsa: added device driver selection [SuperMikeMan] - ruby/audio/ao: set format.matrix=nullptr to prevent a crash on some systems [SuperMikeMan] - ruby/video/cgl: rename term() to terminate() to fix a crash on macOS [Sintendo] ¹: The observation that this mapper split $4000-7fff into two banks came from MAME's implementation. But their implementation was quite broken and incomplete, so I didn't actually use any of it. The observation that this mapper split $a000-bfff into two banks came from Tauwasser, and I did directly use that information, plus the knowledge that $0400/$0800 are the RAM bank select registers. The text corruption is due to a race condition with timing. The game is transferring font letters via HDMA, but the game code ends up setting the bank# with the font a bit too late after the HDMA has already occurred. I'm not sure how to fix this ... as a whole, I assumed my Game Boy timing was pretty good, but apparently it's not that good. ²: The entire design of this mapper comes from endrift's notes. endrift gets full credit for higan being able to emulate this mapper. Note that the accelerometer implementation is still not tested, and probably won't work right until I tweak the sensitivity a lot. ³: So the fun part of this is ... it breaks the strict 60fps rate of the Game Boy. This was always inevitable: certain timing conditions can stretch frames, too. But this is pretty much an absolute deal breaker for something like Vsync timing. This pretty much requires adaptive sync to run well without audio stuttering during the transition. There's currently one very important detail missing: when the LCD is turned off, presumably the image on the screen fades to white. I do not know how long this process takes, or how to really go about emulating it. Right now as an incomplete patch, I'm simply leaving the last displayed image on the screen until the LCD is turned on again. But I will have to output white, as well as add code to break out of the emulation loop periodically when the LCD is left off eg indefinitely, or bad things would happen. I'll work something out and then implement. Another detail is I'm not sure how long it takes for the LCD to start rendering again once enabled. Right now, it's immediate. I've heard it's as long as 1/60th of a second, but that really seems incredibly excessive? I'd like to know at least a reasonably well-supported estimate before I implement that. |
|
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 | 17697317d4 |
Update to v103r14 release.
byuu says: Changelog: - tomoko: by popular choice, default to adaptive mode on new installs - hiro/windows: fix bug that was preventing the escape key from closing some dialog windows - nall/registry: use "\\\\" as separator instead of "/" ... because some registry keys contain "/" in them >_> - ruby: add ASIO driver stub (so far it can only initialize and grab the driver name/version information) |
|
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 | 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 | b7006822bf |
Update to v103 WIP release.
byuu says (in the WIP forum): Changelog: - higan: cheat codes accept = and ? separators now - the new preferred code format is: address=value or address=if-match?value - the old code format of address/value and address/if-match/value will continue to work - higan: cheats.bml is no longer included with the base distribution - mightymo stopped updating it in 2015, and it's not source code; it can still be pulled in from older releases - fc: improved PAL mode timing; use PAL APU timing tables; fix PAL noise period table [hex\_usr] - md: support aborting a Z80 bus wait in order to capture save states without freezing - note that this will violate accuracy; but in practice a slight desync is better than an emulator deadlock - sfc: revert DSP ENDX randomization for now (want to research it more before deploying in an official release) - sfc: fix Super Famicom.sys/manifest.bml APU RAM size [hex\_usr] - tomoko: cleaned up make install rules - hiro/cocoa: use ABGR for pixel data [Sintendo] Note: I forgot to change the command-line and drag-and-drop separator from : to | in this WIP. However, it is corrected in the v103 official binary and source published on download.byuu.org. Sorry about that, I know it makes the Git repository history more difficult. I'm not concerned whether the : → | change is part of v103 or v103r01 in the repository, and will leave this to your discretion, Screwtape. I also still need to set the VDP bit to indicate PAL mode in the Mega Drive core. This is what happens when I have 47 things I have to do, given how lousy my memory is. I miss things. |
|
Tim Allen | fa6cbac251 |
Update to v102r06 release.
byuu says: Changelog: - added higan/emulator/platform.hpp (moved out Emulator::Platform from emulator/interface.hpp) - moved gmake build paramter to nall/GNUmakefile; both higan and icarus use it now - added build=profile mode - MD: added the region select I/O register - MD: started to add region selection support internally (still no external select or PAL support) - PCE: added cycle stealing when reading/writing to the VDC or VCE; and when using ST# instructions - PCE: cleaned up PSG to match the behavior of Mednafen (doesn't improve sound at all ;_;) - note: need to remove loadWaveSample, loadWavePeriod - HuC6280: ADC/SBC decimal mode consumes an extra cycle; does not set V flag - HuC6280: block transfer instructions were taking one cycle too many - icarus: added code to strip out PC Engine ROM headers - hiro: added options support to BrowserDialog The last one sure ended in failure. The plan was to put a region dropdown directly onto hiro::BrowserDialog, and I had all the code for it working. But I forgot one important detail: the system loads cartridges AFTER powering on, so even though I could technically change the system region post-boot, I'd rather not do so. So that means we have to know what region we want before we even select a game. Shit. |
|
Tim Allen | bdc100e123 |
Update to v102r02 release.
byuu says: Changelog: - I caved on the `samples[] = {0.0}` thing, but I'm very unhappy about it - if it's really invalid C++, then GCC needs to stop accepting it in strict `-std=c++14` mode - Emulator::Interface::Information::resettable is gone - Emulator::Interface::reset() is gone - FC, SFC, MD cores updated to remove soft reset behavior - split GameBoy::Interface into GameBoyInterface, GameBoyColorInterface - split WonderSwan::Interface into WonderSwanInterface, WonderSwanColorInterface - PCE: fixed off-by-one scanline error [hex_usr] - PCE: temporary hack to prevent crashing when VDS is set to < 2 - hiro: Cocoa: removed (u)int(#) constants; converted (u)int(#) types to (u)int_(#)t types - icarus: replaced usage of unique with strip instead (so we don't mess up frameworks on macOS) - libco: added macOS-specific section marker [Ryphecha] So ... the major news this time is the removal of the soft reset behavior. This is a major!! change that results in a 100KiB diff file, and it's very prone to accidental mistakes!! If anyone is up for testing, or even better -- looking over the code changes between v102r01 and v102r02 and looking for any issues, please do so. Ideally we'll want to test every NES mapper type and every SNES coprocessor type by loading said games and power cycling to make sure the games are all cleanly resetting. It's too big of a change for me to cover there not being any issues on my own, but this is truly critical code, so yeah ... please help if you can. We technically lose a bit of hardware documentation here. The soft reset events do all kinds of interesting things in all kinds of different chips -- or at least they do on the SNES. This is obviously not ideal. But in the process of removing these portions of code, I found a few mistakes I had made previously. It simplifies resetting the system state a lot when not trying to have all the power() functions call the reset() functions to share partial functionality. In the future, the goal will be to come up with a way to add back in the soft reset behavior via keyboard binding as with the Master System core. What's going to have to happen is that the key binding will have to send a "reset pulse" to every emulated chip, and those chips are going to have to act independently to power() instead of reusing functionality. We'll get there eventually, but there's many things of vastly greater importance to work on right now, so it'll be a while. The information isn't lost ... we'll just have to pull it out of v102 when we are ready. Note that I left the SNES reset vector simulation code in, even though it's not possible to trigger, for the time being. Also ... the Super Game Boy core is still disconnected. To be honest, it totally slipped my mind when I released v102 that it wasn't connected again yet. This one's going to be pretty tricky to be honest. I'm thinking about making a third GameBoy::Interface class just for SGB, and coming up with some way of bypassing platform-> calls when in this mode. |
|
Tim Allen | 2707c5316d |
Update to v101r20 release.
byuu says: Changelog: - Z80: emulated 272 new instructions - hiro/GTK: fixed v101r19 Linux regression [thanks, SuperMikeMan!] |
|
Tim Allen | f3e67da937 |
Update to v101r19 release.
byuu says: Changelog: - added \~130 new PAL games to icarus (courtesy of Smarthuman and aquaman) - added all three Korean-localized games to icarus - sfc: removed SuperDisc emulation (it was going nowhere) - sfc: fixed MSU1 regression where the play/repeat flags were not being cleared on track select - nall: cryptography support added; will be used to sign future databases (validation will always be optional) - minor shims to fix compilation issues due to nall changes The real magic is that we now have 25-30% of the PAL SNES library in icarus! Signing will be tricky. Obviously if I put the public key inside the higan archive, then all anyone has to do is change that public key for their own releases. And if you download from my site (which is now over HTTPS), then you don't need the signing to verify integrity. I may just put the public key on my site on my site and leave it at that, we'll see. |
|
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 | ac2d0ba1cf |
Update to v101r05 release.
byuu says: Changelog: - 68K: fixed bug that affected BSR return address - VDP: added very preliminary emulation of planes A, B, W (W is entirely broken though) - VDP: added command/address stuff so you can write to VRAM, CRAM, VSRAM - VDP: added VRAM fill DMA I would be really surprised if any commercial games showed anything at all, so I'd probably recommend against wasting your time trying, unless you're really bored :P Also, I wanted to add: I am accepting patches\! So if anyone wants to look over the 68K core for bugs, that would save me untold amounts of time in the near future :D |
|
Tim Allen | e39987a3e3 |
Update to v101 release.
byuu says (in the public announcement): Not a large changelog this time, sorry. This release is mostly to fix the SA-1 issue, and to get some real-world testing of the new scheduler model. Most of the work in the past month has gone into writing a 68000 CPU core; yet it's still only about half-way finished. Changelog (since the previous release): - fixed SNES SA-1 IRQ regression (fixes Super Mario RPG level-up screen) - new scheduler for all emulator cores (precision of 2^-127) - icarus database adds nine new SNES games - added Input/Frequency to settings file (allows simulation of latency) byuu says (in the WIP forum): Changelog: - in 32-bit mode, Thread uses uint64\_t with 2^-63 time units (10^-7 precision in the worst case) - nearly ten times the precision of an attosecond - in 64-bit mode, Thread uses uint128\_t with 2^-127 time units (10^-26 precision in the worst case) - far more accurate than yoctoseconds; almost closing in on planck time Note: a quartz crystal is accurate to 10^-4 or 10^-5. A cesium fountain atomic clock is accurate to 10^-15. So ... yeah. 2^-63 was perfectly fine; but there was no speed penalty whatsoever for using uint128\_t in 64-bit mode, so why not? |
|
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 | 07995c05a5 |
Update to v100 release.
byuu says: higan has finally reached v100! I feel it's important to stress right away that this is not "version 1.00", nor is it a major milestone release. Rather than arbitrary version numbers, all of my software simply bumps version numbers by one for each official release. As such, higan v100 is simply higan's 100th release. That said, the primary focus of this release has been code clean-ups. These are always somewhat dangerous in that regressions are possible. We've tested through sixteen WIP revisions, one of which was open to the public, to try and minimize any regressions. But all the same, please report any regressions if you discover any. Changelog (since v099): FC: render during pixels 1-256 instead of 0-255 [hex_usr] FC: rewrote controller emulation code SFC: 8% speedup over the previous release thanks to PPU optimizations SFC: fixed nasty DB address wrapping regression from v099 SFC: USART developer controller removed; superseded by 21fx SFC: Super Multitap option removed from controller port 1; ports renamed 2-5 SFC: hidden option to experiment with 128KB VRAM (strictly for novelty) higan: audio volume no longer divided by number of audio streams higan: updated controller polling code to fix possible future mapping issues higan: replaced nall/stream with nall/vfs for file-loading subsystem tomoko: can now load multi-slotted games via command-line tomoko: synchronize video removed from UI; still available in the settings file tomoko, icarus: can navigate to root drive selection on Windows all: major code cleanups and refactoring (~1MB diff against v099) Note 1: the audio volume change means that SGB and MSU1 games won't lose half the volume on the SNES sounds anymore. However, if one goes overboard and drives the sound all the way to max volume with the MSU1, clamping may occur. The obvious solution is not to drive volume that high (it will vastly overpower the SNES audio, which usually never exceeds 25% volume.) Another option is to lower the volume in the audio settings panel to 50%. In general, neither is likely to ever be necessary. Note 2: the synchronize video option was hidden from the UI because it is no longer useful. With the advent of compositors, the loss of the complicated timing settings panel, support for the WonderSwan and its 75hz display, the need to emulate variable refresh rate behaviors in the Game Boy, the unfortunate latency spike and audio distortion caused by long Vsync pauses, and the arrival of adaptive sync technology ... it no longer makes sense to present this option. However, as stated, you can edit settings.bml to enable this option anyway if you insist and understand the aforementioned risks. Changelog (since v099r16 open beta): - fixed MSU1 audio sign extension - fixed compilation with SGB support disabled - icarus can now navigate to root directory - fixed compilation issues with OS X port - (hopefully) fixed label height issue with hiro that affected icarus import dialog - (mostly) fixed BS Memory, Sufami Turbo slot loading Errata: - forgot to remove the " - Slot A", " - Slot B" suffixes for Sufami Turbo slot loading - this means you have to navigate up one folder and then into Sufami Turbo/ to load games for this system - moving WonderSwan orientation controls to the device slot is causing some nastiness - can now select orientation from the main menu, but it doesn't rotate the display |
|
Tim Allen | 13ad9644a2 |
Update to v099r16 release (public beta).
byuu says: Changelog: - hiro: BrowserDialog can navigate up to drive selection on Windows - nall: (file,path,dir,base,prefix,suffix)name => Location::(file,path,dir,base,prefix,suffix) - higan/tomoko: rename audio filter label from "Sinc" to "IIR - Biquad" - higan/tomoko: allow loading files via icarus on the command-line once again - higan/tomoko: (begrudging) quick hack to fix presentation window focus on startup - higan/audio: don't divide output audio volume by number of streams - processor/r65816: fix a regression in (read,write)DB; fixes Taz-Mania - fixed compilation regressions on Windows and Linux I'm happy with where we are at with code cleanups and stability, so I'd like to release v100. But even though I'm not assigning any special significance to this version, we should probably test it more thoroughly first. |
|
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 | 82293c95ae |
Update to v099r14 release.
byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes. |
|
Tim Allen | b08449215a |
Update to v098r18 release.
byuu says: Changelog: - hiro: fixed the BrowserDialog column resizing when navigating to new folders (prevents clipping of filenames) - note: this is kind of a quick-fix; but I have a good idea how to do the proper fix now - nall: added BitField<T, Lo, Hi> class - note: not yet working on the SFC CPU class; need to go at it with a debugger to find out what's happening - GB: emulated DMG/SGB STAT IRQ bug; fixes Zerd no Densetsu and Road Rash (won't fix anything else; don't get hopes up) |
|
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 | 6ae0abe3d3 |
Update to v098r09 release.
byuu says: Changelog: - fixed major nall/vector/prepend bug - renamed hiro/ListView to hiro/TableView - added new hiro/ListView control which is a simplified abstraction of hiro/TableView - updated higan's cheat database window and icarus' scan dialog to use the new ListView control - compilation works once again on all platforms (Windows, Cocoa, GTK, Qt) - the loki skeleton compiles once again (removed nall/DSP references; updated port/device ID names) Small catch: need to capture layout resize events internally in Windows to call resizeColumns. For now, just resize the icarus window to get it to use the full window width for list view items. |