Archive for the ‘Uncategorized’ Category

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.

Eggcellent! (sorry)

Guess what?

Chuckie Egg

I got Chuckie Egg working!

There was still a problem in the interrupt handler. As I mentioned before the weekend, I had changed the behavour of IM 2 to make sure the program counter was pointing to (I * 256) + 0xFF. I discovered it should actually point to the contents of that location. Once that had changed it started working!

This has also given Chaos a new spurt of life. But it still seems to go a bit wrong when casting your first spell.

I also tracked down the bug that broke the teleports in Earth Shaker. The cause was a bug in the CPI, CPD, CPIR and CPDR instructions.

All in all, compatibility is getting better. I may move my focus to the two main items I want to complete before I release a beta… Snapshot loading and sound.

Bugs be gone!

I fixed quite a few problems in the code last night.

First up was the DAA instruction.  I scrapped what I had there already and re-wrote it.  It now seems to be working as it should.  The scores in various games are now being shown correctly, which is nice.

Second was the flash routine.  I had noticed that when flashing, the ink colour was always displayed as black.  A couple of altered lines in the screen drawing routine and it was fixed.  The result of this is that Jetpac and Atic Atac now work perfectly! (apart from sound).

After forcing myself away from Atic Atac (I had forgot how much I enjoy that game!) I decided to have a look at theproblem with Interrupt Mode 2 that was causing Chuckie Egg to crash.  What I found was quite surprising…

In my notes, I have this info about IM2

In IM 2, the Z80 reads a byte b from the data bus. The memory at location 256 * I + b is then treated as a 16 bit word (LSB of course) and PC is set to this value. On an unexpanded Spectrum, the byte read from the data bus in IM 2 will always be 0xff.

Pretty straight forward.  Take the value in I, multiply it by 256 and add 0xFF.  Basically, if the ‘I’ register contains 0xB0 then the new PC should be set to 0xB0FF.

This is the code I had written (r7 is the current Program Counter, r3 = 0xFFFF and is used to mask 16-bit values).  Please excuse the bad formatting…

ldrb r1, [r4, #OFFSET_I]   @ r1 = I
mov r1, r1, lsl#5    @ r1 *= 256
and r7, r7, r3
add r7, r1, #0xFF    @ PC = r1 + 0xFF
and r7, r7, r3

I must have been drunk or something when I did this.  First of all, to multiply a number by 256 you have to bit shift it left by 8, not 5.  And what are those ‘and’ instructions all about?  I must have put them in to make sure the PC didn’t overflow, but it never will even if I = 0xFF.

Anyway, I have now changed it to the following…

ldrb r1, [r4, #OFFSET_I]   @ r1 = I
mov r1, r1, lsl#8    @ r1 *= 256
add r7, r1, #0xFF    @ PC = r1 + 0xFF

Much better!  I ran Chuckie Egg after making the changes and now it just hangs on the startup screen instead of crashing, which is progress!

I’m going to leave this problem over the next few days and see if I can track down the few Z80 instructions that are still causing problems.  The teleports in Earth Shaker look like a good place to start…