Elektor copybit stripper

[James_S]

Apologies if this is not the right place for this. I'm trying to help a friend out with a project, he's trying to build one of the copybit strippers that was published in Elektor about 20 years ago detailed here http://www.minidisc.org/copybit/copybit.html It's a clever design that uses a ROM based state machine built of jellybean parts however he has been unable to find the code for the ROM and my Google-fu has come up dry as well. It was at one point offered as a kit but it seems that company is long gone. Has anyone here actually built one of these? The ROM is a standard 27C512 so dumping the contents is trivial if I could locate a unit to read it from. If anyone does have one of these or better yet has already dumped the firmware from one that would be fantastic.

[bluecrab]

Right place, but maybe a tough question. That does go way back. I've never seen a report of one that was actually built, but maybe someone here has.  I owned a Hucht ICP 1-CE Copyprocessor for a long time; now I rely on the MDS-E10 for SCMS killing. If Mr. Hanft is extant, perhaps you could try to contact him?

[sfbp]

With respect, we know so many simple ways to get around SCMS, this project is kinda moot.

1. Buy a pro model (for around $200?) such as the MDS-E10
2. Get a device like the Behringer Ultramatch Pro
3. Buy a $20 sound card for a PC - the majority of them don't care about SCMS and allow you to disable it, period.

