mirror of https://github.com/bsnes-emu/bsnes.git
126 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
byuu
|
20977817ae |
Update to bsnes v030r06? release.
New WIP up. This one fixes HDMA bus sync timing. I verified this was correct per hardware with the HDMA test sync ROM. It was definitely wrong before. Secret of Mana, Street Racer and Jumbo Ozaki no Hole in One all work. Yes, they worked in the official v030 release, but that release had HDMA sync disabled and rounded. Mecarobot is improved greatly, but still flickers when the golf course is moving. If you're as desperate as I am to play this amazing masterpiece _right now_, you can always hex edit the ROM and change offset 0x1c6f from 0x40 to 0x80 :) I'm still investigating that issue more before I start running hardware tests. I want to rule out things that can't be the cause of the bug first. I've also added (hopefully) proper SPC7110 detection. If anyone wants to test all of them to make sure it works, great. It should give you a popup now saying that it's unsupported. Down to just needing ST-011 detection now. [No archive available] |
|
|
byuu
|
ba25c82939 |
Update to bsnes v030r05? release.
New WIP posted, which adds: - krom's Direct3D fix; point mode at multiples of 3x and higher without aspect ratio correction is no longer blurry - FitzRoy's updated SNES controller graphic - glX improvement for Linux, window will clear to black on startup for ATI cards now too, but it still doesn't redraw when the window is damaged because I can't trap the exposure events - tiny clarification to S-DSP emulator source (use echo_hist_pos enum instead of just "8") - started to add SPC7110 _detection_ for the sole purpose of advising that the chip isn't supported. Not finished yet. Also need to fix ST-011 detection while I'm at it (it's detected as ST-010 now; they share ROM type and mapper IDs), and all special chip games should be covered. - re-added the slightly incorrect HDMA sync timing. It helps (but doesn't fix) Mecarobot, it breaks the SoM intro again; but Street Racer and Jumbo Ozaki are still working right -- looks like other timing improvements since then were enough for those titles For those asking for WIP access, I'm really sorry but I have way too many testers now. It's extremely hard for me to even keep track anymore. I just don't have the bandwidth. If you absolutely need a specific WIP, I'll stick it on a file sharing site or something for you. Otherwise, my apologies for not sending you the link. I absolutely do appreciate the offers to help beta test, though. [No archive available] |
|
|
byuu
|
3babe932fd |
Update to bsnes v030r04? release.
One thing we can always do is add some platform-specific profiling code. Have bsnes try and determine what the fastest driver is upon first run. As if I don't have enough to do already, heh. New WIP, which converts the S-DSP ring buffers to an internal class object. Surprisingly, it actually does make the code a bit nicer to look at, although it's kind of unfortunate I can't hijack operator[]=, heh. I'd be forced to use modulus for that. Even more surprising, it's about ~2% faster than before. Even though it's technically even more complex now with three writes instead of two. Makes no sense at all, but I won't complain. Getting 122fps now on Zelda 3 load screen. --- ATI Radeon X300LS: Direct3D = 64fps OpenGL = 24(!!)fps ... as if we needed _another_ reason not to buy ATI products. What the hell was AMD thinking, buying them? Better yet, why do people buy ATI products? Laptops, I can understand. But for desktops?? Seriously. That performance is so terrible, you couldn't even play OpenGL games with that. We really need more OGL titles to rape ATI on benchmark tests, so that they'll get their heads out of their asses. [No archive available] |
|
|
byuu
|
6bdeaef0f4 |
Update to bsnes v030r03 release.
v030 wip3 posted. This one add's krom's ruby changes, meaning Windows OpenGL support. For consistency, I changed the Windows system.video setting to "wgl", and Linux OpenGL to "glx". Linux users should be sure to update that to avoid SDL video output. I get ~119fps with OpenGL, and ~120fps with Direct3D. I'd appreciate if everyone else would test OpenGL support. If it works everywhere that D3D works, and avoids that texture size slowdown issue, then we should make it the default driver. The only issue I see with the driver now is that vsync is enabled no matter what. You can turn it off in eg the nVidia control panel by overriding the setting. I also recommend enabling triple buffering. With that, video is perfectly smooth and audio is ~99.5% perfect. So, so close. A slight cpu.freq change and you can probably get it perfect. God, it's so nice having perfect video and audio. I really wish that worked across the board. It's absolute euphoria playing games like that. [No archive available] |
|
|
byuu
|
9e3827e2a2 |
Update to bsnes v030 release.
I didn't want to release a new version so soon, however there is a rather serious bug in bsnes v029 where the path information for the save RAM files is discarded when one has not selected a default save RAM / cheat path from the path settings tab in the configuration settings window. Because of this, it gets stored to the base directory. For Windows users, this is c:\, and for Linux users, this is / This bug forced my hand, so I'm releasing v030 to correct this issue. I also cleaned up the S-DSP emulation code to be more consistent with my programming style -- it gets bit-perfect matches to v029's wave output, so I don't foresee there being any problems. |
|
|
byuu
|
e499670ad9 |
Update to bsnes dsp release.
Okay, it's just blargg's. I hope he doesn't mind ...
I rewrote his S-DSP emulator in pure C++. Only took me seven hours,
not bad. anomie's took a few days.
Now, given, it's extremely similar of course. First, the algorithms
are going to be mostly the same regardless of who writes the code.
Second, I really didn't see a reason to waste too much time on this
reverse engineering a bunch of stuff myself, so I pretty much just
took the code and "rewrote" (read: copied) it in my unique style, and
changed a few things here and there. Code flow, variable names,
tables, exact algorithms, etc were blatant, direct copies.
Things I did change:
- counter rate 0 is now hardcoded to not ever hit zero
- counter read is now boolean instead of unsigned short
- a lot of multiplication was converted to shifts
- broke up the program into ~9 source files
- no more global functions anywhere, all in one class
- removed the hooks for things like external channel muting -- will
re-add if I ever add an option like that to bsnes
- modified VREG to not need the voice regs handle passed to it
- all voice functions take a reference instead of pointer to the voice
structs now
- packed 32-line timing table expanded to multi-line
- left everything in their own small chunk functions ... kind of torn
on whether I want to merge that with the main timing function. I like
the encapsulation, but it would remove the need to keep so many
struct-based state variables
- added a few more comments on parts that confused me at first
- removed assignment inside conditional stuff; even though I do that
myself on occasion in other code I write, heh
- yadda yadda, more minor stuff like that
Going to keep working at it -- wanted to get it working now, so that
finding regressions will be easier. I want to remove the double writes
for the ring buffer, make a decision on whether I want to rely on sign
extension, or use sclip<> for that, implement a compile-time option to
bypass libco (will save 2.048 million co_switch calls a second) since
the S-DSP's entire operation fits into a single switch table quite
easily, convert a lot of the mul / div stuff to shifts, convert those
clever split up branches in the envelope and BRR decoding routines to
switch / case tables, remove the shift tables from the BRR decoding,
and try and figure out what's going on with some of the code so that I
can try and document it :)
I'll see if I can contribute something back, too. Perhaps I can look
into what happens when you enable mute or something.
New WIP up which has the new core enabled by default. For those
without WIP access, I've posted the new source for reference. Comments
welcome.
byuu.org/files/bsnes_dsp.zip
... man, feels weird posting a new topic.
[No archive available]
|
|
|
byuu
|
805398e5a8 |
Update to bsnes v029 release.
A new version of bsnes has been released. It contains a few minor emulation fixes, as well as user interface improvements. Behind the scenes, the source has been cleaned up more in preparation for running the CPU and PPU (video processor) separately from each other (eg with no enslavement.) This is required for implementing a clock cycle based PPU renderer.
- Greatly improved invalid DMA transfer behavior, should be nearly perfect now
- Major code cleanup -- most importantly, almost all PPU timing-related settings moved back to PPU, from CPU
- Added option to auto-detect file type by inspecting file headers rather than file extensions
- Rewrote video filter system to move it out of the emulation core -- HQ2x and Scale2x will work even in hires and interlace modes now, 50% scanline filter added
- Re-added bsnes window icon
- Added new controller graphic when assigning joypad keys [FitzRoy]
- Redundant "Advanced" panel settings which can be configured via the GUI are no longer displayed
- Improved speed regulation settings
- XP and Vista themes will now apply to bsnes controls
- Added "Path Settings" window to allow easy selection of default file directories
- Tab key now mostly works throughout most of the GUI (needs improvement)
- Main window will no longer disappear when setting a video multipler which results in a window size larger than the current desktop resolution
- Added two new advanced options: one to control GUI window opacity, and one to adjust the statusbar text
|
|
|
byuu
|
7e6e3e3a69 |
Update to bsnes v028r16? release.
Lots of talking. As I've said many times before, I typically don't like working on fan translations. The programmers are almost always far less skilled than professional developers, and they almost always test on emulators rather than hardware. I may look into this when I'm feeling particularly bored, though I don't know how you could have possibly picked a worse game for me to be caught debugging at work. Well, maybe those "Adult Manga" PD ROMs ... EDIT: New WIP. This one adds IsDialogMessage() support. It isn't perfect, the test apps get the highlighted dots around the active controls, but bsnes isn't for some reason. Don't know why that is yet. And it seems once tab enters into a child window, you can't get back to the outer window. But otherwise, it's better than nothing. I even got the z-order thing down so tab works in the right direction. [No archive available] |
|
|
byuu
|
16ba1d1191 |
Update to bsnes v028r15? release.
Thanks, FitzRoy. The controller graphic looks really amazing. I have
two very minor changes to request if you don't mind.
First, I had to increase the size to 372x178 (Windows BMP format adds
alignment if width is not a multiple of 4 -- this makes it a real
bitch to convert the image to my UI wrapper pixel format), and shift
the actual image one pixel left to center the gradient fade.
Second, and more importantly, could you store the controller graphic
in 32-bit format with alpha? Rather than using a white or gray
background, if I could get the full alpha channel information, then I
can adjust the background color to anything I like in the future.
Depending on how it looks, maybe I can just let the controller blend
against the window background itself.
And thank you, King of Chaos, as well. It was extremely difficult to
choose one over the other. I wish I could use just both so as not to
offend anyone. But I kind of like FItzRoy's more. I was kind of going
for that pristine, "cleaner than real life" look. Still, I really
appreciate your help in making a controller graphic.
---
New WIP.
I've added FitzRoy's controller graphic to the input capture window.
It will only display when configuring joypad buttons, not when
configuring UI buttons.
I've also added the new UI settings panel. This lets you control
window translucency for all but the main bsnes window. I capped
opacity to 50% minimum, because I don't want to hear bug reports when
people slide it to 0% and can't find the config window anymore :P
Works on Windows and Linux. If you lack a compositor on Linux, it'll
just stay a solid color. If you have Compiz / Beryl and the blur
filter, use it with gaussian alpha blur. Then you can set opacity all
the way down to 50% and it will still look amazing. I want to post a
screenshot of it, but the image is ~3MB. Maybe later I'll post it to
one of those file hosting sites.
There's also a setting here to control what gets written to the
statusbar. I went back to just displaying the raw ROM title. So you
can use %t for that, %n for the filename, and %f for the frame rate.
Still working on this feature. Plan to keep the game name visible when
pausing, add some additional info that can be output here, etc. It may
be better to keep this setting in the advanced panel, as it's not the
most user friendly thing in the world. Up to you guys, I guess.
Need more settings here, though. Need to fill out that
window more.
[No archive available]
|
|
|
byuu
|
29c871ef62 |
Update to bsnes v028r14? release.
New WIP. Adds Win2k alpha adjust (against black background), some
minor code cleanups, LZSS compression / decompression for storing
graphics, and puts the program icon onto the about screen, which has
been shrunk down a bit again.
So, too late mudlord, the answer was LZSS :P
I wanted to just go with RLE for simplicity, but the compression
ratio sucked. LZSS is the same number of lines of code, yet is three
times more efficient with the icon. And something like a controller
with much more repetition will probably make an even bigger
difference. Meh, the code's easy enough. I wrote it for clarity over
speed, and decompression is always lightning fast with LZ anyway.
Good job decoding the base64 portion, though. Very useful
routine for a library.
As for the controller graphics, wow ... I'm really torn. I really
love how clean FitzRoy's version looks, yet at the same time King of
Chaos' version is so lifelike it's scary. I dislike the "flaws",
though. The scratches on the X, the dot on the bottom right, and the
off-center buttons ... since it's digital anyway, I'd prefer it to
appear perfect, if at all possible.
But it's a tough call. I'll have to hold a vote or
something :)
Thanks a million for helping with the controller graphic,
both of you!
[No archive available]
|
|
|
byuu
|
42f1d08c02 |
Update to bsnes v028r13? release.
New WIP.
Adds a base64 encoder, which zaps the ~21kb icon down to ~5kb. With
the extra space, I used the 48x48 icon instead. It should look a tiny
bit better, but it still obviously can't beat a non-resampled icon.
Also added Linux icon support. That turned out to be a royal pain, as
the gdk-pixbuf library documentation was separate from the GDK
documentation. Tried finding visuals, to make colormaps, to get GCs,
to create pixmaps to blit onto as drawables, to create pixbufs with,
to attach to the window. Turns out, gdk-pixbuf has a function to turn
raw data into a pixbuf.
> Could we have an option to disable this effect in advanced settings
> so that the mode can appear "crisp" as it does in other emulators?
This blurring is required for pseudo-hires to operate
properly, eg in Jurassic Park.
Nonetheless, if you guys really want the option to disable the
blurring, I can add it. Just keep in mind that we're opening up a can
of worms. People will then want an option to disable the sprite
drawing limit, to add hi-res mode7, etc etc. Harder to draw a line in
the sand when you aren't all or nothing.
> This is a problem? If it's a question of storing them all in an ico,
> why not simply say "Here's a nicer ico set seperately, DL if you
> want'.
I'm not going to put resources external to the executable, unless I
absolutely have to. Thus, I have to put all of these icons inside the
source code, and I have to modify the GUI API wrapper to handle this.
> I was thinking, you know, one of you could report it to them.
"Hi, uh, Microsoft? Yeah, your compiler is erroring out
when I compile my emulator with it and PGO enabled."
"Sure, as that's a $12,000 Team Suite Edition feature,
if I could just get your serial number, that'd be great."
"Oh, uh ... I think I left that at home. I'll call you
right back with it, okay?"
"Oh, no problem. If I can just get your full name, I'll
pull you up in our system ... ... hello? Sir?"
::dial tone::
And for the _official_ legal record, I only used the
free trial and express editions :)
> Yeah, one issue they can fix is maybe implement blargg's spc core;
> then again, I thought Snes9x was dead.
Not dead, but on severe life support. Same for SNEeSe and Super
Sleuth. anomie, TRAC and Overload have minimal presence anymore. A
damn shame. The SNES scene is in worse shape than most people realize
at the moment. NES emulators have had dot-based PPU renderers for
years now.
[No archive available]
|
|
|
byuu
|
521f4f6952 |
Update to bsnes v028r12? release.
New WIP.
vcounter / hclock / hcounter renamed to vcounter / hcounter / hdot. I
think it's more clear this way. Fixed up the v/hc stuff to v/h in
bppu_mmio.cpp to match.
Instead of building each driver for ruby independently, I grouped
them all together into one object file. I know everyone else hates
that, but too bad -- that's the way I program. No sense building ~10
object files when one will do just as well. I was able to cut out ~20
lines from the Makefile as a result of this.
I added CB_SETITEMHEIGHT magic to actually set combo box to requested
height. Neat. Of course, bsnes doesn't currently use any combo boxes
in the UI, but it'll be nice when it does, at least.
Lastly, I added something new to the Windows port (that
used to be there a long time ago), just for FitzRoy :P
I'll go over that in more detail tomorrow. For now,
consider it a surprise.
[No archive available]
|
|
|
byuu
|
92cfb1268a |
Update to bsnes v028r11? release.
New WIP up.
I was a little too busy to work on bsnes this weekend,
but I got some work done tonight.
First, I moved the field / interlace / overscan status
functions over to the PPU, where they belong.
This led me to kill a lot of extra CPU timing variables, such as
vblstart and vnmi_trigger_pos. The latter I had to kill because I can
no longer call sCPU::update_interrupts() when the PPU changes the
overscan setting. You may be wondering about interlace toggle -- well,
it can only take effect at the start of a new frame anyway, and the
timing for scanline 0 is the same regardless of interlace setting, so
it doesn't really need to call update_interrupts() anyway.
With this moved back to the PPU, I was able to clean up the PPU
functions a bit, too. Before, I had PPU::scanline_is_hires() and
CPU::interlace(), and then a function called PPU::get_scanline_info()
that would read the previous two functions and copy them into a
struct. What an odd construct, I'm sure it was more complex in the
past. Cruft, basically. I just killed that, renamed scanline_is_hires
to just hires, and now SNES::Video just queries ppu.hires() and
ppu.interlace() directly. Much nicer.
I didn't lose any speed here, either. I made up the difference by
force inlining the PPU states in the bPPU header file.
I ran all my IRQ and NMI tests again, I didn't see any regressions.
Testing of games that use interlace and overscan, as well as of IRQ-
sensitive games, would be appreciated.
While cleaning up the PPU, I had some code that would flush the PPU
buffer when disabling interlace. I removed that as it looked rather
ugly. Don't really have a clean way of handling that. Not like any
game out there toggles interlace every frame anyway.
I went through and killed a bunch of config file options that don't
actually do anything anymore, such as audio.frequency and
video.use_vram.
Lastly, I rewrote the advanced panel code finally. All options that
can be controlled through the UI have been removed. The list is ~80%
smaller now. I also improved a lot of the descriptions. I think it
looks a lot better now, at least. I went with a blacklist, rather than
whitelist. I figure, better to have extra options if I forget to
filter them out; than to have missing options if I forget to add them.
Before the next release, I'd like to add back default_height() stuff
to get the textboxes and buttons smaller on the Windows port. Maybe
revert that back to Tahoma 8. I should also add descriptions to the
last few advanced panel options missing them. Other than that -- just
regression testing, I suppose. I can't break up the PPU enslavement
any more without adversely affecting performance at this point.
Hmm, would also be nice to rename vcounter / hclock / hcounter to
vcounter / hcounter / hdot. Afraid of missing a reference somewhere
and screwing up the timing, heh.
I tried to get the icon working again on the Windows port. But using
LoadImage or CreateIconIndirect doesn't handle the alpha level of
bsnes' icon properly. It ends up as a 1-bit transparency that looks
terrible in the titlebar, as well as the taskbar. The only way I can
get it to look good is with LoadIcon and grabbing the icon from the
resource file. The reason I don't want to do this is because it's not
at all portable to GTK+. Sigh. Tested this on Win2k, by the way. Win2k
isn't supposed to support the alpha channel in icons at all, but it
sure the hell does on the taskbar.
I even tried GetIconInfo() on the icon returned from LoadIcon(), and
then CreateIconIndirect on that, and it crushes the translucency
again. So it isn't a problem with the format of hbmMask and hbmColor
in my ICONINFO struct.
[No archive available]
|
|
|
byuu
|
4d922ba17c |
Update to bsnes v028r10? release.
New WIP.
This one nukes the region, region_scanlines, prev_line_clocks and
prev_field_lines variables, and removes timeshift.cpp; replaced with
the new history ring buffer. It doesn't appear to affect speed at all,
which is fine by me. Next up, I want to move interlace and overscan
settings back to the PPU.
All of my NMI and IRQ test ROMs, even the absolutely insane clock-
perfect ones, still pass. So there shouldn't be any regressions. But
if you feel like testing any IRQ sensitive games, that's cool.
More visibly, I've bound the .cht path to the selection in the path
settings window. So all three paths actually work now. I tested it by
sorting all of my images by ROM, SRAM and Cheat ... have to say, the
folder looks a whole hell of a lot nicer now. I can see why this
feature is so popular.
> Mainly, there needs to be mechanisms to capture the current frames,
> like through render targets.
Well, I guess if you don't mind writing up a small
example I could work on porting the current code over.
[No archive available]
|
|
|
byuu
|
3b2918791c |
Update to bsnes v028r09? release.
New WIP with XP / Vista theming and cheat path selection. Note that cheat selection is just a placeholder. It still saves in the same folder as the ROM for now. I also spent about four hours trying to get the dual counter into a fork of bsnes ... and had my ass handed to me. Rigging something up really quickly that will break every last timing test I have is easy. But it looks like doing this properly is going to be an extreme undertaking that will take at least a few weeks. The code is just too old and too hardcoded. I've started cleaning up that code to match my modern programming style. It seems the only way to really tackle this is going to be very slowly moving variable by variable to a separate class/struct somewhere (and running my regression test ROMs each time), and then once the entire thing is moved out of the CPU, try and clone it and fork off the PPU to its own thread. By my estimates, it appears that simply splitting the CPU and PPU, and giving the PPU its own cothread, is eating ~8% of performance. The good news though is that if and when I succeed, it's quite possible I can emulate the OAM cache behavior, which would fix the black scanlines in Dr Franken and Winter Olympics. Some other good news ... I decided there was really no sane reason to have different clock frequencies for the CPU<>PPU and SMP<>DSP, since the real SNES only has two crystal clocks anyway. A novelty, sure, but that would complicate the fuck out of dual counters. With that gone, I can avoid a 64-bit multiplication during each SMP/DSP addclocks call. That gives a modest ~2% speedup -- possibly placebo. Looks like a ring buffer for timeshifting backwards isn't going to help much. I only notice a ~1-2fps difference even when disabling timeshifting completely. Not surprising, timeshifting really doesn't have that much overhead to it. Oh yeah, it seems I disabled the code that set the hclock to 186 upon reset a while back, which was causing some of my oldest tests to fail. I can't remember why I disabled that (maybe something to do with cothreads), and enabling it didn't seem to cause any problems, so ... I left it enabled. Let me know if anything screwy happens. [No archive available] |
|
|
byuu
|
b7d34a8aa3 |
Update to bsnes v028r08? release.
New WIP.
Fixed the frameskipping bug, fixed the DirectDraw renderer. I also
added a new folder_select function to both ports of hiro (Windows and
GTK+), and with that, I added a new path settings panel to the
configuration window.
You can see how it looks here:
http://byuu.cinnamonpirate.com/images/bsnes_20080219.png
Also, I compiled the Windows binary with Direct3D support omitted.
tetsuo55, please grab this version, as I intend to compile with
Direct3D support for subsequent WIPs.
[No archive available]
|
|
|
byuu
|
8fd90cc123 |
Update to bsnes v028r07? release.
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]
|
|
|
byuu
|
e651beb72e |
Update to bsnes v028r06? release.
New WIP.
Richard Bannister asked me a year ago to add support to detect the
file compression type by reading the header, as apparently Mac users
can't be bothered to use proper file extensions.
In an act of extreme expediency, I've added his request
in record time :P
Here's the detection code I wrote:
Reader::Type Reader::detect(const char *fn) {
FILE *fp = fopen(fn, "rb");
if(!fp) return Unknown;
fseek(fp, 0, SEEK_END);
unsigned size = ftell(fp);
rewind(fp);
uint8_t a = size >= 1 ? fgetc(fp) : 0;
uint8_t b = size >= 2 ? fgetc(fp) : 0;
uint8_t c = size >= 3 ? fgetc(fp) : 0;
uint8_t d = size >= 4 ? fgetc(fp) : 0;
fclose(fp);
if(a == 0x1f && b == 0x8b && c == 0x08 && d <=
0x1f) return GZIP;
if(a == 0x50 && b == 0x4b && c == 0x03 && d ==
0x04) return ZIP;
if(a == 0x4a && b == 0x4d && c == 0x41 && d ==
0x00) return JMA;
return Normal;
}
If anyone sees any problems, please let me know. And unless your name
is Nach, I expect you to read and cite official documentation to point
out any problems.
Note: I need more than 16-bit accuracy to avoid false positives, so I
read the compression type and flags for GZIP. Compression type should
always be 0x08 according to my understanding of GZ. Flag top 3 bits
are always 0 per spec. I guessed with JMA's fourth byte. I hope it's
always zero, but I don't know that for certain.
The new WIP has GZ/ZIP/JMA support built-in, so testing would be
appreciated, though I doubt you'll hit any false positives.
Now, a more important question. Should I enable this
detection by default in bsnes, or go by filename? It's _possible_ an
SNES ROM could have these headers, despite not being compressed at
all. One could even add these signatures intentionally if they really
wanted. A real SNES game could have these bytes at the top of the
file, quite obviously.
So, is it better to cater to people who misname extensions, or to the
possibility that a game might have these bytes in the signature (a one
in four billion chance of happening accidentally. One in 500 million
for GZ false detection.)
---
Also, I added some changes by KarLKoX to allow OpenAL to build on
Windows. Namely, I removed the unused ALut dependency, and added
support to the makefile to include openal32. I don't intend to build
OpenAL into the default Windows binaries (because I don't want extra
DLL dependencies that most people do not have; and because OpenAL
support sucks on Windows for non-Creative cards), but perhaps in the
future I'll offer more than one version for download.
> The "almost black" color below the door is 8/16/24 in bsnes
> (standard preset) and 0/16/16 in SNES9x. It's best to see on a black
> background.
> EDIT: This might be due to the RGB565 format.
Wow, that's quite a difference. If you have bsnes v013-v019, you can
dump the palette through the memory viewer. Perhaps see what SNES9x
has from its savestate, and if it's different -- one of us has an
emulation bug.
Not an RGB565 problem, or the colors would match when
ignoring the low three bits (two for green.)
bsnes:
00001000
00010000
00011000
SNES9x:
00000000
00010000
00010000
[No archive available]
|
|
|
byuu
|
4cbba77fc7 |
Update to bsnes v028r05? release.
New WIP up. This one re-adds HQ2x and NTSC, so all
filters from v028 are back, plus there's the new scanline filter.
So all of that code is now out of the core. It was pretty silly that
eg the S-SMP core was dependent upon the SNES class, which depended on
the VideoFilter class, which depended upon the HQ2x class, which
depended upon the ~50kb HQ2x blending tables. Well, no longer.
While I didn't make V-only HQ2x and Scale2x filters (yet?), I did add
some code to make it fallback on the direct renderer if hires or
interlace is being used. This means the issues with hires games (eg
DKC intro) should be gone. Let me know if you find any problems.
I also re-added DMPSDisable to the GTK+ screensaver disable code,
since that was triggering after ~30 minutes or so still. It probably
won't even work, but whatever.
> Why default to a crippled renderer to save those people a few
> clicks?
First impressions and all that, mostly.
> I have an Intel Mac with OS X 10.4 (no Leopard, sorry, but it
> shouldn't be that different yet) I can test whatever on
Thank you! :D
Okay, first thing would be to make sure libco itself
works. Please download this:
http://byuu.cinnamonpirate.com/files/libco_v13_rc2.zip
You can compile the test program like this:
g++ -O3 -fomit-frame-pointer -c test_timing.cpp
gcc -O3 -fomit-frame-pointer -o libco.o -c
../libco.c
g++ -O3 -fomit-frame-pointer test_timing.o
libco.o -o test_timing
Then just run test_timing that is produced, and let me
know what the output is, or if it segfaults.
> Really, you want a first-gen Core 2 Duo or newer.
Yeah, it's pretty slow. Especially since v018. It used
to be easy to get 80-100fps with a 3500+.
[No archive available]
|
|
|
byuu
|
1194d3f9dc |
Update to bsnes v028r04? release.
New WIP. Windows binary included. I've added back
Scale2x support, and I also added a scanline filter for Snark. No, I
don't plan on combining them so you can do things like Scale2x +
scanlines. It's a 50% scanline filter. I may add 75% and 100% in the
future.
Ah, and a while back I mentioned a certain software
filter I saw. Here is that picture:
http://byuu.cinnamonpirate.com/temp/PhosphorSimTest1.jpg
Unfortunately, I don't even remember where I found the image anymore,
let alone who made it. Does anyone here know how to recreate the
filtered image from the source image?
I'd prefer to avoid baseless speculation, if you know how it is done
-- and better yet, if you can duplicate it -- please let me know. I
really, really like the filter and would love to add it to bsnes.
[No archive available]
|
|
|
byuu
|
89a1b3d65f |
Update to bsnes v028r03? release.
Posted a new WIP, which cleans up src/snes. I've completely killed all the video filtering stuff, and cleaned up the rest. Only the audio WAV logger remains. Didn't feel like moving that to the UI tonight. So far, I have the colortable and a direct filter moved to libfilter. I'll probably just add Scale2X and a simple scanline filter for the time being, but HQ2x and NTSC will have to be re-added before another official release can happen. [No archive available] |
|
|
byuu
|
5a82cdf978 |
Update to bsnes v028r02? release.
Okay, I've posted a new WIP. Windows binary included.
Changes:
- Video output uses RGB888, rather than RGB565
- Removed RGB modes from Xv. They're a major hassle, I can't test
them, and they didn't even work right. Maybe I'll try again in the
future
- $(DESTDIR) added to Makefile
- Increased Linux usleep idle delay from 20 to 20,000, so
bsnes appears to consume 0% CPU time when idle
- Started moving src/snes/video to src/lib/libfilter. So
far, only the colortable has been moved over
I held off on actually using libfilter's colortable. I'm intending to
break things completely here very shortly by eliminating
src/snes/video stuff, but I wanted to get a WIP out before doing so,
so that people could mess around with RGB888.
Speed is going to be a little slower for Linux users who use the GLX
or Xv video driver. Very sorry about this. If you need to, stick with
v0.028 official for the time being.
---
By the way, RGB888 is the bottom row. Thanks for playing. RGB888
doesn't make bright colors darker or vice versa, it avoids rounding
errors. It has the biggest effect on near-black colors, as before they
were getting crushed badly by the exponential curve gamma adjust. But
don't be fooled: really dark colors will still be much harder to see
than with the gamma curve turned off.
Anyway, if you liked the top row more, then just adjust
the settings slightly on the raster settings tab :)
EDIT: Neat, fglrx driver goes from 57.5fps to 59.5fps
with GLX. YMMV.
[No archive available]
|
|
|
byuu
|
52be510d2b |
Update to bsnes v028r01? release.
New WIP posted, Linux only. Need all the testers I can
get on this one, please.
First and foremost, I spent about four hours figuring out how to
disable the screensaver on Linux. I tried XSetScreensaver,
XResetScreenSaver, XScreenSaverSuspend, DPMSDisable, synthetic
XSendEvent, and all of them failed miserably. I ended up getting it to
work with only one thing: XTestFakeKeyEvent. I send a fake keypress
every ~20 seconds. The key send is keycode (not keysym) 255. I don't
know of many 256-key keyboards, so I think that should be fine.
Anyway, testing would be greatly appreciated. Please make sure the
synthetic key events do not interfere with your applications in any
way. Technically, the fake key send goes to whatever the active app
is. It shouldn't matter as the keycode used is undefined. I haven't
seen any GTK+ or Qt apps do anything with it, they just ignore it. If
any issues come up, then the best I can do is enable the screensaver
whenever bsnes doesn't have focus, and disable when it does have
focus. I think it should be fine, though. Totem uses the same trick
and nobody seems to mind. mplayer tries all of my above methods plus
bizarre fake messages and dbus commands to try and stop the
screensaver, and it still fails for a lot of people.
Next up, I've extended the Xv renderer. It can handle RGB15, 16, 24,
32 and YUY2 formats now. It defaults to RGB ones if you have them. I'd
like if all of them could be tested. RGB15 and 16 should be perfect,
24 and 32 will likely have bad pointer arithmetic, but will hopefully
work.
Need to set driver to "xv", and check what you have with "xvinfo". It
defaults to RGB16, then RGB15, then RGB32, then RGB24, then YUY2, then
it gives up and fails. In the future we can see about letting the
encoding be user-selectable.
> if your repository-maintaining friend doesn't have an amd64 install
> with which to build packages
That's exactly it, sorry. Plus I don't want to burden
him more than I do already.
[No archive available]
|
|
|
byuu
|
8b7219bdef |
Update to bsnes v028 01 release.
[No changelog available] |
|
|
byuu
|
926ffd9695 |
Update to bsnes v028 release.
Changelog:
- OpenGL (with hardware filter mode support) and SDL video drivers added to Linux port
- OpenAL (with speed regulation disable support) and OSS audio drivers added to Linux port [Nach]
- SDL input driver (with joypad support) added to Linux port
- Emulator pause option added
- Added option to select behavior of bsnes when idle: allow input, ignore input or pause emulator
- Added support to remap common GUI actions to key/joypad presses on the "Input Configuration" screen
- bsnes will now clamp the video output size when it is larger than the screen resolution
- GUI library has been enhanced, and renamed to hiro
- Fullscreen mode now always centers video, rather than approximates
- Fullscreen mode now works correctly on Linux/Openbox
- Extra layer of abstraction in src/ui has been removed, as GUI lib unifies all ports anyway
- Video, audio and input drivers unified into standard library, named ruby
- All custom headers have been merged into a new template library, named nall
- Makefile rewritten, vastly improved. Allows quick toggling of compiled-in drivers
- Makefile: all object files now placed in /src/obj, binary placed in /
- libco greatly enhanced, no longer requires an assembler to build [byuu, blargg, Nach]
- libco SJLJ driver added; bsnes should now build on any Unix-derivative now (Solaris, OS X, PS3, etc) [Nach]
- Fixed register $213e.d4 PPU1 open bus behavior [zones]
- Windows port will not activate screensaver while bsnes is running [Nightcrawler]
- Visual C++ target no longer requires stdint.h
- And lots more -- mostly code refactoring related
|
|
|
byuu
|
a1389a2ba3 |
Update to bsnes v027r14? release.
> Anything is better than re-using an already well-established name
> (even a short acronym like "vai"), but that's just me.
I was asking about eliminating the extra layer of
abstraction in the UI.
But since you brought it up ... I'm sure vai has been taken before.
Quark certainly has been. Hell, BSNES was taken by some people trying
to port ZSNES to BeOS (they gave up). Given, none of those have
anywhere near the popularity of the programming language. But eh, I
_really_ don't care. I like the name, and nobody else in the world is
ever going to use any of my software libraries anyway, so I'll use it.
Speaking of which, I hate the name miu for the GUI
library, it sounds stupid. So in the spirit of selecting **totally
random names** that are _certainly not associated with any licensed /
trademarked / copyrighted proper nouns_, **especially** not from any
_video games_ or somesuch; I've renamed miu to the **completely
arbitrary** name of hiro. Boy, I'm so creative and original with
naming.
---
That said, new WIP up, with Windows binary.
Windows users, be sure to set system.video to "direct3d",
system.audio to "directsound", system.input to "directinput".
Linux users, "opengl", "openal" and "sdl" are
preferred. "xv", "ao" and "x" are safer fallbacks.
Changes:
- Finally found a problem with dots in folder names, it
screws with GNU make. So foo.bar has been renamed foo_bar.
- Decided to drop the pointless duplications of folder names into
file names, such as miu.gtk/miu.gtk.button.cpp -> hiro_gtk/button.cpp.
Same for libco.
- ruby is completed, all 13 drivers are in the ruby namespace, and
bound to the base ruby.cpp file. The UI just calls
ruby::video.driver("name"); to select a driver. Before v028's release,
omitting the name will select the default best-case driver. ruby is no
longer dependent on anything besides nall (the template library, for
those losing track in the sea of _arbitrary_ names.)
- miu became hiro, as mentioned above. Like ruby, I wanted to remove
the need for platform-specific tests inside the UI for it. There's now
a base hiro.cpp file that will auto-select the best implementation and
compile it. Just build hiro.cpp on whatever platform you want and it
does the rest.
- UI platform abstraction removed. src/ui/miu was moved to src/ui.
The two main.cpp files were merged into one. With the GUI wrapper and
hardware drivers moved out of this folder, it's quite orderly there
now.
- More improvements to the Makefile system. New folder obj/
accumulates all of the object files now. Added streq(al) and
strn(ot)e(qual) to Makefile.string library. Improved the delete
command to support deleting from either obj/*.$(obj) with rm, or
obj\*.$(obj) with del. bsnes executable is moved up one folder above
src/ for both Windows and Linux now. The batch file doesn't perform
this copy anymore.
- Killed the doc/ folder. Just a pointless, out of date
.dia file there anyway.
Future plans:
- I want to make ruby take advantage of nall/config.hpp, and output
to ~/.bsnes/ruby.cfg. This file will contain driver-specific
configuration settings. I may or may not add editing support for them
to the advanced window. Or maybe I'll be lazy and just throw
everything into bsnes.cfg.
- Really need to add automatic driver selection to
ruby. Can't release it with "" defaulting to no driver.
- I'd like to replace the god-awful GTK+ video driver (that spawns a
new window) with SDL video. Yeah, I know. At least with SDL_WINDOWID
environment variable hack, it will go into the main window. I'll
probably make this the default driver on Linux, since ATI can't even
seem to get X-Video right with their drivers.
[No archive available]
|
|
|
byuu
|
5263ffb7aa |
Update to bsnes v027r13? release.
Yeah, I'll probably worry about the axis stuff later. I didn't intend
to spend a ton of time on adding SDL input support like this, to be
honest. Though I guess I should have known better with SDL and Linux.
Okay, new WIP with no Windows binary. There's really no reason to get
the WIP. The only change is renaming vai to ruby. That's right matz,
ruby. Deal.
Moved the folder to lib/ruby from ui/vai. The main point is trying to
make it easier to use for other applications. Instead of having each
app include all sorts of platform-specific header files and manually
create the objects at runtime, it's all done for you now. Just
#include <ruby/ruby.h>, call ruby::input.init(const char *driver = "")
and use it. So far, only the input driver has been ported in this way.
Note: if you use this WIP, you'll want to make sure system.input is
set to either "sdl"/Linux or "directinput"/Windows. It defaults to no
driver with "", for the time being.
Once I finish the video and audio drivers in the same manner, I'm
strongly considering eliminating the "multiple UI" bindings, as my
Win32/GTK+ wrapper is pretty much meant to wrap all possible
interfaces into one. This means it would be harder to create a
standalone, GUI-less SDL or VESA2/DOS only port in the future, for
example. But I really don't have any plans to do that anyway. So it's
just needless separation of components, really.
That extra separation layer was being blurred a lot recently anyway.
The config.cpp file was adding miu-specific GUI commands, where they
had to be to bind to interface.cpp, which binds to the core. Meh.
So basically, I'm wanting to change the structure from:
core <> abstracted UI <> miu, SDL, VESA2
to:
core <> miu
Even with this, porting to pure SDL would still be doable in the
future, you'd just have more code to write to do it.
Any objections?
[No archive available]
|
|
|
byuu
|
1744bcb99c |
Update to bsnes v027r12? release.
New WIP. I removed property.hpp, as I really didn't like it. Reverted Audio wrappers to use cap/get/set method that Video and Input wrappers use. Yay, consistency. Capped input.sdl to only poll up to six axes. I suppose if someone really only has 2 or 4, and has phantom 5,6 axes, they'll run into Glenn's problem. Meh. We'll wait for a way to configure vai settings on a per-driver basis to work on that problem more. I was thinking of just giving it the handle to either unique configuration class objects, or to the bsnes.cfg one. Just dump all settings for all (compiled-in) drivers in there, in case the user wants to keep swapping between drivers. Added Nightcrawler's screensaver and monitorpower disable code. Happy now? Note, I don't use screensavers, nor do I feel like playing for ten minutes to verify. If anyone else could verify whether or not it's working, I'd appreciate it. Note again, this won't work on X11, only Windows. Improved the makefile a bit more for Visual C++. Disabled the warning about passing "this" in a constructor. It's valid and safe C++, and the only way to implement a bidirectional private implementation by reference. The last warning is comparison between unsigned long long and bool, which I can't see a problem with (it gives no warnings about unsigned long and bool, either). Should I just disable that warning, as well? > It ended up being axis 6, but yes, that pinpointed it exactly. Oops, sorry. When there are two of something, I always have a really hard time telling them apart (x/y, hidori/migi, edge/level (sensitive), etc etc). Not sure why that is. Three or more choices and it's never a problem. > Would need porting for BSD gamepads however. If it doesn't support BSD, then I'm not really interested. I kind of have to special case Windows (~95+% userbase), but I don't personally want to waste my time writing Linux only code. [No archive available] |
|
|
byuu
|
6362044c05 |
Update to bsnes v027r11? release.
Alright, new WIP posted, Windows binary included.
I've added the auto-pause setting. I removed the formerly useless
joypad selection comboboxes, as I want to stick those in the main menu
when they are ready anyway. It defaults to auto-pause, so that
discussion is moot now.
Don't complain that three combo boxes are not natural compared to two
checkboxes -- I don't care. There are only three possible states, and
I like it the way it is. Thanks in advance.
Nach, you have my humble thanks for your input today. This was
definitely a lot easier than I thought it would be with your help.
For those curious, here's how things look at the
moment:
[image]
I also fixed up the CPU usage when paused. I tried to stress test as
many things as possible (manual pause <> auto pause conflicts,
statusbar update failures, toggling settings in real time, etc etc),
but I may have overlooked something. Rigorous testing would be
appreciated :)
---
In other news, I completely rewrote the Makefile. It is now far more
advanced, and will allow you to easily remove vai modules. Once
removed, the dependencies on those modules will automatically be
removed. The source still needs to be updated to auto-detect non-
existent modules, but this is a step in the right direction.
Take a look at some of my GNU make-fu:
ifneq ($(findstring gcc,$(compiler)),) # GCC family
flags = -O3 -fomit-frame-pointer -Ilib
c = $(compiler) $(flags)
cpp = $(subst cc,++,$(compiler)) $(flags)
ifeq ($(platform),x) # X11
miu = miu.gtk
vai = video.glx video.xv video.gtk audio.openal
audio.oss audio.ao input.sdl input.x
link += $(if $(findstring audio.directsound,$(vai)),$(call
mklib,dsound))
link += $(if $(findstring
audio.openal,$(vai)),$(call mklib,openal) $(call mklib,alut))
link += $(if $(findstring
input.directinput,$(vai)),$(call mklib,dinput8) $(call
mklib,dxguid))
link += $(if $(findstring
input.sdl,$(vai)),`sdl-config --libs`)
arch := $(patsubst %,$(call mkdef,%),$(arch))
objects := $(patsubst %,%.$(obj),$(objects))
compile = $(strip \
$(if $(filter %.c,$<), \
$(c) $(1) $(rule), \
$(if $(filter %.cpp,$<), \
$(cpp) $(1) $(rule) \
) \
) \
)
%.$(obj): $<; $(call compile)
video.glx.$(obj) : ui/vai/video/video.glx.cpp ui/vai/video/*
video.gtk.$(obj) : ui/vai/video/video.gtk.cpp
ui/vai/video/*
$(call compile,`pkg-config --cflags gtk+-2.0`)
Hahahahahah :)
[No archive available]
|
|
|
byuu
|
319b244af4 |
Update to bsnes v027r10? release.
New WIP posted.
I downloaded a 64-bit Linux OS to verify that libco.x86-64.c worked
this time. Turns out the problem was that I declared "register stack =
*(long long*)to;" -- forgot the size qualifier, so it was being
truncated to 32-bits. Anyway, it works now.
I also added two more GUI keys, one to pop open the load ROM window,
and one to pause emulation. Yes, took me eight versions, but I finally
re-added pause mode. It probably still consumes CPU time, not sure. I
don't really care, I'll fix it before release. The whole thing is
silly anyway, task scheduler is so easy to cheat. Add sleep(1) inside
the main loop and it states bsnes uses ~1-2% CPU time. As if.
Windows binary updated, too.
> Unfortunately, it will be 64-bit and using Vista 64 Ultimate, so I'm
> not sure what all will be compatible in terms of software and
> emulators.
32-bit software runs fine for the most part on Vista. bsnes works
there for sure. But if you want it 64-bit native, you'll have to
compile it yourself, as I have no idea how to make a 64-bit Windows
binary. Nor do I really feel like maintaining another build :/
[No archive available]
|
|
|
byuu
|
a3f1802845 |
Update to bsnes v027r09? release.
New WIP. No Windows binary. This one fixes the GTK+
fullscreen issue on Openbox completely. How do I know? Because I'm
running Openbox now to verify :P
It's pretty spiffy, whole thing is only consuming ~5mb
of memory. Total mem usage sans the 'fox is ~40mb.
The cool part with these changes is that video no longer flickers for
one frame when you toggle the menubar in fullscreen mode anymore. Not
even on XFCE.
Just in case, verification always helps. Hopefully it'll work on all
the esoteric window managers out there, so long as they honor the
undecorate window request. You may have some small issues if not.
I didn't need keepabove to get on top of my XFCE panel, even when I
run the panel in Openbox. I'd like to keep it off if possible.
void pWindow::fullscreen() {
if(state.is_fullscreen == true) return;
state.is_fullscreen = true;
gtk_window_fullscreen(GTK_WINDOW(window));
gtk_window_set_decorated(GTK_WINDOW(window),
false);
gtk_widget_set_size_request(window,
gdk_screen_width(), gdk_screen_height());
}
void pWindow::unfullscreen() {
if(state.is_fullscreen == false) return;
state.is_fullscreen = false;
gtk_widget_set_size_request(formcontainer,
state.width, state.height);
gtk_widget_set_size_request(window, -1, -1);
gtk_window_set_decorated(GTK_WINDOW(window),
true);
gtk_window_unfullscreen(GTK_WINDOW(window));
}
I also fixed the "esc" -> "escape" keysym for menu toggle, and
updated the x86-64 target with OpenGL + SDL input stuff. Thanks
everyone for the awesome feedback!
> EDIT3: How come you haven't added the icon to the window? Need to
> write another class for handling it (for MIU)? Adding the following
> to the end of pWindow::create() in
> 'src/lib/miu.gtk/miu.gtk.window.cpp':
Yes, I need a way to do the same in Windows. Ideally, I need a way to
embed the icon inside the EXE, and have an API that allows me to set
the icon both on Windows and Linux from it. I'd prefer to not require
another external file for bsnes binary releases.
Thanks for the GTK+ code, though. It's a step in the
right direction.
> I tested the linux version of bsnes with my Radeon Mobility x1400,
> and I don't get any video inside the bsnes window. I'm running
> Ubuntu, and I've set up all the ATI driver stuff, AFAIK (Compiz, at
> least, works).
Aw ... well, thanks for trying. I kind of figured it wouldn't work.
Perhaps ATI doesn't support GLX ... I honestly have no idea. I'll look
into it.
> What other package(s) do I need to install to correct these
> warnings/errors?
libsdl1.2-dev
> My first problem when running this WIP is that my statusbar is
> black. All black. No one else has complained, so this must just be
> happening over here... any ideas why? Also, fullscreen won't work
> for me... gameplay freezes for a moment when I toggle it and then
> continues windowed, as normal.
Sigh. I fixed this a while back. Certain GTK+ themes weren't painting
the background of statusbars, so I embedded the statusbar inside an
event box. I don't know why it still isn't working for you. It seems
to work for everyone else now ...
> Secondly, when attempting to map my gamepad, every single key logged
> correctly... except my right directional. What? Weird.
Good question. The SDL docs say axis 0 = x, axis 1 = y. but the two
thumbs are axes 2, 3 left and 4,5 right. The left thumb uses 2 for X
and 3 for Y, but the right uses 4 for Y and 5 for X. Since the API has
no way to tell you what direction an axis is in, I decided to play it
safe and do axis&1 over all axes. I guess I'll just hardcode for D-pad
+ two thumbs in the next version by swapping 4 and 5 ... no idea how
other apps do it.
> Finally, turning on Scale2x with or without opengl as video does
> this to the Donkey Kong Country intro (note the statusbar)...
Longstanding issue. Never modified the hq2x and scale2x filters to
support hires modes. Only direct and NTSC do. Hoping to bypass the
issue with pixel shaders in the future. That, or wait until I cleanup
the video filter code and get it out of the core.
> Does GtkSocket not do what you're looking for?
> http://www.gtk.org/api/2.6/gtk/GtkSocket.html
Nah, that's for other processes. I just need to convert an X11 handle
back to a gtk_drawing_area GtkWidget. Sounds weird, but miu only has
one handle() function for cross-platform reasons. So I make that
export an X11 handle (that Xv and OGL take) rather than a GtkWidget
handle (which requires gdkx.h header to extract the X11 handle from in
a safe manner.)
[No archive available]
|
|
|
byuu
|
4370acae2e |
Update to bsnes v027r08? release.
Okay, new WIP. This time there's a Windows binary.
I improved input.hpp a lot, and now InputManager will scan the
joypads as well. DirectInput is fixed, so the Windows port works
again. Now that the InputCaptureWindow stuff is cleaned up, I made it
only capture joypad assignment keypresses when that window has focus.
I'm also planning to make a "fast assign all keys" button or
something, like I used to have. Not sure how I want to do that just
yet.
I also tested triggering UI events through the joypad,
it works great :)
Now I just need to add entries to Input Configuration window for each
UI action. Hmm, should I list the UI entries above or below the SNES
joypad entries? (eg ui.fullscreen, joypad1.up, ... or ...
joypad2.start, ui.fullscreen?)
The rest of my time tonight I spent working on my cross assembler,
xkas. Added sublabels to it, and some more parsing improvements. It's
getting messy already, though. Trying to write complex grammar parsers
in C++ usually does. But it has to be pure C++. No yacc, flex, etc.
So, I'll have to go back through and find redundant code to factor
out. Why would you care about xkas? Well, the sooner I get that done,
the sooner I can help out the Mother 3 translation project a bit more.
GBA cross assemblers suck for ROM hacking.
> You have a big disclaimer about how it's perfectly legal to use "_0"
> as an identifier inside a namespace... and then never actually do
> it.
I was using it for joypad button IDs, but I just decided to go with
button_0n. I removed the comment in the latest WIP. Also added a way
to index joypad IDs at runtime, and packed the enums into a linear
list.
> Apps that process input according to 'the characters printed on the
> key' are my pet hate because I the Dvorak layout, so Z and X or WASD
> are not nearly as convenient as you might otherwise expect.
Would require supporting every keyboard in existence, and needing
some sort of lower-level stuff to translate keycodes to raw keyboard
IDs. The only issue you'll have to reassign your keys one time on
first startup :(
I envy you though for managing to switch to dvorak. I tried for a
really long time, I could never get above ~40wpm, whereas I get
~110wpm with qwerty now. I think programming is the worst part, all of
my brackets moved? Well, that or the fact that all apps use
Ctrl+C/X/V/Z. That hack to make Ctrl+ use qwerty on dvorak doesn't
solve the underlying issue, either.
> If there is any other areas in the bsnes ppu rendering code that you
> want me to verify in a similar fashion, please tell me, so that I
> can try and code something to prove if it is right.
Hahah, there sure are :)
I think the biggest one is that I've yet to test setting BG3 tilesize
to 16x16 when using Mode2/4/6's offset-per-tile mode. Does it affect
indexing? I don't think that it does. May want to also toggle BG1/2
tilesize, just for fun, but I'm almost certain I have that right
already.
Don't worry about it if you're busy. It's obviously not a big deal
since no game in the world uses the effect (that, or I already emulate
it correctly), and I'll no doubt get around to it if I ever rewrite
the PPU emulation.
Either way, many thanks for helping me with this :D
[No archive available]
|
|
|
byuu
|
5a804eac58 |
Update to bsnes v027r07? release.
Okay, new WIP.
But before you download it ... there's no Windows binary, because I
haven't finished porting some changes over to DirectInput yet. So it
won't compile just yet.
But, here's the changes anyway:
- fixed up the recursive descent math parser, it should
reject 100% of invalid math now
- added a new header, new.hpp, by Nach. This allows for uint8_t
*buffer = new(zeromemory) uint8_t[65536]; //zeromemory ==
memset(buffer, 0, 65536);
- updated input.hpp more, and removed keymap.hpp
completely -- this is why DirectInput is broken right now
- rewrote all of inputmgr.cpp, and InputCaptureWindow. The really
ugly, hackish code is now gone. InputCaptureWindow no longer needs to
hijack the main UI event loop to catch keycodes. Instead, a ~20ms
polling occurs that will alert event::key(up|down) of key changes. The
really, really good news about this, is that it also catches the UI
keypresses now, too. That means that I can now map GUI events to the
joypad, or alternate keys!! Expect that within the next release or
two.
- ran krom's mode7 test -- holy hell, he has good eyes o.O -- took me
about 20 minutes to definitively tell which output looked correct on
my SNES. He was right of course, and I trusted him, but double
verification is always nice, right? Removed TRAC's theorem from the
mode7 code, and spruced up the formatting in that file a bit.
- **a real emulation change!!** zones recently pointed
out that anomie figured out that $213e.d4 was PPU1 open bus. I'm
pretty sure I was really thorough when I initially added PPU1+PPU2
open bus (even verified CGRAM.d15 open bus (-much- harder than it
sounds)), but I guess I missed a bit ... odd. anomie also said that
$213e.d5 is basically tied to GND, so that should mean it always
returns 0. I read previously that it was some weird "no PPU activity
for ~40 frames" bit or something, but I don't even remember where I
saw that. I trust anomie anyway, so that means all PPU register status
bits should be accounted for. Thanks for the heads up, zones! :) Now,
of course, it's _extremely_ minor and it won't fix any games (there
aren't any known bugs anyway), but it's still nice to actually fix
something in the core for a change.
[No archive available]
|
|
|
byuu
|
3b65b50aea |
Update to bsnes v027r06? release.
Double post! Better to separate this, I think.
Okay, new WIP lacks Windows binary, and only changes one
header.
I figured it might be fun to show you guys what I've been doing as
far as code cleanup goes, something a little different, you know?
Okay, here was the config.hpp file from the last WIP:
http://byuu.cinnamonpirate.com/temp/config_old.txt
And here is the new one:
http://byuu.cinnamonpirate.com/temp/config_new.txt
Or for those who do not know C++ ... :)
Like a standard library should be, I've reverted UpperCase to
lower_case, I've converted everything to const-correctness, I've
hidden everything that should not be public, improved the code
formatting, added proper casting, removed the needless template
overloads all over the place, converted the variable names from
incomprehensible gibberish (idef, ifmt?) to clean, understandable
alternatives (default_value, type), removed needless copying of const
char* data, which means no more destructors needed, and added proper
int -> unsigned types when indexing arrays.
The only thing left is to add better-named integer->string conversion
routines to string.hpp, to get rid of the ugly sprintf code.
[No archive available]
|
|
|
byuu
|
a85ff8c437 |
Update to bsnes v027r05? release.
Another WIP, this one's really just for myself to look
over at work tomorrow.
Changed any.hpp again to not auto upcast fundamental types, as it
causes problems such as downcasting references to long doubles and
such. Sucks how limited the any type is by forced casting 100% of the
time, but whatever ... no endian issues possible now, at least.
I added property.hpp and bound that to the Audio class (not to Video
or Input yet). It's a lot more complicated than the old integral
identifier cap/get/set functions, but I need the char*-named list
functionality to allow changing driver-specific settings from the GUI
one day. Not too much done there yet. Need to work on it more, I'd
like to make bconfig use property.hpp rather than the IntegerSetting +
StringSetting classes. Tried to make property.hpp read in a config
file without bstring, talk about pain ... ugh.
Tried to move bstring into nall, failed miserably. When strcpy(char*,
const char*) is in the global namespace and strcpy(string&, const
char*) is not, the compiler gets angry. Not going to work. Really
should go object-oriented entirely and ditch libc functions, but ...
that's a _lot_ of code rewriting on my part. Need to think about it
more first.
Removed bbase.h dependency from bstring, miu and xkas. Now I just
need to do something about bkeymap.h, and things will be looking a lot
better for code sanity.
Nach wrote the _seventh(!!)_ libco driver tonight, an
implementation using setjmp / longjmp. Pretty neat, overhead is ~20x,
which puts it only slightly worse off than Windows Fibers on my
machine. Using it in bsnes slows the emulator down by <1%, but it
should be portable across all Unix-derivative systems now. This means
eg a PS3, Alpha, SPARC, etc port should be completely doable now, just
need someone to compile it.
Planning to position libco as a competitor to GNU Pth,
so that leaves me with:
SDL -> vai
wxWidgets -> miu
GNU Pth and pthreads -> libco
boost and Loki -> nall
std::string -> bstring
Good times. Now I just need to register
inventedhere.org for all of these libraries.
> but it's pointless since the sound quality of the S-DSP isn't good
> enough to make a difference.
The only thing we could possibly bypass would be the driver / API
resampling our audio (eg 32khz -> 44khz native). Running each SNES
channel through its own hardware channel is just silly. Either use an
API that bypasses the mixer, or don't.
And yes, there's lots of ways to "enhance" the audio. Replacing
gaussian with a higher end interpolation, bypassing the clipping, etc.
But then you end up with "better" (in most cases), but less accurate
sound.
> is anyone currently working on an enhancement snes emu?
ZSNES adds cubic spline audio interpolation, SNES9x adds "hi-res"
mode7, ZSNES/XBOX adds rumble pad support to most games.
Other than smaller things like that, not really.
I've talked about adding things like rumble, a new MMC to map more
than 64mbits, CD-audio and video playback capabilities. Nobody seemed
all that interested. Eh, maybe if someone finds and sends me one of
those SNES CD player addons used by that one English teaching game,
I'll add support for that to bsnes and then rig something like Der
Langrisser to use it :P
[No archive available]
|
|
|
byuu
|
a15d15047c |
Update to bsnes v027r04? release.
Okay, I posted a new WIP. This one's source only again,
since the Windows port is still unchanged.
I went through and used std::min + std::max, rather than my own
#define, for the sole benefit of getting Nach's JMA code to compile
again (JMA includes a C++ standard header that doesn't like you
#defining min/max, apparently). I was kind of cheap with it though,
max(0, min(10, value)) -> max(0U, min(10U, value)), etc.
Geez, std::min/max can't even cast between uint16 and uint32. What a
joke, I'll have to write my own that takes advantage of type traits.
I also started killing off the "bheader.h" files. Since 90% of them
are just template classes, I figure I may as well stick them all in a
namespace and make something akin to boost / Loki. I'm calling this
one nall (I love making up all these names, lately). I also use gcc -I
to point to it, so you get #include <nall/array.hpp> instead of
#include "../../../lib/barray.h", much nicer.
Taking advantage of the new template library, I added any.hpp
(generic object container), traits.hpp (type traits) and static.hpp
(static assert, if), and with that, I made stdint.hpp, which is a C++
implementation of stdint.h. Since stdint.h is part of C99, it isn't
included with all compilers (eg Visual C++). By using sizeof() and
static_if, I was able to make my own compiler-independent version of
this file. Thus, the dependency on stdint.h was removed.
I'd be very interested in feedback on anything in nall/
(it's located in src/lib).
Specifically, could someone with a big-endian machine test any.hpp?
I'm worried that downcasting will reverse the order of data read back.
Example test app:
#include <stdio.h>
#include <nall/any.hpp>
int main() {
nall::any t = 0x01020304;
printf("0x%x\n",nall::any_cast<short>(t));
//should print 0x0304
return 0;
}
> Please byuu, can you extend the API, would you be so kind?
Of course, I want vai to be used for more than just SNES emulation.
Though I've yet to get anyone using any of my libraries before, so it
may be a fairly pointless endeavor.
It'll take me some time, though. I'm working on a lot
of other stuff first.
> Anyways, byuu, here's what I wrote of the OpenGL renderer so far, to
> prove its very much being worked on.
Really cool! My only concern is the use of Win32-specific code
(header, GetForegroundWindow(), HDC stuff, setting up the pixel format
stuff) ... no idea how this is going to compile on Linux :(
I don't know the Linux equivalents to all of the
Win32-specific stuff being done.
Nonetheless, please take your time. I'll check it out when you have
the Win version finished. Thanks a million for making this :D
> What about guys like me who just stick to Intel HDA.
Hah, I do the same. I'm not going to spend more on my
sound card than on my mainboard that comes _with_ onboard sound. HDA
sounds just fine to me :/
[No archive available]
|
|
|
byuu
|
f77aca7172 |
Update to bsnes v027r03? release.
I have a new WIP up. Again, this one has only source, as nothing has
changed on Windows since wip01.
This time, I've just cleaned up the OSS and OpenAL drivers. Nach will
probably want to kill me, since by cleaned up, I mean "removed lots of
not-so-helpful comments and safety checks", but I intend to add them
back. Before v028, I'd like to have vai init() functions return a
boolean success value, and have bsnes continue to fall back on lesser
drivers until there are none left, in which case it won't use one. But
it will keep the program from crashing.
Also, I tried some black magic on the OSS4 support. Because
soundcard.h is included in a different location than the OSS3 one, I
tried manually defining the new SNDCTL options and invoking ioctl
regardless of OSS version. This is supposed to be safe -- the ioctls
should just fail silently and it will behave just like OSS3. Let me
know if you have problems compiling or using the driver with OSS3,
especially on non-Linux boxen.
> Will you update the readme with recommendations for
which sound driver to use on which system?
I suppose I can do that. I was planning on writing up an article
about OSS4 and such, perhaps I can just link to that in the readme.
> I changed it to set_background_color(0, 255, 0) and sure enough I
had a green statusbar. The main window background color was still
black though. Assuming that set_background_color() is meant to be used
for the main UI this is very odd.
Okay, here's how this works. Inside the main window, there is a view
control, which is a gtk_drawing_area(). I draw the video to this. When
bsnes is in windowed mode, obviously this control fills the entire
window. And the view control draws a black background by default. But
when you go fullscreen, the view area centers itself on your screen
(or tries to, some issues in GTK+ size requests render it non-
perfect.) Now there's the problem that the window itself is exposed on
the sides. Therefore, I have to set the window background to black
here, otherwise it will show up gray, which is _very_ distracting in
fullscreen mode, to say the least.
Now, I only tell GTK+ to set the window to black. The reason I do
this is because just setting the formcontainer to black has no effect,
since containers do not draw a background. As for why that is causing
your statusbar to render black ... good lord, I have no idea at all
o.O
I don't know what to do to fix this, unfortunately ... but at least
we now know where the problem is so we can research it. Thank you very
much for tracking that down [vEX], I realize my request to have an
end-user look into that was unreasonable, but it's very much
appreciated.
> EDIT2: After some testing it doesn't appear that bsnes was guilty.
I can't reproduce the memory consumption, but it could be all the
recompiling bsnes that somehow ate all my memory.
bsnes does appear to have a tiny memory leak at the moment. It loses
about ~100k a minute on me. I'm not sure if it's specific to the Linux
port or not. This will certainly be a hard one to track down in such a
big program.
> I believe OpenAL is pretty smart in frequency handling.
Definitely. I don't really like complex APIs, but the buffering
system in OpenAL will actually come in handy. I failed with
DirectSound, but maybe with OpenAL I can manage to resample audio --
maybe even let OpenAL do the resampling for me by calculating the
frequency as a measure of "how many samples should have been created"
versus "how many actually were."
That would be awesome. Combine that with OpenGL triple buffering, and
SDL/libjsw joypad support, and wow ... I'll have something really,
really usable :)
[No archive available]
|
|
|
byuu
|
c32195cbd6 |
Update to bsnes v027r02? release.
Okay, here's the deal with sound.
wertigon's initial OpenAL driver was incomplete and produced no
audio, and _willow_'s had some Windows-specific bindings.
So, Nach took those, some OpenAL sample code, and some other
application's OpenAL code and produced a working driver for it. Then
Nach and I refined the driver -- I got rid of the crashing on exit and
frequency changing, and both of us wrote new sample() functions.
Nach's is vastly superior on CPU resources, so we'll probably go with
that one.
That code can be found here:
http://byuu.cinnamonpirate.com/temp/audio.openal.cpp
This code wouldn't be possible without the help from
wertigon, _willow_ _and_ Nach, so many thanks to everyone, and I'm
sorry I wasn't able to go directly with anyone's specific OpenAL
driver. Linux compatibility was a big concern here. You'll all be
getting full credit in the source and documentation for bsnes v0.028.
---
Now, as for the driver itself. It should work on Windows now with the
sample() and init() corrections, but maybe not. I don't have the means
at the moment to build a Windows binary with it, but maybe I can in
the future.
But anyway, I don't intend to compile in OpenAL/Win support by
default with bsnes, but rather leave it as an option for those who
compile it themselves. Why? Because Windows does not come with
alut.dll and OpenAL32.dll. I don't want to require another download to
use bsnes, and I don't want to package an extra 300kb of DLLs with it
either. Plus, it doesn't seem to be working too well for most people
anyway thus far.
Windows does come with DX9, and basically nobody has problems with
DirectSound. It's great, it has very low latency, and it seems to work
on everyone's sound cards, unlike the OpenAL stuff. So it's really not
needed for Windows.
---
However, on Linux, OpenAL has a lot of good points. Unlike with
Linux/OSS3, OpenAL backends to ALSA which supports software mixing.
Meaning audacious and bsnes can run at the same time. And OpenAL has
much lower latency than libao, as well as the ability to disable speed
throttling when necessary.
But! The OSS4 driver, with SND_DSP_COOKEDMODE,
absolutely _destroys_ even the OpenAL driver. In fact, it's even twice
as good as the DirectSound driver on Windows! No joke!
From http://wiki.freebsd.org/RyanBeasley/ioctlref :
> ... this ioctl is meant to give processes direct access to the
> hardware buffer, giving the application the most control possible
> (ex: minimizing latency by avoiding in-kernel processing).
With this, I get roughly ~15-20ms latency, at the very most, with
bsnes. It skips kernel processing entirely! It's hard to even describe
such a low latency. I've never heard Link's sword sound effect start
so quickly. It's really quite impressive. Remember when kode54 was
talking about ASIO or kmixer or whatever? That super low latency
kernel-level audio setup that bypasses the kernel and goes directly to
the sound card? This is it, but for Linux. It's that good.
But the problem, of course, is Linux' obsession with ALSA, even
though OSS4 is GPLv2 now (and not to mention portable). ALSA is, of
course, total garbage. Anyone who's programmed for it knows that.
It's very easy to install OSS4, download a DEB package, double click
it, hit install and reboot. But the problem is, many Linux distros try
their best to kill OSS now. Lots of apps are compiled by Linux distro
vendors to only support ALSA, so it does cause some problems, and you
have to reconfigure many apps to use OSS afterwards, so it's not a
very good solution to make bsnes default to the OSS driver.
Further, because ALSA is so terrible, it causes the OpenAL driver
(which is really just a wrapper to ALSA here) to suck, and it causes
lots of static in the sound. And ALSA's OSS emulation causes severe
video lag -- bizarre, but it has something to do with the blocking
mechanism in ALSA. Only installing OSS4 fixes this. For both drivers,
in fact.
So, because of ALSA's pathetically poor emulation of both OSS and
OpenAL, I can't default bsnes to either of these drivers. Therefore, I
have to leave the libao driver as the default, but I really recommend
the installation of OSS4 (if you haven't gotten that hint already) if
you really want the best audio possible, and don't mind losing a
couple of your favorite ALSA-only apps. If installing OSS4 is too much
of a plunge, then I still recommend experimenting with the OpenAL and
OSS (in that order) drivers under ALSA. If they work good, great. If
not, sorry, it isn't a problem with the bsnes drivers. You'll have to
stick with libao and it's terrible latency and forced blocking. Unless
someone else wants to write an ALSA driver. I have no intentions of
programming for yet another single-platform API, myself.
---
With all of that said, I have a new WIP up. I'll send the link to any
Linux users who want to test it, as well. Feel free to ask.
This WIP is source code _only_ (nothing changed on
Windows), and has both the new OpenAL and OSS drivers. Testing would
be greatly appreciated.
[No archive available]
|
|
|
byuu
|
161366df9b |
Update to bsnes v027r01? release.
I posted a new private WIP that adds the new statusbar. But much more
importantly, thanks to Nach, the Linux port now has an OSS driver.
It's current set as the default. You can get ao again by
setting system.audio to, yep, you guessed it, "ao".
Would some Linux users mind giving it a spin? For me, it appears to
be blocking and causing serious video lag (xv [XV_SYNC_TO_VBLANK=0] or
GTK+ video, 60hz monitor, speed regulation = normal). Not happening
for Nach ... it's quite possible the problem is just on my system.
The complete and utter lack of perceived latency lag though, makes
this sound a million times better than the ao driver.
[No archive available]
|
|
|
byuu
|
4c43e85141 |
Update to bsnes v027 release.
This version replaces libui with miu -- a new GUI wrapper library, and cleans up large portions of the source code.
Unfortunately, the GUI rewrite took far, far longer than I ever imagined. As a result, no work has gone into the core emulation for this version. But with the GUI rewrite out of the way, that should change in the near future. And thanks to the new UI library, I can now begin work on adding a cross-platform debugger to bsnes, at long last.
Changelog:
- Major source code cleanup (lib/, ui/miu/, ui/vai/)
- Cheat code editor was broken in v0.026, this is now fixed
- Cheat code file format simplified for human readability
- Makefile install target improvements [belegdol]
- libui replaced with miu GUI library
- Custom video / audio / input drivers replaced with vai HW library
- ppc and ppc64 libco targets added [Vas Crabb]
- x86 and x86-64 libco targets now work on OS X [Lucas Newman]
|
|
|
byuu
|
9da42c18c3 |
Update to bsnes v026r04? release.
Another WIP. Consider this one v0.027 RC1.
Bugs fixed:
- cheat code editor works once again -- cart/ was not loading or
saving the files, and memory/ was not reading from it. Yeah, it was
completely broken in v0.026
- miu/Win supports window.set_background_color(). The trick was to
capture WM_ERASEBKGND and use FillRect to draw the background myself.
- miu/Win menubar toggle in fullscreen mode works as expected now for
me. Testing would be appreciated. A total shot in the dark, I tried
using SWP_FRAMECHANGED when resizing the windows, and it worked. It
seems to be an issue due to having two windows that are both set to
use the same menu (I have a hidden window I use for resize-purposes
only, because AdjustWindowRect doesn't work right on multi-line menus,
but the resize window is never visible.) I'm not sure exactly why
SWP_FRAMECHANGED fixed the problem, or why it wasn't needed in libui,
but it works, so I'll take it.
- make install target uses "install" rather than cp+chmod, but
belegdol unfortunately removed his makefile patch, and I don't recall
where $(DESTDIR) and $(PREFIX) are supposed to go, so those aren't in
there yet ... belegdol, could you please repost that? You're of course
free to change my makefile with your packages as always in case it
gets missed before v027.
Bugs remaining:
- D3D renderer is still acting weird. If you start at 256x224 window
size, then the point video filter never works. If you resize to a
larger window and back to 256x224, the video image is linear filtered
no matter what. I tried to fix this tonight, but I had no luck. I'm
really not sure what's wrong, I don't think it's ever really worked
right. Should I fallback on the DDraw renderer for the next release?
It lacks the point filter mode (DDraw lacks an API to control mag
filtering), but that's it. Also, mudlord, PM me if I haven't given you
my WIP URL and you wanted to look at the latest stuff. I can never
remember who I gave the link to or not.
- system.video / audio / input are not checked, so you get the
compiled defaults only. All vai drivers have now been ported, however.
I changed the cheat code format. It is now:
code = status, "description" \r\n
Or for an example:
7e1234:56 = enabled, "Infinite Lives"
7e1235:67 = disabled, "Infinite Health"
A little easier to read. But maybe still not perfect. I'd really like
to unify the .cht file format with other SNES emu devs ... I don't
want to use a binary file format like ZSNES and SNES9x does.
I tried testing log audio data -- it seems to be working for me both
on Windows and Linux. FitzRoy, maybe the file isn't going to the
folder you are expecting? Or maybe I fixed it and didn't realize it?
Hmm ...
Anything else I'm forgetting before a new release? Anyone
see any new / show stopping bugs?
[No archive available]
|
|
|
byuu
|
d115c7f6aa |
Update to bsnes v026r03? release.
Another WIP. This one builds on Windows and Linux, and the binary has
the terminal window disabled.
Bugs fixed:
- Added WM_ENTERMENULOOP message. Fixes audio looping for
the 37th time since I started on bsnes.
- Esc toggles menu properly
- F11 fullscreen centers, but only to the screen, not to the window
(meaning when the menubar is visible, it isn't really centered) --
this is because GTK+ does not return the correct widget size after
calling gtk_window_fullscreen() for up to ~200ms after processing all
messages via gtk_main_iteration_do(), and thus I can't make a
window.get_size() function. I really hope
GetSystemMetrics(SM_CXSCREEN) and gdk_screen_width() only return the
width of the active monitor, and not both for multi-monitor setups
- Background of main window is black on Linux only. Only one
background brush per class for Windows. It may end up staying gray on
Windows for the next release ...
- miu/Win enable/disable works. Even for menu items now, so I can
disable features that aren't supported by certain drivers now.
Bugs remaining:
- bsnes/Win background in fullscreen mode is gray --
quite ugly
- D3D still blurring images even with perfect multiplier
- cheat code editor still doesn't load .cht files on ROM
load
New bugs:
- bsnes/Win menubar is ultrafucked in fullscreen mode if
you toggle it on and off with esc. I have _no_ idea what the hell is
up with that. Code to show and hide the menu is identical to
libui/bsnes v026. Not sure I can fix this one. Basically, when the
menu gets toggled back on, clicking it does nothing, and if you press
alt, it will pop up the menu, but it will be _below_ the visible
menubar, so you end up seeing two of them. And you can only access the
new menubar via keyboard. Weird stuff ... could use some help here.
Anyone ever seen or heard of anything like this before?
- I still need to work on that makefile cp+chmod ->
install thing for belegdol, I think ...
[No archive available]
|
|
|
byuu
|
2efce0fd83 |
Update to bsnes v026r02? release.
New WIP. Much, much closer to release quality. Linux port (probably)
won't compile at the moment due to minor changes to miu and vai. I
left the console enabled for this WIP.
Bugs fixed:
- Windows always appear at 0,0 instead of centered
- Input capture window doesn't actually read anything. I actually can
get this working now, I just don't like the hacky way I did it before.
- miu doesn't send Key events, so no F11 / esc shortcut
keys.
- miu/Win is still missing some event messages, so some controls may
appear unresponsive. miu/Linux should be complete.
- miu/Win may still send duplicate messages in some
cases, like that old log audio option bug was doing
- miu lacks an on_show event, so the config window can't
set focus to the listbox on show just yet
- bsnes will no longer crash when you try and load a GZ / ZIP / JMA
file with the support not built in (it obviously won't play the games
either) [Richard Bannister]
Bugs remaining:
- D3D still blurring image, haven't looked at it yet
- Cheat code list never populates when loading ROM, probably doesn't
save either (I probably removed that code when rewriting cart/ and
memory/ a while back)
- miu doesn't emit WM_ENTERMENULOOP, meaning audio cycles when going
into the menu. I wish there were a way to make it pre-emptive like
GTK+ without needing multiple threads ...
New bugs:
- Esc doesn't toggle menu yet
- F11 fullscreen doesn't center, and window background is gray. This
will be tricky, as I only have one RegisterClass() in miu, but you can
only have one HBRUSH per class. Hopefully there's a window message I
can hijack to add back window.set_background_color().
- miu/Win enable() / disable() doesn't work -- input
config dropdowns active, despite them not working yet
Other than that, any new bug reports would be appreciated. I hope to
have v027 out by Sunday, but I may not make it in time.
[No archive available]
|
|
|
byuu
|
f6732133e7 |
Update to bsnes v026r01? release.
Alright, it's been a full month now since the last private WIP.
I have Direct3D, DirectSound and DirectInput all working on the
Windows port now; and Xv, GTK+ Video, libao and XInput working on the
Linux port, so now's a good time for a beta.
Note that countless things are broken, still.
- D3D still blurring image, haven't looked at it yet
- Cheat code list never populates when loading ROM, probably doesn't
save either (I probably removed that code when rewriting cart/ and
memory/ a while back)
- Windows always appear at 0,0 instead of centered
- miu doesn't emit WM_ENTERMENULOOP, meaning audio cycles when going
into the menu. I wish there were a way to make it pre-emptive like
GTK+ without needing multiple threads ...
- Input capture window doesn't actually read anything. I actually can
get this working now, I just don't like the hacky way I did it before.
- miu doesn't send Key events, so no F11 / esc shortcut
keys.
- miu/Win is still missing some event messages, so some controls may
appear unresponsive. miu/Linux should be complete.
- miu/Win may still send duplicate messages in some
cases, like that old log audio option bug was doing
- miu lacks an on_show event, so the config window can't
set focus to the listbox on show just yet
Any bugs outside of this that seem serious, please tell
me about. Otherwise, I'm working on the rest still :/
[No archive available]
|
|
|
byuu
|
95547f4ff8 |
Update to bsnes v026 release.
- Major source code cleanup
- Completely rewrote memory mapper to support runtime MMCs
- Updated S-DD1 MMC to use new memory mapping interface
- Improved S-DD1 emulation, thanks to information from orwannon
- Added support for SameGame -- load via "Load Special -> Load BS-X Slotted Cart" menu option
- Completely rewrote cartridge loader to support BS-X, BS-X slotted carts and ST carts
- Created custom dialog windows for multicart loading
- Improved generic memory mapper, which eliminates the need for cart.db [Nach]
- Added BS-X slotted cart detection to generic memory mapper [Nach]
- Linux port will now ignore keypresses when window is inactive
- Linux port will use much less CPU power when idle
- Added detailed compilation instructions to Makefile for Linux port
- Added "make install" target and PNG program icon for Linux port
- Switched Windows compiler to MinGW/GCC4
- Windows executable is now packed with UPX to decrease filesize
- Removed .ufo, .gd7 and .078 ROM extensions; added .bs extension
- Added preliminary support for the BS-X base unit, BS-X base cartridge + MMC, and BS-X flash I/O
|
|
|
byuu
|
4f5bdfe347 |
Update to bsnes v025r12? release.
New WIP is up.
I fixed PSRAM size, it's now 512kbytes. SRAM was correct before at
32kbytes. I also now save these files to "bsxbios.psr" (PSRAM) and
"bsxbios.srm" (SRAM). I honestly don't know if the PSRAM is supposed
to be battery backed or not. If it's not, it'll be easy enough to
remove. I imagine it is, because that's where you'd store your games
on if you lacked a flash cart. Would be pretty lousy to have it wiped
every time you power cycle.
I also save the PSRAM+SRAM data only once, just as a real BS-X cart
would work, and it also makes the Ancient Tablets series work with no
file renaming needed. I may add an option later to save these files
separately per-game.
BS-X support overall is still pitiful. bs-x.txt doc says $03 has to
be set to mirror PSRAM, SNES9x thinks it needs to be clear. Neither
know whether it affects just $60-6f or also $70-77. bs-x.txt doesn't
say to mirror hi/lo on PSRAM based on $02 setting, but SNES9x seems to
try it. LoROM doesn't map well into 64k granularity banks. Still don't
emulate $0c/$0d flash i/o register enable. Base unit is still
completely unsupported, and it's apparently needed for some games. And
I have no intentions of including an internal database of times to
manually hack the clock (even while the system is running!) ala
SNESGT. I'm just going to map the BS-X base unit RTC to the PC clock.
Some stuff like Dragon Slayer Eiyuu Densetsu work fine under regular
mapping, yet don't work with BS-X mapping. No idea why. Still don't
hack-enable headers during load, so that has to be done manually still
(do this if the game doesn't show up in cart menu. Make a backup if
you care.)
Added SameGame support. Load it with "Load BS-X Slotted Cartridge"
(that's what it is, after all.) Unfortunately, I don't know what the
memory map is supposed to be, so the add-on cart doesn't appear to be
working. Or maybe I just can't figure out how to tell.
Nach or anyone else, would you mind sharing that info with me? The
code in SNES9x looks identical to what I have, but loading the FEoEZ
512kbyte cart doesn't seem to do anything. Well, at least the game
itself works under this menu option now.
Fixed config::path.save, and added realpath() for the Linux port, so
./ paths work too. Of course it won't be useful at all if you
"install" bsnes to /usr/bin, but if you keep it in its own folder,
it's helpful.
Fixed the SRAM mapping bug affecting Fire Emblem 776. Also optimized
the file loading stuff a little more, removing a couple redundant ROM
memcpy's. Still far from perfect.
If possible, please test this WIP a lot. I'd like to post
a new public release this weekend.
[No archive available]
|
|
|
byuu
|
49b0bed1a6 |
Update to bsnes v025r11? release.
New WIP up. Has a Windows binary this time. I completed the BSX cart MMIO registers. It definitely doesn't work too well. For one, I don't override the header bit in the emulator, so anyone testing will have to modify the bit as discussed first. It also doesn't work on my only other BS game, BS Dragon Quest. I don't know why, it throws a St. GIGA error (09). Maybe it needs base unit emulation ... who knows. There's probably bugs in the cart and flash reg support, too. > My notes on the subject tell me it's the year of download or'd with > other data. I haven't entirely figured out everything it's or'd with > though. Well, Lancer said the BIOS makes sure d15 of $ffd5,$ffd4 is not set. If it is, the game does not appear in the list of games you can start. I'm guessing certain (all?) games expired after a certain date. If that's true, then we're quite fortunate that only a header bit was set, rather than the entire cart erased. So then, most likely all of these games with $80 in $ffd5 appeared "blank", but were dumped and the games retrieved. Sigh, such a sad fate. Really makes you wonder why Nintendo hates their fanbase so much to go out of their way to destroy these games. [No archive available] |
|
|
byuu
|
1554170312 |
Update to bsnes v025r10? release.
Yeah, even if we still don't have the S-DD1 100% understood, we can at
least get all known software working properly. And now we at least
have all the registers understood, just the edge cases that need to be
tested. I'm honestly glad I was incorrect in that the original patch
worked on hardware. Given it will never be updated again, this means I
won't have to get bug reports from now unto infinity about it.
I posted a new binary WIP. If anyone wants to play through a few
levels of SFA2 or dungeons in SO and look for corrupted graphics, it'd
be appreciated. I'm sure it'll be fine, though. Oh, and the speedhit I
reported a few days ago was wrong. The old builds ran at the same
speed. Seems I have a ~6-8fps variance in that game per reboot.
New WIP also starts the BS-X mapping. You can map in a cart now, but
it immediately freezes because the flash I/O registers do not respond.
---
Also, I'd like to get serious about emulating the
SPC7110. But to do that, I need custom-made hardware.
I asked someone about this already, but I may as well throw it out
there publicly in case anyone else would like to help.
Here is the PCB for one of the SPC7110 games:
http://nsrt.edgeemu.com/INFO/chip-pix/SPC7110.JPG
What I would need is for the top two ICs to be desoldered, and socket
IC connectors to be placed on them instead. I would also obviously
need lots of compatible EEPROMs to connect to it (just two would
suffice, more would be better as it's quite possible I'd wear out the
write cycles with lots of intense testing, or bend up the pins like I
usually do when removing socket ICs).
I would also need software+hardware to actually flash the
EEPROMs, as I don't have anything like this presently.
More complex solutions, such as a ROM emulator with a parallel/USB
interface to the PC would be acceptable as well. So long as it's
something I can reprogram at my relatively low skill level.
One cart would suffice, but again, the more carts the better in case
of failure. And I'd also like to see about sending one to another
person who's been interested in the SPC7110 for a while. So, three or
four preferred.
I can supply the cartridges and money for time +
shipping. I'd prefer someone who _knows_ they can do this well try, so
that we don't ruin any unnecessary cartridges and so that the test
cartridges are as durable as possible. Especially since they most
likely won't be encased anymore.
So, any takers?
[No archive available]
|
|
|
byuu
|
ec137d6fb9 |
Update to bsnes v025r09? release.
I posted a new WIP last night. No binary this time,
sorry.
It redoes the memory mapping of the cartridge and moves it into the
cartridge class -- forking each slotted cart away from the base cart
memory.
This allows me to determine the proper sizes for each individual cart
again, so I can now map RPG Tsukuru II again correctly.
EDIT:
Ahahahahahah!! Finally! I figured out how the S-DD1
$4800 and $4801 registers work! :D
Original game transfer (should transfer
compressed->decompressed):
CC2418 LDA #$4000 A:00DA X:F458 Y:1C00 S:01FA DB:00 D:0000 P:01 e
CC241B PEA $00DB [0000DB] A:4000 X:F458 Y:1C00
S:01FA DB:00 D:0000 P:01 e
CC241E LDX #$E8ED A:4000 X:F458 Y:1C00 S:01F8
DB:00 D:0000 P:01 e
CC2421 LDY #$0800 A:4000 X:E8ED Y:1C00 S:01F8
DB:00 D:0000 P:81 e
CC2424 JSR $2470 [CC2470] A:4000 X:E8ED Y:0800
S:01F8 DB:00 D:0000 P:01 e
CC2470 STA $2116 [002116] A:4000 X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:01 e
CC2473 SEP #$20 A:4000 X:E8ED Y:0800 S:01F6
DB:00 D:0000 P:01 e
;* enable $4800 *
CC2475 LDA #$01 A:4000 X:E8ED Y:0800 S:01F6
DB:00 D:0000 P:21 e
CC2477 STA $4800 [004800] A:4001 X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:21 e
CC247A LDA #$09 A:4001 X:E8ED Y:0800 S:01F6
DB:00 D:0000 P:21 e
CC247C STA $4300 [004300] A:4009 X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:21 e
CC247F LDA #$18 A:4009 X:E8ED Y:0800 S:01F6
DB:00 D:0000 P:21 e
CC2481 STA $4301 [004301] A:4018 X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:21 e
CC2484 STX $4302 [004302] A:4018 X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:21 e
CC2487 LDA $03,S [0001F9] A:4018 X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:21 e
CC2489 STA $4304 [004304] A:40DB X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:A1 e
CC248C STY $4305 [004305] A:40DB X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:A1 e
CC248F LDA #$01 A:40DB X:E8ED Y:0800 S:01F6
DB:00 D:0000 P:A1 e
CC2491 STA $4801 [004801] A:4001 X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:21 e
CC2494 PHA A:4001 X:E8ED Y:0800 S:01F6 DB:00
D:0000 P:21 e
CC2495 PLA A:4001 X:E8ED Y:0800 S:01F5 DB:00
D:0000 P:21 e
CC2496 STA $420B [00420B] A:4001 X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:21 e
CC2499 STZ $4800 [004800] A:4001 X:E8ED Y:0800
S:01F6 DB:00 D:0000 P:21 e
CC249C REP #$20 A:4001 X:E8ED Y:0800 S:01F6
DB:00 D:0000 P:21 e
CC249E RTS A:4001 X:E8ED Y:0800 S:01F6 DB:00
D:0000 P:01 e
Custom transfer (should transfer
decompressed->decompressed):
CC2428 LDA #$5008 A:00DB X:E8ED Y:0800 S:01FA DB:00 D:0000 P:01 e
CC242B PEA $00E9 [0000E9] A:5008 X:E8ED Y:0800
S:01FA DB:00 D:0000 P:01 e
CC242E LDX #$0400 A:5008 X:E8ED Y:0800 S:01F8
DB:00 D:0000 P:01 e
CC2431 LDY #$04E0 A:5008 X:0400 Y:0800 S:01F8
DB:00 D:0000 P:01 e
CC2434 JSR $244C [CC244C] A:5008 X:0400 Y:04E0
S:01F8 DB:00 D:0000 P:01 e
CC244C STA $2116 [002116] A:5008 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:01 e
CC244F SEP #$20 A:5008 X:0400 Y:04E0 S:01F6
DB:00 D:0000 P:01 e
;* disable $4800 *
CC2451 STZ $4800 [004800] A:5008 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:21 e
;* $43x0.d3 (fixed transfer flag) is irrelevent
to S-DD1 *
;* can be #$01 or #$09 here *
CC2454 LDA #$09 A:5008 X:0400 Y:04E0 S:01F6
DB:00 D:0000 P:21 e
CC2456 BRA $247C [CC247C] A:5009 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:21 e
CC247C STA $4300 [004300] A:5009 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:21 e
CC247F LDA #$18 A:5009 X:0400 Y:04E0 S:01F6
DB:00 D:0000 P:21 e
CC2481 STA $4301 [004301] A:5018 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:21 e
CC2484 STX $4302 [004302] A:5018 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:21 e
CC2487 LDA $03,S [0001F9] A:5018 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:21 e
CC2489 STA $4304 [004304] A:50E9 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:A1 e
CC248C STY $4305 [004305] A:50E9 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:A1 e
CC248F LDA #$01 A:50E9 X:0400 Y:04E0 S:01F6
DB:00 D:0000 P:A1 e
CC2491 STA $4801 [004801] A:5001 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:21 e
CC2494 PHA A:5001 X:0400 Y:04E0 S:01F6 DB:00
D:0000 P:21 e
CC2495 PLA A:5001 X:0400 Y:04E0 S:01F5 DB:00
D:0000 P:21 e
CC2496 STA $420B [00420B] A:5001 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:21 e
CC2499 STZ $4800 [004800] A:5001 X:0400 Y:04E0
S:01F6 DB:00 D:0000 P:21 e
CC249C REP #$20 A:5001 X:0400 Y:04E0 S:01F6
DB:00 D:0000 P:21 e
CC249E RTS A:5001 X:0400 Y:04E0 S:01F6 DB:00
D:0000 P:01 e
Original transfer right after custom transfer:
CC2438 LDA #$4000 A:00E9 X:0400 Y:04E0 S:01FA DB:00 D:0000 P:01 e
CC243B PEA $00DC [0000DC] A:4000 X:0400 Y:04E0
S:01FA DB:00 D:0000 P:01 e
CC243E LDX #$E0E8 A:4000 X:0400 Y:04E0 S:01F8
DB:00 D:0000 P:01 e
CC2441 LDY #$1080 A:4000 X:E0E8 Y:04E0 S:01F8
DB:00 D:0000 P:81 e
CC2444 JSR $2458 [CC2458] A:4000 X:E0E8 Y:1080
S:01F8 DB:00 D:0000 P:01 e
CC2458 STA $2181 [002181] A:4000 X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:01 e
CC245B SEP #$20 A:4000 X:E0E8 Y:1080 S:01F6
DB:00 D:0000 P:01 e
CC245D LDA #$7F A:4000 X:E0E8 Y:1080 S:01F6
DB:00 D:0000 P:21 e
CC245F STA $2183 [002183] A:407F X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:21 e
CC2462 LDA #$01 A:407F X:E0E8 Y:1080 S:01F6
DB:00 D:0000 P:21 e
;* $4800 enabled again *
CC2464 STA $4800 [004800] A:4001 X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:21 e
CC2467 LDA #$08 A:4001 X:E0E8 Y:1080 S:01F6
DB:00 D:0000 P:21 e
CC2469 STA $4300 [004300] A:4008 X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:21 e
CC246C LDA #$80 A:4008 X:E0E8 Y:1080 S:01F6
DB:00 D:0000 P:21 e
CC246E BRA $2481 [CC2481] A:4080 X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:A1 e
CC2481 STA $4301 [004301] A:4080 X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:A1 e
CC2484 STX $4302 [004302] A:4080 X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:A1 e
CC2487 LDA $03,S [0001F9] A:4080 X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:A1 e
CC2489 STA $4304 [004304] A:40DC X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:A1 e
CC248C STY $4305 [004305] A:40DC X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:A1 e
CC248F LDA #$01 A:40DC X:E0E8 Y:1080 S:01F6
DB:00 D:0000 P:A1 e
CC2491 STA $4801 [004801] A:4001 X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:21 e
CC2494 PHA A:4001 X:E0E8 Y:1080 S:01F6 DB:00
D:0000 P:21 e
CC2495 PLA A:4001 X:E0E8 Y:1080 S:01F5 DB:00
D:0000 P:21 e
CC2496 STA $420B [00420B] A:4001 X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:21 e
CC2499 STZ $4800 [004800] A:4001 X:E0E8 Y:1080
S:01F6 DB:00 D:0000 P:21 e
CC249C REP #$20 A:4001 X:E0E8 Y:1080 S:01F6
DB:00 D:0000 P:21 e
CC249E RTS A:4001 X:E0E8 Y:1080 S:01F6 DB:00
D:0000 P:01 e
I was completely wrong, and was thrown off by ZSNES' memory remapping
magic that worked due to an oversight with $43x0.d3, or the fixed
transfer flag. I never added a check for the fixed transfer flag
because it quite honestly made no sense. Why would the S-DD1 care
about that?
Turns out, it doesn't. What really matters is $4800.
The register everyone currently ignores completely.
I figured out what purpose it serves: it's a sticky
toggle, whereas $4801 is a loose toggle.
It works like this: in order for the S-DD1 to decompress a DMA
transfer, both $4800 and $4801 have to be set. Upon completion of the
transfer, $4801 is cleared. But $4800 is not.
If you look at the above logs, it becomes clear. And it's all
contained inside the S-DD1 code. It has nothing to do with $43x0.
Now, how can I verify this? orwannon made a flash cart for Star Ocean
and ran my old title screen patch on it. Sure enough, it did not try
and decompress the graphics data, despite the fixed transfer flag
being set. That tells us that the fixed transfer flag has nothing to
do with this.
What's interesting is that every single S-DD1 supporting emulator
works just fine with my title screen patch. Meaning that they've all
implemented these two registers wrong.
What was also interesting is that it's supposedly been confirmed that
the patched SO works on real hardware. That means the bug was in bsnes
after all. No excuses, I was flat out wrong. My sincere apologies.
I've added the above changes, and bsnes now works with the original
patch, and fails with my custom patch. This mimics the behavior of
real hardware.
Huge thanks to orwannon for the screenshot of my patch running on
real hardware. This fix wouldn't have been possible without that.
[No archive available]
|
|
|
byuu
|
aee683a475 |
Update to bsnes v025r08? release.
New WIP up.
I spent four hours completely rewriting everything but the generic
header parsing code in src/cart. I'm now happy with the code both in
src/memory and src/cart. Hoorah.
With the new load_cart() functionality, I made the "Load Special"
menu entries functional. For those of you stuck on Windows or without
WIP access, you can see how nice the load menus look on Linux below :)
http://byuu.cinnamonpirate.com/bsnes/images/ui_bsx.png
http://byuu.cinnamonpirate.com/bsnes/images/ui_st.png
There is one bug: because of the way I map the slotted carts into one
contigious chunk of ROM (and hence update the size accordingly), it
throws off the memory mirroring on some of the BS-X slotted cart games
(like RPG Tsukuru II). I need to work on that a bit. For now, you can
play it through the normal load cartridge menu option.
And of course, there's still that annoying Windows issue where the
main window steals focus after loading a ROM. Haven't looked into that
yet.
And I still need to rework the file extension stuff per previous
discussions. It'd be nice to have the BS-X / ST windows only show .bs
/ .st ROMs by default.
[No archive available]
|
