NGY

This looks like a neat "all-in-one” amp. Good for those who want "bigger sound" than their head unit can provide. I cannot judge though how good its subwoofer circuit is. If your main speakers are loud enough with the Sony, and the only thing missing is the good bass, I would rather go for a dedicated sub amp, something like this (or eventually, better). Beware though, that a few 100 Watts on a 12V car circuit means a few dozens of Amperes (!), therefore it would also call for dedicated, thick enough wiring directly from the car's battery (and/or, actually another, dedicated battery, also with some beefy buffer caps, next to the amp).

Yes, you do. Sub outs on head units normally meant for either active subwoofers or subs hooked on a power amplifier. You can also see it in the manual (see as well the other RCA audio outs for additional, externally amplified front/rear speakers): Sub amps require a lot of power, way more than the regular speakers, and normally there is not enough space in a 1 din head unit for such an amp. Even if it was feasible, as only a fraction of the buyers install subwoofers, it would be an excess feature, with no value to the vast majority of users.

Thanks for your enormous work Kevin! You "lit the light" so to speak - no, actually your analysis above is way more than that. It will take some time for me to read and digest everything, but way less time if I had to figure out all this on my own (if I ever would have been able to). So thanks again, and please forward our apologies to your family, for stealing you from them (or maybe they were happy that Dad was busy with some crazy stuff and kept quiet the whole day :-P ?)

Here you can download the SM of the MZ-R909.

I saw the same case once, although it was an MXD-D3 combo deck, not a portable. The solution was cleaning the two sensor microswitches (i.e., the prerecorded media detector and the writeable media read-only tab detector switches) with some contact cleaning/lubricating spray, then the problem disappeared.

Haha, you expect too much from me :-) - but yes, I will spin on this. Sadly my brain has trouble with thinking and "seeing" in hex (I had a mate at the university, who actually did assembly level programming in hex, all in his head - I mean he did not take any notes, only jotted down the final code when he was ready ... - I am quite the opposite).

Now you need to explain it to me :-) . In theory, I can imagine, that this is key. Seeing the pattern and compare it to the periodicity of the SPDIF serial data stream (with your kind explanations above) though I still cannot see, how. So here are those exceptions are at 0x0717, 0x07e8, 0x081d, 0x08e2, 0x091d, 0x09e2, 0x7f17 and 0x7fe8 - that is eight in total, that goes well with the "bit management" description part of the original article. More precisely these addresses with the respective values there: 0x0717 - 0x11 0x07e8 - 0x10 0x081d - 0x13 0x08e2 - 0x12 0x091d - 0x21 0x09e2 - 0x20 0x7f17 - 0x11 0x7fe8 - 0x10 OK, I see something in the address, these are in pairs (sort of), like ...17, ...e8, ...1d, ...e2 - this is cool (even if I don't yet understand the other part of the addresses, i.e., 0x07... to 0x09... but then jumps to 0x7f...). As for the values, I could explain (I think) most, but these ones: 0x13, 0x12, 0x21.

Thanks Kevin! This was the key sentence for me. And yes, everything you wrote does make sense. Now I can go back and break my head over the mechanism of the FSM at those "interesting" addresses/blocks. (Those minor, singular oddities might still be just pure errors of an aged silicon, although ~20 years time is not that much for an EPROM)

I must confess I need someone to explain this subframe / status block structure. I cannot visualize that "at Bit 30" there is another block (of another 32 bits), of which "Bit 2 is the copy bit". Apologies for the dumb question, but how can one "split a bit" into another 32 bits? I am missing here something bit big time (no pun was intended :-) ). (For reading the .bin file I am using this free hex editor, it's a neat little program that helped a lot in visualizing the general structure of the ROM FSM, as well as finding the "interesting"' parts.)

Yeah ... I should have read the whole thread from the beginning. Then I would now that you could be our rescue here, in understanding those exceptions. No intention from my end to reinvent the wheel :-). I am sending over the file to you, Kevin, also with some of my notes we exchanged with zedstarr in PM recently, if that makes any sense (I am totally an outsider in this area ...).

Certainly there should not. Neither the board, nor the EEPROM "program" should be considered as one's particular intellectual proterty, because the technologies used there are well known and public (i.e., a ROM based implementation of an FSM - Finite State Machine, for finding and altering certain bits of a serial data stream). Matter of fact the ROM content was never published, nor was the cited "little Pascal program" either, but looking into the EEPROM dump kindly provided by zedstarr there is nothing fancy or unique there. Besides some very interesting anomalies found in the otherwise plain pattern (there is no "program code" or anything such there) - whether those are related somehow to this SCMS thing, or just pure errors (or maybe some "low level" protection for the ROM content) is to be figured out somehow. It is great though that someone pioneered to read the content of the EEPROM - many thanks again to zedstarr.

I am glad to see that early unit coming back to life. Yes, this P/N is a 2A fuse. Rated 2A, while the "50" stands for the 5A fusing current. See the extract from the datasheet: With that, you can just buy any microfuse that is rated similarly, and has the same form factor (i.e., 3.2×2.5mm footprint). EDIT: be careful when soldering the new fuse. You need to use an old style solder (before RoHS) with lower melting point (around somewhere 220...240 °C), and do not heat the fuse for more than a few seconds, keeping a short break (say a minute) between soldering the two contacts.

