The Digiblaster is supposed to operate off the printer port, and I assume it outputs any value written to the printer port with bit 7 inverted, but, the (Plus) firmware writes a #7F to the port at startup. This would infer that the Digiblaster is always outputting the full voltage value #FF at all times until some Digiblaster software is run or the printer port is actually printed to??? Am I right, and if so, how do you think it is possible to mix this value with the other channels (from an emulation perspective) without the sound generally being crap when the Digiblaster is turned on.
I don't know about the bit inversion part, but if I understand what you're saying I would think this isn't going to produce any sound? Because, again maybe I've misunderstood the operation but the voltage must change to move the speaker cone, and so a constant voltage will just make the speaker sit in a single position. That may not be good for the speaker but you certainly wont hear anything except perhaps when you first plug it in or turn on, for a split second.
Surely the solution is to simply write 0x00 to the port before turning on the digiblaster? You could also modify the plus firmware so it doesn't do the write (perhaps use FW3 or a custom cart image).
In an emulator surely you could just ignore the first write to the port if using a firmware image that has the bug? Or even just for any firmware, because it wont make much (audible) difference to lose the first write even if it's valid.
From V3 schematic, you can see that there are nothing else than a R2R resistor ladder to do the digital to analogue conversion.
Also, there is a high pass filter between the resistor ladder and the output. So the voltage will end being 0V after a delay, whatever the constant value put on the parallel port.
So, from the emulation point of view, you just need to emulate the low pass filter (simple 1st order RC), and except a 'plop' sound at start or reset, there should not be any constant high voltage on the sound output.
It appears to happen on every firmware version, not just the Plus. I'm sure it wouldn't hurt to simply ignore the first #7f written on reset, but that does require some extra logic. If I was simply adding the value to the wave it wouldn't particularly be a problem but may reduce the overall volume per channel since I'd have each channel at 1/4 maximum volume. JavaCPC appears to only enable digiblaster when the AY channels aren't enabled and playing sound.
As gerald says, there's a DC blocking capacitor in series with the signal output, so a constant voltage will only cause a momentary current flow through that path. There's also a minimum 30K resistance between the DAC and ground, so worst case you're looking at *less than 0.5mA* of current being drawn from the computer.
So, don't worry about it. :)
Well, that high pass filter is a little hard to emulate, I decided to ignore writes to port #EFxx from #05xx in the lower ROM. From this point, only writes to the printer can affect the DigiBlaster output, or actual DigiBlaster samples. The first section of Bordelik Meeting 4 plays through Digiblaster, but it has some serious clipping and undesirable noises. Is this the way it's supposed to be?
Quote from: Executioner on 03:38, 30 May 14
Well, that high pass filter is a little hard to emulate, I decided to ignore writes to port #EFxx from #05xx in the lower ROM. From this point, only writes to the printer can affect the DigiBlaster output, or actual DigiBlaster samples. The first section of Bordelik Meeting 4 plays through Digiblaster, but it has some serious clipping and undesirable noises. Is this the way it's supposed to be?
I can't remember if the samples are "unsigned" or "signed".
The Digiblaster is *very* simple to emulate:
Just map a device called "Digiblaster" to the emulated printer port.
Then just grab the written byte, and invert it:
(Pseudocode)
int audioByte = 0x0FF;
void writePort(int value){
audioValue = (value ^ 0x080) & 0x0FF;
}
int getAudio(){
return audioValue;
}
this 'audioValue' just send to your audiooutput.
If your output is stereo, send it to chan. A and B.
Edit: AmDrum works almost the same. Just that the audiobyte is not inverted here and the port is a different one:
int audioByte = 0x0FF;
void writePort(int value){
audioValue = value & 0x0FF;
}
int getAudio(){
return audioValue;
}
Edit 2:
Yeah, the song from 'bordelik meeting 4' demo has a few strange artefacts. I guess because not very clean samples.
I attach the song as WAV here...
QuoteI can't remember if the samples are "unsigned" or "signed".
I have read somewhere (not sure the source was reliable) you can use both but if you are forced to invert the "strobe bit" with unsigned samples (with software) , it s not an obligation with signed samples.
Quote from: Aeliss on 18:00, 30 May 14
I have read somewhere (not sure the source was reliable) you can use both but if you are forced to invert the "strobe bit" with unsigned samples (with software) , it s not an obligation with signed samples.
100% of all existing software which makes use of digiblaster, needs a signed byte....
Sure you can send an unsigned byte, too, but this will sound bad on a real digiblaster then ;)
Signed samples can be played directly on the Digiblaster since it effectively adds 128 to the sample to give it the range 0..255. To play unsigned samples, simply invert the top bit since the hardware re-inverts it. In the end, I have implemented a pseudo high-pass filter which simply counts the number of frames the Digiblaster has been at the same output level, and sets the volume to 0 after a few frames until something else gets written. That stops the reset frimware value causing all other sound to be crap since the Digiblaster output is ORed with channel B.