kgallen

OK, so blocks 0x46 and 0x47 for the PARITY were a bit more hairy. But we're getting the hang of this now, so this is getting easier! Also finally we bump into the Y preamble detection! Remember we have to do the operation of blocks 0x44 thru 0x47 again on Sub-frame Y. And you all thought this stuff was easy! We're only 2/3 of the way there yet! You get another bit - a big bit! - of my table as explanation for blocks 0x46 and 0x47 handling PARITY. Note we'll stay in state47 pushing in to out until we detect the Y preamble pattern (which should come along in the next 8 bi-phase bits). Note some of the 0x47 entries I've commented as "illegal" will be used to propagate the incoming bits of the Y preamble through to the output unchanged. After matching the Y preamble we'll exit to state48. (Edit to correct a couple of the state47 COPY/PARITY action comments). Hold on, I'm sure there must be something more important I should be doing...!

Indeed - only the other week I added new logic to generate a 2048kHz network time reference output from our current chip in development...

Changing the COPY to a binary 1: block 0x45 is probably best summarised by sharing the relevant portion of my ever-growing table, with comments: So that means blocks 0x46 and 0x47 will deal with correcting the PARITY bit if needed (if we changed the COPY bit). What is also "clever" here is we don't need to remember what went out as the COPY bit (we have no way of recording this) - but the information we need is there in the historical biphase information. Remember we have an 8 bit shift register which still has the incoming COPY biphase bits in there...

(Edited to correct that the COPY bit is handled by states 0x44 and 0x45). For those playing along at home, this is what I'm currently considering in states 0x44/0x45. In state 0x44, the first biphase bit of COPY is in bit 0 of the SR. In the incoming frame, COPY could be a binary 0 or a 1. We want it to be a 1 in the output SPDIF. Since the bits are biphase, we can have the following scenarios as we clock in each half of the COPY bit. Remember each biphase bit of COPY needs to go to the output on the next clock cycle - we can't wait to see both halves of the COPY bit to make a decision. Seems it all works nicely for us... Let's call the the biphase parts of the COPY bit 'a' and 'b'. At state 0x44, we have 'a' in bit 0 of the SR. We have 4 scenarios for the biphase bits of COPY, but at this point in time we only have 'a' to look at. The polarity of the (incoming) COPY bit 'a' phase will depend on the polarity of the 'b' phase of the previous bit, the U bit, since biphase mark requires the encoding to transition the bit polarity. We thus have the following scenarios: The cute thing we see from the above diagram, is that if we have just shifted in 'a', we can shift out the same polarity to the output regardless of whether we need to change COPY or not. We can make our invert decision on the 'b' phase of the COPY bit (state 0x45). Convenient!!! Bear in mind that in SR bit 1 we have the previous biphase bit in time - the 'b' bit of the U bit. Block 0x44 does a plain out=in as we require - so it's "special" in that it's dealing with 'a' of the COPY bit, but not special in that it is just replicating in to out :-) So considering SR[1]=U 'b' and SR[0]=COPY 'a', we can see that valid combinations for biphase - which requires a transition - on SR[1:0] are 01 and 10. The values SR[1:0]=11 and SR[1:0]=00 would not be valid for the 'b' phase of U and the 'a' phase of COPY to be compliant biphase. So the addresses of interest are the "odd" pairs of 0x4401 and 0x4402 (and the same for the rest of the 256-byte block since we don't know/care what SR[7:2] bits are, but we want the same behaviour whatever). So we get the values of: SR[1:0]=01 -> 0x8b - thus a 1 will be output on ROM Q[0] as required and SR[1:0]=10 -> 0x8a - thus a 0 will be output on ROM Q[0] again as required and these will be the 'a' phase of the COPY bit clocked to the SPDIF output. That's block 0x44. Phew! On to block 0x45 where we actually determine the binary value of the COPY bit by determining the polarity of the 'b' bit of COPY. Block 0x45 has a different data pattern to what we've seen before: 8d 8d 8c 8c ...

