Jump to content

aTc

Members
  • Posts

    12
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by aTc

  1. I've updated the links in the first post. I moved about some of the server stuff, and I thought I had these files in the same place as the sidplay sources, but apparently they weren't.
  2. It has the same implementation and limitations as the and sid players Getting it in upstream vice shouldn't be that hard, although they might not like that im borrowing the rtmidi code to get platform independant midi output. And it's more or less bolted on to the "dump" driver, that happens to catch all the sid writes, and has a flush routine that gets called at just about the right time to send the midi packets out. So something more reliable might be needed there. And here's a not so great video of it running Also here and here are two more videos of the old version, which inserted inself in the sid emulation of vice, but that only really worked with those two games, and was a lot more complex than what i'm doing now :)
  3. This should allow you to use your midibox sid as the sound output for the VICE C64 emulator. I should have released this ages ago (although this is redone for the new vice2.4 release) Both linux and windows version still need a lot of testing. I only just got it working again, and decided to get it out there before I get lost in some other project and forget to release it :smile: I do get some errors in the windows version, but that could be because im trying to run that from virtualbox, and it might also be because of some wrong mingw compiler settings. I'll have to see if this can be cleaned up enough to be considered to be included with the official vice release. And any help is welcome of course. binary windows version here: http://wreck.k-n-p.org/asid/vice2.4-asid-win32.zip linux sources here : http://wreck.k-n-p.org/asid/vice-2.4-asid.tar.bz2 To enable the asid output, use the "-sounddev asid" command line option. Select the midi port to use with "-soundarg". The list of ports is output when the asid driver is started (either on the command line, or in vice.log) It defaults to port 0, which is usually some internal port. x64 -sounddev asid -soundarg 1 It can also be set in vice.ini : SoundDeviceName="asid" SoundDeviceArg="1"
  4. aTc

    linux asid player

    I'll try to get it cleanly into VICE as just another sound output option. VICE is pretty modular. Of course I have to fix a lot of stuff first. PCM playback is never going to work with this protocol, and even with another protocol there's still an awful lot of data to be sent over midi. Most routines seem to write every 120-200 clockcycles to register $18. And most sids that don't play back properly now is because it writes more than once to a register, which the protocol doesn't support (except for two writes to the gate registers). And another possible problem might be that the delay between the writes to the registers is lost as well.
  5. aTc

    linux asid player

    Done. :) Well, not quite, needs a lot of cleaning up first, and better integration with the rest of vice, but it's usably on my machine.
  6. aTc

    linux asid player

    Well, best player.. I only show the sids that work properly in the videos :) And it's basically as good as sidplay2 is. Of course the biggest problem is the asid protocol itself. Anyway, I did mess about with VICE, and to my own surprise managed to get it to output to asid. It's in very early stages, but it works reasonably well. And as before, the biggest limitation is the asid protocol, you have to wait untill there haven't been any writes to the sid registers for a while, then group all the writes together and send the data. Would be a lot easier if you could just send the register and data in two midi bytes and have it update immediately. No idea if midi can handle that sort of stuff fast enough, they must have had a reason to make asid the way it is. Here's a video of that hacked VICE, playing Great Giana Sisters.
  7. aTc

    linux asid player

    Turned out there was an easier solution, which is clock_nanosleep(), which will wake your task up at a requested time with pretty good accuracy. Videos of it playing various sids on the pandora here. Video 2 uses nanosleep instead of usleep, which already improved accuracy quite a lot, but it still wobbled about a bit. Video 3 uses clock_nanosleep, waking it up at a requested time, and is far more stable. Has only minor problems when there's other programs generating a heavy cpu load, but that's more a task switching priority thing. Accuracy can be improved even more by giving the task a higher priority. sidplay2-asid_0.2 can be downloaded here. I'll have a look at the VICE code, but i'm not promising anything :)
  8. aTc

    linux asid player

    Problem with my version is that it just puts the task to sleep based on the c64 clock cycles between the writes, without taking into consideration how long the emulation, or the midi writing takes. So on a fast computer it's more accurate, since it spends less time calculating stuff. It's mostly to do with the timer used by the kernel for task switching. I think the main reason for the slowdown is because my desktop is using a 1ms timer, and the arm device as 10ms one. (sid playing in that video is C64Music/MUSICIANS/W/Whittaker_David/Tube.sid , should have probably used a more well known tune) A more accurate method would be one where you just have a function that's called 50 times/second, and sends the changes. But i think you run into problems with sids that were meant to run at 60hz, or use timing other than vblank. At the moment I have no idea if it's possible to get that sort of info from sidplay2 inside a builder. All you seem to get in a builder is which register is written to, and at which clockcycle, and for that method to work properly you really need to be able to call the emulation for new data, instead of the emulation calling you when something's written to a sid register. As I said before, really need to dig a lot deeper into this whole thing.
  9. aTc

    linux asid player

    Making it more stable than asidxp isn't much of a challenge :) And as a bonus, here's a video of the player running on an arm device. Apart from the obvious timing problems, it's quite easy to get it running on almost any device that runs linux. (and has a midi port). Fixing the timing properly is a bit of a challenge though, and I first have to dig about in the sidplay2 source a bit more to find out exactly how it does things.
  10. aTc

    linux asid player

    Ah, yes, I seem to have forgotten to move the old writes to the secondary registers back to the first ones. Fixed now. Do you happen to have a list of sids that are especially problematic to play back ?
  11. After getting annoyed with asidxp, and having to boot into windows to actually use it, I decided to have a go at getting the linux sidplay2 to output to midi. And so after a few days of messing about (most of which was listening to sids on my sammich), I came up with this: http://wreck.k-n-p.org/asid/sidplay2-asid.tar.bz2 It's a sidplay2 with the hardsid part modified to output to midi. It works for most sids, there are a few problems with some that write to the registers more than 3 times every frame, since the protocol doesn't support that. Sample playback obviously also doesn't work. It's pretty much a hack, the code needs some serious cleaning up, and needs to be moved into its own builder, instead of hijacking the hardsid one. It also uses a very basic, slightly inaccurate timing method at the moment, which also needs work. I'll get to that once i've tried all 38,714 sids in the hvsc with it, which is slightly more fun :) It's pretty much hardcoded to work with linux+alsa at the moment, but since it uses RtMidi to take care of the midi end of things, it should have no problems running on other platforms after some cleaning up. No binaries, you'll have to compile this yourself. See readme.txt included in the archive for compiling details. Tested on ubuntu 10.04, both 32 and 64 bit versions, and crosscompiled to arm. It's pretty much in the "it works for me" stage now, any suggestions, bugfixes and code cleanups are welcome :)
  12. I finished putting my sammichSID together a few days ago, had too much fun messing about with it to post here sooner. Building it wasn't that hard, took me about 12 hours in all (did it in one go, with a few short breaks. There's no way I'd be able to sleep with it sitting half finished on my desk anyway). Painting it took me a bit longer, but that was mostly waiting for it to dry before painting the next layer. This was the third, and biggest kit I soldered this far, so someone with a bit more experience could probably do it a bit quicker. Only mistake I made was forgetting to solder one side of one of the sid sockets, which caused that sid to sound all out of tune, and later it just stopped working. Luckily it was only the socket not beeing soldered in properly, and not a dead sid. Everything works fine now. The package took exactly one week to arrive here in .nl, which was a lot faster than I expected. One question about the sammichSID itself though. Some of the default patches, and especially the "Filtered Poly" one when it's playing 3 notes on a single chip, seems to distort quite a lot. I know the sid is supposed to have some distortion, but in this case i'm not sure if it's supposed to do that, or that I made another mistake soldering it. It happens with both sids, and the output level at the jack seems fine. So probably nothing to worry about, but I just want to make sure. Now to get a linux sid player working with it...
×
×
  • Create New...