mirror of https://github.com/bsnes-emu/bsnes.git
52 Commits
Author | SHA1 | Message | Date |
---|---|---|---|
Tim Allen | 22bd4b9277 |
Update to v106r52 release.
byuu says: I stand corrected, I managed to create and even larger diff than ever. This one weighs in at 309KiB `>__>` I'll have to create a changelog later, I'm too tired right now to go through all of that. |
|
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 | 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 | 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 | a73a94f331 |
Update to v106r24 release.
byuu says: Changelog: * yes. But seriously, a list of changes on a pre-alpha GUI is going to get annoying. Basically, work on embedding stuff in the binary, firmware loading (both appended to the ROM and in a firmware/ subfolder) added, SGB games can be loaded, config file holds more values for driver settings, added ruby drivers to other platforms, etc. |
|
Tim Allen | ea11c6d098 |
Update to v106r23 release.
byuu says: Changelog: - bsnes: work on the new GUI; can load games now, but no input support yet - icarus: heuristics game/label uses filename instead of internal header name |
|
Tim Allen | b69909be8d |
Update to v106r18 release.
byuu says: Changelog: - major restructuring of board manifests - cleanup of generic board names - Super Famicom: updates to SA1, SuperFX, Cx4, SPC7110, EpsonRTC, SharpRTC load/save code - Super Famicom: added experimental SuperFX plot dithering fix [qwertymodo] - higan, icarus: rename shared folders to lowercase names; put .sys folders into new subfolder - Video Shaders/ → shaders/ - Database/ → database/ - Firmware/ → firmware/ - \*.sys/ → systems/\*.sys/ So right now, only standard SNES games, SA-1, SuperFX, and Cx4 games load. I have not tested SPC7110 or RTC support, because icarus import seems to be completely broken? It's creating blank folders when I try it now. I'll have to fix that ... Since we are now up to thirteen systems, I've put the .sys folders into a subfolder. This should declutter the main higan-windows release folder a good deal. Linux users will need to re-run make install, or manually move things into a new systems/ subfolder. Same goes for icarus: lowercase the database/ and firmware/ folders or re-run make install. I don't know if qwertymodo's SuperFX fix is exactly correct or not. Hopefully it is, but I didn't write a test ROM or anything to be certain. Since SuperFX games should run, if people could please play through some of them and look for any regressions, that'd be very much appreciated. |
|
Tim Allen | 8f61c267c5 |
Update to v106r14 release.
byuu says: Changelog: - game/memory/type/battery → game/memory/volatile - (manufacturer.)content.type → (architecture.)content.type - nall: Markup::find() strips spaces from values in comparisons - higan: updated game manifest loading/saving code for all cores - GBA: flash memory ID is internally selected based on the manufacturer and memory size - SFC: ST018 (ARM6) frequency can be modified via game manifest now - WS: EEPROM::name removed (not useful) - icarus, genius: battery→volatile updates I did my best to look over the diff between r13 and r14, but it's 84KiB excluding the game database changes. It's just too much for me. I'd greatly appreciate if someone could look over it and check for any errors in this update. But more than likely, I suppose we'll iron out any issues by determining which games fail to load. Right now, I know the Super Game Boy support doesn't seem to work. But all non-SFC cores should work fully, and all normal + NEC DSP SFC games should work as well. Unsure about the rest. Also, I'm planning to change the Game Boy “MBC1M” mapper to “MBC1#A” to indicate it's an alternate wiring configuration of the stock MBC1, and not a new mapper type. |
|
Tim Allen | eaa2c1f6c0 |
Update to v106r13 release.
byuu says: Changelog: - game/memory/category → game/memory/content - game/memory/model → game/memory/architecture - game/memory/identity → game/memory/identifier - Super Famicom: memory/content=Bitmap → memory/content=Save - Super Famicom: memory/architecture=DMG,MGB → memory/architecture=LR35902 The game manifest field names are now officially set in stone. I won't change them again, I'll only add new fields if required. As for the values in the field, I'm still undecided on the manufacturer of the ST018, and I could be talked into different identifiers for the Super Game Boy (SGB1/SGB2, DMG/MGB, or just ICD(2)?) The board manifest format is still in flux, as is the choice of what to name firmware files (it's between manufacturer and architecture, where I'm leaning toward the latter currently.) Board memory to Game memory mappings will require both the manufacturer and architecture fields to match. I'll be updating doc.byuu.org soon with the finalized game manifest format. |
|
Tim Allen | 72b824cf1a |
Update to v106r11 release.
byuu says: Changelog: - genius: improve sorting when game name is identical (eg revisions) - icarus, genius: update to finalized manifest syntax |
|
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 | c49d3b2006 |
Update to v106r07 release.
byuu says: Changelog: - Super Game Boy: for the 50th time, higan won't segfault if you cancel the Game Boy cartridge load request - icarus: moved to new manifest syntax for all remaining systems - Game Boy: moved to new manifest syntax Errata: - Game Boy: save RAM does not appear to be working for some reason - Famicom: higan won't even start to run this system; it just acts like a cartridge was never loaded ... - cores outside of the Super Famicom and Game Boy/Color will not run due to icarus/higan manifest syntax differences |
|
Tim Allen | 3a175ad2b0 |
Update to v106r06 release.
byuu says: Changelog: - icarus: new Firmware/ folder, which is used to import external firmware when it's missing from the ROM image - icarus: improved Super Famicom heuristics; including Shift-JIS to UTF-8 encoding of game titles Errata: - if firmware isn't appended, it still cuts out the size from the memory/program.rom file - boards.bml is still missing the new Japanese production boards |
|
Tim Allen | 5e330da4e8 |
Update to v106r05 release.
byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though. |
|
Tim Allen | c38a771f22 |
Update to v106r04 release.
byuu says: Changelog: - nall: `Markup::Node::operator[]` now uses `find()` instead of `lookup()` behind the scenes - Super Famicom: RAM memory ordering is now independent of ROM memory ordering - Super Famicom: added 19 new generic board definitions - icarus: improved Super Famicom heuristics generation Not putting it in the changelog, but the SPC7110 RAM now has write protection disabled again. 99% of games should now be playable with heuristics. The exceptions should be: - 4MB LoROM games with SRAM (Ys 3, FE: Thracia 776) - 2MB DSP LoROM games - BS-X Town - BS-X slotted games - SA1 BSX slotted games - SPC7110 games without the RTC (Momotarou Dentetsu Happy, Super Power League 4) - SPC7110 7MB fan translation (wasn't supported earlier either) - ExLoROM games (wasn't supported earlier either) - Sufami Turbo - Campus Challenge '92 and Powerfest '94 - ST010 is going to run at 15MHz instead of 11MHz - MSU1 (needs to be supported in higan, not icarus) I'll add support for most of these before the release of v107. |
|
Tim Allen | 3d8be92550 |
Update to v106r3 release.
byuu says: Changelog: - Super Famicom: update to newer board markup syntax - Super Famicom: update all mapped ROMs to be write-protected - errata: SPC7110 set ram.writeProtect(true), I'll fix it in the next WIP - icarus: rewrote the Super Famicom heuristics module from scratch Instead of icarus heuristics generating higan-specific mappings, it now generates generic board IDs that can be used by any emulator. I had originally planned to print out real PCB ID codes here, but these board mappings are meant to be more generic, and I don't want them to look real. The pseudo-codes are easy to parse, for example: `DSP-LOROM-NVRAM` for Super Mario Kart, `SUPERFX-RAM` for Doom. I'm going to make a `Boards (Generic).bml` file that will contain mapping definitions for every board. Until this is done, any games not in the SNES preservation database will fail to play because the mapping information is now missing. |
|
Tim Allen | 9c25f128f9 |
Update to v104r07 release.
byuu says: Changelog: - md/vdp: added VIP bit to status register; fixes Cliffhanger - processor/m68k/disassembler: added modes 7 and 8 to LEA address disassembly - processor/m68k/disassembler: enhanced ILLEGAL to display LINEA/LINEF $xxx variants - processor/m68k: ILLEGAL/LINEA/LINEF do not modify the stack register; fixes Caeser no Yabou II - icarus/sfc: request sgb1.boot.rom and sgb2.boot.rom separately; as they are different - icarus/sfc: removed support for external firmware when loading ROM images The hack to run Mega Drive Ballz 3D isn't in place, as I don't know if it's correct, and the graphics were corrupted anyway. The SGB boot ROM change is going to require updating the icarus database as well. I will add that in when I start dumping more cartridges here soon. Finally ... I explained this already, but I'll do so here as well: I removed icarus' support for loading SNES coprocessor firmware games with external firmware files (eg dsp1.program.rom + dsp1.data.rom in the same path as supermariokart.sfc, for example.) I realize most are going to see this as an antagonizing/stubborn move given the recent No-Intro discussion, and I won't deny that said thread is why this came to the forefront of my mind. But on my word, I honestly believe this was an ineffective solution for many reasons not related to our disagreements: 1. No-Intro distributes SNES coprocessor firmware as a merged file, eg "DSP1 (World).zip/DSP1 (World).bin" -- icarus can't possibly know about every ROM distribution set's naming conventions for firmware. (Right now, it appears GoodSNES and NSRT are mostly dead; but there may be more DATs in the future -- including my own.) 2. Even if the user obtains the firmware and tries to rename it, it won't work: icarus parses manifests generated by the heuristics module and sees two ROM files: dsp1.program.rom and dsp1.data.rom. icarus cannot identify a file named dsp1.rom as containing both of these sub-files. Users are going to have to know how to split files, which there is no way to do on stock Windows. Merging files, however, can be done via `copy /b supermariokart.sfc+dsp1.rom supermariokartdsp.sfc`; - and dsp1.rom can be named whatever now. I am not saying this will be easy for the average user, but it's easier than splitting files. 3. Separate firmware breaks icarus' database lookup. If you have pilotwings.sfc but without firmware, icarus will not find a match for it in the database lookup phase. It will then fall back on heuristics. The heuristics will pick DSP1B for compatibility with Ballz 3D which requires it. And so it will try to pull in the wrong firmware, and the game's intro will not work correctly. Furthermore, the database information will be unavailable, resulting in inaccurate mirroring. So for these reasons, I have removed said support. You must now load SNES coprocessor games into higan in one of two ways: 1) game paks with split files; or 2) SFC images with merged firmware. If and when No-Intro deploys a method I can actually use, I give you all my word I will give it a fair shot and if it's reasonable, I'll support it in icarus. |
|
Tim Allen | d13f1dd9ea |
Update to v104r03 release.
byuu says: Changelog: - md/vdp: added full interlace emulation [byuu, Sik, Eke, Mask of Destiny] - md/vdp: fix an issue with overscan/highlight when setting was disabled [hex\_usr] - md/vdp: serialize field, and all oam/objects state - icarus/md: do not enable RAM unless header 0x1b0-1b1 == "RA" [hex\_usr] I really can't believe how difficult the interlace support was to add. I must have tried a hundred combinations of adjusting Y, Vscroll, tile addressing, heights, etc. Many of the changes were a wash that improved some things, regressed others. In the end I ended up needing input from three different people to implement what should have been trivial. I don't know if the Mega Drive is just that weird, if I've declined that much in skill since the days when I implemented SNES interlace, or if I've just never been that good. But either way, I'm disappointed in myself for not being able to figure either this or shadow/highlight out on my own. Yet I'm extremely grateful to my friends for helping carry me when I get stuck. Since it wasn't ever documented before, I'm going to try and document the changes necessary to implement interlace mode for any future emudevs. |
|
Tim Allen | 366e9cebff |
Update to v104r01 release.
byuu says: Changelog: - gba/cpu: synchronize to the PPU, not oneself, when the CPU is stopped - this bug was patched in the official v104 release; but not in the .tar.xz archive - ms/vdp: backdrop color is on the second 16-entry palette, not the first [hex\_usr] - ms/vdp: fix background color 0 priority; fixes Alex Kidd in High Tech World text boxes [hex\_usr] - tomoko: choose first option when loading files via the command-line [hex\_usr] - icarus: lo/hi RAM addressing was backwards; M68K is big endian; fixes save files in Sonic 3 Many thanks to hex\_usr for the Master System / Game Gear VDP fix. That's a tricky system to get good technical information on. The fix should be correct, but please report if you spot any regressions just in case. |
|
Tim Allen | ba384a7c48 |
Update to v104 release.
byuu says: Changelog: - emulator/interface: removed unused Region struct - gba/cpu: optimized CPU::step() as much as I could for a slight speedup¹ - gba/cpu: synchronize the APU better during FIFO updates - higan/md, icarus: add automatic region detection; make it the default option [hex\_usr] - picks NTSC-J if there's more than one match ... eventually, this will be a setting - higan/md, icarus: support all three combinations of SRAM (8-bit low, 8-bit high, 16-bit) - processor/arm7tdmi: fix bug when changing to THUMB mode via MSR [MerryMage] - tomoko: redesigned crash detector to only occur once for all three ruby drivers - this will reduce disk thrashing since the configuration file only needs to be written out one extra time - technically, it's twice ... but we should've always been writing one out on first run in case it crashes then - tomoko: defaulted back to the safest ruby drivers, given the optimal drivers have some stability concerns ¹: minor errata: spotted a typo saying `synchronize(cpu)` when the CPU is stopped, instead of `synchronize(ppu)`. This will be fixed in the v104 official 7zip archives. I'm kind of rushing here but, it's really good timing for me to push out a new official release. The blocking issues are resolved or close to it, and we need lots of testing of the new major changes. I'm going to consider this a semi-stable testing release and leave links to v103 just in case. |
|
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 | 82c58527c3 |
Update to v102r17 release.
byuu says: Changelog: - GBA: process audio at 2MHz instead of 32KHz¹ - MD: do not allow the 68K to stop the Z80, unless it has been granted bus access first - MD: do not reset bus requested/granted signals when the 68K resets the Z80 - the above two fix The Lost Vikings - MD: clean up the bus address decoding to be more readable - MD: add support for a13000-a130ff (#TIME) region; pass to cartridge I/O² - MD: emulate SRAM mapping used by >16mbit games; bank mapping used by >32mbit games³ - MD: add 'reset pending' flag so that loading save states won't reload 68K PC, SP registers - this fixes save state support ... mostly⁴ - MD: if DMA is not enabled, do not allow CD5 to be set [Cydrak] - this fixes in-game graphics for Ristar. Title screen still corrupted on first run - MD: detect and break sprite lists that form an infinite loop [Cydrak] - this fixes the emulator from dead-locking on certain games - MD: add DC offset to sign DAC PCM samples [Cydrak] - this improves audio in Sonic 3 - MD: 68K TAS has a hardware bug that prevents writing the result back to RAM - this fixes Gargoyles - MD: 68K TRAP should not change CPU interrupt level - this fixes Shining Force II, Shining in the Darkness, etc - icarus: better SRAM heuristics for Mega Drive games Todo: - need to serialize the new cartridge ramEnable, ramWritable, bank variables ¹: so technically, the GBA has its FIFO queue (raw PCM), plus a GB chipset. The GB audio runs at 2MHz. However, I was being lazy and running the sequencer 64 times in a row, thus decimating the audio to 32KHz. But simply discarding 63 out of every 64 samples resorts in muddier sound with more static in it. However ... increasing the audio thread processing intensity 64-fold, and requiring heavy-duty three-chain lowpass and highpass filters is not cheap. For this bump in sound quality, we're eating a loss of about 30% of previous performance. Also note that the GB audio emulation in the GBA core still lacks many of the improvements made to the GB core. I was hoping to complete the GB enhancements, but it seems like I'm never going to pass blargg's psychotic edge case tests. So, first I want to clean up the GB audio to my current coding standards, and then I'll port that over to the GBA, which should further increase sound quality. At that point, it sound exceed mGBA's audio quality (due to the ridiculously high sampling rate and strong-attenuation audio filtering.) ²: word writes are probably not handled correctly ... but games are only supposed to do byte writes here. ³: the SRAM mapping is used by games like "Story of Thor" and "Phantasy Star IV." Unfortunately, the former wasn't released in the US and is region protected. So you'll need to change the NTSU to NTSCJ in md/system/system.cpp in order to boot it. But it does work nicely now. The write protection bit is cleared in the game, and then it fails to write to SRAM (soooooooo many games with SRAM write protection do this), so for now I've had to disable checking that bit. Phantasy Star IV has a US release, but sadly the game doesn't boot yet. Hitting some other bug. The bank mapping is pretty much just for the 40mbit Super Street Fighter game. It shows the Sega and Capcom logos now, but is hitting yet another bug and deadlocking. For now, I emulate the SRAM/bank mapping registers on all cartridges, and set sane defaults. So long as games don't write to $a130XX, they should all continue to work. But obviously, we need to get to a point where higan/icarus can selectively enable these registers on a per-game basis. ⁴: so, the Mega Drive has various ways to lock a chip until another chip releases it. The VDP can lock the 68K, the 68K can lock the Z80, etc. If this happens when you save a state, it'll dead-lock the emulator. So that's obviously a problem that needs to be fixed. The fix will be nasty ... basically, bypassing the dead-lock, creating a miniature, one-instruction-long race condition. Extremely unlikely to cause any issues in practice (it's only a little worse than the SNES CPU/SMP desync), but ... there's nothing I can do about it. So you'll have to take it or leave it. But yeah, for now, save states may lock up the emulator. I need to add code to break the loops when in the process of creating a save state still. |
|
Tim Allen | 1cab2dfeb8 |
Update to v102r11 release.
byuu says: Changelog: - MD: connected 32KB cartridge RAM up to every Genesis game under 2MB loaded¹ - MS, GG, MD: improved PSG noise channel emulation, hopefully² - MS, GG, MD: lowered PSG volume so that the lowpass doesn't clamp samples³ - MD: added read/write handlers for VRAM, VSRAM, CRAM - MD: block VRAM copy when CD4 is clear⁴ - MD: rewrote VRAM fill, VRAM copy to be byte-based⁵ - MD: VRAM fill byte set should fall through to regular data port write handler⁶ ¹: the header parsing for backup RAM is really weird. It's spaces when not used, and seems to be 0x02000001-0x02003fff for the Shining games. I don't understand why it starts at 0x02000001 instead of 0x02000000. So I'm just forcing every game to have 32KB of RAM for now. There's also special handling for ROMs > 2MB that also have RAM (Phantasy Star IV, etc) where there's a toggle to switch between ROM and RAM. For now, that's not emulated. I was hoping the Shining games would run after this, but they're still dead-locking on me :( ²: Cydrak pointed out some flaws in my attempt to implement what he had. I was having trouble understanding what he meant, so I went back and read the docs on the sound chip and tried implementing the counter the way the docs describe. Hopefully I have this right, but I don't know of any good test ROMs to make sure my noise emulation is correct. The docs say the shifted-out value goes to the output instead of the low bit of the LFSR, so I made that change as well. I think I hear the noise I'm supposed to in Sonic Marble Zone now, but it seems like it's not correct in Green Hill Zone, adding a bit of an annoying buzz to the background music. Maybe it sounds better with the YM2612, but more likely, I still screwed something up :/ ³: it's set to 50% range for both cores right now. For the MD, it will need to be 25% once YM2612 emulation is in. ⁴: technically, this deadlocks the VDP until a hard reset. I could emulate this, but for now I just don't do the VRAM copy in this case. ⁵: VSRAM fill and CRAM fill not supported in this new mode. They're technically undocumented, and I don't have good notes on how they work. I've been seeing conflicting notes on whether the VRAM fill buffer is 8-bits or 16-bits (I chose 8-bits), and on whether you write the low byte and then high byte of each words, or the high byte and then low byte (I chose the latter.) The VRAM copy improvements fix the opening text in Langrisser II, so that's great. ⁶: Langrisser II sets the transfer length to one less than needed to fill the background letter tile on the scenario overview screen. After moving to byte-sized transfers, a black pixel was getting stuck there. So effectively, VRAM fill length becomes DMA length + 1, and the first byte uses the data port so it writes a word value instead of just a byte value. Hopefully this is all correct, although it probably gets way more complicated with the VDP FIFO. |
|
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 | 186f008574 |
Update to v102r03 release.
byuu says: Changelog: - PCE: split VCE from VDC - HuC6280: changed bus from (uint21 addr) to (uint8 bank, uint13 addr) - added SuperGrafx emulation (adds secondary VDC, plus new VPC) The VDC now has no concept of the actual display raster timing, and instead is driven by Vpulse (start of frame) and Hpulse (start of scanline) signals from the VCE. One still can't render the start of the next scanline onto the current scanline through overly aggressive timings, but it shouldn't be too much more difficult to allow that to occur now. This process incurs quite a major speed hit, so low-end systems with Atom CPUs can't run things at 60fps anymore. The timing needs a lot of work. The pixels end up very jagged if the VCE doesn't output batches of 2-4 pixels at a time. But this should not be a requirement at all, so I'm not sure what's going wrong there. Yo, Bro and the 512-width mode of TV Sports Basketball is now broken as a result of these changes, and I'm not sure why. To load SuperGrafx games, you're going to have to change the .pce extensions to .sg or .sgx. Or you can manually move the games from the PC Engine folder to the SuperGrafx folder and change the game folder extensions. I have no way to tell the games apart. Mednafen uses CRC32 comparisons, and I may consider that since there's only five games, but I'm not sure yet. The only SuperGrafx game that's playable right now is Aldynes. And the priorities are all screwed up. I don't understand how the windows or the priorities work at all from sgxtech.txt, so ... yeah. It's pretty broken, but it's a start. I could really use some help with this, as I'm very lost right now with rendering :/ ----- Note that the SuperGrafx is technically its own system, it's not an add-on. As such, I'm giving it a separate .sys folder, and a separate library. There's debate over how to name this thing. "SuperGrafx" appears more popular than "Super Grafx". And you might also call it the "PC Engine SuperGrafx", but I decided to leave off the prefix so it appears more distinct. |
|
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 | 0ad70a30f8 |
Update to v101r30 release.
byuu says: Changelog: - SMS: added cartridge ROM/RAM mirroring (fixes Alex Kidd) - SMS: fixed 8x16 sprite mode (fixes Wonder Boy, Ys graphics) - Z80: emulated "ex (sp),hl" instruction - Z80: fixed INx NF (should be set instead of cleared) - Z80: fixed loop condition check for CPxR, INxR, LDxR, OTxR (fixes walking in Wonder Boy) - SFC: removed Debugger and sfc/debugger.hpp - icarus: connected MS, GG, MD importing to the scan dialog - PCE: added emulation skeleton to higan and icarus At this point, Master System games are fairly highly compatible, sans audio. Game Gear games are running, but I need to crop the resolution and support the higher color palette that they can utilize. It's really something else the way they handled the resolution shrink on that thing. The last change is obviously going to be the biggest news. I'm very well aware it's not an ideal time to start on a new emulation core, with the MS and MD cores only just now coming to life with no audio support. But, for whatever reason, my heart's really set on working on the PC Engine. I wanted to write the final higan skeleton core, and get things ready so that whenever I'm in the mood to work on the PCE, I can do so. The skeleton is far and away the most tedious and obnoxious part of the emulator development, because it's basically all just lots of boilerplate templated code, lots of new files to create, etc. I really don't know how things are going to proceed ... but I can say with 99.9% certainty that this will be the final brand new core ever added to higan -- at least one written by me, that is. This was basically the last system from my childhood that I ever cared about. It's the last 2D system with games that I really enjoy playing. No other system is worth dividing my efforts and reducing the quality and amount of time to work on the systems I have. In the future, there will be potential for FDS, Mega CD and PCE-CD support. But those will all be add-ons, and they'll all be really difficult and challenge the entire design of higan's UI (it's entirely cartridge-driven at this time.) None of them will be entirely new cores like this one. |
|
Tim Allen | 569f5abc28 |
Update to v101r27 release.
byuu says: Changelog: - SMS: emulated the generic Sega memory mapper (none of the more limited forms of it yet) - (missing ROM shift, ROM write enable emulation -- no commercial games use either, though) - SMS: bus I/O returns 0xff instead of 0x00 so games don't think every key is being pressed at once - (this is a hack until I implement proper controller pad reading) - SMS: very limited protection against reading/writing past the end of ROM/RAM (todo: should mirror) - SMS: VDP background HSCROLL subtracts, rather than adds, to the offset (unlike VSCROLL) - SMS: VDP VSCROLL is 9-bit, modulates voffset+vscroll to 224 in 192-line mode (32x28 tilemap) - SMS: VDP tiledata for backgrounds and sprites use `7-(x&7)` rather than `(x&7)` - SMS: fix output color to be 6-bit rather than 5-bit - SMS: left clip uses register `#7`, not palette color `#7` - (todo: do we want `color[reg7]` or `color[16 + reg7]`?) - SMS: refined handling of 0xcb, 0xed prefixes in the Z80 core and its disassembler - SMS: emulated (0xfd, 0xdd) 0xcb opcodes 0x00-0x0f (still missing 0x10-0xff) - SMS: fixed 0xcb 0b-----110 opcodes to use direct HL and never allow (IX,IY)+d - SMS: fixed major logic bug in (IX,IY)+d displacement - (was using `read(x)` instead of `operand()` for the displacement byte fetch before) - icarus: fake there always being 32KiB of RAM in all SMS cartridges for the time being - (not sure how to detect this stuff yet; although I've read it's not even really possible `>_>`) TODO: remove processor/z80/dissassembler.cpp code block at line 396 (as it's unnecessary.) Lots of commercial games are starting to show trashed graphical output now. |
|
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 | 3dd1aa9c1b |
Update to v100r02 release.
byuu says: Sigh ... I'm really not a good person. I'm inherently selfish. My responsibility and obligation right now is to work on loki, and then on the Tengai Makyou Zero translation, and then on improving the Famicom emulation. And yet ... it's not what I really want to do. That shouldn't matter; I should work on my responsibilities first. Instead, I'm going to be a greedy, self-centered asshole, and work on what I really want to instead. I'm really sorry, guys. I'm sure this will make a few people happy, and probably upset even more people. I'm also making zero guarantees that this ever gets finished. As always, I wish I could keep these things secret, so if I fail / give up, I could just drop it with no shame. But I would have to cut everyone out of the WIP process completely to make it happen. So, here goes ... This WIP adds the initial skeleton for Sega Mega Drive / Genesis emulation. God help us. (minor note: apparently the new extension for Mega Drive games is .md, neat. That's what I chose for the folders too. I thought it was .smd, so that'll be fixed in icarus for the next WIP.) (aside: this is why I wanted to get v100 out. I didn't want this code in a skeleton state in v100's source. Nor did I want really broken emulation, which the first release is sure to be, tarring said release.) ... So, basically, I've been ruminating on the legacy I want to leave behind with higan. 3D systems are just plain out. I'm never going to support them. They're too complex for my abilities, and they would run too slowly with my design style. I'm not willing to compromise my design ideals. And I would never want to play a 3D game system at native 240p/480i resolution ... but 1080p+ upscaling is not accurate, so that's a conflict I want to avoid entirely. It's also never going to emulate computer systems (X68K, PC-98, FM-Towns, etc) because holy shit that would completely destroy me. It's also never going emulate arcade machines. So I think of higan as a collection of 2D emulators for consoles and handhelds. I've gone over every major 2D gaming system there is, looking for ones with games I actually care about and enjoy. And I basically have five of those systems supported already. Looking at the remaining list, I see only three systems left that I have any interest in whatsoever: PC-Engine, Master System, Mega Drive. Again, I'm not in any way committing to emulating any of these, but ... if I had all of those in higan, I think I'd be content to really, truly, finally stop writing more emulators for the rest of my life. And so I decided to tackle the most difficult system first. If I'm successful, the Z80 core should cover a lot of the work on the SMS. And the HuC6280 should land somewhere between the NES and SNES in terms of difficulty ... closer to the NES. The systems that just don't appeal to me at all, which I will never touch, include, but are not limited to: * Atari 2600/5200/7800 * Lynx * Jaguar * Vectrex * Colecovision * Commodore 64 * Neo-Geo * Neo-Geo Pocket / Color * Virtual Boy * Super A'can * 32X * CD-i * etc, etc, etc. And really, even if something were mildly interesting in there ... we have to stop. I can't scale infinitely. I'm already way past my limit, but I'm doing this anyway. Too many cores bloats everything and kills quality on everything. I don't want higan to become MESS v2. I don't know what I'll do about the Famicom Disk System, PC-Engine CD, and Mega CD. I don't think I'll be able to achieve 60fps emulating the Mega CD, even if I tried to. I don't know what's going to happen here with even the Mega Drive. Maybe I'll get driven crazy with the documentation and quit. Maybe it'll end up being too complicated and I'll quit. Maybe the emulation will end up way too slow and I'll give up. Maybe it'll take me seven years to get any games playable at all. Maybe Steve Snake, AamirM and Mike Pavone will pool money to hire a hitman to come after me. Who knows. But this is what I want to do, so ... here goes nothing. |
|
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 | 0955295475 |
Update to v098r08 release.
byuu says: Changelog: - nall/vector rewritten from scratch - higan/audio uses nall/vector instead of raw pointers - higan/sfc/coprocessor/sdd1 updated with new research information - ruby/video/glx and ruby/video/glx2: fuck salt glXSwapIntervalEXT! The big change here is definitely nall/vector. The Windows, OS X and Qt ports won't compile until you change some first/last strings to left/right, but GTK will compile. I'd be really grateful if anyone could stress-test nall/vector. Pretty much everything I do relies on this class. If we introduce a bug, the worst case scenario is my entire SFC game dump database gets corrupted, or the byuu.org server gets compromised. So it's really critical that we test the hell out of this right now. The S-DD1 changes mean you need to update your installation of icarus again. Also, even though the Lunar FMV never really worked on the accuracy core anyway (it didn't initialize the PPU properly), it really won't work now that we emulate the hard-limit of 16MiB for S-DD1 games. |
|
Tim Allen | 379ab6991f |
Update to v097r28 release.
byuu says: Changelog: (all WSC unless otherwise noted) - fixed LINECMP=0 interrupt case (fixes FF4 world map during airship sequence) - improved CPU timing (fixes Magical Drop flickering and FF1 battle music) - added per-frame OAM caching (fixes sprite glitchiness in Magical Drop, Riviera, etc.) - added RTC emulation (fixes Dicing Knight and Judgement Silversword) - added save state support - added cheat code support (untested because I don't know of any cheat codes that exist for this system) - icarus: can now detect games with RTC chips - SFC: bugfix to SharpRTC emulation (Dai Kaijuu Monogatari II) - ( I was adding the extra leap year day to all 12 months instead of just February ... >_< ) Note that the RTC emulation is very incomplete. It's not really documented at all, and the two games I've tried that use it never even ask you to set the date/time (so they're probably just using it to count seconds.) I'm not even sure if I've implement the level-sensitive behavior correctly (actually, now that I think about it, I need to mask the clear bit in INT_ACK for the level-sensitive interrupts ...) A bit worried about the RTC alarm, because it seems like it'll fire continuously for a full minute. Or even if you turn it off after it fires, then that doesn't seem to be lowering the line until the next second ticks on the RTC, so that likely needs to happen when changing the alarm flag. Also not sure on this RTC's weekday byte. On the SharpRTC, it actually computes this for you. Because it's not at all an easy thing to calculate yourself in 65816 or V30MZ assembler. About 40 lines of code to do it in C. For now, I'm requiring the program to calculate the value itself. Also note that there's some gibberish tiles in Judgement Silversword, sadly. Not sure what's up there, but the game's still fully playable at least. Finally, no surprise: Beat-Mania doesn't run :P |
|
Tim Allen | d3413db04a |
Update to v097r27 release.
byuu says: Absolutely major improvements to the WS/C emulation today. Changelog: (all WS/C related) - fixed channel 3 sweep pitch adjustment - fixed channel 3 sweep value sign extension - removed errant channel 5 speed setting (not what's really going on) - fixed sign extension on channel 5 samples - improved DAC mixing of all five audio channels - fixed r26 regression with PPU timing loop - fixed sprite windowing behavior (sprite attribute flag is window mode; not window enable) - added per-scanline register latching to the PPU - IRQs should terminate HLT even when the IRQ enable register bits are clear - fixed PALMONO reads - added blur emulation - added color emulation (based on GBA, so it heavily desaturates colors; not entirely correct, but it helps a lot) - no longer decimating audio to 24KHz; running at full 3.072MHz through the windowed sinc filter [1] - cleaned up PPU portRead / portWrite functions significantly - emulated a weird quirk as mentioned by trap15 regarding timer frequency writes enabling said timers [2] - emulated LCD_CTRL sleep bit; screen can now be disabled (always draws black in this case for now) - improved OAM caching; but it's still disabled because it causes huge amounts of sprite glitches (unsure why) - fixed rendering of sprites that wrap around the screen edges back to the top/left of the display - emulated keypad interrupts - icarus: detect orientation bit in game header - higan: use orientation setting in manifest to set default screen rotation [1] the 24KHz -> 3.072MHz sound change is huge. Sound is substantially improved over the previous WIPs. It does come at a pretty major speed penalty, though. This is the highest frequency of any system in higan running through an incredibly (amazing, yet) demanding sinc resampler. Frame rate dropped from around 240fps to 150fps with the sinc filter on. If you choose a different audio filter, you'll get most of that speed back, but audio will sound worse again. [2] we aren't sure if this is correct hardware behavior or not. It seems to very slightly help Magical Drop, but not much. The blur emulation is brutal. It's absolutely required for Riviera's translucency simulation of selected menu items, but it causes serious headaches due to the WS's ~75hz refresh rate running on ~60hz monitors without vsync. It's probably best to leave it off and just deal with the awful flickering on Riviera's menu options. Overall, WS/C emulation is starting to get quite usable indeed. Couple of major bugs that I'd really like to get fixed before releasing it, though. But they're getting harder and harder to fix ... Major Bugs: - Final Fantasy battle background music is absent. Sound effects still work. Very weird. - Final Fantasy IV scrolling during airship flight opening sequence is horribly broken. Scrolls one screen at a time. - Magical Drop flickers like crazy in-game. Basically unplayable like this. - Star Hearts character names don't appear in the smaller dialog box that pops up. Minor Bugs: - Occasional flickering during Riviera opening scenes. - One-frame flicker of Leda's sprite at the start of the first stage. |
|
Tim Allen | b0d2f5033e |
Update to v097r21 release.
byuu says: Changelog: - icarus: WS/C detects RAM type/size heuristically now - icarus: WS/C uses ram type=$type instead of $type - WS: use back color instead of white for backdrop - WS: fixed sprite count limit; removes all the garbled sprites from GunPey - WS: hopefully fixed sprite priority with screen 2 - WS: implemented keypad polling; GunPey is now fully playable - SNES: added Super Disc expansion port device (doesn't do anything, just for testing) Note: WS is hard-coded to vertical orientation right now. But there's basic code in there for all the horizontal stuff. |
|
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 | 605a8aa3e9 |
Update to v097r05 release.
byuu says: More V30MZ implemented, a lot more to go. icarus now supports importing WS and WSC games. It expects them to have the correct file extension, same for GB and GBC. > Ugh, apparently HiDPI icarus doesn't let you press the check boxes. I set the flag value in the plist to false for now. Forgot to do it for higan, but hopefully I won't forget before release. |
|
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. |
|
Tim Allen | 27660505c8 |
Update to v096 release.
byuu says: Changelog (since v095): - higan: absolutely massive amounts of coding style updates; probably 150 hours of work here - higan: manifest format updated for much greater consistency and simplicity - higan: wrote popen() replacement to suppress console flashing when loading games via icarus - icarus: now includes external database with mapping information for all verified games - icarus: added support for importing Campus Challenge '92 and Powerfest '94 - icarus: merged settings.bml with higan; changing library path in one affects the other now - SFC: added MSU1 audio resume support - SFC: added new expansion port device (eBoot); simulation of SNES-Boot hardware - SFC: expansion port device can now be selected from system menu - SFC: updated handling of open bus (thanks to Exophase for the design idea) - SFC: "BS-X Satellaview" library folder renamed to "BS Memory" - GBA: fixed 8-bit SRAM reading/writing - GBA: PRAM is 16-bits wide - GBA: VRAM OBJ 8-bit writes are ignored - GBA: BGnCNT unused bits are writable - GBA: BG(0,1)CNT can't set d13 - GBA: BLDALPHA is readable (fixes many games including Donkey Kong Country) - GBA: DMA masks &~1/Half, &~3/Word - GBA: fixed many other I/O register reads; gets perfect score on endrift's I/O tests - GBA: fixed caching of r(d) to pass armwrestler tests (Jonas Quinn) - GBA: blocked DMA to/from BIOS region (Cydrak) - GBA: fixed sign-extend and rotate on ldrs instructions (Cydrak) - tomoko: added "Ignore Manifests" option to advanced settings panel - tomoko: re-added support for ruby/quark video shaders - tomoko: improved aspect correction behavior - tomoko: added new tool, "Manifest Viewer" (mostly useful for developers) - ruby: fixed mouse capture clipping on Windows (Cydrak) - ruby: won't crash when using OpenGL 3.2 Linux driver with only OpenGL 2.0 available - ruby: added Linux fallback OpenGL 2.0 driver (not compiled in by default) - ruby: added preliminary WASAPI driver (not compiled in by default, due to bugginess) - hiro: fixed the appearance of Button and ListView::CheckButton on Windows classic - hiro: added missing return values from several functions (fixes crashes with Clang) |
|
Tim Allen | 0253db8685 |
Update to higan and icarus v095r17 release.
byuu says: higan supports Event mapping again. Further, icarus can now detect Event ROMs and MSU1 games. Event ROMs must be named "program.rom", "slot-(1,2,3).rom" MSU1 games must contain "msu1.rom"; and tracks must be named "track-#.pcm" When importing the CC'92, PF'94 ROMs, the program.rom and slot-(1,2,3).rom files must be concatenated. The DSP firmware can optionally be separate, but I'd recommend you go ahead and merge it all to one file. Especially since that common "higan DSP pack" floating around on the web left out the DSP1 ROMs (only has DSP1B) for god knows what reason. There is no support for loading "game.sfc+game.msu+game-*.pcm", because I'm not going to support trying to pull in all of those files through importing. Games will have to be distributed as game folders to use MSU1. The MSU1 icarus support is simply so your game folders won't require an unstable manifest.bml file to be played. So once they're in there, they are good for life. Note: the Event sizes in icarus' SFC heuristics are wrong for appended firmware. Change from 0xXX8000 to 0xXX2000 and it works fine. Will be fixed in r18. Added Sintendo's flickering fixes. The window one's a big help for regular controls, but the ListView double buffering does nothing for me on Windows 7 :( Fairly sure I know why, but too lazy to try and fix that now. Also fixes the mMenu thing. |
|
Tim Allen | 2a4eb1cfc8 |
Update to higan and icarus v095r16 release.
byuu says (in the WIP forum): Changelog: - satellaviewcartridge/SatellaviewCartridge is now bsmemory/BSMemory - Emulation/BS-X Satellaview/ is now Emulation/BS Memory/ - masking is in for MCC's mcu (awful hack in the code, but that's temporary) - BS Memory types are now "flash" or "mrom" - fixed loading Same Game - Tengai Hen - icarus fixed up a lot; can load database entries for any supported media type now (only the SFC DB exists currently) mMenu::remove() fix will be in the next WIP. byuu says (in the public beta thread): Changelog: - GBA emulation accuracy improved quite a bit - video shaders are supported once again - icarus shares settings.bml with higan; changing library path in one now affects the other - icarus manifest generation now uses my SNES game dumping database for perfect mapping of US games - major overhaul to manifest file format. As long as you have v095-style folders without manifest.bml, you will be fine - if not, go to higan->settings->configuration->advanced and check "Ignore Manifests" before loading your first game - new "Manifest Viewer" tool (not really meant for regular users; more of a developer tool) - experimental (but disabled in the binary) WASAPI driver. Help stabilizing it would be *greatly* appreciated! - lots of other stuff |
|
Tim Allen | bd628de3cf |
Update to higan and icarus v095r15 release.
r13 and r14 weren't posted as individual releases, but their changelogs were posted. byuu says about r13: I'm not going to be posting WIPs for r13 and above for a while. The reason is that I'm working on the major manifest overhaul I've discussed previously on the icarus subforum. I'm recreating my boards database from scratch using the map files and the new map analyzer. The only games that will load are ones I've created board definitions for, and updated sfc/cartridge/markup.cpp to parse. Once I've finished all the boards, then I'll update the heuristics. Then finally, I'll sync the syntax changes over to the fc, gb, gba cores. Once that's done, I'll start posting WIPs again, along with a new build of icarus. But I'll still post changelogs as I work through things. Changelog (r13): - preservation: created new database-builder tool (merges region-specific databases with boards) - icarus: support new, external database format (~/.config/icarus/Database/(Super Famicom.bml, ...) - added 1A3B-(10,11,12); 1A3B-20 byuu says about r14: r14 work: I successfully created mappings for every board used in the US set. I also updated icarus' heuristics to use the new mappings, and created ones there for the boards that are only in the JP set. Then I patched icarus to support pulling games out of the database when it's used on a game folder to generate a manifest file. Then I updated a lot of code in higan/sfc to support the new mapping syntax. sfc/cartridge/markup.cpp is about half the size it used to be with the new mappings, and I was able to kill off both map/id and map/select entirely. Then I updated all four emulated systems (and both subsystems) to use "board" as the root node, and harmonized their syntax (made them all more consistent with each other.) Then I added a manifest viewer to the tools window+menu. It's kind of an advanced user feature, but oh well. No reason to coddle people when the feature is very useful for developers. The viewer will show all manifests in order when you load multi-cart games as well. Still not going to call any syntax 100% done right now, but thankfully with the new manifest-free folders, nobody will have to do anything to use the new format. Just download the new version and go. The Super Famicom Event stuff is currently broken (CC92/PF94 boards). That's gonna be fun to support. byuu says about r15: EDIT: small bug in icarus with heuristics. Edit core/super-famicom.cpp line 27: if(/*auto*/ markup = cartridge.markup) { Gotta remove that "auto" so that it returns valid markup. Resolved the final concerns I had with the new manifest format. Right now there are two things that are definitely broken: MCC (BS-X Town cart) and Event (CC '92 and PF'94). And there are a few things that are untested: SPC7110, EpsonRTC, SharpRTC, SDD1+RAM, SufamiTurbo, BS-X slotted carts. |
|
Tim Allen | 0fe55e3f5b |
Update to v095r03 release and icarus 20151107.
byuu says: Note: you will need the new icarus (and please use the "no manifest" system) to run GBA games with this WIP. Changelog: - fixed caching of r(d) to pass armwrestler tests [Jonas Quinn] - DMA to/from GBA BIOS should fail [Cydrak] - fixed sign-extend and rotate on ldrs instructions [Cydrak] - fixed 8-bit SRAM reading/writing [byuu] - refactored GBA/cartridge - cartridge/rom,ram.type is now cartridge/mrom,sram,eeprom,flash - things won't crash horribly if you specify a RAM size larger than the largest legal size in the manifest - specialized MROM / SRAM classes replace all the shared read/write functions that didn't work right anyway - there's a new ruby/video.glx2 driver, which is not enabled by default - use this if you are running Linux/BSD, but don't have OpenGL 3.2 yet - I'm not going to support OpenGL2 on Windows/OS X, because these OSes don't ship ancient video card drivers - probably more. What am I, clairvoyant? :P For endrift's tests, this gets us to 1348/1552 memory and 1016/1260 timing. Overall, this puts us back in second place. Only no$ is ahead on memory, but bgba is even more ahead on timing. |
|
Tim Allen | bc5ad4a1cd |
Update to icarus_20151002.
byuu says: - fixes checkboxes (-again- again [*again*]) - won't check folders with select all / unselect all - won't crash anymore if the SNES ROM image is too small (Saturday Night Slam Masters was crashing it before due to DB size error) - corrected heuristics for Sufami Turbo base cart (mirrors the absurdities of the real cart precisely, since it's one of a kind) - corrected a few DB issues (BS-X name + PSRAM (again [*again*]), SNSM, LAH) (_again_) - these are temporary. Monkey patched in the generated .hpp source rather than the actual DB - not going to fix the SFT sizes because I want to verify what happened there first |