Mobile SID player - DIY?
Brian Lund
player (Or just a stationary SID-player for that matter). I have been
looking at google, i also found a single project with a guy who made a
stationary SID-player, there was also a schematic, but it seemed to
complicated, especially since there was no software included...
My idea was to use a 8051 microcontroller to feed the sid-files to the
SID-chip, but then i need to know what exactly to do with the files so that
the SID will understand what is being fed to it, and put out some sound :) -
I have no idea how a sid file works...
Can anyone help?
Brian
John Moore
"Brian Lund" <geronimo@-ABCDE-mobilixnet.dk> wrote in message
news:406990ee$0$158$edfa...@dread11.news.tele.dk...
I can't remember the name or address of the site, but someone has made a
portable sid player. I think it was called the 'Sidman'. I think that this
may be on the same site that you found the stationary version.
--
"I'm programmed to never perform any extraneous tasks."
Please change 'nospam' to jcom to reply.
----- http://jcom.shorturl.com ----
John Moore
"John Moore" <butter_...@nospam.freeserve.co.uk> wrote in message
news:c4cqev$d2u$1...@newsg3.svr.pol.co.uk...
>
> "Brian Lund" <geronimo@-ABCDE-mobilixnet.dk> wrote in message
> news:406990ee$0$158$edfa...@dread11.news.tele.dk...
> > Hello, i have been speculating if it might be possible to build a mobile
> SID
> > player (Or just a stationary SID-player for that matter). I have been
> > looking at google, i also found a single project with a guy who made a
> > stationary SID-player, there was also a schematic, but it seemed to
> > complicated, especially since there was no software included...
> >
> > My idea was to use a 8051 microcontroller to feed the sid-files to the
> > SID-chip, but then i need to know what exactly to do with the files so
> that
> > the SID will understand what is being fed to it, and put out some sound
> :) -
> > I have no idea how a sid file works...
> >
> > Can anyone help?
>
> I can't remember the name or address of the site, but someone has made a
> portable sid player. I think it was called the 'Sidman'. I think that
this
> may be on the same site that you found the stationary version.
>
found the site:
http://www.tripoint.org/kevtris/Projects/sid/sidman.html
mid64
not like hacking the X-box or something.
I doubt the DMCA stormtroopers would come down on him too hard.
He's kind of saying "look what I did... you can't have it!"
Pretty much the antithesis of what the 21st century C= spirit should be.
(But the sidman is a cool project)
Brian Lund
Yes, the page is really good for nothing except pictures...
> He's kind of saying "look what I did... you can't have it!"
>
> Pretty much the antithesis of what the 21st century C= spirit should be.
>
> (But the sidman is a cool project)
Yes, yes, yes!...
If I only knew what to do with the SID-files so that the SID chip will
"understand" it I could do the rest myself i think.
Maybe I could mail him...
Brian
Scott McDonnell
teams, since they invented the formats. There are still some raw
formats in PRG form. I believe Compute magazine came up with those.
Scott
"Brian Lund" <geronimo@-ABCDE-mobilixnet.dk> wrote in message
news:406ad3c8$0$180$edfa...@dread11.news.tele.dk...
J.Oppermann
Brian Lund wrote:
> If I only knew what to do with the SID-files so that the SID chip will
> "understand" it I could do the rest myself i think.
come on, you can find all those documentations about the formats.
http://www.geocities.com/SiliconValley/Lakes/5147/sidplay/doc_formats.html
AFAIK the SID-File is a 1:1 copy of the C64 binary with a header added.
I once wrote a little tool for my Atari ST to show the contents of that header.
Kevin Horton seemingly is mainly concerned violatig copyrights.
I think I can understand why he rejects doing it.
Scott McDonnell
The reason I did not recommend that document directly is because it only
describes the header. AFAIK, the binary data contains machine code
subroutines for the 'player' and the SID register data packed in a certain
order. The subroutine is called to load the registers. I have yet to find
documentation on the binary portions of the files.
Probably one of the easiest ways to know for sure is to get a C64 SID or
MUS player and then disassemble it or use the monitor in the Vice emulator
to watch what is going on.
It appears that to make a portable SID player easily, you will need to
emulate the 6510 because of the machine code. However, if you can
figure out the exact layout of the register data, it should be possible to
simply load the data into the SID with whatever processor. Other than
timing issues, I don't see why it wouldn't work this way.
I cannot say for sure, of course, because when I was toying with the idea,
I gave up because I realized I could just get a cheap MP3 player and
download converted SIDs. Sure, it's not going to sound the same, but I
am not a real SID fanatic either.
Scott
"J.Oppermann" <m...@privacy.net> wrote in message
news:c4gl4r$2icnj3$1...@ID-67386.news.uni-berlin.de...
Marcel Gonzalez
Don't even waste your time going there. You will like what he made and
then find out he doesn't even have schematics or wiring diagrams up
for download, just basic specs.
Marcel
J.Oppermann
Scott McDonnell wrote:
> It appears that to make a portable SID player easily, you will need to
> emulate the 6510 because of the machine code. However, if you can
that's "all" I would say - what else anyway?! (;
> figure out the exact layout of the register data, it should be possible to
> simply load the data into the SID with whatever processor. Other than
> timing issues, I don't see why it wouldn't work this way.
This is a "recorder-project" I once wanted to approach with my Atari ST, but
it's too slow, so I was considering that for my SID'esizer, but... *lazy me* (;
But you still need an emulator to "unpack". Well, David's Atari FlaySID had this
feat for debugging, as it's happening in the emulation anyway. So I guess
PlaySID (or SID-Play, or whatzit) can do the job as well. Even though in size it
will be a compromise between an averagely quality mp3 (or better ogg) and the
original SID-file. But it gives funny options...
> I gave up because I realized I could just get a cheap MP3 player and
> download converted SIDs. Sure, it's not going to sound the same, but I
> am not a real SID fanatic either.
I was considering it, to be able to spread the SID tune upon my 4 SID's in the
SID'esizer (;
BTW I read Kevin's FAQ - that's tells it all... I almost guess that.
Rainer Buchty
"J.Oppermann" <m...@privacy.net> writes:
|> > It appears that to make a portable SID player easily, you will need to
|> > emulate the 6510 because of the machine code. However, if you can
|>
|> that's "all" I would say - what else anyway?! (;
Potentially the CIA, at least the CIA timer IRQ since the sample playback
routines are usually timer IRQ-driven. (At least the ones I touched so far.)
Rainer
Zed Yago
> The reason I did not recommend that document directly is because it only
> describes the header. AFAIK, the binary data contains machine code
> subroutines for the 'player' and the SID register data packed in a certain
> order. The subroutine is called to load the registers. I have yet to find
> documentation on the binary portions of the files.
After the header, there is the player itself. Its in 6502
Machinelanguage.
So, every sidplayer has to emulate the 6502, too.
Furthermore, many player-routines use the VIC or a CIA, so you should
have a (simple) emulation of these chips, too.
Often its just:
At the start, jump to that routine.
Each frame, call this routine.
In these cases, you dont need to emulate VIC/CIA.
Because there are many different editors/players, the SID registers
are not really in a certain order.
HTH,
Zed Yago
Scott McDonnell
news:f5e16757.04040...@posting.google.com...
> "Scott McDonnell" <devi...@NOSPAMexcite.com> wrote in message
news:<EtSac.52853$w54.334572@attbi_s01>...
>
> > The reason I did not recommend that document directly is because it only
> > describes the header. AFAIK, the binary data contains machine code
> > subroutines for the 'player' and the SID register data packed in a
certain
> > order. The subroutine is called to load the registers. I have yet to
find
> > documentation on the binary portions of the files.
>
> After the header, there is the player itself. Its in 6502
> Machinelanguage.
> So, every sidplayer has to emulate the 6502, too.
> Furthermore, many player-routines use the VIC or a CIA, so you should
> have a (simple) emulation of these chips, too.
Well, if the actual 6581 register data is located in some repeating, fixed
table
within the .SID file, I disagree that 6502 emulation is needed. All that is
needed is to pass the bytes into a 6581's registers. ANY microcontroller
that has at least 2 ports can do that. Most microcontrollers have built in
timers which are at least as capable as the timers in the 6526, so it is
entirely
possible to replicate the timing without a problem. Given the fact that most
modern uCs run at a much higher clock rate than the 6502s, this would not
even begin to tax the uC. You could add LCD and keyboard routines that
do their job while 'waiting' for the next update of the 6581 registers and
STILL
have lots of time to spare.
Again, I repeat:
The ONLY thing missing to do a project like this is the *exact* format of
the
.SID data. Is it just a recurring table with images of the registers and
subroutines
load the accumulator with these values and store them to the 6581 registers?
Or is it a bunch of LDA #/STA#s that do this (would be outrageously silly
and redundant.) Not to mention the fact the *every* SID file would need to
be
written from SCRATCH as a program. So, is it a program, or a self-playing
music file? If it were not modular, it would not have been a standard and
every
SID would be different. I can only imagine that the player just loads data
from
the tables and plugs them into the 6581 registers, and has the ability to
use
delays to effect tempo.
Sure, if you emulate the 6502 and partially emulate the CIA, then you just
load the .SID and 'run' it. The .SID file itself does all the work. But this
seems extraordinarily unnecessary just to load the registers and work
the gate bits at the right times. You waste a lot of code space emulating
when all you should need to do is load the data, and plug it into the
registers. Nice, tight, efficient code.
I cannot imagine that a .SID would not have the data arranged in a table
with registers, durations, etc.. and in a recurring format so that a
subroutine
were called and it would just sequentially load from the table and store in
the
registers, load and store, load and store, ad infinitum. Anything else just
seems ridiculous.
Somebody here HAS to know the answer to this. It is obvious there is
machine code for a player, and a header to store info about the contents
of the file. THAT information is in a hundred places all over the internet.
But, the really important piece of information is the format of the data
tables themselves, if they exist.
Scott
gary
that the CPU actually controls the way SID plays a song, the SID
ship itself takes data in order to play notes. In other words
the SID can read data to play a note at a certain pitch, waveform,
etc.. but that is all. The CPU executes machine code which would be
the .SID file without the header in order to play a song.
SID=musical instrument
CPU=musician
ROM/RAM=music sheets
:)
---
Gary
J.Oppermann
Rainer Buchty wrote:
Hach, Du mußt immer so präsize sein (;
Perhaps the VIC, too, if sb used the Rasters SCNR (8
Zed Yago wrote:
>
> Furthermore, many player-routines use the VIC or a CIA, so you should
> have a (simple) emulation of these chips, too.
ViC, bingo... (;
Scott McDonnell wrote:
> Well, if the actual 6581 register data is located in some repeating, fixed
> table
> within the .SID file, I disagree that 6502 emulation is needed. All that is
> needed is to pass the bytes into a 6581's registers. ANY microcontroller
You expect any SID-Tune to be of the same format, that is certainly not at all
the case. AFAIK Rob Hubbard never used a "generating player", but own routines.
And the players routine is de facto 6510/6502 mach.lang. So you can never expect
Tunes to be of the same structure, especially not the "old" tunes, where
(time-tight) tune-creators were not, yet, "invented".
> that has at least 2 ports can do that. Most microcontrollers have built in
> timers which are at least as capable as the timers in the 6526, so it is
along with the SID format I once found a description of how to rip tunes. this
guy gave a rough overview how most of the tunes are "designed". sth about
interrupts around the Zeropage-Vectors and this kind of stuff.
For that reason the Header bears the "jump-in" address of the player-routine
that cares all about the rest. I remeber that ppl even wrote selfmodifying code,
and/or runtime-decompression.
correct me if I'm wrong, but you'll need an emulator for (m)any tune(s).
> Again, I repeat:
> The ONLY thing missing to do a project like this is the *exact* format of
> the
> .SID data. Is it just a recurring table with images of the registers and
to my knowledge there is NO such thing.
What makes you thinking that?
There might even be tunes in BASIC. There is no "player" in the C64 OS.
Everybody wrote their own!
Well all which for efficency, the unltimative Format, but it's not here.
(yes, what about SID-Tunes in XML *oh, bugger*)
> load the accumulator with these values and store them to the 6581 registers?
> Or is it a bunch of LDA #/STA#s that do this (would be outrageously silly
> and redundant.) Not to mention the fact the *every* SID file would need to
of course they will usually have used tables, but I guess they all did it
differently (;
> written from SCRATCH as a program. So, is it a program, or a self-playing
> music file? If it were not modular, it would not have been a standard and
exactly, I think they are all self-sufficient-interrupt-timed-music-playing routines
> SID would be different. I can only imagine that the player just loads data
> from
> the tables and plugs them into the 6581 registers, and has the ability to
> use delays to effect tempo.
SIDplay cannot do this, have a guess why (;
They hardly can even speed up the tune without crashing the emulator.
AFAIK they do not even know when a tune ends. For that reason the HVSC guys came
up with another auxilary-list which has manual (subjectively) messured playing
times for tunes.
> Sure, if you emulate the 6502 and partially emulate the CIA, then you just
> load the .SID and 'run' it. The .SID file itself does all the work. But this
yes, this is how - I understand - it works
> seems extraordinarily unnecessary just to load the registers and work
> the gate bits at the right times. You waste a lot of code space emulating
> when all you should need to do is load the data, and plug it into the
> registers. Nice, tight, efficient code.
No, I do not think so. I thought about intercepting the 6510's transmissions to
the SID (my 8MHz ST is to slow, well the TOS overhead is too much in fact, not
to mention that sth odd is happening on the SID's /CS-line). Now you will get an
endless list of register changes and when will you stop? what is the timer?
Tunes have been packed by repeating the same part over and over again until
jumping to other patterns (what cubase would call ghost-patterns) you would then
"un-roll" these "efficent" loops. That's why I said you will gain a compromise
between the orignal smaller SID file and a mp3/ogg of good quality.
> I cannot imagine that a .SID would not have the data arranged in a table
> with registers, durations, etc.. and in a recurring format so that a
> subroutine
yes, I came up for at least 4 bytes per register change:
8 bit data
5 bit address (3 bit lost)
16 bit (hopefully sufficent) duration in some milli, or micro-seconds.
considering all the sweeps and stuff I guess any SID tune will be about 200 to
700KB then. Have a look at the SID file. Hardly any goes beyond 10KB.
> Somebody here HAS to know the answer to this. It is obvious there is
> machine code for a player, and a header to store info about the contents
> of the file. THAT information is in a hundred places all over the internet.
> But, the really important piece of information is the format of the data
> tables themselves, if they exist.
I never have written tunes and I never went much into this subject. but I went a
bit into the SID & C64 hardware and those are my perecptions and assumptions.
There is no such thing as an unique LUT-Tune format. well you could "unroll" all
the tunes and convert them (; I stopped bothering with the HVSC as they where
about 50.000 Tunes *hehehe*
MagerValp
SM> Again, I repeat: The ONLY thing missing to do a project like this
SM> is the *exact* format of the .SID data.
http://sourceforge.net/docman/display_doc.php?docid=8889&group_id=9266
SM> Is it just a recurring table with images of the registers and
SM> subroutines load the accumulator with these values and store them
SM> to the 6581 registers?
Heck no.
SM> Or is it a bunch of LDA #/STA#s that do this (would be
SM> outrageously silly and redundant.)
It's 6502 machine code. There's no structure or separation of code and
data. Some of the most famous musicians, like Rob Hubbard, wrote their
tunes in a machine code monitor. There are similarities between the
player routines in his different tunes, but they aren't identical.
SM> Not to mention the fact the *every* SID file would need to be
SM> written from SCRATCH as a program.
Yes, this is how it was done in a lot of cases.
SM> So, is it a program, or a self-playing music file?
You tell me:
.$10c1 A5 FB LDA $FB
.$10c3 48 PHA
.$10c4 A5 FC LDA $FC
.$10c6 48 PHA
.$10c7 CE 46 17 DEC $1746
.$10ca 10 1D BPL $10E9
.$10cc AD 47 17 LDA $1747
.$10cf 8D 46 17 STA $1746
.$10d2 C9 02 CMP #$02
.$10d4 B0 13 BCS $10E9
.$10d6 AC 94 17 LDY $1794
.$10d9 B9 6D 18 LDA $186D,Y
.$10dc 8D 46 17 STA $1746
.$10df CE 94 17 DEC $1794
.$10e2 10 05 BPL $10E9
.$10e4 A9 01 LDA #$01
.$10e6 8D 94 17 STA $1794
.$10e9 A2 02 LDX #$02
[... and so on]
SM> If it were not modular, it would not have been a standard and
SM> every SID would be different.
And they are.
SM> I can only imagine that the player just loads data from the tables
SM> and plugs them into the 6581 registers, and has the ability to use
SM> delays to effect tempo.
Basically, yeah. But there are literally thousands of different player
routines, all written by hand by different people. They all basically
do the same thing (read tables and store data in SID registers) but
they do it in subtly different ways, and in the end it affects the
sound and the tunes.
Don't be fooled into thinking that SIDs have anything in common with
MOD or MID files - they are completely different beasts.
--
___ . . . . . + . . o
_|___|_ + . + . + . Per Olofsson, arkadspelare
o-o . . . o + Mage...@cling.gu.se
- + + . http://www.cling.gu.se/~cl3polof/
Anders Carlsson
> Don't be fooled into thinking that SIDs have anything in common
> with MOD or MID files - they are completely different beasts.
Unfortunately, a LOT of people do. I have a friend who one day
last fall dreamed up an idea to write his own PC-based SID enhancer,
which would take all the notation data from a SID, apply samples
to each instrument and output a MP3 file. When I told him that
SID filesน don't work like that, he was greatly disappointed.
I also told him about SID2MIDI and that he could try to program
something in a similar approach, but it is probably way ahead of
his ambitions or capacity.
น) with the possible exception of COMPUTE Gazette's MUS files etc
which most recent SID playing software also can play
--
Anders Carlsson
Laust Brock-Nannestad
> They hardly can even speed up the tune without crashing the emulator.
Huh? This has never given me any problems.
> AFAIK they do not even know when a tune ends. For that reason the HVSC
> guys came up with another auxilary-list which has manual (subjectively)
> messured playing times for tunes.
If you are referring to the "Songlengths Database", it is automatically
generated based on an algorithm that Michael Schwendt (original author of
Sidplay) developed. And it does a great job, I might add.
The only way to achieve Scott's idea would be to pre-render/play the SID
file using a regular emulator and log all the SID accesses to a file. This
file would then be little more than a register dump and could be played
back using a relatively simple routine (written for just about any
microcontroller) that just kept feeding the SID at appropriate intervals.
This is pretty much what Nanosid by Laurent Ovaert does. Unfortunately,
the project appears to be abandoned, but more details can be found
here:
http://www.sid6581.org/NanoSID/
Regards,
Laust
Scott McDonnell
news:k2gk70y...@legolas.mdh.se...
Well, add me to that list of people that are disappointed. : (
Though, as I stated, I am not all too interested in such a beast.
It would be cool though. I guess if someone invents a new
format that includes the tables and tempo information that would
work well, but as MagerValp pointed out, a converter program
would be necessary. I guess this wouldn't be the end of the world
if someone has the ambition to do it.
So, Brian, you now have your answer (thanks guys!), now you
just need to decide if you want to do it. Modifying a SID player
to rip the registers and build a table would probably not be
extremely difficult, would work with whatever music files it could
play, and would offer a portable, universal format for future players.
Like I said, the hardware is the easy part...it is just a matter of
how difficult you want your code to be.
If you decide to do it, and you already know C++ and a little about
assembly and hex, I will help you out where I can. The brunt of the
effort will be on you, however.
Scott
Scott McDonnell
"MagerValp" <Mage...@cling.gu.se> wrote in message
news:p14wu4y...@panini.cling.gu.se...
> >>>>> "SM" == Scott McDonnell <devi...@NOSPAMexcite.com> writes:
>
> SM> Again, I repeat: The ONLY thing missing to do a project like this
> SM> is the *exact* format of the .SID data.
>
> http://sourceforge.net/docman/display_doc.php?docid=8889&group_id=9266
>
> SM> Is it just a recurring table with images of the registers and
> SM> subroutines load the accumulator with these values and store them
> SM> to the 6581 registers?
>
> Heck no.
>
> SM> Or is it a bunch of LDA #/STA#s that do this (would be
> SM> outrageously silly and redundant.)
>
> It's 6502 machine code. There's no structure or separation of code and
> data. Some of the most famous musicians, like Rob Hubbard, wrote their
> tunes in a machine code monitor. There are similarities between the
> player routines in his different tunes, but they aren't identical.
>
> SM> Not to mention the fact the *every* SID file would need to be
> SM> written from SCRATCH as a program.
>
> Yes, this is how it was done in a lot of cases.
In retro-spect, I guess I should have figured that. Since most of the
registers in a real SID are write-only, I don't see how the music
could've been 'ripped' that way. Though, in an emulator, it would be
simple. Also a semi-emulator that ran the machine code cycle-exact,
and just logged the data being directed to the registers and time-
stamping them would work as well. As Laust suggested.
Thanks for answering the question!
Scott
Anders Carlsson
> It would be cool though. I guess if someone invents a new
> format that includes the tables and tempo information that would
> work well, but as MagerValp pointed out, a converter program
> would be necessary.
One could settle for only playing SID music written in *one*
particular music program, i.e. the PC-based GoatTracker by
Lasse 嘱rni which I believe also has the source code available.
It is somewhat popular, at least among those newcomers to the music
scene who like the SID but not the C64 editing tools. What you would
do is basically to port the 6502 playing routine to a PIC etc, and
keep the music and instrument data as it is. You could even convert
the existing SIDs which are using this player to strip away the play
routine and add your own instead.
Certainly, it won't play Hubbard, Galway, Daglish, JCH or any of
the other classics, but at least a few of the newer musics. Maybe
it would also become another reason to use the GoatTracker because
a portable SID player is built specifically to play that routine.
--
Anders Carlsson
Agemixer
On Thu, 1 Apr 2004, J.Oppermann wrote:
> Brian Lund wrote:
> > If I only knew what to do with the SID-files so that the SID chip will
> > "understand" it I could do the rest myself i think.
>
> come on, you can find all those documentations about the formats.
> http://www.geocities.com/SiliconValley/Lakes/5147/sidplay/doc_formats.html
>
> AFAIK the SID-File is a 1:1 copy of the C64 binary with a header added.
> I once wrote a little tool for my Atari ST to show the contents of that
> header.
Not always; The HVSC crew added sometimes some C64 code within the
original C64 file memory rip, like the CIA (dc04/dc05) timers to play NTSC
and multiple speed tunes. (multispeed=Sid registers updated more
frequently than once per 50 Hz frame)
Generally, a .sid file is just the header + original C64 memory rip.
Usually, a memory rip is located from $1000-$2000, while the init
routine is $1000 (tune# to be played in accu) and playroutine at $1003,
played 50 times per second (or 60 times in NTSC). A tune copyright note by
author was usually located at $1020-$1040. The area $1000-($1500...$1a00)
was 6502 code, the playroutine itself, and the rest until $2000 was the
music data (note-tables, channels, tracks, instruments, and sector data.)
These are not a "very standard" of a c64 music file, but a widely used
manner.
Most tunes were created with some tracker, but please note that every time
the compression/executable tool of a certain tracer was used, the tunes
packed differently, and therefore every C64 tune data location is not
any standard.
For HVSC sid files, some tunes were ripped between $0f80-$2000, for
example, where the $0f80-$0fff (or similiar) was a driver for the
sidplay, sidplay2 etc to play the multispeed tunes correctly. Yep,
tweaking... which sometimes caused a real C64 not to play that tune
anymore ;-)
--
Agemixer/Skalaria - "First run, then load."
email: age...@japo.fi pass: "C64 mailinki" to the Subject: line
Spam filter is on
Agemixer
On 1 Apr 2004, Zed Yago wrote:
> After the header, there is the player itself. Its in 6502
> Machinelanguage.
> So, every sidplayer has to emulate the 6502, too.
> Furthermore, many player-routines use the VIC or a CIA, so you should
> have a (simple) emulation of these chips, too.
>
> Often its just:
> At the start, jump to that routine.
> Each frame, call this routine.
> In these cases, you dont need to emulate VIC/CIA.
..unless it is a multispeed-tune which must be treated correctly with a
CIA timers. Same goes for IRQ and NMI samples (so you need to emulate
both CIAs anyway...) :-)
Scott McDonnell
> "Scott McDonnell" <devi...@NOSPAMexcite.com> writes:
>
> > It would be cool though. I guess if someone invents a new
> > format that includes the tables and tempo information that would
> > work well, but as MagerValp pointed out, a converter program
> > would be necessary.
My apologies, it was Laust that pointed that out, not MagerValp.
> One could settle for only playing SID music written in *one*
> particular music program, i.e. the PC-based GoatTracker by
> Lasse 嘱rni which I believe also has the source code available.
>
> It is somewhat popular, at least among those newcomers to the music
> scene who like the SID but not the C64 editing tools. What you would
> do is basically to port the 6502 playing routine to a PIC etc, and
> keep the music and instrument data as it is. You could even convert
> the existing SIDs which are using this player to strip away the play
> routine and add your own instead.
>
> Certainly, it won't play Hubbard, Galway, Daglish, JCH or any of
> the other classics, but at least a few of the newer musics. Maybe
> it would also become another reason to use the GoatTracker because
> a portable SID player is built specifically to play that routine.
Good ideas, but I still think it would be worth the effort to make a
ripping utility that would work with any sounds going through the SID. I
have
another very large project going on right now, and thinking about this will
only distract me, so I will leave it up to the OP and anyone else interested
to implement this. I think for sure, there is enough information in this
thread
to being working on this. Now, it's just a matter of effort. Not sure how
that will work out, since the OP has only participated once in this thread
since his original post.
Scott
Agemixer
On Thu, 1 Apr 2004, Scott McDonnell wrote:
> Well, if the actual 6581 register data is located in some repeating, fixed
> table within the .SID file, I disagree that 6502 emulation is needed.
The 6510 emulation is a must, because there are several timing issues
between the CPU and SID anyway. Atleast when it comes to hardrestart, ADSR
triggering, SID recovery times and tunes played with higher speed. (Sorry
for getting quite in-depth of the trouble...) ;-)
> The ONLY thing missing to do a project like this is the *exact* format of
> the
> .SID data. Is it just a recurring table with images of the registers and
> subroutines
> load the accumulator with these values and store them to the 6581 registers?
You need an intelligent stepping code routine to find the correct areas...
also taking care someone might access SID registers with $d3ff,x instead
of d400,x in his code for example...
> Somebody here HAS to know the answer to this. It is obvious there is
> machine code for a player, and a header to store info about the contents
> of the file. THAT information is in a hundred places all over the internet.
> But, the really important piece of information is the format of the data
> tables themselves, if they exist.
There are, but you need an information of hundreds of (the most common)
playroutines, where the data is located etc. ...and there you start
debugging. No no :-)
Agemixer
On Fri, 2 Apr 2004, Scott McDonnell wrote:
> In retro-spect, I guess I should have figured that. Since most of the
> registers in a real SID are write-only, I don't see how the music
> could've been 'ripped' that way. Though, in an emulator, it would be
> simple.
There were a program called "tune optimizer" for C64 (or something like
that).
There is a solution to make a SID "debug" file in almost realtime, in
practice something like that:
lda $01 ;set RAM instead of SID I/O
and #$f8
sta $01
jsr init_NMI_trapper_grabber ;starts the SID grabber
lda #$00 ;standard tune init
jsr $1000
jsr grabbed ;add the first end mark to debugfile
and at the playroutine:
replace: jsr $1003
with: jsr $1003
jsr grabbed ;add end mark for each grabbed playframe.
Then, the NMI grabber should check for changes only at area $d400-$d420.
When done, we have a debugfile, which can be "packed" for a re-playing
routine, and if done correctly, the playroutine is faster and the
music (loop)data could be even shorter than original.. who knows ;)
That's how i would do it in real C64.
Agemixer
On Fri, 2 Apr 2004, Scott McDonnell wrote:
> "Anders Carlsson" <anders....@mds.mdh.se> wrote in message
>
> > One could settle for only playing SID music written in *one*
> > particular music program, i.e. the PC-based GoatTracker by
> > Lasse 嘱rni which I believe also has the source code available.
[...]
> Good ideas, but I still think it would be worth the effort to make a
> ripping utility that would work with any sounds going through the SID.
Well, sticking into one playroutine of SIDS is, hmm...
There is one solution in my previous message how it is possible to grab
a tune into a generic data format... but the .sid files are
easier converted to a generic "playroutine" with an emulator like
sidplay2, outputting a generic playroutine sid's, with a similiar way, but
the encoder should additionally output some kind of frequency delay
commandbytes (or whatever) to keep up the original speed and common
register "durations" in the sidtune. The resulting sid can be then also
played with a real c64 without a fear of the original sid routine crash...
(AFAIK They are still not all compatible with real c64)
I already gave my idea out in my prev message, so there you go... ;)
Brian Lund
> > the other classics, but at least a few of the newer musics. Maybe
> > it would also become another reason to use the GoatTracker because
> > a portable SID player is built specifically to play that routine.
>
> Good ideas, but I still think it would be worth the effort to make a
> ripping utility that would work with any sounds going through the SID. I
> have
> another very large project going on right now, and thinking about this
will
> only distract me, so I will leave it up to the OP and anyone else
interested
> to implement this. I think for sure, there is enough information in this
> thread
> to being working on this. Now, it's just a matter of effort. Not sure how
> that will work out, since the OP has only participated once in this thread
> since his original post.
Yes i sure got what i asked for :)
Well, as I don't know any other language than 8051 assembler I can't write a
program to rip/convert the SID data...
Maybe I could write something to emulate 6502, but since I don't know 6502
assembly either I would have to learn it first, sure it would be great to
know that too, but this project is just getting too complex.
So for now I think I will put this particular project on the shelf, however
I have thought about other things to do with the SID-chip :)
Thank you to anyone who wrote anything in this thread, and please inform me
if you know or intend to make a program which can convert sid files to
something i can put directly into the SID chip :)
Brian
Lars Haugseth
VICE features a file dump of any writes to SID registers. (At least the
Unix version does, don't know about WinVICE.)
$ vsid -sounddev dump MyTune.sid
Let this run for a while, and you will have a file 'vicesnd.sid'
containing one line for each write to a SID register. Each line
consists of three numbers separated by a space. The first number
is the delay in CPU cycles since last time a register was written
to. The second number is the SID register index ($D4nn). The third
number is the value written to the register.
The data in this file should be all you need to work on further
conversion of SID music or emulation of the SID itself.
--
Lars Haugseth
Lars Haugseth
I did something like this in the old days, to get music in a demo part
that only had a few CPU cycles left to spare per frame. It needs a LOT of
memory for storing the register data, though, unless you can think up a
_very_ efficient packing algorithm.
--
Lars Haugseth
Jan Harries rambones
Well, if you take the NanoSID technology, where all SID-output is
captured in a streamed file, you can use that for a generic player
that can be used for all sids.
Agemixer
On Mon, 5 Apr 2004, Lars Haugseth wrote:
> | When done, we have a debugfile, which can be "packed" for a re-playing
> | routine, and if done correctly, the playroutine is faster and the
> | music (loop)data could be even shorter than original.. who knows ;)
> |
> | That's how i would do it in real C64.
>
> I did something like this in the old days, to get music in a demo part
> that only had a few CPU cycles left to spare per frame. It needs a LOT of
> memory for storing the register data, though, unless you can think up a
> _very_ efficient packing algorithm.
True. It may help a lot if the routine was made to ask for a basic tempo
and duration (plus some initial offset of frames) so the music can be
"re-tracked" comparing on a fly, data as a lookup branch table
at that time... changes-per-channel comparison and stuff like that. I
don't think it can play realtime, so some kind of clock is required to
know when to stop grabbing the data :)
But ofcourse an emulator output with more memory gives us better chance
to analyze the data... i don't say it can't be done in C64 assembly but
atleast it takes less time to debug the more complex cruncher
algorithms and more convenient for .sid format ;)
But as the playroutines within the music and vice versa, are copyrighted
material, coder's art theirselves, i'm not very happy about the idea of
replacing other's work with some "generic" routine... unless you made
your own.