ShuriZma
/
bsnes
mirror of https://github.com/bsnes-emu/bsnes.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
bsnes/higan/sfc/ppu/ppu.hpp

160 lines
3.1 KiB
C++
Raw Normal View History

Update to v098r02 release. byuu says: Changelog: - SFC: fixed a regression on auto joypad polling due to missing parentheses - SFC: exported new PPU::vdisp() const -> uint; function [1] - SFC: merged PPU MMIO functions into the read/write handles (as I previously did for the CPU) - higan: removed individual emulator core names (bnes, bsnes, bgb, bgba, bws) [2] Forgot: - to remove /tomoko from the about dialog [1] note that technically I was relying on the cached, per-frame overscan setting when the CPU and light guns were polling the number of active display scanlines per frame. This was technically incorrect as you can change this value mid-frame and it'll kick in. I've never seen any game toggle overscan every frame, we only know about this because anomie tested this a long time ago. So, nothing should break, but ... you know how the SNES is. You can't even look at the code without something breaking, so I figured I'd mention it >_> [2] I'll probably keep referring to the SNES core as bsnes anyway. I don't mind if you guys use the b<system> names as shorthand. The simplification is mostly to make the branding easier.
2016-04-09 05:20:41 +00:00
struct PPU : Thread, PPUcounter {
alwaysinline auto interlace() const -> bool { return display.interlace; }
alwaysinline auto overscan() const -> bool { return display.overscan; }
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.
2016-07-01 11:50:32 +00:00
alwaysinline auto vdisp() const -> uint { return io.overscan ? 240 : 225; }
Update to v098r02 release. byuu says: Changelog: - SFC: fixed a regression on auto joypad polling due to missing parentheses - SFC: exported new PPU::vdisp() const -> uint; function [1] - SFC: merged PPU MMIO functions into the read/write handles (as I previously did for the CPU) - higan: removed individual emulator core names (bnes, bsnes, bgb, bgba, bws) [2] Forgot: - to remove /tomoko from the about dialog [1] note that technically I was relying on the cached, per-frame overscan setting when the CPU and light guns were polling the number of active display scanlines per frame. This was technically incorrect as you can change this value mid-frame and it'll kick in. I've never seen any game toggle overscan every frame, we only know about this because anomie tested this a long time ago. So, nothing should break, but ... you know how the SNES is. You can't even look at the code without something breaking, so I figured I'd mention it >_> [2] I'll probably keep referring to the SNES core as bsnes anyway. I don't mind if you guys use the b<system> names as shorthand. The simplification is mostly to make the branding easier.
2016-04-09 05:20:41 +00:00
Update to 20100809 release. byuu says: This adds some sync.sh improvements to make it handle errors more gracefully. It also updates asnes a good bit. All of the four base processors now have all publicly accessible functions right at the top of the main headers, and everything else is private. This is to allow these headers to essentially take the place of the previous base classes in the old bsnes-merged format. So if there's something public there, you need to implement that exact function to make your own module. I removed the frame counter from the PPU, as it has nothing to do with emulation. That now resides inside the Qt -> SNES interface code. Quite amazing, I was actually saving the frame counter into the save state files before, yuck. Removed some baggage in the System class: it was friending a bunch of long-dead functions and classes. Forgot to re-add the CHEAT_SYSTEM define to info.hpp, so that's been put back.
2010-08-09 13:33:44 +00:00
PPU();
~PPU();
Update to v095r05 release. byuu says: Changelog: - GBA: lots of emulation improvements - PPU PRAM is 16-bits wide - DMA masks &~1/Half, &~3/Word - VRAM OBJ 8-bit writes are ignored - OAM 8-bit writes are ignored - BGnCNT unused bits are writable* - BG(0,1)CNT can't set the d13 - BLDALPHA is readable (fixes Donkey Kong Country, etc) - SNES: lots of code cleanups - sfc/chip => sfc/coprocessor - UI: save most recent controller selection GBA test scores: 1552/1552, 37/38, 1020/1260 (* forgot to add the value to the read function, so endrift's I/O tests for them will fail. Fixed locally.) Note: SNES is the only system with multiple controller/expansion port options, and as such is the only one with a "None" option. Because it's shared by the controller and expansion port, it ends up sorted first in the list. This means that on your first run, you'll need to go to Super Famicom->Controller Port 1 and select "Gamepad", otherwise input won't work. Also note that changing the expansion port device requires loading a new cart. Unlike controllers, you aren't meant to hotplug expansion port devices.
2015-11-12 10:15:03 +00:00
alwaysinline auto step(uint clocks) -> void;
Update to v098r02 release. byuu says: Changelog: - SFC: fixed a regression on auto joypad polling due to missing parentheses - SFC: exported new PPU::vdisp() const -> uint; function [1] - SFC: merged PPU MMIO functions into the read/write handles (as I previously did for the CPU) - higan: removed individual emulator core names (bnes, bsnes, bgb, bgba, bws) [2] Forgot: - to remove /tomoko from the about dialog [1] note that technically I was relying on the cached, per-frame overscan setting when the CPU and light guns were polling the number of active display scanlines per frame. This was technically incorrect as you can change this value mid-frame and it'll kick in. I've never seen any game toggle overscan every frame, we only know about this because anomie tested this a long time ago. So, nothing should break, but ... you know how the SNES is. You can't even look at the code without something breaking, so I figured I'd mention it >_> [2] I'll probably keep referring to the SNES core as bsnes anyway. I don't mind if you guys use the b<system> names as shorthand. The simplification is mostly to make the branding easier.
2016-04-09 05:20:41 +00:00
static auto Enter() -> void;
Update to v097r13 release. byuu says: I refactored my schedulers. Added about ten lines to each scheduler, and removed about 100 lines of calling into internal state in the scheduler for the FC,SFC cores and about 30-40 lines for the other cores. All of its state is now private. Also reworked all of the entry points to static auto Enter() and auto main(). Where Enter() handles all the synchronization stuff, and main() doesn't need the while(true); loop forcing another layer of indentation everywhere. Took a few hours to do, but totally worth it. I'm surprised I didn't do this sooner. Also updated icarus gmake install rule to copy over the database.
2016-02-09 11:51:12 +00:00
auto main() -> void;
Update to v099r09 release. byuu says: Changelog: - Emulator::Interface::Medium::bootable removed - Emulator::Interface::load(bool required) argument removed [File::Required makes no sense on a folder] - Super Famicom.sys now has user-configurable properties (CPU,PPU1,PPU2 version; PPU1 VRAM size, Region override) - old nall/property removed completely - volatile flags supported on coprocessor RAM files now (still not in icarus, though) - (hopefully) fixed SNES Multitap support (needs testing) - fixed an OAM tiledata range clipping limit in 128KiB VRAM mode (doesn't fix Yoshi's Island, sadly) - (hopefully, again) fixed the input polling bug hex_usr reported - re-added dialog box for when File::Required files are missing - really cool: if you're missing a boot ROM, BIOS ROM, or IPL ROM, it warns you immediately - you don't have to select a game before seeing the error message anymore - fixed cheats.bml load/save location
2016-06-25 08:53:11 +00:00
auto load(Markup::Node) -> bool;
Update to v095r05 release. byuu says: Changelog: - GBA: lots of emulation improvements - PPU PRAM is 16-bits wide - DMA masks &~1/Half, &~3/Word - VRAM OBJ 8-bit writes are ignored - OAM 8-bit writes are ignored - BGnCNT unused bits are writable* - BG(0,1)CNT can't set the d13 - BLDALPHA is readable (fixes Donkey Kong Country, etc) - SNES: lots of code cleanups - sfc/chip => sfc/coprocessor - UI: save most recent controller selection GBA test scores: 1552/1552, 37/38, 1020/1260 (* forgot to add the value to the read function, so endrift's I/O tests for them will fail. Fixed locally.) Note: SNES is the only system with multiple controller/expansion port options, and as such is the only one with a "None" option. Because it's shared by the controller and expansion port, it ends up sorted first in the list. This means that on your first run, you'll need to go to Super Famicom->Controller Port 1 and select "Gamepad", otherwise input won't work. Also note that changing the expansion port device requires loading a new cart. Unlike controllers, you aren't meant to hotplug expansion port devices.
2015-11-12 10:15:03 +00:00
auto power() -> void;
auto serialize(serializer&) -> void;
Update to v099r13 release. byuu says: Changelog: - GB core code cleanup completed - GBA core code cleanup completed - some more cleanup on missed processor/arm functions/variables - fixed FC loading icarus bug - "Load ROM File" icarus functionality restored - minor code unification efforts all around (not perfect yet) - MMIO->IO - mmio.cpp->io.cpp - read,write->readIO,writeIO It's been a very long work in progress ... starting all the way back with v094r09, but the major part of the higan code cleanup is now completed! Of course, it's very important to note that this is only for the basic style: - under_score functions and variables are now camelCase - return-type function-name() are now auto function-name() -> return-type - Natural<T>/Integer<T> replace (u)intT_n types where possible - signed/unsigned are now int/uint - most of the x==true,x==false tests changed to x,!x A lot of spot improvements to consistency, simplicity and quality have gone in along the way, of course. But we'll probably never fully finishing beautifying every last line of code in the entire codebase. Still, this is a really great start. Going forward, WIP diffs should start being smaller and of higher quality once again. I know the joke is, "until my coding style changes again", but ... this was way too stressful, way too time consuming, and way too risky. I'm too old and tired now for extreme upheavel like this again. The only major change I'm slowly mulling over would be renaming the using Natural<T>/Integer<T> = (u)intT; shorthand to something that isn't as easily confused with the (u)int_t types ... but we'll see. I'll definitely continue to change small things all the time, but for the larger picture, I need to just accept the style I have and live with it.
2016-06-29 11:10:28 +00:00
//io.cpp
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
2016-07-01 11:58:12 +00:00
alwaysinline auto addressVRAM() const -> uint16;
alwaysinline auto readVRAM() -> uint16;
alwaysinline auto writeVRAM(bool byte, uint8 data) -> void;
alwaysinline auto readOAM(uint10 addr) -> uint8;
alwaysinline auto writeOAM(uint10 addr, uint8 data) -> void;
alwaysinline auto readCGRAM(bool byte, uint8 addr) -> uint8;
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.
2016-07-04 11:53:24 +00:00
alwaysinline auto writeCGRAM(uint8 addr, uint15 data) -> void;
Update to v099r12 release. byuu says: Changelog: - fixed FC AxROM / VRC7 regression - BitField split to BooleanBitField/NaturalBitField (in preparation for IntegerBitField) - BitFieldReference removed - GB CPU cleaned up - GB Cartridge + Mappers cleaned up - SFC CGRAM is now emulated as uint15[256] instead of uint[512] - sfc/ppu/memory.cpp no longer needed; removed - purged SFC Debugger hooks for now (some of the operator[] calls were bypassing them anyway) Unfortunately, for reasons that defy all semblance of logic, the CGRAM change caused a slight speed hit. As have the last few changes. We're now down to around 129.5fps compared to 123.fps for v099 and 134.5fps at our peak (v099r01-r02). I really like the style I came up with for the Game Boy mappers to settle the purpose(ROM,RAM) vs (rom,ram)Purpose naming convention. If I ever get around to redoing the NES mappers, that's likely the approach I'll take.
2016-06-28 10:43:47 +00:00
auto readIO(uint24 addr, uint8 data) -> uint8;
auto writeIO(uint24 addr, uint8 data) -> void;
Update to v098r02 release. byuu says: Changelog: - SFC: fixed a regression on auto joypad polling due to missing parentheses - SFC: exported new PPU::vdisp() const -> uint; function [1] - SFC: merged PPU MMIO functions into the read/write handles (as I previously did for the CPU) - higan: removed individual emulator core names (bnes, bsnes, bgb, bgba, bws) [2] Forgot: - to remove /tomoko from the about dialog [1] note that technically I was relying on the cached, per-frame overscan setting when the CPU and light guns were polling the number of active display scanlines per frame. This was technically incorrect as you can change this value mid-frame and it'll kick in. I've never seen any game toggle overscan every frame, we only know about this because anomie tested this a long time ago. So, nothing should break, but ... you know how the SNES is. You can't even look at the code without something breaking, so I figured I'd mention it >_> [2] I'll probably keep referring to the SNES core as bsnes anyway. I don't mind if you guys use the b<system> names as shorthand. The simplification is mostly to make the branding easier.
2016-04-09 05:20:41 +00:00
auto latchCounters() -> void;
auto updateVideoMode() -> void;
Update to v101r29 release. byuu says: Changelog: - SMS: background VDP clips partial tiles on the left (math may not be right ... it's hard to reason about) - SMS: fix background VDP scroll locks - SMS: fix VDP sprite coordinates - SMS: paint black after the end of the visible display - todo: shouldn't be a brute force at the end of the main VDP loop, should happen in each rendering unit - higan: removed emulator/debugger.hpp - higan: removed privileged: access specifier - SFC: removed debugger hooks - todo: remove sfc/debugger.hpp - Z80: fixed disassembly of (fd,dd) cb (displacement) (opcode) instructions - Z80: fix to prevent interrupts from firing between ix/iy prefixes and opcodes - todo: this is a rather hacky fix that could, if exploited, crash the stack frame - Z80: fix BIT flags - Z80: fix ADD hl,reg flags - Z80: fix CPD, CPI flags - Z80: fix IND, INI flags - Z80: fix INDR, INIT loop flag check - Z80: fix OUTD, OUTI flags - Z80: fix OTDR, OTIR loop flag check
2017-01-09 21:27:13 +00:00
private:
Update to v099r08 release. byuu says: Changelog: - nall/vfs work 100% completed; even SGB games load now - emulation cores now call load() for the base cartridges as well - updated port/device handling; portmask is gone; device ID bug should be resolved now - SNES controller port 1 multitap option was removed - added support for 128KiB SNES PPU VRAM (for now, edit sfc/ppu/ppu.hpp VRAM::size=0x10000; to enable) Overall, nall/vfs was a huge success!! We've substantially reduced the amount of boilerplate code everywhere, while still allowing (even easier than before) support for RAM-based game loading/saving. All of nall/stream is dead and buried. I am considering removing Emulator::Interface::Medium::id and/or bootable flag. Or at least, doing something different with it. The values for the non-bootable GB/BS/ST entries duplicate the ID that is supposed to be unique. They are for GB/GBC and WS/WSC. Maybe I'll use this as the hardware revision selection ID, and then gut non-bootable options. There's really no reason for that to be there. I think at one point I was using it to generate library tabs for non-bootable systems, but we don't do that anymore anyway. Emulator::Interface::load() may not need the required flag anymore ... it doesn't really do anything right now anyway. I have a few reasons for having the cores load the base cartridge. Most importantly, it is going to enable a special mode for the WonderSwan / WonderSwan Color in the future. If we ever get the IPLROMs dumped ... it's possible to boot these systems with no games inserted to set user profile information and such. There are also other systems that may accept being booted without a cartridge. To reach this state, you would load a game and then cancel the load dialog. Right now, this results in games not loading. The second reason is this prevents nasty crashes when loading fails. So if you're missing a required manifest, the emulator won't die a violent death anymore. It's able to back out at any point. The third reason is consistency: loading the base cartridge works the same as the slot cartridges. The fourth reason is Emulator::Interface::open(uint pathID) values. Before, the GB, SB, GBC modes were IDs 1,2,3 respectively. This complicated things because you had to pass the correct ID. But now instead, Emulator::Interface::load() returns maybe<uint> that is nothing when no game is selected, and a pathID for a valid game. And now open() can take this ID to access this game's folder contents. The downside, which is temporary, is that command-line loading is currently broken. But I do intend on restoring it. In fact, I want to do better than before and allow multi-cart booting from the command-line by specifying the base cartridge and then slot cartridges. The idea should be pretty simple: keep a queue of pending filenames that we fill from the command-line and/or drag-and-drop operations on the main window, and then empty out the queue or prompt for load dialogs from the UI when booting a system. This also might be a bit more unorthodox compared to the traditional emulator design of "loadGame(filename)", but ... oh well. It's easy enough still. The port/device changes are fun. We simplified things quite a bit. The portmask stuff is gone entirely. While ports and devices keep IDs, this is really just sugar-coating so UIs can use for(auto& port : emulator->ports) and access port.id; rather than having to use for(auto n : range(emulator->ports)) { auto& port = emulator->ports[n]; ... }; but they should otherwise generally be identical to the order they appear in their respective ranges. Still, don't rely on that. Input::id is gone. There was no point since we also got rid of the nasty Input::order vector. Since I was in here, I went ahead and caved on the pedantics and renamed Input::guid to Input::userData. I removed the SNES controller port 1 multitap option. Basically, the only game that uses this is N-warp Daisakusen and, no offense to d4s, it's not really a good game anyway. It's just a quick demo to show 8-players on the SNES. But in the UI, all it does is confuse people into wasting time mapping a controller they're never going to use, and they're going to wonder which port to use. If more compelling use cases for 8-players comes about, we can reconsider this. I left all the code to support this in place, so all you have to do is uncomment one line to enable it again. We now have dsnes emulation! :D If you change PPU::VRAM::size to 0x10000 (words), then you should now have 128KiB of VRAM. Even better, it serializes the used-VRAM size, so your save states shouldn't crash on you if you swap between the two (though if you try this, you're nuts.) Note that this option does break commercial software. Yoshi's Island in particular. This game is setting A15 on some PPU register writes, but not on others. The end result of this is things break horribly in-game. Also, this option is causing a very tiny speed hit for obvious reasons with the variable masking value (I'm even using size-1 for now.) Given how niche this is, I may just leave it a compile-time constant to avoid the overhead cost. Otherwise, if we keep the option, then it'll go into Super Famicom.sys/manifest.bml ... I'll flesh that out in the near-future. ---- Finally, some fun for my OCD ... my monitor suddenly cut out on me in the middle of working on this WIP, about six hours in of non-stop work. Had to hit a bunch of ctrl+alt+fN commands (among other things) and trying to log in headless on another TTY to do issue commands, trying to recover the display. Finally power cycled the monitor and it came back up. So all my typing ended up going to who knows where. Usually this sort of thing terrifies me enough that I scrap a WIP and start over to ensure I didn't screw anything up during the crashed screen when hitting keys randomly. Obviously, everything compiles and appears to work fine. And I know it's extremely paranoid, but OCD isn't logical, so ... I'm going to go over every line of the 100KiB r07->r08 diff looking for any corruption/errors/whatever. ---- Review finished. r08 diff review notes: - fc/controller/gamepad/gamepad.cpp: use uint device = ID::Device::Gamepad; not id = ...; - gb/cartridge/cartridge.hpp: remove redundant uint _pathID; (in Information::pathID already) - gb/cartridge/cartridge.hpp: pull sha256 inside Information - sfc/cartridge/load/cpp: add " - Slot (A,B)" to interface->load("Sufami Turbo"); to be more descriptive - sfc/controller/gamepad/gamepad.cpp: use uint device = ID::Device::Gamepad; not id = ...; - sfc/interface/interface.cpp: remove n variable from the Multitap device input generation loop (now unused) - sfc/interface/interface.hpp: put struct Port above struct Device like the other classes - ui-tomoko: cheats.bml is reading from/writing to mediumPaths(0) [system folder instead of game folder] - ui-tomoko: instead of mediumPaths(1) - call emulator->metadataPathID() or something like that
2016-06-24 12:16:53 +00:00
struct VRAM {
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
2016-07-01 11:58:12 +00:00
auto& operator[](uint addr) { return data[addr & mask]; }
Update to v099r08 release. byuu says: Changelog: - nall/vfs work 100% completed; even SGB games load now - emulation cores now call load() for the base cartridges as well - updated port/device handling; portmask is gone; device ID bug should be resolved now - SNES controller port 1 multitap option was removed - added support for 128KiB SNES PPU VRAM (for now, edit sfc/ppu/ppu.hpp VRAM::size=0x10000; to enable) Overall, nall/vfs was a huge success!! We've substantially reduced the amount of boilerplate code everywhere, while still allowing (even easier than before) support for RAM-based game loading/saving. All of nall/stream is dead and buried. I am considering removing Emulator::Interface::Medium::id and/or bootable flag. Or at least, doing something different with it. The values for the non-bootable GB/BS/ST entries duplicate the ID that is supposed to be unique. They are for GB/GBC and WS/WSC. Maybe I'll use this as the hardware revision selection ID, and then gut non-bootable options. There's really no reason for that to be there. I think at one point I was using it to generate library tabs for non-bootable systems, but we don't do that anymore anyway. Emulator::Interface::load() may not need the required flag anymore ... it doesn't really do anything right now anyway. I have a few reasons for having the cores load the base cartridge. Most importantly, it is going to enable a special mode for the WonderSwan / WonderSwan Color in the future. If we ever get the IPLROMs dumped ... it's possible to boot these systems with no games inserted to set user profile information and such. There are also other systems that may accept being booted without a cartridge. To reach this state, you would load a game and then cancel the load dialog. Right now, this results in games not loading. The second reason is this prevents nasty crashes when loading fails. So if you're missing a required manifest, the emulator won't die a violent death anymore. It's able to back out at any point. The third reason is consistency: loading the base cartridge works the same as the slot cartridges. The fourth reason is Emulator::Interface::open(uint pathID) values. Before, the GB, SB, GBC modes were IDs 1,2,3 respectively. This complicated things because you had to pass the correct ID. But now instead, Emulator::Interface::load() returns maybe<uint> that is nothing when no game is selected, and a pathID for a valid game. And now open() can take this ID to access this game's folder contents. The downside, which is temporary, is that command-line loading is currently broken. But I do intend on restoring it. In fact, I want to do better than before and allow multi-cart booting from the command-line by specifying the base cartridge and then slot cartridges. The idea should be pretty simple: keep a queue of pending filenames that we fill from the command-line and/or drag-and-drop operations on the main window, and then empty out the queue or prompt for load dialogs from the UI when booting a system. This also might be a bit more unorthodox compared to the traditional emulator design of "loadGame(filename)", but ... oh well. It's easy enough still. The port/device changes are fun. We simplified things quite a bit. The portmask stuff is gone entirely. While ports and devices keep IDs, this is really just sugar-coating so UIs can use for(auto& port : emulator->ports) and access port.id; rather than having to use for(auto n : range(emulator->ports)) { auto& port = emulator->ports[n]; ... }; but they should otherwise generally be identical to the order they appear in their respective ranges. Still, don't rely on that. Input::id is gone. There was no point since we also got rid of the nasty Input::order vector. Since I was in here, I went ahead and caved on the pedantics and renamed Input::guid to Input::userData. I removed the SNES controller port 1 multitap option. Basically, the only game that uses this is N-warp Daisakusen and, no offense to d4s, it's not really a good game anyway. It's just a quick demo to show 8-players on the SNES. But in the UI, all it does is confuse people into wasting time mapping a controller they're never going to use, and they're going to wonder which port to use. If more compelling use cases for 8-players comes about, we can reconsider this. I left all the code to support this in place, so all you have to do is uncomment one line to enable it again. We now have dsnes emulation! :D If you change PPU::VRAM::size to 0x10000 (words), then you should now have 128KiB of VRAM. Even better, it serializes the used-VRAM size, so your save states shouldn't crash on you if you swap between the two (though if you try this, you're nuts.) Note that this option does break commercial software. Yoshi's Island in particular. This game is setting A15 on some PPU register writes, but not on others. The end result of this is things break horribly in-game. Also, this option is causing a very tiny speed hit for obvious reasons with the variable masking value (I'm even using size-1 for now.) Given how niche this is, I may just leave it a compile-time constant to avoid the overhead cost. Otherwise, if we keep the option, then it'll go into Super Famicom.sys/manifest.bml ... I'll flesh that out in the near-future. ---- Finally, some fun for my OCD ... my monitor suddenly cut out on me in the middle of working on this WIP, about six hours in of non-stop work. Had to hit a bunch of ctrl+alt+fN commands (among other things) and trying to log in headless on another TTY to do issue commands, trying to recover the display. Finally power cycled the monitor and it came back up. So all my typing ended up going to who knows where. Usually this sort of thing terrifies me enough that I scrap a WIP and start over to ensure I didn't screw anything up during the crashed screen when hitting keys randomly. Obviously, everything compiles and appears to work fine. And I know it's extremely paranoid, but OCD isn't logical, so ... I'm going to go over every line of the 100KiB r07->r08 diff looking for any corruption/errors/whatever. ---- Review finished. r08 diff review notes: - fc/controller/gamepad/gamepad.cpp: use uint device = ID::Device::Gamepad; not id = ...; - gb/cartridge/cartridge.hpp: remove redundant uint _pathID; (in Information::pathID already) - gb/cartridge/cartridge.hpp: pull sha256 inside Information - sfc/cartridge/load/cpp: add " - Slot (A,B)" to interface->load("Sufami Turbo"); to be more descriptive - sfc/controller/gamepad/gamepad.cpp: use uint device = ID::Device::Gamepad; not id = ...; - sfc/interface/interface.cpp: remove n variable from the Multitap device input generation loop (now unused) - sfc/interface/interface.hpp: put struct Port above struct Device like the other classes - ui-tomoko: cheats.bml is reading from/writing to mediumPaths(0) [system folder instead of game folder] - ui-tomoko: instead of mediumPaths(1) - call emulator->metadataPathID() or something like that
2016-06-24 12:16:53 +00:00
uint16 data[64 * 1024];
Update to v099r09 release. byuu says: Changelog: - Emulator::Interface::Medium::bootable removed - Emulator::Interface::load(bool required) argument removed [File::Required makes no sense on a folder] - Super Famicom.sys now has user-configurable properties (CPU,PPU1,PPU2 version; PPU1 VRAM size, Region override) - old nall/property removed completely - volatile flags supported on coprocessor RAM files now (still not in icarus, though) - (hopefully) fixed SNES Multitap support (needs testing) - fixed an OAM tiledata range clipping limit in 128KiB VRAM mode (doesn't fix Yoshi's Island, sadly) - (hopefully, again) fixed the input polling bug hex_usr reported - re-added dialog box for when File::Required files are missing - really cool: if you're missing a boot ROM, BIOS ROM, or IPL ROM, it warns you immediately - you don't have to select a game before seeing the error message anymore - fixed cheats.bml load/save location
2016-06-25 08:53:11 +00:00
uint mask = 0x7fff;
Update to v099r08 release. byuu says: Changelog: - nall/vfs work 100% completed; even SGB games load now - emulation cores now call load() for the base cartridges as well - updated port/device handling; portmask is gone; device ID bug should be resolved now - SNES controller port 1 multitap option was removed - added support for 128KiB SNES PPU VRAM (for now, edit sfc/ppu/ppu.hpp VRAM::size=0x10000; to enable) Overall, nall/vfs was a huge success!! We've substantially reduced the amount of boilerplate code everywhere, while still allowing (even easier than before) support for RAM-based game loading/saving. All of nall/stream is dead and buried. I am considering removing Emulator::Interface::Medium::id and/or bootable flag. Or at least, doing something different with it. The values for the non-bootable GB/BS/ST entries duplicate the ID that is supposed to be unique. They are for GB/GBC and WS/WSC. Maybe I'll use this as the hardware revision selection ID, and then gut non-bootable options. There's really no reason for that to be there. I think at one point I was using it to generate library tabs for non-bootable systems, but we don't do that anymore anyway. Emulator::Interface::load() may not need the required flag anymore ... it doesn't really do anything right now anyway. I have a few reasons for having the cores load the base cartridge. Most importantly, it is going to enable a special mode for the WonderSwan / WonderSwan Color in the future. If we ever get the IPLROMs dumped ... it's possible to boot these systems with no games inserted to set user profile information and such. There are also other systems that may accept being booted without a cartridge. To reach this state, you would load a game and then cancel the load dialog. Right now, this results in games not loading. The second reason is this prevents nasty crashes when loading fails. So if you're missing a required manifest, the emulator won't die a violent death anymore. It's able to back out at any point. The third reason is consistency: loading the base cartridge works the same as the slot cartridges. The fourth reason is Emulator::Interface::open(uint pathID) values. Before, the GB, SB, GBC modes were IDs 1,2,3 respectively. This complicated things because you had to pass the correct ID. But now instead, Emulator::Interface::load() returns maybe<uint> that is nothing when no game is selected, and a pathID for a valid game. And now open() can take this ID to access this game's folder contents. The downside, which is temporary, is that command-line loading is currently broken. But I do intend on restoring it. In fact, I want to do better than before and allow multi-cart booting from the command-line by specifying the base cartridge and then slot cartridges. The idea should be pretty simple: keep a queue of pending filenames that we fill from the command-line and/or drag-and-drop operations on the main window, and then empty out the queue or prompt for load dialogs from the UI when booting a system. This also might be a bit more unorthodox compared to the traditional emulator design of "loadGame(filename)", but ... oh well. It's easy enough still. The port/device changes are fun. We simplified things quite a bit. The portmask stuff is gone entirely. While ports and devices keep IDs, this is really just sugar-coating so UIs can use for(auto& port : emulator->ports) and access port.id; rather than having to use for(auto n : range(emulator->ports)) { auto& port = emulator->ports[n]; ... }; but they should otherwise generally be identical to the order they appear in their respective ranges. Still, don't rely on that. Input::id is gone. There was no point since we also got rid of the nasty Input::order vector. Since I was in here, I went ahead and caved on the pedantics and renamed Input::guid to Input::userData. I removed the SNES controller port 1 multitap option. Basically, the only game that uses this is N-warp Daisakusen and, no offense to d4s, it's not really a good game anyway. It's just a quick demo to show 8-players on the SNES. But in the UI, all it does is confuse people into wasting time mapping a controller they're never going to use, and they're going to wonder which port to use. If more compelling use cases for 8-players comes about, we can reconsider this. I left all the code to support this in place, so all you have to do is uncomment one line to enable it again. We now have dsnes emulation! :D If you change PPU::VRAM::size to 0x10000 (words), then you should now have 128KiB of VRAM. Even better, it serializes the used-VRAM size, so your save states shouldn't crash on you if you swap between the two (though if you try this, you're nuts.) Note that this option does break commercial software. Yoshi's Island in particular. This game is setting A15 on some PPU register writes, but not on others. The end result of this is things break horribly in-game. Also, this option is causing a very tiny speed hit for obvious reasons with the variable masking value (I'm even using size-1 for now.) Given how niche this is, I may just leave it a compile-time constant to avoid the overhead cost. Otherwise, if we keep the option, then it'll go into Super Famicom.sys/manifest.bml ... I'll flesh that out in the near-future. ---- Finally, some fun for my OCD ... my monitor suddenly cut out on me in the middle of working on this WIP, about six hours in of non-stop work. Had to hit a bunch of ctrl+alt+fN commands (among other things) and trying to log in headless on another TTY to do issue commands, trying to recover the display. Finally power cycled the monitor and it came back up. So all my typing ended up going to who knows where. Usually this sort of thing terrifies me enough that I scrap a WIP and start over to ensure I didn't screw anything up during the crashed screen when hitting keys randomly. Obviously, everything compiles and appears to work fine. And I know it's extremely paranoid, but OCD isn't logical, so ... I'm going to go over every line of the 100KiB r07->r08 diff looking for any corruption/errors/whatever. ---- Review finished. r08 diff review notes: - fc/controller/gamepad/gamepad.cpp: use uint device = ID::Device::Gamepad; not id = ...; - gb/cartridge/cartridge.hpp: remove redundant uint _pathID; (in Information::pathID already) - gb/cartridge/cartridge.hpp: pull sha256 inside Information - sfc/cartridge/load/cpp: add " - Slot (A,B)" to interface->load("Sufami Turbo"); to be more descriptive - sfc/controller/gamepad/gamepad.cpp: use uint device = ID::Device::Gamepad; not id = ...; - sfc/interface/interface.cpp: remove n variable from the Multitap device input generation loop (now unused) - sfc/interface/interface.hpp: put struct Port above struct Device like the other classes - ui-tomoko: cheats.bml is reading from/writing to mediumPaths(0) [system folder instead of game folder] - ui-tomoko: instead of mediumPaths(1) - call emulator->metadataPathID() or something like that
2016-06-24 12:16:53 +00:00
} vram;
Update to v099r12 release. byuu says: Changelog: - fixed FC AxROM / VRC7 regression - BitField split to BooleanBitField/NaturalBitField (in preparation for IntegerBitField) - BitFieldReference removed - GB CPU cleaned up - GB Cartridge + Mappers cleaned up - SFC CGRAM is now emulated as uint15[256] instead of uint[512] - sfc/ppu/memory.cpp no longer needed; removed - purged SFC Debugger hooks for now (some of the operator[] calls were bypassing them anyway) Unfortunately, for reasons that defy all semblance of logic, the CGRAM change caused a slight speed hit. As have the last few changes. We're now down to around 129.5fps compared to 123.fps for v099 and 134.5fps at our peak (v099r01-r02). I really like the style I came up with for the Game Boy mappers to settle the purpose(ROM,RAM) vs (rom,ram)Purpose naming convention. If I ever get around to redoing the NES mappers, that's likely the approach I'll take.
2016-06-28 10:43:47 +00:00
Update to v095r05 release. byuu says: Changelog: - GBA: lots of emulation improvements - PPU PRAM is 16-bits wide - DMA masks &~1/Half, &~3/Word - VRAM OBJ 8-bit writes are ignored - OAM 8-bit writes are ignored - BGnCNT unused bits are writable* - BG(0,1)CNT can't set the d13 - BLDALPHA is readable (fixes Donkey Kong Country, etc) - SNES: lots of code cleanups - sfc/chip => sfc/coprocessor - UI: save most recent controller selection GBA test scores: 1552/1552, 37/38, 1020/1260 (* forgot to add the value to the read function, so endrift's I/O tests for them will fail. Fixed locally.) Note: SNES is the only system with multiple controller/expansion port options, and as such is the only one with a "None" option. Because it's shared by the controller and expansion port, it ends up sorted first in the list. This means that on your first run, you'll need to go to Super Famicom->Controller Port 1 and select "Gamepad", otherwise input won't work. Also note that changing the expansion port device requires loading a new cart. Unlike controllers, you aren't meant to hotplug expansion port devices.
2015-11-12 10:15:03 +00:00
uint32* output = nullptr;
Update to v068r12 release. (there was no r11 release posted to the WIP thread) byuu says: This took ten hours of mind boggling insanity to pull off. It upgrades the S-PPU dot-based renderer to fetch one tile, and then output all of its pixels before fetching again. It sounds easy enough, but it's insanely difficult. I ended up taking one small shortcut, in that rather than fetch at -7, I fetch at the first instance where a tile is needed to plot to x=0. So if you have {-3 to +4 } as a tile, it fetches at -3. That won't work so well on hardware, if two BGs fetch at the same X offset, they won't have time. I have had no luck staggering the reads at BG1=-7, BG3=-5, etc. While I can shift and fetch just fine, what happens is that when a new tile is fetched in, that gives a new palette, priority, etc; and this ends up happening between two tiles which results in the right-most edges of the screen ending up with the wrong colors and such. Offset-per-tile is cheap as always. Although looking at it, I'm not sure how BG3 could pre-fetch, especially with the way one or two OPT modes can fetch two tiles. There's no magic in Hoffset caching yet, so the SMW1 pixel issue is still there. Mode 7 got a bugfix, it was off-by-one horizontally from the mosaic code. After re-designing the BG mosaic, I ended up needing a separate mosaic for Mode7, and in the process I fixed that bug. The obvious change is that the Chrono Trigger Mode7->Mode2 transition doesn't cause the pendulum to jump anymore. Windows were simplified just a tad. The range testing is shared for all modes now. Ironically, it's a bit slower, but I'll take less code over more speed for the accuracy core. Speaking of speed, because there's so much less calculations per pixel for BGs, performance for the entire emulator has gone up by 30% in the accuracy core. Pretty neat overall, I can maintain 60fps in all but, yeah you can guess can't you?
2010-09-04 03:36:03 +00:00
struct {
bool interlace;
bool overscan;
} display;
Update to v098r02 release. byuu says: Changelog: - SFC: fixed a regression on auto joypad polling due to missing parentheses - SFC: exported new PPU::vdisp() const -> uint; function [1] - SFC: merged PPU MMIO functions into the read/write handles (as I previously did for the CPU) - higan: removed individual emulator core names (bnes, bsnes, bgb, bgba, bws) [2] Forgot: - to remove /tomoko from the about dialog [1] note that technically I was relying on the cached, per-frame overscan setting when the CPU and light guns were polling the number of active display scanlines per frame. This was technically incorrect as you can change this value mid-frame and it'll kick in. I've never seen any game toggle overscan every frame, we only know about this because anomie tested this a long time ago. So, nothing should break, but ... you know how the SNES is. You can't even look at the code without something breaking, so I figured I'd mention it >_> [2] I'll probably keep referring to the SNES core as bsnes anyway. I don't mind if you guys use the b<system> names as shorthand. The simplification is mostly to make the branding easier.
2016-04-09 05:20:41 +00:00
auto scanline() -> void;
auto frame() -> void;
Update to v098r06 release. byuu says: Changelog: - emulation cores now refresh video from host thread instead of cothreads (fix AMD crash) - SFC: fixed another bug with leap year months in SharpRTC emulation - SFC: cleaned up camelCase on function names for armdsp,epsonrtc,hitachidsp,mcc,nss,sharprtc classes - GB: added MBC1M emulation (requires manually setting mapper=MBC1M in manifest.bml for now, sorry) - audio: implemented Emulator::Audio mixer and effects processor - audio: implemented Emulator::Stream interface - it is now possible to have more than two audio streams: eg SNES + SGB + MSU1 + Voicer-Kun (eventually) - audio: added reverb delay + reverb level settings; exposed balance configuration in UI - video: reworked palette generation to re-enable saturation, gamma, luminance adjustments - higan/emulator.cpp is gone since there was nothing left in it I know you guys are going to say the color adjust/balance/reverb stuff is pointless. And indeed it mostly is. But I like the idea of allowing some fun special effects and configurability that isn't system-wide. Note: there seems to be some kind of added audio lag in the SGB emulation now, and I don't really understand why. The code should be effectively identical to what I had before. The only main thing is that I'm sampling things to 48000hz instead of 32040hz before mixing. There's no point where I'm intentionally introducing added latency though. I'm kind of stumped, so if anyone wouldn't mind taking a look at it, it'd be much appreciated :/ I don't have an MSU1 test ROM, but the latency issue may affect MSU1 as well, and that would be very bad.
2016-04-22 13:35:51 +00:00
auto refresh() -> void;
Update to v098r02 release. byuu says: Changelog: - SFC: fixed a regression on auto joypad polling due to missing parentheses - SFC: exported new PPU::vdisp() const -> uint; function [1] - SFC: merged PPU MMIO functions into the read/write handles (as I previously did for the CPU) - higan: removed individual emulator core names (bnes, bsnes, bgb, bgba, bws) [2] Forgot: - to remove /tomoko from the about dialog [1] note that technically I was relying on the cached, per-frame overscan setting when the CPU and light guns were polling the number of active display scanlines per frame. This was technically incorrect as you can change this value mid-frame and it'll kick in. I've never seen any game toggle overscan every frame, we only know about this because anomie tested this a long time ago. So, nothing should break, but ... you know how the SNES is. You can't even look at the code without something breaking, so I figured I'd mention it >_> [2] I'll probably keep referring to the SNES core as bsnes anyway. I don't mind if you guys use the b<system> names as shorthand. The simplification is mostly to make the branding easier.
2016-04-09 05:20:41 +00:00
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
struct {
uint version;
uint8 mdr;
} ppu1, ppu2;
struct Latches {
uint16 vram;
uint8 oam;
uint8 cgram;
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 >_>
2017-07-12 08:24:27 +00:00
uint8 bgofsPPU1;
uint3 bgofsPPU2;
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
uint8 mode7;
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
2016-07-01 11:58:12 +00:00
uint1 counters;
uint1 hcounter;
uint1 vcounter;
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
uint10 oamAddress;
Update to v099r12 release. byuu says: Changelog: - fixed FC AxROM / VRC7 regression - BitField split to BooleanBitField/NaturalBitField (in preparation for IntegerBitField) - BitFieldReference removed - GB CPU cleaned up - GB Cartridge + Mappers cleaned up - SFC CGRAM is now emulated as uint15[256] instead of uint[512] - sfc/ppu/memory.cpp no longer needed; removed - purged SFC Debugger hooks for now (some of the operator[] calls were bypassing them anyway) Unfortunately, for reasons that defy all semblance of logic, the CGRAM change caused a slight speed hit. As have the last few changes. We're now down to around 129.5fps compared to 123.fps for v099 and 134.5fps at our peak (v099r01-r02). I really like the style I came up with for the Game Boy mappers to settle the purpose(ROM,RAM) vs (rom,ram)Purpose naming convention. If I ever get around to redoing the NES mappers, that's likely the approach I'll take.
2016-06-28 10:43:47 +00:00
uint8 cgramAddress;
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
} latch;
Update to v098r02 release. byuu says: Changelog: - SFC: fixed a regression on auto joypad polling due to missing parentheses - SFC: exported new PPU::vdisp() const -> uint; function [1] - SFC: merged PPU MMIO functions into the read/write handles (as I previously did for the CPU) - higan: removed individual emulator core names (bnes, bsnes, bgb, bgba, bws) [2] Forgot: - to remove /tomoko from the about dialog [1] note that technically I was relying on the cached, per-frame overscan setting when the CPU and light guns were polling the number of active display scanlines per frame. This was technically incorrect as you can change this value mid-frame and it'll kick in. I've never seen any game toggle overscan every frame, we only know about this because anomie tested this a long time ago. So, nothing should break, but ... you know how the SNES is. You can't even look at the code without something breaking, so I figured I'd mention it >_> [2] I'll probably keep referring to the SNES core as bsnes anyway. I don't mind if you guys use the b<system> names as shorthand. The simplification is mostly to make the branding easier.
2016-04-09 05:20:41 +00:00
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.
2016-07-01 11:50:32 +00:00
struct IO {
Update to v098r02 release. byuu says: Changelog: - SFC: fixed a regression on auto joypad polling due to missing parentheses - SFC: exported new PPU::vdisp() const -> uint; function [1] - SFC: merged PPU MMIO functions into the read/write handles (as I previously did for the CPU) - higan: removed individual emulator core names (bnes, bsnes, bgb, bgba, bws) [2] Forgot: - to remove /tomoko from the about dialog [1] note that technically I was relying on the cached, per-frame overscan setting when the CPU and light guns were polling the number of active display scanlines per frame. This was technically incorrect as you can change this value mid-frame and it'll kick in. I've never seen any game toggle overscan every frame, we only know about this because anomie tested this a long time ago. So, nothing should break, but ... you know how the SNES is. You can't even look at the code without something breaking, so I figured I'd mention it >_> [2] I'll probably keep referring to the SNES core as bsnes anyway. I don't mind if you guys use the b<system> names as shorthand. The simplification is mostly to make the branding easier.
2016-04-09 05:20:41 +00:00
//$2100 INIDISP
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
bool displayDisable;
uint4 displayBrightness;
Update to v098r02 release. byuu says: Changelog: - SFC: fixed a regression on auto joypad polling due to missing parentheses - SFC: exported new PPU::vdisp() const -> uint; function [1] - SFC: merged PPU MMIO functions into the read/write handles (as I previously did for the CPU) - higan: removed individual emulator core names (bnes, bsnes, bgb, bgba, bws) [2] Forgot: - to remove /tomoko from the about dialog [1] note that technically I was relying on the cached, per-frame overscan setting when the CPU and light guns were polling the number of active display scanlines per frame. This was technically incorrect as you can change this value mid-frame and it'll kick in. I've never seen any game toggle overscan every frame, we only know about this because anomie tested this a long time ago. So, nothing should break, but ... you know how the SNES is. You can't even look at the code without something breaking, so I figured I'd mention it >_> [2] I'll probably keep referring to the SNES core as bsnes anyway. I don't mind if you guys use the b<system> names as shorthand. The simplification is mostly to make the branding easier.
2016-04-09 05:20:41 +00:00
//$2102 OAMADDL
//$2103 OAMADDH
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
uint10 oamBaseAddress;
uint10 oamAddress;
bool oamPriority;
Update to v098r02 release. byuu says: Changelog: - SFC: fixed a regression on auto joypad polling due to missing parentheses - SFC: exported new PPU::vdisp() const -> uint; function [1] - SFC: merged PPU MMIO functions into the read/write handles (as I previously did for the CPU) - higan: removed individual emulator core names (bnes, bsnes, bgb, bgba, bws) [2] Forgot: - to remove /tomoko from the about dialog [1] note that technically I was relying on the cached, per-frame overscan setting when the CPU and light guns were polling the number of active display scanlines per frame. This was technically incorrect as you can change this value mid-frame and it'll kick in. I've never seen any game toggle overscan every frame, we only know about this because anomie tested this a long time ago. So, nothing should break, but ... you know how the SNES is. You can't even look at the code without something breaking, so I figured I'd mention it >_> [2] I'll probably keep referring to the SNES core as bsnes anyway. I don't mind if you guys use the b<system> names as shorthand. The simplification is mostly to make the branding easier.
2016-04-09 05:20:41 +00:00
//$2105 BGMODE
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
bool bgPriority;
uint8 bgMode;
Update to v098r02 release. byuu says: Changelog: - SFC: fixed a regression on auto joypad polling due to missing parentheses - SFC: exported new PPU::vdisp() const -> uint; function [1] - SFC: merged PPU MMIO functions into the read/write handles (as I previously did for the CPU) - higan: removed individual emulator core names (bnes, bsnes, bgb, bgba, bws) [2] Forgot: - to remove /tomoko from the about dialog [1] note that technically I was relying on the cached, per-frame overscan setting when the CPU and light guns were polling the number of active display scanlines per frame. This was technically incorrect as you can change this value mid-frame and it'll kick in. I've never seen any game toggle overscan every frame, we only know about this because anomie tested this a long time ago. So, nothing should break, but ... you know how the SNES is. You can't even look at the code without something breaking, so I figured I'd mention it >_> [2] I'll probably keep referring to the SNES core as bsnes anyway. I don't mind if you guys use the b<system> names as shorthand. The simplification is mostly to make the branding easier.
2016-04-09 05:20:41 +00:00
//$210d BG1HOFS
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
uint16 hoffsetMode7;
Update to v098r02 release. byuu says: Changelog: - SFC: fixed a regression on auto joypad polling due to missing parentheses - SFC: exported new PPU::vdisp() const -> uint; function [1] - SFC: merged PPU MMIO functions into the read/write handles (as I previously did for the CPU) - higan: removed individual emulator core names (bnes, bsnes, bgb, bgba, bws) [2] Forgot: - to remove /tomoko from the about dialog [1] note that technically I was relying on the cached, per-frame overscan setting when the CPU and light guns were polling the number of active display scanlines per frame. This was technically incorrect as you can change this value mid-frame and it'll kick in. I've never seen any game toggle overscan every frame, we only know about this because anomie tested this a long time ago. So, nothing should break, but ... you know how the SNES is. You can't even look at the code without something breaking, so I figured I'd mention it >_> [2] I'll probably keep referring to the SNES core as bsnes anyway. I don't mind if you guys use the b<system> names as shorthand. The simplification is mostly to make the branding easier.
2016-04-09 05:20:41 +00:00
//$210e BG1VOFS
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
uint16 voffsetMode7;
Update to v098r02 release. byuu says: Changelog: - SFC: fixed a regression on auto joypad polling due to missing parentheses - SFC: exported new PPU::vdisp() const -> uint; function [1] - SFC: merged PPU MMIO functions into the read/write handles (as I previously did for the CPU) - higan: removed individual emulator core names (bnes, bsnes, bgb, bgba, bws) [2] Forgot: - to remove /tomoko from the about dialog [1] note that technically I was relying on the cached, per-frame overscan setting when the CPU and light guns were polling the number of active display scanlines per frame. This was technically incorrect as you can change this value mid-frame and it'll kick in. I've never seen any game toggle overscan every frame, we only know about this because anomie tested this a long time ago. So, nothing should break, but ... you know how the SNES is. You can't even look at the code without something breaking, so I figured I'd mention it >_> [2] I'll probably keep referring to the SNES core as bsnes anyway. I don't mind if you guys use the b<system> names as shorthand. The simplification is mostly to make the branding easier.
2016-04-09 05:20:41 +00:00
//$2115 VMAIN
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
bool vramIncrementMode;
uint2 vramMapping;
uint8 vramIncrementSize;
Update to v098r02 release. byuu says: Changelog: - SFC: fixed a regression on auto joypad polling due to missing parentheses - SFC: exported new PPU::vdisp() const -> uint; function [1] - SFC: merged PPU MMIO functions into the read/write handles (as I previously did for the CPU) - higan: removed individual emulator core names (bnes, bsnes, bgb, bgba, bws) [2] Forgot: - to remove /tomoko from the about dialog [1] note that technically I was relying on the cached, per-frame overscan setting when the CPU and light guns were polling the number of active display scanlines per frame. This was technically incorrect as you can change this value mid-frame and it'll kick in. I've never seen any game toggle overscan every frame, we only know about this because anomie tested this a long time ago. So, nothing should break, but ... you know how the SNES is. You can't even look at the code without something breaking, so I figured I'd mention it >_> [2] I'll probably keep referring to the SNES core as bsnes anyway. I don't mind if you guys use the b<system> names as shorthand. The simplification is mostly to make the branding easier.
2016-04-09 05:20:41 +00:00
//$2116 VMADDL
//$2117 VMADDH
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
uint16 vramAddress;
Update to v098r02 release. byuu says: Changelog: - SFC: fixed a regression on auto joypad polling due to missing parentheses - SFC: exported new PPU::vdisp() const -> uint; function [1] - SFC: merged PPU MMIO functions into the read/write handles (as I previously did for the CPU) - higan: removed individual emulator core names (bnes, bsnes, bgb, bgba, bws) [2] Forgot: - to remove /tomoko from the about dialog [1] note that technically I was relying on the cached, per-frame overscan setting when the CPU and light guns were polling the number of active display scanlines per frame. This was technically incorrect as you can change this value mid-frame and it'll kick in. I've never seen any game toggle overscan every frame, we only know about this because anomie tested this a long time ago. So, nothing should break, but ... you know how the SNES is. You can't even look at the code without something breaking, so I figured I'd mention it >_> [2] I'll probably keep referring to the SNES core as bsnes anyway. I don't mind if you guys use the b<system> names as shorthand. The simplification is mostly to make the branding easier.
2016-04-09 05:20:41 +00:00
//$211a M7SEL
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
uint2 repeatMode7;
bool vflipMode7;
bool hflipMode7;
Update to v098r02 release. byuu says: Changelog: - SFC: fixed a regression on auto joypad polling due to missing parentheses - SFC: exported new PPU::vdisp() const -> uint; function [1] - SFC: merged PPU MMIO functions into the read/write handles (as I previously did for the CPU) - higan: removed individual emulator core names (bnes, bsnes, bgb, bgba, bws) [2] Forgot: - to remove /tomoko from the about dialog [1] note that technically I was relying on the cached, per-frame overscan setting when the CPU and light guns were polling the number of active display scanlines per frame. This was technically incorrect as you can change this value mid-frame and it'll kick in. I've never seen any game toggle overscan every frame, we only know about this because anomie tested this a long time ago. So, nothing should break, but ... you know how the SNES is. You can't even look at the code without something breaking, so I figured I'd mention it >_> [2] I'll probably keep referring to the SNES core as bsnes anyway. I don't mind if you guys use the b<system> names as shorthand. The simplification is mostly to make the branding easier.
2016-04-09 05:20:41 +00:00
//$211b M7A
uint16 m7a;
//$211c M7B
uint16 m7b;
//$211d M7C
uint16 m7c;
//$211e M7D
uint16 m7d;
//$211f M7X
uint16 m7x;
//$2120 M7Y
uint16 m7y;
//$2121 CGADD
Update to v099r12 release. byuu says: Changelog: - fixed FC AxROM / VRC7 regression - BitField split to BooleanBitField/NaturalBitField (in preparation for IntegerBitField) - BitFieldReference removed - GB CPU cleaned up - GB Cartridge + Mappers cleaned up - SFC CGRAM is now emulated as uint15[256] instead of uint[512] - sfc/ppu/memory.cpp no longer needed; removed - purged SFC Debugger hooks for now (some of the operator[] calls were bypassing them anyway) Unfortunately, for reasons that defy all semblance of logic, the CGRAM change caused a slight speed hit. As have the last few changes. We're now down to around 129.5fps compared to 123.fps for v099 and 134.5fps at our peak (v099r01-r02). I really like the style I came up with for the Game Boy mappers to settle the purpose(ROM,RAM) vs (rom,ram)Purpose naming convention. If I ever get around to redoing the NES mappers, that's likely the approach I'll take.
2016-06-28 10:43:47 +00:00
uint8 cgramAddress;
uint1 cgramAddressLatch;
Update to v098r02 release. byuu says: Changelog: - SFC: fixed a regression on auto joypad polling due to missing parentheses - SFC: exported new PPU::vdisp() const -> uint; function [1] - SFC: merged PPU MMIO functions into the read/write handles (as I previously did for the CPU) - higan: removed individual emulator core names (bnes, bsnes, bgb, bgba, bws) [2] Forgot: - to remove /tomoko from the about dialog [1] note that technically I was relying on the cached, per-frame overscan setting when the CPU and light guns were polling the number of active display scanlines per frame. This was technically incorrect as you can change this value mid-frame and it'll kick in. I've never seen any game toggle overscan every frame, we only know about this because anomie tested this a long time ago. So, nothing should break, but ... you know how the SNES is. You can't even look at the code without something breaking, so I figured I'd mention it >_> [2] I'll probably keep referring to the SNES core as bsnes anyway. I don't mind if you guys use the b<system> names as shorthand. The simplification is mostly to make the branding easier.
2016-04-09 05:20:41 +00:00
//$2133 SETINI
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
bool extbg;
bool pseudoHires;
Update to v098r02 release. byuu says: Changelog: - SFC: fixed a regression on auto joypad polling due to missing parentheses - SFC: exported new PPU::vdisp() const -> uint; function [1] - SFC: merged PPU MMIO functions into the read/write handles (as I previously did for the CPU) - higan: removed individual emulator core names (bnes, bsnes, bgb, bgba, bws) [2] Forgot: - to remove /tomoko from the about dialog [1] note that technically I was relying on the cached, per-frame overscan setting when the CPU and light guns were polling the number of active display scanlines per frame. This was technically incorrect as you can change this value mid-frame and it'll kick in. I've never seen any game toggle overscan every frame, we only know about this because anomie tested this a long time ago. So, nothing should break, but ... you know how the SNES is. You can't even look at the code without something breaking, so I figured I'd mention it >_> [2] I'll probably keep referring to the SNES core as bsnes anyway. I don't mind if you guys use the b<system> names as shorthand. The simplification is mostly to make the branding easier.
2016-04-09 05:20:41 +00:00
bool overscan;
bool interlace;
//$213c OPHCT
uint16 hcounter;
//$213d OPVCT
uint16 vcounter;
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.
2016-07-01 11:50:32 +00:00
} io;
Update to v098r02 release. byuu says: Changelog: - SFC: fixed a regression on auto joypad polling due to missing parentheses - SFC: exported new PPU::vdisp() const -> uint; function [1] - SFC: merged PPU MMIO functions into the read/write handles (as I previously did for the CPU) - higan: removed individual emulator core names (bnes, bsnes, bgb, bgba, bws) [2] Forgot: - to remove /tomoko from the about dialog [1] note that technically I was relying on the cached, per-frame overscan setting when the CPU and light guns were polling the number of active display scanlines per frame. This was technically incorrect as you can change this value mid-frame and it'll kick in. I've never seen any game toggle overscan every frame, we only know about this because anomie tested this a long time ago. So, nothing should break, but ... you know how the SNES is. You can't even look at the code without something breaking, so I figured I'd mention it >_> [2] I'll probably keep referring to the SNES core as bsnes anyway. I don't mind if you guys use the b<system> names as shorthand. The simplification is mostly to make the branding easier.
2016-04-09 05:20:41 +00:00
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
#include "background/background.hpp"
Update to v099r02 release. byuu says: Changelog: - renamed sfc/ppu/sprite (OAM oam;) to sfc/ppu/object (Object obj;) [hex_usr] - renamed sfc/ppu's memory {vram, oam, cgram} to just vram, oam, cgram - fixed addr&=~1 regression [hex_usr] - fixed 8bpp tiledata regression [hex_usr]
2016-06-15 11:32:17 +00:00
#include "object/object.hpp"
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
#include "window/window.hpp"
Update to v099r02 release. byuu says: Changelog: - renamed sfc/ppu/sprite (OAM oam;) to sfc/ppu/object (Object obj;) [hex_usr] - renamed sfc/ppu's memory {vram, oam, cgram} to just vram, oam, cgram - fixed addr&=~1 regression [hex_usr] - fixed 8bpp tiledata regression [hex_usr]
2016-06-15 11:32:17 +00:00
#include "screen/screen.hpp"
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Background bg1;
Background bg2;
Background bg3;
Background bg4;
Update to v099r02 release. byuu says: Changelog: - renamed sfc/ppu/sprite (OAM oam;) to sfc/ppu/object (Object obj;) [hex_usr] - renamed sfc/ppu's memory {vram, oam, cgram} to just vram, oam, cgram - fixed addr&=~1 regression [hex_usr] - fixed 8bpp tiledata regression [hex_usr]
2016-06-15 11:32:17 +00:00
Object obj;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Window window;
Screen screen;
Update to 20100809 release. byuu says: This adds some sync.sh improvements to make it handle errors more gracefully. It also updates asnes a good bit. All of the four base processors now have all publicly accessible functions right at the top of the main headers, and everything else is private. This is to allow these headers to essentially take the place of the previous base classes in the old bsnes-merged format. So if there's something public there, you need to implement that exact function to make your own module. I removed the frame counter from the PPU, as it has nothing to do with emulation. That now resides inside the Qt -> SNES interface code. Quite amazing, I was actually saving the frame counter into the save state files before, yuck. Removed some baggage in the System class: it was friending a bunch of long-dead functions and classes. Forgot to re-add the CHEAT_SYSTEM define to info.hpp, so that's been put back.
2010-08-09 13:33:44 +00:00
friend class PPU::Background;
Update to v099r02 release. byuu says: Changelog: - renamed sfc/ppu/sprite (OAM oam;) to sfc/ppu/object (Object obj;) [hex_usr] - renamed sfc/ppu's memory {vram, oam, cgram} to just vram, oam, cgram - fixed addr&=~1 regression [hex_usr] - fixed 8bpp tiledata regression [hex_usr]
2016-06-15 11:32:17 +00:00
friend class PPU::Object;
Update to 20100809 release. byuu says: This adds some sync.sh improvements to make it handle errors more gracefully. It also updates asnes a good bit. All of the four base processors now have all publicly accessible functions right at the top of the main headers, and everything else is private. This is to allow these headers to essentially take the place of the previous base classes in the old bsnes-merged format. So if there's something public there, you need to implement that exact function to make your own module. I removed the frame counter from the PPU, as it has nothing to do with emulation. That now resides inside the Qt -> SNES interface code. Quite amazing, I was actually saving the frame counter into the save state files before, yuck. Removed some baggage in the System class: it was friending a bunch of long-dead functions and classes. Forgot to re-add the CHEAT_SYSTEM define to info.hpp, so that's been put back.
2010-08-09 13:33:44 +00:00
friend class PPU::Window;
friend class PPU::Screen;
Update to v100r03 release. byuu says: Changelog: - moved Thread, Scheduler, Cheat functionality into emulator/ for all cores - start of actual Mega Drive emulation (two 68K instructions) I'm going to be rather terse on MD emulation, as it's too early for any meaningful dialogue here.
2016-07-10 05:28:26 +00:00
friend class System;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
};
Update to v085r03 release. byuu says: Changelog: - fixed cursor being visible under Metacity window manager (hopefully doesn't cause regression with other WMs) - show normal cursor when using SDL video driver - added menu accelerators (meh, why not?) - removed debugvirtual, ChipDebugger and chip/debugger functionality entirely - alt/smp disassembler moved up - fixed alt/smp incw/decw instructions (unsigned->uint16 for internal variables) My plan going forward for a debugger is not to hardcode functionality that causes the 10-15% slowdown right into the emulator itself. Instead, I'm going to make a callback class, which will be a specialized version of nall::function: - can call function even if not assigned (results in no-op, return type must have a trivial default constructor) - if compiled without #define DEBUGGER, the entire thing turns into a huge no-op; and will be eliminated entirely when compiled - strategically place the functions: cb_step, cb_read, cb_write, etc. From here, the ui-debugger GUI will bind the callbacks, implement breakpoint checking, usage table generation, etc itself. I'll probably have to add some breakout commands to exit the emulation core prior to a frame event in some cases as well. I didn't initially want any debugger-related stuff in the base cores, but the #if debugger sCPUDebugger #else sCPU #endif stuff was already more of a burden than this will be.
2012-02-04 09:23:53 +00:00
extern PPU ppu;