I tried your emulator (the Swing version) and it is nice, I should probably make a Swing version of JaC64 too, it is nice to be able to install locally. Do you know about the problem with Javasound in the latest version (Java 6?). It messes up the timing completely, at least for me.
Also, I would be much happier if you at least mention that you "inherited" from JaC64 in the beginning.
Best
-- Joakim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the main Wiki page of the project, http://jmec64.wiki.sourceforge.net/, refers to JaC64 as the original base of the emulator. Meanwhile every class has been rewritten from scratch, so that JME/JSwing C64 is now completely different.
This I fear is also the reason for some problems with the sound as my new SID implementation is not as "C64 compatible" as yours in JaC64 :-(. Can you tell what sound problems you encountered, as with most C64 programs it worked fine with JSwingC64 on my machine?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem is when the C64 emulator is synched using the write function that is supposed to block for a very short time (the time that it takes to get enough space in the buffer). But in Java 6 it is not the case, it can start blocking for a very long time. I got this problem when using your emulator (The JSwingC64 with the latest Java).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the quick answer. You refer to the SourceDataLine.write method, if I get it right. Is there a way to avoid this sync problem? I indeed have the problem that sound is not perfectly in sync.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
for the sound issue I created a bug and I already have an idea how to solve the problem: Passing data to the DataLine object could be done in a separate thread. This thread won't bother if it is blocked for a short period. As writing to the DataLine object is at the moment also used to keep the emulator work at the original C64's speed, this implementation OTOH requires that the emulator speed is throttled in another way. But that is no problem as my classes already contain such code.
Regards,
Jörg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess that should work fine. What type of method do you use for emulator speed control (that is not based on the SourceDataLine's write method)? Just interested, I have tried a few myself, non of which was as precise as using this blocking write method.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"What type of method do you use for emulator speed control (that is not based on the SourceDataLine's write method)?"
With every frame that is displayed, the time passed and the processed cycles are measured. It is then calculated how much time should really have passed for this number of cycles. The emulator then waits according to the time difference. E.g. if the emulator ran 20ms it should process 20000 cycles. Lets say it processed 40000 cycles then this should normally have taken 40ms, so we let the thread sleep 20ms. This works quite well.
"BTW: I fixed it by avoiding to allow the method to block. But insted take a 1 ms sleep if the buffer did not have enough room for the current "write"."
So you avoid the blocking by always ensuring that there is room in the buffer, right?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Joerg,
I tried your emulator (the Swing version) and it is nice, I should probably make a Swing version of JaC64 too, it is nice to be able to install locally. Do you know about the problem with Javasound in the latest version (Java 6?). It messes up the timing completely, at least for me.
Also, I would be much happier if you at least mention that you "inherited" from JaC64 in the beginning.
Best
-- Joakim
Hi Joakim,
the main Wiki page of the project, http://jmec64.wiki.sourceforge.net/, refers to JaC64 as the original base of the emulator. Meanwhile every class has been rewritten from scratch, so that JME/JSwing C64 is now completely different.
This I fear is also the reason for some problems with the sound as my new SID implementation is not as "C64 compatible" as yours in JaC64 :-(. Can you tell what sound problems you encountered, as with most C64 programs it worked fine with JSwingC64 on my machine?
The problem is when the C64 emulator is synched using the write function that is supposed to block for a very short time (the time that it takes to get enough space in the buffer). But in Java 6 it is not the case, it can start blocking for a very long time. I got this problem when using your emulator (The JSwingC64 with the latest Java).
Thanks for the quick answer. You refer to the SourceDataLine.write method, if I get it right. Is there a way to avoid this sync problem? I indeed have the problem that sound is not perfectly in sync.
Hi Joakim,
for the sound issue I created a bug and I already have an idea how to solve the problem: Passing data to the DataLine object could be done in a separate thread. This thread won't bother if it is blocked for a short period. As writing to the DataLine object is at the moment also used to keep the emulator work at the original C64's speed, this implementation OTOH requires that the emulator speed is throttled in another way. But that is no problem as my classes already contain such code.
Regards,
Jörg
I guess that should work fine. What type of method do you use for emulator speed control (that is not based on the SourceDataLine's write method)? Just interested, I have tried a few myself, non of which was as precise as using this blocking write method.
"What type of method do you use for emulator speed control (that is not based on the SourceDataLine's write method)?"
With every frame that is displayed, the time passed and the processed cycles are measured. It is then calculated how much time should really have passed for this number of cycles. The emulator then waits according to the time difference. E.g. if the emulator ran 20ms it should process 20000 cycles. Lets say it processed 40000 cycles then this should normally have taken 40ms, so we let the thread sleep 20ms. This works quite well.
"BTW: I fixed it by avoiding to allow the method to block. But insted take a 1 ms sleep if the buffer did not have enough room for the current "write"."
So you avoid the blocking by always ensuring that there is room in the buffer, right?
BTW: I fixed it by avoiding to allow the method to block. But insted take a 1 ms sleep if the buffer did not have enough room for the current "write".
Yes, that is correct! And that makes it possible to synch with sound if desired (so that I do not need to count any cycles explicitly).