ivop

Yes, it's possible that VCOUNT==0 is missed. Some tunes periodically take very long to return from their play-routine. This can be remedied by lowering the replay rate slightly to give the player more time, but the downside is that the pitch of the tune is slightly lower. But I'll add your vbi trick. Most of the time there is enough time and with this vbi trick it should be less audible if it goes wrong. Which tune displayed this behaviour and at what point? It seems I haven't noticed it

Sanxion is tricky as it uses sid features that are not emulated. Here's a zip with Delta, Monty on the run and Sanxion. I also fixed a bug in adsr.sh65. Monty triggered it atarisid3-delta-monty-sanxion.zip

Uhm, have you followed the link to my latest blog entry and checked out my new version which plays at 15.5kHz?

I was delighted by the positive responses I got on my previous blog entry and on the forum about my SID emulator on the Atari 8-bit. I also was a bit disappointed that it turned out there already was an emulator eight years ago that I did not know about, that sounded pretty much the same as mine (some tunes were better, some were worse IMHO). But, this challenged me to improve my emulation A few days ago, I "broke" the 15kHz boundary, and after some bug fixes, I am pleased to present you "Atari SID III". Included are .xex binaries for International Karate, Freeze, JT42, Cybernoid and Cybernoid II, as are all the sources. Sorry Heaven/TQA, all shasm65 again No more badly tuned radio! atarisid3.zip

@Rybags, pokey might actually benefit from the C64's slower clock @Tezz, I really liked your ported and modified Chimera song. Well done! as for macgoo and emkay, yeah, I know I can get a C64 for five bucks and yes, I could spend the same amount of time working on a pokey-only tune, but it's like asking a mountain climber why (s)he climbs that mountain. Because it's there. I think it's fun to try to emulate the sid chip on the atari 8-bit in my spare time. So, here's my latest blog entry http://www.atariage.com/forums/blog/293/entry-9202-sid-emulation-revisited-atari-sid-iii/

Note to those who want to use my sid-engine to play other tunes: some player routines toggle the gate bit in one frame, which means the conversion routines do NOT see it go to zero and back to one again. This means you have to patch the player at this point too (not just writing to shadow sid registers and possibly relocate the zero page addresses). Every write to sid control registers need to be redirected to a small subroutine that compares the previous value to the new value before writing to the shadow register. If the gate bit gets toggled, you need to reset the ADSR envelope phase of that voice to zero. Examples of such player routines are most songs by David Whitaker, Adam Gilmore and probably a whole lot more

One and half bit more volume dynamics doesn't seem to improve the sound that much. The ADSR envelopes get a bit more distinct, but you still have that 'badly tuned radio' kind of sound. In my experience, samplerate is way more important than bits/sample. For example 4 bits/sample at 44100Hz sounds way better than 16 bits/sample at 11025Hz, which is the same bitrate btw. I have some ideas to improve the emulation in other ways. Stay tuned

yes, please, continue. I love reading these kind of stories from 'back in the day'.

@andym00, Thanks for the link to sidreloc. Looks indeed like a great piece of programming. Not sure if it'll be that much faster than my current version of siddasm2 but I'll look into it. @Rybags, Originally I wanted to use three separate voices, but I must admit, I have complete forgotten to try it later once the mixing and scaling worked like I wanted it to. I'll probably have to scale each channel down to 0-10 or 11 to not cross the 32 maximum volume of Pokey, but I guess it will work. Not sure if I can keep the screen on though, or I might have to let the "scope" go.

Here's my blog entry about this: http://www.atariage.com/forums/blog/293/entry-9180-sid-emulation-siddasm2-and-shasm65/ I included binaries, source code and tools. I was not aware of Saint's code (where can I find it?) and Aleksi's Sid Vicious, but judging by the youtube video Sid Vicious indeed sounds quite similar.

