Snes9x.COM: Developers Journal

 

Bandwidth problems...
We are currently experiencing bandwidth problems; we are working towards a solution. We are sorry about the inconvenience.

Jerremy, 8-6-2001 22:22:00

 

Long Time No Hear...
Life has been a bit busy of late. 300+ unread e-mails. I thought I was unable to upload new stuff onto the web site, but it looks like some sort of maintenance happens at certain times of day and ftp accounts are blocked during this time; I'd been trying to upload a German translation of Snes9x and had been unlucky about the times I chose. Also, a couple of the files that Microsoft's Visual C++ needs to build Snes9x got corrupt and to my horror I hadn't backed them up - I thought they were just automatically generated stuff. I had to spend a few hours (= several days available development time) rebuilding project files.

A new Windows port was ready to go several weeks ago - its just I couldn't release it, or so I thought. While waiting for the ftp account to be  sorted out, I got bored and started adding new functionality, but I forgot to build a releasable package/zip file first and at the moment I can't build a 100% working version.

The thing that's breaking the Windows port at the moment is triple-buffer support in full-screen mode - I thought I'd added triple buffer support a long time ago, but while scanning the code I discovered it was commented out - now I know why. Windows implements double and triple buffering by stacking drawing surfaces one on top of the other like pieces of paper - the trick is to draw on the piece of paper under the one of top, then flip piece of paper (the surface) on top to the bottom of the pile. This stops screen tearing - when the part of the screen that is being displayed gets updated the program, especially noticeable on scrolling games. The surface flipping can only take place during the screen vertical blank period, so if only two surfaces are used (double-buffering) it might slow the program down because it has to wait for the flip to happen before it start drawing the next frame. Enter triple-buffering.

