Bugs fixed

Thanks to the two games submitted by Charlie as not working (wheres the rest of you, eh? ūüėČ ), i’ve made a lot progress in fixing bugs in the CPU core… ¬†Critical Mass was particulary useful. ¬†Thanks for your help. Charlie! ūüôā

As a result, the following games now seem to work perfectly… ¬†Arkanoid, Bubble Bobble, Critical Mass, MegaBucks (yay!) and Zynaps. The AI in Chaos is fixed, but there is still the odd graphical glitch. Starquake still seems to crash, which is a shame.

The bug fixes have also sorted out the flashing graphics in a few games, such as Spike in Transylvania. Now i’ve just got to track down that Starquake bug…

Software Compatibility

Over the last couple of weeks I have made a few changes to SpeccyDS. First up was the file browser. As suggested, files can now highlighted with the stylus or the up and down d-pad controls. Once highlighted, a file can be loaded by either selecting them again or by pressing ‘A’. The system seems to work quite well.

I have also added support for .Z80 files. I really should have done this for the last release. The implementation was much easier than I expected and, as many people pointed out, the selection of .Z80 files is far better than .SNA.

The .Z80 support brings me onto the subject of this post… .Z80 support has given me the opportunity to test more games than I did with .SNA (since converting files to .SNA was a boring process). I’m happily surprised at the number of games that work without any problems.¬†However, the crashes in Megabucks and Starquake still bother me since I‚Äôm having trouble tracking them down.

Therefore, I have created a new Compatibility page on the blog. The theory behind this is that bugs should be easier to track down if I have a larger list of non-working games to test. It’s looking a bit empty at the moment, so if you know of a game that doesn’t work with SpeccyDS I would appreciate it if you could add it to the comments with a description of what goes wrong. I will regularly check the comments and update the list as they come in.

Thanks for your help ūüôā

Sound Problems

Some of you who have used SpeccyDS 0.1a may have noticed a problem with the sound.

Occasionally, a small scratch or pop will be played.  You can hear it when the Spectrum is playing a fixed tone, such as the BEEP command, or during the lose-a-life music in Chuckie Egg.

I knew what was causing the problem, the ARM9 processor (which runs the emulation) was feeding too much data to the ARM7 processor (which plays the sound), but couldn’t originally get the two processors to synchronise correctly.

I had another look at it last night.  I scrapped the original timing code on the ARM9 and replicated it with the timings on the ARM7 to make sure they are running at exactly the same frequency.

This seems to have fixed it.¬† The BEEP command sounds much better and plays a nice constant tone.¬† I quickly played a few levels of Chuckie Egg and didn’t notice any more problems.¬† It also means SpeccyDS runs at a more accurate speed than before (it was running slightly too quickly in v0.1a).

Hardware Compatibility

Thanks¬†for¬†all¬†the¬†feedback¬†on¬†compatibility¬†with various homebrew methods over the last few days and apologies if your choosen method isn’t working at the moment.

Since the only hardware I own is a SuperCard CF it was always going to be difficult to get all devices working straight away.  With help from The Caffeen Kid, I was able to test v0.1a on a SuperCard SD before releasing it.

The main problem with other hardware is due to the FAT file system driver. ¬†I am using an unmodified version of Chism’s nds_fat_lib which has issues with some types of card, including the M3.

There is an unofficial version of the nds_fat_lib that has been modified to increase
compatibility, which has been included in the Rein project.  I plan to  merge this version into SpeccyDS for the next release.

Chism is also working on a new driver named fatlib which is currently in alpha stage.  The driver is a huge improvement over the old nds_fat_lib but it does have a few key features missing, such as listing the files in a directory, which SpeccyDS requires.

If fatlib is released before the next version of SpeccyDS then I will start to use that instead.

Other than that, thanks for all the kind words! ¬†ūüôā

SpeccyDS v0.1a Released

Just a quick sneeky release to add support for the SuperCard SD (and possibly other SD based devices). Download it here!

SpeccyDS v0.1 Released

Available from the new download tab, or by clicking here!

Quite a few changes have been made since the last update, including an overhaul of the keyboard graphics, a new snapshot loading screen and a currently incomplete control screen.

A few CPU bugs have also been removed, which has fixed problems in a few more games (such as Renegade and Cobra).

Enjoy! ūüôā

