mirror of https://github.com/bsnes-emu/bsnes.git
8fd90cc123
New WIP adds an option to enable or disable filetype
detection by reading the format header. I received no feedback, so I'm
defaulting to this behavior being off. In other words, I'm defaulting
to requiring the file extension to be correct to properly handle the
file. This is because there's no reason a real SNES would behave
different just because $8000 = 'P' and $8001 = 'K', and with the
option enabled by default, you wouldn't be able to get such a game to
run. But the option is there for those who want it.
I've also added bumpers to everything but the core (cpu, smp, ppu,
dsp) and some of the library stuff and platform-specific stuff (hiro,
libfilter, libco, ui) -- really can't add them to libco as I want each
individual file to compile on its own if the user wants. But overall,
it should make things a lot easier for those trying to build bsnes
without using my Makefile.
Not in the WIP, I just fixed a frameskipping bug. It
was broken in the last few WIPs, including the most recent.
> You'd be best off reading 7 bytes, and then memcmp()'ing them.
Can't memcmp() the low five bits of the GZ flags byte. I'm not
concerned about rigid speed here anyway. It's just file type
detection. I changed it to fread() the bytes, that's good enough.
Thanks for the information, I've extended JMA to a
40-bit check.
> Anyway, the -mdynamic-no-pic option does work and is likely the
> better solution, since it apparently continues to allow linking to
> dynamic libraries, whereas -static apparently does not.
Well, we use -static only when building libco.c. I like -static more,
because it exists in all versions of GCC. I will mention -mdynamic-no-
pic in the libco documentation for v0.13 official.
> Well, turns out the CGRAM content is the same... Surprised
> bsnes, ZSNES and vSNES show 8/16/24, so it's
> something to do with SNES9x.
Thank you for testing! If only all beta testers had
your technical prowess :D
Glad to see it's not a bug on my side. Not really in
the mood to track down bugs at the moment, heh.
> You obviously haven't been around here very long. Razz
> Believe me, someone has or will try it.
I've actually been very fortunate in that regard. At least 95%, if
not all, of bsnes users have been very intelligent and well spoken :)
> Another small issue could be adding a list of recently loaded ROMs
> to the menu.
Not a chance. I can't _stand_ recently opened document
lists.
> now I'll leave you all to this medical hijacking of the thread,
> while waiting for richard bannister to successfully compile and
> release a new bsnes
He has. Get it here. Be sure to send him thanks, please
:)
> byuu's been planning to write documentation for ages, he's just
> never gotten around to it. Perhaps all the experience he's gained
> restructuring bsnes will help him plan out the documentation when he
> does, though
I won't start on docs until I have a functional CPU<>PPU cycle-level
emulation model. I'll try documenting the PPU as I work on cycle
timing, and I can expand upon the documentation from there.
[No archive available]
|
||
|---|---|---|
| src | ||
| license.txt | ||
| readme.txt | ||
readme.txt
bsnes Version: 0.028 Author: byuu -------- General: -------- bsnes is a Super Nintendo / Super Famicom emulator that began on October 14th, 2004. The latest version can be downloaded from: http://byuu.org/ Please see license.txt for important licensing information. ------------------ Known Limitations: ------------------ S-CPU - Invalid DMA / HDMA transfers not fully emulated - Multiply / Divide register delays not implemented S-PPU - Uses scanline-based renderer. This is very inaccurate, but few (if any) games rely on mid-scanline writes to function correctly - Does not support FirstSprite+Y priority - OAM / CGRAM accesses during active display not supported correctly - RTO flags are not calculated on frames that are skipped when frameskipping is enabled. This provides a major speedup, however it will cause in issues in games that test these flags, eg the SNES Test Program Electronics Test. Turning frameskipping off will allow RTO flag calculation on every frame Hardware Bugs - S-CPU.r1 HDMA crashing bug not emulated - S-CPU<>S-SMP communication bus conflicts not emulated --------------------- Unsupported Hardware: --------------------- SA-1 Coprocessor used in many popular games, including: - Dragon Ball Z Hyper Dimension - Kirby Super Star - Kirby's Dreamland 3 - Marvelous - SD Gundam G-NEXT - Super Mario RPG Super FX Coprocessor used in many popular games, including: - Doom - Star Fox - Star Fox 2 (unreleased beta) - Super Mario World 2: Yoshi's Island SPC7110 Coprocessor used only by the following games: - Far East of Eden Zero - Far East of Eden Zero: Shounen Jump no Shou - Momotarou Densetsu Happy - Super Power League 4 ST-011 SETA DSP used only by Quick-move Shogi Match with Nidan Rank-holder Morita ST-018 SETA RISC CPU used only by Quick-move Shogi Match with Nidan Rank-holder Morita 2 Super Gameboy Cartridge passthrough used for playing Gameboy games ------------------------ Unsupported Controllers: ------------------------ Mouse Super Scope Justifier Multitap (4-port and 5-port)