I'm a little lost now as I expected in block 0x42 to find some operation related to the COPY bit. 0x42 is state 0x10 plus 50 (dec) biphase clock cycles which would put us pointing at the U bit prior to the COPY bit in Frame 2 Subframe X. Also since this same operation needs to be performed in the "Y" subframe I though the designer might hunt for preamble Y then run this same count-50 loop again. But I don't see, yet, any code that matches preamble Y. Maybe it does a brute-force count over the bits to do this - probably so as there is no mechanism in this FSM style to flag that Y (versus X) has been done and jump back to the preamble Z hunt phase. However blocks 0x45 and 0x46 look more interesting... The quest continues... My story so far:

v--no match--| v-no match--| v-no match--| -> state7 ----------|--match Frame 0 Z preamble--> state8 ---------|--match Frame 1 X preamble--> state9 ---------|--match Frame 2 X preamble--> state10 -> TBD

For example, the first 7 address blocks (0x00??-0x06??) just copy SPDIF in to out. This is so we can shift in 7 biphase bits of SPDIF. At address block 7 (0x07??) is where things get interesting, because we can now start looking for the Z preamble as we've shifted in 8 bits. And yay, at 0x0717 and 0x07e8 we have our first "exceptions" which will move us on to track towards the COPY bit. Also note in block 7 that the background fill is the same in block 6 (0e and 0f). This means we loop in state 7 waiting for the Z preamble to appear before we jump out to the next phase. So our state machine so far is: v--no match--| reset -> state0 -> state1 -> state2 -> state3 -> state4 -> state5 -> state6 -> state7 ----------|--match Z preamble--> state8 -> TBD Matching the Z preamble is the process of "gaining frame alignment" (that I may have mentioned early on in this thread). The trick here is that the preamble sequences are carefully designed so that they can't be "simulated" anywhere else in the data stream - noting that of course the audio data can take any binary value. This will be why they've not used true biphase for the preamble signatures - because the preamble patterns can't be emulated in the rest of the data stream that is true biphase (excepting crosstalk errors of course, we won't go there for this project, but I bet the chips in the MD machines do account for this). If it were, we could gain "false frame alignment" by seeing the preamble pattern in what is actually payload data. Being from a telecoms background, I bet @zedstarr can relate to this (e.g. ITU-T G.706, 2048kb/s PDH basic frame alignment).

Note there are many ‘state chains’ of boring 256-byte block numbers where the ‘state’ part of the number just increments. These will be to ‘step through’ all of the other data in the frame (like the audio data, frame 1 etc). e.g. states 0x10 to 0x43 (0x44 too, but we'll come to that below, because it's "special" whilst not being special...)

I'm not sure about how to represent this information. For now, I'm using an Excel sheet in a "traditional" FSM format that is a bit like one would use when designing the next state logic for an FSM (ROM or otherwise). I'm not sure if this is helping me yet, but at least I can capture some of the data (there are some bin2hex formula behind some cells). Note the "exception" addresses quoted by @NGY yield a flip in the SPDIF output polarity.

Regarding the Z preamble, I think I got slightly mislead on the polarity. It seems that whilst these preambles are not "true biphase" they still adhere to the ongoing polarity of the biphase data. So 0xE8 where the bits are flipped is 0x17. So it seems our machine needs to "look" for both SR=0xE8 and SR=0x17 for Z preamble. Similarly X preamble is 0xE2 or 0x1D. Your address numbers are starting to take some shape, huh?! :-) You ok with hex to/from binary? Convert one hex digit to 4 binary digits. (Why we use hex!) ps, hope I'm not coming across as "cocky", I don't know the answer either, but with your info it's also helping me piece together this thing. I would not be this far without the input from you both. As I'm typing these replies, I too have some "aha!" moments of further discovery!