Just a quick edit on hardware compatibility.  This version has only been tested on real hardware using a Supercard CF.  I will investigate problems with other hardware other the next day or two.

It beeps!

I have discovered a new definition for the word frustration.  It goes by the name of a sound ring-buffer.

Driving the sound on the DS is pretty straightforward.  Its simply a case of setting up a sound channel and pointing it to a buffer that holds your sound data.  This works perfectly for playing pre-defined samples.  However, when attempting to stream sound data by creating and playing samples continuously the DS starts struggle.  This causes popping and cracking in the sound.

One method to get around this problem is the use of a ‘ring-buffer’.¬† The theory involves creating an empty sample that is played in a continuous loop.¬† The current play position of this empty sample is tracked using a timer.¬† When a new section of sound data needs to be played it is mixed into the empty sample just ahead of the current play posision.

As far as the hardware is concerned, it is just playing one sample over and over again, but it means that it is posible to alter the sample with the new data being streamed in.

The theory doesn’t sound too bad.¬† It is, however, very dependent on timing.¬† If the new sound data is mixed in too slowly, the play position of the buffer will catch up and eventually override the newly mixed data.¬† If the new sound data is mixed in too quickly, the mix position will wrap around the buffer and override the data currently being played.

I have had major problems getting the timing to be perfect.  I must have redesigned and wrote the sound code 6 or 7 times over the last few weeks without any real success.

Anyway, on Monday I had a bit of free time so a sat down and rewrote it again from scratch.¬† Its the closest i’ve been so far, and sounds pretty good.¬† The mix position is still running slightly quicker than the play position, but if it runs too far forward I skip a sample until it catches up.¬† This can cause the odd scratch in the sound, but it only appears noticable when playing a fixed tone (using the BASIC beep command for example).

This whole problem does indicate that either the CPU core is running too fast or the sound is running too slow.¬† At the moment I think its good enough to put into the first release and am going to move back to the file browser.¬† Once i’ve cleaned it up a bit I think we are looking good for a release of Version 0.1.

Getting there…

Its been a bit quiet on here, but SpeccyDS has been rumbling on…

I’ve been focusing on problems in the CPU core over the last few weeks.¬† I must have made somewhere in the region of 5-10 bug fixes that have been preventing games from running.¬† As a result, the following games that didn’t work 2 weeks ago now all work perfectly…¬† Robocop, Chase HQ, Three Weeks in Paradise, Batman, Exolon, Bombjack and Dan Dare.

There are still issues with a few games, including Chaos (the AI doesn’t feel right), Starquake (crashes in game), Sabre Wulf (classic rhino emulation bug), Megabucks (crashes in the menu).¬† I will be trying out more over the next few days.

I have also been giving some thought about emulating the sound.¬† I’ve already solved how to regularly store the sound data from the CPU, but i’ve only briefly looked at how to convert this into a format that the DS will process.¬† It looks like i’ve got some more reading ahead of me ūüôā

More bug fixes

It looks like my new debug log is paying off. It helped me track down two more bugs in the CPU core.

The first was the JSW bug, which turned out to be a simple typo (I really should be more careful). The second was a bug that had been annoying me for ages which was causing Batty to crash whenever you picked up a triple-ball bonus.

Fixing these has also fixed the crashes in Chaos. Finally I can play one of my favorite spectrum games of all time on the move!

Also, just a quick thanks to everyone who have taken an interest in SpeccyDS. To be honest, I’m quite surprised how quickly people found out about this blog considering I made one casual post in a thread on www.yakyak.org. The wonders of word-of-mouth, eh? ūüôā

Anyone in there?

Almost two weeks without a post eh? Whats going on?

Well, SpeccyDS hasn’t been getting the attention it deserves lately simply because I haven’t had much time to work on it. However, I have still made a bit of progress.

File loading is pretty much complete, along with a touch-screen controlled GUI (which currently looks like it was drawn by a 5-year old. Graphics has never been one of my strong points). Only .SNA files are supported at the moment, but it’s only a small step to add .Z80s.

This has let me quickly test a load of new games. Unfortunatly, I must have broke something somewhere in the CPU core since some games which I knew were working before (such as JSW) now have an annoying habit of crashing at startup.

An unexpected bonus of getting file support enabled is that I can now write debug log files out to my supercard. No more manually stepping through code! I can now run some Z80 code until it crashes and then browse through the log file. Much easier.