The major problem people have with MD these days is the folks who unwisely used NetMD to make LP2 disks (excellent quality, 2-3 CD's per MD) but now have "lost" the original CD (or perhaps never had it except briefly) and want to get the data off the MD. There is almost nothing to fix this problem except playing back at x1. Granted, you will still need to get over the SCMS problem then. But there's no SCMS in the actual ATRAC file, I think.

In addition there are so many other pesky restrictions designed to protect Sony a. as a content producer b. against lawsuits like the one over the Betamax that almost finished them off 40 years ago, and we know all of them, that the SCMS is probably the least of them. 20 years ago it may have presented as the most significant stumbling block to copying music. Today, it ain't.

Good luck in your quest. Or stick around here to see the real life solution to what I can only guess is the the real life problem.

Cheers

[James_S]

Oh he's aware of other ways to get around SCMS, I found at least one other open source project too. I haven't asked what he actually needs it for but knowing him I suspect it's more a case of the ROM based state machine being an interesting approach to the problem and something fun to play around with. I know he also does a fair bit of repair, refurbisment and other work for a recording studio that specializes in vintage gear so it may be related to that, I can ask if anybody actually cares. We're both engineers with an interest in retro tech as much for the technology itself as for any real need for what it does. While I have no need for it myself, indeed I don't think I even own anything that can record from SPDIF the design piqued my interest when I saw it because it reminds me of the vector generator state machine that Atari used in their vector graphics arcade games from the late 70s-early 80s, those being a long time hobby of mine. Anyway if something turns up great, if not, well as has been pointed out here there are other solutions. It just bugs me because I know there must be a handful of these things kicking around someplace, somebody somewhere must have built one. I've found ROMs for obscure computer equipment from the 1980s so I thought this would be easy.

[sfbp]

I took a look at that web page, you can get a lot of kit for 126 Euros these days

[kgallen]

[ETA] Sorry James, I realise you already bagged the EPROM as part of an FSM. I wrote the below on my phone first thing having not read the entire thread above!

The EPROM does not contain machine code for a microprocessor. It’s used as a neat way to implement a finite state machine (standard digital electronics building block). It’s job is to match a sequence of bits in the SPDIF [***] preamble in order to identify the  SCMS control bits which the rest of the circuit then override and reconstruct the SPDIF stream.

Maybe there is some circuit description in the magazine article [*] that describes this and thus you could work out the EPROM contents. 
Do some investigation then come back here with some details and I can probably help you decipher what you need. 
 

Kevin

[*] I’ve got a feeling I have a scan of that article [**].

The EPROM implements the ‘next state’ logic and IC9 holds the ‘current state’.

All the crazy stuff at the top of the schematic is about clock recovery!

Just look at IC7,8,9. IC7 is a shift register clocking in the SPDIF data stream. The first job for our IC8,9 FSM is ‘frame alignment’ as bits arrive in IC7 and get presented to the EPROM.  ‘Bits’ (pins) 18 through 12 on IC9 are your ‘current state’.

 

[**] A had a Google too. It seems Elektor did at least 3 articles on SCMS circuits. I can't get to any of these, even after registering on the Elektor site, as you need a paid membership to access these articles. The article I do have a copy of is for a different SCMS copy-bit killer circuit, again from Elektor, but from June 2002. As with the circuit you refer to, it uses an EPROM as a nifty way to perform the next-state logic, but this logic is specific to their circuit design, so even if I had the ROM contents they wouldn't be correct for your particular Elektor project.

[***] There is some framing/protocol information on epanorama or HwB or scanlime. As I'm sure you've already worked out, the circuit aims to make bit 2 of the ChannelStatus a logic '1' (copy allowed).

[James_S]

I did find the article detailing the construction, unfortunately it doesn't have any specific details about the code in the ROM, only a mention that it was created with the help of a Pascal program which does not appear to have been offered. From what I can see, the source file for the EPROM was never offered directly, the author's company would supply either a programmed ROM, a partial kit with the ROM and PCB, or a complete kit with everything, none of which is any help since the company is long gone and I would not be surprised if the author is dead by now.

 

Yes I'm sure we could work out the "code" to implement a ROM based state machine duplicating the function of the original design given sufficient effort although that could prove to be quite a lot of work and push the effort required to build this one beyond what is reasonably worth doing. I am intrigued by the design though, I have built finite state machines in FPGAs before and but other than in the Atari vector games I can't think of any other places I've encountered one in "real life".

[kgallen]

Hi James,

No problem - I'd understood that you wanted this as a learning/academic exercise - earlier in the thread we've already discussed the more practical solutions to the problem with ready-made products.

Regards the Pascal program, this is something you could code in C or Perl or Python or Tcl, or even Verilog/SystemVerilog or VHDL if that is what you used for your FPGA design work. All it's doing is taking the grind out of converting your FSM next-state logic design into a file to feed your EPROM programmer (Hex, Intel or S-Record file).

I'm not trying to suggest this is trivial by any means, but it is certainly a tractable and interesting/valuable exercise in FSM design with ROM. Most of the ROM will contain very boring numbers. For example, most of the time, the circuit should just copy the SPDIF input to the SPDIF output. It's only that Copy bit that we're trying to intercept and change to a '1'. What this means, is for most states, the EPROM D0 output (which is the SPDIF output) is the same value as input A0 (the "oldest" bit in the SPDIF input shift register).

What this means, is that for many addresses, A[15:1]=X, A[0]=0 the ROM location contains 0x00 (i.e D0=0) and for A[15:1]=X, A[1]=1 the ROM location contains 0x01 (i.e D0=1). That is your "background fill" for the ROM. However some of these addresses need overwriting with your FSM design and as previously discussed, this needs to watch the SPDIF input bits arrive at the shift register parallel output (on A[7:0]), look for the framing signal, then step through subsequent bits until the Copy bit is aligned with A[0] and then, instead of outputting "A[0]" on D0, it outputs a '1' (i.e. you will have a memory location with A[0]=0 that has D0=1 rather than the D0=0 we would have had from our "background fill").

Regards FSMs in real life. Any non trivial digital logic is jam-packed with FSMs. They are so fundamental they are ubiquitous. Even a simple digital counter is an FSM. It has states 0,1,2,3,4,...,(n-1),0,... So your clock radio, microwave oven, TV, MD/CD/DVD/video machines, phone, computer, car, DAB radio, calculator, digital watch, FitBit, Xmas tree lights etc etc etc!!!

Good luck and enjoy!

Kevin

[James_S]

Thanks I'll pass that on and see what happens, as an academic exercise it's worth spending some effort on but it's not worth expending a tremendous effort, your explanation combined with what I already know does make things significantly clearer.

Oh yes I realize that FSMs are everywhere, but most of the time these days anything more trivial than a counter or flip flop is typically just done in software with a microcontroller. This particular type of FSM using a ROM that addresses itself through a latch has not come up often but perhaps it was more common back in the 80s. It's also entirely possible that it is a common building block used in ASICs.

[kgallen]

9 minutes ago, James_S said:

Oh yes I realize that FSMs are everywhere, but most of the time these days anything more trivial than a counter or flip flop is typically just done in software with a microcontroller.

Nope, sorry. I'm a (digital) IC designer by day (and night more often than I'd like!). Hardware FSMs are our bread and butter! We love our software boys dearly, but there is a damn lot of complex hardware behind that software (if there is any software involved at all) and the bulk of it is based around implicit or explicit FSMs! There are ~6 billion transistors in the last chip I worked on and a similar number in the current one [that I'm supposed to be working on now, not typing this!]. OK there is a lot of memory in that, but there are also many millions of flip-flops that are part of FSMs, counters, FIFOs and other control type structures.

From a conversation with a non-techie I had a few years ago (maybe at a wedding or something like that): "Oh, you're a silicon chip designer? I thought we dug them up." - yep, they come straight out of the silicon chip mine and they know from birth they're a mobile phone modem/microwave oven controller/TV display controller/toothbrush driver... <add an almost unimaginable number of other electrical devices>

Thinking more widely about the various jobs that people have across the world to create products, provide services and the like, I can imaging the "man on the street" would be totally amazed at the type of jobs there are out there that they wouldn't envisage in daily life, but enable that life. It's easy to comprehend a builder or a shop worker or an accountant, but there are so many "behind the scenes" jobs that enable modern life that most of the general public are just oblivious to!

Anyway I digress... Hope you give it a bash even if you don't manage to work out the entire FSM!!! :-D

[James_S]

That's actually fascinating, it makes me realize that I've often viewed more complex and specialized ICs as a black box that does stuff without really thinking about what goes on inside it. I suppose it's the case that these FSMs are integrated into ASICs so they're there, but the end user designing them into something or working on existing equipment doesn't have any visibility into what's happening inside. Now I'm wondering what other devices implemented this sort of discrete design.

The vector generator I mentioned is fascinating in that it's essentially a simple coprocessor that reads instructions out of a RAM and then draws the vectors on the monitor without intervention from the 6502 CPU. The CPU loads the object(s) to be drawn into the vector RAM and then the vector generator takes care of the heavy lifting and lets the CPU know when it's finished. This enabled extremely primitive (by modern standards) hardware to generate some really impressive high resolution graphics with glassy smooth framerates. I don't want to take this completely off topic but for anyone interested there is an excellent writeup by one of the original designers here: https://www.jmargolin.com/vgens/vgens.htm

[kgallen]

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 Hardware Description Languages or HDLs. This description can't be "anything and everything" you like in these languages, you have to use particular constructs in particular contexts to "infer" meaningful structures like combinational logic or flip-flops (an abstraction we call Register Transfer Level, or RTL). Then we use a process called logic synthesis which converts the HDL description into a logic netlist (AND, OR, NAND, NOR gates, flip-flops etc). This logical netlist then has to be "layed out" onto silicon by taking the transistors of each gate and mapping them onto silicon and defining the layers that are needed in the silicon (wells, channels, contacts), then these transistors have to be wired together by creating metal interconnects that join silicon contact to silicon contact in the required circuit topology. We also have to add power meshes and clock distribution networks and fix the timing of the circuit (setup and hold). Once the physical design is complete and the layout meets all of the logical and physical design rules, the design can be sent to the silicon foundry at a point we call "tape out". The foundry do the magic chemistry steps to actually fabricate our design onto a silicon wafer. Then there is test and packaging assembly and a whole load of qualification testing to be done before the device can be released as a production part. This is a design cycle that is typically between 1 and 3 years depending on the complexity and size of the design. That's an extremely brief and simplified overview, but I'm sure you could google for more detail!

Back to FSMs we wouldn't usually (ever?) use a ROM style implementation on a custom chip, we'd use an HDL to infer "random logic" to build the next-state logic. The ROM method used in the project you are looking at is a clever way to implement "random logic" in one off-the-shelf chip - couple it with a bank of flip-flops (like IC9) and you have yourself the building blocks for your FSM. The clever bit now is to work out the ROM contents which is how you define the logic of your FSM and hence its function/behaviour. There are a couple of flavours of FSM, Moore and Mealy. These terms describe how the state and outputs are a function of the inputs (Moore -> outputs are only a function of the current state, Mealy -> outputs are a function of the current state and the current inputs). Your copy-bit killer is probably a Mealy machine (the output SPDIF flop stage is not part of your FSM state because it doesn't feed back into the EPROM).

Anyway that's enough from me for one night!

[bluecrab]

On 3/30/2020 at 1:06 AM, sfbp said:

With respect, we know so many simple ways to get around SCMS, this project is kinda moot.

1. Buy a pro model (for around $200?) such as the MDS-E10
2. Get a device like the Behringer Ultramatch Pro...

Have the E10, but would like to know if the Behringer and its close kin preserve track marks.

Also, my HHB-BurnIT (standalone CD-R) kills SCMS; between it and the E10 I'm well-covered...but I am hoping to outlive both units, so just looking ahead in a hopeful way.

 

 

[sfbp]

Sorry, I missed your question.

I think the answer is a resounding NO, because what is required is for the transmitter to actually DROP the line. It is my impression that the PCLK does.

[bluecrab]

6 hours ago, sfbp said:

Sorry, I missed your question.

I think the answer is a resounding NO, because what is required is for the transmitter to actually DROP the line. It is my impression that the PCLK does.

Thanks. Here's a way I have foiled SCMS. Elegant it is not. I do have some CD-Rs that have SCMS because of how I copied them. Rip the CD-R. [Insert mp3 silent track of a few seconds between the ripped tracks.] Copy via opt. out to MD. I guess when you rip the CD-R, SCMS goes away? Anyway, the silent tracks almost always do the trick for track marking, when SmartSpace is enabled. Too well do I recall the bad old days when SCMS was a real monster for MD users.

[kgallen]

10 hours ago, sfbp said:

I think the answer is a resounding NO, because what is required is for the transmitter to actually DROP the line. It is my impression that the PCLK does.

I'm a little lost - are we talking here about external kit (like Behringer SRC2496) preserving track marks, or about killing the SCMS bit?

Thanks!

[sfbp]

To make a track mark, you either have to have something which drops the line completely, or something which causes the signal to go below a certain level AND a MD recording device which is set to make a track mark when that happens.

I think the PCLK-MN20 fakes out the complete line drop.

Time to do some experiments, Kevin. I've spent so many hours on this issue fiddling about that I've forgotten the issues. Your analytical mind can probably resolve this better than any of us.

Bruce's comment about SCMS was about the fact that using the Behringer to defeat SCMS leaves you with a signal that doesn't go low enough to trigger track marking. Right?

(this is what routinely happens when I answer one of these exchanges when I'm up in the wee hours - I start babbling. More in daylight hours!)

[kgallen]

Other than threshold crossing detection to insert track breaks when doing recording from analogue, I've no idea how track marking works. I assumed over SPDIF there would be information in the frame that provided either some kind of sequence number (change in sequence number = new track) or an explicit track marker packet. Looks like I need to do some material research and reading up!

Yes, Stephen, I do see you replying at what must be unearthly hours in your neck of the woods, I hope you are looking after yourself!

[bluecrab]

14 hours ago, sfbp said:

Bruce's comment about SCMS was about the fact that using the Behringer to defeat SCMS leaves you with a signal that doesn't go low enough to trigger track marking. Right?

(this is what routinely happens when I answer one of these exchanges when I'm up in the wee hours - I start babbling. More in daylight hours!)

Right. In fact, I had an instance where, when streaming audio, if I reduced the volume by about  a third, I did get most track marks. But I indeed was asking about the Behringer.

[kgallen]

Random, sorry, but I just dug up the Behringer manual page on SCMS for the SRC2496 so thought I’d capture the section here for reference (yes I know you can download the pdf from the Behri website). This also shows all 4 combinations of the two binary digits.

[sfbp]

I bought mine new and never (well, hardly ever) looked at the manual which I am sure is sitting upstairs on top of the device. Thanks.

[kgallen]

8 minutes ago, sfbp said:

I bought mine new and never (well, hardly ever) looked at the manual...

Bought mine new too and it’s never been out of the box since a couple of weeks later I did your option 1). I think it was my E12 but same result!

[kgallen]

Another "random" picture on SCMS copy bit values, this time from the Sony MDS-B5 Service Manual (click thumbnail):

[zedstarr]

 

Coincidentally I've just retrieved my Elektor SCMS "copybit killer" from storage and had a play with it :) The pots to light the correct sample-rate LEDs needed a tweak but it still works fine. I'd also retrieved some of my "old" HiFi gear from storage too, including the MDS-JB930 minidisc deck! And my old Technics RS-B665 tape deck which I've since built a wireless remote control for, but that's another story :-)

I bought the Elektor kit in Jan 2000 (I faxed the order over to Germany, how quaint :-D ) and used it a lot at the time for MD-MD copies. According to the invoice it cost me £48.38

I've imaged the ROM (and already discussed at length with the OP over on another forum!) initially using a Raspberry Pi (without level shifting) but I was worried about data integrity as the 27C512 is an old 5V part and the Pi GPIO is all 3V3 and not 5V tolerant. So I splashed out on a TL866 USB programmer and double checked. The original image good was after all. Reading the old 5V part at 3V3 at slow speed (1ms between reads) worked for me.

Fascinating insight into the design of the SCMS stripper - in my career the last time I came across a (very badly designed) ROM state machine was in some Telecom kit (actually deep inside a System X telephone exchange in 1994 8-) )

 

 

[NGY]

26 minutes ago, zedstarr said:

I've imaged the ROM

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

[zedstarr]

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?
 

[NGY]

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.

[zedstarr]

I've discovered the original article can be found in the Jul-Aug 1998 issue of Elektor held in the archives of https://worldradiohistory.com/Elektor.htm

There's some detailed description of the pattern matching and/or ROM contents in there. 

Edited February 13, 2021 by zedstarr
Typo

[zedstarr]

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

[sfbp]

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!

[NGY]

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.

[sfbp]

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.

[kgallen]

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 )

[NGY]

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

[zedstarr]

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

[kgallen]

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

[zedstarr]

24 minutes ago, kgallen said:

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

I did indeed, it's compulsory isn't it? :-D 

[kgallen]

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

[zedstarr]

SPDIF format - we're looking at the physical layer line code, not the actual audio data itself hence the "bi-phase" bit references below. 

Edited February 19, 2021 by zedstarr
clarity

[kgallen]

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