Long time, no blog. Let's start at the beginning. In 2009 I wrote my first version of a SID Emulator, running directly on the Atari 8-bit hardware. The emulation loop ran in the main loop and synchronisation was done with STA WSYNC. I had created a raw register dump of a .sid file with a modified version of TinySid and every frame I left the main loop a few times for a few cycles to stuff the SID emulation engine with new values. I didn't take long to realize I didn't have quite enough time to do much else. I wanted to ditch the idea of playing a register dump. Even RLE compressed it took way too much memory to store a decently sized song. I wanted to run the original C64 player routine. That led me to the source code of siddasm and a rewrite with more features, which I called siddasm2 (really original). I moved the emulation code to page zero to save some cycles, but that did not really help enough. At the same time, I stumbled upon a bug in Atasm and instead of fixing that, I ended up writing my own assembler. I had always wanted to do that. I won't go into details here. See my previous blog entries on shasm65 and siddasm2. After that, I kind of lost interrest, but a few weeks ago I continued this project. I completely rewrote my SID emulator in shasm65. Now the emulation engine was running of a timer interrupt, leaving the main loop free to periodically call a C64 player routine. This routine had to be patched though to write to shadow SID registers instead of the C64 hardware registers. This is where siddasm2 came in again. Early in the process of disassembling Laxity's song "Freeze" I noticed that the resulting assembly code couldn't be assembled again by atasm AT ALL. Which shouldn't be the case. I fixed a few bugs in siddasm2 and shortly after that I was able to recreate the .sid file from source code with the help of atasm -r and unix dd (for the header). So far, so good. Now I was able to patch the source code of 'Freeze' and run it alongside my sid emulation code. I added code that converted the shadow sid registers to values my engine could work with, added ADSR envelope handling, everything I used to do in my modified TinySid. A few debugging sessions later, I had it all working! After that, I disassembled and patched the International Karate tune. This triggered a new bug in my emulation, which is now fixed. I sent out an example to Freddy (F#Ready on AA), which he turned into a youtube video and posted a link on AA to see what all of you would think about it. And now I figured it's time to release the source code and a few binaries to play with Attached you'll find version 2.1 of siddasm2. A slightly modified shasm65 which is now verbose in hex instead of decimal (but the original shasm65 is still fine to assemble the code, too. The assembler itself did not change). .xex binaries for Laxity's Freeze, Rob Hubbard's International Karate and Jeroen Tel's JT42. The source code for everything. Regards and have fun! binaries.zip shasm65.zip siddasm2-2.1.zip sid-songs.zip atarisid2.zip

I guess running rastaconv on a Cortex-A8 could benefit a lot from converting the usage of floats and doubles to fixed point math.

Perhaps it'd be nice to have a non-gui version, too, in the future, which then can easily be run on headless machines. One might even strip out all FreeImage code and only support PPM files (portable pixmaps) and BMPs, which are trivial to read without an image library. Having Allegro and FreeImage is nice, but not strictly necessary to do the conversion of images.

I got about 10% speed increase by the following procedure: (on Linux) first, compile with -fprofile-generate (add to CXXFLAGS) and link with -lgcov (add to LIBS) run the resulting rastaconv for about 100k itterations, exit with ESC. you'll see a bunch of .gcda files appeared in your src directory. make clean, change -fprofile-generate to -fprofile-use and remove -lgcov from LIBS make again the resulting binary runs about 10% faster than the original build on my humble AMD 32-bit Sempron 2400+ Basically, what g++ does, among other things, is that it logs which codepaths are more likely to be run and uses this information to optimize branch prediction. (edit: numbers where against profile-generate build and not against a normal build; still, it's 10% faster)

I am fairly sure that you can compile it for Mac OS X too if you install the necessary packages from http://www.macports.org/ There's both freeimage and allegro there.

Linux users need this small patch and add -std=c++0x to CXXFLAGS (needed for the auto keyword). Great work Phaeron and thanks for including the portability patches. patch.zip

I guess C64 will (should?) be next, considering its (relatively) huge user base and the SID chip.

Color reduction is not always helpful as a preprocessing stage. Otherwise you could just reduce the amount of colors on each line to four (or six or eight or whatever) and be done with it. Sometimes several colors will map to the same Atari 8-bit color (which is why using different destination palette files results in different solutions). Increasing contrast and/or changing hues of certain colors can also be beneficial. If color and contrast stand out more, chances are they will map to different 8-bit colors and have a higher probability to be kept in the end (instead of being somewhat approximated by dithering with other colors).

These 104 caps (10 plus 4 zeroes --> 100000pF = 100nF ) are often called decoupling capacitors. They sort of "smoothen" the power supply. I doubt a non-working machine will start working again if you replace these capacitors.

This might be a good start http://www.loc.gov/search/?q=atari Also, if you look at my old posts, you might find a few books I scanned recently that were not scanned before.

Here's a patch to compile this on Linux. Just a few small fixes to make it more standards compliant and a simple Makefile. Did not fix the pathsep issue, but you can just specify the input file and palette file on the command line. Thanks for using portable libraries like allegro and freeimage. rasta-linux.patch.zip

O boy, out of tune is not a 'personal taste'. The equal temperament is already slightly out of tune in any key, but most people just don't hear it as they are not used to just intonation. I have not listened to miker's original, but the 'video' you posted is more than 'slightly detuned' in a lot of places.

are the menus cached or re-rendered each time the mouse hovers over?

Hmm, I hate reverse basic. Still, after all those years, my 'arm-muscle-memory' automatically presses option when booting an atari 8-bit. I have to _think_ not to do it. BTW can you reflash a 32-in-1 OS?

I have been thinking about something similar, but a little different. I thought about replacing the RAM with high-speed SRAM and use the first half of the cycle to do the DMA. That way you won't have to halt the CPU. If you buffer the ANTIC bus, you could even get your refresh cycles back by disconnecting the HALT line and bus in case of refresh cycles. It's all just thoughts though, nothing concrete, but it might give you/others some inspiration