LARCing around.... (DIY Lexicon LArc?)

[radardoug]

Yes, the early LARCs were metal, but it was before they had come up with the name. I would be very interested in this, maybe PM me?

 

[pvision]

IIRC the early LARC (224 & 224X) was constructed a little bit like the remote for an MCI tape machine. U-shaped base & top panel wrapping round each other. Two contrasting colours. Quite neat for the pre-plastic era

Nick Froome

 

[radardoug]

And then they made the classic! Seen in all the good studio photos!

 

[radardoug]

Chriss, I PM'd you about your LARC, I am interested in it.

 

[chriss]

Hey guys, I'm sorry but my LARC is already sold now. It went to the first one who mailed me - thought that was fair.
Chris

 

[gyraf]

Has anyone information on the communication protocol used in this?

It would be very interesting to know how and what they talk about, the lex&larc

Jakob E.

 

[teddd]

The LARC uses a 9600 baud communication link to the 224XL.  The protocol is a custom protocol.  The data exchange was designed to be general enough so the LARC could be used by from any similar audio processor, but it wasn't designed to be rigorously general-purpose.  Instead, it was crafted pretty much to be LARC-centric to meet the needs of the LARC in its mission to display it's hosts's data on the LARC and communicate control changes back to the host.

IIRC, there is a bit of handshake at the start, then they talk about exactly what you see on the LARC display - the 224XL tells the LARC what the current labels are for the LEDs-over-the-buttons and also the information for the main-LED-displays, and the LARC tells the 224XL what the buttons and sliders are doing.  I'm pretty sure that the two units only exchange "changed values".

The exception (there is always an exception) being the audio levels - I believe the 224XL sends the audio levels to the LARC on a regular basis.  The 224X used to have a very crude 5 LED VU bar graph, and the 224XL sends the same 5 bits of information to the LARC, where the local software implements a smooth fallback to make it look more appealing when displayed on 16 LEDs instead of 5.

I'm pretty sure there is no encryption to the data exchange, and if masking is used it is very light masking (perhaps an XOR with a fixed value or something similar).  Two ways to dive deeper - snoop on the RS-422 link and infer the protocol. or decompile the LARC's ROM.  Neither are particularly onerous - there's not much to the LARC's protocol, and the 8749 only contains 2K of code and 128 storage locations. 

 

[ruairioflaherty]

Fantastic first post Teddd, welcome to GroupDIY.

 

[teddd]

Thanks!  I was just thinking of a brute-force way to get a LARC without actually having one:  run a LARC in an emulator, as follows:

1) Construct or buy a  RS422->RS232 converter, and connect it to the RS232 port of a Raspberry Pi (RPi)
2) Host an Intel 8749 emulator on the RPi.  Emulators for old CPUs are relatively easy to write.  This emulator would be cognizant of the actual LARC hardware peripherals (the schematics for the LARC can be easily found on the internet), and it would keep the state of the various LED outputs in state variables and it would host input variables for the inputs such as sliders and buttons.  This emulator would also host an HTTP interface to allow the communication of the input and output variables with a browser.
3) Construct a web page that communicates with the RPi and displays the LARC UI.

This seems like a relatively straight-forward way to run something that works exactly like a LARC without having a LARC.  The biggest problem (IMO) would be getting the ROM bits from a real LARC's 8749.

 

[nyoung]

Hey gents, I realize that this is a little bit of a dated thread, but I was wondering if this project ever gained momentum.  No worries if not.  I've only just realized how hard it is to come by a larc if you actually need a replacement. 

Neil

 

[pvision]

There is someone selling "new" Larcs on eBay which look to be along the lines suggested in this thread. They are a little bit expensive but clearly someone has put in the time to make it work

https://www.ebay.co.uk/itm/Lexicon-LARC-224XL-480L-replacement/163360756486

Nick Froome

 

[radardoug]

I'm building a copy of the LARC, just got to do some work with interfacing it to a 224, it works fine on the 480.

 

[rock soderstrom]

I'm building a copy of the LARC, just got to do some work with interfacing it to a 224, it works fine on the 480.

*like*

 

[gyraf]

*like*

 

[nyoung]

------>*LIKE!!!*<------  ;D

 

[radardoug]

Thanks fellers, heres another gear porn photo!

 

[nyoung]

Gorgeous.  Do you plan on making it available to the public? 

 

[radardoug]

Yes, they will be available shortly, as soon as I have tested and verified it with the 224XL. I'm having to buy one to do that testing, should be here in a couple of weeks. PM me for more info.

 

[wersi206]

The exception (there is always an exception) being the audio levels - I believe the 224XL sends the audio levels to the LARC on a regular basis.  The 224X used to have a very crude 5 LED VU bar graph, and the 224XL sends the same 5 bits of information to the LARC, where the local software implements a smooth fallback to make it look more appealing when displayed on 16 LEDs instead of 5.

LED VU meter "exception" is not correct, on old LARC led's are driven as peripheral (or "register") on local bus via buffers, and i'm surprised this method passed CE and FCC certification...

On "new" LARC led's are transmitted as 32 bits, there's no any "smooth fallback" on LARC it self, it's all done on mainframe side.

I'm pretty sure there is no encryption to the data exchange, and if masking is used it is very light masking (perhaps an XOR with a fixed value or something similar).  Two ways to dive deeper - snoop on the RS-422 link and infer the protocol. or decompile the LARC's ROM.  Neither are particularly onerous - there's not much to the LARC's protocol, and the 8749 only contains 2K of code and 128 storage locations.

Comms are not encrypted in any way.

Capturing messages going back and forth and emulating those is good enough, but you'll end up with many situations where emulation system doesn't work well.

Getting code out of 8749 can be very hard, given that those chips are 40 years old (sometimes die on it's own in normal operation), to get code out you need to hook 4x voltage then normal operation voltage on some pins and hope it won't burn out.

Original code for LARC was written in assembler, same functionality written in C and compiled for same familiy of CPUs will need more then 2k of ROM...
ROM is actually quite tightly packed, there are very few unused ROM locations (3 bytes in vector table, 6 at the end, few around string tables....).
For this reason it's not quite straight-forward to reverse engineer it, as it might be for code generated by compiler following any binary interface standard.

My point is: there's bit more to it then just simple say "this is easy".

 

[radardoug]

I've got more than 300 hours invested in my LARC. Its a lot harder than it looks, particularly when you have to work with hardware that wont do exactly what you want!