| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
DE00-DFFF
I read just about everything I could find about this memory area, but I remembered something, perhaps from a chat on IRC or something..
This mem area contains the program-counter, the last accessed line nr, cycle-counter, well - just about everything the machine does.
Is this true ?
Who knows anything ?
I can dig that any expansions put into the machine must have some input data, so naturally there has to be some important info in this memblock - but which ones exactly ?
I also read that it don't nessecarily behave the same way on every C64.
So ?
Help!!
I am also looking for a way to read the read-only registers of the SID.
My friend Kaze/TST did it once, but that program is lost forever, and he didn't code since 1988 on C64. damn.
The program was running a modified KERNAL, and it enabled us to write the music while playing, out to disk as a D400+ dump - but it was way to slow and the disk just got filled up very fast.
But it worked!
|
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11293 |
when you read from open i/o space you will always get the value that was on the bus last. it "contains" nothing at all unless you connect some sort of i/o expansion that maps its registers there (thats what this area is for anyways)
and as for "reading" the sid registers - its not possible either. the program your friend made probably worked the same way as the "music cruncher". it banks out i/o (and thus the sid), then calls the music routine. the music routine would then store whatever it writes into the ram at $d4xx instead of the sid, and the ram can ofcourse be read. (and to play the music at the same time, you keep track of what locations has been written to and write these values into the sid - after banking it in again ofcourse) |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Well, my DE00 area is filled with some random numbers jumping around, but upon closer inspection - they are not random. There are counters and flip/flops. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
the $DE00 area has nothing to do with the SID. also, reading sid register is impossible except for the read only registers ofcourse. if kaze used a modified kernal i believe he switched off the I/O area and let all sid register writes go to ram instead of sid and then log them + copy them to the sid registers. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
oops, same reply as groepaz :D |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Tell me what you know about DE00-DFFF Graham!?
Is there real´ly nothing usefull there, besides adding an expansion ?
|
| |
Hoogo
Registered: Jun 2002
Posts: 103 |
Quote: when you read from open i/o space you will always get the value that was on the bus last. it "contains" nothing at all unless you connect some sort of i/o expansion that maps its registers there (thats what this area is for anyways)
and as for "reading" the sid registers - its not possible either. the program your friend made probably worked the same way as the "music cruncher". it banks out i/o (and thus the sid), then calls the music routine. the music routine would then store whatever it writes into the ram at $d4xx instead of the sid, and the ram can ofcourse be read. (and to play the music at the same time, you keep track of what locations has been written to and write these values into the sid - after banking it in again ofcourse)
I thought about that too, but I found that it would only work if the music-routine writes only one tiome per call into the registers. And I imagined quite some effects that need more than one writing, and so I dropped that. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Quote: Tell me what you know about DE00-DFFF Graham!?
Is there real´ly nothing usefull there, besides adding an expansion ?
it is there for expansions. cartridges map parts of their rom and registers there. no cartridge attached -> no use. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11293 |
hoogo: yes that problem exists. another problem is that you can not say for sure which register has been written to at all, which make things even worse. however, it seems to work ok for many tunes anyway.
graham: didnt marko makäla write some little crazy program that runs in open i/o space? mmmh... or was that color-ram? *shrug* |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Hmmm... about DE00+ i found i could fuck up things by poking values to it.
About SID i made a frame-grabber that saves all poking to the SID.
Problem is, 1 min of music takes more than 64K ( I knew this beforehand).
I will now make it so it only saves the values that are different from the previous frame, then see how much RAM that takes..
LOL |
| |
iopop
Registered: Dec 2001
Posts: 317 |
@rambones: Could you care to explain why you want the data of a whole tune for a post processing scenario? Since, I guess you're aiming for the c64 as target machine of your idea? I'm just curious and if you don't want to reveal your secrets I can surely wait.. |
| |
Hoogo
Registered: Jun 2002
Posts: 103 |
>about DE00+ i found i could fuck up things
>by poking values to it.
Then you might have inserted a cardridge? |
| |
WVL
Registered: Mar 2002
Posts: 889 |
groepaz : you can clear your dummy area every frame with $ea for example to see if something was written or not.
problem remains that then you cannot detect if $ea (or any other number was written at all :(()
solution :
3 dummy buffers :
1 filled with $00, the other with $80 for example. 1 filled with the last data that was written to the sid.
every frame you write $00 to buffer 1 and $80 to buffer 2. then you jsr to the tune, which you have to 'adapt' to write to both your buffers.
then you have to check if something was written to the dummy buffers.
a simple
lda buffer1,x
bne somethingwritten
lda buffer2,x
cmp #$80
bne somethingwritten
..-> register x was not written
somethingwritten :
jsr storewrite
sta sidbuffer,x
sta $d400,x
will do...
and why would rambones want to do this? to save cycles in a darn-hard-cycle-eating-mega part? :)
I've been thinking about this myself too a bit, there's one part where I could really use the extra cycles gained...
(which I always only need for a couple of frames.. so...)
rambones : good luck
|
| |
Hoogo
Registered: Jun 2002
Posts: 103 |
Well, yes, if you can change the music-routine then you can perfectly detect every write to the sid. But what if you want to examine a music done in an unknown, tricky music-routine? |
| |
WVL
Registered: Mar 2002
Posts: 889 |
in case of a tricky music routine...
well... :)
maybe the easiest thing would be to find the pointers, and calling it twice.. or something ;)
you could also just have 1 buffer to catch the writes in, just put a very unusual value in there, and you should be alright in 99% of the cases, i think..
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
99.609375 actually :D and even more if you take into account that some values are more likely than others. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Quote: @rambones: Could you care to explain why you want the data of a whole tune for a post processing scenario? Since, I guess you're aiming for the c64 as target machine of your idea? I'm just curious and if you don't want to reveal your secrets I can surely wait..
Well, I want to attempt to make a universal player.
Just convert any tune to this dumpformat (crunched), and then play it using a STA d400,x
If I can crunch it enough that is...
|
| |
iopop
Registered: Dec 2001
Posts: 317 |
Quote: Well, I want to attempt to make a universal player.
Just convert any tune to this dumpformat (crunched), and then play it using a STA d400,x
If I can crunch it enough that is...
Ok, I thoguht you wanted to do some kind of tool that could filter selected parts of the tune etc. Though, the sampled data is not the amplitude but parameters creating the amplitude. So, that might not have been possible anyhow. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11293 |
uhmz like i mentioned before.... this kind of tool already exists :o) its called "music cruncher" and works exactly like you say. |
| |
Hoogo
Registered: Jun 2002
Posts: 103 |
I'm thinking about an assembler-interpreter for the music-routine. That will surely detect any access to the sid. I have done such an interpreter ages ago, maybe I'll have a look at it again. |
| |
Clarence
Registered: Mar 2004
Posts: 120 |
Quote: uhmz like i mentioned before.... this kind of tool already exists :o) its called "music cruncher" and works exactly like you say.
Can you tell me who made this tool and where can I find it? If you refer to the Spiders Crews 'Music Rastertime Cruncher', that doesn't crunch the dumped data at all. |
| |
Vai
Registered: Mar 2002
Posts: 50 |
The Music rastertime cruncher wasn't supposed to crunch the music data but the amount of rasterlines used by the player.
Yeah, I know ... stupid tool I've made :) |
| |
Clarence
Registered: Mar 2004
Posts: 120 |
Quote: The Music rastertime cruncher wasn't supposed to crunch the music data but the amount of rasterlines used by the player.
Yeah, I know ... stupid tool I've made :)
I like your tool, but It could have been a bit improved. It uses too short dumps, and fe. doesn't detect simple things like if a register has a constant value for hte whole excerpt etc. So I had to do a routine of my own. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Not that I know how the SID-chip works, but isn't there a chance that some registers only reacts to the actual write, not the value, like for instance reseting something. For example a write to register X causes something special despite the actual value. This would mean that by removing duplicate writes with the same value actually causes error in the playback.
Any comments? |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
You are absolutely right! |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
I should have explained..
if you write something to an OSC and it does something,
after a few lines it may be started again (f.ex multispeed tunes), so all writes in 1 frame has to be grabbed
|
| |
Frantic
Registered: Mar 2003
Posts: 1641 |
Quote: Not that I know how the SID-chip works, but isn't there a chance that some registers only reacts to the actual write, not the value, like for instance reseting something. For example a write to register X causes something special despite the actual value. This would mean that by removing duplicate writes with the same value actually causes error in the playback.
Any comments?
Yes..
As rambones say.. More specifically, the wave counter in the SID-chip may for example be reset using the test bit. Switching it back and forth (1=hold it reset/0=start wave counter again) would reset it, which one could imagine could very well happen in some players during one single "tick" of the player, even if it is a single speed tune. (Especially since the testbit is often used deliberatly in the process of doing "Hard Restart".)
|
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Just so I get this straight..
Hardrestart is resetting the OSC to start the waveform from point 0, or ?
|
| |
Frantic
Registered: Mar 2003
Posts: 1641 |
Rambones: Well, flipping the testbit back and forth seems to be resetting the counter to 0, yes. Further info can be found here for example:
http://stud1.tuwien.ac.at/~e9426444/sidtech4.html
However.. About "Hardrestart":
I don't know if there is really any clear definition of exactly what hardrestart is supposed to be, since different people seem to use slightly different methods. But the point in all those cases should be to have ADSR to behave in a more consistent way. I'm not sure weather everyone actually use a method that involves the testbit. (If I remember correctly, my experience is that flipping the testbit may also introduce a little click sometimes, but maybe I just wasn't careful when testing it... Maybe there is other Hardrestart methods?)
Hope I didn't lie about anything now.. :)
|
| |
Stirf
Account closed
Registered: May 2002
Posts: 26 |
have a nice trick for SID readout... trick the player!how?make $d400 ram while calling to $1003 (play) and stash that somewhere in normal RAM then copy to say "rom" (I mean the normal situation) and use the stashed data to save or manipulate, I believe a lot musicplayers can be tricked this way.I have actually used this long ago so it works. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Yes it works, but if f.ex D404 is written 3+ times, with values A,B,A - you only get A after a grab, so the playback will not be correct.
|
| |
Frantic
Registered: Mar 2003
Posts: 1641 |
yeah.. Hmm.. I thought just a little bit more about this and when I think of it I'm not so sure what reasons a player would have for writing to a certain register more than once per call to the player? (That there might me more than one call per frame is obvious though, of course.) Hardrestart does after all operate on a timespan of roughly two frames, so maybe that post by me earlier in this thread was not so relevant after all. (Kingfisher/TRIAD wrote somewhere: "The actual minimum time [for hard restart] is 33 ms = 2^15 cycles according to Dag Lem, author of reSID.") Any experienced player-coders in here might have something to say about this? Is there any (other) "common" reason for why you would want to write more than once to a register each call? |
| |
Stryyker
Registered: Dec 2001
Posts: 466 |
Matt Gray's player used for Last Ninja 2 often writes to SID registers more than once when initialising a note. |
| |
Hoogo
Registered: Jun 2002
Posts: 103 |
If you want to increase the sustainlevel while the voice is in its sustain-phase, the sound will enter its release-phase. You have to reset the gatebit and set it again, 2 writes. But I dont know if that is used in any player. |
