Jump to content
Sony Insider Forums

Elektor copybit stripper

Rate this topic


Recommended Posts

3 minutes ago, NGY said:

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

Seeing as "Stippler Elektronik" the original suppliers are no more and the original Pascal source was never published I don't see why not, for "educational" purposes.

Are you planning on building a copy?
 

Link to post
Share on other sites
  • Replies 75
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

I'm wayyy off topic here, but if you like my waffle... These days (since early 1990s) we do the logic design with specialised software languages like SystemVerilog or VHDL, generally known as Har

Posted Images

2 hours ago, zedstarr said:

why not, for "educational" purposes.

Are you planning on building a copy?

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.

Link to post
Share on other sites

For completeness here's an update on what I've managed to find out about the original article/author:

First published in most European language versions of Elektor 12/1997, English language version 07-08/1998
Author: Dipl.-Ing. Hans-Juergen Hanft (not credited with any other projects on Elektor) no contact details found
Georg Stippler - Stippler Elektronik, Bissingen Germany (suppliers of the kit/components) no contact details found
At the time the Magazine Editor was Len Seymour - has his name on some books of collections of projects that were published like "305 circuits" etc. but not much else
At the time the Technical Editor was Jan Buiting - he's now the Editor, still very active at Elektor and contactable on LinkedIn or via email. I reached out to him and his reply was:

Quote
Very sorry but I have nothing on the project. Most project files and software carrier originals relevant to pre-2000 projects were discarded during a move of our labs and editorial offices, and several restructurings of the Elektor website and store.
 
Best I can advise is to issue a call for help on the Elektor Labs website.

So, I have registered a trial membership on Elektor's "Labs Website" and have asked there also....

Link to post
Share on other sites

There's no way it is protected by patent, way too much time has gone by. It's not a trade secret, since it was published. So you have zero worries about copyright. Charge ahead!

Link to post
Share on other sites
24 minutes ago, sfbp said:

There's no way it is protected by patent

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.

Link to post
Share on other sites

Fair enough, the actual contents of the ROM were not published. But the description was published of the invention and its methodology, so whether a particular implementation is a trade secret is hardly a thorny question when you consider what's happened, generally, in the last 23 years in terms of law about such things.

I don't believe anyone is in legal jeopardy here. The owners of any copyright would have to go to great lengths to protect something so old, and they probably can not.

The only legal issue is from those who USE the technology to break some sort of intellectual-property protection of ideas or data. And that ship has sailed a long time ago.

Rest easy.

Link to post
Share on other sites
On 2/19/2021 at 3:31 PM, NGY said:

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.

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 )

Link to post
Share on other sites
42 minutes ago, kgallen said:

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.

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

Link to post
Share on other sites
11 minutes ago, kgallen said:

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.

Snippet:  0x717 & 0x81D locations of note 

000006e0  0e 0f 0e 0f 0e 0f 0e 0f  0e 0f 0e 0f 0e 0f 0e 0f  |................|
000006f0  0e 0f 0e 0f 0e 0f 0e 0f  0e 0f 0e 0f 0e 0f 0e 0f  |................|
00000700  0e 0f 0e 0f 0e 0f 0e 0f  0e 0f 0e 0f 0e 0f 0e 0f  |................|
00000710  0e 0f 0e 0f 0e 0f 0e 11  0e 0f 0e 0f 0e 0f 0e 0f  |................|
00000720  0e 0f 0e 0f 0e 0f 0e 0f  0e 0f 0e 0f 0e 0f 0e 0f  |................|
00000730  0e 0f 0e 0f 0e 0f 0e 0f  0e 0f 0e 0f 0e 0f 0e 0f  |................|
00000740  0e 0f 0e 0f 0e 0f 0e 0f  0e 0f 0e 0f 0e 0f 0e 0f  |................|
00000750  0e 0f 0e 0f 0e 0f 0e 0f  0e 0f 0e 0f 0e 0f 0e 0f  |................|
00000760  0e 0f 0e 0f 0e 0f 0e 0f  0e 0f 0e 0f 0e 0f 0e 0f  |................|
00000770  0e 0f 0e 0f 0e 0f 0e 0f  0e 0f 0e 0f 0e 0f 0e 0f  |................|
00000780  0e 0f 0e 0f 0e 0f 0e 0f  0e 0f 0e 0f 0e 0f 0e 0f  |................|
00000790  0e 0f 0e 0f 0e 0f 0e 0f  0e 0f 0e 0f 0e 0f 0e 0f  |................|
000007a0  0e 0f 0e 0f 0e 0f 0e 0f  0e 0f 0e 0f 0e 0f 0e 0f  |................|
000007b0  0e 0f 0e 0f 0e 0f 0e 0f  0e 0f 0e 0f 0e 0f 0e 0f  |................|
000007c0  0e 0f 0e 0f 0e 0f 0e 0f  0e 0f 0e 0f 0e 0f 0e 0f  |................|
000007d0  0e 0f 0e 0f 0e 0f 0e 0f  0e 0f 0e 0f 0e 0f 0e 0f  |................|
000007e0  0e 0f 0e 0f 0e 0f 0e 0f  10 0f 0e 0f 0e 0f 0e 0f  |................|
000007f0  0e 0f 0e 0f 0e 0f 0e 0f  0e 0f 0e 0f 0e 0f 0e 0f  |................|
00000800  10 11 10 11 10 11 10 11  10 11 10 11 10 11 10 11  |................|
00000810  10 11 10 11 10 11 10 11  10 11 10 11 10 13 10 11  |................|
00000820  10 11 10 11 10 11 10 11  10 11 10 11 10 11 10 11  |................|
00000830  10 11 10 11 10 11 10 11  10 11 10 11 10 11 10 11  |................|

Also - complete binary attached :-) I wanted to exhaust some of the other avenues of looking for the original author etc. before dumping the contents anywhere. 

Quote

Echo the thanks to @zedstarr (and forward posthumous greetings from GPT Beeston to GPT Liverpool :-D )

Gratefully received. I have Happy Memories of riding the paternoster lifts in the Beeston Engineering block :-D

 

elektor_scms_rom.bin.zip

Link to post
Share on other sites
1 hour ago, zedstarr said:

Gratefully received. I have Happy Memories of riding the paternoster lifts in the Beeston Engineering block :-D

elektor_scms_rom.bin.zip 774 B · 0 downloads

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

Link to post
Share on other sites

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.

ROM_FSM.PNG

(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...

Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
Share on other sites

As I read the file in Linux (on the Raspberry Pi) there's hexdump and xxd - tools that can format & decode the binary into ASCII hex. (both seem to be present on MacOS too tho you'll need to open the terminal to use these command-line utilities.)

Link to post
Share on other sites
19 hours ago, NGY said:

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 teh dumb question, but how can one "split a bit" into another 32 bits? I am missing here something bit time.

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

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

Link to post
Share on other sites

Looking back at some of the references I posted before, the SPDIF format is:

- biphase mark for all bits except the preamble (sync) bits.

518px-Biphase_Mark_Code.svg.png

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.

Link to post
Share on other sites
2 hours ago, kgallen said:

the CCS is multiple bytes long, so it's conveyed over the frames, 1 bit at a time - 1 bit per frame

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)

Link to post
Share on other sites

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. 

Link to post
Share on other sites

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

Link to post
Share on other sites
8 hours ago, NGY said:

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)

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

Link to post
Share on other sites
1 hour ago, kgallen said:

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

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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...