 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| Acmlm's Board - I3 Archive - - Posts by byuu |
| User | Post | ||
|
byuu Newcomer               Since: 01-11-06 Last post: 6561 days Last view: 6561 days |
| ||
| I use a cheap trick with the DirectDraw renderer to speed things up. Basically, I get a 10-20% performance increase in 32-bit mode by always creating a 16-bit surface. When using video memory, your video card automatically converts the surface to 32-bit mode for display, with zero overhead. However, when you are in 32-bit mode and you transfer from system memory, this conversion does not happen and you end up with a "smashed" image like in your screenshot.
It's unfortunate, but the next version of bsnes also supports an optional Direct3D renderer, and with it supports the ability to use point filtering (read: big blocks, no interpolation), among other neat things. Also, transferring from system RAM is painfully slow when you resize the window above 256x223. It gets slower and slower as you up the window size. As for accuracy, the one major thing bsnes doesn't do is run the PPU in synchronization to the CPU. It "catches up" once every scanline. It's unfortunate, but with a power requirement of 2ghz already... this added push would put it out of the hands of nearly every personal computer on the planet. I also can't really break down the CPU / APU instructions anymore than cycles, breaking it down to raw clocks would be near impossible. However, I do *somewhat* split the read / write cycles in half to account for bus hold times, but that doesn't work across processors. So, basically bsnes is most likely the most accurate SNES emulator, but there's still a long way to go. You also have to figure that bsnes is relatively new, and has many major bugs that other emulators do not. It also doesn't support many special chips, so games like Star Fox, Mario Kart, Mario RPG, Yoshi's Island, etc. won't run at all. |
|||
|
byuu Newcomer Since: 01-11-06 Last post: 6561 days Last view: 6561 days |
| ||
I would, and have. And I've had a ton of help from volunteers fixing bugs for me, porting my software to other platforms, etc 
I've considered making table generators such as this for the debugger, e.g. marking which memory bytes are actually accessed, which ones are executed as code, etc. For your idea to work with the SNES, you'd need to take it a step further. The SNES can execute the same exact code differently depending on the status register bits, so you'd pretty much be forced to log each opcode to a disassembly as it is executed in-game. Just knowing what data is code and what data is not is not enough to disassemble 65c816 code. It's doable, but I don't really have any plans to do that specifically myself. Example: binary code = a9 00 ea This is: lda #$00 : nop, if the status register has the m flag set, and lda #$ea00 if the m flag is clear. The 6502 (NES), 680x0 (Genesis), SPC700 (SNES), etc. do not have this problem. |
|||
|
byuu Newcomer  Since: 01-11-06 Last post: 6561 days Last view: 6561 days |
| ||
| Your assertions are correct, but I'll go ahead and post anyway because I'm bored.
[code]tcall_0(0x01, 0), tcall_1(0x11, 1), tcall_2(0x21, 2), tcall_3(0x31, 3), tcall_4(0x41, 4), tcall_5(0x51, 5), tcall_6(0x61, 6), tcall_7(0x71, 7), tcall_8(0x81, 8), tcall_9(0x91, 9), tcall_10(0xa1, 10), tcall_11(0xb1, 11), tcall_12(0xc1, 12), tcall_13(0xd1, 13), tcall_14(0xe1, 14), tcall_15(0xf1, 15) { 1:dp = 0xffde - ($1 << 1); rd = op_read(OPMODE_ADDR, dp); 2:rd |= op_read(OPMODE_ADDR, dp + 1) << 8; 3: 4: 5: 6:stack_write(regs.pc >> 8); 7:stack_write(regs.pc); regs.pc = rd; }[/code] Fairly simple. There is 64kb of SPCRAM. A full 64kb, 0000-ffff. There is also a 64-byte IPLROM. When enabled (via $f1 bit 7 being set), all reads from $ffc0-$ffff return the IPLROM data instead. Writes to this area go to the SPCRAM even with IPLROM enabled. $00F1 - CONTROL bit 7 - IPLROM enable (1=yes, 0=no) bit 6 - no known effect bit 5 - clear ports 2 and 3 (the APU will now read $00 from $f6 and $f7, the CPU will still have the old data on $2142 and $2143) bit 4 - same as bit 5, but for ports 0 and 1 bit 3 - no known effect bit 2-0 - timer 2, 1, 0 enable (1=yes, 0=no) -- writing 1 when the timer is disabled will reset the timer position You want real fun, try figuring out what $00F0 - TEST does. And no, snes9x didn't just decide to make up $f1 bit 7. A real SNES has IPLROM disable as well. Otherwise TCALL would be almost completely useless. TCALL reads will read from the IPLROM with $f1.d7=1, by the way. |
|||
|
byuu Newcomer Since: 01-11-06 Last post: 6561 days Last view: 6561 days |
| ||
Originally posted by MathOnNapkins And if there is something you can't do that isn't completely insane (eg convert an OGG VORBIS file into an SPC program with one line in the assembly file), I'll be happy to add it
Tricks assembler is good. I didn't like that it was a PASCAL app, and kind of slow in comparison. It also lacks a lot of the functionality in xkas (infinitely nested macros and defines, ROM hacking extensions, etc), but other than that it is a really good choice for a simple, light-weight assembler. WLA-DX is the only one I really dislike. The amount of red-tape involved even for trivial aspects such as memory mapping is truly absurd. But the table-based instruction sets it supports is really cool at least. |
| Acmlm's Board - I3 Archive - - Posts by byuu |