I'm still working on this too, but this is my hypothesis. The background fill in the ROM (i.e. all locations before we do any "magic") should be 0x00 in even addresses and 0x01 in odd addresses (at least the bottom 256 anyway). If you programmed a ROM like this and plugged it into the circuit, then it would just replicate the SPDIF input onto the output. This is because ROM A[7:0] would just "point" at one of the bottom 256 locations. An value in the SR of %???????0 (where ?=don't care) would output 0 on D0 (the SPDIF output) and %???????1 would output a 1. Since in the ROM, D[7:1]=0x00, our "state" stays at "state 0" - so ROM A[14:8]=0x00. So like this we are "stuck" in one 256-byte block of the ROM. When we want to do something special, we need to "jump out" of this boring 256-byte table into another 256-byte table that has more interesting numbers in it (well it will still be mostly "background" as usually we still want to replicate SPDIF input to output). So to do this "jump" we have a more "interesting" value in one or more entries of our 256-byte "block". This will move our "state" (A[14:8]=previous clock cycle ROM Q[7:1]) to somewhere else where more interesting things can happen. For example, an interesting number in the SR would be the Z preamble. This is binary pattern %11101000. In hex this is E8. So at some "interesting" addresses 0x??E8 (??=don't know yet!) we will find a more interesting number that takes us somewhere else. We might also be interested in the X preamble which is 0xE2. With that little teaser I'll let you continue... :-) (compare to the address list in your previous post).

Those minor singular oddities are the state changes (or output polarity flips if D0). Key to the operation of this FSM :-)

From the beginning the SR is reset (0x00). Then imagine biphase bits coming in. We need to replicate SR bit 0 on the output whilst holding our state machine in state 0 (so A[14:8]=0). This means we’ll rattle around in EPROM addresses 0x0000-0x00FF with EPROM D0 generating the output where ROM contents D0=A0 and D[7:1]=0x00 (although looking at the bin, bit 1 is a 1 as we see 0x02 and 0x03 in there. Hmmm... so I think this means we’ll end up rattling around ROM block 1 at 0x0100-0x01FF) However when we see the preamble Z pattern on ROM A[7:0] then our FSM will spring into action and we should jump to another 256-byte block (==state in this context) to start hunting for the COPY and PARITY bits... Luckly preamble Z has one fixed pattern as it’s not in true biphase (it seems?). ETA: it’s all coming together now. I wondered why the User Bit is included in the table from @zedstarr above. It’s the bit before the COPY bit. Thus it gives us the biphase polarity information we need to determine how we form our replacement COPY bit in biphase. Clever...

One other horror I’ve just thought of, is the output stream is also biphase. This means that for every input bit pair we need to output a biphase bit pair. This is fair enough, once we see preamble Z we just use the ROM contents to replicate every bit on the output. However there is a complication if we flip a bit: converting a COPY bit 0 to a 1 requires us to output 10 or 01 in biphase. The style will depend on the polarity that has come before. Likewise if we invert the PARITY bit we might need to output a binary 0 or a 1 which in biphase could be any of the patterns 10, 01 (for a 1) or 00 or 11 (for the 0). However flipping the COPY bit will flip the biphase polarity and the PARITY bit by chance is the very next bit in the subframe, which will flip the polarity back, so we don’t get into the situation of needing to biphase invert the rest of the data stream.

Looking back at some of the references I posted before, the SPDIF format is: - biphase mark for all bits except the preamble (sync) bits. The Preamble biphase bit sequences (4 bits, 8 bits of biphase) are shown in the diagram excerpts above from @zedstarr So for the non-sync bits: binary 1 = transition halfway through bit, so Shift Register will have 01 or 10 in even/odd bit-pairs; binary 0 = no transition, so Shift Register will have 00 or 11 in even/odd bit-pairs.

