mirror of https://github.com/bsnes-emu/bsnes.git
15 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
byuu
|
a266a2b5e2 |
Update to bsnes v066 release.
Major features in this release are: serial controller emulation, a brand new scheduler that supports multiple simultaneous coprocessors, and accuracy improvements. The serial controller is something devised by blargg. With the proper voltage adjustments (5v-9v), it is possible to wire an SNES controller to a serial port, which can then be used for bidirectional communication between the SNES, and (usually, but not only) a PC. The support in bsnes was added so that such programs could be debugged and ran from within an emulator, and not just on real hardware. The scheduler rewrite was meant to allow the combination of coprocessors. It was specifically meant to allow the serial controller thread to run alongside the SuperFX and SA-1 coprocessor threads, but it also allows fun things like MSU1 support in SuperFX and SA-1 games, and even creating dev cartridges that utilize both the SuperFX and SA-1 at the same time. The one thing not yet allowed is running multiple instances of the exact same coprocessor at the same time, as this is due to design constraints favoring code inlining. There are two important accuracy updates. The first is that when PAL video mode is used without being in overscan mode, black bars are shown. Emulators have always shown this black bar at the bottom of the screen, but this is actually incorrect. resxto took pictures from his PAL TV that shows the image is in fact vertically centered in the screen. bsnes has been updated to reflect this. Also interesting is that I have backported some code from the dot-based PPU renderer. In the game Uniracers, it writes to OAM during Hblank, and expects the write to go to a specific address. In previous releases, that address was hard-coded to go to the required memory location. But the way the hardware really works is that the write goes to the extended attribute address for the last sprite that the PPU fetched, as the PPU is still asserting the OAM address bus. Now, due to the precision limitations, I was not able to also port timing access during the active display period. However, this is sufficient to at least remove the last global hack from the older, speed-focused scanline renderer. |
|
|
byuu
|
79f20030a0 |
Update to bsnes v065r01 release.
In order to fully decode the 16MB address maps, I am going to need to
use blargg's stop-and-swap, which will require a serial-communications
program. To develop this program, and others in the future, as well as
for testing automation, it would be very beneficial to have a way to
debug these programs through bsnes.
So what I'm working on now is emulating a serial port inside bsnes.
The basic premise is to start with a custom XML map that specifies its
presence:
<?xml version="1.0" encoding="UTF-8"?>
<cartridge region="NTSC">
<rom>
<map mode="linear" address="00-7f:8000-ffff"/>
<map mode="linear" address="80-ff:8000-ffff"/>
</rom>
<ram size="2000">
<map mode="linear" address="70-7f:0000-7fff"/>
</ram>
<serial baud="57600">
</serial>
</cartridge>
I am essentially treating the serial communication as a special chip.
One could argue this belongs as an option under controllers, and one
would be right. But as I can't have two coprocessor threads at the
same time, this is how it is for right now. Eventually it'll probably
be under controller port 2, and only enabled in the debugger builds.
So, this pseudo-coprocessor ... it's basically emulating the PC-side
communications program.
Meaning I still need to externalize this somehow so that any program
can be run.
The below program writes 0x96 six times, and then reads in data six
times. Well, technically forever, but the SNES ROM only writes six
times at the end.
void Serial::enter() {
scheduler.clock.cop_freq = cartridge.serial_baud_rate() * 2;
latch = 0;
add_clocks(512);
for(unsigned i = 0; i < 6; i++) {
latch = 1; add_clocks(2);
latch = 1; add_clocks(2);
latch = 0; add_clocks(2);
latch = 0; add_clocks(2);
latch = 1; add_clocks(2);
latch = 0; add_clocks(2);
latch = 1; add_clocks(2);
latch = 1; add_clocks(2);
latch = 0; add_clocks(2);
latch = 0; add_clocks(2);
}
while(true) {
while(cpu.joylatch() == 0) add_clocks(1);
while(cpu.joylatch() == 1) add_clocks(1);
add_clocks(1);
uint8 data = 0;
for(unsigned i = 0; i < 8; i++) {
add_clocks(2);
data = (data << 1) | cpu.joylatch();
}
print("Read ", strhex<2>(data), "\n");
}
}
The SNES code looks like this:
//21,477,272hz cpu / 57,600hz serial = ~372.87 clocks/tick
org $8000
xce; rep #$10
ldx #$01ff; txs
jsr serial_read; sta $700000
jsr serial_read; sta $700001
jsr serial_read; sta $700002
jsr serial_read; sta $700003
jsr serial_read; sta $700004
jsr serial_read; sta $700005
nop #46
jsr serial_write
jsr serial_write
jsr serial_write
jsr serial_write
jsr serial_write
jsr serial_write
//hang
-; bra -
serial_read:
-; lda $4017; and #$01; bne -
-; lda $4017; and #$01; beq -
nop #23; lda $00; nop #10
lda $4017; and #$01; asl $00; ora $00; sta $00; lda $00; nop #13
lda $4017; and #$01; asl $00; ora $00; sta $00; lda $00; nop #13
lda $4017; and #$01; asl $00; ora $00; sta $00; lda $00; nop #13
lda $4017; and #$01; asl $00; ora $00; sta $00; lda $00; nop #13
lda $4017; and #$01; asl $00; ora $00; sta $00; lda $00; nop #13
lda $4017; and #$01; asl $00; ora $00; sta $00; lda $00; nop #13
lda $4017; and #$01; asl $00; ora $00; sta $00; lda $00; nop #13
lda $4017; and #$01; asl $00; ora $00; sta $00; lda $00; nop #13
rts
serial_write:
lda #$01; sta $4016; nop #23
lda #$00; sta $4016; nop #23
lda #$01; sta $4016; nop #23
lda #$00; sta $4016; nop #23
lda #$00; sta $4016; nop #23
lda #$01; sta $4016; nop #23
lda #$00; sta $4016; nop #23
lda #$01; sta $4016; nop #23
lda #$01; sta $4016; nop #23
lda #$00; sta $4016; nop #23
lda #$01; sta $4016; nop #23
rts
That reads six times, and then writes six times.
I haven't made the test do an infinite PC->SNES transfer, but I have
for SNES->PC. No errors after millions of bytes, even if I stride the
CPU timing.
As this is just an example, it's pretty lousy with actual timing, but
I guess that's a good thing as it still works quite well. More
tolerance = less potential for errors.
**Now, this part is important.**
While debugging this, I noticed that my serial coprocessor was only
running when Vcounter=n,Hcounter=0. In other words, nothing was making
the CPU synchronize back to the coprocessor, except the once-per-
scanline synchronization that was there in case of CPU stalls.
That's ... really bad. MSU1 worked only because it buffers a few
hundred samples for audio mixing. I don't really know why this didn't
cause an issue for SuperFX, SA-1 or Super Game Boy games; but in
theory they were at most 682x less precise than they should have been
in terms of CPU->coprocessor synchronization.
Making it sync after every add_clocks() call results in a 10% speed
hit to SuperFX, SA-1 and Super Game Boy emulation, unfortunately.
I don't notice any quality improvements in emulation, but in theory
the lack of this syncing before effectively eliminated the benefits of
the SuperFX and SA-1 being cycle based.
I'm going to have to look into this more to understand if I was
intentionally not doing this sync before, or if I really did forget
it. I'm thinking it was an oversight right now. The SuperFX and SA-1
don't really talk back and forth a whole hell of a lot, so once a
scanline probably wouldn't be that noticeable.
But holy hell ... now that I'm thinking about it, I wonder if this was
the cause of all that craziness in trying to sync up the Super Game
Boy's VRAM transfers. Yeah, definitely need to look into this more ...
|
|
|
byuu
|
79b939e1c7 |
Update to bsnes v065 release.
It's been a while, so here is a new release of bsnes. Unfortunately I don't have a full changelog this time. Most of the work went into stabilizing libsnes (which is used by the experimental .NET, Cocoa and Python UIs; as well as by Richard Bannister's OS X port). The Windows binary package now comes with all three variants included: bsnes.exe, the standard version that casual users should run; bsnes-debugger.exe, for SNES programmers and ROM hackers only; and bsnes-accurate.exe, which should not be used by anybody, ever. In all seriousness, bsnes-accurate.exe is bsnes with the dot-based S-PPU renderer. It's twice as slow as the normal build, and you won't really notice any differences except in Air Strike Patrol. It's there for the curious and for any SNES programmers who want to try making some really awesome video demos. Changelog: * OS X port builds once again; now requires gcc44 from Macports * libsnes API finalized * fixed a bug with S-CPU debugger breakpoints * various source cleanup |
|
|
byuu
|
8b0153daf0 |
Update to bsnes v064r01 release.
Adds bool snes_get_region(void) to libsnes (permanent). Adds snes_blit_colortable and snes_blit to libsnes (temporary). Adds src/ui_python with a basic Python GUI, and abstraction between the libsnes wrapper and PyGTK (so it can be reused for PyQt, etc.) The GUI has: - menubar - video output (2x scale, supports NTSC/PAL, hires, overscan and interlace correctly) - audio output (libao through ALSA) - input (very lousy key press events, they toggle off and on if you hold a key down ...) I'm getting full-speed, so that's good. Not sure where I want to take all of this stuff yet, but it's kind of neat for now I suppose. It would be kinda fun to go really out there with completely new GUI design styles that aren't just your standard menubar+video. Things like a toolbar, mouse gestures, really deep platform integration, AVI-based recording, frame analysis shit, game- specific GUI shit (perhaps map touch-screen input + gyroscope on top of a simulated gamepad; or perhaps read the contents of RAM and provide statistical information on the sides of the video output screen?), I dunno ... whatever. It's there, it's possible, but it's certainly not good enough to replace the official C++ Qt port, and I don't really have the time or patience to make it that good myself. |
|
|
byuu
|
9ca1e259cb |
Update to bsnes v064 release.
A thank you to everyone who helped test the RC to ensure stability. I've uploaded the official v064 release to Google Code. The most important change in this release is the cycle-based PPU renderer; but due to performance reasons the scanline-based renderer remains the default in the Windows binary. If you want to try out the cycle-based renderer, you will need to compile from source for now. Another major change is the introduction of libsnes, which allows one to build bsnes as a shared library that can be used from other programming languages. It is intended both to create a regression testing framework, and to provide API stability for the various projects that use the bsnes core. While I can't guarantee the API to libsnes won't change, I will properly revision it and do everything I can to avoid changing it if possible. |
|
|
byuu
|
43a3991ddf |
Update to bsnes v063r01 release.
I've had enough of idiots incapable of finding fullscreen settings. The menubar is enabled in fullscreen mode by default. A new option in settings->configuration->video will let you hide it as with v063 official. I don't want to hear about how I shouldn't allow any settings to be configured differently in fullscreen mode, or how it should be in a GUI panel, or whatever. I will ignore you if you bring it up. I've also added the strpos / qstrpos function->class code, as mentioned in the programming section. |
|
|
byuu
|
27c24bc8a6 |
Update to bsnes v063 release.
Time for another (hopefully) stable release. The changelog has all updates since the last stable release.
Most notably, this release features substantial accuracy improvements all around. Almost all of them represent brand new findings never before seen in any SNES emulator.
Changelog:
- fixed off-by-one buffer size issue in S-PPU RTO calculations [PiCiJi]
- added XML parser
- added XML-based memory mapping system
- moved header-based memory mapping code into snesreader library
- added some linker flags for Fedora [belegdol]
- added cheat code database; with codes for over 1,500 games [mightymo]
- fixed a bug where S-CPU IRQs were being tested one cycle early on direct page indexed read opcodes
- added global cheat system enable/disable checkbox to cheat code editor
- fixed bug in overflow calculation of S-CPU ADC and SBC opcodes in BCD mode [blargg]
- emulated the S-CPU ALU MUL and DIV hardware delays with partial result calculation steps [blargg]
- controller port read now returns real-time results of B button when strobe latch is raised
- major improvements to emulation of the S-SMP TEST register [blargg, byuu]
- fixed DSP2 memory map [Overload]
- "Apply Patch" checkbox will now scan UPS patch folder if one is set in the paths section
- fixed S-CPU TSC negative flag calculation in emulation mode [address]
- added "make uninstall" command to Makefile for Linux users
- S-CPU (H)DMA now updates the S-CPU MDR; fixes a freeze in Speedy Gonzales - Stage 6-1
- very substantial code cleanups and optimizations as a result of moving from C++98 to C++0x
|
|
|
byuu
|
f94fcd6f30 |
Update to bsnes v062r05 release.
To run this, you'll need the DLLs from v062r04's public beta, and the updated snesreader.dll in the same folder as the WIP. No profiling. This fixes UPS patching, and it also modifies snesreader to generate the XML map separately, so that the map can be generated post- patching. The new enum classes weren't attaching properly to the config file, so the input settings, expansion port and region settings are saved again. It also converts the S-SMP timers back to unsigned integers instead of using floating point, no accuracy improvement but much more in line with hardware. Lastly, it makes the div register shift left 16 places and pre-shifts on divide, which is just for aesthetics. And I'll wait on your tests, FitzRoy. I really hope that Big Run Jaleco Rally is correct, because I don't have the first idea how to debug that one. Speedy I can probably handle. |
|
|
byuu
|
57f903630a |
Update to bsnes v062r04 release.
I suppose I should start calling these nightlies, heh. blargg went ahead and verified every last possible edge case with regards to the S-CPU MUL / DIV registers. It uncovered a few errors in my implementation, which have since been corrected. The design used now should be a direct reflection of the hardware implementation: no actual multiplication, no actual division, and no variable-length bit-shifting. We also spent about eight hours straight hammering away at the S-SMP test register. We have a partial understanding of TEST.d3 and TEST.d0, and a complete understanding of the other six bits. All of this has been implemented as well. Lastly, snesreader gets a tiny update to fix Test Drive II, which broke due to a slight regression when porting the mapping code to XML. |
|
|
byuu
|
9329de0a8d |
Update to bsnes v062r03 release.
blargg and I sat around for a good 8+ hours today hacking away at the S-SMP Pandora's Box: the TEST register. What better way to spend Pi Day, right? We came up with the following tests: http://byuusan.kuro-hitsuji.net/blargg_2010-03-14.zip First, controller_strobebehavior.smc improves emulation of $4016. When the joypad strobe latch = 1, reading $4016 returns the current value of the B button. As in, you can keep reading it over and over. It won't increment the shift register, and it will keep telling you the actual current state of the button. This is very much like the NES behavior. One more TODO in the S-CPU code taken care of. Next, all kinds of S-SMP TEST register improvements. Turns out d7-d6 alone controls the actual S-SMP clock rate. 0 = 100%, 1 = 50%, 2 = 0% (locks the S-SMP forever), 3 = 10%. Wild stuff, you can actually permanently slow the S-SMP relative to the S-CPU. d6-d5 is a timer tick control, but it actually uses d7-d4 overlaid. The algorithm is fucking nuts, and is really my only contribution to today's work. The rest was all blargg's research. We had d2 wrong, it's not MMIO disable, it's RAM disable. As in, disable read and write. Returns 0x5a on regular SNES, 0xff on mini- SNES. 0x5a is not the S-SMP MDR. IPLROM is still readable when RAM is disabled. d1 was correct, just RAM write disable. Can still write to $f8 and $f9, of course. But it won't go through to RAM. d3 and d0, we are still a little unsure on. The T0-T2 timers seem to have a low and high phase, and if you strobe them you can force ticks of stage 2 to happen, and you can disable them in such a manner than stage 2 never ticks at all. blargg is still uncovering all sorts of crazy things in $xB mode, so emulation of these two bits is not perfect. But overall we are leaps and bounds further now toward complete emulation. I'd say we went from 10% to 80% with today's work. But we'll have to see how deep the rabbit hole goes on d3+d0 first. Current register map: case 0xf0: { //TEST if(regs.p.p) break; //writes only valid when P flag is clear status.clock_speed = (data >> 6) & 3; //100%, 50%, 0%, 10% status.timer_speed = (data >> 4) & 3; //100%, ... status.timers_enabled = data & 0x08; status.ram_disabled = data & 0x04; status.ram_writable = data & 0x02; status.timers_disabled = data & 0x01; unsigned base = 1 + (1 << status.clock_speed); unsigned step = base + (15 >> (3 - status.timer_speed)); status.timer_step = 1.0 / (3.0 / step); t0.sync_stage1(); t1.sync_stage1(); t2.sync_stage1(); } break; Fairly confident that no emulator prior to this WIP could pass any of blargg's tests, so this is all brand new information. Fun stuff :) |
|
|
byuu
|
989648c21c |
Update to bsnes v062 release.
Major accuracy improvements have happened over the past few days. They easily warrant a new beta release. First, it turns out that every emulator to date; not only for the SNES, but for the Apple II GS as well, incorrectly computed ADC (add) and SBC (subtract) flags in BCD (binary-coded decimal) mode. At least fifteen years of emulating the 65816 processor, at least five known investigations into their behavior, and we all still had it wrong. So I wrote some tests that dumped every possible combination of adc and sbc with every possible input and every possible flag, and recorded both the accumulator result and status flag register. From here, blargg figured out the underlying trick: the CPU was computing overflow before the top-nibble's BCD correction pass. With the routines rewritten, bsnes perfectly matches real hardware now. Next, some background. The whole reason I got into SNES emulation was because I was tired of writing code that ran perfectly fine on emulators, but failed miserably on real hardware. The number one problem was emulators allowing video RAM to be written while the screen was being rendered. This single bug has broken dozens of fan translations and ROM hacks. Some have been updated to work around this bug, and many others are left in a permanently broken state (such as the translations of Dragon Quest I & II and Sailor Moon: Another Story, to name just two.) After asking emulator authors to fix this since 1997, I finally had enough in 2004 and started on bsnes. For this particular bug, I'm very happy to report that all but one SNES emulator now properly blocks these invalid accesses. Although sadly one still offers a configuration setting for backwards compatibility with these translations. What an ironic shame ... emulating an emulator. And in the process, sapping the motivation to ever go back and fix these titles to ever run on real hardware. But I digress ... The second biggest problem that causes software created under emulation to break on real hardware has, without a doubt, been the hardware delays as the S-CPU computes MUL (multiplication) and DIV (division) results. To date, whenever you used this hardware functionality, emulators have immmediately furnished the correct results. But on real hardware, multiplication requires eight CPU cycles, and division requires sixteen. Each step computes one bit of the source operand and updates the results. Reading the output registers early thus provides the partially computed results. This is obscure. It isn't well known, and many people writing software for the SNES probably aren't even aware of this limitation. Because of the partial computation results, outright delaying the computation would break many commercial software titles. But by not emulating the delay at all, we were causing a great disservice to anyone wishing to use an emulator for development purposes. Now, once again, thanks to blargg's algorithm help, he has determined the underlying multiplication and division algorithms. Combined with my expertise of SNES analysis and hardware testing, I was able to determine when and how the ALU (arithmetic logic unit) stepped through each work cycle. Our work combined, bsnes now also perfectly emulates the hardware MUL and DIV delays. Again, this isn't going to fix commercial software titles. They would have realized that they were reading back invalid MUL and DIV values, and fixed their code. This is for all of the software developed using emulators. This is an extension of my commitment to create a hardware emulator, and not a video game emulator. We also verified that the S-PPU multiplication interface does indeed return instant results with no delay. So emulation of that interface was already correct. I'm only labelling this release a beta because it hasn't been tested. But I'm fairly confident that it is stable, and I seriously recommend upgrading from v060 or prior releases. This is easily one of the last major pieces missing from emulation. The last notable elements are: S-CPU auto joypad poll timing, S-CPUr1 HDMA crash detection, S-CPU<>S-SMP port ORing, S-SMP timer glitching, S-DSP mute pulse, and full cycle-level emulation of the S-PPU. With all of the aforementioned items, I will consider a v1.0 release of bsnes ;) Lastly, I'll post this screenshot just for fun. When d4s translated Breath of Fire II to German, he added some code that relies on the incorrect emulation of the DIV register to detect emulators. With this emulated properly, you now see the following screen: ./sshots/bs_349.png Sorry to spoil that, but the secret's already out, as the MESS team reported on it publicly already. I intend to add pseudo-randomness support shortly, which should eliminate one of the last vectors possible to distinguish bsnes from real hardware :) A million thanks to blargg for making this release possible. |
|
|
byuu
|
78e1a5b067 |
Update to bsnes v061r02 release.
Complete rewrite of adc + sbc opcodes, should fix: - adc BCD overflow flag - sbc BCD overflow flag - sbc BCD invalid input value Testing is appreciated, I believe Sim Earth is probably the most likely to observe any difference. |
|
|
byuu
|
46a1eb8cce |
Update to bsnes v059r06 release.
This is an experimental release, as such it is posted only to Google Code.
Changelog:
- 21fx API moved to pre-finalized form as S-MSU1; more about this on the forum
- OpenGL driver now uses GL_CLAMP_TO_BORDER instead of GL_CLAMP_TO_EDGE to support screen curvature shader
- rewrote file open dialog; code is greatly simplified, interface is improved
- all cheat code columns are now enquoted, and empty codes at the bottom of the file are omitted (format is compatible with previous releases still)
- debugger: added missing DMA variables to S-CPU properties viewer
- snesfilter: added OpenMP (multi-threading) support to HQ2x filter
- lots of other miscellaneous code cleanup work
|
|
|
byuu
|
b538c13aad |
Update to bsnes v059r04 release.
Eight hours of non-stop work, for the sole purpose of trying to separate the file browser underlying mechanics from the bsnes-specific stuff. So far, it's going quite well. 95% of the functionality is there with only 25% of the code size. Forked the underlying stuff to nall/qt/file-dialog.moc.hpp, which is now designed to support open+save+folder selection natively. Save mode adds a text box to enter your own file name, and folder mode hides the filter drop-down and all files automatically. The top bar now spans 100% of the width. I like it more this way. I also killed the tree view in favor of a list view, for the sole reason that I really can't stand how when you go up a folder and the deeper tree is still open. Since the QFileSystemModel is asynchronous, I can't close the tree nodes when navigating up. The simplifications were needed because it was getting damned-near impossible to edit that mess of a file (diskbrowser.cpp.) Compare to filebrowser.cpp, much cleaner. Now I should be able to add open-folder concept for BS-X, ST and SGB games much easier. And of course, I should be able to offer the base QFileDialog as an option, too. After that, I'll probably export the hex editor to a generic class, and then export the Qb stuff (window geometry save/restore, stock check / radio menu buttons.) Also, I just wiped out Windows XP and put Windows 7 back, just to fix the video tearing issue relating to DWM and ... it works perfectly fine. Zero tearing, zero skipping, zero audio popping. All I did was start bsnes v059.04, set audio sync to the usual 31960, and it was just fine. What the hell are people complaining about, exactly? |
|
|
byuu
|
1d5e09ef07 |
Update to bsnes v059r02 release.
Changelog:
- added folder-up button to the file loading window
- hid new-folder button except on path selection window
- removed "Assign Modifiers as Keys" button; replaced with input.modifierEnable in the configuration file
- fixed a Qt signal issue that was causing ROM loading to take an extra second or two longer than necessary
- scale 5x setting will now maintain an exact multiple in both width and height for both NTSC and PAL modes
- re-added group assignment and unassignment to the input settings window
- re-wrote mouse capture code to be more intuitive, now uses buttons to set assignment
- re-added input.allowInvalidInput check to stop up+down and left+right key combinations by default [Jonas Quinn]
- split "Tools Dialog" menu option into separate items for each tool (Cheat Editor, Cheat Finder, State Manager)
- added S-SMP and S-DSP property information readouts to the debugger
|