2012-08-10 - bsnes_v091-source.tar.xz
A few issues crept up in the last release, this should take care of them.
First, it seems that the 32-bit runtime on 64-bit versions of Windows have 64-bit time functions; whereas true 32-bit Windows does not. This was causing a DLL error when attempting to load bsnes v090.
Second, when there were more than 2,000 files in the same folder on Windows, it was lagging the file browser. With OV2's help, I've fixed that and it'll now load the list instantly.
Lastly, I've included the missing video shaders this time.
2012-08-07 - bsnes_v090-source.tar.xz
Most notably, this release adds Nintendo DS emulation. The Nintendo DS module was written entirely by Cydrak, so please give him all of the credit for it. I for one am extremely grateful to be allowed to use his module in bsnes.
The Nintendo DS emulator's standalone name is dasShiny. You will need the Nintendo DS firmware, which I cannot provide, in order to use it. It also cannot (currently?) detect the save type used by NDS games. As such, manifest.xml files must be created manually for this purpose. The long-term plan is to create a database of save types for each game. Also, you will need an analog input device for the touch screen for now (joypad axes work well.)
There have also been a lot of changes from my end: a unified manifest.xml format across all systems, major improvements to SPC7110 emulation, enhancements to RTC emulation, MSU1 enhancements, icons in the file browser list, improvements to SNES coprocessor memory mapping, cleanups and improvements in the libraries used to build bsnes, etc.
I've also included kaijuu (which allows launching game folders directly with bsnes) and purify (which allows opening images that are compressed, have copier headers, and have wrong extensions); both of which are fully GUI-based.
This release only loads game folders, not files. Use purify to load ROM files in bsnes.
Note that this will likely be the last release for a long time, and that I will probably rename the emulator for the next release, due to how many additional systems it now supports.
2012-08-06 - bsnes_v089r18.tar.bz2
Changelog:
fixed bsnes to let config files and system folders to be in the same folder as the executable
fixed RawInput driver to compile again without linear_vector
fixed phoenix/Windows to compile again without linear_vector
fixed old vs new name warnings on MinGW w64 (technically the warnings were erroneous, but I worked around them anyway)
restored WRAM randomization for v090 stability (we can discuss that idea for v091+)
fixed SuperFX / SA-1 "0x" prefix in the header generation (drop it into the latest purify if you want)
added nall/Makefile uname support for UnxUtils (was breaking compilation with full UnxUtils in your path otherwise)
Won't fix issues:
Windows doesn't like too many files in the same folder?
something about input?, I don't know
Please test as thoroughly as you can. I'd like to release v090 soon.
2012-07-15 - bsnes_v089r17.tar.bz2
purify_v00r06.tar.xz (no Windows binary, you have to compile it yourself)
This implements the spec from the XML part 3 thread (http://board.byuu.org/viewtopic.php?f=16&t=2998)
It's also propagated the changes to nall and purify, so you can test this one.
This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format.
The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions.
And of course, I'm giving it a bit of time for good arguments against the format.
Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector.
vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy.
This works really nicely with the move for read() functions to return vector instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-10 - bsnes_v089r16.tar.bz2
Changelog:
eliminated , tags [they are merged to their parent nodes now]
added <ram name= size=> tag to EpsonRTC, SharpRTC
added tag to DSP-n, ST-01n, ST-018, Cx4
interface->path(0) now returns the system folder, which can be used for storage now
as a fun proof-of-concept, I've simulated SNES warm power cycles by saving and loading work RAM (same effect if you instantly swapped carts)
long-term, I'm not sure how I want to do this. The power menu option makes no sense with warm RAM
I like the idea of decaying RAM based on timestamp from last play; and power can just force the timestamp to 0 (which will corrupt all RAM)
Interface::firmware is gone. The cores now load firmware inside their boot up routines
you now get a message on the screen if the emulator can't find firmware, should help with "I just get a black screen" messages
I'd like to start preparing for a v090 release. I think we're almost there now. Have to update nall/cartridge and purify to handle XML changes first.
2012-07-09 - bsnes_v089r15.tar.bz2
Changelog:
SuperFX has its own ROM and RAM
Cx4 has its own ROM
SPC7110 has its own ProgramROM, DataROM and RAM
OBC1 has its own RAM
BsxCartridge has its own ROM, RAM and PSRAM
mapping changes to accommodate the above
2012-07-08 - bsnes_v089r14.tar.bz2
Changelog:
NSS emulation improvement (DIP is 8-bits, not 16-bits; can be remapped via XML now like all the other chips)
SA-1 memory map improvements (IRAM and BWRAM can be saved; ROM, IRAM and BWRAM are separate from Cartridge::ROM, RAM; no MCU)
S-DD1 memory map improvements (ROM, RAM inside mapping; no MCU)
SPC7110 memory map improvements (ROM, RAM inside mapping; no MCU; not finished yet [have to handle 8mbit expansion somehow now)
ActRaiser (NSS):
Code:
<?xml version="1.0" encoding="UTF-8"?>
Star Ocean (SDD1):
Code:
<?xml version="1.0" encoding="UTF-8"?>
(The S-DD1 is the memory mapper; so even though RAM is mapped constantly, it is still behind the S-DD1 on the board.)
Kirby's Dreamland 3 (SA1):
Code:
<?xml version="1.0" encoding="UTF-8"?>
Far East of Eden Zero (SPC7110): [incomplete]
Code:
<?xml version="1.0" encoding="UTF-8"?>
I have tried multiple times now to get the SuperFX core to use internal ROM and RAM (separate from Cartridge::ROM, RAM) to no avail.
Not sure what the hell is going on there. Trace logs of 430MB are not enticing ...
So right now: SuperFX, SPC7110 and BS-X cheat by mapping stuff to Cartridge::ROM, RAM still. They need to not do that.
2012-06-25 - bsnes_v089r13.tar.bz2
Fixes up loading issues with recent purify changes, and purify also works on BS/ST file types now and should be a bit more crash-resistant.
2012-06-17 - bsnes_v089r12.tar.bz2
Changelog:
Game Boy XML uses instead of
if you run bsnes with a filename argument, it will invoke "purify filename" and exit immediately
* this chains: purify will turn the file into a game folder, and then invoke bsnes with the game folder name
*** net result: you can drag a ZIP file onto bsnes or associate SMC headered ROMs with bsnes and they'll just work
new nall: unified usage of - vs _ vs nothing on filenames; fancier lstring; fancier image (constructor for creating from filename or from memory); etc
new phoenix: images in ListView, GTK+ merges the check box into the first column like the other targets do, etc
browser list now uses icons to differentiate system folders from game folders (the game folder icon sucks, I'm open to suggestions though, as long as it's available on Debian Squeeze in /usr/share/icons, no custom stuff please)
2012-06-05 - bsnes_v089r11.tar.bz2
Changelog:
SPC7110 $480b (and its settings in $4805-6 + $4807) is now fully emulated
decompressor restructured and commented accordingly
The final parts remaining for the SPC7110 core, all within the decompression engine:
need to detect when 15+ input bytes are read for one output byte and simulate a crash somehow (don't have to perfectly simulate corrupted data stream)
need to emulate time required to decompress data (doesn't have to be perfect, just something other than instantaneous)
need to determine what $480c status flags d6-d0 are for, as best we can anyway
2012-05-30 - bsnes_v089r10.tar.bz2
Changelog:
Cydrak merged all three SPC7110 decompression routines into one, cuts the size in half
fixed masking of $4803.d7 and $4813.d7
data port out of bounds accesses emulated correctly for app SPC7110 boards
all(?) data port $4810 reload cases now supported
basic timing for $4805-6 seeking; reworked delay timing to work better as well
fixed $480c.d7 flag (1 = ready, not busy)
AbsoluteInput returns -32768 if presentation window lacks focus and you don't always allow input
I need to rethink how to emulate $4805-6 + $4807 at the same time. I understand how they both work in isolation, but combined it's going to be really tricky.
Then we need to detect the edge case that crashes the real SPC7110 and stop feeding output. Not a perfect simulation but at least catches bad compressed data.
Finally, I need to try and figure out what d6-d0 flags are for in $480c (decompression status register.)
And then we'll call SPC7110 + RTC4513 emulation good enough until after the FEoEZ translation.
We also need to go ahead and finalize the SNES XML markups before v090 as well. This one's not going to be fun at all.
2012-05-28 - bsnes_v089r09.tar.bz2
Changelog:
SPC7110 data port emulation greatly improved
SPC7110 $480b.d1 emulated (but $4805-4806 does not work right for mode 2 decompression yet)
MSU1 will read filenames from manifest now (defaults to msu1.rom and track-#.pcm if missing ... for now)
bugfixes with MSU1 load state and track seek (and $4804 was wrapping into $4805 to change the track#)
Link coprocessor removed (it was meant for ST018 HLE, which never happened)
2012-05-27 - bsnes_v089r08.tar.bz2
Changelog:
Super Game Boy, BS-X Satellaview and Sufami Turbo cartridges all load manifests that specify their file names, and they all work
Sufami Turbo can now properly handle carts without RAM, or empty slots entirely
Emulator::Interface structures no longer specify any file names, ever
exposed "capability.(cheats,states)" now. So far, this just means the GBA doesn't show the cheat editor, since it doesn't support cheat codes yet
as such, state manager and cheat editor windows auto-hide (may be a tiny bit inconvenient, but it makes not having to sync them or deal with input when no cart is loaded easier)
added "AbsoluteInput" type, which returns mouse coordinates from -32767,-32767 (top left) to +32767,+32767 (bottom right) or -32768,-32768 (offscreen)
AbsoluteInput is just something I'm toying with. Idea is to support eg Super Scope or Justifier, or possibly some future Famicom controllers that are absolute-indexed. The coordinates are scaled, so the bigger your window, the more precise they are. But obviously you can't get more precise than the emulated system, so 1x scale will behave the same anyway. I haven't hooked it up yet, need to mess with the idea of custom cursors via phoenix for that first. Also not sure if it will feel smoother or not ... if you resize the window, your mouse will seem to move slower. Still, not having to capture the mouse for SS/JS may be nicer yet. But we'll see ... just experimenting for now.
2012-05-25 - bsnes_v089r07.tar.bz2
Not even purify makes compatible images for this WIP.
Unless you want to figure it out yourself, I'd suggest waiting for an updated tool before using subsequent WIPs.
Changelog:
MSU1 initializes data port + audio track to 0
MSU1 implements audio track error flag on $2000.d3
manifest.xml now controls file names for cartridge folders ... mostly
Regressions:
Super Game Boy support is broken
Sufami Turbo support is broken
So, basically Emulator::Interface() now has:
void load(const string &manifest);
void save();
The first one will analyze the manifest, and call all the ROM + RAM loadRequest() commands necessary to run the game.
The second one will call saveRequest() commands on all writable and non-volatile storage (basically if it's a RAM type and has a filename specified, it gets saved to disk.)
save() shrinks the size of Emulator::Interface() by hiding information one is unlikely to care about. It also makes it much easier to save.
The core auto-calls this when you unload a game as well. So the only time you ever have to worry about it is if you want to save RAM files mid-game (in case you want to do periodic backups in case of a crash.)
BSX only seems to work by some odd fluke, but all of the sub-carts have to be rethought. So that's going to be a pain in the ass for sure.
We also may as well address MSU1 file naming as well.
This change also makes a lot of manifest.xml markup more interesting.
Do we claim BWRAM is the same thing as cartridge RAM? What about SA-1 ROM? Is that the same as cartridge ROM?
Or how about the SPC7110? Do we have a tag, or do we put the ROM names inside +?
I like the idea of having separate files for each tag. But right now, some things end up mapped both inside and outside of special chips, so a lot of work needs to be done to harmonize everything.
2012-05-24 - bsnes_v089r06.tar.bz2
I had some bugs in r07 that I couldn't track down, DKJM2's clock was getting all out of sync.
So I just reverted to r05, blew away both RTCs entirely, and wrote them cleanly from scratch (obviously looking off the old code.) A bit extreme, but it worked.
I believe I found the error in the process, day and month were resetting the counter to 0 instead of 1, it wasn't handling leap year, etc.
While I was at it, I fixed the day-of-week calculation. The SharpRTC epoch is actually 1000-01-01, and not 1900-01-01.
I'm sure you guys will be really happy that if it ever becomes 1000AD again and you're playing a ROM hack that uses the SharpRTC and relies on its weekday value that it will show the correct day now ...
Kind of a pain to compute, but nothing compared to the seventh circle of hell that was my IBM dBase III Julian<>Gregorian conversion functions :/
Also found a few bugs in the Epson code this way. And I moved the round seconds actions and flag clear to +125us after flag set.
So, if you had the old r06 or r07, please delete those.
Unfortunately, this took all of my energy today, so the file names inside manifest changes will have to be in the next WIP.
EDIT: ran a diff against old r07 and new r06.
added if(days == 31) case twice in EpsonRTC::tick_day()
forgot weekday = 0; in SharpRTC::load()
need to move the cartridge+cheat objects up in sfc/Makefile again
System::init() needs assert(interface != nullptr / not 0 /)
2012-05-22 - bsnes_v089r07.tar.bz2
Changelog:
EpsonRTC emulation improved further (stop/pause blocks IRQs, verified secondhi >= 3 triggers 30-second adjust (even on invalid BCD), second-changed flag is mirrored to minute+hour+day+month+weekday, improved busy timing, etc.)
SharpRTC rewritten, works like EpsonRTC now in that it has its own timing thread and ticks with the emulation
won't attempt to read from an unopen file stream now (I think this is what was crashing Sufami Turbo without SRAM?)
added Tools -> Synchronize Time option below load/save state options. Only appears when you play a game with an emulated RTC chip
Just realized that I used 125ms for the 30-second adjust instead of 125us, so I'll fix that in the next WIP.
Aside from that, this is as good as the emulation is going to get. There's still a couple of absolutely psychopathic edge cases that are just too damn difficult to simulate.
So that leaves us with data port control + decompression status registers to investigate before SPC7110 will be finished.
I also still need to redo the BS-X RTC ... I'm not even sure if there is a time-set for it, right now I just return the current system time because of that
And then lastly, there's the Game Boy RTC used by one of the memory mappers. Not sure if there are NES/GBA RTCs or not.
2012-05-21 - bsnes_v089r06.tar.bz2
Changelog:
renamed SRTC -> SharpRTC
renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema)
full emulation of invalid BCD values for EpsonRTC
fixed EpsonRTC IRQ mask
Remaining SPC7110 tasks:
RTC: test 30-second adjust with all values from 00-7f
RTC: hold is supposed to tick the clock one second after being released?
RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly)
Data Port: test $4818 more thoroughly (not too important)
Decompression: test $480c more thoroughly (very important)
Decompression: perform some tests on DMA transferring data, especially with $4807 set
Write-offs, at least for now:
Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data
Decompression: I can find no use of $4808
ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU])
RTC: delay after hold release for $4841 accesses
RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon
RTC: psychotic behavior of reading too early returning port address - 1
2012-05-20 - bsnes_v089r05.tar.bz2
I split the RTC-4513 code from the SPC7110 code (and obviously in the XML mapping as well), since they are separate chips on the FEoEZ PCB.
In this way, you can use just the RTC-4513 in homebrew now if you want. It's a bit nicer than the Sharp RTC from Dai Kaijuu Monogatari II.
This was needed anyway, it has an internal oscillator that's not divisible by the SNES clock used by the SPC7110; and both the RTC and decompression code need to be running their own threads anyway.
In the process, I rewrote the way variables are stored to use named integers rather than a block of memory. Makes the code a lot easier on the eyes, and more importantly, will make emulating bad BCD values a whole lot easier.
cleaned up decompression core (I'd still like to wipe out those static variables, those are bad for save states.)
improved emulation of data port ($481a only increments, never reads)
improved emulation of RTC (block appropriate bits in the hour register based on 12/24h mode select; $4840 modes != 1 all disable the chip; added MDR; etc.)
2012-05-15 - bsnes_v089r03.tar.bz2
Substantial improvements to SPC7110 emulation. Added all of the findings from http://byuu.org/temp/spc7110-mmio.txt that I understood.
I also completely rewrote the RTC. We only had about ~40% of the chip emulated before. Turns out there's cool stuff like spare RAM, calendar disable, 12-hour mode, IRQs, IRQ masking, duty cycles, etc. So I went ahead and emulated all of it. The upper bits on hour+ don't work as nocash described though, not sure what doc he was reading. The Epson RTC-4513 manual I have doesn't explain any of the registers.
The new RTC core also ticks seconds based on the emulated clock, and not on the system clock. This is going to suck for people wanting to keep the in-game clock synced with their computer, who also abuse fast forward and save states. Fast forward makes the clock run faster, and save states will jump the clock to the time it was at when you took the save state. (It will keep track of the number of seconds between unloading the game and loading it again, so time passes normally there.)
This is required, however, and how I'm going to rearrange all of the RTCs for all systems. Any other method can be detected by the game, and is thus not faithful emulation. To help with this, I'll probably make an RTC time tool so that you can adjust the time when the emulator isn't running, but I don't intend to bundle that into bsnes.
New state format bit-packs the RTCRAM values, and it also uses a 64-bit timestamp. So it's 16 bytes now instead of 20 bytes. S-RTC will drop from 16 to 12 when it's done.
The RTC busy flag timing needs to be refined with more hardware tests, there's a slim chance of the game hanging on save at the moment.
The SPC7110 ALU delays are emulated now, too. They may not be perfectly accurate, but they get the basic gist down.
The only hack that needs to be removed now is the decompression busy flag. That's ... not going to be fun.
I also redid the mouse emulation. I was polling the mouse position multiple times per latch. So it should be a bit more precise now, I hope.
I read it regardless of latch state, dunno if that's good or not.
2012-05-13 - bsnes_v089r02.tar.bz2
r02 changelog:
quick fix: SRAM is mapped to 00-3f|80-bf:6000-7fff
quick fix: $4830.d7 is SRAM chip enable, not SRAM write enable. Reads return 0x00 when this bit is clear
2012-05-13 - bsnes_v089r01.tar.bz2
r01 changelog:
major improvements to SPC7110 MCU (memory controller unit)
revised SPC7110 memory map to reflect aforementioned improvements
added "Toggle Tracer" hotkey to target-ethos (only works for SFC so far, I plan to use this as a lightweight laevateinn for FEoEZ)
2012-05-11 - bsnes_v089.tar.xz
This release is going to be unique from previous releases. I am only recommending that developers use this version. As such, only the source archive has been posted. I strongly recommend against Linux package maintainers updating to this build. Casual users should wait for the next release.
This release introduces a brand new user interface. It looks and functions exactly like the previous release, but it is built entirely on a declarative model: the GUI does not know about any individual systems that it supports. It pulls all of this information from a vector of emulated system objects instead. With the same amount of functionality, the new GUI is 66% smaller than the old GUI, code-wise.
In fact, it actually does more. You can now easily add (and remove) entire systems from bsnes with only three lines of code. Input mapping is now more advanced and allows multiple bindings per input.
But there is one critical thing it no longer does: the new GUI does not load individual ROM files. It requires the cartridge-folder concept that is still in development. It further requires a manifest to describe the PCB functionality. The code to handle both modes is cumbersome, and I did not wish to write it again.
Right now, the problem is that we don't have user-friendly tools to make using cartridge folders easy. As such, this is why I've chosen not to release binaries this time. It's my hope that in the interim between v089 and v090, we can bring in developers willing to make the process completely transparent.
And now is a perfect stopping point. Tom has just finished the English script translation for Far East of Eden Zero, so my efforts need to focus on reprogramming this game. This will require my absense from emulator programming for a while. Hopefully during that time, appropriate tools can be made for the next release. My hope is for v090 to be as easy to use as the old Qt releases were, with direct loading of compressed archives and headered images.
That said, this release also fixes some reported emulation bugs. Mini Yonku Shining Scorpion was broken for a bit due to incorrect SA-1 register initialization. Air Strike Patrol surprises us with a second mid-scanline raster effect, which disproved an older theory of mine on the BG scroll registers, and is now emulated correctly as well. There is also a world of internal code restructuring. All processor instruction sets are separated from the functionality built on top of them (for instance, the ST018 and GBA can share core ARM instructions.) Now that libsnes has been superceded by libretro, I've moved to a complete emulator abstraction in C++ that works with all of my emulators. And last but not least, there's a new cheats.xml from mightymo bundled in this release as well.
Changelog to v089:
fix SA-1 Mini Yonku Shining Scorpion
load from command-line
remove SNES::Cartridge::NVRAM
fix SGB save RAM
update cheats.xml
already mapped inputs cancel input assign
BS-X wasn't broken after all. I forgot that I ran purify on my BS-X images, and that the BS Zelda ZIP I have has the disable ROM bit set. Whoops.
2012-05-08 - bsnes_v088r16.tar.bz2
Changelog:
fixed BGnxOFS to not cache when MOSAIC is not in effect [fixes Air Strike Patrol "Good Luck" text]
added GameBoy::Interface::Hook for SGB bindings [SGB works again]
do not create bsnes/ folder unless it is absolutely needed (eg you create a save state or state manager archive)
SuperFX works [needed to call system.init() in Interface::Interface()]
Last chance for any bug reports, at this point I pretty much consider ethos to be finished. It's shipping without BS-X BIOS game loading support. Sorry, I can't figure that one out.
So what's left at this point is refinement of purify.
2012-05-07 - bsnes_v088r15.tar.bz2
Changelog:
default placement of presentation window optimized for 1024x768 displays or larger (sorry if yours is smaller, move the window yourself.)
Direct3D waits until a previous Vblank ends before waiting for the next Vblank to begin (fixes video timing analysis, and ---really--- fast computers.)
Window::setVisible(false) clears modality, but also fixed in Browser code as well (fixes loading images on Windows hanging)
Browser won't consume full CPU resources (but timing analysis will, I don't want stalls to affect the results.)
closing settings window while analyzing stops analysis
you can load the SGB BIOS without a game (why the hell you would want to ...)
escape closes the Browser window (it won't close other dialogs, it has to be hooked up per-window)
just for fun, joypad hat up/down moves in Browser file list, any joypad button loads selected game [not very useful, lacks repeat, and there aren't GUI load file open buttons]
Super Scope and Justifier crosshairs render correctly (probably doesn't belong in the core, but it's not something I suspect people want to do themselves ...)
you can load GB, SGB, GB, SGB ... without problems (not happy with how I did this, but I don't want to add an Interface::setInterface() function yet)
PAL timing works as I want now (if you want 50fps on a 60hz monitor, you must not use sync video) [needed to update the DSP frequency when toggling video/audio sync]
not going to save input port selection for now (lot of work), but it will properly keep your port setting across cartridge loads at least [just goes to controller on emulator restart]
SFC overscan on and off both work as expected now (off centers image, on shows entire image)
laevateinn compiles properly now
ethos goes to ~/.config/bsnes now that target-ui is dead [honestly, I recommend deleting the old folder and starting over]
Emulator::Interface callbacks converted to virtual binding structure that GUI inherits from (simplifies binding callbacks)
*** this breaks Super Game Boy for a bit, I need to rethink system-specific bindings without direct inheritance
Timing analysis works spectacularly well on Windows, too. You won't get your 100% perfect rate (unless maybe you leave the analysis running overnight?), but it'll get really freaking close this way.
added video shader selection (they go in ~/.config/bsnes/Video Shaders/ now)
added driver selection
added timing settings (not only allows video/audio settings, also has code to dynamically compute the values for you ... and it actually works pretty good!)
moved "None" controller device to bottom of list (it is the least likely to be used, after all)
added Interface::path() to support MSU1, USART, Link
input and hotkey mappings remember list position after assignment
and more!
target-ethos now has all of the functionality of target-ui, and more. Final code size for the port is 101.2KB (ethos) vs 167.6KB (ui).
A ~67% reduction in code size, yet it does even more! And you can add or remove an entire system with only three lines of code (Makefile include, header include, interface append.)
The only problem left is that the BS-X BIOS won't load the BS Zelda no Densetsu file.
I can't figure out why it's not working, would appreciate any assistance, but otherwise I'm probably just going to leave it broken for v089, sorry.
So the show stoppers for a new release at this point are:
fix laevateinn to compile with the new interface changes (shouldn't be too hard, it'll still use the old, direct interface.)
clean up Emulator::Interface as much as possible (trim down Information, mediaRequest should use an alternate struct designed to load firmware / slots separately)
enhance purify to strip SNES ROM headers, and it really needs a GUI interface
it would be highly desirable to make a launcher that can create a cartridge folder from an existing ROM set (* ethos will need to accept command-line arguments for this.)
probably need to remember which controller was selected in each port for each system across runs
need to fix the cursor for Super Scope / Justifier games (move from 19-bit to 32-bit colors broke it)
have to refactor that cache.(hv)offset thing to fix ASP
2012-05-06 - bsnes_v088r13.tar.bz2
Changelog:
fixed Super Game Boy input
Sufami Turbo prompts to load second slot now (you can cancel to leave it empty)
NEC/Hitachi/ARM DSP firmware is loaded; NEC RAM is saved
folders are grouped properly: Sufami Turbo save RAM saves to its slot folder, etc.
title shows properly (SGB shows GB game name only, BS-X slotted shows game name and optional slot name, etc.)
*** above extends to saving cheats and such in their correct folders as well
added cheat editor and cheat database
*** and hooked up the requisite SGB mode loads and can use GB cheats, because that's kinda cool
added state manager
input settings, cheat editor and state manager all have erase (one) and reset (all) buttons now
lots of cleanup and restructuring on Emulator::Interface; almost finished with it now
Remaining:
BS-X BIOS won't show the data pack
need XML mapping information window
need NSS DIP switch settings window
need video shaders
need driver selection
need to hide controllers that have no inputs from the input mapping list (tempted to just remove "None" as a controller option ...)
ethos is currently 88KB of code, ui is 167KB. We're missing about 5-10KB of code in ethos to complete it, so the rewrite nearly cut the GUI code size in half, while support all of the same functionality and allowing the easy addition and removal of entire systems.
2012-05-02 - bsnes_v088r11.tar.bz2
Changelog:
phoenix has added Window::setModal(bool modal = true);
file dialog is now modal. This allows emulation cores to request data and get it immediately before continuing the loading process
save data is hooked up for most systems, still need to handle subsystem slot saves (Sufami Turbo, basically.)
toggle fullscreen key binding added (Alt+Enter for now. I think F11 is probably better though, Enter is often mapped to game start button.)
video scaling is in (center, scale, stretch), works the same in windowed and fullscreen mode (stretch hides resize window option), all in the settings menu now
enough structure to map all saved paths for the browser and to load BS-X slotted carts, BS-X carts, single Sufami Turbo carts
Caveats / Missing:
Super Game Boy input doesn't work yet (due to change in callback binding)
doesn't load secondary Sufami Turbo slot yet
BS-X BIOS isn't show the data pack games to load for some reason (ugh, I hate the shit out of debugging BS-X stuff ...)
need mute audio, sync audio+video toggle, save/load state menu and quick keys, XML mapping information window
need cheat editor and cheat database
need state manager
need to sort subsystems below main systems in load menu (basically just see if media.slot.size() > 0)
need video shaders (will probably leave off filters for the time being ... due to that 24/30-bit thing)
need video adjustments (contrast etc, overscan masks)
need audio adjustments (frequency, latency, resampler, volume, per-system frequency)
need driver selection and input focus policy (driver crash detection would be nice too)
need NSS DIP switch settings (that one will be really fun)
need to save and load window geometry settings
need to hook up controller selection (won't be fun), create a map to hide controllers with no inputs to reassign
2012-04-30 - bsnes_v088r10.tar.bz2
ethos is going to be absolutely amazing. You guys are in for a treat :D
I'm impressing the hell out of myself with how well-structured this code is, it's allowing me to do amazing new things.
Just a small sampling of what's in store (and already implemented):
The file browser will display folders as "[ folder name ]", and cartridge folders as "Game Name" (no extension, no /) [icons would be nicer, but well ... phoenix.]
Folders are sorted above cartridge folders.
Cartridge folders for other systems do not show up in the list.
Not only are unique paths stored for each image type, your position in the list is saved across runs.
Some voodoo was added to GTK+ so that all targets even scroll directly to that item when you open the list. Load->System->Enter restarts your last game.
That sounds really simple and obvious, but it makes an -incredible- difference. Didn't realize it until I tried an implementation of it, wow.
The input mapping list now lets you bind as many hotkeys as you want to any given input.
So SFC::Port1::Joypad::B = Keyboard::Z or Joypad::Button1 ... no need to remap everything to switch between keyboard and joypad. Either one activates the key.
There is a separate Hotkeys tab now. This should hopefully end the confusion about how to remap hotkeys that users experience.
Hotkeys are different, too. Instead of OR logic, they use AND logic.
So Fullscreen = Keyboard::Alt and Keyboard::Enter. Both must be pressed to enter the key. This lets you easily implement "super" modifier keys.
The actual codebase has new features the old UI never had, and has about ~50% of the old functionality (so far, of course), yet is only ~25% as much code.
The entire GUI no longer needs to pull in all the headers for each emulated system. It just needs a small interface header file.
Then bind the entire system with exactly two lines of code. Everything is dynamically generated for you after that.
2012-04-29 - bsnes_v088r09.tar.bz2
Lots of work on ethos, nothing more.
Settings window is in, InputManager pulls all the inputs from all cores and binds them to ruby inputs, main window adds menu and dynamically maps in all systems and cartridge slots and options and such, file browser's back in, RAM is loaded and saved, etc. It's barely usable, but you have to set up your inputs from the config file by hand for now.
2012-04-28 - bsnes_v088r08.tar.bz2
From this WIP, I'm starting on the impossible task of a declarative-based GUI, which I'm calling Ethos.
base/ becomes emulator/, and we add emulator/interface.hpp, which is a base API that all emulation cores must implement in full.
(Right now, it's kind of a hybrid to work with the old GUI and the new GUI at the same time, of course.)
Unlike the old interfaces, the new base class also provides all general usability hooks: loading and saving files and states, cheat codes, etc.
The new interface also contains information and vector structs to describe all possible loading methods, controller bindings, etc; and gives names for them all.
The actual GUI in fact should not include eg <gba/gba.hpp> anymore. Should speed up GUI compilation.
So the idea going forward is that ethos will build a list of emulators right when the application starts up.
Once you've appended an emulator to that list, you're done. No more GUI changes are needed to support that system.
The GUI will have code to parse the emulator interfaces list, and build all the requisite GUI options dynamically, declarative style.
Ultimately, once the project is finished, the new GUI should look ~99% identical to the current GUI. But it'll probably be a whole lot smaller.
Themaister should enjoy the new interface, since only a single wrapper will be needed for libretro to support all my emulation cores.
2012-04-28 - bsnes_v088r07.tar.bz2
(r05 and r06 were save points between large core modifications)
I would really appreciate extensive regression testing (especially around SuperFX, Cx4, ST018, DSP-n, ST-01n, NES, GB) at this point.
The most critical core changes should be completed now. And it was an unbelievable amount of restructuring.
Changelog:
SuperFX core moved to Processor::GSU
SNES::CPU core moved to Processor::R65816
SNES::SMP core moved to Processor::SPC700
NES::CPU core renamed to Processor::R6502
use filestream to load RAM files from interface
save states store SHA256 instead of CRC32 (CRC32 usage removed entirely from bsnes)
nes/ -> fc/ and NES -> FC
snes/ -> sfc/ and SNES -> SFC
SuperFamicom::MappedRAM::copy uses stream instead of data+size
Linux port uses gcc-4.7 (still using only gcc-4.6 subset, so you can make a gcc-4.6 symlink for now if you like.)
all profiles and all targets compile and work properly
All eight instruction set cores have been moved to processor/ now. Consistency's a wonderful thing.
The last remnants of NES/SNES are now limited to target-ui code; and the nall/(system) folder names.
I'm building with gcc-4.7 on my Linux box now because the resultant binaries are up to 20% faster (seriously) than gcc-4.6.
...
This is probably an impossible task, but I'd really like it if the GUI could have absolutely no concept of individuals systems.
When it starts up, we attach "systems" to it from data files (eg those profile/manifest files ... easy to embed them right inside the emulator.)
It would then build the input mapping lists, the frequency controls, the cartridge loaders, and the interfaces to the cores.
Given the goal of exposing complete C++ interfaces for Themaister to wrap with libretro though, it would be wonderful to kill two birds with one stone.
2012-04-27 - bsnes_v088r04.tar.bz2
This will hopefully be a short-lived WIP, I just want to save a breakpoint before I attempt something else.
NES, GB, GBC and GBA all load via const stream& now.
NES CPU core moved to Processor::RP2A03.
EDIT: yeah, that failed. Was a wise idea to do a save point after all.
Trying to split SuperFX instructions to GSU core opcodes, but that chip is -much- more entangled than any other core.
Eg the PLOT instruction calls into the screen drawing stuff that handles the pixel buffer caches.
The CACHE instruction needs memory caching access.
There's no separation between MMIO registers and internal processing registers (if such a distinction even exists ...), so all MMIO regs need to go into the struct Regs {} for the CPU core.
And ... blech. Not good at all.
The other two remaining cores, SNES::CPU and SNES::SMP, are already split between core opcodes and functionality on top.
The CPU was done for SA-1 long ago, and the SMP was split for consistency with it long ago as well.
All I really have to do is move those folders and rename the classes.
It's going to bug me to have seven of eight CPU cores split up, and have one glaring inconsistency ...
2012-04-27 - bsnes_v088r03.tar.bz2
static vector file::read(const string &filename); replaces:
static bool file::read(const string &filename, uint8_t *&data, unsigned &size);
This allows automatic deletion of the underlying data.
Added vectorstream, which is obviously a vector wrapper for a data stream.
Plan is for all data accesses inside my emulation cores to take stream objects, especially MSU1.
This lets you feed the core anything: memorystream, filestream, zipstream, gzipstream, httpstream, etc.
There will still be exceptions for link and serial, those need actual library files on disk. But those aren't official hardware devices anyway.
So to help with speed a bit, I'm rethinking the video rendering path.
Previous system:
interfaceSystem transforms samples to 30-bit via lookup table inside the emulation core
interfaceSystem masks off overscan areas, if enabled
interfaceUI runs filter to produce new target buffer, if enabled
interfaceUI transforms 30-bit video to native display depth (24-bit or 30-bit), and applies color-adjustments (gamma, etc) at the same time
New system:
all cores now generate an internal palette, and call Interface::videoColor(uint32_t source, uint16_t red, uint16_t green, uint16_t blue) to get native display color post-adjusted (gamma, etc applied already.)
all cores output to uint32_t* buffer now (output video.palette[color] instead of just color)
interfaceUI runs filter to produce new target buffer, if enabled
interfaceUI memcpy()'s buffer to the video card
videoColor() is pretty neat. source is the raw pixel (as per the old-format, 19-bit SNES, 9-bit NES, etc), and you can create a color from that if you really want to. Or return that value to get a buffer just like v088 and below.
red, green, blue are 16-bits per channel, because why the hell not, right? Just lop off all the bits you don't want. If you have more bits on your display than that, fuck you :P
The last step is extremely difficult to avoid. Video cards can and do have pitches that differ from the width of the texture.
Trying to make the core account for this would be really awful. And even if we did that, the emulation routine would need to write directly to a video card RAM buffer.
Some APIs require you to lock the video buffer while writing, so this would leave the video buffer locked for a long time. Probably not catastrophic, but still awful.
And lastly, if the emulation core tried writing directly to the display texture, software filters would no longer be possible (unless you -really- jump through hooks and divert to a memory buffer when a filter is enabled, but ... fuck.)
Anyway, the point of all that work was to eliminate an extra video copy, and the need for a really painful 30-bit to 24-bit conversion (three shifts, three masks, three array indexes.)
So this basically reverts us, performance-wise, to where we were pre-30 bit support.
Framerate difference (results will likely vary wildly):
Zelda 3 SFC = 105.5 to 109.0 (will be more for compatibility profile, where the video copying was a bigger bottleneck)
Mega Man 2 FC = 239.5 to 243.5
Mega Man 2 GB = 420.0 to 444.5
Mr. Driller 2 = 231.0 to 237.5
The downside to this is that we're going to need a filter for each output depth. Since the array type is uint32_t*, and I don't intend to support higher or lower depths, we really only need 24+30-bit versions of each filter.
Kinda shitty, but oh well.
2012-04-26 - bsnes_v088r02.tar.bz2
Really no reason to download this one unless you want to stay on the absolute bleeding edge of phoenix development.
Basically, the current implementation of nall/array is deprecated now.
The old method was for non-reference types, it acted like a vector for POD types (raw memory allocation instead of placement new construction.)
And for reference types, it acted like an unordered set. Yeah, not good.
As of right now, nall/array is no longer used. The vector type usage was replaced with actual vectors.
I've created nall/set, which now contains the specialization for reference types.
nall/set basically acts much like std::unordered_set. No auto-sort, only one of each type is allowed, automatic growth.
This will be the same both for reference and non-reference types ... however, the non-reference type wasn't implemented just yet.
Future plans for nall/array are for it to be a statically allocated block of memory, ala array<type, size>, which is meant for RAII memory usage.
Have to work on the specifics, eg the size as a template parameter may be problematic. I'd like to return allocated chunks of memory (eg file::read) in this container so that I don't have to manually free the data anymore.
I also removed nall/moduloarray, and moved that into the SNES DSP class, since that's the only thing that uses it.
2012-04-25 - bsnes_v088r01.tar.bz2
Code:
GB::CPU::Core -> Processor::LR35902
Processor::LR35902 -> jump table to switch table
GB::LCD -> GB::PPU
static frequency for DMG (no multiplication on clock ticks)
GB::PPU::interface->videoRefresh() moved outside scheduler (use host thread)
namespace NES -> Famicom
namespace SNES -> SuperFamicom
namespace GB -> GameBoy
namespace GBA -> GameBoyAdvance
removed boot.rom writeout in GB::System
Wishlist for v089:
libsnes++ (basically, cleaner C++ library interface to core for libretro to use)
internal filtering for matching hardware output effects (GB/GBA LCD blur, SNES pseudo-hires blending, possibly NES NTSC encoding, etc.)
internalize color conversion to -possibly- save an extra transformation ?
emulation improvements for NES, GB, GBC, GBA
speedups for GBA
complete GBA memory type database
GBA cheat codes
GBA cheat database ?
move NES::CPU (6502) to processor/
move SNES::CPU (65816) to processor/
move SNES::SMP (SPC700) to processor/
move SNES::SuperFX::Core (GSU) to processor/
all threads should be declared Class::Enter() { class.main(); }
nes -> fc, snes -> sfc ?
rewrite nall/array to be a static byte array rather than a POD-based vector class (get away from raw new / delete, where possible)
2012-04-24 - bsnes_v088-source.tar.xz
As promised from the last news update, this release adds preliminary Game Boy Advance emulation. It's not perfect by any means, but it's one of the better first releases I've put out. It emulates all GBA functionality with the exception of the link cable and ROM prefetch buffer, although being a first release, there are bound to be plenty of bugs lurking in the core. I'd of course love some help with bugfixes, if anyone is interested =)
It's important to note that the GBA emulation has not been optimized yet. The GBA is a more demanding system than the SNES, by way of a much faster CPU core and higher frequency audio. You can expect about ~150fps on average with a Core i7-class CPU for now, but please note that I do intend to improve upon this performance in future releases.
For a bit of backstory: this is basically a byproduct of SNES ST018 emulation. This processor ended up using an ARMv3 CPU core. And since the GBA uses an ARMv4 CPU core, it seemed like a good choice: we could improve the ARM emulation for the ST018, and emulate the final 2D-based Nintendo system.
In the end, it turned out to be harder than expected: it took about a month to complete the emulation core, and it was only this quick due to extensive help from Cydrak; who fixed numerous CPU bugs, emulated the affine and bitmap rendering modes, and also implemented the new GBA FIFO audio channel, among other things.
On a side note, thanks to Cydrak and krom's hardware testing, we do have a nice milestone right out of the gate: proper OBJ mosaic emulation, which seems to be a first. At the very least, hopefully this will be helpful to other emulators.
Note that you will need the GBA BIOS image to use this. There will not be any high-level emulation of the BIOS functions for obvious reasons. Name the file "bios.rom", and place it inside the "Game Boy Advance.sys" folder.
Changes to v088:
OBJ mosaic Y fix
Laevateinn compilation
Remove filebrowser extra code
Fix -march=native on Windows
Fix purify mkdir
GBA sound volume
Add .gbb
free firmware memory after file load
Add GBA game to profile list (Yoshi's Island should work)
Already noticed one miss: my GB core still writes out the SGB BIOS on startup (I was dumping my C struct to a file for the system folders.)
Won't matter unless you happen to have write access to /home/byuu when you run bsnes. If you do, consider this my way of suggesting you choose a different name :P
Didn't add a warning on BIOS missing, but let's be honest, we'd get a dozen posts about it even if I did.
2012-04-22 - bsnes_v087r30.tar.bz2
Changelog:
DMA channel masks added (some are 27-bit source/target and some are 14-bit length -- hooray, varuint_t class.)
No more state.pending flags. Instead, we set dma.pending flag when we want a transfer (fixes GBA Video - Pokemon audio) [Cydrak]
fixed OBJ Vmosaic [Cydrak, krom]
OBJ cannot read <=0x13fff in BG modes 3-5 (fixes the garbled tile at the top-left of some games)
DMA timing should be much closer to hardware now, but probably not perfect
PPU frame blending uses blargg's bit-perfect, rounded method (slower, but what can you do?)
GBA carts really unload now
added nall/gba/cartridge.hpp: used when there is no manifest. Scans ROMs for library tags, and selects the first valid one found
added EEPROM auto-detection when EEPROM size=0. Forces disk/save state size to 8192 (otherwise states could crash between pre and post detect.)
*** detects first read after a set read address command when the size is zero, and sets all subsequent bit-lengths to that value, prints detected size to terminal
added nall/nes/cartridge.hpp: moves iNES detection out of emulation core.
Important to note: long-term goal is to remove all nall/(system)/cartridge.hpp detections from the core and replace with databases. All in good time.
Anyway, the GBA workarounds should work for ~98.5% of the library, if my pre-scanning was correct (~40 games with odd tags. I reject ones without numeric versions now, too.)
I think we're basically at a point where we can release a new version now. Compatibility should be relatively high (at least for a first release), and fixes are only going to affect one or two games at a time. I'd like to start doing some major cleaning house internally (rename NES->Famicom, SNES->SuperFamicom and such.) Would be much wiser to do that on a .01 WIP to minimize regressions.
The main problems with a release now:
speed is pretty bad, haven't really optimized much yet (not sure how much we can improve it yet, this usually isn't easy)
sound isn't -great-, but the GBA audio sucks anyway :P
couple of known bugs (Sonic X video, etc.)
2012-04-20 - bsnes_v087r29.tar.bz2
Changelog:
revised NES XML tag nesting
program.rom is going to refer to PRG+CHR combined. Split is going to have to use different file names
slot loader is gone (good riddance!)
"Cartridge -> Load Game Boy Advance Cartridge ..." has become "Load -> Game Boy Advance ..."
Load Satellaview Slotted Cartridge is gone. If you load an SNES cartridge and it sees , it asks if you want to load a BS-X data pack
If you load a Sufami Turbo cartridge with , it asks if you want to link in another Sufami Turbo cartridge
if you try and load the same exact Sufami Turbo cartridge in both slots, it yells at you for being an idiot :P
2012-04-18 - bsnes_v087r28.tar.bz2
Be sure to run make install, and move required images to their appropriate system profile folders.
I still have no warnings in place if those images aren't present.
Changelog:
OBJ mosaic should hopefully be emulated correctly now (thanks to krom and Cydrak for testing the hardware behavior)
emulated dummy serial registers, fixes Sonic Advance (you may still need to specify 512KB FlashROM with an appropriate ID, I used Panaonic's)
GBA core exits scheduler (PPU thread) and calls interface->videoRefresh() from main thread (not required, just nice)
SRAM, FRAM, EEPROM and FlashROM initialized to 0xFF if it does not exist (probably not needed, but FlashROM likes to reset to 0xFF anyway)
GBA manifest.xml for file-mode will now use "gamename.xml" instead of "gamename.gba.xml"
started renaming "NES" to "Famicom" and "SNES" to "Super Famicom" in the GUI (may or may not change source code in the long-term)
removed target-libsnes/
added profile/
Profiles are the major new feature. So far we have:
Code:
Famicom.sys/{nothing (yet?)}
Super Famicom.sys/{ipl.rom}
Game Boy.sys/{boot.rom}
Game Boy Color.sys/{boot.rom}
Game Boy Advance.sys/{bios.rom[not included]}
Super Game Boy.sfc/{boot.rom,program.rom[not included]}
BS-X Satellaview.sfc/{program.rom,bsx.ram,bsx.pram}
Sufami Turbo.sfc/{program.rom}
The SGB, BSX and ST cartridges ask you to load GB, BS or ST cartridges directly now. No slot loader for them.
So the obvious downsides: you can't quickly pick between different SGB BIOSes, but why would you want to? Just use SGB2/JP.
It's still possible, so I'll sacrifice a little complexity for a rare case to make it a lot easier for the more common case.
ST cartridges currently won't let you load the secondary slot.
BS-X Town cart is the only useful game to load with nothing in the slot, but only barely, since games are all seeded on flash and not on PSRAM images. We can revisit a way to boot the BIOS directly if and when we get the satellite uplink emulated and data can be downloaded onto the PSRAM :P
BS-X slotted cartridges still require the secondary slot.
My plan for BS-X slotted cartridges is to require a manifest.xml to specify that it has the BS-X slot present.
Otherwise, we have to load the ROM into the SNES cartridge class, and parse its header before we can find out if it has one. Screw that.
If it's in the XML, I can tell before loading the ROM if I need to present you with an optional slot loading dialog.
I will probably do something similar for Sufami Turbo. Not all games even work with a secondary slot, so why ask you to load a second slot for them? Let the XML request a second slot. A complete Sufami Turbo ROM set will be trivial anyway.
Not sure how I want to do the sub dialog yet. We want basic file loading, but we don't want it to look like the dialog 'didn't do anything' if it pops back open immediately again. Maybe change the background color of the dialog to a darker gray? Tacky, but it'd give you the visual cue without the need for some subtle text changes.
APU/PPU dont sync back to CPU if syncing for state
fixed APU sync problems in GB/GBC core that could possibly wreck save states as well
Quite a lot of little problems there. I believe GBA save states are fixed now.
2012-04-16 - bsnes_v087r26.tar.bz2
Changelog:
fixed FIFO[1] reset behavior (fixes audio in Sword of Mana)
added FlashROM emulation (both sizes)
GBA parses RAM settings from manifest.xml now
save RAM is written to disk now
added save state support (it's currently broken, though)
fixed ROM/RAM access timings
open bus should mostly work (we don't do the PC+12 stuff yet)
emulated the undocumented memory control register (mirror IWRAM, disable I+EWRAM, EWRAM wait state count)
emulated keypad interrupts
emulated STOP (freezes video, audio, DMA and timers; only breaks on keypad IRQs)
probably a lot more, it was a long night ...
Show stoppers, missing things, broken things, etc:
ST018 is still completely broken
GBC audio sequencer apparently needs work
GBA audio FIFO buffer seems too quiet
PHI / ROM prefetch needs to be emulated (no idea on how to do this, especially PHI)
SOUNDBIAS 64/128/256khz modes should output at that resolution (really, we need to simulate PWM properly, no idea on how to do this)
object mosaic top-left coordinates are wrong (minor, fixing will actually make the effect look worse)
need to emulate PPU greenswap and color palette distortion (no idea on how do this)
need GBA save type database (I would also LIKE to blacklist / patch-out trainers, but that's a discussion for another day.)
some ARM ops advance the prefetch buffer, so you can read PC+12 in some cases
Okay, major points.
First, the save RAM type is now specified in the manifest.xml file. If you don't have one, you have no save RAM.
To run games that need it, you're going to have to make a manifest.xml (or gamename.xml if you don't want to use cartridge folders.)
Here are some examples:
Code:
<?xml version="1.0" encoding="UTF-8"?>
Castlevania - Circle of the Moon (US)
<?xml version="1.0" encoding="UTF-8"?>
Super Mario Advance (US)
<?xml version="1.0" encoding="UTF-8"?>
Super Mario Advance 3 (US)
<?xml version="1.0" encoding="UTF-8"?>
Super Mario Advance 4 (US)
We desperately need a database here. I want all No-Intro set game hashes in a big database along with their memory type before we can release this.
Save states are currently broken. They work when you're on the same screen, but when a lot has changed and you try and load, things explode.
This is typical to see when implementing states. It basically means I'm missing serializing some important data somewhere.
I'd really appreciate if anyone wanted to look the code over to see if they can find any missing variables not being serialized. It's easy for me to overlook.
Looks like GBA states are ~400-500KB uncompressed, FWIW.
EDIT: my guess is that we probably need to call some functions to restored cached states, eg processor.setMode(m) inside the ARM serialization.
2012-04-15 - bsnes_v087r25.tar.bz2
(r24 was a point release during merging of changes.)
This release is almost entirely Cydrak's direct work:
Added ARM::sequential() and some WAITCNT timings
Added Bus::io(uint32 pc), intended for prefetch timing
Added ARM::load() with data rotation (fixed Mother 3 graphics)
Added ARM::store() for data mirroring
LDM, STM, and instruction fetch still use read/write()
ARM::vector() no longer unmasks FIQs
Set THUMB shifter flags via bit(), consistent with ARM
Replace shifter loops with conditional tests
My changes:
fixed sprite clipping on left-edge of screen
added first system folder, GBA.system
sudo make install is now make install
make install will create GBA.system for you in your home folder
Windows users, take data/GBA.system and put it in the same folder as bsnes.exe, and give it a BIOS named bios.rom
Or place it in your home folder (%APPDATA%/bsnes)
Also note that this is highly experimental, I'll probably be changing things a lot before release.
... and thank you krom for the info, much appreciated :D
Will merge that in when I figure out a good way to do object mosaic at screen (0,0) with my renderer.
EDIT: I botched the cartridge timing change. Will fix in r26. It'll still run a bit too fast for now, unfortunately.
2012-04-14 - bsnes_v087r23.tar.bz2
Changelog:
fixed cascading timers and readouts (speed hit from 320fps to 240fps; would be 155fps with r20 timers) (fixes Spyro)
OBJ mode 3 acts like OBJ mode 2 now (may not be correct, but nobody has info on it)
added background + object vertical+horizontal mosaic in all modes (linear+affine+bitmap)
object mosaic uses sprite (0,0) for start coordinates, not screen (0,0) (again, nobody seems to have info on it)
BIOS cannot be read by r(15)>=0x02000000; returns last BIOS read instead (I can't believe games rely on this to work ... fixes SMA Mario Bros.)
Mosaic is what concerns me the most, I've no idea if I'm doing it correctly. But anything is probably better than nothing, so there's that.
I don't really notice the effect in Metroid Fusion. So either it's broken, or it's really subtle.
added full support for windows (both inputs, OBJ windows, and output, with optional color effect disable)
EEPROM uses nall::bitarray now to be friendlier to saving memory to disk
removed incomplete mosaic support for now (too broken, untested)
improved sprite priority. Hopefully it's right now.
Just about everything should look great now. It took 25 days, but we finally have the BIOS rendering correctly.
In order to do OBJ windows, I had to drop my above/below buffers entirely. I went with the nuclear option.
There's separate layers for all BGs and objects. I build the OBJ window table during object rendering.
So as a result, after rendering I go back and apply windows (and the object window that now exists.)
After that, I have to do a painful Z-buffer select of the top two most important pixels.
Since I now know the layers, the blending enable tests are a lot nicer, at least.
But this obviously has quite a speed hit: 390fps to 325fps for Mr. Driller 2 title screen.
TONC says that "bad" window coordinates do really insane things. GBAtek says it's a simple y2 < y1 || y2 > 160 ? 160 : y2; x2 < x1 || x2 > 240 ? 240 : x2;
I like the GBAtek version more, so I went with that. I sure hope it's right ... but my guess is the hardware does this with a counter that wraps around or something.
Also, say you have two OBJ mode 2 sprites that overlap each other, but with different priorities. The lower (more important) priority sprite has a clear pixel, but the higher priority sprite has a set pixel. Do we set the "inside OBJ window" flag to true here? Eg does the value OR, or does it hold the most important sprite's pixel value? Cydrak suspects it's OR-based, I concur from what I can see.
Mosaic, I am at a loss. I really need a lot more information in order to implement it.
For backgrounds, does it apply to the Vcounter of the entire screen? Or does it apply post-scroll? Or does it even apply after every adjust in affine/bitmap modes?
I'm betting the hcounter background mosaic starts at the leftmost edge of the screen, and repeats previous pixels to apply the effect. Like SNES, very simple.
For sprites, the SNES didn't have this. Does the mosaic grid start at (0,0) of the screen, or at (0,0) of each sprite? The latter will look a lot nicer, but be a lot more complex. Is mosaic on affine objects any different than mosaic of linear(tiled) objects?
With that out of the way, we still have to fix the CPU memory access timing, add the rest of the CPU penalty cycles, the memory rotation / alignment / extend behavior needs to be fixed, the shifter desperately needs to be moved from loops to single shift operations, and I need to add flash memory support.
Exophase, I appreciate your assistance with the semi-transparent objects.
2012-04-10 - bsnes_v087r21.tar.bz2
EDIT: below green channel shift in PPU::blend() [gba/ppu/screen.cpp at the bottom] is >> 6, should be >> 5. That would probably break most alpha blending effects.
Timer speedup added. Boosts Mr. Driller 2 title from 170fps to 400fps. Other games still benefit, but not as amazingly. I don't dip below 160fps ever here.
Reverted the memory speed to 2 for everything for now, to fix Castlevania slowdown. We obviously need to add the N/S stuff before we do that.
Added linear BG and linear OBJ mosaic-Y. Did not add mosaic-X, or any mosaic to the affine/bitmap modes, because I'm not sure when to apply the compensation.
Rewrote layer stuff. It now has two layers (above and below), and it performs the four blending modes as needed.
Didn't add semi-transparent sprites because the docs are too confusing.
Added a blur filter directly into the PPU for now. This obviously violates my interface, but F-Zero needed it for HUD display. We can remove it when we have an official release with a blur filter available. The filter still doesn't warp colors like a real GBA, because I don't know the formula.
So, major priorities now are CPU speed, CPU rotation, windowing, semi-transparent sprites, rest of mosaic, low audio volume (and center GB channels.) Probably in that order?
2012-04-09 - bsnes_v087r20.tar.bz2
Changelog:
HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later]
MMIO regs for CPU/PPU simplified by combining array accesses
custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes
16-bit PRAM data (decent speedup)
emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all]
misc. code cleanups
For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 - bsnes_v087r19.tar.bz2
Changelog:
added FIFO buffer emulation (with DMA and all that jazz) [Cydrak]
fixed timers and vcounter assign [Cydrak]
emulated EEPROM (you have to change size manually for 14-bit mode, we need a database badly now) [SMA runs now]
removed OAM array, now decoding directly to struct Object {} [128] and ObjectParam {} [32] (faster this way)
check forceblank (still doesn't remove all garble between transitions, though??)
lots of other stuff
Delete your settings.cfg, or manually change frequencyGBA to 32768, or bad things will happen (this may change back to 256KHz-4MHz later.)
15 of 16 games are fully playable now, and look and sound great.
The major missing detail right now is PPU blending support, and we really need to optimize the hell out of the code.
fixed IRQ bug in THUMB mode (fixed almost every game)
timers added (broke almost every game, whee.)
Cydrak is absolutely amazingly awesome and patient. This really wouldn't be happening without him.
Also fixed some things from my end, including greatly improved sprite priorities, and a much better priority sorter. Mr. Driller looks a lot better now.
Direct Sound / FIFO DMA stuff is completely kicking my ass right now. The explanations are unbelievably spartan.
DMA FIFO A/B have 32 byte buffers each. They also have that MMIO register that supposedly accesses the first four(?) samples.
The docs say you can write the first 8-bits to it. So why is the register 32-bits wide with four samples exposed?
What happens if I keep writing to the FIFO anyway? Will it keep filling up? Does it only advance when I wrote to xa0? Or on xa0,a1,a2,a3?
It says DMA sound requests a FIFO DMA when the FIFO buffer is at 16 bytes. When you start, it'll be at 0 bytes. So is it really <= 16 bytes?
What happens if the FIFO buffer runs out, but it keeps playing? Will the read wrap around, or start returning zeroes, or stall something?
What happens if you write too much data in the FIFO? Does it wrap around, or does it just get rejected, or stall something?
What is this nonsense about 6-9 bit width for these samples? The samples input are 8-bit. I can't "make" 9-bit out of that in any useful sense. I can extend it, but that's kind of stupid and useless.
Does FIFO DMA secretly write to xa0-a3 (or FIFO B registers)? Or does it just go directly to the APU?
And that's just off the top of my head.
2012-04-05 - bsnes_v087r17.tar.bz2
Emulated GBC sound plus the new extensions to it.
I am kind of surprised by how little developers utilized the GBC audio portion.
Mr. Driller now has sound effects, and Pinobee no Daibouken has BGM.
I still have yet to emulate the GBA extra sound channels and PWM. Need to emulate timers and DMA 2 refresh mode before I can do that.
Also, I moved both GBC and GBA audio to use length = data; if(++length == 0); rather than length = 64 - data; if(--length == 0); so that I could return literal values for register reads.
I thought there was a good reason we used the latter version, but I can't hear any audible difference even in GBC games, so oh well.
Lastly, I think the pattern[++offset] in the wave channel was a bug in the DMG/GBC only. I really, really hope it doesn't apply to the GBA, because that will make bank selection a serious pain in the ass.
I've no idea how the audio actually works, so I'm running the GBC audio at 4MHz. It sounds good, but obviously that's a bitch on speed.
Down to about 130fps now (30% faster than SNES/accuracy), and there's more pain to come. But there's an entire world of speedups available to us, so we'll be profiling and optimizing once we have a decent compatibility rate.
Hopefully before first public release, for first impressions and all, but we'll see.
2012-04-03 - bsnes_v087r16.tar.bz2
ixed the r15 mask per Cydrak.
Added DMA support (immediate + Vblank + Hblank + HDMA) with IRQ support. Basically only missing FIFO reload mode for the APU on channel 2.
Added background linear renderer (tilemap mode.)
Added really inefficient pixel priority selector, so that all BGs+OBJ could be visible onscreen at the same time.
As a result of the above:
Mr. Driller is our first fully playable game
Bakunetsu Dodge Ball Fighters is also fully playable
Pinobee no Daibouken is also fully playable
Most games (15 of 16 tested) are now showing something, many things look really really good in fact.
Absolutely essential missing components:
APU
CPU timers and their interrupts
DMA FIFO mode
OBJ affine mode
BG affine mode
BG bitmap mode
PPU windows (BG and OBJ)
PPU mosaic
PPU blending modes
SRAM / EEPROM (going to rely on a database, not heuristics. Homebrew will require a manifest file.)
2012-04-03 - bsnes_v087r15.tar.bz2
Added linear (eg non-affine) sprite rendering, 4bpp and 8bpp with hflip and vflip. Nothing else.
You can now see the Nintendo logo and Gameboy text at the end of the BIOS.
It's a start =)
The BIOS doesn't use BGs, so I can't really test any BG implementation there.
Need to find some good test ROMs to implement the tilemap and bitmap BG modes.
2012-03-31 - bsnes_v087r14.tar.bz2
Fixed aforementioned issues.
All CPU+PPU registers are now hooked up (not that they do anything.) SOUNDBIAS for APU was hooked up, got tired of working on it for the rest :P
I recall from the GB APU that you can't just assign values for the APU MMIO regs. They do odd reload things as well.
Also, was using MMIO read code like this:
Code:
return (
(flaga << 0)
|| (flagb << 1)
|| (flagc << 2)
);
Logical or doesn't work so well with building flags :P
Bad habit from how I split multiple conditionals across several lines.
So ... r14 is basically what r13 should have been yesterday, delaying my schedule by yet another day :(
2012-03-30 - bsnes_v087r13.tar.bz2
Contains all of Cydrak's fixes, sans PPU.
On the PPU front, I've hooked up 100% of read and write registers.
All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well.
Super Mario Advance now runs without appearing to crash, although it's hard to tell since I have no video or sound :P
ARM Wrestler is known to run, as is the BIOS.
APU can wait. I believe I'm capable of at least getting that started. Basically a copy/paste job from the GB/C audio core, followed by a few simple extensions, hopefully. We'll see.
So ... now it's on to the PPU. Honestly, it looks a lot more complicated than the SNES PPU, but I suppose a lot of that is because I understand the SNES PPU so well.
Certainly nothing like the NES and GB where I can just cobble together something that works in ten minutes.
Have Cydrak's awesome code, so I can start with that and build upon it, and see what happens. But I definitely need to understand how it works, so copy/paste here is out. I won't be able to add the more advanced features if I don't understand the basics.
2012-03-29 - bsnes_v087r12.tar.bz2
Enough to get through the BIOS and into cartridge ROM.
I am a bit annoyed that I was basically told that the GBA PPU wasn't that bad. Sprites are a clusterfuck, easily worse than Mode7, docs don't even begin to explain them in enough detail.
This is going to be fun.
2012-03-28 - bsnes_v087r11.tar.bz2
Added all of the above fixes and changes.
Also new is pipeline_decode() to fetch data, and IME/IE/IF support, and an ARM::processor.irqline flag that triggers IRQs at 0x18. Only Vblank is hooked up, which is what SWI 4 was waiting on previously.
I'm sure my interrupt support is horribly broken and wrong. I was never able to really figure out IE/IF on the Game Boy, so there's no question this is even worse.
It's now going crazy and writing 0 to IE forever now after the Vblank IRQ triggers.
2012-03-26 - bsnes_v087r10.tar.bz2
Changelog:
fixed THUMB hi immediate reads (immediate * 4)
cartridge is properly mirrored to 32MB (eg 12mbit repeats as lo8+hi4+hi4+lo8+hi4+hi4) [so it's a bit slower than a standard memcpy fill]
added ARM - load/store halfword register offset
added ARM - load/store halfword immediate offset
added ARM - load signed halfword/byte register offset
added ARM - load signed halfword/byte immediate offset
added decode() function to make opcode bit testing a lot clearer (didn't apply it to the debugger yet)
All ARMv4M and all THUMBv4 instructions should now be implemented. Although I'm not sure if my implementations of the new instructions are correct.
I'm still stuck in the aforementioned loop. It's obviously a CPU bug, because that loop is not polling any I/O registers.
Much nicer:
Code:
decode("???? 0000 00?? ???? ???? ???? 1001 ????", multiply);
decode("???? 0001 0?00 ???? ???? ---- 1001 ????", memory_swap);
decode("???? 000? ?0?? ???? ???? ---- 1011 ????", move_half_register);
decode("???? 000? ?1?? ???? ???? ???? 1011 ????", move_half_immediate);
decode("???? 000? ?0?1 ???? ???? ---- 11?1 ????", load_register);
decode("???? 000? ?1?1 ???? ???? ???? 11?1 ????", load_immediate);
2012-03-25 - bsnes_v087r09.tar.bz2
Split apart necdsp: core is now in processor/upd96050 (wish I had a better name for it, but there's no family name that is maskable.)
I would like to support the uPD7720 in the core as well, just for completeness' sake, but I'll have to modify the decoder to drop one bit from each mode.
So ... I'll do that later. Worst part is even if I do, I won't be able to test it :(
Added all of Cydrak's changes. I also simplified LDMIA/STMIA and PUSH/POP by merging the outer loops.
Probably infinitesimally slower, but less code is nicer. Maybe GCC optimization will expand it, who knows.
We were getting stuck polling SOUNDBIAS:
Code:
00000800 2102 mov r1,#0x02
00000802 0209 lsl r1,r1,#8
00000804 468c mov r12,r1
00000806 4bb3 ldr r3,[pc,#0xad4] =0x04000088
00000808 881a ldrh r2,[r3,#0x00]
0000080a 4bb2 ldr r3,[pc,#0xad4] =0x04000088
0000080c 0591 lsl r1,r2,#22
0000080e 0d89 lsr r1,r1,#22
00000810 2800 cmp r0,#0x00
00000812 d003 beq 0x0000081c
00000814 4561 sub r1,r12
00000816 da09 bge 0x0000082c
00000818 1c92 add r2,r2,#2
0000081a e002 b 0x00000822
00000822 801a strh r2,[r3,#0x00]
00000824 2208 mov r2,#0x08
00000826 1e52 sub r2,r2,#1
00000828 d5fd bpl 0x00000826
00000826 1e52 sub r2,r2,#1
00000828 d5fd bpl 0x00000826
0000082a e7e9 b 0x00000800
So I hooked the APU up to it and return 0x200 now (per gbatek.)
Now we're getting stuck in an infinite loop here:
Code:
00000ba0 4718 bx r3 ;switch to ARM mode (per Exophase's disassembly)
(supposed to switch to ARM mode, just repeats forever)
(r3 == 0xba1 here ...)
Hit after 38,112 opcodes.
Exophase, don't suppose you'd know how many (ARM+THUMB) instructions are executed before cartridge entry point? That should be a nice measurement of how close I am.
My cycle counter is basically (ARM2)+(THUMB1)*instructions, which is horribly inaccurate. Need to talk with Cydrak about how to do the SNI cycles in a way that's compatible with non-sequential accesses to different memory regions of the GBA.
2012-03-22 - bsnes_v087r08.tar.bz2
Added some more ARM opcodes, hooked up MMIO. Bind it with mmio[(addr 000-3ff)] = this; inside CPU/PPU/APU, goes to read(), write().
Also moved the Hitachi HG51B core to processor/, and split it apart from the snes/chip/hitachidsp implementation.
This one actually worked really well. Very clean split between MMIO/DMA and the processor core. I may move a more generic DMA function inside the core, not sure yet.
I still believe the HG51B169 to be a variant of the HG51BS family, but given they're meant to be incredibly flexible microcontrollers, it's possible that each variant gets its own instruction set.
So, who knows. We'll worry about it if we ever find another HG51B DSP, I guess.
Notes while working on Cydrak's updated ST018 code:
Code:
lsl/lsr/etc perform masking, but so do opcodes?
Would like to get ARMwrestler working before optimizing these for performance.
arithmetic() reloads cpsr??
if(isprivileged() && cpsr.m != 0x1f || source == 0)
if(a && (b || c)) or if((a && b) || c) ?
I went off the docs instead, and do the transfer if SPSR or CPSR.mode != USR
Added modified booth encoding (awesome stuff!)
t = (int2)n; Testing -2, -1, +1, +2 ... int2 should have a range of {-2, -1, 0, +1} only though ... bug?
Added memory_swap()
Added move_to_status_from_immediate()
Added software_interrupt()
GBA BIOS is constantly reading from 04000300, but it never writes. If I return prng()&1, I can get it to proceed until it hits a bad opcode (stc opcode, which the GBA lacks a coprocessor so ... bad codepath.)
Without it, it just reads that register forever and keeps resetting the system, or something ...
I guess we're going to have to try and get ARMwrestler working, because the BIOS seems to need too much emulation code to do anything at all.
2012-03-22 - bsnes_v087r07.tar.bz2
Both snes/chip/armdsp and gba/cpu use processor/arm now.
Fixed THUMB to execute the BL prefix and suffix separately. I can now get the GBA BIOS stuck in some kind of infinite loop. Hooray ... I guess?
2012-03-22 - bsnes_v087r07pre.tar.bz2
And now for something a bit different:
Creates the bsnes/processor folder. This has a shared ARM core there which both the GBA and ST018 inherit.
There are going to be separate decoders, and revision-specific checks, to support the differences between v3+.
In the future, I also want to move the other processor cores here:
GBZ80 (GB, GBC)
65816 (SNES CPU, SA-1)
NEC uPD (7725, 96050, maybe 7720 just for fun)
Hitachi HG51B169
SuperFX
SPC700
65(C?)02
Basically, the GBA/ST018 forces my hand to start coding a bit more like a multi-system emulator.
Right now, the ST018 is broken. Hence the pre. Apparently the GBA core being used now has some bugs. So this'll be a nice way to stress-test the GBA core a bit before we make it to ARMwrestler.
2012-03-21 - bsnes_v087r06.tar.bz2
I believe I've implemented every THUMB instruction now, although I'm sure there are dozens of bugs in the implementation.
Here is a run-log: http://byuu.org/temp/armtrace.txt (instructions below current register values)
It seems that the last jump taken is ending up being off-by-two. It's probably due to not masking/adjusting PC correctly at certain points.
I don't know if any other bugs are being hit prior to this or not.
I don't implement any I/O registers yet, and the BIOS seems to be poking at a few of them along the way, so ... who knows.
I could also be reading the log wrong, but it looks to me like there's some PSR setting the mode flag register to 0, which is supposed to be an undefined behavior mode ... perhaps mrs has no effect on the m/t bits, and it just affects the i/f bits?
It'd be nice if we could get a trace log like mine from a good emulator running the BIOS to compare for issues.
2012-03-20 - bsnes_v087r05.tar.bz2
Implemented all of the ARMv3 instructions, and the bx rm instruction as well.
Already hit THUMB mode right at the start of the BIOS, sigh.
Implemented the first THUMB instruction to get that rolling.
Also tried to support the S flag to LDM/STM, but not sure how successful I was.
Code:
00000000 ea000018 b 0x00000068
00000068 e35e0000 cmp lr,#0x00000000
0000006c 03a0e004 moveq lr,#0x00000004
00000070 e3a0c301 mov r12,#0x04000000
00000074 e5dcc300 ldrb r12,[r12,+0x300]
00000078 e33c0001 teq r12,#0x00000001
0000007c 010fc000 mrseq r12,cpsr
00000080 038cc0c0 orreq r12,r12,#0x000000c0
00000084 0129f00c msreq cpsr:cf,r12
00000088 0affffe3 beq 0x0000001c
0000008c e3a000df mov r0,#0x000000df
00000090 e129f000 msr cpsr:cf,r0
00000094 e3a04301 mov r4,#0x04000000
00000098 e5c44208 strb r4,[r4,+0x208]
0000009c eb00000f bl 0x000000e0
000000e0 e3a000d3 mov r0,#0x000000d3
000000e4 e129f000 msr cpsr:cf,r0
000000e8 e59fd0d0 ldr sp,[pc,+0x0d0] =0x03007fe0
000000ec e3a0e000 mov lr,#0x00000000
000000f0 e169f00e msr spsr:cf,lr
000000f4 e3a000d2 mov r0,#0x000000d2
000000f8 e129f000 msr cpsr:cf,r0
000000fc e59fd0b8 ldr sp,[pc,+0x0b8] =0x03007fa0
00000100 e3a0e000 mov lr,#0x00000000
00000104 e169f00e msr spsr:cf,lr
00000108 e3a0005f mov r0,#0x0000005f
0000010c e129f000 msr cpsr:cf,r0
00000110 e59fd0a0 ldr sp,[pc,+0x0a0] =0x03007f00
00000114 e28f0001 add r0,pc,#0x00000001
00000118 e12fff10 bx r0
0000011c 2000 mov r0,#0x00
0000011e 4958 ???
r0:00000000 r1:00000000 r2:00000000 r3:00000000 r4:04000000 r5:00000000 r6:00000000 r7:00000000 cpsr:nZcv
r8:00000000 r9:00000000 r10:00000000 r11:00000000 r12:00000000 sp:03007f00 lr:000000a0 pc:00000122 spsr:----
2012-03-19 - bsnes_v087r04.tar.bz2
GBA stuff re-added. Only thing missing that was there before is the ARM branch opcode.
Since we're going to be staring at it for a very long time, I added a more interesting test video pattern.
Went from 6fps to 912fps. Amazing what being able to divide can do for a frame rate.
2012-03-19 - bsnes_v087r03.tar.bz2
Fixing the PPU stepping increased FPS to 250. Promising, at least, since the ARM core is still severely overclocked.
However, I reverted back to r02. This one patches gameboy/ and GameBoy:: to gb/ and GB:: and that's it.
Sorry, I just couldn't shake this bad feeling about the code. There were some poorly hacked-together constructs. I'd rather just redo two days of work than feel bad about the codebase for the next several years. Going to attempt the GBA bridge again. Third time's a charm, I suppose (there was a pre-r03 WIP I abandoned as well.)
This isn't unprecedented, GB core took a few attempts like this as well.
2012-03-18 - 2zb.rat.40r780v_sensb
Changelog:
gameboy/ -> gb/
GameBoy -> GB
basic memory map for GBA
enough code to execute the first BIOS instruction (b 0x68)
I have the code resetting r(15) to 0 on an exception just as a test. Since that flushes the pipeline, that means we're basically executing "b 0x68" at 8MHz, and nothing else.
... and I am getting 6 motherfucking FPS at 4.4GHz on an i7.
Something is seriously, horribly, unfuckingbelievably wrong here, and I can't figure out what it is.
My fully complete ARM core on the ST018 is even less efficient and runs at 21.47MHz, and yet I get 60fps even after emulating the SNES CPU+PPU @ 10+MHz each as well.
... I'm stuck. I can't proceed until we figure out what in the holy fuck is going on here. So ... if anyone can help, please do. If we can't fix this, the GBA emulation is dead.
I was able to profile on Windows, and I've included that in this WIP under out/log.txt.
But it looks normal to me. But yeah, there's NO. FUCKING. WAY. This code should be running this slowly.
2012-03-12 - 2zb.rat.30r780v_sensb
I wanted to keep this a secret, but unlike other recent additions, this will easily take several weeks, maybe months, to show anything.
Assuming I can even pull it off. Nothing technically overwhelming here, I'm more worried about the near-impossibility of debugging the CPU.
So that would kill all WIPs until then, which would kind of suck. Well, that's open source for you I guess.
Let's at least try and keep it a secret, please. No 'hinting', etc. There's a good chance I'll give up on this, so we'll see.
If anyone is interested in co-developing this with me, I'd love the help. A lot of stuff is unclear already.
So is the current CPU mode always stored in CPSR::M? Then what is stored in the various SPSR::M values?
Current batshit insanity: in cpu.cpp, there is a line "apu.clock -= clocks;".
If I uncomment that, the framerate drops from 720fps to 140fps.
Running -pg binaries is hanging on me, so I can't tell what the holy fuck is going on there. But 4M subtractions a second should not cause a 500% speed hit.
Would also appreciate any help in tracking down what is going on there.
2012-03-10 - bsnes_v087r02.tar.bz2
Changelog:
extended USART with quit(), readable(), writable() [both emulation and hardware]
quit() returns true on hardware when Ctrl+C (SIGINT) is generated (breaks main loop); no effect under emulation yet (hard to simulate)
readable() returns true when data is ready to be read (non-blocking support for read())
** writable() returns true when data can be written (non-blocking support for write()) [always true under emulation, since we have no buffer size limit]
They really don't make it easy to determine if a file descriptor has data ready to be read ... took me a long while to figure out how to use select() for that.
2012-03-10 - bsnes_v087r01.tar.bz2
Changelog:
fixes ARM core unaligned memory reads (fixes HNMS2 AI, hopefully completely, we'll see though) [Cydrak]
ARM 40000010 writes are now connected to d2 rather than the timer
ARM bus_readbyte() removed (would love to do the same for writebyte if we can ... then we can drop back to bus_read + bus_write only)
USART with IObit set acts as a regular gamepad now (don't have this hooked up with real hardware, but oh well, it's technically possible so there's that)
OpenGL/GLX will use 30-bit when you have a 30-bit display; no need for config file video.depth anymore
2012-03-06 - bsnes_v087-source.tar.bz2
This release adds ST018 emulation. As this was the final unsupported SNES coprocessor, this means that bsnes v087 is the first SNES emulator to be able to claim 100% known compatibility with all officially released games. And it does this with absolutely no hacks.
Again, I really have to stress the word known. No emulator is perfect. No emulator ever really can be perfect for a system of this complexity. The concept doesn't even really exist, since every SNES behaves subtly different. What I mean by this, is that every single game ever officially sold has been tested, and zero bugs (of any severity level) are currently known.
It is of course extremely likely that bugs will be found in this release, as well as in future releases. But this will always be a problem for every emulator ever made: there is no way to test every possible codepath of every single game to guarantee perfection. I will, of course, continue to do my best to fix newfound bugs so long as I'm around.
I'd really like to thank Cydrak and LostTemplar for their assistance in emulating the ST018. I could not have done it without their help.
The ST018 ROM, like the other coprocessor ROMs, is copyrighted. This means I am unable to distribute the image.
Changelog:
emulated the 21.47MHz ST018 (ARMv3) coprocessor used by Hayazashi Nidan Morita Shougi 2
fixed PPU TM/TS edge case; fixes bottom scanline of text boxes in Moryo Senki Madara 2
fixed saving and loading of Super Game Boy save RAM
NEC uPD7725,96050 ROMs now stored in little-endian format for consistency
cartridge folder concept has been reworked to use fixed file names
added emulation of serial USART interface (replaces asynchronous UART support previously)
2012-03-06 - bsnesv086r16.tar.bz2
Cydrak, I moved the step from the opcode decoder and opcodes themselves into bus(read,write)(byte,word), to minimize code.
If that's not feasible for some reason, please let me know and I'll change it back to your latest WIP.
This has your carry flag fix, the timer skeleton (doesn't really work yet), the Booth two-bit steps, and the carry flag clear thing inside multiply ops.
Also added the aforementioned reset delay and reset bit stuff, and fixed the steps to 21MHz for instructions and 64KHz for reset pulse.
I wasn't sure about the shifter extra cycles. I only saw it inside one of the four (or was it three?) opcodes that have shifter functions. Shouldn't it be in all of them?
he game does indeed appear to be fully playable now, but the AI doesn't exactly match my real cartridge.
This could be for any number of reasons: ARM CPU bug, timer behavior bug, oscillator differences between my real hardware and the emulator, etc.
However ... the AI is 100% predictable every time, both under emulation and on real hardware.
2012-03-01 - bsnes_v086r15.tar.bz2
Most importantly ... I'm now using "st018.rom" which is the program ROM + data ROM in one "firmware" file.
You'll need to get the second archive and put it in the same folder as your HNMS2 ROM.
Since all three Seta DSPs have the ST01N stamp, unlike some of the arcade variants, I'm just going to go with ST01N from now on instead of ST-001N.
I was using the latter as that's what Overload called them.
Moving on ...
The memory map should match real hardware now, and I even match the open bus read results.
I also return the funky 0x40404001 for 60000000-7fffffff, for whatever that's worth.
The CPU-side registers are also mirrored correctly, as they were in the last WIP, so we should be good there.
I also simulate the reset pulse now, and a 0->!0 transition of $3804 will destroy the ARM CPU thread.
It will wait until the value is set back to zero to resume execution.
At startup, the ARM CPU will sleep for a while, thus simulating the reset delay behavior.
Still need to figure out the exact cycle length, but that's really not important for emulation.
Note in registers.hpp, the |4 in status() is basically what allows the CPU program to keep going, and hit the checkmate condition.
If we remove that, the CPU deadlocks. Still need to figure out how and when d4 is set on $3804 reads.
I can run any test program on both real hardware and in my emulator and compare results, so by all means ... if you can come up with a test, I'll run it.
2012-03-01 - bsnes_v086r14.tar.bz2
Attempted to fix the bugs pointed out by Cydrak for the shifter carry and subtraction flags. No way to know if I was successful.
The memory map should exactly match real hardware now.
Also simplified bus reading/writing: we can get fancy when it works, I suppose.
Reduced some of the code repetition to try and minimize the chances for bugs.
I hopefully fixed up register-based ror shifting to what the docs were saying.
And lastly, the disassembler should handle every opcode in every mode now.
ldr rn,[pc,n] adds (pc,n) [absolute address] after opcode. I didn't want to actually read from ROM here (in case it ever touches I/O or something), but I suppose we could try anyway.
At startup, it will write out "disassembly.txt" which is a disassembly of the entire program ROM.
If anyone wants to look for disassembly errors, I'll go ahead and fix them. Just note that I won't do common substitutions like mov pc,lr == ret.
At this point, we can make two moves and then the game tells us that we've won.
So ... I'm back to thinking the problem is with bugs in the ARM core, and that our bidirectional communication is strong enough to play the game.
Although that's not perfect. The game definitely looks at d4 (and possibly others later), but my hardware tests can't get anything but d0/d3 set.
2012-02-28 - bsnes_v086r13.tar.bz2
That's my best implementation of the shifter carry. It's horribly inefficient and possibly wrong (especially on ROR by register, but that doesn't ever appear to be used in this program), but oh well. It's the best I can do.
Game is basically getting stuck after a board upload and issuing another command. It's sitting in a loop waiting on $3804.d0 to be set, meaning the ARM is never writing anything for the CPU to read. There's some chance that my $3804/r40000000 flags are wrong. Short of guessing though, I'm not sure how we can get more info on how those work.
... I really can't debug this any better than I have. If no one else sees anything, then we're going to have to give up and wait for MESS to create opcode logs for us to compare against.
ARM is stuck in the below code, it looks like ... although it's really hard to tell since it fucking logs 200+MB of instructions per second. The command is 0xad, for whatever that's worth.
Code:
r0:00000000 r1:00000000 r2:0001d890 r3:00000000 r4:00000226 r5:00000158 r6:e0001640 r7:0001e090
r8:e000168c r9:00000000 r10:00000016 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000d6e8
cpsr:nZCv
0000d6e0 e3100040 tst r0,#0x00000040
return 0;
}
Code:
0xf3.bin[0:1f440] = ecf28ee0
0xf4.bin[0:05100] = bd8a23a5
0xf3.bin[0:20000] = ecf28ee0
0xf4.bin[0:08000] = a75e50f8
F3 has null data at the end of the file, thus its checksum is ecf28ee0 @ 1f440 and ecf28ee0 @ 20000.
F4 does not have null data at the end, thus its checksum is bd8a23a5 @ 5100 and a75e50f8 @ 8000.
So yes, random as it may appear ... both dumps are perfectly valid.
So I guess F4 is also ROM ... I'll rename it to dataROM for now.
For v087, I'm going to seed st0018.rom as the two ROMs appended together, like I do for the uPD chips and FEoEZ ROM. It'll be a 160KB file.
But until then, we'll leave it as st0018.rom and st0018d.rom, as we have it now.
And now with MUL/MLA supported, we're back to no invalid ops (that we know of) being executed ... so it's just some CPU bugs preventing the game from running fully.
2012-02-28 - bsnesv086r11.tar.bz2
I'm ... really not following this at all ><
I've uploaded a new WIP. It completes F1 (test), F2 (test), and AA (9x9+16 board upload.)
It runs B3 (checkmate), but is telling the CPU that checkmate has occurred as soon as you start a new game.
It's not hitting any missing opcodes, so I can only guess there are CPU bugs.
Also, my implementation of the status register isn't exactly right.
It seems for the board upload, it waits for $3804.d4 (&#$10) = 0.
If I set that to !armtocpu.ready, the game dies with ST0018 fail right at power-on.
So I'm not really sure how all the flags work right now.
It does seem to be properly handshaking, though. You can see the ST0018 telling the CPU how many bytes are remaining in the upload after each write.
Also ... if you put the 32K file in the same folder as st0018.rom, and name it st0018d.rom, it will load that into a000:0000-7fff.
The game seems to read from it at power-on, but never writes to it. I'm not sure what's up with that right now.
And I'm going to sleep. I'm pretty much stuck here, so I could realllllly use some help :/
2012-02-27 - bsnes_v086r10.tar.bz2
More ARM work. ARM core now begins to act upon initial 0xf1 command, but hangs.
2012-02-26 - bsnes_v086r09.tar.bz2
A lot more work on the ARMv3 core.
2012-02-26 - bsnes_v086r08.tar.bz2
Contains the fledgling beginnings of an ARM CPU core, which can execute the first three and a half instructions of the ST-0018.
It's a start, I guess.
2012-02-23 - bsnes_v086r07.tar.bz2
USART improvements. The clock pulse from reading data() drives both reading and writing.
Also added a usart_init() to bind the initializer functions, so all you need now is:
extern "C" usartproc void usart_main() { ... }
And inside, you use usart_read(), usart_write(), etc.
So we can add all the new functions we want (eg I'd like to have usart_readable() to check if data is available) without changing the entry point signature.
blargg enhanced his Teensy driver to ignore frame error reads, as well.
2012-02-22 - bsnes_v086r06.tar.bz2
It is done. bsnes can now emulate sending and receiving data via USART. As such, the UART code has been removed.
The final UART code can be downloaded here: http://byuu.org/snes/uart/
I won't maintain it going forward, because nobody ever used it, and USART is superior in every way.
I've also verified both sending and receiving on the real SNES now :D
It's so easy ... a caveman with electrical engineering and computer programming experience can do it.
2012-02-22 - bsnes_v086r05.tar.bz2
USART implements reading and writing, but I don't yet have code to test SNES reading yet.
So ... obviously I need to do that next.
Went ahead and required nall::function, so the modules will have to be C++11. I don't see anyone else making these, and it avoids the annoyance of deducing the correct controller port based on dynamic casting the active thread.
Apparently a library can have a main() function to no ill effect, so there's no need for USART_HARDWARE. Same exact code with different flags will make the binary and the library.
2012-02-21 - bsnes_v086r04.tar.bz2
There will probably be a series of small WIPs as I experiment here.
snes/controller/serial is now snes/controller/uart. Asynchronous serial communications, typically capped at 57,600 baud.
snes/controller/usart is new. It aims to emulate the SNES connected to a Teensy++ board, and can easily handle 524,288 baud.
And much more importantly, it's synchronous, so there are no timing issues anymore. Just bit-bang as fast as you can.
Right now, the USART code is just enough for SNES->PC to transfer data to ... well, nothing yet.
Unless anyone is actually using the UART stuff, I'll be removing it once the USART is totally up and running.
No sense maintaining code that is 10x slower, more error prone, and used by nobody.
Note: this is all thanks to blargg being absolutely amazing.
2012-02-17 - bsnes_v086r03.tar.bz2
Cart unload save path was using the new game rather than the old game.
Caused by trying to allow a failed cartridge load to not unload the current game.
But that's so uncommon that it's not worth worrying about. It'll always unload before trying to load a new game now.
Removed the TM/TS disable speedup, to fix Madara 2's text boxes.
This actually did cause a slight performance penalty on games that disable layers via TM/TS. Zelda 3 inside Link's house is a good example.
It knocked the FPS from 98.5 to 94.5. So to counter that, I removed conditionals from tiledata loading and decoding, and used fall through switches.
This boosted us back to 97.0. The -march=native flag apparently works better with SB now, so that was added, putting us up to 99.0fps.
So it should be the same speed in the worst case, and slightly faster in the best case.
Bumped the pre-render time to 68 clocks from 60 clocks. Adjusted sprite tile fetch time from 22 to 14 to compensate.
This should give us perfectly stable Dai Kaijuu Monogatari 2 battles.
2012-02-15 - bsnes_v086r02.tar.bz2
Fixed Super Game Boy RAM saving and loading. It plainly wasn't hooked up at all. Was apparently hard-coded before it became a multi-emulator.
I also fixed a crashing issue when loading Satellaview-slotted or Satellaview games without specifying the sub-cart, wasn't setting has_bsx_slot = true, so the raw memory wasn't being allocated internally when it wasn't mapped in. Of course a better fix would be to just not physically map the ranges if the things aren't present. Kind of a lazy hack to map blank cartridges there, but oh well.
Oh, fixed title displays as well; and did the best I could for now with regards to multi-file path saving.
Basically, Satellaview-slotted and Sufami Turbo modes need special handling for cheats.xml and states.bsa.
Your cheat codes may apply to where the two different ST games are mapped in currently, or your save state may be dependent upon the Tengai Makyou pack being loaded into Same Game. Storing the cheats.xml in either the base or one of the slot folders isn't enough. The base can have different slotted carts, and the slotted carts can be put in different configurations or into different cartridges.
We need something like this:
Code:
Base (US).sfc/
Slot 1 (US).bs + Slot 2 (US).bs/
cheats.xml
state-1.bsa
Slot 1 (US).st/
Slot 2 (US).st/
... but I really don't want to jump through a million hoops to make that happen. So for now, these two modes are rare enough that I'll just have them store to the first child slot. Use cheats and states on them at your own risk. Once we enforce folder loading across the board, I can simplify things and do the above, no problem.
Aside: the complexity really has to stop here. bsnes is starting to get overwhelming for just me alone. The abstractions needed to support multiple systems at a time (and I want that very much, fuck having five different GUIs) is really starting to get hard to keep in order in my head.
2012-02-15 - bsnes_v086r01.tar.bz2
The goals for v087 are to have a unified cartridge-folder concept, as well as a more functional SNES debugger.
Starting with the cartridge folders. What I have so far:
Code:
NES:
program.rom
character.rom
program.ram
…
SNES:
program.rom
program.rtc
data.rom (SPC7110)
{ dsp1.rom, dsp1b.rom, cx4.rom, … }
msu1.rom
track-#.pcm
Game Boy, Game Boy Color:
program.rom
program.ram
program.rtc
Sub-cartridges (BS-X, Sufami Turbo, …) are stored as separate folders
Folder names must be UTF-8 based, with all-lowercase extensions
File names must be all-lowercase
SNES:
"program.ram" (.srm, .sts)
"msu1.rom" (name.msu)
"track-#.pcm" (name-#.pcm)
"upd96050.ram" -> "name.ram"
"bsx.ram" (.bss)
"bsx.psram" (.bsp)
"serial.so" -> "libserial.so" (broken)
Need:
Super Game Boy (not even sure how this loads and saves memory, it's obviously broken)
And I need to think of some way of handling multi-cart loaded games.
Eg Satellaview-slotted and Sufami Turbo. It was { base + slot ( + slot ... } }, but this gets trickier with folders and fixed names.
Actual markup for the NES needs to change as well.
2012-02-13 - bsnes_v086-source.tar.bz2
The main focus of this release is Laevateinn, which is the new bsnes debugger. Unlike previous debuggers, Laevateinn is a standalone application with its own GUI entirely focused on debugging.
Changelog:
created ui-debugger target (Laevateinn)
fixed multitap ports 2-4 [quequotion]
fixed ui-libsnes target compilation
fixed a crashing issue with NSS XML markup
improved cartridge-folder loading support
NES can now load .fc (headerless NES) or .prg+.chr (split NES) images
fixed cursor being visible in fullscreen mode when using Linux/Metacity window manager [ncbncb]
show normal cursor when using Linux/SDL video driver [ncbncb]
added menu accelerators
fixed a bug in performance profile SMP incw/decw instructions
SNES core can now optionally be built without Game Boy emulation core
added 2012-02-04 cheats.xml database [mightymo]
2012-02-12 - bsnes_v085r09.tar.bz2
See debugger thread for changes.
../emus/bsnes/laevateinn_v085r09.tar.bz2
Includes Windows 64-bit binary (in the out/ folder) and source code.
You'll have to patch phoenix to compile on 32-bit mode.
Finally figured it out: TDM/GCC 32-bit lacks updated Win32 Platform API headers, whereas the 64-bit version does not. Isn't that fun?
./sshots/laevateinn_v085r09.png
Added VRAM viewer (mouse over to get tile# and VRAM address), CPU+SMP register editors, settings.cfg to cache path+sync audio+mute audio settings (Windows Vista+ ignore my request for the default folder because they are fucking stupid, so they always default to your home folder. I'm going to have to recommend using a batch file to start laevateinn there. Sorry, blame Microsoft for being fuck-ups), geometry.cfg to remember where you placed windows and what size you made them (a bug in Qt prevents me from making some windows fixed-size for now, but that'll change when I can work around the Qt issue), usage map invalidation if the ROM was modified after the usage files, that empty line insertion thing creaothceann wanted on emulation resume, all chips now synchronize immediately rather than just-in-time, which is important for a debugger.
Going to postpone the properties viewer until after v086.
2012-02-11 - bsnes_v085r08.tar.bz2
Changelog:
follow the Laevateinn topic to get most of it
also added NMI, IRQ step buttons to CPU debugger
also added trace masking + trace mask reset
also added memory export
cartridge loading is entirely folder-based now
Test binary - Windows amd64 accuracy profile: (you need 64-bit Windows!!)
../emus/bsnes/laevateinn_v085r08.7z
You'll have to resize the windows a bit, based on your font. I'm still doing manual sizing that's optimal for Linux right now.
./sshots/laevateinn_v085r08.png
Added SMP/PPU breakpoints, SMP debugger, SMP stepping / tracing, memory editing on APU-bus / VRAM / OAM / CGRAM, save state menu, WRAM mirroring on breakpoints, protected MMIO memory regions (otherwise, viewing $002100 could crash your game.)
Major missing components:
trace mask
trace mask clear / usage map clear
window geometry caching / sizing improvements
VRAM viewer
properties viewer
working memory export button
The rest will most likely appear after v086 is released.
EDIT:
Forgot to connect the PPU events to the core. So PPU breakpoints won't work on this binary, sorry.
Added NMI and IRQ buttons to the CPU debugger. Clicking them seeks you to the respective interrupt entry points.
Added trace masking and trace mask reset.
Added memory export for all memory modes.
Cartridge loading is now folder-based.
2012-02-10 - bsnes_v085r07.tar.bz2
Changelog:
stuff
./sshots/laevateinn_v085r07.png
Breakpoints now work on CPU { Read, Write, Exec }. They have next-to-zero overhead now.
Rather than testing all possible breakpoints in linear fashion, I build vector lists for all possible combinations.
So if you only have one CPU read breakpoint, CPU writes won't bother testing anything.
The whole thing is honestly designed for speed. I can easily run the accuracy core at >60fps here.
But of course, the fact that I won't support the debugger in compatibility mode will be problematic for people without i7's.
Maybe someone here can patch PPU-compatibility or something.
The usage maps are back. They are necessary for proper forward+backward disassembly.
They're saved across runs. I will probably get fancier at some point and do a timestamp check to invalidate the usage maps if the ROM was modified.
Decided against having gamename-bla.ext for every debugger file. Enforcing my folder-style, sorry.
Say you have /path/to/Zelda (U).sfc/{ SFC, SRM, etc. }
It will make: /path/to/Zelda (U).sfc/debug/ { usage.cpu, usage.apu, trace-NNN.log, etc. }
Again, this is what I meant by personal project. Doing things my way. If you guys don't like these types of choices, I'll welcome a fork that changes things up to be more mainstream.
Now, for the CPU debugger ... "Step Into" will run until the next CPU opcode edge and then break. Whereas the console "Step" will run until the next enabled chip under the debug menu hits an instruction. The other commands are more problematic, and disabled for now. See, bsnes is a sub-cycle-accurate emulator. That means that you can be in the middle of an opcode when the emulator is paused. You obviously cannot skip a half-executed opcode.
Worst case, you will have to hit "Step Into" once to align it to an opcode edge, and then you can use the other commands. Once they're implemented. Not sure if they'll make it to the first official release.
So ... major things missing:
SMP/PPU breakpoints
SMP debugger
SMP stepping / tracing
memory editor on APU-bus / VRAM / OAM / CGRAM
save state menu
window geometry memorization
trace mask
WRAM mirroring on breakpoints
Nice things missing:
global hotkeys
key configuration
properties viewer for each processor
trace mask / usage map flush
tilemap / spritemap / tiledata viewers
Nice to dream things missing:
register editors
mosaic integration
bass integration
symbol integration into disassemblers
step (over, out); skip
trace for N opcodes
2012-02-08 - bsnes_v085r06.tar.bz2
Lots of debugger enhancements. Memory editor works for CPU-bus only, breakpoint editor does nothing yet.
Tracing works, writes to 001-999 files sequentially. Stepping works, too. But only on the CPU.
Added "privileged", which becomes "public" if DEBUGGER is defined, "private" otherwise.
Meant so the debugger can stab deeply into the cores for state manipulation. Interface is guaranteed to be unstable and dependent upon the accuracy core.
The about screen logo adds 100KB onto the source download (won't affect regular bsnes binaries), but too bad. I want some visual flair this time.
Debugger so far is looking incredibly awesome, at least to me: http://i.imgur.com/rEpr6.png
2012-02-06 - bsnes_v085r04.tar.bz2
Changelog:
added base/ folder
base/base.hpp defines the version number for all UI targets, all the varint-types, and a hook() class for debugger functions (see below)
fixed compatibility profile compilation
removed within<> template from the SNES target
the SNES core can be built without Game Boy support now, if you so choose (my SNES debugger is not going to support debugging the GBZ80, sorry.)
added ui-debugger; not at all useful right now, will be a long while to get something usable ready
So hook is a class wrapper around nall::function. It allows you to invoke potentially empty functions (and as such, the return type must have a trivial constructor.)
It also doesn't actually perform the test+invocation when DEBUGGER (options=debugger) is not defined. So you should have no overhead in regular builds.
The core classes now have a subclass with all the debugging hooks, so you'll see eg:
Code:
void CPU::op_step() {
debugger.op_exec(regs.pc);
(this->*opcode_table[op_read()])();
}
Clear what it's doing, clear what it's for. A whole lot less work than inheriting the whole CPU core and virtualizing the functions we want to hook.
All the logic for what to do inside these callbacks will be handled by individual debuggers, so they can have all the functionality they want.
I may also add a debugonly #define that becomes "public" for the debugger, and "private" otherwise. That way the debugger can really prod into internal state at will, with the obvious caveat that the interface is subject to change.
2012-02-04 - bsnes_v085r03.tar.bz2
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-01-25 - bsnes_v085r02.tar.bz2
Fixed NSS XML crashing issue.
Improved folder-loading support.
NES can now load game.fc/game.fc, or game.fc/game.prg+game.chr.
Both types should have no iNES header at all.
And both types require an XML file (until we have a built-in database.)
Windows users: if you compile your own build with the options := console enabled, it will print any iNES mapping string to the terminal for you, so you can see how to generate your own XML.
2012-01-14 - bsnes_v085r01.tar.bz2
Changelog:
updated bsnes to use the newest versions of nall and phoenix
fixed ui-libsnes compilation (testing would be a good idea, especially the cheat codes. I just copy-pasted that from the regular UI.)
fixed multitap controllers 2-4 [quequotion]
2012-01-02 - bsnes_v085-source.tar.bz2
A new release for the new year.
Changelog:
fixed auto joypad polling edge case; fixes Ys 5 controls
fixed Justifier polling code; Lethal Enforcers should be fully responsive once again
rewrote SNES S-SMP processor core (~20% code reduction)
fixed Game Boy 8x16 sprite mode; fixed some sprites in Zelda: Link's Awakening
treat Game Boy HuC1 RAM enable flag as writable flag instead; fixes Pokemon Card GB
created far faster XML parser; bsnes can now load XML files once again
updated to mightymo's most recent cheat code database
internal color calculations now performed at 30-bits per pixel
gamma slider now acts as fine-tuned gamma ramp option
Linux OpenGL driver will output at 30bpp on capable displays
Linux port defaults to GTK+ now instead of Qt (both are still available)
So that we can also find results with the github search and do not have to search on another site. Source: https://gitlab.com/higan/bsnes-history-kit/-/blob/master/sources/tukuyomi/misc/bsnes_changelog.txt
Compiled using infos found on byuu's homepage and forums (http://byuu.org), on bsnes Dev Talk (http://board.zsnes.com/phpBB3/viewforum.php?f=22) and on the old bsnes thread (http://snesemu.black-ship.net/misc/archives/bsnes_thread.zip)
2012-08-10 - bsnes_v091-source.tar.xz A few issues crept up in the last release, this should take care of them. First, it seems that the 32-bit runtime on 64-bit versions of Windows have 64-bit time functions; whereas true 32-bit Windows does not. This was causing a DLL error when attempting to load bsnes v090. Second, when there were more than 2,000 files in the same folder on Windows, it was lagging the file browser. With OV2's help, I've fixed that and it'll now load the list instantly. Lastly, I've included the missing video shaders this time.
2012-08-07 - bsnes_v090-source.tar.xz Most notably, this release adds Nintendo DS emulation. The Nintendo DS module was written entirely by Cydrak, so please give him all of the credit for it. I for one am extremely grateful to be allowed to use his module in bsnes. The Nintendo DS emulator's standalone name is dasShiny. You will need the Nintendo DS firmware, which I cannot provide, in order to use it. It also cannot (currently?) detect the save type used by NDS games. As such, manifest.xml files must be created manually for this purpose. The long-term plan is to create a database of save types for each game. Also, you will need an analog input device for the touch screen for now (joypad axes work well.) There have also been a lot of changes from my end: a unified manifest.xml format across all systems, major improvements to SPC7110 emulation, enhancements to RTC emulation, MSU1 enhancements, icons in the file browser list, improvements to SNES coprocessor memory mapping, cleanups and improvements in the libraries used to build bsnes, etc. I've also included kaijuu (which allows launching game folders directly with bsnes) and purify (which allows opening images that are compressed, have copier headers, and have wrong extensions); both of which are fully GUI-based. This release only loads game folders, not files. Use purify to load ROM files in bsnes. Note that this will likely be the last release for a long time, and that I will probably rename the emulator for the next release, due to how many additional systems it now supports.
2012-08-06 - bsnes_v089r18.tar.bz2 Changelog:
2012-07-15 - bsnes_v089r17.tar.bz2 purify_v00r06.tar.xz (no Windows binary, you have to compile it yourself) This implements the spec from the XML part 3 thread (http://board.byuu.org/viewtopic.php?f=16&t=2998) It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-10 - bsnes_v089r16.tar.bz2 Changelog:
2012-07-09 - bsnes_v089r15.tar.bz2 Changelog:
2012-07-08 - bsnes_v089r14.tar.bz2 Changelog:
Star Ocean (SDD1): Code: <?xml version="1.0" encoding="UTF-8"?>
(The S-DD1 is the memory mapper; so even though RAM is mapped constantly, it is still behind the S-DD1 on the board.) Kirby's Dreamland 3 (SA1): Code: <?xml version="1.0" encoding="UTF-8"?>
Far East of Eden Zero (SPC7110): [incomplete] Code: <?xml version="1.0" encoding="UTF-8"?>
I have tried multiple times now to get the SuperFX core to use internal ROM and RAM (separate from Cartridge::ROM, RAM) to no avail. Not sure what the hell is going on there. Trace logs of 430MB are not enticing ... So right now: SuperFX, SPC7110 and BS-X cheat by mapping stuff to Cartridge::ROM, RAM still. They need to not do that.
2012-06-25 - bsnes_v089r13.tar.bz2 Fixes up loading issues with recent purify changes, and purify also works on BS/ST file types now and should be a bit more crash-resistant.
2012-06-17 - bsnes_v089r12.tar.bz2 Changelog:
2012-06-05 - bsnes_v089r11.tar.bz2 Changelog:
2012-05-30 - bsnes_v089r10.tar.bz2 Changelog:
2012-05-28 - bsnes_v089r09.tar.bz2 Changelog:
2012-05-27 - bsnes_v089r08.tar.bz2 Changelog:
2012-05-25 - bsnes_v089r07.tar.bz2 Not even purify makes compatible images for this WIP. Unless you want to figure it out yourself, I'd suggest waiting for an updated tool before using subsequent WIPs. Changelog:
2012-05-24 - bsnes_v089r06.tar.bz2 I had some bugs in r07 that I couldn't track down, DKJM2's clock was getting all out of sync. So I just reverted to r05, blew away both RTCs entirely, and wrote them cleanly from scratch (obviously looking off the old code.) A bit extreme, but it worked. I believe I found the error in the process, day and month were resetting the counter to 0 instead of 1, it wasn't handling leap year, etc. While I was at it, I fixed the day-of-week calculation. The SharpRTC epoch is actually 1000-01-01, and not 1900-01-01. I'm sure you guys will be really happy that if it ever becomes 1000AD again and you're playing a ROM hack that uses the SharpRTC and relies on its weekday value that it will show the correct day now ... Kind of a pain to compute, but nothing compared to the seventh circle of hell that was my IBM dBase III Julian<>Gregorian conversion functions :/ Also found a few bugs in the Epson code this way. And I moved the round seconds actions and flag clear to +125us after flag set. So, if you had the old r06 or r07, please delete those. Unfortunately, this took all of my energy today, so the file names inside manifest changes will have to be in the next WIP. EDIT: ran a diff against old r07 and new r06.
2012-05-22 - bsnes_v089r07.tar.bz2 Changelog:
2012-05-21 - bsnes_v089r06.tar.bz2 Changelog:
2012-05-20 - bsnes_v089r05.tar.bz2 I split the RTC-4513 code from the SPC7110 code (and obviously in the XML mapping as well), since they are separate chips on the FEoEZ PCB. In this way, you can use just the RTC-4513 in homebrew now if you want. It's a bit nicer than the Sharp RTC from Dai Kaijuu Monogatari II. This was needed anyway, it has an internal oscillator that's not divisible by the SNES clock used by the SPC7110; and both the RTC and decompression code need to be running their own threads anyway. In the process, I rewrote the way variables are stored to use named integers rather than a block of memory. Makes the code a lot easier on the eyes, and more importantly, will make emulating bad BCD values a whole lot easier.
2012-05-18 - bsnes_v089r04.tar.bz2 Changelog: (SPC7110)
2012-05-15 - bsnes_v089r03.tar.bz2 Substantial improvements to SPC7110 emulation. Added all of the findings from http://byuu.org/temp/spc7110-mmio.txt that I understood. I also completely rewrote the RTC. We only had about ~40% of the chip emulated before. Turns out there's cool stuff like spare RAM, calendar disable, 12-hour mode, IRQs, IRQ masking, duty cycles, etc. So I went ahead and emulated all of it. The upper bits on hour+ don't work as nocash described though, not sure what doc he was reading. The Epson RTC-4513 manual I have doesn't explain any of the registers. The new RTC core also ticks seconds based on the emulated clock, and not on the system clock. This is going to suck for people wanting to keep the in-game clock synced with their computer, who also abuse fast forward and save states. Fast forward makes the clock run faster, and save states will jump the clock to the time it was at when you took the save state. (It will keep track of the number of seconds between unloading the game and loading it again, so time passes normally there.) This is required, however, and how I'm going to rearrange all of the RTCs for all systems. Any other method can be detected by the game, and is thus not faithful emulation. To help with this, I'll probably make an RTC time tool so that you can adjust the time when the emulator isn't running, but I don't intend to bundle that into bsnes. New state format bit-packs the RTCRAM values, and it also uses a 64-bit timestamp. So it's 16 bytes now instead of 20 bytes. S-RTC will drop from 16 to 12 when it's done. The RTC busy flag timing needs to be refined with more hardware tests, there's a slim chance of the game hanging on save at the moment. The SPC7110 ALU delays are emulated now, too. They may not be perfectly accurate, but they get the basic gist down. The only hack that needs to be removed now is the decompression busy flag. That's ... not going to be fun. I also redid the mouse emulation. I was polling the mouse position multiple times per latch. So it should be a bit more precise now, I hope. I read it regardless of latch state, dunno if that's good or not.
2012-05-13 - bsnes_v089r02.tar.bz2 r02 changelog:
2012-05-13 - bsnes_v089r01.tar.bz2 r01 changelog:
2012-05-11 - bsnes_v089.tar.xz This release is going to be unique from previous releases. I am only recommending that developers use this version. As such, only the source archive has been posted. I strongly recommend against Linux package maintainers updating to this build. Casual users should wait for the next release. This release introduces a brand new user interface. It looks and functions exactly like the previous release, but it is built entirely on a declarative model: the GUI does not know about any individual systems that it supports. It pulls all of this information from a vector of emulated system objects instead. With the same amount of functionality, the new GUI is 66% smaller than the old GUI, code-wise. In fact, it actually does more. You can now easily add (and remove) entire systems from bsnes with only three lines of code. Input mapping is now more advanced and allows multiple bindings per input. But there is one critical thing it no longer does: the new GUI does not load individual ROM files. It requires the cartridge-folder concept that is still in development. It further requires a manifest to describe the PCB functionality. The code to handle both modes is cumbersome, and I did not wish to write it again. Right now, the problem is that we don't have user-friendly tools to make using cartridge folders easy. As such, this is why I've chosen not to release binaries this time. It's my hope that in the interim between v089 and v090, we can bring in developers willing to make the process completely transparent. And now is a perfect stopping point. Tom has just finished the English script translation for Far East of Eden Zero, so my efforts need to focus on reprogramming this game. This will require my absense from emulator programming for a while. Hopefully during that time, appropriate tools can be made for the next release. My hope is for v090 to be as easy to use as the old Qt releases were, with direct loading of compressed archives and headered images. That said, this release also fixes some reported emulation bugs. Mini Yonku Shining Scorpion was broken for a bit due to incorrect SA-1 register initialization. Air Strike Patrol surprises us with a second mid-scanline raster effect, which disproved an older theory of mine on the BG scroll registers, and is now emulated correctly as well. There is also a world of internal code restructuring. All processor instruction sets are separated from the functionality built on top of them (for instance, the ST018 and GBA can share core ARM instructions.) Now that libsnes has been superceded by libretro, I've moved to a complete emulator abstraction in C++ that works with all of my emulators. And last but not least, there's a new cheats.xml from mightymo bundled in this release as well. Changelog to v089:
2012-05-08 - bsnes_v088r16.tar.bz2 Changelog:
2012-05-07 - bsnes_v088r15.tar.bz2 Changelog:
2012-05-06 - bsnes_v088r14.tar.bz2 Changelog:
2012-05-06 - bsnes_v088r13.tar.bz2 Changelog:
2012-05-02 - bsnes_v088r11.tar.bz2 Changelog:
2012-04-30 - bsnes_v088r10.tar.bz2 ethos is going to be absolutely amazing. You guys are in for a treat :D I'm impressing the hell out of myself with how well-structured this code is, it's allowing me to do amazing new things. Just a small sampling of what's in store (and already implemented): The file browser will display folders as "[ folder name ]", and cartridge folders as "Game Name" (no extension, no /) [icons would be nicer, but well ... phoenix.] Folders are sorted above cartridge folders. Cartridge folders for other systems do not show up in the list. Not only are unique paths stored for each image type, your position in the list is saved across runs. Some voodoo was added to GTK+ so that all targets even scroll directly to that item when you open the list. Load->System->Enter restarts your last game. That sounds really simple and obvious, but it makes an -incredible- difference. Didn't realize it until I tried an implementation of it, wow. The input mapping list now lets you bind as many hotkeys as you want to any given input. So SFC::Port1::Joypad::B = Keyboard::Z or Joypad::Button1 ... no need to remap everything to switch between keyboard and joypad. Either one activates the key. There is a separate Hotkeys tab now. This should hopefully end the confusion about how to remap hotkeys that users experience. Hotkeys are different, too. Instead of OR logic, they use AND logic. So Fullscreen = Keyboard::Alt and Keyboard::Enter. Both must be pressed to enter the key. This lets you easily implement "super" modifier keys. The actual codebase has new features the old UI never had, and has about ~50% of the old functionality (so far, of course), yet is only ~25% as much code. The entire GUI no longer needs to pull in all the headers for each emulated system. It just needs a small interface header file. Then bind the entire system with exactly two lines of code. Everything is dynamically generated for you after that.
2012-04-29 - bsnes_v088r09.tar.bz2 Lots of work on ethos, nothing more. Settings window is in, InputManager pulls all the inputs from all cores and binds them to ruby inputs, main window adds menu and dynamically maps in all systems and cartridge slots and options and such, file browser's back in, RAM is loaded and saved, etc. It's barely usable, but you have to set up your inputs from the config file by hand for now.
2012-04-28 - bsnes_v088r08.tar.bz2 From this WIP, I'm starting on the impossible task of a declarative-based GUI, which I'm calling Ethos. base/ becomes emulator/, and we add emulator/interface.hpp, which is a base API that all emulation cores must implement in full. (Right now, it's kind of a hybrid to work with the old GUI and the new GUI at the same time, of course.) Unlike the old interfaces, the new base class also provides all general usability hooks: loading and saving files and states, cheat codes, etc. The new interface also contains information and vector structs to describe all possible loading methods, controller bindings, etc; and gives names for them all. The actual GUI in fact should not include eg <gba/gba.hpp> anymore. Should speed up GUI compilation. So the idea going forward is that ethos will build a list of emulators right when the application starts up. Once you've appended an emulator to that list, you're done. No more GUI changes are needed to support that system. The GUI will have code to parse the emulator interfaces list, and build all the requisite GUI options dynamically, declarative style. Ultimately, once the project is finished, the new GUI should look ~99% identical to the current GUI. But it'll probably be a whole lot smaller. Themaister should enjoy the new interface, since only a single wrapper will be needed for libretro to support all my emulation cores.
2012-04-28 - bsnes_v088r07.tar.bz2 (r05 and r06 were save points between large core modifications) I would really appreciate extensive regression testing (especially around SuperFX, Cx4, ST018, DSP-n, ST-01n, NES, GB) at this point. The most critical core changes should be completed now. And it was an unbelievable amount of restructuring. Changelog:
2012-04-27 - bsnes_v088r04.tar.bz2 This will hopefully be a short-lived WIP, I just want to save a breakpoint before I attempt something else. NES, GB, GBC and GBA all load via const stream& now. NES CPU core moved to Processor::RP2A03. EDIT: yeah, that failed. Was a wise idea to do a save point after all. Trying to split SuperFX instructions to GSU core opcodes, but that chip is -much- more entangled than any other core. Eg the PLOT instruction calls into the screen drawing stuff that handles the pixel buffer caches. The CACHE instruction needs memory caching access. There's no separation between MMIO registers and internal processing registers (if such a distinction even exists ...), so all MMIO regs need to go into the struct Regs {} for the CPU core. And ... blech. Not good at all. The other two remaining cores, SNES::CPU and SNES::SMP, are already split between core opcodes and functionality on top. The CPU was done for SA-1 long ago, and the SMP was split for consistency with it long ago as well. All I really have to do is move those folders and rename the classes. It's going to bug me to have seven of eight CPU cores split up, and have one glaring inconsistency ...
2012-04-27 - bsnes_v088r03.tar.bz2 static vector file::read(const string &filename); replaces:
static bool file::read(const string &filename, uint8_t *&data, unsigned &size);
This allows automatic deletion of the underlying data.
Added vectorstream, which is obviously a vector wrapper for a data stream.
Plan is for all data accesses inside my emulation cores to take stream objects, especially MSU1.
This lets you feed the core anything: memorystream, filestream, zipstream, gzipstream, httpstream, etc.
There will still be exceptions for link and serial, those need actual library files on disk. But those aren't official hardware devices anyway.
So to help with speed a bit, I'm rethinking the video rendering path.
Previous system:
2012-04-26 - bsnes_v088r02.tar.bz2 Really no reason to download this one unless you want to stay on the absolute bleeding edge of phoenix development. Basically, the current implementation of nall/array is deprecated now. The old method was for non-reference types, it acted like a vector for POD types (raw memory allocation instead of placement new construction.) And for reference types, it acted like an unordered set. Yeah, not good. As of right now, nall/array is no longer used. The vector type usage was replaced with actual vectors. I've created nall/set, which now contains the specialization for reference types. nall/set basically acts much like std::unordered_set. No auto-sort, only one of each type is allowed, automatic growth. This will be the same both for reference and non-reference types ... however, the non-reference type wasn't implemented just yet. Future plans for nall/array are for it to be a statically allocated block of memory, ala array<type, size>, which is meant for RAII memory usage. Have to work on the specifics, eg the size as a template parameter may be problematic. I'd like to return allocated chunks of memory (eg file::read) in this container so that I don't have to manually free the data anymore. I also removed nall/moduloarray, and moved that into the SNES DSP class, since that's the only thing that uses it.
2012-04-25 - bsnes_v088r01.tar.bz2 Code:
2012-04-24 - bsnes_v088-source.tar.xz As promised from the last news update, this release adds preliminary Game Boy Advance emulation. It's not perfect by any means, but it's one of the better first releases I've put out. It emulates all GBA functionality with the exception of the link cable and ROM prefetch buffer, although being a first release, there are bound to be plenty of bugs lurking in the core. I'd of course love some help with bugfixes, if anyone is interested =) It's important to note that the GBA emulation has not been optimized yet. The GBA is a more demanding system than the SNES, by way of a much faster CPU core and higher frequency audio. You can expect about ~150fps on average with a Core i7-class CPU for now, but please note that I do intend to improve upon this performance in future releases. For a bit of backstory: this is basically a byproduct of SNES ST018 emulation. This processor ended up using an ARMv3 CPU core. And since the GBA uses an ARMv4 CPU core, it seemed like a good choice: we could improve the ARM emulation for the ST018, and emulate the final 2D-based Nintendo system. In the end, it turned out to be harder than expected: it took about a month to complete the emulation core, and it was only this quick due to extensive help from Cydrak; who fixed numerous CPU bugs, emulated the affine and bitmap rendering modes, and also implemented the new GBA FIFO audio channel, among other things. On a side note, thanks to Cydrak and krom's hardware testing, we do have a nice milestone right out of the gate: proper OBJ mosaic emulation, which seems to be a first. At the very least, hopefully this will be helpful to other emulators. Note that you will need the GBA BIOS image to use this. There will not be any high-level emulation of the BIOS functions for obvious reasons. Name the file "bios.rom", and place it inside the "Game Boy Advance.sys" folder. Changes to v088:
2012-04-22 - bsnes_v087r30.tar.bz2 Changelog:
2012-04-20 - bsnes_v087r29.tar.bz2 Changelog:
2012-04-18 - bsnes_v087r28.tar.bz2 Be sure to run make install, and move required images to their appropriate system profile folders. I still have no warnings in place if those images aren't present. Changelog:
2012-04-17 - bsnes_v087r27.tar.bz2 Changelog:
2012-04-16 - bsnes_v087r26.tar.bz2 Changelog:
some ARM ops advance the prefetch buffer, so you can read PC+12 in some cases Okay, major points. First, the save RAM type is now specified in the manifest.xml file. If you don't have one, you have no save RAM. To run games that need it, you're going to have to make a manifest.xml (or gamename.xml if you don't want to use cartridge folders.) Here are some examples: Code: <?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" encoding="UTF-8"?>
We desperately need a database here. I want all No-Intro set game hashes in a big database along with their memory type before we can release this. Save states are currently broken. They work when you're on the same screen, but when a lot has changed and you try and load, things explode. This is typical to see when implementing states. It basically means I'm missing serializing some important data somewhere. I'd really appreciate if anyone wanted to look the code over to see if they can find any missing variables not being serialized. It's easy for me to overlook. Looks like GBA states are ~400-500KB uncompressed, FWIW. EDIT: my guess is that we probably need to call some functions to restored cached states, eg processor.setMode(m) inside the ARM serialization.
2012-04-15 - bsnes_v087r25.tar.bz2 (r24 was a point release during merging of changes.) This release is almost entirely Cydrak's direct work:
2012-04-14 - bsnes_v087r23.tar.bz2 Changelog:
2012-04-13 - bsnes_v087r22.tar.bz2 Changelog:
2012-04-10 - bsnes_v087r21.tar.bz2 EDIT: below green channel shift in PPU::blend() [gba/ppu/screen.cpp at the bottom] is >> 6, should be >> 5. That would probably break most alpha blending effects. Timer speedup added. Boosts Mr. Driller 2 title from 170fps to 400fps. Other games still benefit, but not as amazingly. I don't dip below 160fps ever here. Reverted the memory speed to 2 for everything for now, to fix Castlevania slowdown. We obviously need to add the N/S stuff before we do that. Added linear BG and linear OBJ mosaic-Y. Did not add mosaic-X, or any mosaic to the affine/bitmap modes, because I'm not sure when to apply the compensation. Rewrote layer stuff. It now has two layers (above and below), and it performs the four blending modes as needed. Didn't add semi-transparent sprites because the docs are too confusing. Added a blur filter directly into the PPU for now. This obviously violates my interface, but F-Zero needed it for HUD display. We can remove it when we have an official release with a blur filter available. The filter still doesn't warp colors like a real GBA, because I don't know the formula. So, major priorities now are CPU speed, CPU rotation, windowing, semi-transparent sprites, rest of mosaic, low audio volume (and center GB channels.) Probably in that order?
2012-04-09 - bsnes_v087r20.tar.bz2 Changelog:
2012-04-09 - bsnes_v087r19.tar.bz2 Changelog:
2012-04-07 - bsnes_v087r18.tar.bz2 Merged Cydrak's r17c changes:
2012-04-05 - bsnes_v087r17.tar.bz2 Emulated GBC sound plus the new extensions to it. I am kind of surprised by how little developers utilized the GBC audio portion. Mr. Driller now has sound effects, and Pinobee no Daibouken has BGM. I still have yet to emulate the GBA extra sound channels and PWM. Need to emulate timers and DMA 2 refresh mode before I can do that. Also, I moved both GBC and GBA audio to use length = data; if(++length == 0); rather than length = 64 - data; if(--length == 0); so that I could return literal values for register reads. I thought there was a good reason we used the latter version, but I can't hear any audible difference even in GBC games, so oh well. Lastly, I think the pattern[++offset] in the wave channel was a bug in the DMG/GBC only. I really, really hope it doesn't apply to the GBA, because that will make bank selection a serious pain in the ass. I've no idea how the audio actually works, so I'm running the GBC audio at 4MHz. It sounds good, but obviously that's a bitch on speed. Down to about 130fps now (30% faster than SNES/accuracy), and there's more pain to come. But there's an entire world of speedups available to us, so we'll be profiling and optimizing once we have a decent compatibility rate. Hopefully before first public release, for first impressions and all, but we'll see.
2012-04-03 - bsnes_v087r16.tar.bz2 ixed the r15 mask per Cydrak. Added DMA support (immediate + Vblank + Hblank + HDMA) with IRQ support. Basically only missing FIFO reload mode for the APU on channel 2. Added background linear renderer (tilemap mode.) Added really inefficient pixel priority selector, so that all BGs+OBJ could be visible onscreen at the same time. As a result of the above:
2012-04-03 - bsnes_v087r15.tar.bz2 Added linear (eg non-affine) sprite rendering, 4bpp and 8bpp with hflip and vflip. Nothing else. You can now see the Nintendo logo and Gameboy text at the end of the BIOS. It's a start =) The BIOS doesn't use BGs, so I can't really test any BG implementation there. Need to find some good test ROMs to implement the tilemap and bitmap BG modes.
2012-03-31 - bsnes_v087r14.tar.bz2 Fixed aforementioned issues. All CPU+PPU registers are now hooked up (not that they do anything.) SOUNDBIAS for APU was hooked up, got tired of working on it for the rest :P I recall from the GB APU that you can't just assign values for the APU MMIO regs. They do odd reload things as well. Also, was using MMIO read code like this: Code: return ( (flaga << 0) || (flagb << 1) || (flagc << 2) ); Logical or doesn't work so well with building flags :P Bad habit from how I split multiple conditionals across several lines. So ... r14 is basically what r13 should have been yesterday, delaying my schedule by yet another day :(
2012-03-30 - bsnes_v087r13.tar.bz2 Contains all of Cydrak's fixes, sans PPU. On the PPU front, I've hooked up 100% of read and write registers. All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well. Super Mario Advance now runs without appearing to crash, although it's hard to tell since I have no video or sound :P ARM Wrestler is known to run, as is the BIOS. APU can wait. I believe I'm capable of at least getting that started. Basically a copy/paste job from the GB/C audio core, followed by a few simple extensions, hopefully. We'll see. So ... now it's on to the PPU. Honestly, it looks a lot more complicated than the SNES PPU, but I suppose a lot of that is because I understand the SNES PPU so well. Certainly nothing like the NES and GB where I can just cobble together something that works in ten minutes. Have Cydrak's awesome code, so I can start with that and build upon it, and see what happens. But I definitely need to understand how it works, so copy/paste here is out. I won't be able to add the more advanced features if I don't understand the basics.
2012-03-29 - bsnes_v087r12.tar.bz2 Enough to get through the BIOS and into cartridge ROM. I am a bit annoyed that I was basically told that the GBA PPU wasn't that bad. Sprites are a clusterfuck, easily worse than Mode7, docs don't even begin to explain them in enough detail. This is going to be fun.
2012-03-28 - bsnes_v087r11.tar.bz2 Added all of the above fixes and changes. Also new is pipeline_decode() to fetch data, and IME/IE/IF support, and an ARM::processor.irqline flag that triggers IRQs at 0x18. Only Vblank is hooked up, which is what SWI 4 was waiting on previously. I'm sure my interrupt support is horribly broken and wrong. I was never able to really figure out IE/IF on the Game Boy, so there's no question this is even worse. It's now going crazy and writing 0 to IE forever now after the Vblank IRQ triggers.
2012-03-26 - bsnes_v087r10.tar.bz2 Changelog:
added decode() function to make opcode bit testing a lot clearer (didn't apply it to the debugger yet) All ARMv4M and all THUMBv4 instructions should now be implemented. Although I'm not sure if my implementations of the new instructions are correct. I'm still stuck in the aforementioned loop. It's obviously a CPU bug, because that loop is not polling any I/O registers. Much nicer: Code: decode("???? 0000 00?? ???? ???? ???? 1001 ????", multiply); decode("???? 0001 0?00 ???? ???? ---- 1001 ????", memory_swap); decode("???? 000? ?0?? ???? ???? ---- 1011 ????", move_half_register); decode("???? 000? ?1?? ???? ???? ???? 1011 ????", move_half_immediate); decode("???? 000? ?0?1 ???? ???? ---- 11?1 ????", load_register); decode("???? 000? ?1?1 ???? ???? ???? 11?1 ????", load_immediate);
decode("???? 0001 0?00 ++++ ???? ---- 0000 ----", move_to_register_from_status); decode("???? 0001 0?10 ???? ++++ ---- 0000 ????", move_to_status_from_register); decode("???? 0001 0010 ++++ ++++ ++++ 0001 ????", branch_exchange_register);
decode("???? 000? ???? ???? ???? ???? ???0 ????", data_immediate_shift); decode("???? 000? ???? ???? ???? ???? 0??1 ????", data_register_shift); decode("???? 001? ???? ???? ???? ???? ???? ????", data_immediate); decode("???? 0011 0?10 ???? ++++ ???? ???? ????", move_to_status_from_immediate); decode("???? 010? ???? ???? ???? ???? ???? ????", move_immediate_offset); decode("???? 011? ???? ???? ???? ???? ???0 ????", move_register_offset); decode("???? 100? ???? ???? ???? ???? ???? ????", move_multiple); decode("???? 101? ???? ???? ???? ???? ???? ????", branch); decode("???? 1111 ???? ???? ???? ???? ???? ????", software_interrupt); Code: decode("0001 10?? ???? ????", adjust_register); decode("0001 11?? ???? ????", adjust_immediate); decode("000? ???? ???? ????", shift_immediate); decode("001? ???? ???? ????", immediate); decode("0100 00?? ???? ????", alu); decode("0100 0111 0??? ?---", branch_exchange); decode("0100 01?? ???? ????", alu_hi); decode("0100 1??? ???? ????", load_literal); decode("0101 ???? ???? ????", move_register_offset); decode("0110 ???? ???? ????", move_word_immediate); decode("0111 ???? ???? ????", move_byte_immediate); decode("1000 ???? ???? ????", move_half_immediate); decode("1001 ???? ???? ????", move_stack); decode("1010 ???? ???? ????", add_register_hi); decode("1011 0000 ???? ????", adjust_stack); decode("1011 ?10? ???? ????", stack_multiple); decode("1100 ???? ???? ????", move_multiple); decode("1101 1111 ???? ????", software_interrupt); decode("1101 ???? ???? ????", branch_conditional); decode("1110 0??? ???? ????", branch_short); decode("1111 0??? ???? ????", branch_long_prefix); decode("1111 1??? ???? ????", branch_long_suffix);
2012-03-25 - bsnes_v087r09.tar.bz2 Split apart necdsp: core is now in processor/upd96050 (wish I had a better name for it, but there's no family name that is maskable.) I would like to support the uPD7720 in the core as well, just for completeness' sake, but I'll have to modify the decoder to drop one bit from each mode. So ... I'll do that later. Worst part is even if I do, I won't be able to test it :( Added all of Cydrak's changes. I also simplified LDMIA/STMIA and PUSH/POP by merging the outer loops. Probably infinitesimally slower, but less code is nicer. Maybe GCC optimization will expand it, who knows. We were getting stuck polling SOUNDBIAS: Code: 00000800 2102 mov r1,#0x02 00000802 0209 lsl r1,r1,#8 00000804 468c mov r12,r1 00000806 4bb3 ldr r3,[pc,#0xad4] =0x04000088 00000808 881a ldrh r2,[r3,#0x00] 0000080a 4bb2 ldr r3,[pc,#0xad4] =0x04000088 0000080c 0591 lsl r1,r2,#22 0000080e 0d89 lsr r1,r1,#22 00000810 2800 cmp r0,#0x00 00000812 d003 beq 0x0000081c 00000814 4561 sub r1,r12 00000816 da09 bge 0x0000082c 00000818 1c92 add r2,r2,#2 0000081a e002 b 0x00000822 00000822 801a strh r2,[r3,#0x00] 00000824 2208 mov r2,#0x08 00000826 1e52 sub r2,r2,#1 00000828 d5fd bpl 0x00000826 00000826 1e52 sub r2,r2,#1 00000828 d5fd bpl 0x00000826 0000082a e7e9 b 0x00000800 So I hooked the APU up to it and return 0x200 now (per gbatek.) Now we're getting stuck in an infinite loop here: Code: 00000ba0 4718 bx r3 ;switch to ARM mode (per Exophase's disassembly) (supposed to switch to ARM mode, just repeats forever) (r3 == 0xba1 here ...) Hit after 38,112 opcodes. Exophase, don't suppose you'd know how many (ARM+THUMB) instructions are executed before cartridge entry point? That should be a nice measurement of how close I am. My cycle counter is basically (ARM2)+(THUMB1)*instructions, which is horribly inaccurate. Need to talk with Cydrak about how to do the SNI cycles in a way that's compatible with non-sequential accesses to different memory regions of the GBA.
2012-03-22 - bsnes_v087r08.tar.bz2 Added some more ARM opcodes, hooked up MMIO. Bind it with mmio[(addr 000-3ff)] = this; inside CPU/PPU/APU, goes to read(), write(). Also moved the Hitachi HG51B core to processor/, and split it apart from the snes/chip/hitachidsp implementation. This one actually worked really well. Very clean split between MMIO/DMA and the processor core. I may move a more generic DMA function inside the core, not sure yet. I still believe the HG51B169 to be a variant of the HG51BS family, but given they're meant to be incredibly flexible microcontrollers, it's possible that each variant gets its own instruction set. So, who knows. We'll worry about it if we ever find another HG51B DSP, I guess. Notes while working on Cydrak's updated ST018 code: Code: lsl/lsr/etc perform masking, but so do opcodes? Would like to get ARMwrestler working before optimizing these for performance.
GBA BIOS is constantly reading from 04000300, but it never writes. If I return prng()&1, I can get it to proceed until it hits a bad opcode (stc opcode, which the GBA lacks a coprocessor so ... bad codepath.) Without it, it just reads that register forever and keeps resetting the system, or something ... I guess we're going to have to try and get ARMwrestler working, because the BIOS seems to need too much emulation code to do anything at all.
2012-03-22 - bsnes_v087r07.tar.bz2 Both snes/chip/armdsp and gba/cpu use processor/arm now. Fixed THUMB to execute the BL prefix and suffix separately. I can now get the GBA BIOS stuck in some kind of infinite loop. Hooray ... I guess?
2012-03-22 - bsnes_v087r07pre.tar.bz2 And now for something a bit different: Creates the bsnes/processor folder. This has a shared ARM core there which both the GBA and ST018 inherit. There are going to be separate decoders, and revision-specific checks, to support the differences between v3+. In the future, I also want to move the other processor cores here:
2012-03-21 - bsnes_v087r06.tar.bz2 I believe I've implemented every THUMB instruction now, although I'm sure there are dozens of bugs in the implementation. Here is a run-log: http://byuu.org/temp/armtrace.txt (instructions below current register values) It seems that the last jump taken is ending up being off-by-two. It's probably due to not masking/adjusting PC correctly at certain points. I don't know if any other bugs are being hit prior to this or not. I don't implement any I/O registers yet, and the BIOS seems to be poking at a few of them along the way, so ... who knows. I could also be reading the log wrong, but it looks to me like there's some PSR setting the mode flag register to 0, which is supposed to be an undefined behavior mode ... perhaps mrs has no effect on the m/t bits, and it just affects the i/f bits? It'd be nice if we could get a trace log like mine from a good emulator running the BIOS to compare for issues.
2012-03-20 - bsnes_v087r05.tar.bz2 Implemented all of the ARMv3 instructions, and the bx rm instruction as well. Already hit THUMB mode right at the start of the BIOS, sigh. Implemented the first THUMB instruction to get that rolling. Also tried to support the S flag to LDM/STM, but not sure how successful I was. Code: 00000000 ea000018 b 0x00000068 00000068 e35e0000 cmp lr,#0x00000000 0000006c 03a0e004 moveq lr,#0x00000004 00000070 e3a0c301 mov r12,#0x04000000 00000074 e5dcc300 ldrb r12,[r12,+0x300] 00000078 e33c0001 teq r12,#0x00000001 0000007c 010fc000 mrseq r12,cpsr 00000080 038cc0c0 orreq r12,r12,#0x000000c0 00000084 0129f00c msreq cpsr:cf,r12 00000088 0affffe3 beq 0x0000001c 0000008c e3a000df mov r0,#0x000000df 00000090 e129f000 msr cpsr:cf,r0 00000094 e3a04301 mov r4,#0x04000000 00000098 e5c44208 strb r4,[r4,+0x208] 0000009c eb00000f bl 0x000000e0 000000e0 e3a000d3 mov r0,#0x000000d3 000000e4 e129f000 msr cpsr:cf,r0 000000e8 e59fd0d0 ldr sp,[pc,+0x0d0] =0x03007fe0 000000ec e3a0e000 mov lr,#0x00000000 000000f0 e169f00e msr spsr:cf,lr 000000f4 e3a000d2 mov r0,#0x000000d2 000000f8 e129f000 msr cpsr:cf,r0 000000fc e59fd0b8 ldr sp,[pc,+0x0b8] =0x03007fa0 00000100 e3a0e000 mov lr,#0x00000000 00000104 e169f00e msr spsr:cf,lr 00000108 e3a0005f mov r0,#0x0000005f 0000010c e129f000 msr cpsr:cf,r0 00000110 e59fd0a0 ldr sp,[pc,+0x0a0] =0x03007f00 00000114 e28f0001 add r0,pc,#0x00000001 00000118 e12fff10 bx r0 0000011c 2000 mov r0,#0x00 0000011e 4958 ??? r0:00000000 r1:00000000 r2:00000000 r3:00000000 r4:04000000 r5:00000000 r6:00000000 r7:00000000 cpsr:nZcv r8:00000000 r9:00000000 r10:00000000 r11:00000000 r12:00000000 sp:03007f00 lr:000000a0 pc:00000122 spsr:----
2012-03-19 - bsnes_v087r04.tar.bz2 GBA stuff re-added. Only thing missing that was there before is the ARM branch opcode. Since we're going to be staring at it for a very long time, I added a more interesting test video pattern. Went from 6fps to 912fps. Amazing what being able to divide can do for a frame rate.
2012-03-19 - bsnes_v087r03.tar.bz2 Fixing the PPU stepping increased FPS to 250. Promising, at least, since the ARM core is still severely overclocked. However, I reverted back to r02. This one patches gameboy/ and GameBoy:: to gb/ and GB:: and that's it. Sorry, I just couldn't shake this bad feeling about the code. There were some poorly hacked-together constructs. I'd rather just redo two days of work than feel bad about the codebase for the next several years. Going to attempt the GBA bridge again. Third time's a charm, I suppose (there was a pre-r03 WIP I abandoned as well.) This isn't unprecedented, GB core took a few attempts like this as well.
2012-03-18 - 2zb.rat.40r780v_sensb Changelog:
2012-03-12 - 2zb.rat.30r780v_sensb I wanted to keep this a secret, but unlike other recent additions, this will easily take several weeks, maybe months, to show anything. Assuming I can even pull it off. Nothing technically overwhelming here, I'm more worried about the near-impossibility of debugging the CPU. So that would kill all WIPs until then, which would kind of suck. Well, that's open source for you I guess. Let's at least try and keep it a secret, please. No 'hinting', etc. There's a good chance I'll give up on this, so we'll see.
If anyone is interested in co-developing this with me, I'd love the help. A lot of stuff is unclear already. So is the current CPU mode always stored in CPSR::M? Then what is stored in the various SPSR::M values?
Current batshit insanity: in cpu.cpp, there is a line "apu.clock -= clocks;". If I uncomment that, the framerate drops from 720fps to 140fps. Running -pg binaries is hanging on me, so I can't tell what the holy fuck is going on there. But 4M subtractions a second should not cause a 500% speed hit. Would also appreciate any help in tracking down what is going on there.
2012-03-10 - bsnes_v087r02.tar.bz2 Changelog:
2012-03-10 - bsnes_v087r01.tar.bz2 Changelog:
OpenGL/GLX will use 30-bit when you have a 30-bit display; no need for config file video.depth anymore
2012-03-06 - bsnes_v087-source.tar.bz2 This release adds ST018 emulation. As this was the final unsupported SNES coprocessor, this means that bsnes v087 is the first SNES emulator to be able to claim 100% known compatibility with all officially released games. And it does this with absolutely no hacks. Again, I really have to stress the word known. No emulator is perfect. No emulator ever really can be perfect for a system of this complexity. The concept doesn't even really exist, since every SNES behaves subtly different. What I mean by this, is that every single game ever officially sold has been tested, and zero bugs (of any severity level) are currently known. It is of course extremely likely that bugs will be found in this release, as well as in future releases. But this will always be a problem for every emulator ever made: there is no way to test every possible codepath of every single game to guarantee perfection. I will, of course, continue to do my best to fix newfound bugs so long as I'm around. I'd really like to thank Cydrak and LostTemplar for their assistance in emulating the ST018. I could not have done it without their help. The ST018 ROM, like the other coprocessor ROMs, is copyrighted. This means I am unable to distribute the image. Changelog: emulated the 21.47MHz ST018 (ARMv3) coprocessor used by Hayazashi Nidan Morita Shougi 2 fixed PPU TM/TS edge case; fixes bottom scanline of text boxes in Moryo Senki Madara 2 fixed saving and loading of Super Game Boy save RAM NEC uPD7725,96050 ROMs now stored in little-endian format for consistency cartridge folder concept has been reworked to use fixed file names added emulation of serial USART interface (replaces asynchronous UART support previously)
2012-03-06 - bsnesv086r16.tar.bz2 Cydrak, I moved the step from the opcode decoder and opcodes themselves into bus(read,write)(byte,word), to minimize code. If that's not feasible for some reason, please let me know and I'll change it back to your latest WIP. This has your carry flag fix, the timer skeleton (doesn't really work yet), the Booth two-bit steps, and the carry flag clear thing inside multiply ops. Also added the aforementioned reset delay and reset bit stuff, and fixed the steps to 21MHz for instructions and 64KHz for reset pulse. I wasn't sure about the shifter extra cycles. I only saw it inside one of the four (or was it three?) opcodes that have shifter functions. Shouldn't it be in all of them? he game does indeed appear to be fully playable now, but the AI doesn't exactly match my real cartridge. This could be for any number of reasons: ARM CPU bug, timer behavior bug, oscillator differences between my real hardware and the emulator, etc. However ... the AI is 100% predictable every time, both under emulation and on real hardware.
2012-03-01 - bsnes_v086r15.tar.bz2 Most importantly ... I'm now using "st018.rom" which is the program ROM + data ROM in one "firmware" file. You'll need to get the second archive and put it in the same folder as your HNMS2 ROM. Since all three Seta DSPs have the ST01N stamp, unlike some of the arcade variants, I'm just going to go with ST01N from now on instead of ST-001N. I was using the latter as that's what Overload called them. Moving on ... The memory map should match real hardware now, and I even match the open bus read results. I also return the funky 0x40404001 for 60000000-7fffffff, for whatever that's worth. The CPU-side registers are also mirrored correctly, as they were in the last WIP, so we should be good there. I also simulate the reset pulse now, and a 0->!0 transition of $3804 will destroy the ARM CPU thread. It will wait until the value is set back to zero to resume execution. At startup, the ARM CPU will sleep for a while, thus simulating the reset delay behavior. Still need to figure out the exact cycle length, but that's really not important for emulation. Note in registers.hpp, the |4 in status() is basically what allows the CPU program to keep going, and hit the checkmate condition. If we remove that, the CPU deadlocks. Still need to figure out how and when d4 is set on $3804 reads. I can run any test program on both real hardware and in my emulator and compare results, so by all means ... if you can come up with a test, I'll run it.
r0:00000000 r1:00000000 r2:0001d890 r3:00000000 r4:00000226 r5:00000158 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000016 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000d6ec cpsr:nZCv 0000d6e4 1a000000 bne 0x0000d6ec
r0:00000000 r1:00000000 r2:0001d890 r3:00000000 r4:00000226 r5:00000158 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000016 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000d6f0 cpsr:nZCv 0000d6e8 e2833078 add r3,r3,#0x00000078
r0:00000000 r1:00000000 r2:0001d890 r3:00000078 r4:00000226 r5:00000158 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000016 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000d6f4 cpsr:nZCv 0000d6ec e5561027 ldrb r1,[r6-0x027]
r0:00000000 r1:00000016 r2:0001d890 r3:00000078 r4:00000226 r5:00000158 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000016 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000d6f8 cpsr:nZCv 0000d6f0 e3a00018 mov r0,#0x00000018
r0:00000018 r1:00000016 r2:0001d890 r3:00000078 r4:00000226 r5:00000158 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000016 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000d6fc cpsr:nZCv 0000d6f4 e00a0190 mul r10,r0,r1
r0:00000018 r1:00000016 r2:0001d890 r3:00000078 r4:00000226 r5:00000158 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000d700 cpsr:nZCv 0000d6f8 e084400a add r4,r4,r10
r0:00000018 r1:00000016 r2:0001d890 r3:00000078 r4:00000436 r5:00000158 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000d704 cpsr:nZCv 0000d6fc ea00061b b 0x0000ef70
r0:00000018 r1:00000016 r2:0001d890 r3:00000078 r4:00000436 r5:00000158 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef78 cpsr:nZCv 0000ef70 e08330a4 add r3,r3,r4 lsr #1
r0:00000018 r1:00000016 r2:0001d890 r3:00000293 r4:00000436 r5:00000158 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef7c cpsr:nZCv 0000ef74 e1a031a3 mov r3,r3 lsr #3
r0:00000018 r1:00000016 r2:0001d890 r3:00000052 r4:00000436 r5:00000158 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef80 cpsr:nZCv 0000ef78 e51271b4 ldr r7,[r2-0x1b4]
r0:00000018 r1:00000016 r2:0001d890 r3:00000052 r4:00000436 r5:00000158 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef84 cpsr:nZCv 0000ef7c e2450054 sub r0,r5,#0x00000054
r0:00000104 r1:00000016 r2:0001d890 r3:00000052 r4:00000436 r5:00000158 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef88 cpsr:nZCv 0000ef80 e7970000 ???
r0:00000042 r1:00000016 r2:0001d890 r3:00000052 r4:00000436 r5:00000158 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef8c cpsr:nZCv 0000ef84 e0833000 add r3,r3,r0
r0:00000042 r1:00000016 r2:0001d890 r3:00000094 r4:00000436 r5:00000158 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef90 cpsr:nZCv 0000ef88 e51201f4 ldr r0,[r2-0x1f4]
r0:00000140 r1:00000016 r2:0001d890 r3:00000094 r4:00000436 r5:00000158 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef94 cpsr:nZCv 0000ef8c e1530000 cmp r3,r0
r0:00000140 r1:00000016 r2:0001d890 r3:00000094 r4:00000436 r5:00000158 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef98 cpsr:NzCv 0000ef90 21a03000 movcs r3,r0
r0:00000140 r1:00000016 r2:0001d890 r3:00000140 r4:00000436 r5:00000158 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef9c cpsr:NzCv 0000ef94 e5120274 ldr r0,[r2-0x274]
r0:00000004 r1:00000016 r2:0001d890 r3:00000140 r4:00000436 r5:00000158 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000efa0 cpsr:NzCv 0000ef98 e08032a3 add r3,r0,r3 lsr #5
r0:00000004 r1:00000016 r2:0001d890 r3:0000000e r4:00000436 r5:00000158 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000efa4 cpsr:NzCv 0000ef9c e5c63002 strb r3,[r6+0x002]
r0:00000004 r1:00000016 r2:0001d890 r3:0000000e r4:00000436 r5:00000158 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000efa8 cpsr:NzCv 0000efa0 e5165f98 ldr r5,[r6-0xf98]
r0:00000004 r1:00000016 r2:0001d890 r3:0000000e r4:00000436 r5:00000154 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000efac cpsr:NzCv 0000efa4 e3550054 cmp r5,#0x00000054
r0:00000004 r1:00000016 r2:0001d890 r3:0000000e r4:00000436 r5:00000154 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000efb0 cpsr:nzCv 0000efa8 2affffe4 bcs 0x0000ef40
r0:00000004 r1:00000016 r2:0001d890 r3:0000000e r4:00000436 r5:00000154 r6:e0001640 r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef48 cpsr:nzCv 0000ef40 e08c6005 add r6,r12,r5
r0:00000004 r1:00000016 r2:0001d890 r3:0000000e r4:00000436 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef4c cpsr:nzCv 0000ef44 e5561000 ldrb r1,[r6]
r0:00000004 r1:00000040 r2:0001d890 r3:0000000e r4:00000436 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef50 cpsr:nzCv 0000ef48 e201101e and r1,r1,#0x0000001e
r0:00000004 r1:00000000 r2:0001d890 r3:0000000e r4:00000436 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef54 cpsr:nzCv 0000ef4c e08b2081 add r2,r11,r1 lsl #1
r0:00000004 r1:00000000 r2:0001d890 r3:0000000e r4:00000436 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef58 cpsr:nzCv 0000ef50 e3a03000 mov r3,#0x00000000
r0:00000004 r1:00000000 r2:0001d890 r3:00000000 r4:00000436 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef5c cpsr:nzCv 0000ef54 e5d60001 ldrb r0,[r6+0x001]
r0:00000019 r1:00000000 r2:0001d890 r3:00000000 r4:00000436 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef60 cpsr:nzCv 0000ef58 e512a234 ldr r10,[r2-0x234]
r0:00000019 r1:00000000 r2:0001d890 r3:00000000 r4:00000436 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000016 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef64 cpsr:nzCv 0000ef5c e0040a90 mul r4,r0,r10
r0:00000019 r1:00000000 r2:0001d890 r3:00000000 r4:00000226 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000016 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef68 cpsr:nzCv 0000ef60 e5d6020d ldrb r0,[r6+0x20d]
r0:00000000 r1:00000000 r2:0001d890 r3:00000000 r4:00000226 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000016 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef6c cpsr:nzCv 0000ef64 e1811000 orr r1,r1,r0
r0:00000000 r1:00000000 r2:0001d890 r3:00000000 r4:00000226 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000016 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef70 cpsr:nzCv 0000ef68 e08f0081 add r0,pc,r1 lsl #1
r0:0000ef70 r1:00000000 r2:0001d890 r3:00000000 r4:00000226 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000016 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000ef74 cpsr:nzCv 0000ef6c e590f0b0 ldr pc,[r0+0x0b0]
r0:0000ef70 r1:00000000 r2:0001d890 r3:00000000 r4:00000226 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000016 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000d6dc cpsr:nzCv 0000d6d4 e5560028 ldrb r0,[r6-0x028]
r0:00000000 r1:00000000 r2:0001d890 r3:00000000 r4:00000226 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000016 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000d6e0 cpsr:nzCv 0000d6d8 e3100080 tst r0,#0x00000080
r0:00000000 r1:00000000 r2:0001d890 r3:00000000 r4:00000226 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000016 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000d6e4 cpsr:nZCv 0000d6dc 1a000006 bne 0x0000d6fc
r0:00000000 r1:00000000 r2:0001d890 r3:00000000 r4:00000226 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000016 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000d6e8 cpsr:nZCv 0000d6e0 e3100040 tst r0,#0x00000040
r0:00000000 r1:00000000 r2:0001d890 r3:00000000 r4:00000226 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000016 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000d6ec cpsr:nZCv 0000d6e4 1a000000 bne 0x0000d6ec
r0:00000000 r1:00000000 r2:0001d890 r3:00000000 r4:00000226 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000016 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000d6f0 cpsr:nZCv 0000d6e8 e2833078 add r3,r3,#0x00000078
r0:00000000 r1:00000000 r2:0001d890 r3:00000078 r4:00000226 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000016 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000d6f4 cpsr:nZCv 0000d6ec e5561027 ldrb r1,[r6-0x027]
r0:00000000 r1:00000016 r2:0001d890 r3:00000078 r4:00000226 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000016 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000d6f8 cpsr:nZCv 0000d6f0 e3a00018 mov r0,#0x00000018
r0:00000018 r1:00000016 r2:0001d890 r3:00000078 r4:00000226 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000016 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000d6fc cpsr:nZCv 0000d6f4 e00a0190 mul r10,r0,r1
r0:00000018 r1:00000016 r2:0001d890 r3:00000078 r4:00000226 r5:00000154 r6:e000163c r7:0001e090 r8:e000168c r9:00000000 r10:00000210 r11:0001d890 r12:e00014e8 r13:e0003fdc r14:00007b5c r15:0000d700^C cpsr:nZCv
2012-02-28 - bsnes_v086r12.tar.bz2 Attract demonstration game is fully playable.
Bingo. The F3 and F4 dumps are both valid. Code:
include
include
//basically just add 32-bit words together. simple stuff. void checksum(const char filename, unsigned size) { FILE fp = fopen(filename, "rb");
unsigned r0 = 0, r4, r9; while(ftell(fp) < size) { r4 = fgetc(fp); r9 = fgetc(fp); r4 |= r9 << 8; r9 = fgetc(fp); r4 |= r9 << 16; r9 = fgetc(fp); r4 |= r9 << 24; r0 += r4; } fclose(fp); printf("%s[0:%.5x] = %.8x\n", filename, size, r0); }
int main() { checksum("0xf3.bin", 0x1f440); checksum("0xf4.bin", 0x05100);
checksum("0xf3.bin", 0x20000); checksum("0xf4.bin", 0x08000);
return 0; } Code: 0xf3.bin[0:1f440] = ecf28ee0 0xf4.bin[0:05100] = bd8a23a5 0xf3.bin[0:20000] = ecf28ee0 0xf4.bin[0:08000] = a75e50f8 F3 has null data at the end of the file, thus its checksum is ecf28ee0 @ 1f440 and ecf28ee0 @ 20000. F4 does not have null data at the end, thus its checksum is bd8a23a5 @ 5100 and a75e50f8 @ 8000. So yes, random as it may appear ... both dumps are perfectly valid. So I guess F4 is also ROM ... I'll rename it to dataROM for now. For v087, I'm going to seed st0018.rom as the two ROMs appended together, like I do for the uPD chips and FEoEZ ROM. It'll be a 160KB file. But until then, we'll leave it as st0018.rom and st0018d.rom, as we have it now. And now with MUL/MLA supported, we're back to no invalid ops (that we know of) being executed ... so it's just some CPU bugs preventing the game from running fully.
2012-02-28 - bsnesv086r11.tar.bz2 I'm ... really not following this at all >< I've uploaded a new WIP. It completes F1 (test), F2 (test), and AA (9x9+16 board upload.) It runs B3 (checkmate), but is telling the CPU that checkmate has occurred as soon as you start a new game. It's not hitting any missing opcodes, so I can only guess there are CPU bugs. Also, my implementation of the status register isn't exactly right. It seems for the board upload, it waits for $3804.d4 (&#$10) = 0. If I set that to !armtocpu.ready, the game dies with ST0018 fail right at power-on. So I'm not really sure how all the flags work right now. It does seem to be properly handshaking, though. You can see the ST0018 telling the CPU how many bytes are remaining in the upload after each write. Also ... if you put the 32K file in the same folder as st0018.rom, and name it st0018d.rom, it will load that into a000:0000-7fff. The game seems to read from it at power-on, but never writes to it. I'm not sure what's up with that right now. And I'm going to sleep. I'm pretty much stuck here, so I could realllllly use some help :/
2012-02-27 - bsnes_v086r10.tar.bz2 More ARM work. ARM core now begins to act upon initial 0xf1 command, but hangs.
2012-02-26 - bsnes_v086r09.tar.bz2 A lot more work on the ARMv3 core.
2012-02-26 - bsnes_v086r08.tar.bz2 Contains the fledgling beginnings of an ARM CPU core, which can execute the first three and a half instructions of the ST-0018. It's a start, I guess.
2012-02-23 - bsnes_v086r07.tar.bz2 USART improvements. The clock pulse from reading data() drives both reading and writing. Also added a usart_init() to bind the initializer functions, so all you need now is: extern "C" usartproc void usart_main() { ... } And inside, you use usart_read(), usart_write(), etc. So we can add all the new functions we want (eg I'd like to have usart_readable() to check if data is available) without changing the entry point signature. blargg enhanced his Teensy driver to ignore frame error reads, as well.
2012-02-22 - bsnes_v086r06.tar.bz2 It is done. bsnes can now emulate sending and receiving data via USART. As such, the UART code has been removed. The final UART code can be downloaded here: http://byuu.org/snes/uart/ I won't maintain it going forward, because nobody ever used it, and USART is superior in every way. I've also verified both sending and receiving on the real SNES now :D It's so easy ... a caveman with electrical engineering and computer programming experience can do it.
2012-02-22 - bsnes_v086r05.tar.bz2 USART implements reading and writing, but I don't yet have code to test SNES reading yet. So ... obviously I need to do that next. Went ahead and required nall::function, so the modules will have to be C++11. I don't see anyone else making these, and it avoids the annoyance of deducing the correct controller port based on dynamic casting the active thread. Apparently a library can have a main() function to no ill effect, so there's no need for USART_HARDWARE. Same exact code with different flags will make the binary and the library.
2012-02-21 - bsnes_v086r04.tar.bz2 There will probably be a series of small WIPs as I experiment here. snes/controller/serial is now snes/controller/uart. Asynchronous serial communications, typically capped at 57,600 baud. snes/controller/usart is new. It aims to emulate the SNES connected to a Teensy++ board, and can easily handle 524,288 baud. And much more importantly, it's synchronous, so there are no timing issues anymore. Just bit-bang as fast as you can. Right now, the USART code is just enough for SNES->PC to transfer data to ... well, nothing yet. Unless anyone is actually using the UART stuff, I'll be removing it once the USART is totally up and running. No sense maintaining code that is 10x slower, more error prone, and used by nobody. Note: this is all thanks to blargg being absolutely amazing.
2012-02-17 - bsnes_v086r03.tar.bz2 Cart unload save path was using the new game rather than the old game. Caused by trying to allow a failed cartridge load to not unload the current game. But that's so uncommon that it's not worth worrying about. It'll always unload before trying to load a new game now. Removed the TM/TS disable speedup, to fix Madara 2's text boxes. This actually did cause a slight performance penalty on games that disable layers via TM/TS. Zelda 3 inside Link's house is a good example. It knocked the FPS from 98.5 to 94.5. So to counter that, I removed conditionals from tiledata loading and decoding, and used fall through switches. This boosted us back to 97.0. The -march=native flag apparently works better with SB now, so that was added, putting us up to 99.0fps. So it should be the same speed in the worst case, and slightly faster in the best case. Bumped the pre-render time to 68 clocks from 60 clocks. Adjusted sprite tile fetch time from 22 to 14 to compensate. This should give us perfectly stable Dai Kaijuu Monogatari 2 battles.
2012-02-15 - bsnes_v086r02.tar.bz2 Fixed Super Game Boy RAM saving and loading. It plainly wasn't hooked up at all. Was apparently hard-coded before it became a multi-emulator. I also fixed a crashing issue when loading Satellaview-slotted or Satellaview games without specifying the sub-cart, wasn't setting has_bsx_slot = true, so the raw memory wasn't being allocated internally when it wasn't mapped in. Of course a better fix would be to just not physically map the ranges if the things aren't present. Kind of a lazy hack to map blank cartridges there, but oh well. Oh, fixed title displays as well; and did the best I could for now with regards to multi-file path saving. Basically, Satellaview-slotted and Sufami Turbo modes need special handling for cheats.xml and states.bsa. Your cheat codes may apply to where the two different ST games are mapped in currently, or your save state may be dependent upon the Tengai Makyou pack being loaded into Same Game. Storing the cheats.xml in either the base or one of the slot folders isn't enough. The base can have different slotted carts, and the slotted carts can be put in different configurations or into different cartridges. We need something like this: Code: Base (US).sfc/ Slot 1 (US).bs + Slot 2 (US).bs/ cheats.xml state-1.bsa Slot 1 (US).st/ Slot 2 (US).st/ ... but I really don't want to jump through a million hoops to make that happen. So for now, these two modes are rare enough that I'll just have them store to the first child slot. Use cheats and states on them at your own risk. Once we enforce folder loading across the board, I can simplify things and do the above, no problem. Aside: the complexity really has to stop here. bsnes is starting to get overwhelming for just me alone. The abstractions needed to support multiple systems at a time (and I want that very much, fuck having five different GUIs) is really starting to get hard to keep in order in my head.
2012-02-15 - bsnes_v086r01.tar.bz2 The goals for v087 are to have a unified cartridge-folder concept, as well as a more functional SNES debugger. Starting with the cartridge folders. What I have so far: Code: NES:
SNES:
Game Boy, Game Boy Color:
Sub-cartridges (BS-X, Sufami Turbo, …) are stored as separate folders Folder names must be UTF-8 based, with all-lowercase extensions File names must be all-lowercase
SNES:
Need:
2012-02-13 - bsnes_v086-source.tar.bz2 The main focus of this release is Laevateinn, which is the new bsnes debugger. Unlike previous debuggers, Laevateinn is a standalone application with its own GUI entirely focused on debugging. Changelog: created ui-debugger target (Laevateinn) fixed multitap ports 2-4 [quequotion] fixed ui-libsnes target compilation fixed a crashing issue with NSS XML markup improved cartridge-folder loading support NES can now load .fc (headerless NES) or .prg+.chr (split NES) images fixed cursor being visible in fullscreen mode when using Linux/Metacity window manager [ncbncb] show normal cursor when using Linux/SDL video driver [ncbncb] added menu accelerators fixed a bug in performance profile SMP incw/decw instructions SNES core can now optionally be built without Game Boy emulation core added 2012-02-04 cheats.xml database [mightymo]
2012-02-12 - bsnes_v085r09.tar.bz2 See debugger thread for changes.
../emus/bsnes/laevateinn_v085r09.tar.bz2 Includes Windows 64-bit binary (in the out/ folder) and source code. You'll have to patch phoenix to compile on 32-bit mode. Finally figured it out: TDM/GCC 32-bit lacks updated Win32 Platform API headers, whereas the 64-bit version does not. Isn't that fun? ./sshots/laevateinn_v085r09.png Added VRAM viewer (mouse over to get tile# and VRAM address), CPU+SMP register editors, settings.cfg to cache path+sync audio+mute audio settings (Windows Vista+ ignore my request for the default folder because they are fucking stupid, so they always default to your home folder. I'm going to have to recommend using a batch file to start laevateinn there. Sorry, blame Microsoft for being fuck-ups), geometry.cfg to remember where you placed windows and what size you made them (a bug in Qt prevents me from making some windows fixed-size for now, but that'll change when I can work around the Qt issue), usage map invalidation if the ROM was modified after the usage files, that empty line insertion thing creaothceann wanted on emulation resume, all chips now synchronize immediately rather than just-in-time, which is important for a debugger. Going to postpone the properties viewer until after v086.
2012-02-11 - bsnes_v085r08.tar.bz2 Changelog:
cartridge loading is entirely folder-based now
Test binary - Windows amd64 accuracy profile: (you need 64-bit Windows!!) ../emus/bsnes/laevateinn_v085r08.7z You'll have to resize the windows a bit, based on your font. I'm still doing manual sizing that's optimal for Linux right now. ./sshots/laevateinn_v085r08.png Added SMP/PPU breakpoints, SMP debugger, SMP stepping / tracing, memory editing on APU-bus / VRAM / OAM / CGRAM, save state menu, WRAM mirroring on breakpoints, protected MMIO memory regions (otherwise, viewing $002100 could crash your game.) Major missing components:
2012-02-10 - bsnes_v085r07.tar.bz2 Changelog:
stuff
./sshots/laevateinn_v085r07.png Breakpoints now work on CPU { Read, Write, Exec }. They have next-to-zero overhead now. Rather than testing all possible breakpoints in linear fashion, I build vector lists for all possible combinations. So if you only have one CPU read breakpoint, CPU writes won't bother testing anything. The whole thing is honestly designed for speed. I can easily run the accuracy core at >60fps here. But of course, the fact that I won't support the debugger in compatibility mode will be problematic for people without i7's. Maybe someone here can patch PPU-compatibility or something. The usage maps are back. They are necessary for proper forward+backward disassembly. They're saved across runs. I will probably get fancier at some point and do a timestamp check to invalidate the usage maps if the ROM was modified. Decided against having gamename-bla.ext for every debugger file. Enforcing my folder-style, sorry. Say you have /path/to/Zelda (U).sfc/{ SFC, SRM, etc. } It will make: /path/to/Zelda (U).sfc/debug/ { usage.cpu, usage.apu, trace-NNN.log, etc. } Again, this is what I meant by personal project. Doing things my way. If you guys don't like these types of choices, I'll welcome a fork that changes things up to be more mainstream. Now, for the CPU debugger ... "Step Into" will run until the next CPU opcode edge and then break. Whereas the console "Step" will run until the next enabled chip under the debug menu hits an instruction. The other commands are more problematic, and disabled for now. See, bsnes is a sub-cycle-accurate emulator. That means that you can be in the middle of an opcode when the emulator is paused. You obviously cannot skip a half-executed opcode. Worst case, you will have to hit "Step Into" once to align it to an opcode edge, and then you can use the other commands. Once they're implemented. Not sure if they'll make it to the first official release. So ... major things missing:
2012-02-08 - bsnes_v085r06.tar.bz2 Lots of debugger enhancements. Memory editor works for CPU-bus only, breakpoint editor does nothing yet. Tracing works, writes to 001-999 files sequentially. Stepping works, too. But only on the CPU. Added "privileged", which becomes "public" if DEBUGGER is defined, "private" otherwise. Meant so the debugger can stab deeply into the cores for state manipulation. Interface is guaranteed to be unstable and dependent upon the accuracy core. The about screen logo adds 100KB onto the source download (won't affect regular bsnes binaries), but too bad. I want some visual flair this time. Debugger so far is looking incredibly awesome, at least to me: http://i.imgur.com/rEpr6.png
2012-02-06 - bsnes_v085r04.tar.bz2 Changelog:
2012-02-04 - bsnes_v085r03.tar.bz2 Changelog:
2012-01-25 - bsnes_v085r02.tar.bz2 Fixed NSS XML crashing issue. Improved folder-loading support. NES can now load game.fc/game.fc, or game.fc/game.prg+game.chr. Both types should have no iNES header at all. And both types require an XML file (until we have a built-in database.) Windows users: if you compile your own build with the options := console enabled, it will print any iNES mapping string to the terminal for you, so you can see how to generate your own XML.
2012-01-14 - bsnes_v085r01.tar.bz2 Changelog:
2012-01-02 - bsnes_v085-source.tar.bz2 A new release for the new year. Changelog: fixed auto joypad polling edge case; fixes Ys 5 controls fixed Justifier polling code; Lethal Enforcers should be fully responsive once again rewrote SNES S-SMP processor core (~20% code reduction) fixed Game Boy 8x16 sprite mode; fixed some sprites in Zelda: Link's Awakening treat Game Boy HuC1 RAM enable flag as writable flag instead; fixes Pokemon Card GB created far faster XML parser; bsnes can now load XML files once again updated to mightymo's most recent cheat code database internal color calculations now performed at 30-bits per pixel gamma slider now acts as fine-tuned gamma ramp option Linux OpenGL driver will output at 30bpp on capable displays Linux port defaults to GTK+ now instead of Qt (both are still available)