OK, one needs to read the article desciption a few times looking at the frame diagram. This structure is carrying more data that just the audio data. There are 192 "frames" and each frame has two "subframes" which will be the left and right audio channels. A subframe is 32 bits: 4 bits of preamble, 4 bits of "aux data" (supports 24-bit audio samples), 20 bit audio sample, the 4 other bits, 2 of which are of interest - bit 30 which is one bit of a multi-byte "Consumer Channel Status" and a Parity bit (even or odd?). Before each audio data sample is this preamble burst, which serves several purposes like telling us if we're at the start of the 192-frame sequence - we look for preamble "Z" (4 bits, but biphase code=11101000), then we know we are starting Frame 0. Frame 2 is special for us here, because the non-audio information for that frame contains byte 0/bit 2 of the "Consumer Channel Status" which is the COPY bit we are looking for. It seems this same data is replicated in both subframes. Re the "bit 2"/"bit 30" thing: every subframe has 32 bits. Bit 30 is the Consumer Channel Status. But the CCS is multiple bytes long, so it's conveyed over the frames, 1 bit at a time - 1 bit per frame (repeated twice - in each subframe). As there are 192 frames, this would mean the CCS could be 192/8=24 bytes long. COPY is CCS byte 0/bit 2, so we need to wait to frame *2* to get byte 0/bit 2 of the CCS, since the CCS is conveyed 1 bit per frame in bit 30. Make sense? CCS is multiple bytes long! The second byte for example has that Category Code field. We're lucky our COPY bit is in the first byte otherwise we'd need to look further into the frame counts! So loosely, the process for the machine will be: - Find preamble Z - SR will hold [D7]11101000[D0]. This means we're at frame 0. - We then have to count through a load of bits (actually 2x due to biphase) to skip past F0/SF0,F0/SF1,F1/SF0,F1/SF1 - On arrival at what we think is Frame 2, we should see preamble X, so the SR should hold [D7]11100010[D0]. Then we have to skip along to bit 30 (biphase 60/61) to find our COPY bit. - Then we have to check the COPY bit. If it's already a 1 (=COPY allowed) we have nothing to change, just keep on passing the SPDIF through unchanged - COPY and PARITY bits. If the COPY bit is 0, then we need to flippity-doo-dah the COPY bit and flippity the PARITY bit too (if the COPY bit was already "correct" (i.e. a 1) then we don't change the PARITY bit otherwise we'd make it wrong). So actually we don't care what whether the parity is even or odd, we just flip it if we flip the COPY bit. If the parity was errored due to a transmission issue, then it's still errored! Lost the will to live yet? We're learning together (=me waffling on at random!).

It's not a dumb question at all, I need to get my head around that too, it's complex. Separately: Teasing apart more info from the circuit description: On the "block" of memory, our FSM "state" is the top address bits. The SR (SPDIF data) is the bottom 8 bits, so SPDIF data values move us around the least-significant locations within a 256-byte block. Our state machine states are the upper 7 bits of address, so a movement in the state machine hops us around between 256-byte blocks. So the "detail" within a 256-byte block will be a "response" to a moving low-level SPDIF bit pattern, and the FSM will "jump" us to another state in the machine by moving us to another 256-bytes block. This probably makes little sense, but as we start to get the hang of how this machine "interprets" the SPDIF stream, it might help! (Maybe...!)

Ignore the wiring twist between the ROM (IC8) and the register (IC9) - I can just make out the address lines are brought back into numeric sequence to the left of IC9. Also note from the information supplied by @zedstarr above (and evident from the schematic had I looked) is the data presented to the shift register (IC7) will be in the bi-phase format as per the SPDIF on the coaxial or TOSLINK line. I need to check what format is used, but it may be Manchester Encoding which is a mechanism to convey a clock (timing) signal along with a data sequence (and to avoid a DC voltage offset accumulating on a long capacitive line).