My problem is that while I've got triple buffering working, I can't seem to clear the buffers initially or get the Windows menu bar to appear on all buffer surfaces - causing flickering junk and a flickering menu bar. Windows provides an API call to walk down all the "attached" surfaces calling a user supplied function for each one - but this API call always stops after the first hidden surface has been processed. :(

I did try just clearing the top surface, drawing the menu bar, then flipping the next surface to the top and repeating, but that didn't seem to work. Oh no! I've just realised why that might not have worked - I for forgot to wait for the flip to actually happen! Oh well, I was going to try creating my own surfaces next, and attaching them to each other myself; maybe I don't have to do that now...

If triple-buffering surface clearing problem can be fixed, that only leaves one more problem - Windows lets you create a triple-buffered surface whether it will fit in video memory or not - if the it doesn't fit, enabling triple-buffering actually slows down the emulation rather than speeding it up as Windows uses systems memory as a overspill area and data has to be copied from system memory to video memory. I'll need to add some code to make sure that all the buffer surfaces will fit in video memory before enabling triple-buffering.

I've also been trying to get Sanma Iwashi's unofficial Windows port up and running for the source code he supplied - I'm toying with the idea of switching to use his GUI in the official Windows port - but the program crashes every time I try to start a game, and Micro$oft's debugger crashes Windows if I try to debug it!

John Weidman thought he might have made a big break through with the S-DD1, but the trail has gone cold. John and I also had the idea of trying to extract the Nintendo specific code from the DSP-1 and then using it to write a 100% perfect emulation of the chip - the DSP-1 is actually just an old, standard, NEC DSP chip with custom code bur

Gary, 29-3-2001 6:35:00

 

Message Board working again
Well, I'm feeling a bit better now... And I've found the three offending messages and deleted them from the message database... You might be wondering what I'm talking about, well it seemed three messages were(for some reason) causing a problem... Now I'm not sure that it won't happen again... If it does, I'll have to figure out why and how, but for now... We can all use the message board again...

Jerremy, 24-1-2001 16:02:00

 

Message Board not working
As some of you might have noticed, the message board isn't working anymore. I have no clue yet why it's not working, but I'm a bit ill and haven't got the spirit to look at it... As soon as I feel better, I'll see if I can remedy the problem...

Jerremy, 22-1-2001 4:20:00

 

A Week In the Life of Snes9x...
People are asking where the Windows port is... well I've decided to give you a blow by blow account of what I've done over the last week, Snes9x wise, at least. First some background information. I'm married with two young kids; the chances of me being able to work on Snes9x at home are almost zero, hence I can only work on Snes9x while travelling to and from work while sat on a train - about 2 hours a day.

Monday morning:
Transferred the new, v1.34 emulator sources from Linux to Windows and compiled them up. Gave Snes9x a quick test, it didn't work! Hmm. Looked through the source for any obvious errors, couldn't see any. Compared the Windows initialisation code with the UNIX init code - couldn't see any variable omissions.

Monday evening:
Did a complete rebuild of the Snes9x's sources, Snes9x still didn't work - just a black screen when you load up a ROM, DKC even causes Snes9x to crash with a divide by zero. Spent the rest of the time getting Snes9x compiled with debugging turned on and replying to e-mails.

Tuesday morning:
Load up DKC, Snes9x crashes again, but because of the debugging info, Visual Studio offers to debug it, so I accept. I'm presented with a nice disassembly listing but with no symbolic information - and its not code I recognise so it must be Windows library code. Without symbolic information the disassembly listing is useless. Enable Snes9x's CPU trace option. Spent the rest of the time replying to some of the backlog of e-mails.

Tuesday evening:
Bump into a friend that I haven't seen in a long time - brain the size of a planet. Ask him about compression algorithms and he spends the train journey telling me about loss-less compression algorithms (hopefully one similar to these is used in the S-DD1 chip).

Wednesday morning:
Trace Bomberman's emulated CPU execution into a file - the file is empty! Help! Enable sound CPU tracing, that seems to be working fine, I can see the SPC700 initialise its registers and memory, then wait for the main SNES CPU to give it something to do. Add more debugging to the code. The CPU cycles count is increasing as expected; the only thing that increments that is the CPU emulation code, so that must be doing something.

Wednesday evening:
Decide to re-check everything. Boot back into Linux and make sure I've transferred all the source code - I haven't. What an idiot! I didn't transfer the new asm CPU code and the new unix.cpp file. Transferred them. Rebooted back into Windows and recompiled; Snes9x still didn't work. Double-checked I'd initialised all the required variables - I hadn't! I'd forgotten about the new CyclesPercentage variable. Initialised it to 100 and the Windows port burst into life!

Thursday morning:
Started scanning through e-mails and saved snes9x.com forum messages and built up a list of nice-to-haves for the new release; noticed that several people mentioned that Super Robot Wars Ex wasn't working - a quick scan revealed that I didn't have the ROM. Made a note to download ROM for testing when I got a chance.

Thursday evening:
Reread the 'to-do' list and picked a few easy ones. Plugged in the new ZSNES freeze-file support. Added a toggle turbo mode on/off option to the GUI and the registry code (to persist the option). Spent the rest of the journey reading Windows' API docs to find out how you dynamically alter menus so I can implement a 'Recent Game/Favourites list in the file menu.

Friday morning:
Rebooted into Linux and tested Robot Wars Ex. Play tested it (by randomly pressing keys - its a Japanese game!) and sure enough, the game locks up when you get to the 'battle' screen. Traced the ROM. Its waiting for a bit in a register to be set - except that I've no idea what that bit is meant to indicate, I've never seen any other ROM test it. Disassembled the ROM. Its in an IRQ routine and seems to be waiting for the end of the scan-line before it updates some PPU register va

Gary, 14-1-2001 5:29:00

Go back in time

Snes9X.COM
Back

Filter on
Funkyass
4-7-2006 21:51:00
Gary
15-10-2001 13:20:00
Jerremy
8-6-2001 22:22:00
Mkendora
4-12-2003 18:59:00
TeleKawaru
20-4-1999 6:13:00
All

Supported by   NZBCheck - The online usenet NZB checker
DisclaimerView our Privacy Policy
The Snes9X team is not connected or affiliated with any mentioned company in any way. The opinions of the Snes9X team do not reflect the views of the various companies mentioned here. Companies and all products pertaining to that company are trademarks of that company. Please contact that company for trademark and copyright information.

Copyright 1998,1999 Webmaster