ChanServ changed the topic of ##yamahasynths to: Channel dedicated to questions and discussion of Yamaha FM Synthesizer internals and corresponding REing. Discussion of synthesis methods similar to the Yamaha line of chips, Sound Blasters + clones, PCM chips like RF5C68, and CD theory of operation are also on-topic. Channel logs: https://freenode.irclog.whitequark.org/~h~yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ej5>
now i just need to figure out how to release it lol
<ej5>
maybe Lord_Nightmare has some ideas.
<Lord_Nightmare>
If you want it to get out there, I can make sure it does get out, but...
<Lord_Nightmare>
It might be better to just email it to the mamedev.org code submisson address and it will get included in MAME most likely, and i'm sure it will find its way out somehow.
<Lord_Nightmare>
(its one of those phenomena which its best not to ask too many questions about.)
<ej5>
sounds good
<Lord_Nightmare>
The MAME team doesn't distribute roms, as that would be illegal.
<ej5>
right, of course not.
<Lord_Nightmare>
speaking of firmware 2.02...
<Lord_Nightmare>
there was someone on twitter, i forget exactly who, who had a card with firmware 2.01 on it
<ej5>
interesting
<Lord_Nightmare>
if that short 'secret' test code which is in mask ROM on the chip (outside of the normal 0x1000 of ROM) allows the ROM to be dumped digitally...
<Lord_Nightmare>
then we could get that too
<ej5>
sadly it does not, it's designed to coordinate with external ATE hardware
<Lord_Nightmare>
i'd love to know what the sum16 is for the 2.01 code (and the 1.0x code from the original sound blaster, including the killer card proto)
<Lord_Nightmare>
do you have a verified copy of that test ROM btw?
<ej5>
dumping without decapping may still be possible but i'd have to reverse engineer the 80c51 a bit further
<Lord_Nightmare>
i'm curious if it is the same on all 80c51s of the same vintage
<Lord_Nightmare>
and manufacturer
<ej5>
hard to say. it's as verified as i can get since it was obtained optically
<Lord_Nightmare>
ah
<Lord_Nightmare>
does it make sense?
<ej5>
well, somewhat
<ej5>
it does lots of copying back and forth to I/O ports
<Lord_Nightmare>
another thing i was wondering is: if the exact number of cycles that the code to display the copyright string is known, and the code will just bang whatever it points to out the io port...
<Lord_Nightmare>
then that can be abused to dump the ROM using glitching
<Lord_Nightmare>
by glitching it so the comparison which ends the copy loop fails
<Lord_Nightmare>
and then it should go on and dump the entire ROM out as a giant string
<Lord_Nightmare>
i'm not sure that will work as i don't know the exact specifics of the string mess
<Lord_Nightmare>
does the mcu actually DUMP the string?
<Lord_Nightmare>
or do you have to UPLOAD the string to it and it will only 'unlock' if it gets the correct string uploaded?
<ej5>
hmm, that's an interesting idea
<Lord_Nightmare>
if you still have a few ct-dsp 2.02 PLCC chips lying around, its worth a shot
<Lord_Nightmare>
and if it works, i'll bet it also works on 2.01
<Lord_Nightmare>
i'm curious what creative fixed between 2.01 and 2.02
<ej5>
2.02 has no DSP copyright command
<Lord_Nightmare>
probably something stupid
<ej5>
just a version command that returns 2 bytes
<ej5>
but
<Lord_Nightmare>
ah, so that's a dsp 3.x/4.x thing?
<ej5>
perhaps there is a way to abuse the MIDI commands. hmm
<Lord_Nightmare>
or that command which plays back from RAM? but that plays from 8051 ramspace, not romspace
<Lord_Nightmare>
harvard arch bites again
<ej5>
yeah
<ej5>
hmm, actually the DSP version command could work
<ej5>
it does a mov dptr,#dsp_version (since the version is stored in program rom)
<ej5>
then later it uses movc a,@a+dptr
<ej5>
so it may be possible to get it out 2 bytes at a time.
<Lord_Nightmare>
if we can control dptr somehow
<Lord_Nightmare>
or make a jump fail in a very creative way
<ej5>
glitch the clock right at that instruction
<ej5>
so that it skips it, and dptr is just 0
<ej5>
hmm, doesn't help much unless you interrupt the checksum command partway through
<Lord_Nightmare>
if the code 'before' it loads the dptr with something user controllable and we can make it skip both the RET and the mov dptr,#dsp_version instructions as NOPs
<Lord_Nightmare>
then we could repeatedly do that and dump the entire ROM 2 bytes at a time
<ej5>
it would be easier to glitch the cjne in the checksum routine
<ej5>
so you'd get the contents basically one byte at a time, summed to the previously recorded contents
<Lord_Nightmare>
so glitch the cjne once, or glitch it every time?
<ej5>
send dsp checksum command->delay n clock cycles->glitch cjne so it skips->read byte->increment n
<ej5>
so you get location 0, then location 0 + location 1, location 0 + 1 + 2, etc
<Lord_Nightmare>
oh!
<Lord_Nightmare>
that means you need to glitch it once, then twice, then 3 times, then... etc
<Lord_Nightmare>
eventually 0x1000 times
<Lord_Nightmare>
the glitching isn't necessarily consistent
<ej5>
yes
<Lord_Nightmare>
but if it can be made consistent, or a way of doing it which won't blow up the chip is found...
<Lord_Nightmare>
clock glitch by halting the clock completely i don't know if that will work on a cmos 80c51
<Lord_Nightmare>
clock glitch by bringing the clock to 3ghz or so for like 5 cycles might work but it may end up with the pc in an inconsistent location
<Lord_Nightmare>
reset glitch may or may not work depending on whether intel added some filtering to the reset pin
<ej5>
yeah i was thinking vcc glitch
<ej5>
but who knows
<Lord_Nightmare>
the mc68705p3/p5 did not have any filtering but the mc68hc705c4 added filtering to the reset pin
<Lord_Nightmare>
reset glitching on the old nmos 68705 parts is so stupidly easy you probably would do it by accident
<Lord_Nightmare>
if you power up the device with the reset pin held to 5v/vcc it starts in a glitched state
<Lord_Nightmare>
and will often be happily spitting its ROM contents out one of the buses
<Lord_Nightmare>
until you actually pull /reset low
<whitequark>
lol
<Lord_Nightmare>
i think you have to be pulling one other pin into the NUM state though
<Lord_Nightmare>
C3 tied to 9v maybe
<Lord_Nightmare>
i forget
<Lord_Nightmare>
i have notes somewhere
<ej5>
heh
<Lord_Nightmare>
NUM is the non-user-mode 'debugger connection' state
<Lord_Nightmare>
it wasn't documented except in one place
<Lord_Nightmare>
its intended for connecting a 68705 to an in-circuit debugger
<andlabs>
if ( cfg_suppressopeningsilence ) // ohcrap
<andlabs>
- kode54
<Lord_Nightmare>
the security bit is supposed to disable NUM and it does... if you correctly pull /reset low briefly on startup
<kode54>
just a nonsense comment
<Lord_Nightmare>
if you don't do this, it gets into a glitched NUM state REGARDLESS of whether the part is secured or not
<kode54>
basically, skipping startup silence involves spinning the emulator until it starts to produce audio
<Lord_Nightmare>
this is how the MAME guys were able to dump almost all of the taito 68705 security chips
<kode54>
then saving the actual audio it produces for later
<Lord_Nightmare>
so 68705p5 security is just totally completely broken/useless
<Lord_Nightmare>
68705p3 doesn't even have a security bit
<Lord_Nightmare>
it was crudely bolted on for the p5
<Lord_Nightmare>
and it shows
<Lord_Nightmare>
MAME team also discovered that at least one group of pirates was able to extract the arkanoid 68705 code
<Lord_Nightmare>
so its possible people knew about this glitch back in the day
<Lord_Nightmare>
in fact, i'd say its likely
<Lord_Nightmare>
also interestingly, pirates were able to extract the 8751-88 code from super qix (japan version), and we don't know how they did that.
<Lord_Nightmare>
nowadays there's a fairly easy procedure to deprotect the 8751 devices by painting nail polish over the eprom array but not the security bit, and uv-erasing just the bit
<Lord_Nightmare>
since nail polish blocks UV
<ej5>
was it an 8751 or 8051?
<Lord_Nightmare>
8751-88
<whitequark>
Lord_Nightmare: that's not rocket science
<ej5>
i bet they independently figured out the nail polish technique
<Lord_Nightmare>
that's not unlikely
<whitequark>
it's kind of obvious especially if you spend all days UV erasing chips
<whitequark>
and it's not like optical microscopes got any better since then
<whitequark>
probably worse *looks at amscope shite*
<ej5>
haha better than the crap that i have on my bench
<whitequark>
ej5: i got my mirror replaced by a guy who professionally repairs microscopes, with a new mirror from an amscope distributor
<whitequark>
he also aligned it
<whitequark>
guess what
<whitequark>
the *actual frame* is assembled such that you *can't* align the mirror completely
<whitequark>
it's out of plane or something like that
<whitequark>
still need to get it back... soon
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xyz39808 has joined ##yamahasynths
Xyz39808 has quit [Client Quit]
andlabs has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
<andlabs>
so can anyone here describe the strm and wsr (wonderswan?) music rip formats
<andlabs>
or any players for them
<andlabs>
okay the strm is from DS games
<andlabs>
oh, vgmstream ok
<andlabs>
okay well that settles that
<andlabs>
just one file left - the wonderswan one
<andlabs>
not sure what will open it, if any
<andlabs>
so... yeah, can someone explain what players or player plugins can play .wsr wonderswan rips