OK all, I'll take a look, but it won't be a quick job! For starters I'm not currently familiar with the SPDIF frame structure which we'll need to understand to work out where this machine is trying to take us. Seems I left some links in an earlier post, so my chickens have come home to roost and it seems I'm gonna have to read them! I'm not sure where we're going with this - for me the endgame would be to draw out the FSM states/transitions. If anyone is building this then the bin file provided can be used to programme an EPROM (given the required equipment!). If you want to have a try at reverse engineering this machine, this is the bit of the schematic that is needed along with the binary file provided above. Use a utility like this to convert the bin file into a more readable HEX dump. (Above from here) SPDIF comes into the shift register IC7 top right. This shifts in the serial SPDIF and presents the most recent 8 bits to the ROM (IC8) as address lines A0-A7 (A0 being the newest SPDIF bit). The 8-bit register bank, IC9, is the FSM "current state" and the ROM contents are the "next state logic" that decodes the "next state" based on the inputs of the last 8 bits of SPDIF presented on A0-A7 and the "current state" presented on A8-A14. For some reason, maybe PCB layout or maybe decode convenience, bits 3,4,6,7 are transposed which means we need to keep this in mind when working out the decode. There may turn out to be a good reason for this, but I'm coming cold to this so I don't know the reason, if any, yet. There are 7 bits of "state". This means we have at most 2**7=128 states in our FSM - a lot to decode but I guess most of them won't do anything except move to the next state. In IC9 the 8th register is just registering the SPDIF output (top left) and you can see this comes from the ROM D0. This means for all but 2 bits of the SPDIF stream, bit D0 in the ROM will be the same binary value as the SPDIF input on A0, so D0 of pairs of addresses will be 0 (even addresses, A0=0) or 1 (odd addresses, A0=1). This machine has to find and flip two bits: the COPY bit and a PARITY bit (so I understand). This means in one specific ROM location you will see D0 be the opposite to what we expect from above. There will be one other location that has the same "flip" for the parity bit. So let's look first for addresses where D0 is flipped to the background pattern. These should correspond to the two FSM states that fix our COPY and PARITY bits... Some of the text is hard to read above, but all 3 devices are off-the shelf from many manufacturers, so if you need to, consult the datasheets, for example: IC7 74xx164 IC8 27C512 EPROM IC9 74xx574 By the way, don't worry about addresses 0x8000-0xFFFF in the bin file - address A15 is tied off to 0 in the design (above), so we can only ever address the bottom 32KB of the ROM, 0x0000-0x7FFF. In the bin file you can see that the top 32KB, 0x8000-0xFFFF are all 0x00 - ignore it all. This design could have used a 27C256 32KB EPROM rather than the 64KB 27C512 shown above - actually the pinouts are compatible, so if you're building you could use a 27C256 or a 27C512...

EE Block Engineering. Now we’re talking! Did you ever go ‘over the top’?! Who am I kidding, of course you did! :-D

There should be one "juicy" section that finds then inverts the COPY bit (and another bit that inverts the parity to keep it consistent). The bulk of the rest of the values will be background "fill" that does "output bit=input bit, clock next bit". If you have a hex dump, maybe you could share small parts of any interesting sections here? Might be of interest to the earlier poster where I was trying to describe how such ROM-based FSMs work. Echo the thanks to @zedstarr (and forward posthumous greetings from GPT Beeston to GPT Liverpool :-D )

Other option, not a Tascam one but a "programmed" substitute... https://www.remote-control-world.eu/rc-for-audio-hifi-tascam-c-12_715/tascam-rm-mc1-replacement-remote-control-p-7084?currency=GBP&gclid=Cj0KCQiAvbiBBhD-ARIsAGM48bwu4INh5l_JYKIlImKRhpv8wNGfPPoGqw1bHr3oqPNHpHp0jcnrkk0aAmmuEALw_wcB

I'm looking for a Tascam RC-MC1 at the moment... (for Tascam MD-CD1). Anyone know if the RC-5 would work with this machine? (I guess there is a good chance it will work with the MD section as the IR manufacturer code will be right...) https://www.ebay.co.uk/itm/Tascam-RC-5-Mini-Disc-Remote-Control-Tascam-Original/363226779505?hash=item549200cf71:g:RVQAAOSwbwFeySdn

I doubt anyone is looking, but there is a Tascam RC-8 listed on eBay UK at the moment (at a moderately healthy price): https://www.ebay.co.uk/itm/Tascam-RC-8-Wired-Remote-Control-RC-Unit-for-MiniDisc/133446843259?hash=item1f120d3b7b:g:xzwAAOSwO5BeXtLn

For other readers who are wondering what we’re waffling in about, here is a Wikipedia article talking about one phenomena due to a manufacturing issue: CD bronzing A few months back I purchased a second hand Compact Disc that seems to exhibit the above. It wouldn’t read. It was an 80’s CD from the period and ‘Made in UK by PDO’ so quite likely from the cited Philips/DuPont manufacturing plant. I’ve not seen this particular phenomenon on an MD (I’ve a sample size of 2 for MD-CD though!).