kgallen

@zedstarr - sure, go for it. No pride in that code!

My 801 is very poorly since it seems to be missing (at least) the laser lens, possibly the whole laser. Some photos of that BU-801 next to a 1/10” rule(r) would be useful. I’m guessing the PCB pins are 1/10” spacing - but what about the left/right pitch? Assuming a suitable DRAM can be found these days a PCB for that module would be straightforward to design. Can you capture here the part number of the DRAM? It’s not fully clear for me from the photo - the line starting M5 I think it might be M5M416400CTP, 4Mx4-bit (note: no speed grade is evident from the markings on your chip, e.g. -6 or -7): DSAFRAZ0013654.pdf The more clear info you can post the better as good data on all this kit is virtually impossible to find. Whilst the data is with someone interested and knowledgable we should get it captured in good quality. Still love that setup. Kevin ps An MD801R sold on eBay here the other day. Had a disk read issue otherwise smart. Went for around 50GBP plus postage. Also from the same seller went a working Tascam MD-CD1mk1 and a mk2 and an MD-350. They went for pretty good money too (145GBP for the MD-CD1mk1) so someone out there is still keen on minidisc! pps Note for the future, other 4Mx4 DRAMs of 80ns or better access time from other suppliers, other than the Mitsubishi used originally, might well work. A datasheet comparison would be required to check key timing specifications, but there is unlikely to be anything unique about the Mitsubishi part. ppps From the MD-801R-mk2 Service Manual: NEC UPD4216400G3-80-7JD NECCS00623-1.pdf pppps The socket is Toshiba/KEL ICC04-20-350T but cut down from 20-way to 11-way for each side.

@zedstarr Thanks for the py, I like it! There were a couple of comment errors - also "...4-byte fill..." should have been "8-byte fill" (it changed!). Should be fixed in the uploaded C (and Tcl) above. Any more, let me know, I'm a stickler for correctness! :-D

@zedstarr - looks like you could knock us up a Python version of same... we'll find a language that is portable enough for everyone to have a play, sooner or later! Thanks for the 'bump' on the Blog :-D

If you can make use of it, here is the same thing in the scripting language Tcl. It's interpreted rather than compiled like C. You can get a Tcl interpretter here, but you have to "register" with ActiveState these days: Tcl Download The script: it's just a rehash of the C code provided above. elektor_scms_rom.tcl If you're on Linux you can almost certainly use wish or tclsh.

Here is some C code to generate a hex and bin version of the ROM. I'm no C coder and this C code is awful. Someone, please rewrite! I compiled this with gcc on Linux. I've no idea how to compile C on Windows, sorry. So use this code as inspiration for your own more worthy efforts! elektor_scms_rom.c I used tkd iff to check the hex output from this code matches the hex dump I generated from the bin file uploaded above by @zedstarr .

Fixed a couple of the Comments on state47 COPY/PARITY and improved a couple of other Comments in the Table pdf above if you've already downloaded it and are scratching your head on some of my documentation errors...

You have to "fill in the blanks" for me on the 0x7? stages to make sure I didn't miss anything! :-D Just look at the technical insight in your other posts - you would have got there.

Right I'm being lazy now and jumping to the endgame from what I see in the 0x7? blocks. This is what I "promised" you right? I might finish the entries in my table later just for completeness, but I need food and to remind myself what the rest of the family look like... Here is my take on the state diagram. Not much of a surprise there, huh! Apologies for the brevity but with the above information I'm sure you can work out what I'm saying... (Sorry this is so large, using a thumbnail and expansion leaves the text unreadable.) Table: elektor_scms_rom_fsm.pdf Overall I think I'd comment that both the design of the SPDIF frame is smart and the ROM-based design of this "Copy-bit Killer" is also very neat and well implemented. I'll note also from the FSM state diagram above that the "illegal states" (0x0a-0x0f) are also handled. If the machine ended up by error in one of those blocks, if will self-recover back to the initialisation state where it will look for Z preamble again. Good robust design. Actually it's required since IC9, the register chip, doesn't have a reset, so in theory it could come up (from power-on) in any state (any binary value) and thus dump us unceremoniously into any state of the FSM, including the "illegal" ones. Hex dump of the bin file if anyone else wants a play. Open in a text editor. elektor_scms_rom.hex Please post your own homework below :-)

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!).