You have some good points to begin with. If the faulty one draws zero current, then it might just be the microfuse at the beginning of the power circuit. Look for PS401 on page 64-65 of the SM. This is a 2 Amp fuse, measures normally as a short circuit (i.e., a few milli-Ohms resitance only). As for the battery thing: your pack might have just discharged below the treshold level set by the device, or died eventually. Normally, a fully discharged - or even a fully dead - battery should not cause any damage to the electronics behind (except for the acid leaking and oxidizing the contacts or other parts). (You can probe your battery pack: try to charge it from your lab PSU, set at 6....8 Volts and 50...100 milli-Amps, for 20...30 seconds. Observe if it gets hot. Then measure again the voltage shown by the battery. If it is other than zero, repeat the process until you see min. 3 Volts - keeping always an eye on the temperature. In case your PSU does not have current limiting function, you can use a ~100 Ohm resistor in series with the battery. Now, if your battery happens to take the charge, you can try to continue charging it in the unit, with the good board.)

Hi Paolo, Is your power adapter is one of those "bulky" ones, with a transformer inside? (I guess it is, because when the MZ-1 came to the market switchers were less usual.) If so, then the 18V when measured unloaded seems normal to me. (This thread is discussing a similar case, although the portable there in question is a much younger one.)

I guess the core thing - the magnetic alloy, that ultimately "holds" the data - remained the same. At least I have not yet seen any indications that laser settings (wave length as well as emitted power) would have ever been different since the first commercial MD decks appearing on the market.

Yeah, translations from Japanese to English might be misleading sometimes. My interpretation is that this "lube" is not necessary anymore, because it is "built into" the top side protective layer. But as Kevin pointed out: with or without lubrication it should not impact the recordability of an MD disc.

I got you. The point I tried to make was that the early days "CD-rot" has possibly nothing to do with the above mentioned recording problems on some NOS recordable MD-s - for the different materials used.

MD-s and CD-s are two different things. Layers that hold data on recordable minidiscs and regular CD-s are two very distinct materials. Former one is a special magnetic alloy, while the latter one is a pure reflective layer of a thin metal film. Yes, some makes of early CD-s have shown oxidizing, when the plastic encapsulation was done cheaply. As for premastered MD-s, yes, they are essentially CD-s with different encoding and track structure, while the reflective layer and the read out technology are practically the same. Yes, they might be subject of the same disease. However, we don't want to record on a premastered MD, do we.

I tend to lean towards that "lubricant" is more of a solid form than of a liquid or gel-like. Something similar to the teflon coatings on the "non-stick" pans. Certainly even that could deteriorate over time, although I still owe myself an explanation, how - besides when exposed to excess heat and/or damp. (That coating on the back of the discs were claimed as a sort of silicone-based compound, and those are generally fairly stable stuff.) I second to Kevin, none of my MD discs I have ever bought (first one back in early 1998 or so) had any trouble with recording onto, even these days, but one or two (out of ~1400-ish).

Yes, I am, out of sheer curiousity - thanks in advance. I like these smart little technical inventions. A copybit stripper can be very handy for those who regularly use MD (also DAT) gear in their daily job, and not only for making copies. For many years I spent in the MD world (as a pure hobbyist) I really never sported to have such a device, because any time I got to duplicate a particular recording I could do it with the help of my W1 (and those were even "true 1:1" copies, made in the digital domain), and for other purposes I would have not needed one anyway.

Hi zedstarr, Welcome to the forums. Great job on getting the ROM image - any chance you'd share the file? Say in private, if you feel inappropriate doing it publicly. Thank you

Correct. If the source device has a TOSLINK digital audio output, you can record that audio with your MZ-G750 digitally. Beware though the SCMS rules/limitations.

You can use either a 3,5 mm jack / TOSLINK optical cable, or a 3,5 mm jack to TOSLINK female plug and a regular TOSLINK/TOSLINK optical cable: or

Well, we tried it at least. It needed more patience from your end, and you did a good job in getting back with exact measures, etc. Many people just don't bother coming back and telling what happened, while any information, even dead-ends could help future readers. Back to Jonathan's post for a second: I took a grab on the text with an on-line translator, and what I understood is that his J3000 did not want to turn on, some segments on the VFD lit briefly, but the machine did not do anything beyond. He found the reason was IC309 being faulty, with the 3.3V system rail being shorted to ground internally. I feel pretty much convinced - as your 510 does have the necessary power rail voltages and lot of functions (turning on and off, disc loading, etc., etc.) do work - that your's is a different case. Nevertheless, you may want to close that thread too for peace of mind, and measure the voltages on that regulator (as well as checking the one in your 510 if it shows that overheating symptom too). Some of it's signals are sensed by the MCU, it may worth a few minutes to see if all is there.

Can you be a bit more specific? What is the "it" you're referring to? The TOC writing problem, or the dark display, or else? Sadly I don't speak French at all. From what I see on the pictures, Jonathan dealt with a faulty power regulator IC, and the symptoms in his case - if I got it right - don't seem to have much similarities with your case (either the dark display, or the TOC writing problem, the latter being 99,99% sure as not a regulator issue). Honestly, my limited knowledge already ended with the conclusion above, and - if your 510 was in front of me - taking that repair attempt any further I could/would only rely on swapping the boards with known good parts, to see if something pops out - either to support the conclusion, or to discover something totally different I possibly overlooked.